Apple's iOS security model

Before we jump to iOS apps in detail, it is vital to understand the fundamental security features of the iOS platform, which are crucial during app assessment.

The following diagram shows the security architecture of an iOS device and also provides an overview of security features implemented from the hardware level to software stack:

Roughly, we can split the iOS security model into these layers:

• Device-level security
• System-level security
• Data-level security
• Network-level Security
• Application-level security
• Hardware-level security

Device-level security

At the device level, the security model ensures that unauthorized personnel cannot use a user's device. It enforces a device-level lock such as a PIN or passcode, remote wipe using mobile device management (MDM), and options such as activation lock and finding your phone. Strategically, Apple allows the signing of configuration profiles, thereby allowing companies to centrally distribute all configurations to the device in a secure way.

These kinds of configurations can restrict the device by applying a particular policy, for example, making it impossible to open an application on a device that is jailbroken.

System-level security

Apple designed the system-level security layer by authorizing system software on or before system updates and implementing a secure boot chain, Secure Enclave, and Touch ID.

An introduction to the secure boot chain

The mechanism that maintains the integrity of iOS from firmware initialization to loading the code into the iOS device is termed the secure boot chain or chain of trust. This chain ensures at all levels from hardware to software, making sure the code are trusted, tamperproof and run only on valid devices.

The following diagram shows the secure boot chain in an iOS device:

The entire chain of trust is maintained since Apple signs every single step. In simple terms, when a device is booted, the processor executes the code from Boot ROM, which is also called the hardware root of trust, and it is essentially connected to the chip's fabrication, which includes Apple's root CA certificate. Before iOS loads, the Low Level Bootloader (LLB) needs to be signed by Apple. Once the LLB is passed and the verification is done, the next stage, iBoot, is loaded, and finally, the iOS Kernel is executed. iBoot normally acts like the second-level bootloader, which is responsible for verifying and loading the iOS Kernel into the device.

System software authorization

Normally, software update pushes in iOS are done through iTunes or over the air. The mechanism by which Apple prevents malicious users from downgrading the existing iOS version to a lower one is done through system software authorization.

Secure Enclave

To prevent kernel-level attacks, Secure Enclave was introduced at the hardware level to ensure that integrity is never compromised. This is independent from the application processor. Interestingly, the version of Secure Enclave used on the latest A7 or A8 Apple processors comes with unique IDs that are not known to Apple. Secure Enclave is also responsible for Touch ID sensors, fingerprint verification, and access approval.

Touch ID

This is nothing but the fingerprinting technology added by Apple to its latest devices, with which users can protect their devices from unauthorized access. However, even if Touch ID is enabled, it is possible to unlock the device with a valid PIN or passcode.

Data-level security

The biggest challenge that developers have to deal with is data storage on mobile devices. Data-level security is primarily aimed at protecting data that is not in transit. This is normally achieved by enforcing encryption techniques using hardware and software components and also through data-protection classes. You can set up the device in such a way that it can remotely wipe all the data if a predefined number of attempts has been made to unlock the device in the case of a stolen or lost device. All the techniques involve encryption keys combined with device passcode or PIN.

We will discuss some important techniques of data protection in the following subsections.

Data-protection classes

Here is a list of important data-protection classes:

• NSFileProtectionComplete: It provides complete protection; to access the file, one must always enter the passcode or use Touch ID.
• NSFileProtectionCompleteUnlessOpen: It provides complete protection to the file unless it is open.
• NSFileProtectionCompleteUntilFirstUserAuthentication: It provides complete protection to the file until it is opened. This is the class most commonly deployed by third-party application developers.
• NSFileProtectionNone: It provides no protection, but still, files in iOS are encrypted by default.

The following diagram illustrates the data-protection API:

Application developers can protect files or keychain items by using data-protection classes. This normally includes whether the class protects the files or keychain items. As illustrated in the preceding diagram, on the left, NSfileProtectionNone indicates that data can be accessed any time even if the device is locked. On the right, the NSProtectionComplete class is used, which means that data can only be accessed if the device is unlocked either by passcode or fingerprint.

Keychain data protection

A keychain is engaged by Apple to perform basic-level password management. Similar to the previous file data protection classes, keychain data is also protected with classes:

• kSecAttrAccessibleAfterFirstUnlock: Keychains can be accessed while the device is locked but in the case of a reboot, it requires an unlock before allowing access to data
• kSecAttrAccessibleWhenUnlocked: All the keychain data will be accessible when the device is unlocked
• kSecAttrAccessibleAlways: All the data is accessible at any point of time
• kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: This is similar to kSecAttrAccessibleWhenUnlocked
• kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: This similar to kSecAttrAccessibleAfterFirstUnlock, but data migration between devices through backups is not possible
• kSecAttrAccessibleAlwaysThisDeviceOnly: This is similar to kSecAttrAccessibleAlways, but data migration is not possible through backups

A keychain is a single database; every time a keychain item is requested by an app or process, the request is sent to the security daemon, which verifies the keychain item, and decryption happens through Secure Enclave. The keychain data accessibility also depends on the state of the service.