Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

1: Hopefully the delay was so the device updates with time-based activation triggers would shut out the bad actor in as many places as possible at once.

2: I don't see any reason to share the master key with an OEM, the master key could be used to sign certificates down-chain but they should never share it.

This leaves 2 options:

- Google had waaay too sloppy key management (sitting on servers or even possibly developer laptops)

- Google had proper management by putting the keys on HSMs or some virtual HSM with multi-party activation, unless there was weaknesses in the HSMs(or the virtual HSM OS) then yes, some person(s) would've gained physical access to extract it.

3: Universal 2nd stage rootkit?



These aren't Google's keys. They are vendor-specific keys (e.g. Samsung's) used to sign their releases.


The bug doesn't mention any vendor, rather the bug specifies "Partner-Multiple", seen reports elsewhere that points to a particular vendor?


It's not hard to figure out which vendors are affected. Just search for the SHA256 hash of each malware sample on VirusTotal.

eg. https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7d...


Search google for the certificate SHAs. Most don't result in anything but this report, but one is for Samsung and another for LG.


Google isn't at fault, their certs weren't leaked (as far as we know).


Why would Google have these keys?


(posterity) Sure the primary OS/Bootloader key probably falls under vendors, but wasn't much of the core systems (phone, play, browser,etc) moved to be under Googles control due to the vendors being sloppy with providing updates for devices in the olden days? (And as such this key would be the thing that the os/loader grants privilegies to).

Edit: Noticed the comment about them being lowend(mediatek?) certificates.


My understanding is that with v3 google started requiring that app developers send their private keys to google, as a requirement for inclusion in the play store (using the 'Play Encrypt Private Key (PEPK) tool').

In light of that I guess it wouldn't be shocking if there were similar requirements for vendor's platform keys.


This is about non-Google OEM OS signing keys.

v1/v2/v3 APK signing has nothing to do with the Play Store requiring Play Signing for newly published apps. App bundles / split APKs also don't inherently have to be used the way they're using them. Entirely possible to use them outside the Play Store with your own signing keys. v3 signing is just v2 with key rotation support. v2 is proper whole file signing instead of v1 which was just the flawed JAR signing system.


Platform keys are only required to be v2, as far as my understanding goes.


Yeah that's the minimum since Android 11 for system apps targeting API level 30+.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: