Open List of Requested iOS Security Improvements

Secure Enclave

  1. Lock the SEP, so that it doesn’t allow flashing until it is first unlocked with passcode; keep the SEP storage (except for fail register) in read-only mode until unlocked.
  2. Lock 2nd stage boot loader so that it won’t load anything (an IPSW, or even the device’s operating system) until the SEP is unlocked with passcode. This effectively creates a boot password; this boot password could/should theoretically be longer and more complex than a UI pin, perhaps user-configurable.
  3. Move the wipe-on-fail into the enclave, and just set it with a flag passed to the enclave by the OS’ settings app.
  4. Split the enclave into two segments and place the backoff/wipe code into ROM so that it cannot be flashed. The basic functionality of the entanglement process should be sufficiently stable by now to commit to silicon.


  1. Modify DFU mode to be destructive so it drops the device’s keys before it loads an image, unless first unlocked with a user pin; if this is truly supposed to be a last resort, it should refuse to recover the system without authentication from the user. This would likely only be something possible in future hardware revisions.
  2. Encrypt the OS partition using DKEY, and encrypt DKEY with a key stored in the SEP, so the OS can’t be mounted without the passcode, even by a RAM disk or hardware method. This will prevent direct software modifications without the user’s passcode.
  3. Encrypt the KBAG with a key in the enclave derived from the boot password, to prevent the keychain from being unlocked without it. This enforces the boot password logic.


  1. Verify the write state of the NAND when performing any authentication operations; if the NAND is write blocked then all SEP auth should fail, otherwise this could be a sign of tampering to prevent wipe.
  2. Verify the IC’s serial number and geometry (in the FTL maybe?) to prevent the NAND from being swapped out easily.

OS Integrity

  1. Automatically lock the entire key bag when the fingerprint timer expires (48 hours, though that might should be configurable to be less); this would shut down NSProtection class for first user authentication while the phone remains dormant, effectively locking the crypto before the device is shutdown.
  2. Attempt to detect clock tampering, which at the moment may affect the backoff.


  1. Encrypt all data backed up to the iCloud with keys derived from the user’s alphanumeric backup password. Use a very high iteration count to help thwart brute force / dictionary attacks.


  1. Give the user the option to “set a password” to allow the desktop to connect to the device; in reality, this password will be used to derive a key that encrypts the pair record on the desktop, so that a stolen/compromised desktop computer cannot be used to access the device without a password.