The bounty money is quite good, too. Up to $250K for RCE in the Pixel TEE, and up to $1M for the Titan M. As the author of keymaster and owner of keystore attestation, I strongly encourage everyone to find the vulns and collect the bounties!
So we can fix the vulns, of course.
Conversation
If I'm not mistaken, Safetynet's security relies on all the ecosystem's TEE safety, not just Pixels. Once one is broken, everyone using Magisk (or whatever) can jump on this private key+fp. And from my lengthy experience, Android doesn't spend time towards its ecosystem's safety.
1
2
1
2
Of course, but will Google actually revoke them?
Say you have a security flaw in Qualcomm's bootloader, will Google revoke every single Qualcomm device?
When (not if.) that happen, will they close their money-maker Google Pay to 100M+ customers?
2
2
12
Yes, we will revoke them. If the keys are leaked, we'll revoke them. If the firmware has an unrecoverable flaw, we'll revoke them. If the firmware has a flaw that can be fixed via OTA, we'll analyze the situation to decide if that is adequate.
7
6
28
So, considering the current revocation list, you haven't found a single OEM who shipped devices without hardware secure boot in three years?
1
1
3
We don't test devices; the device makers run the tests and certify compliance. We effectively rely on the security research community to identify cheaters. Note that there have been a few revocations. I expect there are far more that need to be revoked, but don't know which.
4
1
11
Sorry, your answer isn't clear to me. In your answer, checking SoC's secure boot is done by "the tests"? If yes, which ones?
1
Of course tests can't check if the implementation is secure, only that it exhibits the expected functional behavior. There are non-functional requirements, too. Device makers effectively self-certify that they pass the tests and meet the untestable requirements.
1
5
It's not possible to write a test suite or list of requirements to impose upon other companies to force their software and hardware to be reasonably secure. They need to care about security themselves and put resources into it, beyond just complying with bare minimum standards.
Most OEMs are pretty stupid. But in a good way!
If CTS gets automatic testing of default bootrom for Qualcomm, Mediatek, Unisoc's OTPs (including detecting SoC default keys...), they'll probably check it. Issue is that it must be done not just in CTS, but also in production
1
2
CTS runs tests via apps and adb shell within the security model of the OS. It runs on a production build of the OS with the full security model intact and is very limited in how deeply it can probe and test. It can't peak behind the curtain and enforce implementation details.
1
3
Show replies
Expecting device makers to go beyond the minimum requirements is likely to result in disappointment. A few will do it, but most are operating on razor-thin margins and argue that their customers care more about lower prices than about better security, and they're mostly right.
2