4 ms·

The post title here should really be corrected. It's editorialized and is completely wrong. There is no 'Android platform signing key'. Android is not a single

by strcat 4y ago

The post title here should really be corrected. It's editorialized and is completely wrong. There is no 'Android platform signing key'. Android is not a single OS provided by Google. It's an OS family. Each OEM has their own OS and keys, often per device or device family. Several non-Google OEMs either got tricked into signing malware or had at least one of these keys (platform key) compromised. The issue is clearly marked as a partner issue discovered by their program for reporting issues to partners (non-Google Android OEMs). Google detected it and that's why it's on a Google issue tracker. Platform signing key is used to sign app-based components in the OS which are able to receive platform signature permissions, including some quite privileged access. Any app can define signature permissions. Platform signing key is the one used by the highly privileged app-based components of the platform itself, such as the Settings app. Platform key is only really meant to be used for first party code, normally all built with the OS but potentially updated outside it. It's not the verified boot key (avb key) or the key for signing over-the-air updates (releasekey by default but can be a dedicated key). There are also similar keys for several other groups of OS components with internal signature permissions (media, shared, etc.). All of these keys can be rotated, but aren't rotated in practice as part of the normal process of maintaining devices, partly because supporting phones for 5+ years is a recent development. The rotation that's done in practice is using a separate set of keys for each device / device family. For example, Google used new keys for each generation of Pixel phones and they currently use separate keys for separate device models although they've sometimes used the same keys for XL and non-XL variants in the same generation. Even the verified boot key for the stock OS could be rotated by firmware updates since they're all shipped with OS updates and it's completely normal to do breaking changes requiring both new firmware and new OS. It'd require adding code to handle the rotation in several places (TEE and secure element pin it and use it as a bonus input for key derivation, which would need to continue using the old value) along with breaking anything pinning the hash for attestation. Only the SoC firmware signing key and firmware for other secondary components with the key burned into the hardware can't be rotated.

dang 4y ago
Ok, we've changed the title to be that of the article. (Submitted title was "Android platform signing key compromised".)
strcat 4y ago
> Only the SoC firmware signing key and firmware for other secondary components with the key burned into the hardware can't be rotated. Side note: those components do have fuses burned via updates that are used to implement downgrade protection dynamically. In theory, they could provide key rotation support. That may make sense as device support gets longer than 5 years. They should also really support more downgrade protection counter increments than they currently do. Snapdragon used to support 16 increments (16 fuses) but I'm not sure what they support in current generation devices. They called it a '16 bit version number' but you can't unset a bit. OS downgrade protection is generally being done with special replay protected storage from the TEE (Pixel 2), the secure element (Pixel 3 and later) or simply by hard-wiring the version in firmware (very common approach before Android Verified Boot 2.0). It's a lot more flexible both in terms of being able to do key rotation in theory and not having any limit on # of updates. Pixels simply convert the Android / Pixel patch level such as 2022-11-05 into a Unix timestamp and that's the OS rollback counter stored in the secure element after successful boot. Happens alongside updating the firmware rollback counter, which rarely increases. Pixel 6 only bothered shipping the code to increment the firmware counter with Android 13 when they increased it. It's so uncommon that the external development community largely wasn't prepared to cope with it even though it should be done much more regularly.

by strcat 4y ago

dang 4y ago

Ok, we've changed the title to be that of the article. (Submitted title was "Android platform signing key compromised".)

strcat 4y ago

> Only the SoC firmware signing key and firmware for other secondary components with the key burned into the hardware can't be rotated. Side note: those components do have fuses burned via updates that are used to implement downgrade protection dynamically. In theory, they could provide key rotation support. That may make sense as device support gets longer than 5 years. They should also really support more downgrade protection counter increments than they currently do. Snapdragon used to support 16 increments (16 fuses) but I'm not sure what they support in current generation devices. They called it a '16 bit version number' but you can't unset a bit. OS downgrade protection is generally being done with special replay protected storage from the TEE (Pixel 2), the secure element (Pixel 3 and later) or simply by hard-wiring the version in firmware (very common approach before Android Verified Boot 2.0). It's a lot more flexible both in terms of being able to do key rotation in theory and not having any limit on # of updates. Pixels simply convert the Android / Pixel patch level such as 2022-11-05 into a Unix timestamp and that's the OS rollback counter stored in the secure element after successful boot. Happens alongside updating the firmware rollback counter, which rarely increases. Pixel 6 only bothered shipping the code to increment the firmware counter with Android 13 when they increased it. It's so uncommon that the external development community largely wasn't prepared to cope with it even though it should be done much more regularly.