3 ms·
Interesting. What's your source? Apple's whitepaper suggests otherwise, to my reading: "The device’s unique ID (UID) and a device group ID (GID) are AES 256-bi
by abalone 11y ago
Interesting. What's your source? Apple's whitepaper suggests otherwise, to my reading:
"The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing."[1]
What this says to me is that while rewritable data storage is indeed kept in regular commodity flash memory chips, it's all encrypted by a unique device-specific key that is somehow burned into the secure enclave. So that one little secret kept inside the enclave would allow it to store everything else off-chip.
[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf
- makomk 11y agoThat unique device-specific key provides no protection against replay attacks. So in practice, the newer Apple devices don't appear to provide any more protection against an attacker with physical access than the one that the FBI just cracked - they should be able to get everything they were demanding in their warrant without Apple's help on any iPhone.
- abalone 11y agoMaybe I don't understand what you mean by "replay attack" in this context, but the secure enclave does in fact provide protection against brute forcing passcodes. It is detailed in Apple's security whitepaper (see p12). Basically, you have to give the passcode to the secure enclave to get the data decryption key which is derived from the device-specific key contained therein. And the enclave enforces time delays between wrong guesses. If you can envision a procedure for hacking around this I would love to hear it.