4 ms·

I faced a similar issue: it seems like it has now become close to impossible to use your own signing / release key. My understanding is that Google really want

I faced a similar issue: it seems like it has now become close to impossible to use your own signing / release key. My understanding is that Google really wants to manage your keys so that you can't really mess up. If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss. I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, since at first install the apps trust whatever key you provide (and the only cross-check I'm aware of is, well, Play Protect, also owned by Google)

danpalmer 3y ago
> My understanding is that Google really wants to manage your keys so that you can't really mess up. It's not just this, apps are now delivered as many separate parts so that a device only gets what it needs. In the age of ARM/ARM64/x86, varying DPIs, different graphics abilities, etc, it can be easy for most users to not need most of an app. Google generates all these pieces from the "bundle", and picks optimal sets for each user/device. This could be potentially managed by users (it's all based on bundletool, an open source project), but there's a lot more on top of this, dynamic pieces that Google can generate on-demand for apps for various app health/security/product features. This only works if Google can sign the pieces.
- ndriscoll 3y ago
  If the distributor (Google) has the signing keys, why not just... not sign it? What does signing give you that TLS doesn't? Why can't Google sign the app with its own keys without the author having a say? The entire point of signatures is that users can trust their download is what the author published because they're the only one who could produce that signature.
  - Hizonner 3y ago
    > What does signing give you that TLS doesn't? A huge number of replicated servers have to have access to TLS keys, and a huge number of people have to be involved in the administration of those servers. And, to rely on TLS, you have to assure the integrity of the data within the whole store infrastructure, not just at the point that a file gets injected into it. The practical exposure is vastly worse than with end to end signing.
    - ndriscoll 3y ago
      I suppose that's fair. Still, can't the play store app just always accept a Google signed package (possibly from a root CA that doesn't get used for other purposes)?
  - denysvitali 3y ago
    If you don't have a way to validate the key ownership, you're at the same starting point: you have to trust Google
- Izkata 3y ago
  They also strongly recommend compatibility packages to handle different versions of Android (it's basically required to handle notifications), but those add a crazy amount of crap that doesn't get removed during the build, even if whole features are unused. It wouldn't surprise me if Google does remove those during their optimizations when they build it for you.
api 3y ago
Also means any user can be selectively targeted with a compromised app signed by the correct key. If you use pretty much anything other than Linux (and even that with care) there is a rather long list of people who effectively have root on all your stuff. Maybe this can’t be avoided. Economies and civilizations run on division of labor and interdependency. I just think it’s important that people understand this. Most people don’t and think they have far more digital security and privacy than they do.
- rvnx 3y ago
  Disabling auto-updates is a controversial but nice way to prevent backdoors from getting added, or for software to turn becoming malicious. For example, Chrome extensions, it's crazy that a random guy, can automatically update its piece of JS, just to steal all credentials, and there is no mechanism to disable that (or very well hidden) (like what happened with "The Great Suspender", though it was a great extension)
  - klooney 3y ago
    It's not clear that the vendors will respect that when the going gets tough, or that they don't have "no just force the update" channels. I think Apple has done that, for instance.
  - denysvitali 3y ago
    You can still remotely install apps with the Play services. This is effectively a RCE (if you have access to the target Google account)
Hizonner 3y ago
> My understanding is that Google really wants to manage your keys so that you can't really mess up. Instead, Google can really mess up. Which they will do somewhat less often than your average app developer, but when they do do it, it will break everything. > I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, [...] Only on new installs, which is a much smaller window than being able to change the app on every update. "Google" in the large, of course, also has a lot of paths to modify the OS and everything that's validating the signatures... but that's a different part of Google, and that risk does not justify this one.
Izkata 3y ago
> If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss. Half right: it means you can't publish updates under the same package name. They can continue using the old version, so it doesn't force any sort of data loss, but if they want to upgrade they have to find the new app, it won't be a reinstall-the-same-one situation.
- denysvitali 3y ago
  Yes, but that's basically migrating to a new app. This means that the new app can't access the /data/data part of the other app. This is of course not a huge deal for apps that are just wrappers of cloud services - but apps with local data will suffer the most.
  - prmoustache 3y ago
    Only apps with local data that don't propose a mechanism to export/backup. I don't know many of them as this would be stupid.

danpalmer 3y ago

> My understanding is that Google really wants to manage your keys so that you can't really mess up. It's not just this, apps are now delivered as many separate parts so that a device only gets what it needs. In the age of ARM/ARM64/x86, varying DPIs, different graphics abilities, etc, it can be easy for most users to not need most of an app. Google generates all these pieces from the "bundle", and picks optimal sets for each user/device. This could be potentially managed by users (it's all based on bundletool, an open source project), but there's a lot more on top of this, dynamic pieces that Google can generate on-demand for apps for various app health/security/product features. This only works if Google can sign the pieces.

ndriscoll 3y ago
If the distributor (Google) has the signing keys, why not just... not sign it? What does signing give you that TLS doesn't? Why can't Google sign the app with its own keys without the author having a say? The entire point of signatures is that users can trust their download is what the author published because they're the only one who could produce that signature.
- Hizonner 3y ago
  > What does signing give you that TLS doesn't? A huge number of replicated servers have to have access to TLS keys, and a huge number of people have to be involved in the administration of those servers. And, to rely on TLS, you have to assure the integrity of the data within the whole store infrastructure, not just at the point that a file gets injected into it. The practical exposure is vastly worse than with end to end signing.
  - ndriscoll 3y ago
    I suppose that's fair. Still, can't the play store app just always accept a Google signed package (possibly from a root CA that doesn't get used for other purposes)?
- denysvitali 3y ago
  If you don't have a way to validate the key ownership, you're at the same starting point: you have to trust Google
Izkata 3y ago
They also strongly recommend compatibility packages to handle different versions of Android (it's basically required to handle notifications), but those add a crazy amount of crap that doesn't get removed during the build, even if whole features are unused. It wouldn't surprise me if Google does remove those during their optimizations when they build it for you.

api 3y ago

Also means any user can be selectively targeted with a compromised app signed by the correct key. If you use pretty much anything other than Linux (and even that with care) there is a rather long list of people who effectively have root on all your stuff. Maybe this can’t be avoided. Economies and civilizations run on division of labor and interdependency. I just think it’s important that people understand this. Most people don’t and think they have far more digital security and privacy than they do.

rvnx 3y ago
Disabling auto-updates is a controversial but nice way to prevent backdoors from getting added, or for software to turn becoming malicious. For example, Chrome extensions, it's crazy that a random guy, can automatically update its piece of JS, just to steal all credentials, and there is no mechanism to disable that (or very well hidden) (like what happened with "The Great Suspender", though it was a great extension)
- klooney 3y ago
  It's not clear that the vendors will respect that when the going gets tough, or that they don't have "no just force the update" channels. I think Apple has done that, for instance.
- denysvitali 3y ago
  You can still remotely install apps with the Play services. This is effectively a RCE (if you have access to the target Google account)

Hizonner 3y ago

> My understanding is that Google really wants to manage your keys so that you can't really mess up. Instead, Google can really mess up. Which they will do somewhat less often than your average app developer, but when they do do it, it will break everything. > I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, [...] Only on new installs, which is a much smaller window than being able to change the app on every update. "Google" in the large, of course, also has a lot of paths to modify the OS and everything that's validating the signatures... but that's a different part of Google, and that risk does not justify this one.

Izkata 3y ago

> If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss. Half right: it means you can't publish updates under the same package name. They can continue using the old version, so it doesn't force any sort of data loss, but if they want to upgrade they have to find the new app, it won't be a reinstall-the-same-one situation.

denysvitali 3y ago
Yes, but that's basically migrating to a new app. This means that the new app can't access the /data/data part of the other app. This is of course not a huge deal for apps that are just wrappers of cloud services - but apps with local data will suffer the most.
- prmoustache 3y ago
  Only apps with local data that don't propose a mechanism to export/backup. I don't know many of them as this would be stupid.