Device hardware, firmware, and software are integrated to protect your most sensitive data from mobile threats. With Moto KeySafe, PINs, passwords, and cryptographic keys are isolated from other device data for an added layer of high-level security.
It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.
It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.
Are you sure there’s no rate limiting? My phone definitely does rate limit the on-boot disk decryption prompt. Do you mean there’s no rate limiting if someone detaches the NAND and brute-forces it off-device?
That rate limiting can easily be bypassed by an attacker. In order to be effective, the rate limit needs to be enforced by tamper-resistant hardware, i.e. a secure element. Here are some of the requirements for a secure element: https://developer.android.com/privacy-and-security/keystore#StrongBoxKeyMint
An implementation of StrongBox KeyMint must contain the following:
Its own CPU
Secure storage
A true random-number generator
Additional mechanisms to resist package tampering and unauthorized sideloading of apps
A secure timer
A reboot notification pin (or equivalent), like general-purpose input/output (GPIO)
Only devices with a proper implementation of a secure element (Titan M2, i.e. Pixel 6 or later, or the Apple SEP, i.e. iPhone 12 or later) are actually resistant to brute-force attacks by forensic data extraction tools, such as Cellebrite or GrayKey. GrapheneOS has obtained some internal documents from multiple forensics companies. They published the Cellebrite docs at https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation
Specifically, I recommend looking at this chart:
It clearly shows that data cannot be extracted from iPhones with the SEP, unless the device is in the AFU state, meaning that the encryption keys are kept in memory.
Yeah this sounds like what Graphene insists on.
That sounds like a fancy speak for a Trusted Platform Module. Isn’t some kind of TPM mandatory to obtain a google certification for a new device?
It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.
Yeah, a TPM or secure element. I don’t think it’s required.
It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.
Are you sure there’s no rate limiting? My phone definitely does rate limit the on-boot disk decryption prompt. Do you mean there’s no rate limiting if someone detaches the NAND and brute-forces it off-device?
That rate limiting can easily be bypassed by an attacker. In order to be effective, the rate limit needs to be enforced by tamper-resistant hardware, i.e. a secure element. Here are some of the requirements for a secure element: https://developer.android.com/privacy-and-security/keystore#StrongBoxKeyMint
For details, I recommend reading:
Only devices with a proper implementation of a secure element (Titan M2, i.e. Pixel 6 or later, or the Apple SEP, i.e. iPhone 12 or later) are actually resistant to brute-force attacks by forensic data extraction tools, such as Cellebrite or GrayKey. GrapheneOS has obtained some internal documents from multiple forensics companies. They published the Cellebrite docs at https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation
Specifically, I recommend looking at this chart:
It clearly shows that data cannot be extracted from iPhones with the SEP, unless the device is in the AFU state, meaning that the encryption keys are kept in memory.
Those are the charts for Pixels: