Apple Launches $200,000 Bug Bounty, Details iOS 10 Enclave Defenses
Black Hat
Hardware-enforced key isolation and the physical destruction of cloud signing smart cards ensure user secrets remain technically inaccessible to host operating systems and Apple itself.
AI-assisted summary of Behind the Scenes of iOS Security — original source. Check the original for full context.
Source published:
Key ideas
- iOS 10 implements execute-only memory (XOM) and dual virtual mappings for WebKit JIT pages, preventing attackers with write-anywhere primitives from directly reading back or executing injected shellcode. (1:04)
- The Secure Enclave Processor (SEP) isolates Data Protection key derivation using a hardware-bound UID key, enforcing rate limiting and an absolute 10-attempt lockout counter entirely outside the Application Processor's reach. (6:57)
- iCloud Keychain Backup protects escrow records across HSM clubs using a distributed quorum protocol, terminating firmware updates by physically destroying administrative signing smart cards in a blender. (32:28)
- Apple launched its first official Security Bounty program with top payouts reaching $200,000 for secure boot firmware vulnerabilities and $100,000 for Secure Enclave extraction, alongside a 1:1 charity donation match. (36:00)
Detailed notes
## Background Published on YouTube by Black Hat on August 16, 2016, this presentation features Apple Head of Security Architecture and Architecture Ivan Krstić delivering a deep-dive technical briefing. According to the page description, the talk covers three core iOS security systems: hardened JIT memory mapping new to iOS 10, Data Protection key derivation using the Secure Enclave Processor, and the cryptographic synchronization fabric backing iCloud Keychain, HomeKit, and Auto Unlock.
## TL;DR Ivan Krstić details the low-level cryptographic engineering that secures modern iOS devices and cross-device secret synchronization. He explains how iOS 10 eliminates writable-and-executable JIT memory mappings using execute-only memory (XOM), how the Secure Enclave Processor isolates master key derivation and brute-force rate-limiting away from the untrusted Application Processor, and how Cloud Key Vault HSM clusters use quorum consensus to safeguard escrowed credentials without Apple holding the decryption keys. Krstić also describes the physical destruction ceremony of the HSM firmware signing smart cards and concludes by officially announcing the launch of the Apple Security Bounty program.
## Atmosphere & style The presentation carries the measured, authoritative, and intensely rigorous tone of a high-stakes engineering masterclass. Krstić speaks with calm confidence and minimal theatricality, letting intricate silicon designs, low-level assembly workflows, and cryptographic primitives command the room's attention. The atmosphere balances executive poise with subtle, dry humor—most notably when showcasing the mechanical destruction of firmware signing cards in a commercial blender labeled the 'Crypto Blender'—and turns strictly guarded during the audience Q&A, where Krstić firmly deflects political controversies to keep the focus locked on verifiable implementation details.
## Bulletin - [01:04](https://www.youtube.com/watch?v=BLGFriOKz6U&t=64s) iOS 10 implements execute-only memory (XOM) and dual virtual mappings for WebKit JIT pages, preventing attackers with write-anywhere primitives from directly reading back or executing injected shellcode. - [06:57](https://www.youtube.com/watch?v=BLGFriOKz6U&t=417s) The Secure Enclave Processor (SEP) isolates Data Protection key derivation using a hardware-bound UID key, enforcing rate limiting and an absolute 10-attempt lockout counter entirely outside the Application Processor's reach. - [32:28](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1948s) iCloud Keychain Backup protects escrow records across HSM clubs using a distributed quorum protocol, terminating firmware updates by physically destroying administrative signing smart cards in a blender. - [36:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2160s) Apple launched its first official Security Bounty program with top payouts reaching $200,000 for secure boot firmware vulnerabilities and $100,000 for Secure Enclave extraction, alongside a 1:1 charity donation match.
## Key takeaways - [00:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=0s) Apple deliberately removed encryption from iOS 10 kernelcaches during performance profiling after concluding it provided no meaningful security boundary. - [02:36](https://www.youtube.com/watch?v=BLGFriOKz6U&t=156s) WebKit JIT in iOS 10 splits the 32 MB buffer into separate readable/executable and readable/writable virtual mappings, hiding the writable address inside an execute-only memcpy routine. - [06:57](https://www.youtube.com/watch?v=BLGFriOKz6U&t=417s) Data Protection treats the Application Processor as potentially compromised, keeping raw master keys and derivation logic isolated inside the Secure Enclave Processor. - [08:58](https://www.youtube.com/watch?v=BLGFriOKz6U&t=538s) The hardware UID key is created at first boot by the SEP's hardware TRNG and cannot be extracted by any mutable software layer. - [10:47](https://www.youtube.com/watch?v=BLGFriOKz6U&t=647s) Key derivation iteration counts in the SEP are dynamically tuned to achieve a target delay of 100 to 150 milliseconds to systematically slow brute-force attacks. - [12:12](https://www.youtube.com/watch?v=BLGFriOKz6U&t=732s) File payloads are encrypted via AES-XTS, and file keys passed to the kernel are ephemerally rewrapped so they become entirely useless upon reboot. - [10:47](https://www.youtube.com/watch?v=BLGFriOKz6U&t=647s) Data Protection Class B relies on Curve25519 asymmetric cryptography, allowing incoming files to be encrypted while the device is locked without exposing the private decryption key. - [19:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1140s) Overnight iOS updates utilize One-Time Unlock Tokens minted by the SEP with an 8-hour expiration to finish post-boot database migrations before the user wakes. - [21:34](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1294s) Demoting a production device for hardware debugging permanently exposes an alternate UID key, destroying access to any previously stored user Data Protection keys. - [27:20](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1640s) The Cloud Key Vault escrow architecture relies on zero-knowledge Secure Remote Password (SRP) authentication directly terminated on physical HSMs. - [29:58](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1798s) To prevent partition and offline brute-force attacks, Cloud Key Vault HSMs form five-member clubs requiring quorum consensus before updating failure counters. - [32:28](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1948s) Physical destruction of the Custom Security Code smart cards renders production Cloud Key Vault HSM firmware permanently immutable, eliminating coercion vectors. - [43:11](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2591s) Because existing escrow records cannot be migrated between Cloud Key Vault fleets, software patches require standing up separate new fleets solely for future enrollments. - [36:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2160s) Apple's initial Security Bounty program begins by invitation with rewards tiered up to $200,000 for verified Secure Boot exploits.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=0s) Introduction and Decrypted Kernelcaches
Ivan Krstić introduces himself as the head of security engineering and architecture at Apple, welcoming the audience to a deep dive into three major iOS security mechanisms—including a brand-new feature debuting in iOS 10. Before jumping into the main agenda, he addresses the widespread speculation surrounding a recent change in the iOS 10 betas: unencrypted kernelcaches. Following laughs from the crowd, Krstić explains that in iOS 10 betas, Apple intentionally shipped unencrypted kernelcaches, and in subsequent betas extended this practice to unencrypted iBoot and boot logos for pre–iPhone 5s devices.
Addressing rumors head-on, he clarifies that this change was deliberate. While conducting general performance optimizations, Apple reviewed the efficacy of specific security controls and concluded that removing this layer of encryption had zero impact on platform security or the protection of user data. As Krstić succinctly frames it: “yes this is on purpose um we from time to time revisit the efficacy of some of our security mechanisms and in this case while doing some other optimizations we took a look and realized that we could simply remove this encryption and uh not in any way impact platform security”.
- The iOS 10 developer betas stopped encrypting kernelcaches, and later betas left iBoot and boot logos unencrypted on pre–iPhone 5s devices. - Apple confirmed the unencrypted kernelcache was a deliberate optimization decision, with no negative bearing on platform security or user data encryption.
---
[01:04](https://www.youtube.com/watch?v=BLGFriOKz6U&t=64s) Hardened WebKit JIT Mapping in iOS 10
Krstić shifts focus to the first major technical topic: hardened WebKit Just-In-Time (JIT) memory mapping in iOS 10. To maintain competitive web performance in Safari, JavaScript execution relies heavily on JIT compilation to produce machine code on the fly. However, iOS strictly enforces mandatory code signing across all executable pages. To accommodate JIT compilation, Apple historically had to relax this rule and grant the Safari JIT engine the ability to emit unsigned native code directly into memory.
In iOS 9 and earlier, this compromise was implemented through a dedicated 32-megabyte memory region mapped as readable, writable, and executable (`RWX`). This configuration presented a serious security hazard: if an attacker discovered a "write-anywhere" primitive via a browser-level JavaScript bug, they could trivially achieve arbitrary code execution by copying shellcode directly into the `RWX` JIT region and redirecting execution to it.
To eliminate this vulnerability vector, iOS 10 leverages execute-only memory (`XOM`). Krstić notes that while ARM processors historically made memory readability implicit whenever execution permissions were granted, the ARMv8 architecture introduced formal support for execute-only pages. Apple integrated the software implementation of execute-only memory directly into the iOS 10 kernel, allowing the operating system to map pages that code can execute, but which the running process cannot inspect or read.
```mermaid flowchart TD accTitle: Evolution of iOS WebKit JIT Mappings accDescr: Visual comparison between iOS 9 RWX JIT memory mapping and iOS 10 dual-mapping using execute-only memory.
subgraph iOS9["iOS 9 Implementation"] Phys9["Physical Memory (32 MB)"] RWX["Single Virtual Mapping: Readable, Writable, Executable (RWX)"] Phys9 --> RWX end
subgraph iOS10["iOS 10 Hardened Architecture"] Phys10["Physical Memory (32 MB)"] ExecMap["Virtual Mapping: Executable (RX)"] WriteMap["Virtual Mapping: Writable (RW)\n(Secret Randomized Address)"] XOM["Execute-Only Page (X)\nSpecialized memcpy\n[Embeds Writable Address]"]
Phys10 --> ExecMap Phys10 --> WriteMap XOM -.->|"Writes JIT code via secret address"| WriteMap end ```
- In iOS 9, Safari maintained a single 32 MB JIT memory region marked `RWX`, allowing an attacker with a memory write primitive to drop shellcode and jump straight to it. - ARMv8 introduced hardware-level support for execute-only memory, which Apple implemented within the iOS 10 kernel to prevent a process from reading its own executing bytes.
---
[02:36](https://www.youtube.com/watch?v=BLGFriOKz6U&t=156s) Dual Virtual Mappings and Execute-Only memcpy
With execute-only memory supported by the kernel, iOS 10 redesigns the WebKit JIT compilation engine by splitting the single physical 32 MB JIT memory buffer into two distinct virtual mappings. One virtual mapping is strictly readable and executable (`RX`), while the second virtual mapping is readable and writable (`RW`). To prevent malicious use, the writable mapping is placed at a secret, randomized virtual address.
To safely write newly compiled code into this hidden memory space without exposing its location to the rest of the application, WebKit generates a specialized `memcpy` routine. The randomized base address of the writable mapping is baked directly into this custom `memcpy` as immediate assembly values. Once generated, Apple marks this `memcpy` function's memory page as execute-only and actively scrubs (zeroes out) the address of the writable region from all other process memory. When WebKit needs to write generated code, it calls this specialized `memcpy`, which uses its internally hardcoded secret address to copy the instructions into the writable alias, making the code appear instantly in the executable alias.
Krstić illustrates this mechanism live on stage by comparing an iPhone running iOS 9.3 against an iPhone running iOS 10: - **iOS 9.3 Demo**: Attaching to the Safari `com.apple.WebKit.WebContent` process reveals guard pages surrounding a unified 32 MB `RWX` JIT region. - **iOS 10 Demo**: Inspection shows the split structure with distinct executable and writable mappings, alongside an execute-only page. Attaching a debugger to inspect the disassembly of the execute-only region reveals immediate values representing the secret address (e.g., `0x1708ac000`), followed by basic memory copy instructions. - **Permission Verification**: Krstić demonstrates that attempting to read bytes from the normal readable/executable mapping succeeds with an error code of zero. However, attempting to read memory bytes directly from the execute-only `memcpy` mapping instantly crashes the debugger with a `bad access` exception, confirming the page is entirely unreadable.
Krstić emphasizes the security impact of this hardening measure: “where this gets us is that an attacker who simply has a right anywhere primitive from the context of uh JavaScript can no longer use it uh by itself for arbitrary code execution in the process instead they have to subvert control flow usually through r or a similar mechanism”.
- Physical JIT memory is aliased to two virtual addresses: one executable mapping and one writable mapping placed at a randomized address. - A tailored `memcpy` routine encodes the secret writable destination address as immediate values and is placed in execute-only memory. - The writable mapping address is zeroed out across the remainder of the address space, denying attackers read access even if they gain arbitrary memory read primitives. - An arbitrary write primitive within WebKit is no longer sufficient on its own to achieve arbitrary native code execution; adversaries are forced into complex control-flow hijacking techniques like Return-Oriented Programming (ROP).
---
[06:57](https://www.youtube.com/watch?v=BLGFriOKz6U&t=417s) Data Protection and the Secure Enclave Processor
Krstić introduces the next foundational topic: iOS Data Protection, the cryptographic system responsible for securing all user data at rest. When architecting Data Protection, Apple established strict security requirements: strong cryptographic keys, hardware-bound protection to rule out offline dictionary attacks, strict hardware rate-limiting to block brute-force passcode guesses, and support for modern alternative authentication vectors like Touch ID and macOS Sierra's Auto Unlock via Apple Watch.
Crucially, the architecture had to assume the host processor could be completely compromised. As Krstić notes: “we also had one more goal which is to entirely sidestep the attack surface for the AP this is the application processor this is the normal uh CPU the trun all uh uh all the rest of the code in the operating system”. To achieve this separation, authentication policies and attempt limits must remain strictly enforceable even when facing a completely adversarial Application Processor (AP). Under this model, long-term master keys are never exposed to the AP; any session-specific keying material released to the AP is strictly ephemeral, bound to the current session, and rendered useless across reboots.
To fulfill these constraints, Apple introduced the Secure Enclave Processor (SEP), beginning with the iPhone 5s. The SEP is an isolated, dedicated silicon co-processor running its own compact Trusted Computing Base (TCB) with dedicated hardware-accelerated cryptographic engines. It features isolated encrypted memory, communicates with the general AP exclusively through a narrow mailbox interface, and relies on factory-paired cryptographic channels to communicate securely with both the Touch ID fingerprint sensor and the Apple Pay Secure Element.
- Data Protection safeguards resting user data against offline decryption and automated online brute-forcing. - The threat model treats the Application Processor (AP) running iOS as untrusted and potentially adversarial. - The Secure Enclave Processor (SEP) operates as an independent cryptographic coprocessor with isolated TCB, encrypted RAM, and dedicated cryptographic hardware. - Factory pairing establishes authenticated, encrypted communication channels between the SEP, the Touch ID sensor, and the Apple Pay Secure Element.
---
[08:58](https://www.youtube.com/watch?v=BLGFriOKz6U&t=538s) UID Keys, Keybags, and Brute-Force Rate Limiting
The internal cryptographic foundation of the SEP begins during manufacturing. The SEP contains an on-chip True Random Number Generator (TRNG) powered by free-running oscillators. The very first time silicon receives power at the factory, the TRNG generates the device Unique ID (UID) key. The UID is a private key that never leaves the hardware boundaries of the Enclave; it cannot be exported, and it can only be utilized by dedicated cryptographic operations burned immutably into secure hardware logic. No mutable software or firmware update can ever expose or alter this root secret.
All higher-level keys protecting user files are organized into "user keybags"—sets of cryptographic keys assigned to each user profile on the device. Every user keybag is encrypted and wrapped by a master key derived using a combination of the user's secret passcode and the hardware UID key inside the SEP.
Because the hardware UID is accessible only via operations executed internally by the SEP, the Enclave maintains absolute authority over passcode evaluation. After ten consecutive incorrect passcode attempts, the SEP locks down and permanently refuses to process any additional key derivation operations against the UID key. Krstić transitions into how keys within a keybag are differentiated into distinct classes (Classes A through D), where certain class keys remain accessible while the device operates in the background, while others are strictly restricted until the device is explicitly unlocked by the user for the first time.
- The hardware UID key is generated internally on first boot via the SEP's hardware TRNG (free-running oscillators) and remains strictly non-exportable. - The UID is only accessible via hardwired silicon cryptographic operations, preventing mutable software from reading it. - Keybags contain user keys wrapped by a master key derived jointly from the user's passcode and the hardware UID. - The SEP enforces a hard limit of 10 failed passcode attempts before permanently disabling further derivation requests. - Data Protection categorizes file keys into Classes A through D, controlling key availability based on lock state and initial post-boot authentication.
[10:47](https://www.youtube.com/watch?v=BLGFriOKz6U&t=647s) Data Protection Classes and Key derivation
Ivan Krstic breaks down the cryptographic specifics of the iOS Data Protection classes, noting that while Class C and Class D are standard, “Class A is stronger; these are only available while the user is actively using the unlocked device.” Classes A, C, and D rely on 256-bit AES keys. Class B takes a radically different architectural approach: rather than a symmetric key, it uses a Curve25519 asymmetric key pair. This public-key setup allows the public key to remain perpetually accessible on the device, while the corresponding private key is strictly wiped and inaccessible whenever the device is locked.
```mermaid flowchart LR accTitle: Class B Cryptographic Asymmetric Operation accDescr: Class B data protection allows writing files while locked using an asymmetric Curve25519 keypair. subgraph ClassB["Curve25519 Class B Keypair"] Pub["Public Key<br/>(Always Available)"] Priv["Private Key<br/>(Unlocked State Only)"] end Pub -->|"Encrypt / Write while locked"| Store["Encrypted Storage (Dropbox mode)"] Store -.->|"Decrypt / Read only when unlocked"| Priv ```
Displaying an annotated keybag taken straight from the file system, Krstic explains the components present on every iOS unit: a version header, the salt, and the iteration count used for the key derivation function (KDF), accompanied by the key identifiers for the wrapped keys and the raw bytes of the Class B public key. Deriving the master key is a deliberate split between software and hardware: userland takes the user passcode and salt, runs it through an initial KDF phase, and hands the output over to the Secure Enclave Processor (SEP). The SEP continues iterating using its hard-wired hardware UID key. Krstic emphasizes that the number of iterations is tuned dynamically to enforce a strict latency target:
> “And the number of iterations is chosen to meet a time goal which is between 100 and 150 milliseconds, so we want it to be the case that derivation takes a certain amount of time.”
- **Class A, C, and D Keys**: 256-bit AES symmetric keys. - **Class B Keypair**: Curve25519 asymmetric key pair; public key stays open, while the private key is held strictly during active unlocked sessions. - **Hardware-bound Iteration**: The SEP hardware UID engine enforces a calculation delay between 100 ms and 150 ms to defeat offline brute-force attacks.
---
[12:12](https://www.youtube.com/watch?v=BLGFriOKz6U&t=732s) File Encryption and Ephemeral Boot Keys
Turning to file-level security, Krstic details how individual file payloads are encrypted using AES-XTS with 128-bit keys. Crucially, every individual file receives its own distinct, cryptographically random key minted directly inside the SEP. These raw keys never surface in cleartext on the Application Processor (AP). Instead, the long-term wrapped file keys live within file metadata, wrapped by the user keybag keys that only the SEP can parse.
```mermaid flowchart TD accTitle: Ephemeral File Key Wrapping Flow accDescr: Step-by-step lifecycle showing how file keys are wrapped with ephemeral boot keys before reaching the kernel and storage controller. subgraph Boot["Boot Initialization"] SEP_Boot["SEP AES Engine"] -->|"Secure Outbound Channel"| NC["NAND Storage Controller"] SEP_Boot -.->|"Stores Ephemeral Key"| NC end
subgraph Access["File Access Pipeline"] Kernel["Kernel"] -->|"1. Fetch wrapped file key"| SEP["SEP (SKS)"] SEP -->|"2. Unwrap via Keybag Key & Rewrap via Ephemeral Key"| SEP SEP -->|"3. Ephemerally wrapped key"| Kernel Kernel -->|"4. Send wrapped key"| NC NC -->|"5. Unwrap via Ephemeral Key & Decrypt data"| Nand["NAND Flash"] NC -->|"6. Cleartext data"| Kernel end ```
When an active device requests a file, the kernel pulls the wrapped key from the file system metadata and submits it to the SEP. The SEP unwraps the key using the user keybag key, but it does not return the plaintext key to the operating system. Instead, it rewraps the key using an ephemeral AES key created by the SEP at boot and pushed over a dedicated outbound hardware channel to the NAND storage controller. The kernel receives only an ephemerally wrapped key, passes it along to the storage controller, and the controller decrypts the key on-chip to read the ciphertext off flash and return cleartext back into kernel space. Krstic points out the profound architectural benefit:
> “What's important about this is that if you look at the keys that are exposed to the kernel, none of them have any long-term value; after the device is rebooted, that ephemerally wrapped key simply serves no purpose.”
- **Per-file Encryption**: AES-XTS-128 using SEP-generated random keys. - **Boot Session Binding**: The storage controller receives an ephemeral master key via an isolated secure channel at early boot. - **Zero Kernel Exposure**: Even an attacker with complete kernel code execution inspects only ephemerally wrapped keys useless across reboots.
---
[14:03](https://www.youtube.com/watch?v=BLGFriOKz6U&t=843s) Device Boot Sequence and Effaceable Storage
Achieving Apple’s data protection goals demands intricate hardware and daemon handoffs from the moment power is applied. When the kernel boots from the read-only system partition, the AppleKeyStore driver retrieves the Class D key out of *effaceable storage*—a dedicated area of NAND flash silicon configured to forbid wear leveling or block relocation, ensuring data placed in those sectors can be securely zeroed out on demand. The encrypted Class D key is piped into the SEP, decrypted via the hardware UID key, and registered into the Secure Key Store (SKS) application running within the Secure Enclave.
```mermaid flowchart TD accTitle: Boot Sequence and Early Keystore Unwrapping accDescr: Early boot transitions from effaceable storage loading to launchd and keybagd initialization. subgraph Effaceable["Effaceable Storage (No Wear-Leveling)"] DKey["Class D Key (Encrypted)"] MediaKey["Media Key"] ProtKey["Protection Key"] end
DKey -->|"Load into SEP"| SKS["SEP SKS Keyring"] MediaKey -->|"Decrypt metadata"| FS["File System Metadata"] ProtKey -->|"Decrypt System Keybag"| KeybagD["keybagd Daemon"]
FS --> Launchd["launchd"] Launchd --> KeybagD SKS -->|"Unwrap Class D"| KeybagD KeybagD -->|"Load Class B Public Key"| SKS ```
The kernel then decrypts overall file system metadata using an effaceable-storage Media Key, allowing `launchd` to launch, mount the user partition, and fire up `keybagd`. Because the Class D key is now unlocked in the SKS keyring, `keybagd` can read the system keybag file off the disk, decrypt it using a third effaceable value called the Protection Key, and hand it to SKS to register the Curve25519 Class B public key.
At this stage, the user has entered zero credentials. Classes A and C, along with the Class B private key, remain completely undecryptable. However, this state gives iOS a functional “Dropbox mechanism”: the device can boot up background services, read Class D operational files, and receive incoming content—such as incoming email attachments or messages—by writing files protected under the Class B public key, guaranteed unreadable until the owner arrives to unlock the screen.
---
[16:27](https://www.youtube.com/watch?v=BLGFriOKz6U&t=987s) First Unlock, Lock State, and Biometric Integration
When a user interacts with the lock screen after a cold boot, SpringBoard captures the passcode and transmits it to the SEP. Combining this passcode with the burned-in hardware UID key, the SEP reconstructs the raw master key, instantly unwrapping the remaining Class A, Class B (private), and Class C keys into the SKS keyring.
```mermaid flowchart TD accTitle: Touch ID Biometric Keyring Reconstitution accDescr: Shows the relationship between SKS, s_bio, and the random secret during device lock and biometric unlock. subgraph FirstUnlock["First Unlock Flow"] Master["Master Key"] -->|"Encrypt with Random Secret"| EncMaster["Encrypted Master Key"] Secret["Random Secret"] -->|"Sent to isolated app"| SBio["s_bio App (Biometric)"] EncMaster -->|"Stored in memory"| SKS["SKS (Raw Master Key Wiped)"] end
subgraph SensorMatch["Touch ID Fingerprint Match"] Finger["Home Button Sensor Image"] --> SBio SBio -->|"Valid Match: Return Secret"| SKS SKS -->|"Decrypt Master Key"| Ring["Reconstitute Class A & B Private Keys"] end ```
To support Touch ID without keeping the sensitive master key exposed in raw SEP memory, the SEP creates a single-use random secret, encrypts the master key with it, and hands *only* the secret to `s_bio` (the isolated biometric matching daemon within the Secure Enclave). The raw master key is immediately wiped:
> “After this, SKS will securely destroy the master key, the raw master key from its memory, holding on only to the encrypted version with the secret that it's sent to `s_bio`.”
When the device locks, the SKS simply purges the Class A and Class B private keys from its keyring. The Class C key remains loaded (as it is accessible after first unlock), alongside Class D and the Class B public key. When a finger depresses the home button sensor, the sensor streams the fingerprint raster directly to `s_bio`. If `s_bio` validates the biometric print, it releases the random secret back to SKS, which temporarily unseals the master key, re-derives the Class A and Class B private keys, restores them to the active keyring, and immediately destroys the cleartext master key once more.
---
[19:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1140s) One-Time Unlock Tokens and the Demotion Mechanism
Krstic introduces an advanced lifecycle feature introduced to make background updates painless: “Update Later” (install overnight). Historically, applying an update required a full reboot that stripped all encryption keys, leaving the device sitting uselessly at a cold-boot lock screen until the user awoke to type their passcode. With "Update Later," iOS prompts for the user's passcode upfront to authorize an OTUT (One-Time Unlock Token) inside the SEP.
Using the predictive machine-learning heuristics built into Apple's proactive assistant engine, the system determines the user's downtime habits:
```mermaid flowchart TD accTitle: Update Later Token Lifecycle accDescr: The generation, persistence, and execution flow of the One-Time Unlock Token across overnight software updates. Passcode["Passcode Entry + Install Later"] -->|"Authorize"| SEP_OTUT["SEP Authorizes OTUT"] Proactive["Proactive Engine Prediction"] -->|"Detect Final Bedtime Unlock"| Mint["SEP Generates OTUT"] Mint -->|"Persist + Start 8-Hour Expiration"| SUSub["Software Update Subsystem"] SUSub -->|"3:00 AM Execution"| Reboot["Run Update & Reboot System"] Reboot -->|"Consume OTUT"| Keyring["Unwrap User Data / Run Migrations"] Keyring --> Ready["Device Fully Unlocked & Updated for Morning"] ```
When the proactive assistant identifies what is likely the user’s final unlock before sleep, the SEP mints the actual OTUT. The software update subsystem takes custody of the persisted token and sets an uncompromising 8-hour hardware-enforced expiration timer. Around 3:00 AM, the OS executes the update, reboots the hardware, and supplies the OTUT to the SEP to restore access to the protected user keybag. The system can immediately run essential post-boot database migrations, presenting the owner with a fully refreshed, ready-to-use phone the following morning.
Krstic transitions to maintenance mechanisms, introducing the "demotion" process. Because Apple supports over one billion active consumer devices, engineers require concrete, robust debugging abilities to diagnose edge-case failures on production silicon without undermining or dismantling the Data Protection security perimeter.
- **OTUT (One-Time Unlock Token)**: Ephemeral authorization allowing an automated reboot to decrypt userland for post-update migrations. - **8-Hour Expiry**: The token self-destructs if software update cycles fail to complete within the 8-hour operating window. - **Proactive Scheduling**: Tokens are minted dynamically on the predicted final pre-bedtime unlock rather than sitting idle for extended periods.
[21:34](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1294s) Secure Enclave Processor Demotion and Data Protection Wrap-up
Ivan Krstic explains how Apple handles debugging on production hardware through a mechanism known as "demotion." The demotion feature allows a production device to enable lower-level debugging functionality—such as JTAG and the capability to load development software—specifically on the Application Processor (AP), while strictly excluding the Secure Enclave Processor (SEP). To trigger this mode, the device must first be authorized by an Apple personalization server, which mandates that the target unit be completely wiped and re-imaged with a fresh operating system.
Crucially, this transition enforces a hardware-level shift in the device's cryptographic identity. When demotion occurs, the hardware automatically exposes a completely different Unique ID (UID) key to the SEP. As a direct consequence, the original UID that was used to derive the device's master Data Protection key disappears entirely from mutable software reach. “In other words, if a production device is demoted, the UID key that was used in deriving the master key that protects any user data previously on that device is simply unavailable to any software—a different UID key turns up,” Krstic points out. This architectural barrier ensures that physical access combined with factory-style debugging privileges cannot retroactively reconstruct or decrypt existing user data, satisfying all of Apple's baseline Data Protection security requirements.
[22:40](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1360s) The Challenges and Design Goals of Synchronizing Secrets
Moving beyond single-device Data Protection, Krstic pivots to the problem of moving secrets across multiple devices within a user's ecosystem. Modern operating system features heavily rely on seamless cryptographic sharing: - **Safari Autofill**: Synchronizing stored web passwords and credit card credentials across phones, tablets, and Macs. - **Auto Unlock**: Securely provisioning and passing ephemeral keys between an Apple Watch and a paired Mac to unlock the computer without a password. - **HomeKit**: Replicating authorization keys to every approved device so that a homeowner can manage smart devices like door locks from whichever screen is at hand.
Krstic analyzes the two historical approaches to distributed secret storage and explains why both fail consumers. The first standard approach relies on generating an ultra-strong, random key to encrypt everything in transit. While cryptographically sound, this yields an unworkable user experience because individuals are forced to transcribe, print, or store recovery phrases in obscure locations. The second approach derives transit keys directly from a user's master account password. However, this model breaks down because users notoriously pick weak passwords, immediately putting the cloud provider's backend into a privileged position where it can brute-force the credential and seize the underlying payload. Displaying an excerpt from a cryptography text noting that humans are inherently poor at generating high-entropy keys, Krstic outlines Apple’s five strict design criteria for iCloud secret synchronization:
1. **Selective Availability**: Necessary secrets must be reachable on all designated user devices. 2. **Strong Cryptography**: Data must be shielded by robust cryptographic keys. 3. **Frictionless Recovery**: Users must be able to restore secrets after losing all hardware without having to write down emergency recovery keys and stash them in a sock drawer. 4. **Zero Knowledge**: Secrets must never be exposed to Apple at any stage. 5. **Brute-Force Immunity**: The recovery pipeline must prevent brute-force attacks against lower-entropy credentials even if an adversary gains full control of the cloud backend.
[24:57](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1497s) iCloud Keychain Circles and Cloud Escrow Architecture
To satisfy standard day-to-day synchronization, Apple developed the iCloud Keychain synchronization circle. Every device admitted into the circle generates a dedicated, high-entropy key pair locally. When a user introduces a new piece of hardware, the new device cannot unilaterally join; it must receive explicit cryptographic approval from an existing, already-enrolled device. The Apple Cloud backend serves purely as an untrusted message broker and storage relay. Because messages remain encrypted under keys generated exclusively on endpoints, Apple retains zero visibility into the synchronized payloads.
```mermaid flowchart TD accTitle: iCloud Keychain Circle and Cloud Key Vault Escrow accDescr: Diagram showing how a trusted device uses iCloud Keychain circles for peer sync and routes escrow backups through HSMs.
subgraph Circle ["Device-to-Device Circle"] DevA["Trusted Device A"] DevB["New Device B"] CloudMsg["Apple Cloud Relay\n(Untrusted Storage)"]
DevA -->|"Approves enrollment"| DevB DevA <-->|"E2E encrypted sync"| CloudMsg DevB <-->|"E2E encrypted sync"| CloudMsg end
subgraph Escrow ["iCloud Keychain Backup & Escrow"] UserSecret["Keychain Secrets"] EscrowKey["Random Escrow Key"] iSC["iCloud Security Code\n(Device Passcode)"] HSM["Cloud Key Vault\n(Fleet HSM Cluster)"]
UserSecret -->|"Encrypted with"| EscrowKey EscrowKey & iSC -->|"SRP verifier + record"| HSM end ```
The model becomes far more complex when a user loses all active devices and must recover their secrets from scratch. To resolve this, Apple introduced the iCloud Keychain Backup flow. This introduces an auxiliary credential dubbed the iCloud Security Code (iSC), which is most often configured as the local device passcode—a secret never disclosed to Apple. The system generates an ephemeral, high-entropy random key termed the "escrow key," encrypts the user's keychain contents with this escrow key, and then wraps the escrow key itself with a key derived from the iSC. The wrapped package and encrypted payload are subsequently uploaded to Apple's infrastructure.
While this covers standard data recovery, it introduces a dangerous vulnerability: because passcodes typically have limited entropy (such as a 6-digit numeric PIN with only one million possible combinations), an adversarial cloud backend could trivially brute-force the iSC to expose the underlying escrow key. To prevent this, Apple mandated that unwrapping the escrow key must take place exclusively inside specialized Hardware Security Modules (HSMs) capable of enforcing rate-limiting and authorization policies.
[27:20](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1640s) Cloud Key Vault Fleet and Secure Remote Password Verification
Apple's solution to secure cloud escrow is an internal architecture known as the "Cloud Key Vault." This system consists of an extensive fleet of paired units, where an individual host machine connects directly to a tamper-resistant HSM cryptographic co-processor. These HSMs run custom, cryptographically signed firmware that prevents keys from being exported in plaintext and exposes strictly constrained cryptographic APIs.
The entire Cloud Key Vault fleet operates its own isolated internal Certificate Authority (CA), whose root private key never leaves the physical hardware of the HSMs. Each iOS device in the field ships with the public certificate of this fleet CA hardcoded into the OS. To control execution, the HSM strictly validates two critical keys: 1. **Custom Secure Code Signing Key**: Authorizes and validates the deployment of verified software builds into the HSM. 2. **Service Key**: Grants the capability to process and unwrap incoming user escrow records.
Krstic breaks down the precise contents of a user's escrow record: - The user's strong, randomly generated **escrow key**. - A **Secure Remote Password (SRP) verifier** derived from their iCloud Security Code / device passcode. - A **maximum failure count** setting a ceiling on the total number of permitted incorrect passcode attempts.
The entire record is encrypted directly to the public Cloud Key Vault service key. Krstic observes: “Where does this get us? Well, we've effectively built a kind of Data Protection, but for escrow records.” When a user initiates recovery, their device contacts Apple Cloud, fetches the encrypted escrow record, and opens a cryptographic SRP session to the Cloud Key Vault. The HSM unpacks the record internally and initiates the zero-knowledge SRP handshake. If the user presents the correct iSC, the HSM yields the decrypted escrow key. If SRP authentication fails, a hardware-enforced monotonic counter increments; once the count matches the maximum failure limit, the record is flagged as permanently terminal, and the Cloud Key Vault refuses all future recovery attempts.
[29:58](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1798s) HSM Clubs and Quorum Consensus against Partitioning Attacks
```mermaid flowchart LR accTitle: HSM Club Quorum Commit Architecture accDescr: Flowchart illustrating how a club of five HSMs participates in a quorum consensus vote before recording failure attempts.
Proxy["Escrow Service Proxy"] --> Unit1["Originator HSM\n(Club Member 1)"]
subgraph Club ["HSM Club of 5 (Shared Service Key)"] Unit1 Unit2["HSM Member 2"] Unit3["HSM Member 3"] Unit4["HSM Member 4"] Unit5["HSM Member 5"] end
Unit1 -->|"Propose attempt / vote"| Unit2 Unit1 -->|"Propose attempt / vote"| Unit3 Unit1 -->|"Propose attempt / vote"| Unit4 Unit1 -->|"Propose attempt / vote"| Unit5
Unit2 & Unit3 & Unit4 -.->|"Majority Quorum Consensus"| Unit1 ```
Relying on a single HSM per user poses obvious reliability challenges, as hardware failures could permanently lock users out of their data. However, simply duplicating an escrow record across multiple separate HSMs creates an unacceptable security risk: backing up to five standalone units would multiply the brute-force attack budget by five, expanding a strict 10-guess ceiling into 50 attempts.
To resolve this trade-off between reliability and brute-force resistance, Apple groups the Cloud Key Vault fleet into clusters called "clubs" of five HSM units that share a single unified service key. An escrow record is certified against a specific club identified by the fleet CA. While clustering solves hardware redundancy, it introduces the threat of network partitioning attacks: an attacker with internal infrastructure access could physically isolate individual club members one by one, exhaust the full 10-attempt limit against each unit in isolation, and accumulate the combined failure threshold across the whole club.
Apple prevents this by enforcing a distributed quorum commit protocol directly across the HSM firmware: - Each individual club member maintains an independent, tamper-proof failure log for every escrow record. - Any incoming recovery transaction forces the HSMs to conduct a real-time distributed vote. - An attempt can only proceed if a strict majority quorum within the five-member club agrees to process the transaction and log the attempt state.
The physical architecture places an iCloud Escrow Service proxy at the front edge to receive client traffic, authenticated object storage at the back end, and the partitioned HSM clubs in between. Whenever an escrow transaction initiates, one HSM in the targeted club is chosen as the originator to formally propose the verification attempt to its peers.
- Production AP demotion forces an irreversible hardware switch to an alternate SEP UID, rendering previous Data Protection keys permanently unrecoverable. - iCloud Keychain sync relies on end-to-end device circles where incoming devices must be authorized by an already trusted device. - iCloud Security Codes map to the user's local device passcode, ensuring Apple never learns the underlying secret. - Cloud Key Vault HSMs leverage a fleet-wide Certificate Authority whose private keys are physically generated and locked inside the HSM silicon. - Escrow attempts utilize Secure Remote Password (SRP) verification to validate passcodes without leaking credentials in transit. - HSM clubs use groups of five hardware units bound by a majority quorum consensus to guarantee fault tolerance while eliminating network partitioning attacks.
[31:49](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1909s) Quorum Agreement and Failure Counter Updates in Cloud Key Vault
Ivan Krstic completes the technical walkthrough of the consensus protocol used across Hardware Security Modules (HSMs) in Cloud Key Vault. When an update to an escrow record's failure counter is initiated, the originating HSM queries the cluster: "Update, please give me your failure count for a specific escrow record." The peer units respond by transmitting their current counter values and casting affirmative votes, confirming they are not entangled in conflicting transactions. Once the originator verifies that a majority quorum has responded and that none of the nodes hold a record indicating a terminal failure count, it directs the peers to prepare to advance the counter—for instance, to five. Each participant validates the quorum, signals readiness, and executes the increment, with all club members ultimately confirming to the originator that their internal records reflect the newly committed counter value.
```mermaid flowchart TD accTitle: Cloud Key Vault Quorum Protocol accDescr: Step-by-step transaction flow between the originating HSM and peer members to update an escrow failure counter.
subgraph Phase1["Phase 1: Query & Voting"] A["Originating HSM"] -->|"Query counter & request vote"| B["Peer HSM Units"] B -->|"Return counter & vote YES"| A end
subgraph Phase2["Phase 2: Quorum Check & Prepare"] A -->|"Majority quorum verified: Prepare update"| B B -->|"Verify quorum & acknowledge ready"| A end
subgraph Phase3["Phase 3: Commit & Confirmation"] A -->|"Execute counter increment"| B B -->|"Confirm new failure counter value"| A end ```
[32:28](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1948s) The Smart Card Ceremony and Physical Destruction via the "Crypto Blender"
The firmware running on the HSMs underpinning Cloud Key Vault is governed by a Custom Security Code (CSC) signing key. Krstic outlines the physical administrative controls safeguarding this key: signing new firmware images requires a physical quorum of smart cards. When creating a new HSM fleet, Apple conducts an elaborate provisioning ceremony in which three administrative smart cards capable of unlocking the CSC signing key are sealed inside tamper-evident bags and distributed to three separate Apple organizations, which lock them inside three independent physical safes.
Addressing the obvious threat model—whether an adversary or rogue insider who gathered all three cards could sign malicious code to bypass security boundaries and brute-force user escrow records—Krstic delivers an emphatic negative. Before any Cloud Key Vault fleet enters production, representatives from all three organizations convene in a secure facility. They cross-check bag serial numbers against the original ceremony logs and record formal attestations swearing to their presence at creation, confirming no duplicate cards were struck, and certifying the tamper-evident seals remained unbroken throughout custody.
The cards are then combined not through a software operation, but using what Krstic jokingly introduces to audience laughter and applause as “a novel physical one-way hash function”—a commercial blender labeled the "Crypto Blender." Following this physical destruction, final formal attestations are recorded certifying that all administrative smart cards have been obliterated, that no unauthorized firmware images were signed while the cards existed, and that no residual administrative backdoors remain to modify the custom secure code loaded on the production fleet.
```mermaid flowchart LR accTitle: Administrative Smart Card Lifecycle accDescr: The lifecycle of admin smart cards from creation through attestation and destruction in the Crypto Blender. subgraph Provisioning["1. Provisioning"] A["Generate CSC Key"] --> B["Split to 3 Admin Cards"] B --> C["Seal in Evidence Bags"] C --> D["Store in 3 Separate Safes"] end subgraph Verification["2. Verification & Attestation"] D --> E["Inspect Serial Numbers & Seals"] E --> F["Record Formal Attestations"] end subgraph Destruction["3. Irrevocable Destruction"] F --> G["Crypto Blender"] G --> H["Cards Destroyed"] H --> I["Attest: No Cards Exist & Code Locked"] end ```
[35:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2100s) Unequivocal Trust and Cloud Boundary Guarantees
Krstic explains why Apple adopts such an extreme, unusual procedure for destroying the administrative smart cards. While on-device features like Data Protection and the Secure Enclave Processor rely on deep silicon engineering to protect user assets, data in transit to off-device cloud infrastructure demands a higher evidentiary standard. Krstic emphasizes that maintaining long-term customer trust requires absolute technical finality: “So here when we make a statement like your secrets are not exposed to Apple when they're being synchronized, we have to be able to make it unequivocally and if we still retain possession of these admin cards there's the possibility that that's not true.” By mechanically destroying the root provisioning material, Apple eliminates the capacity to compromise the Cloud Key Vault even under internal or external coercion.
- Apple views security when data leaves the device as having even higher stakes than on-device storage. - Retaining administrative signing cards leaves an ongoing risk that claims of zero access could be rendered false. - The irreversible destruction protocol is designed to provide an absolute guarantee that Apple cannot read synchronized secrets.
[36:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2160s) Announcing the Apple Security Bounty Program
Concluding his prepared remarks, Krstic announces the launch of the Apple Security Bounty program, which is met with immediate applause from the audience. Acknowledging the essential role played by external security researchers and Apple’s internal red team, Krstic observes that as core platform defenses have matured, finding high-impact exploits has become substantially more difficult. The bounty program is engineered to offer compensation matching the technical investment and creativity required to break modern iOS defenses, alongside public recognition for participating researchers.
The program includes four on-device vulnerability tiers and one cloud tier covering unauthorized access to iCloud account data hosted on Apple servers:
| Bounty Category | Target / Scope | Maximum Payout | |:--- |:--- |:--- | | Secure Boot Firmware Components | Extraction of confidential material from Secure Boot | Up to $200,000 | | Secure Enclave Processor (SEP) | Extraction of sensitive data from SEP execution environment | Up to $100,000 | | Kernel Code Execution | Execution of arbitrary kernel code with kernel privileges | Up to $50,000 | | Unauthorized iCloud Data Access | Access to unauthorized iCloud account data on Apple servers | Up to $50,000 | | Sandboxed Process Access | Process sandbox escape accessing sensitive user data | Up to $25,000 |
- Researchers who elect to donate their bounty payouts to an eligible charity receive an optional one-for-one match from Apple, doubling the total donation. - Listed payouts represent maximum award tiers; exact amounts depend on report clarity, a reproducible proof-of-concept, exploitation novelty, and the degree of user interaction required. - Exploits must function against the latest iOS release on the latest device hardware. - The bounty program launches in September 2016, beginning by invitation with a few dozen active researchers to refine triage workflows before expanding to wider submissions.
[39:40](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2380s) Audience Q&A: Government Access, Trust Revocation, and Hardware Architecture
Opening the floor to questions, Krstic responds to inquiries from attendees:
- **FBI Device Unlocking Inquiries:** A researcher asks whether recent high-profile conflicts with the FBI influenced the security architecture in iOS 10. Krstic declines to discuss political matters: “I'm an engineer; I'm happy to answer technical questions about what I've covered today.” - **Device Trust Revocation:** An attendee asks if users can inspect and revoke specific trusted devices that share an iCloud Keychain circle to guard against an unlocked phone being linked without consent. Krstic clarifies that keybags themselves are never synced. He notes that changing the primary iCloud account password invalidates the trust pairing fabric as documented in the public iOS Security Guide, but confirms that viewing an active synchronized device management list is not currently supported in that workflow. - **Timing of Architecture Disclosures:** When asked why Apple chose to disclose deep Data Protection details and launch the bounty program now, Krstic points out that foundational architectures have long appeared in the public iOS Security Guide. He explains that today's presentation was meant to offer an unprecedented level of low-level technical detail for the security community, while the bounty program arrives specifically because the difficulty of locating critical vulnerabilities has escalated to the point of warranting direct financial rewards. - **Apple Pay Secure Element Separation:** An attendee asks about the architectural history behind keeping the Apple Pay Secure Element as a separate physical hardware module rather than embedding it inside the Secure Enclave Processor. Krstic declines to expand into unannounced hardware design rationale, reiterating his focus on the technical mechanisms presented during the talk.
[43:11](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2591s) FIPS Certification and Cloud Key Vault Fleet Lifecycle
During the audience Q&A session, an attendee inquires whether Apple's cryptographic systems and methods are validated under FIPS 140-2. After locating the speaker in the room, Ivan Krstic points out that the precise status of Apple's FIPS validation is documented in the published iOS Security Guide, summarizing: “essentially some of it is validated and some is not.”
A follow-up question shifts back to the Cloud Key Vault hardware security modules, asking how software or firmware updates can be deployed once the code-signing key has been deliberately destroyed. Krstic clarifies that updating running hardware in place is fundamentally impossible by design: “there's not in fact that's the very purpose of destroying that uh that signing key”. When pressed on what happens if a zero-day or critical vulnerability is uncovered in production, Krstic explains the operational recovery protocol:
> “if a critical vulnerability were to be discovered in the Cloud Keychain Fleet we would have to stand up a new Fleet that has the patch software and then over time migrate new user enrollments to that Fleet”
Another audience member draws a comparison to Apple’s hardened posture against government access, asking what mitigations keep the chip from being forced to run modified software that might leak key material. Krstic gently clarifies the hardware terminology—noting the question concerns the Secure Enclave Processor (SEP) rather than the Secure Element (SE)—and states: “the software that runs on the SEP is covered by the same secure boot chain that validates all the rest of the software that's running on iOS devices.”
```mermaid flowchart TD accTitle: Cloud Key Vault Fleet Replacement Lifecycle accDescr: Flow showing how Apple handles vulnerabilities in the Cloud Key Vault fleet without updating existing hardware. subgraph FleetOps["Fleet Operations"] V["Vulnerability Identified in Fleet A"] --> N["Stand Up New Fleet B with Patched Firmware"] N --> U["Issue iOS Update with New Fleet B CA Certificate"] end subgraph Enrollment["Client Enrollment"] U --> M["New User Enrollments Directed to Fleet B"] E["Existing Escrow Records"] -->|"Locked permanently to"| O["Original Fleet A HSMs"] end ```
[45:09](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2709s) Apple Watch Auto Unlock and Escrow Migration Boundaries
The conversation turns to the physical security of Auto Unlock. An attendee asks how the rest of a user’s devices or accounts remain safe if their Apple Watch is lost or stolen. Krstic asks if the person wears one themselves; when they admit they do not, Krstic smiles and remarks, “if you did you would know that uh when you uh set up your Apple watch you actually have to pick a passcode for it”. He explains that while a paired iPhone can assist in unlocking the watch, the watch hardware contains sensors that immediately detect when it is removed from the wrist. The moment wrist contact is lost, the watch locks instantly, requiring either a nearby paired iPhone unlock or manual entry of the watch passcode before it can authorize anything else.
Building on the earlier discussion of Cloud Key Vault fleets, an attendee asks what prevents an adversary or law enforcement agency—specifically naming the FBI—from forcing Apple to migrate existing user escrow keys over to a compromised or government-controlled fleet. Krstic explains that such an attack vector is architecturally impossible:
> “there is no ability to migrate an existing record to a new Fleet that's simply not possible what we can do is stand up a new Fleet and migrate new enrollments into that Fleet”
Krstic emphasizes that an existing escrow record can only ever be decrypted by the specific hardware security module cluster to which the user committed it. Introducing a new fleet requires deploying the new fleet's root CA certificate directly onto user devices via an iOS software update. When asked whether existing devices would stay attached to older fleets, Krstic notes that devices target the best fleet available to their current software version, underscoring that “more than 90% of our user base is using the latest version of iOS so that's a good place to be”.
[47:19](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2839s) SEP Passcode Rate Limiting and Biometric Spoofing
An attendee asks about the enforcement mechanism behind the 10-attempt passcode limit before an iOS device wipes or locks out, asking whether that counter is maintained within the Secure Enclave or stored in external memory. Krstic confirms that the process is completely isolated:
> “it is enforced fully in the SEP the SEP has a secure monotonically increasing counter and if uh that counter reaches 10 incorrect passcode attempts it will simply refuse to use the UID key any further for that user key bag”
The next question raises concerns over fingerprint spoofing research and large-scale biometric credential theft, citing the Office of Personnel Management (OPM) breach. The attendee wonders whether Apple has considered mitigations against fabricated fingers or allowing end users to shorten the 48-hour passcode fallback window. Krstic acknowledges the inherent challenges of biometric authentication:
> “for uh Biometrics in general I think uh these uh vulnerabilities are to some degree inherent and we do the the very best we can with both our sensor and how it's used”
He reminds the audience that all Touch ID template matching occurs strictly inside the Secure Enclave and never touches the Application Processor (AP), adding that Apple actively monitors public biometric research to iteratively strengthen hardware and algorithmic defenses.
[49:00](https://www.youtube.com/watch?v=BLGFriOKz6U&t=2940s) Research Inquiries and Closing Remarks
The remaining questions touch on various security domains, though Krstic keeps the scope tightly bounded: - **iOS 10 Watchtower:** When asked to elaborate on the internal architecture of iOS 10’s Watchtower feature, Krstic politely declines, stating he wants to remain focused on the topics presented during the talk. - **Hardware Side Channels:** In response to an inquiry about side-channel defenses against electromagnetic (EM), power analysis, or acoustic monitoring attacks, Krstic notes he is unsure how much is detailed in the current iOS Security Guide, but encourages the researcher to email the security team so they can evaluate expanding that documentation. - **Top Threat Vector:** An attendee humorously asks what single security issue Krstic finds most persistent in iOS. Krstic jokingly reacts to the difficulty of the question by playing to the crowd with a deadpan “tough audience questions thank you”, drawing laughter and applause before quieting them with a smile: “no really don't thank you”. - **Vulnerability Response Times:** A researcher representing a security team from China raises a concern that reports submitted to Apple Product Security have faced long turnaround times, sometimes stretching toward a year. Krstic responds that while Apple receives an extraordinary volume of inbound reports, the vast majority receive very prompt responses: “if you have issues that for some reason you're having trouble with please send another email you should not be encountering that kind of issue”.
Krstic concludes the presentation by thanking the audience for attending and expressing his hope that they enjoyed the deep technical dive into iOS security internals.
## Notable quotes > [21:34](https://www.youtube.com/watch?v=BLGFriOKz6U&t=1294s) if a production device is demoted, the UID key that was used in deriving the master key that protects any user data previously on that device is simply unavailable to any software—a different UID key turns up. — Ivan Krstic
## Mentioned Apple, AppleKeyStore, Apple Pay, Apple Security Bounty, Apple Watch, Application Processor (AP), ARM, ARMv8, Auto Unlock, Cloud Key Vault, Crypto Blender, Custom Security Code (CSC), Federal Bureau of Investigation (FBI), FIPS 140-2, Hardware Security Module (HSM), HomeKit, iCloud Keychain, iCloud Security Code (iSC), iOS 9, iOS 10, iOS Security Guide, iPhone, iPhone 5s, Ivan Krstić, keybagd, macOS Sierra, Office of Personnel Management (OPM), s_bio, Safari, Secure Boot, Secure Element, Secure Enclave Processor (SEP), Secure Key Store (SKS), Secure Remote Password (SRP), SpringBoard, Touch ID, Watchtower, WebKit
## Video description by Ivan Krstic
With over a billion active devices and in-depth security protections spanning every layer from silicon to software, Apple works to advance the state of the art in mobile security with every release of iOS. We will discuss three iOS security mechanisms in unprecedented technical detail, offering the first public discussion of one of them new to iOS 10.
HomeKit, Auto Unlock and iCloud Keychain are three Apple technologies that handle exceptionally sensitive user data – controlling devices (including locks) in the user's home, the ability to unlock a user's Mac from an Apple Watch, and the user's passwords and credit card information, respectively. We will discuss the cryptographic design and implementation of our novel secure synchronization fabric which moves confidential data between devices without exposing it to Apple, while affording the user the ability to recover data in case of device loss.
Data Protection is the cryptographic system protecting user data on all iOS devices. We will discuss the Secure Enclave Processor present in iPhone 5S and later devices and explain how it enabled a new approach to Data Protection key derivation and brute force rate limiting within a small TCB, making no intermediate or derived keys available to the normal Application Processor.
Traditional browser-based vulnerabilities are becoming harder to exploit due to increasingly sophisticated mitigation techniques. We will discuss a unique JIT hardening mechanism in iOS 10 that makes the iOS Safari JIT a more difficult target.
[Source](https://www.youtube.com/watch?v=BLGFriOKz6U)