Hello Friends!

Security continues to grow and become a more pressing issue every day. I have been working extensively on some security engineering in the mobile space to improve both the security posture of devices, but also improve the delivery of payloads on devices. Sadly, you cannot have one without the other. It’s often difficult to help people understand why they aren’t getting new versions of apps or a profile update didn’t come through yet. I’m going to cover a few areas that I think will be very helpful to other Mobility people out there.

The security footprint of iOS is growing and evolving daily. People think its simple, but it has many layers of complexity as you can see…

We will talk about these areas:

• System Security
• Data Protection

My belief is that achieving a deeper understanding of these key areas will help many of my peers be more effective and set expectations with their users. That is the goal of everything that I write. I simply want to elevate us to a new level and show people how valuable mobility is.

System Security

I have spent much of my career preaching about the relationship and flow of client to server. Apple focuses on securing that channel in a few different ways, including the boot-up process, OS updates, and their lifeblood the Secure Enclave. We need to understand those parts to have a good understanding of the device’s architecture.

The Boot Up Process

Apple’s secure boot chain focuses on certificates around their bootloaders, kernel, its extensions, and the baseband firmware. This gives them a degree of tamper-protection that is paramount to their success.

The diagram below is a helpful representation of how it works, but essentially the following happens:

1. Device is Powered On
2. The App Processor executes code from Read-Only Memory known as the BootROM (Hardware Root of Trust) aka code built into the TPM chip during fabrication including the Apple Root CA to create a trusted chain back to Apple.
3. Some older devices will go to the Low-Level Bootloader (LLB) to load and verify the BootROM, which then loads iBoot.
4. On newer devices, BootROM will load iBoot (a stage 2 bootloader for all Apple products). iBoot’s job is to authenticate and validate your OS before proceeding to load the iOS kernel and operating system.

The important thing to note is any failure of LLB or iBoot is what causes a device to go into DFU mode (aka recovery mode). It’s important to understand how it flows and DFU mode actually does besides letting you reload your OS.

System Software Authorization

Apple’s startup process creates a solid foundation, but it needs to be thorough. They built their system software authorization process to ensure OS downgrades cannot occur. The key things to know are:

• iTunes downloads a full copy of the OS during installation
• OTA software updates only download the new components
• MacOS High Sierra supports OS software caching to improve performance

The steps to OS validation against the SSA are:

1. iTunes or the Device connects to the SSA
2. The SSA sends a list of the crypto measurements for each part of the install bundle
   1. iBoot
   2. Kernel
   3. OS Image
   4. Random Anti-Replay Value (nonce)
   5. The Device UID
3. The SSA checks the measurements against its allowed list.
4. If successful, it adds the UID to the measurement and signs the result, which ensures that only that device can use the data it will send back.
5. The SSA sends a complete set of signed data to the device as part of the upgrade process.
6. When the device boots, the chain of trust evaluation will verify the signature comes from Apple and the data returned from the SSA matches the signature. This protects against spoofing and other attacks.

Secure Enclave

The Secure Enclave is arguably the most important aspect of iOS security today. It is a co-processor that is fabricated in Apple’s T1, S2, S3, A7, or later A-series processors. The key features of the Secure Enclave are:

• Runs an Apple-modified version of the L4 microkernel
• Uses Encrypted Memory
• Uses a Hardware Random Number Generator
• Provides all Crypto Operations for Data Protection key management
• Persists and maintains integrity of Data Protection with a compromised kernel
• Communicates with the Application Processor through an isolated interrupt-driven mailbox and shared memory data buffers
• Apple-signed microkernel that is verified during the iOS secure boot process
• Regularly updated through the SSA process mentioned earlier
• Encrypts data that it saves with a key that contains the UID and an antireplay counter.
  • This process is used to revoke data in certain situations like passcode changes, Apple Pay account changes, device wipes, Touch ID or Face ID changes, etc.

Boot Process with Secure Enclave

1. Device boots up
2. An ephemeral key is created with a hash of the device UID, and used to encrypt the Secure Enclave’s portion of device memory
3. Outside of the A7 Chip, the Secure Enclave’s memory is authenticated with the ephemeral key.
4. On the A11 Chip, an integrity tree will be used to prevent the replay of security-critical Secure Enclave memory, authenticated by the ephemeral key and nonces stored in on-chip SRAM.

Data Protection

User Data is arguably more important than the OS itself. The balance between protecting data and the impact of that protection is very visible. We have for years been plagued by Symantec Antivirus and friends obliterating our PCs. With that in mind, Apple knew that to perform complex crypto ops that they would need to make them efficient. We should keep a few things in mind:

• iOS Devices use a 256-bit crypto engine built into the DMA (Direct Memory Access) path between flash storage and main system memory
• The engine makes their encryption very efficient
• Devices with an A9 Chip or later has an isolated bus housing the flash storage subsystem
• The flash storage subsystem leverages the DMA crypto engine to get access to memory locations holding user data
• During manufacturing,  the device UID gets a fused AES-256 bit key and the Group ID (GID) gets a compiled AES-256 bit key on the application processor and secure enclave
• Software and Firmware are unable to read the keys, but they can see the results of encrypt or decrypt operations performed by the dedicated AES engines on the device.
• The AES engines use the device UID and GID as keys implemented in silicon for the crypto operations
• The Secure Enclave’s UID and GID can only be used by the AES engine dedicated to the Secure Enclave.
• The UID and GID are shielded from debugging interfaces like JTAG
• UID’s are unique to the device itself because its generated inside of the Secure Enclave. Neither Apple nor its suppliers have access to it.
• The UID is part of the layers of keys that make up the Secure Enclave architecture.
• The GID represents a group of devices (e.g. all devices using an A8 chip)
• The remainder of keys on an iOS device are generated by its RNG (Random Number Generator for you non-nerds)
• The RNG uses an algorithm based on CTR_DRBG

Apple does many things to make their data protection robust. One of the interesting things they do is leverage system entropy. The concept is very interesting. They basically measure the level of disorder/interruption in a system. The system uses timing variations and interrupt timings once the boot completes. As mentioned earlier, these keys use the RNG inside of the Secure Enclave, which is based on multiple ring oscillators post processed by the CTR_DRBG algorithm.

Erasing keys is probably harder to achieve than Apple’s key creation process. The fact they exist on flash storage makes it much more challenging. They use a very neat technology called wear-leveling to prolong the life of the storage and properly cleanup keys. They also use a technique called effaceable storage to access the storage technology and address a small number of blocks at a low level.

File Data Protection

People often think the idea of having contacts and email on your phone while also receiving a phone call at the same time is really simple. The fact is that it is quite complex. As I mentioned earlier, it can be very challenging to efficiently encrypt content while also performing normal operations. Data Protection, which is the encryption of data in flash storage is provided by default for system applications and on 3rd party apps from iOS 7 or greater.

So how does this mystical data protection work you ask? Well, Apple loves their keys right? I think anyone with a RSS feeder knows that. Data Protection is no different as it maintains a hierarchy of keys to secure your data. This is where their security becomes increasingly complex on iOS. Each file is assigned a class and accessibility depends on if the class keys are currently unlocked. The new Apple File System (APFS) has made this even more of a cluster you know what by further dividing keys into per-extent (that means that a specific part of a file could have a separate key).

The Architecture

Let’s start by talking about how individual file encryption works. Every time you create a file it creates a per-file encryption key. The flow below shows you how a file is saved to flash memory with data protection.

Things get really interesting if your device is using APFS (which will be most devices now). The APFS format tends to clone files (the concept of zero-cost copies with copy-on-write technology). Each half of the clone will get a new key to accept writes so that new data is written with a new key. When per-extent keys are involved, a file may be compromised of several keys, but will be guided by the same class key.

The decryption of a file can be seen below, but we will also explain it as its very important. Read on:

1. File is opened
2. Metadata is decrypted with the file system key, showing the wrapped per-file key and information on what class it is assigned to.
3. The Per-file or per-extent key is unwrapped with the class key and sent to the hardware AES engine.
4. The hardware AES engine decrypts the file and reads it from flash memory
5. All wrapped file key handling happens in the Secure Enclave thus never exposing the operations outside of the Secure Enclave.
6. After completed, it uses the ephemeral key to re-wrap the keys to send them to the application processor.

Its important to remember that all metadata is encrypted with a random key created during OS install or after a device wipe. Like most things APFS, makes it even more secure by wrapping the file system metadata key with the Secure Enclave UID key for long-term storage. The Secure Enclave handles this in an interesting way by creating an ephemeral per-boot version of the key to protect it from the application processor. When stored, the encrypted file system key is additionally wrapped by an effaceable key stored in Effaceable Storage. This key by design is managed to be erased easily either by a MDM wipe command or a user wiping the device. In this situation, all files will be cryptographically irretrievable. The hierarchy that has been mentioned provides pliability and good performance. One example you will find in Apple’s security docs is when you change a file’s class would only require rewrapping the per-file key or changing a passcode will require changing the class key.

How Passcodes Impact Data Protection

Most people know that if a device has its passcode enabled then it enables data protection. The biggest thing to know is that without the passcode certain data classes are near impenetrable. They also entangle the device UID in the passcode requiring you to input it on the device to attempt to break through. They also use an iteration count to deter attackers by making a single attempt take up to 90ms along with a growing scale based on the number of attempts. A 6 character passcode for example could take up to 5 years to penetrate. Secure Enclave devices will use the Secure Enclave coprocessor to enforce delays and works similarly to a BIOS by remembering the password attempt status on reboot.

Data Protection Classes

We have been hinting at classes for awhile. It’s time you understand them. The key to remember is it is up to the application to decide what class a file has. They are as follows

Complete Protection: The key is created with a combination of the passcode and UID. Shortly after being locked, the keys are discarded thus rendering data inaccessible until the device is unlocked.

Protected Unless Open:  The use case for this class is when you need to write when locked, such as downloading something while locked. This class uses asymmetric elliptic curve cryptography to achieve the desired result. The per-file key is protected by One-Pass Diffie-Hellman Key Agreement The ephemeral public key is stored along with the per-file key with these characteristics:

• Concatenation Key Derivation Function
• Omitted AlgorithmID
• PartyUInfo and PartyVInfo are the ephemeral and static public keys
• SHA-256 hashing
• Per-file key is wiped on file closure

The shared secret is re-created with the Protected Unless Open class private key and the file’s ephemeral public key when the file wants to be re-opened, which are then used to restart the process again.

Protected Until First User Authentication: This class is the same as the complete protection class with the one exception that the decrypted class key remains. This is similar to desktop full-volume encryption. The goal of this class is to protect from attacking involving reboots. This is considered to be the standard 3rd party data class unless otherwise specified.

No Protection: This class key is protected by the UID and lives in effaceable storage. All of the keys are stored on the device, which mostly only facilitates fast remote wipes.

Keychain Data Protection

The iOS keychain is a vital aspect of how iOS functions seamlessly. The keychain manages passwords, login keys, and much more. At its core, the keychain is a SQLite database stored on the file system. A daemon in iOS called securityd determines what can access the keychain at a process or application level. The keychain access APIs talk to the daemon to determine  the keychainaccess-groups, application-identifier, and application-group entitlements for applications. Access groups let keychain items be shared across apps. That is limited to the developer, such as your MDM can share the keychain across all of their apps. Today, Apple requires 3rd party apps to use access groups with a prefix allocated via app groups.

Keychain Data Protection closely mimics how regular data protection works as seen below.

An important class to focus on is kSecAttrAccessibleAfterFirstUnlock which is used frequently for apps that need to perform background updates. The class kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly works the same as kSecAttrAccessibleWhenUnlocked with the exception that it only exists when the device is locked with a passcode. Its only part of the system keybag and cannot sync to the iCloud keychain, in backups, or in escrow keybags.  Passcode changes make the keybag uselesss like when you do a device wipe.

The device only classes are very appealing as they can be backed up but only are accessible by the time they were created on. Apple did a nice job of organizing keys in a way that makes the OS less cumbersome and more secure by making choices that are practical. As an example, certificates are usable when the device is locked but can’t be exfiltrated to other devices.

Apple also leverages ACLs to ensure that certain items can only be accessed under certain conditions. As an example, you need TouchID to access saved passwords in Safari. A seldom used feature is one that can render some keys useless if a new fingerprint is added to the device as a way of thwarting attackers. Like most things that matter, the ACLs are evaluated inside of the Secure Enclave.

In Closing

I know most people won’t care about a lot of this stuff. I personally feel that any mobility engineer must understand how the basics of iOS security work to be effective. If you understand how Data-at-Rest Encryption, the keychain, and several other tenets of iOS security work then they can be great stewards of their organizations. Most times people in mobility get a bad rap because they have a few gaps in their knowledge because lets face it mobility training sucks. I believe that grasping the concepts and understanding how to secure devices will empower you to be champions of your respective companies.