GrapheneOS 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.
I'm talking specifically about iOS here. iOS in contrast to Android has NSFileProtectionComplete. " Shortly after the user locks a device (10 seconds, if the Require Password setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks (logs in to) the device using Face ID or Touch ID." https://support.apple.com/guide/security/data-protection-classes-secb010e978a/web
What you're referring to is an AFU extraction. The difference between an AFU extraction and FFS extraction is that data protected by NSFileProtectionComplete such as keychain data is not available in AFU extraction on iOS. On Android, AFU and FFS are the same due to lack of NSFileProtectionComplete class keys and no secure element exploit is needed for AFU or FFS extraction.
Full File System (FFS) Extraction:
The most comprehensive type of extractions you can get on these devices.
Required to gain access to deeper information like health, Keychain data (on iOS), and location/breadcrumb data that shows where the device has been.
AFU Extraction:
On Android: Get the same data as a full file system extraction.
On iOS: Different levels of access depending on the device state can limit the information you can extract. (For example, Keychain, location data, and email accounts that may require passcode access)
https://cellebrite.com/en/episode-23-i-beg-to-dfir-data-extractions-explained-ffs-afu-bfu-advanced-logical-digital-forensics-webinar/
Furthermore, even with secure enclave code execution, the plaintext passcode shouldn't be recovered if Apple had implemented it correctly. Because only the passcode verifier value i.e hash of (passcode + salt) is saved by the Secure Storage Component. However, Cellebrite specifically claims they can get iPhone plaintext passcode, suggesting Secure Enclave RAM is not clearing iPhone passcode properly after user input. Please see Cellebrite's explanation of IPR IPR.jpg
GrapheneOS 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.
Please forgive my ignorance about how key derivation works on Android. All iOS data protection key derivation happens in secure enclave on iOS. You're saying on Android, the first part of key derivation happens on AP, then on TEE in Titan M2?
GrapheneOS 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.
You're right. Cellebrite claimed they can do FFS on pixel 8. They must have at least gained code execution on AP on AFU mode and used AP to communicate with Titan M2 to decrypt data if not code execution on Titan M2 itself, correct?
GrapheneOS 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.
Thank you informing me that Android is already implementing something similar
GrapheneOS 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.
According to you, even without setting any additional database password on Molly, AFU extraction will not yield the plaintext database? https://github.com/mollyim/mollyim-android/wiki/Data-Encryption-At-Rest Didn't say anything about this. Possible for @Nuttso to clarify?
GrapheneOS ndroid 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.
GrapheneOS 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.
I've read FAQ multiple times before posting. In fact, I specifically referred to the 5 failed attempts: 30 second delay in my original posting.
Let me rephrase my question to make it more concrete.
My question is, if secure enclave/Tian M2 is totally compromised with full code execution, and a brute force attack is performed on device, how long does it take to brute force a six-character alphanumeric passcode with lowercase letters and numbers?
Apple claims that The passcode or password is entangled with the device’s UID, so brute-force attempts must be performed on the device under attack. A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. In fact, it would take more than five and one-half years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers.
How long does it take for a pixel phone with standard os and graphene os respectively?
Keep in mind that the delay mentioned in FAQ reproduced below is all bypassed due to code execution on Titan M2
Standard delays for encryption key derivation enforced by the secure element:
0 to 4 failed attempts: no delay
5 failed attempts: 30 second delay
6 to 9 failed attempts: no delay
10 to 29 failed attempts: 30 second delay
30 to 139 failed attempts: 30 × 2⌊(n - 30) ÷ 10⌋ where n is the number of failed attempts. This means the delay doubles after every 10 attempts. There's a 30 second delay after 30 failed attempts, 60s after 40, 120s after 50, 240s after 60, 480s after 70, 960s after 80, 1920s after 90, 3840s after 100, 7680s after 110, 15360s after 120 and 30720s after 130
140 or more failed attempts: 86400 second delay (1 day)