That's essentially how it works with many of the hardware security features on almost every single non-Pixel. It's mostly that they don't want to bother implementing them. Some devices had partially working verified boot for alternate OSes but it was insecure/broken.
Conversation
Samsung seems to be the only non-Pixel phone currently available with Weaver support (grapheneos.org/faq#encryption) which is one of the hardware security features we consider mandatory. Problem is that most devices have fallen literally years behind Pixels in a lot of security areas.
1
2
To sum up the importance of Weaver: on Samsung flagship or Pixel, a random 6 digit PIN gives you highly secure encryption that can only be bypassed by exploiting the secure element.
On nearly all other Android devices, 6 digit PIN is trivially bypassed. You just need OS exploit.
1
2
On other devices, you literally need a 7 diceware word passphrase (~90 bit entropy or higher) to have working encryption. That seems quite important for most users, and yet no one talks about it. There are many other examples. Most vendors really don't care about security.
1
2
You still ideally have a high entropy passphrase on a Pixel, but 6 digit random PIN does hold up to even sophisticated attackers unless they find a secure element exploit, which is increasingly hard, especially with Pixel 6 Titan M2 where ARM Cortex secure element was replaced.
1
2
Replying to
They don't even mention it as a recommendation:
source.android.com/compatibility/
The only thing they require is some kind of TEE integration which makes it so that brute force attacks can't be offloaded to a cluster but rather you need to do it on the device, unless you bypass this.
1
2
TEE hardware-bound key derivation integration helps to make a decent passphrase much more secure. It can't really increase the value of a random 6 digit PIN because it doesn't take long to iterate through all the possible values on the device despite key derivation work factor.
1
For Pixels, due to Weaver, the 2 most sensible choices are either a random 6 digit PIN (most people) or 7 random diceware words as a passphrase. Either you rely on the hardware security features or you don't.
1
1
If you use a typical weak/mediocre passphrase, the TEE hardware bound key derivation helps if they can exploit secure element but cannot extract the hardware bound key. It depends on how well that's implemented, the delay per attempt (perhaps ~50ms) and your passphrase quality.
1
Also worth noting: TEE hardware bound key derivation has often been incorrectly implemented where the TEE firmware has a key available that is leaked if you compromise the TEE. It's *supposed* to be burned in hw and not accessible to the firmware, just usable for AES or HMAC.
The concept is that the TEE is supposed to run thousands of iterations using a hardware provided crypto primitive like AES / HMAC where the key is burned into hardware. Qualcomm Crypto Engine has this feature but their TEE didn't used to actually use it for this key derivation.
1
1
CDD has absolutely no requirements for the implementation beyond the hardware keystore / TEE being integrated somehow. They could require that there is actual hardware bound key derivation and they could require secure element with Weaver, but there's no quality requirements.
1
Show replies