4 ms·
>My understanding is that these certs are vendor-specific (and potentially more finely grained than that - I think it'd be fine to have a separate cert per mode
by MishaalRahman 4y ago
>My understanding is that these certs are vendor-specific (and potentially more finely grained than that - I think it'd be fine to have a separate cert per model, for instance) and are rooted in the firmware, not the hardware - that is, it's not the secure boot signing key, and a new firmware update can simply use a different platform certificate.
Correct, affected OEMs can still rotate the cert used to sign their system apps and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert.
However, V2 versus V3 signatures complicate things a bit, I think.
- flatiron 4y agoI assume that the level that the malware is running at couldn’t simply modify the OTA file and inject itself back in?
- saagarjha 4y agoPotentially but then you get into “reflections on trusting trust” type attacks, which are pretty hard to sustain.
- MishaalRahman 4y agoAccording to the OP of the report, the key used to sign an OTA image and the key used to sign system apps are different.
- saagarjha 4y agoI believe the author of this report and the discoverer are different people.
- MishaalRahman 4y agoOh yeah, that's true. Here's who I was citing then: https://twitter.com/maldr0id/status/1598467755887529990 https://twitter.com/maldr0id/status/1598467755887529990
- ShredKazoo 4y agoIf your device is rooted, it seems like maybe the malware could change the key used to verify the OTA update to a key controlled by the malware authors? (I don't know how that key is stored.)
- Sirened 4y agoYes but actually no. While they may be able to install a bogus update, unless they also compromised the keys for verified boot the system won't boot if they change anything interesting as AVB has a hardware root of trust (typically).
- strcat 4y agoYou can freely update from a v2 signature to a v3 signature. If the minimum SDK version is below when v2 was introduced, Android will include both a v1 and v2 signature by default. If the minimum SDK version is above when v2 was introduced but below when v3 was introduced, Android will only include a v2 signature by default. It will only include a v3 signature by default if the minimum SDK version is above when v3 was introduced, which is rare. The reason it works this way is because v2 was a significant security upgrade over v1 but v3 is just v2 with rotation support. If you do a key rotation, you get a v3 signature included to handle it for versions with key rotation support. If you support older versions, the users on those versions are still relying on the original keys. This is transparently supported in a way that it's backwards compatible. It would simply waste space to include v2 + v3 when no rotation has happened yet. I don't know why they bothered to micro-optimize to this extent but they did. For some reason the Play Store doesn't make use of Android's support for key rotations yet. They only support key rotations with Play Signing since they're phasing out non-Play-signed apps. If you switch from non-Play-signed to Play Signing, they keep signing the app for existing installs with the old key but switch to a new key for fresh installs. They do the same thing if you trigger a key rotation with the UI. They could rotate the key for existing users on Android versions with v3 support. They might as well rotate it even for users on versions predating it, since if they did get an OS upgrade it will start working right away.