I’m not sure I’m there for the moralizing over Android security (but I see where it comes from.)
But if you’re trying to help a campaign lock itself down, that doesn’t matter; there’s a good reason we recommend iPhones, and a whole crowd of nerds loudly pretending otherwise.
Conversation
Replying to
Google’s encryption and security posture has been very far behind, and I think some of that represents past corporate priorities *as well* as the fact that they’re solving a hard problem. They have made some good hires recently though....
1
2
Replying to
I believe those gaps are due to the fact that what Google does has to cohere with 3rd party hardware vendors.
1
4
Replying to
For example, Google introduced file encryption but doesn’t have a “keys removed when phone locks” protection class. That’s not a hardware vendor issue.
2
3
10
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
Yes, profile switches kick out keys. But then apps can’t do background processing on anything. Which is normal for a profile switch.
This Tweet was deleted by the Tweet author. Learn more
He's talking about FBE keys, not the keystore. The keystore has offered functionality for protecting app data at rest for a while, not just with the new unlockedDeviceRequired API. Apps can protect data when locked via the keystore, but it's another layer of encryption on top.
1
They could have a similar set of 3-4 data classes for FBE like iOS instead of only 2. It requires layering on another layer of encryption via the keystore instead of switching the data class. iOS and Android have the same defaults for this, but iOS makes it easier to do better.
1
Aside from it being more of a hassle (i.e. bringing in a library or making custom code using the keystore), it's also not very efficient to be layering on another layer of encryption. It can also only be hardware accelerated via the CPU crypto instructions, not the crypto engine.