Behind the Scenes with iOS Security
Black Hat 2016

Ivan Krstić
Head of Security Engineering and Architecture, AppleDecrypted Kernel Caches

Component Encryption
iOS 10User data—No change to encryption
Image3 (pre-iPhone 5S)—iBoot, kernel caches, boot logos no longer encrypted
Image4 kernel caches—No longer encrypted
Changes made as part of wider set of performance optimizations
Encryption for these objects was no longer adding a lot of value
No impact to platform security or encryption of user data

Hardened WebKit JIT MappingHardened WebKit JIT Mapping
BackgroundJust-in-time compilation is necessary for high-performance JavaScript
iOS normally requires all executable pages to be signed
Code signing policy is relaxed in Safari through dynamic-codesigning entitlement tosupport JIT compilation

Hardened WebKit JIT Mapping
iOS 9
32MB RWX JIT memory region
Write-anywhere primitive suﬃcient for arbitrary code execution
Attacker can write shell code into JIT region and jump to it without ROP

Hardened WebKit JIT Mapping
Execute-only memory protection
Hardware support introduced in ARMv8
Kernel implementation added in iOS 10
Allows us to emit code containing secret data, not readable within the process

Hardened WebKit JIT Mapping
Split view
Create two virtual mappings to the same physical JIT memory
One executable, one writable
The location of the writable mapping is secretHardened WebKit JIT Mapping
Tying it all together
Writable mapping to JIT region is randomly locatedEmit specialized memcpy with base destination address encoded as immediate values
Make it execute-only
Discard the address of the writable mapping
Use specialized memcpy for all JIT write operations

void initializeSeparatedWXHeaps(void* stubBase, size_t stubSize, void* jitBase,size_t jitSize){mach_vm_address_t writableAddr = 0;// 1. Create a second mapping of the JIT region at a random address.
vm_prot_t cur, max;
kern_return_t ret = mach_vm_remap(mach_task_self(), &writableAddr, jitSize, 0,
VM_FLAGS_ANYWHERE | VM_FLAGS_RANDOM_ADDR,
mach_task_self(), (mach_vm_address_t)jitBase, FALSE,&cur, &max, VM_INHERIT_DEFAULT);bool remapSucceeded = (ret == KERN_SUCCESS);
if (!remapSucceeded)
return;// 2. Assemble specialized memcpy function for writing into the JIT region.
MacroAssemblerCodeRef writeThunk =jitWriteThunkGenerator(reinterpret_cast<void*>(writableAddr), stubBase, stubSize);
int result = 0;
#if USE(EXECUTE_ONLY_JIT_WRITE_FUNCTION)// 3. Prevent reading the memcpy code we just generated.
result = mprotect(stubBase, stubSize, VM_PROT_EXECUTE_ONLY);RELEASE_ASSERT(!result);#endif// 4. Prevent writing into the executable JIT mapping.
result = mprotect(jitBase, jitSize, VM_PROT_READ | VM_PROT_EXECUTE);RELEASE_ASSERT(!result);// 5. Prevent execution in the writable JIT mapping.
result = mprotect((void*)writableAddr, jitSize, VM_PROT_READ | VM_PROT_WRITE);
RELEASE_ASSERT(!result);// 6. Zero out writableAddr to avoid leaking the address of the writable mapping.
memset_s(&writableAddr, sizeof(writableAddr), 0, sizeof(writableAddr));
jitWriteFunction =reinterpret_cast<JITWriteFunction>(writeThunk.code().executableAddress());}

iOS 9RWX

iOS 10
--X

R-X

RW-

iOS 10
--X

R-X

RW-

iOS 10
--X

R-X

RW-

mov x0, #0

iOS 10
--X

R-X

RW-

mov x0, #0

mov x0, #0

iOS 10
--X

R-X

RW-

mov x0, #0

mov x0, #0Hardened WebKit JIT Mapping
iOS 10
Write-anywhere primitive now insuﬃcient for arbitrary code execution
Attacker must subvert control flow via ROP or other means or find a way to call executeonly JIT write function
Mitigation increases complexity of exploiting WebKit memory corruption bugs

Data Protection with the
Secure Enclave Processor

Data Protection
Goals
User data protected by strong cryptographic master key derived from user passcodeNo oﬄine attack on user passcode—Hardware-bound master key derivation
No brute force—Hard limit on number of passcode attempts
Hardware keys for master key derivation not directly exposed to any mutable software
Secure support for alternative unlock mechanisms (Touch ID, Auto Unlock)Data Protection
Goals—Sidestep AP attack surface
Authentication policy enforcement even under adversarial AP
Master (long-term) key material never exposed to AP
Non-master key material exposed to AP must be ephemeral and session-boundSecure Enclave Processor

Secure Enclave Processor
Overview
Dedicated SoC core provides trusted environment for handling cryptographic material
Arbitrates all user data accessHardware accelerators for AES, EC, SHAManages its own encrypted memory and communicates with the AP using mailboxes
Factory-paired secure channels to Touch ID sensor and Secure Element

Device UID Key
Background
Each SEP has reference access to a unique private key (UID)
UID generated by SEP itself immediately after fabrication, using its own free-runningoscillator TRNG
Available for cryptographic operations via commands exposed by the Secure ROM
No access to UID key material from SEP or other mutable software after fuses blown

User Keybags
Background
Sets of keys generated for each user to protect their data at rest
Keys wrapped by master key derived from user passcode and SEP UID
After 10 incorrect passcode entries, SEP will not process any further attempts
Diﬀerent policy associated with each keybag key—Usage, availability

User Keybags
Class keys
Class

Description

A (256-bit AES)

Only available while the device is unlocked

B (Curve 25519)

Public key always available, private key only available when device is unlocked

C (256-bit AES)

Available after the user unlocked the phone at least once after bootD (256-bit AES)

Always available

00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090...
000004e0000004f0
00000500
00000510
00000520
00000530
00000540
00000550
00000560
00000570
00000580
00000590
000005a0000005b0
000005c0000005d0000005e0000005ee

44 41 54 41 00 00 05 ca
00 00 00 04 54 59 50 45
55 55 49 44 00 00 00 10
96 96 30 36 42 3a 42 0c
49 78 be cb 61 71 ed c8
4e d4 c4 19 83 dc d1 97
d3 d2 be d1 e2 55 ef 40
00 00 00 01 53 41 4c 54
ee 44 89 d1 c8 47 9a d7
49 54 45 52 00 00 00 04

56 45 52 53 00 00 00 04
00 00 00 04 00 00 00 00
4a 99 c1 fd 7e 55 44 43
48 4d 43 4b 00 00 00 28
70 4e fc 3d 01 2b 10 bf
82 3c e1 2f de 9b 51 53
57 52 41 50 00 00 00 04
00 00 00 14 7e f0 23 95
75 2f 07 49 54 74 d0 cc
00 00 c3 50 47 52 43 45|DATA....VERS....||....TYPE........||UUID....J...~UDC||..06B:B.HMCK...(||Ix..aq..pN.=.+..||N........<./..QS||.....U.@WRAP....||....SALT....~.#.||.D...G..u/.ITt..||ITER.......PGRCE|

47 47 bc 18 6b 92 f3 fa
00 04 00 00 00 02 57 52
00 03 4b 54 59 50 00 00
4b 59 00 00 00 28 a2 dd
70 07 79 5f 6e ed 42 05
a2 7f 3c c0 4c 38 bd 5f
4b 59 00 00 00 20 03 b1
83 7c d1 2c d7 28 f9 d3
00 ae f7 b5 7b 51 55 55
b5 bc cd cb 42 e6 93 ed
41 53 00 00 00 04 00 00
00 04 00 00 00 03 4b 54
00 00 57 50 4b 59 00 00
2a 37 2c 9e 39 b0 90 74
eb 36 17 42 16 6b 74 13
af aa 53 49 47 4e 00 00
b4 f8 70 88 b1 8a c4 cc

cc 94 43 4c 41 53 00 00
41 50 00 00 00 04 00 00
00 04 00 00 00 01 57 50
c7 83 56 45 21 bb 1f 70
2e a0 2f e2 6f a5 14 4e
1a ce 45 a1 06 ca 50 42
b1 6e aa 7a 59 25 b5 43
48 c1 41 cc 50 47 38 53
49 44 00 00 00 10 50 ba
dd 1a 18 3e fb f4 43 4c
00 01 57 52 41 50 00 00
59 50 00 00 00 04 00 00
00 28 45 9c 2c 38 0c f1
f4 e4 21 f8 b3 c1 48 44
15 b2 72 c8 a9 1d 17 f5
00 14 db 7a 1e 3c 39 56
4b ea a6 fb df 65|GG..k.....CLAS..||......WRAP......||..KTYP........WP||KY...(....VE!..p||p.y_n.B.../.o..N||..<.L8._..E...PB||KY... ...n.zY%.C||.|.,.(..H.A.PG8S||....{QUUID....P.||....B......>..CL||AS........WRAP..||......KTYP......||..WPKY...(E.,8..||*7,.9..t..!...HD||.6.B.kt...r.....||..SIGN.....z.<9V||..p.....K....e|Keybag version 4

KDF Salt
Iteration CountKey Identifier: Class B
Key Type: Curve25519
Wrapped Private Key Bytes
Public Key Bytes

Key Identifier: Class A
Key Type: AES
Wrapped Private Key Bytes

Master Key Derivation

Passcode

UserlandSEP

KDF

Mki = KDF2(E(UID, MKi-1))

Salt

Timed Iterations (100-150ms)

Master Key

Filesystem Data Protection
Overview
File blocks are encrypted using AES-XTS with 128-bit keys
Each file on the user partition is encrypted using a unique random key chosen by SEP
Raw file keys are never exposed to the AP• Wrapped with a key from the user keybag for long-term storage• Wrapped with an ephemeral key while in use, bound to boot session

Filesystem Data Protection
User

Kernel
1. Fetch wrapped
file_key frommetadata

open(“foo.txt”, …)

4. Send IO
command withephemerally
wrappedfile_key

Hardware

NAND

Cipher Text

SEP
HFS

NVME Driver
Clear Text

Storage
Controller

Key Store

AES Engine

2. Unwrap file_key
using keybag key

3. Wrap file_key using
ephemeral_key,
return ephemerally
wrapped file_key
to kernel

Ephemeral Key
established on boot7) keybagd loads system keybag (class D key available)
6) launchd starts keybagd

Userspacekeybagd

systembag.kb

gets prot key from eﬀaceableloads device keybag into SEP/var/keybags/systembag.kb
encrypted with the keybag
prot key8) decrypts keybag
with prot key from
eﬀaceable5) launchd mounts user partition

4) decrypt HFS metadata with media key

XNU (Kernel)

AppleKeyStoreHFS

SEP endpoint to SKS

1) kernel boots (system partition)

SEP

Eﬀaceable
media key
keybag prot key
Class D

2) AppleKeyStore loads D key (before user partition is mounted)3) decrypt class D key, load into keyringclass D

contains the device keybag9) keybag loaded into sks memory, class B public loaded into keyring

SEP UID

SKS

class DSKS memory

SKS keyring

master key + SEP UID

class B (public)
class D

class A
class B (priv)class C10) class keys cannot be decrypted until we get the passcode11) launchd permits userspace to start loadingboot1) SpringBoard acquires the passcode

Userspace

UserEventAgent

SpringBoard

Darwin lock/unlock
Notifications

MobileKeybag.framework7) first unlock notification sent

AppleKeyStoreXNU (Kernel)

SEP Endpoint to SKS

bio unlock token only created if bio unlock is enabled steps 4 & 52) generate master key

master key

SKS

SBIO

SEP
SKS keyring

SKS memory

random secret

SBIO memory

class A
class B (priv)class B (public)
class Cclass D

master key + SEP UID

master key

random secretclass A
class B (priv)class C5) send random secret to
SBIO, destroy it in SKS4) encrypt master key with random secret – this encrypted master key never leaves SKS6) securely destroy raw master key3) decrypt class keys, add to keyring

first unlock

1) device locks

Userspace

UserEventAgent

SpringBoard

Darwin lock/unlock
Notifications

MobileKeybag.framework3) send lock notification

AppleKeyStoreXNU (Kernel)

SEP Endpoint to SKS

SKS
SEP

2) purge class A and class B priv keys

SKS keyringclass B (public)
class Cclass DSKS memory
master key + SEP UID
class A
class B (priv)class Clock

Userspace

UserEventAgent

SpringBoard

Darwin lock/unlock
Notifications

MobileKeybag.framework

1) pressing home button starts Touch ID sensor

7) send unlock notificationXNU (Kernel)

4) decrypt
master key

random secretAppleKeyStoreAppleMesa

SEP endpoint to SKS

SEP endpoint to SBIO

SKS

SBIO

master key

bio memory
SEP

master key

random secret

SKS memory

SKS keyring

3) upon successful match send
random secret to SKS

master key + SEP UID

class A
class B (priv)class B (public)
class Cclass D6) securely destroy master keyclass A
class B (priv)class C

Touch ID
Sensor2) template match sent to SBIO

5) decrypt class keys, add to keyring

Touch ID unlock

Unattended Update—Install LaterFirst
Unlock

1:00 PM

10:00 PM

10:15 PM

NotifyUpdateLast
UnlockBeforeUpdateSoftwareUpdateLock

10:30 PM

3:00 AM

Lock

UpdateWindow

8 hr persist timer

Boot

20 min commit timer

prompt for passcode
OTUT creation enabled

OTUT created

OTUT persist
enabledOTUT persisted

OTUT committed
rebootSoC Security Mode
Demotion
Production devices can be “demoted” to enable some debugging features like JTAG andloading development software on the AP (but not the SEP)
Requires full OS erase and device explicitly authorized by the personalization server
Forces a diﬀerent UID on the SEP, no access to existing user data after demotion

SoC mode

AP status

SEP status

SEP UID

Development fused

Development

Development

Development

Production fused

Production

Production

Production

AP demoted

Development

Production

Development

Data Protection
Goals
User data protected by strong cryptographic master key derived from user passcodeNo oﬄine attack on user passcode—hardware-bound master key derivation
Hardware keys for master key derivation not directly exposed to any mutable software
Secure support for alternative unlock mechanisms (Touch ID, Auto Unlock)Sidesteps AP attack surface, SEP policy enforced under adversarial AP

Synchronizing Secrets

Synchronizing Secrets
Uses
Passwords and credit card information available on all of a user’s devices
Auto Unlock cryptographic keys shared between Apple Watch and Mac
HomeKit cryptographic keys available on all devices

Synchronizing Secrets
Traditional approaches
Wrap user secrets with strong random key• User has to take care of a printed “sock drawer key” and enter it on each device• If printed key is lost, losing devices means loss of secrets

Wrap user secrets with KDF-derived key from their password• Account provider backend is privileged, can intercept or brute-force account password• If user resets their account password, must prompt for old password to recover secrets• Anyone else in possession of wrapped user secrets can launch a brute-force attack

“Humans are incapable of securely storinghigh-quality cryptographic keys, and they
have unacceptable speed and accuracy
when performing cryptographic operations.”
C. Kaufman, R. Perlman, M. Speciner

Synchronizing Secrets
Goals—Inspired by Data Protection
Selected user secrets available on all of the user’s devices
Synchronization protected with strong cryptographic keys
User can recover secrets even if they lose all their devices
User secrets not exposed to Apple
No brute-force—backend not in a privileged position

iCloud Keychain
Approach
Each device locally generates iCloud Keychain synchronization key pair
User explicitly approves new devices joining the sync circle from a device already in it
Sync circle uses Apple cloud backend for storage and message passing• No data is accessible to Apple• Backend not in a privileged position since key pair is strong and random

What if all devices are lost, or need to configure new device without access to old one?

iCloud Keychain Backup
PremiseNew credential—iCloud Security Code (commonly device passcode),
unknown to Apple
Generate strong random backup (“escrow”) key, wrap with KDF-derived key from iCSC
Back up copy of iCloud Keychain secrets to the Apple cloud, encrypted with escrow key
Send wrapped escrow key to AppleIn case of device loss or new device, user can recover secrets with their iCloud password
and the iCSC

Synchronizing Secrets
Goals—Inspired by Data Protection
Selected user secrets (passwords, credit cards, …) available on all of the user’s devices
Synchronization protected with strong cryptographic keys
User can recover secrets even if they lose all their devices
User secrets not exposed to Apple
Backend not in a privileged position to brute-force keys protecting user secrets

iCloud Keychain Backup
Backend attack surface
In naive implementation, backend could brute force the iCSC to access escrow key
Just like with SEP, need to enforce policy over escrow key
No brute–force—Want hard limit on escrow recovery attempts under adversarial cloud
What if escrow key unwrapping only took place in Hardware Security Modules?

Cloud Key Vault
Overview
HSMs running custom secure code connected to Apple cloudKey vault fleet operates its own CA, private key never leaves the hardware
Each iOS device hardcodes key vault fleet CA certCloud Key Vault
Unit

Host

HSM

Cloud Key Vault
HSM keysKey

Description

CSCIK

RSA-2048, allows signing custom secure code to run on the HSM

AK

256-bit for HMAC-SHA-256, to authenticate messages between vault unitsCA

RSA-2048, to certify service key (SK)SK

RSA-2048, allows unwrapping escrow records

Cloud Key Vault
Escrow record generated on iOS device

SRP verifier for iCSC
User’s escrow key

🔐Maximum failure countencrypted to
public service key

Cloud Key Vault
Understanding the design
A kind of SEP Data Protection approach for escrow records
Vault service private key material not available to mutable software, just like SEP UID key
User attempting escrow recovery sends previous escrow record, establishes SRP session
Vault unwraps escrow record, SRP with user device against iCSC verifier in the record,
return escrow key if successful
If SRP fails due to incorrect iCSC, vault unit bumps a secure counter• If maximum failure count (10) is exceeded for the record, record is marked terminal

Cloud Key Vault
Redundancy and attack surface
Users can’t escrow to only a single vault unit, need redundancy
Escrowing to multiple units means multiplying the maximum failure count providing
more opportunity for brute force attack

Cloud Key Vault
Club
Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Cloud Key Vault
Club
Group of five vault units that share a single SK—Service Key
User generates escrow record for a particular club, certified by the fleet CA
Solves redundancy, but not the brute force limiting problem
Club members would still be subject to partitioning attacks

Cloud Key Vault
Quorum commit
Each club member maintains its own failure count for each escrow record
Escrow recovery prompts a vote, majority quorum required to proceed
Provides redundancy and breaks membership partitioning attacks

Cloud Key Vault
Fleet
Authenticated object
storage

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

Host

HSM

Host

HSM

Host

HSM

Host

HSM

Host

iCloud escrow service

Host

HSM

Host

HSM

Host

HSM

HSM

Host

HSM

HSM

Host

HSM

…

Cloud Key Vault
Escrow Recovery Transaction
1. Proposal
2. VoteHost

HSM

3. Schedule

Host

HSM

Host

HSM

Host

HSM

4. Ack
5. Perform

Host

HSM

6. Confirm“I propose an update. Please give me your failure count for this record.”Cloud Key Vault
Escrow Recovery Transaction
1. Proposal
2. VoteHost

HSM

3. Schedule

Host

HSM

Host

HSM

Host

HSM

4. Ack
5. Perform

Host

HSM

6. Confirm“My counter is 4. I vote yes to update since I’m not in another transaction.”

Cloud Key Vault
Escrow Recovery Transaction
1. Proposal
2. VoteHost

HSM

3. Schedule

Host

HSM

Host

HSM

Host

HSM

4. Ack
5. Perform

Host

HSM

6. Confirm“We have majority quorum and no one’s record is terminal,
prepare to update failure count to 5.”Cloud Key Vault
Escrow Recovery Transaction
1. Proposal
2. VoteHost

HSM

3. Schedule

Host

HSM

Host

HSM

Host

HSM

4. Ack
5. Perform

Host

HSM

6. Confirm“OK, I’ve verified majority quorum and stand ready to increase failure count to 5.”Cloud Key Vault
Escrow Recovery Transaction
1. Proposal
2. VoteHost

HSM

3. Schedule

Host

HSM

Host

HSM

Host

HSM

4. Ack
5. Perform

Host

HSM

6. Confirm“Please proceed with increasing failure count to 5 for this record.”Cloud Key Vault
Escrow Recovery Transaction
1. Proposal
2. VoteHost

HSM

3. Schedule

Host

HSM

Host

HSM

Host

HSM

4. AckHost

HSM

5. Perform
6. Confirm“OK, my failure count is now 5 for this record.”Cloud Key Vault
Who watches the watchers?
A given vault fleet runs code signed by its CSCIK (custom secure code signing key)
Use of this signing key requires a quorum of physical vault admin smart cards
Admin cards are created in a secure ceremony when fleet is commissioned, stored inseparate physical safes in custody of three diﬀerent organizations at Apple in tamperproof evidence bagsCloud Key Vault
Who watches the watchers?
If someone got their hands on all the admin cards…
Couldn’t they sign a malicious custom secure code image that can brute-force iCSC for
arbitrary escrow records?

No.

Cloud Key Vault
Before a fleet goes into production
Members of all three admin card-carrying organizations meet in a secure facility
Cross-check serial numbers on evidence bags and on cards
Attestations• Card carriers present at creation of the admin cards• No other cards were created• Evidence bags remained sealed since creation• Cards present today are the ones originally createdPhysical One-Way Hash Function

(We Run the Cards Through a Blender)Cloud Key Vault
Final attestation
All admin cards originally created are now destroyed
The cards were not used to sign any other custom secure code that can be loaded
No other mechanism is known for changing custom secure code or loading new code
This enables us to make the unequivocal commitment that user secrets are not exposed
to Apple

Some News

Apple Security Bounty

Apple Security Bounty
Great help from researchers in improving iOS security all along
iOS security mechanisms continue to get stronger
Feedback from Apple Red Team and external researchers: as iOS security has advanced,
increasingly diﬃcult to find the most critical security issues

Apple Security Bounty
Rewards researchers who share critical issues with AppleWe make it a priority to resolve confirmed issues as quickly as possible
Provide public recognition, unless asked otherwise

Initial Categories
Category

Max. Payment

Secure boot firmware components$200,000

Extraction of confidential material protected by the Secure Enclave Processor$100,000

Execution of arbitrary code with kernel privileges$50,000

Unauthorized access to iCloud account data on Apple servers$50,000

Access from a sandboxed process to user data outside of that sandbox$25,000

Apple Security Bounty
Payments
We require a clear report and working proof of concept
Vulnerability must aﬀect latest shipping iOS, and where relevant, latest hardware
Exact payment amount determined after review by engineering team, criteria include
novelty and likelihood of exposure/degree of user interaction required
Researcher can elect to donate reward to charity of their choice, Apple will consider
matching 1:1

Apple Security Bounty
Few dozen initially invited researchers
If vulnerabilities that would be covered under the program are submitted by researchers
outside of the program, we will review the submission and, if the work merits it, invite
researcher into the program and reward the vulnerability

September

Thank You!
product-security@apple.com

TM and © 2016 Apple Inc. All rights reserved.