Mobile device security
======================

What attacks is this design trying to address?
  Real system so inevitably many issues to balance.
    Looks similar to the Google paper, in some ways.
  Physical device security.
    Someone steals your iPhone.
    Maybe as a special case, someone briefly grabs your iPhone.
    Wants to get data from it.
  Malicious apps.
    Will talk about this more in Wednesday's lecture.
    Android has a different (and better explained) app security plan.

What are potential attacks on a physical device?
  Try to impersonate user: passcode, fingerprint, facial recognition.
  Take apart the phone and remove the flash storage chips.
  Exploit a bug in the OS kernel to bypass security checks.
  Install a different version of the OS that doesn't have security checks.
    Maybe by redirecting network traffic to adversary's server.
    Maybe by taking apart the phone and writing different OS onto flash chips.
  Install an old version of the OS that has a known bug.

Reasonably successful design, w.r.t. physical security.
  Significantly raises the effort required to obtain data from iPhone.
  E.g., even the FBI complains about difficulty of extracting data.

iOS device architecture, at the hardware level:
  Main CPU.
  DRAM memory.
  Flash storage.
  AES encryption engine between main CPU / DRAM and flash storage.
  Secure enclave CPU.
  "UID" cryptographic key in hardware.
    Can encrypt / decrypt but not get the key.
  Authentication sensors: fingerprint reader, face ID camera.
  Baseband CPU with its own DRAM.

Interesting aspects of the design, for this lecture:
  Secure boot.
  Authentication in secure enclave.
  Data encryption.
  Next lecture: app isolation and sharing (focusing on Android).

===

Secure boot.
  Goal: make sure adversary cannot run modified OS / apps / enclave.
  At boot time, CPU starts executing code 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.
  OS kernel requires that each app process runs code from that app's developer.
    Libraries must be part of the same "Team ID", or system libraries.

Downgrade attacks.
  Boot-sequence software will inevitably have bugs (many "Jailbreak" exploits).
  Possible attack: replace OS kernel with an older one with a known bug.
  The old OS kernel was legitimately signed by Apple.
  Now adversary can exploit some bug in the 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, determined at chip fabrication time.
  Signed software (e.g., iBoot, OS kernel) is signed for a specific ECID.
  Boot sequence checks signature is for the correct ECID.
  Why does this help?
    Adversary unlikely to have a copy of the old software with victim's ECID.
    Apple update servers will not sign an old kernel once newer version exists.
    Adversary probably didn't know victim's ECID ahead of time, to request an
      update for that ECID.

===

Secure enclave.
  Manages keys for device unlock.
  Implemented using a separate CPU.
    Secure boot sequence, like the main CPU.
  Sort-of like SGX.
    Shares DRAM with the main CPU.
    Encrypts memory contents.
    Authenticates memory for integrity / freshness.
    Memory authentication state stored in on-chip SRAM.
      Not back in DRAM like SGX's EPC.
  Simpler than SGX.
    No dynamic enclave creation, no enclave enter / exit.
    Separate CPU, always running "enclave" code.

User authentication using the enclave.
  Goal: decrypt user data, allow user to access phone.
  Why offload authentication onto the secure enclave?
    Protect user fingerprint / facial data.
    Prevent OS kernel compromise from getting decryption keys.
    Prevent OS kernel compromise from bypassing retry limits.
    Prevent "take-apart-the-phone" attacks with memory encryption / auth.
      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, facial recognition.
    Secure enclave caches keys once user enters passcode.
    Will use these keys if presented with correct fingerprint or facial match.

Protecting sensor-to-enclave communication.
  OS kernel controls all devices, including fingerprint reader, camera, etc.
  Possible attack: compromised OS replays fingerprint reading to secure enclave.
  Alternatively: adversary takes apart phone, plugs in fake fingerprint reader.
  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 authenticates all data with the AES key.
    Some sensors (camera) encrypt data as well.
    Probably some nonce or session ID to prevent replay of old data.

Facial recognition (sort-of an aside, but surprisingly sophisticated)
  Special hardware for facial authentication: IR dot projector, IR camera.
  Many IR dots, in a randomly chosen pattern, are projected onto user's face.
  IR camera reads the dots, reports them to the secure enclave.
  Presumably secure enclave correlates IR camera dots with visible camera image.
  Might help defend against an adversary using a photograph of the user's face.

===

Data encryption.
  Attack: adversary takes apart the phone, reads data from flash chips.
  Plan: encrypt data stored on flash chips.

Why is this difficult?
  Strawman: "just" encrypt all data on flash.
  Where to store the key?
    OS kernel?  Does not defend against OS kernel compromise.
    Secure enclave?  Don't want secure enclave to be a performance bottleneck.
    Hard-wired AES circuit?  Does not defend against taking apart the phone.
    User passcode?  Can brute-force, but also can't use phone without passcode.

Important idea for key management: "key wrapping".
  E_k1(k2)
  Anyone that knows k1 can obtain k2, by decrypting.
  Delegation.

File encryption.
  Each file has a separate key for encrypting its data: Kf.
  Encrypt each file block separately, for efficiency.
  Concern: what if file has repeating patterns between blocks?
    Deterministic encryption would produce identical ciphertexts.
  Approach: "randomize" encryption of different file blocks.
    Encryption IV chosen based on block's offset within file.
  Another key to encrypt rest of file system metadata (directories, inodes, ...)
    Kfs.

Different levels of "data protection".
  Complete: can decrypt if phone is currently unlocked.
  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.
  No protection: can decrypt any time.

  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.
  File metadata stores 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.)
  Secure enclave will decrypt these wrapped keys, 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.

UID key: Kuid.
  Generated randomly for each device.
  Hard-wired into a separate AES engine in the secure enclave.
  Software cannot access key, can only encrypt/decrypt.

Data protection keys.
  For the "no protection" level, it's just Kuid.
    Or wrapped with it and stored somewhere in secure enclave's storage.
  For other levels, combination of user passcode and Kuid.
    Roughly, E_Kuid(E_Kuid(...(passcode))), with encryption repeated many times.
    Why this construction?
      Slow, to limit brute-forcing.
      Dependent on Kuid, to prevent brute-forcing outside of the device.
      Dependent on passcode, so key exists nowhere on device after reboot.

How to obtain data protection keys with Touch ID or Face ID?
  Seems like there's multiple processes on the secure enclave.
    Touch ID process, Face ID process, key manager process.
    Touch ID and Face ID processes have their own keys: Ktouch, Kface.
  Cannot use Touch ID / Face ID after reboot; must first enter passcode.
  When passcode is entered, key manager gets all the Kdp keys.
  Key manager wraps Kdp for later Touch ID / Face ID authentication:
    E_Ktouch(Kdp), E_Kface(Kdp)
    Sends them to the Touch ID / Face ID processes.
  When user locks phone, key manager deletes Kdp.
  But now can re-obtain keys with Touch ID / Face ID.

File system key: Kfs.
  Protected by Kuid: secure enclave stores E_Kuid(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_Kuid(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 typically does remapping 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_Kuid(Kfs).

===

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.