[deleted]
Secure Enclave RAM is not clearing iPhone passcode properly after user input. Theoretically, as soon as the Secure Enclave derives KEK, the plaintext iPhone passcode should be wiped from Secure Enclave RAM immediately and renders IPR cryptographically not possible. Can someone file a security report with Apple security?
The conclusion you're drawing from this information is wrong. The OS implements the lockscreen and no issues with the secure element are needed for data to persist in the OS and be obtained via an OS exploit. They do appear to have secure enclave exploits but that's not an inherent requirement for this capability.
Cellbrite can dump Secure Enclave RAM since A11.
They can likely get code execution on it rather than only dumping the memory, but it's not implied by that capability. It would be unusual if they could dump the memory without getting code execution.
Titian M2 on pixel seems to prevent such code execution or memory dump for now. However, can we be sure that the pixel passcode is cleared by Titan M2 RAM after authentication?
That's not how encryption works on Pixels and isn't how the secure element is integrated. It doesn't have access to the lock method but rather receives a key derived by the OS from the initial key derived via scrypt from the lock method. The final key derivation happens in the TEE via a hardware-bound algorithm.
Furthermore, Android security model exposes all cryptographic key in AP RAM even in AFU mode. This renders memory dump on Titan M2 RAM unnecessary because AP RAM dump is enough for all user data. Is it possible to implement NSFileProtectionComplete keys in graphene os such that specific applications can opt in to use such keys to make data cryptographically inaccessible in AFU mode?
That's not how encryption works on Pixels. The keys aren't available to the OS or in regular memory. You're missing that the SoC provides hardware encryption features, not only the secure element. Wrapped keys are used for disk encryption rather than them being in regular memory or accessible to the OS at any point.
Android already does provide apps with the ability to keep data at rest while the locked is locked. You've been misinformed about this. Android does not yet have a data class for keeping data at rest when locked but that doesn't mean it isn't a supported feature already. It can be done via the hardware keystore. Android is in the process of adding a data class for this purpose to make it more efficient and easier to implement. It would serve no purpose for GrapheneOS to add an API that's not actually going to be used by apps, and we'd be stuck maintaining that forever instead of using the upcoming standard implementation. It's already possible for apps to keep data at rest while the device is locked via the keystore APIs across Android, so it's highly unlikely they would use a GrapheneOS specific API. It's not a realistic approach to improving things. If app developers cared about this, they'd already be keeping data at rest while locked but they aren't doing it on Android or iOS in general. That iOS feature is hardly used and the harder to use Android feature is actually used more broadly due to apps like Molly... showing that making this easier and more efficient is not everything.
When IPR makes this point almost irrelevant, iPhone Supersonic BF is still limited by Secure Enclave Processor's power. "The iteration count is calibrated so that one attempt takes approximately 80 milliseconds." Such 80ms delay is enforced by cryptography and cannot be bypassed by gaining code execution on secure enclave and can only be bypassed by extracting UID physically from the fuses of the SoC.
Android has hardware-bound key derivation too. You should really read our encryption FAQ. Such a short delay makes no difference with the typical lock methods that are being used. It only helps with a decent passphrase, which few people use, and the few people that do are likely using fingerprint unlock to make it more convenient which is a major weakness.
What's the iteration count and the cryptography delay of passcode derivation on Titan M2 used by graphene os? The standard delay (5 failed attempts: 30 second delay, etc) is enforced by Titan M2 and can be bypassed once code execution is obtained on the Titan M2
That's not how the encryption is implemented. Hardware-bound key derivation happens on the SoC from the TEE. With a random 6-8 digit PIN, the key derivation work factor from scrypt in the OS and hardware-bound key derivation in the TEE doesn't make it secure. It requires a passphrase with more entropy to truly work. The hardware-bound aspect can only be bypassed through extracting the key from the hardware if it's correctly implemented and cannot be obtained through TEE code execution.