Secure Enclave
- 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.
- 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.
- Move the wipe-on-fail into the enclave, and just set it with a flag passed to the enclave by the OS’ settings app.
- 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.
Device
- 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.
- 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.
- 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.
NAND
- 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.
- Verify the IC’s serial number and geometry (in the FTL maybe?) to prevent the NAND from being swapped out easily.
OS Integrity
- 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.
- Attempt to detect clock tampering, which at the moment may affect the backoff.
iCloud
- 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.
Desktop
- 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.