Mobile device security ====================== What attacks is this design trying to address? Someone steals your iPhone. And wants to extract data from it. This paper represents a big effort: why might Apple care? Customers who must keep secrets (medical, government, reporters, &c). Ordinary customers nervous about e.g. bank password. Competitive advantage vs e.g. Android. Trying to do the right thing. The design assumes: Device is passcode-protected. Device is locked at time of theft. What are potential attacks on a stolen device? Exhaustive search for passcode -- often only four digits. Impersonate user's fingerprint or face. Take apart the phone and remove the flash storage chips. Or read from powered-up RAM. Exploit a bug in the OS kernel. Phone locked -- but USB, WiFi, and radio may be active. Install a hacked version of the OS w/o security checks. Redirect network traffic to adversary's update server? Take apart the phone and write different OS onto flash chips? Down-grade to an old version of the OS that has a known bug. Reasonably successful design for stolen phones. Much harder to extract data from stolen iPhone than 10 years ago. Even the FBI complains. Though history suggests this is not the end of the story. iOS hardware architecture: Main CPU. RAM. Flash file storage. AES encryption engine between main CPU / DRAM and flash storage. Secure enclave CPU. "UID" cryptographic key in enclave hardware. Enclave can encrypt / decrypt but cannot get the UID. Authentication sensors: fingerprint reader, face ID camera. Touch ID Ktouch | | Flash ----- AES DMA ----- Main CPU ----- RAM ----- Enclave Ke ECID UID+AES Boot ROM Boot ROM Apple pub key Apple pub key Ke anti replay counter Ktouch RAM crypto Interesting aspects of the design, for this lecture: Secure boot. Enclave Hiding of all keys and crypto operations from main CPU. Data encryption gated by passcode. Defenses against exhaustive passcode search. Inter-unit crypto. Next lecture: app isolation and sharing (focusing on Android). === Secure boot. Goal: make sure adversary cannot run modified OS / apps / enclave. At power-on, CPU starts executing from Boot ROM. Read-only. Specified at chip fabrication. Boot sequence: Boot ROM -> iBoot -> OS kernel -> apps. Boot ROM checks that iBoot code is signed by Apple. iBoot checks that OS kernel code is signed by Apple. OS kernel checks that apps are signed by developer approved by Apple. Downgrade attacks. Attack: replace OS kernel with an older one with a known bug. An old OS kernel signed by Apple! Now adversary can exploit an old bug in the old OS kernel. Strawman solution: record versions. E.g., iBoot checks that OS kernel is at least a certain version. Where would the version number be stored? What prevents adversary from modifying the stored version number? Downgrade prevention with ECID. Each device has a unique ID called the ECID. Read-only, set at chip fabrication time. Apple's servers sign upgrades for a specific ECID. Boot sequence checks signature is for the this phone's ECID. Why does this help? Adversary unlikely to have the old software with victim's ECID. Apple update servers will not sign an out-of-date kernel. === Secure enclave. The point: Prevent main CPU from ever seeing crypto keys. Defend against passcode guessing. CPU asks enclave to do things, e.g. help it decrypt. Implemented using a separate CPU. Secure boot sequence, like the main CPU. Shares DRAM with the main CPU. Communicates w/ main CPU through DRAM. Encrypts its own memory contents. Authenticates memory for integrity / freshness. Memory authentication state stored in on-chip SRAM. Compared to SGX? Shares SGX goal of hiding secrets from a not-very-trustworthy kernel. Separate CPU (not a mode). Runs only fixed Apple s/w (not applications). User authentication using the enclave. Overall plan: All user data is encrypted. Allow decryption when phone is unlocked. Forbid decryption when phone is locked. Why offload authentication onto the secure enclave? Prevent compromised OS kernel from: Getting decryption keys, fingerprint/face data. Bypassing passcode retry limits. Allow hiding of keys &c with memory encryption / auth. So direct read of RAM yields no crypto secrets. Too costly for main CPU, but acceptable for the secure enclave. Primary authentication mechanism: passcode. Decryption keys computed based on passcode (will discuss later). Additional mechanisms: fingerprint, face recognition. Secure enclave caches decryption keys once user enters passcode. Uses these keys if presented with correct fingerprint or face match. Protecting sensor-to-enclave communication. Attack: compromised OS replays fingerprint reading to secure enclave. Attack: adversary substitues fake fingerprint sensor. Design: cryptographic authentication between sensors and secure enclave. Sensor has a secret AES key. Enclave knows the same secret key (shared at phone manufacture time). Sensor encrypts and authenticates all data with the AES key. Probably some nonce or session ID to prevent replay of old data. Facial recognition (sort of an aside, but surprisingly sophisticated) Face camera includes IR dot projector, IR camera. Many IR dots, in a random pattern, are projected onto user's face. IR camera reads the dots, reports them to the secure enclave. May help distinguish 3d face from 2d picture of face. === Data encryption. Data = files stored in flash. Attack: adversary takes apart the phone, reads data from flash chips. Plan: encrypt data stored on flash chips. Why do they generate data encryption keys from passcode? (versus storing the key somewhere permanently) So that keys exist nowhere on device after reboot. So that keys can be forgotten when device locks. How do they generate data encryption keys from passcode? Danger: only 9999 passcodes, easy to try them all. Danger: attacker extracts flash chips, tries all passcodes in attacker's machine. iOS scheme: Enclave h/w contains unique UID and AES engine. Enclave s/w cannot access UID, can only encrypt/decrypt. Data encryption key is roughly E_UID(E_UID(...(passcode))) i.e. encrypt w/ UID many times. Why? Dependent on passcode, so key exists nowhere on device after reboot. In enclave, which limits number of guesses. Slow, to limit speed of exhaustive search. Dependent on UID, to prevent brute-forcing outside of the device. Important idea for key management: "key wrapping". E_k1(k2) Anyone that knows k1 can obtain k2, by decrypting. Used to delegate: from module that knows k2 to module that knows k1. File encryption. Each file's content is encrypted by a different key, Kf. File system metadata (directories, inodes, ...) Encrypted with a single key, Kfs. Different levels of "data protection". Complete: can decrypt if phone is currently unlocked. Derived from passcode on unlock, discarded when locked. Complete unless open: file can be written any time (but not read). Special case for background downloading of attachments. Until first authentication: .. if phone was unlocked since reboot. Derived from passcode on first unlock, discarded on power-off. No protection: can decrypt any time. Derived only from UID (not passcode), so available from boot. Each of these levels corresponds to a data protection level key. Kdp These data protection keys are stored only in the secure enclave. Wrapping file keys. A file's metadata contains the file's key wrapped with DP key. E_Kdp(Kf) (This is in turn encrypted with Kfs, since it's part of FS metadata.) FS code on main CPU sees only wrapped keys. Asks secure enclave to unwrap needed keys. Secure enclave will unwrap, if it has DP key. But OS kernel never gets the raw keys! Data is encrypted/decrypted by hardware AES engine. Shared secret between the AES engine and the secure enclave: Ke. Secure enclave wraps the file key with the AES engine's key. E_Ke(Kf) Sends this wrapped key to the OS kernel. OS kernel can program the AES engine as needed. How to obtain data protection keys with Touch ID or Face ID? Cannot use Touch ID / Face ID immediately after reboot; must first enter passcode. When passcode is entered, enclave computes the Kdp keys. Enclave sets aside (encrypted) copies for later use w/ * ID. When user locks phone, enclave deletes Kdp. But can re-obtain keys with Touch ID / Face ID. File system key: Kfs. Protected by UID: secure enclave stores E_UID(Kfs). Secure enclave gives E_Ke(Kfs) to OS kernel at boot time. Why bother with Kfs at all? Makes it possible to erase data quickly, by deleting Kfs. Or, really, deleting E_UID(Kfs). Secure data deletion. Goal: allow user to quickly wipe data on the phone. Goal: wipe phone after 10 failed unlock attempts. Challenge: hard to delete data! Takes time. Flash makes copies for wear-leveling. "Effaceable storage" Special NAND flash direct access for secure enclave! Can issue low-level NAND flash operations to delete data. Used to store E_UID(Kfs). Places to look for weaknesses? Kernel on main CPU sees lots of sensitive material. Passcode, decrypted data, web passwords, &c. But iOS kernel has had bugs that apps can exploit. These give an app root / kernel privileges on main CPU. Luckily you can't install new malicious apps on a locked phone. Boot code may have bugs; boot a kernel that allows passcode guessing. USB, WiFi, and radio s/w probably have bugs, and may be active even when the phone is locked. Apple's private key must be kept safe -- but must also be used to sign "personalized" updates. Can UID be extracted from h/w if you have enough money? Is there a cost to this iOS security? Specialized hardware costs money (enclave, fingerprint reader, AES DMA). Irritating to have to type passcode. Need passcode in many situations, e.g. backing up. Background activities are awkward, when device is locked. Forgotten passcode -> data permanently lost (unless backed up). === Several interesting ideas / techniques. Secure boot: code signing, downgrade prevention. Secure enclave: encrypted/authenticated communication with sensors. Data protection: file keys, key wrapping, device key, effaceable storage.