What Is the Secure Enclave?
Each iOS CPU is built with a 256-bit unique identifier or UID. This UID is burned into the hardware and not stored anywhere else. The UID is not only inaccessible to the outside world, but it’s inaccessible even to the software running at the highest privilege levels on the CPU. Instead, the CPU contains a hardware AES encryption engine, and the only way the UID can be accessed by the hardware is by loading it into the AES engine as a key and using it to encrypt or decrypt data.
Apple uses this hardware to entangle the user’s passcode with the device. By setting the device’s UID as the AES key and then encrypting the passcode, the result is a random-looking bunch of data which can’t be recreated anywhere else, since it depends on both the user’s passcode and the secret, unreadable, device-specific UID.
[…]
The Secure Enclave contains its own UID and hardware AES engine. The passcode verification process takes place here, separated from the rest of the system.
[…]
The escalating delays for failed passcode attempts are enforced by the Secure Enclave. The main CPU merely submits passcodes and receives the results. The Secure Enclave performs the checks, and if there have been too many failures it will delay performing those checks. The main CPU can’t speed things along.
[…]
This would be fairly easy to implement, and shouldn’t affect the usability of the device. Given Apple’s public stance on user privacy, I would find it extremely weird if it the Secure Enclave’s software update mechanism wasn’t implemented in this way. On the other hand, Tim Cook’s public letter implies that all iPhone models are potentially vulnerable, so perhaps they haven’t taken this extra step.
Previously: FBI Asks Apple for Secure Golden Key.
