4 ms·

Not to be the devil's advocate but how is just a signing key for an Android app/developer that is used for signing APKs and bundles comparable to "keys to your

Not to be the devil's advocate but how is just a signing key for an Android app/developer that is used for signing APKs and bundles comparable to "keys to your bank account"?

danpalmer 3y ago
It is not. Google signs the parts of the app because apps are no longer one single APK, they're a complex set of many parts that can be updated independently and in complex ways. The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient.
- RHSeeger 3y ago
  That being said, the signing key is supposed to be "we certify this". Handing your key over to a 3rd party defeats that. If both <software producer> and google need to be able to sign it in some way, then the signing process should be enhanced to represent that. Maybe the software producer signs their individual components, and google signs the bundle, or something like that.
  - danpalmer 3y ago
    I believe this is captured already – it's possible to verify that the binary was created by Google, but that it originated from the original developer.
  - rvnx 3y ago
    The key your describe, is the developer key, Google checks it. The key that VLC is talking about, is the distribution key. Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
  - wongarsu 3y ago
    Similar to how on Windows you sign both the installer and each binary that will be installed. In that setup it's trivial to have the binaries signed by one party, and the installer by another party.
  - Turing_Machine 3y ago
    > Handing your key over to a 3rd party defeats that. Hmm... if Google went rogue, wouldn't everyone's Android phone basically be pwnt whether they had some dev's signing key or not?
- treyd 3y ago
  That may be true but begs the questions: * Why should developers being forced to use more complex multi-part distribution methods if they don't want to? * Why can't developers handle signing the multi-part packages themselves if they're comfortable doing so? (instead of relying on Google)
  - sanitycheck 3y ago
    I've wondered this. For the apps I deal with, switching to AABs offered no benefit to anybody and a number of drawbacks to us. My usual theory about stuff coming out of Google is that there's a big incentive for changing stuff just to change stuff. Android seems to have become about as bad as JS is when it comes to the old "OK, let's try to get this 3-year-old app building with today's tooling" nightmare.
- Hizonner 3y ago
  > The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient. As a user, I expect that software I run is protected from tampering. ... and there's no reason, other than laziness and "we know better than you do", that you can't define a manifest/asset signing format that supports that and supports incremental distribution of apps and doesn't demand giving the authentication keys for every single app to the distribution point.
Aissen 3y ago
It's an over-simplification of course, and probably won't be true once proper attestations are in place. Problem: unless you're using GrapheneOS-style hardware attestations, the main attestation solution (Play Integrity) is signed by the same entity (Google) that signs the app bundles…
pwdisswordfishc 3y ago
Ever heard of banking apps?
- Aissen 3y ago
  Mandatory banking apps: https://lists.fsfe.org/pipermail/discussion/2024-February/013383.html https://lists.fsfe.org/pipermail/discussion/2024-February/01...
denysvitali 3y ago
No one explained it in any other comment (yet), so here is the idea: Google owns your bank's app signing key, which means that they can craft any update for your banking app in a way that it makes it leak the content of your application data. In the case of a bank, this might contain sensitive information: but not necessarily the password / token that is used to access your account as this might be stored in a more secure place like the HW-backed keystore. Nevertheless, if they have a way to modify your banking app binary without you noticing - they technically have access to your bank account (to the same level the app has). Would Google ever do this? Probably not, but the risk of a key compromise by a rogue employee is still there. Is this risk higher than your bank leaking the key? It depends, hopefully the person who has access to Google HSMs is not the same that has the rights to create a new release on the Google Play Store. The biggest issue I personally see is that we're putting so much trust in Google to basically control all of your apps - but that's sort of already happening on Android because people are generally running Google-flavored Android builds which have privileged Google Play Services.
- hbn 3y ago
  Can't any browser also access your banking info, steal your password, sessions, etc if you're logging into your bank's site with it? And Google already provides the default web browser for Android, the OS web view, and the most popular desktop browser in the world.

Not to be the devil's advocate but how is just a signing key for an Android app/developer that is used for signing APKs and bundles comparable to "keys to your bank account"?

danpalmer 3y ago

It is not. Google signs the parts of the app because apps are no longer one single APK, they're a complex set of many parts that can be updated independently and in complex ways. The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient.

RHSeeger 3y ago
That being said, the signing key is supposed to be "we certify this". Handing your key over to a 3rd party defeats that. If both <software producer> and google need to be able to sign it in some way, then the signing process should be enhanced to represent that. Maybe the software producer signs their individual components, and google signs the bundle, or something like that.
- danpalmer 3y ago
  I believe this is captured already – it's possible to verify that the binary was created by Google, but that it originated from the original developer.
- rvnx 3y ago
  The key your describe, is the developer key, Google checks it. The key that VLC is talking about, is the distribution key. Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
- wongarsu 3y ago
  Similar to how on Windows you sign both the installer and each binary that will be installed. In that setup it's trivial to have the binaries signed by one party, and the installer by another party.
- Turing_Machine 3y ago
  > Handing your key over to a 3rd party defeats that. Hmm... if Google went rogue, wouldn't everyone's Android phone basically be pwnt whether they had some dev's signing key or not?
treyd 3y ago
That may be true but begs the questions: * Why should developers being forced to use more complex multi-part distribution methods if they don't want to? * Why can't developers handle signing the multi-part packages themselves if they're comfortable doing so? (instead of relying on Google)
- sanitycheck 3y ago
  I've wondered this. For the apps I deal with, switching to AABs offered no benefit to anybody and a number of drawbacks to us. My usual theory about stuff coming out of Google is that there's a big incentive for changing stuff just to change stuff. Android seems to have become about as bad as JS is when it comes to the old "OK, let's try to get this 3-year-old app building with today's tooling" nightmare.
Hizonner 3y ago
> The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient. As a user, I expect that software I run is protected from tampering. ... and there's no reason, other than laziness and "we know better than you do", that you can't define a manifest/asset signing format that supports that and supports incremental distribution of apps and doesn't demand giving the authentication keys for every single app to the distribution point.

Aissen 3y ago

It's an over-simplification of course, and probably won't be true once proper attestations are in place. Problem: unless you're using GrapheneOS-style hardware attestations, the main attestation solution (Play Integrity) is signed by the same entity (Google) that signs the app bundles…

pwdisswordfishc 3y ago

Ever heard of banking apps?

Aissen 3y ago
Mandatory banking apps: https://lists.fsfe.org/pipermail/discussion/2024-February/013383.html https://lists.fsfe.org/pipermail/discussion/2024-February/01...

denysvitali 3y ago

No one explained it in any other comment (yet), so here is the idea: Google owns your bank's app signing key, which means that they can craft any update for your banking app in a way that it makes it leak the content of your application data. In the case of a bank, this might contain sensitive information: but not necessarily the password / token that is used to access your account as this might be stored in a more secure place like the HW-backed keystore. Nevertheless, if they have a way to modify your banking app binary without you noticing - they technically have access to your bank account (to the same level the app has). Would Google ever do this? Probably not, but the risk of a key compromise by a rogue employee is still there. Is this risk higher than your bank leaking the key? It depends, hopefully the person who has access to Google HSMs is not the same that has the rights to create a new release on the Google Play Store. The biggest issue I personally see is that we're putting so much trust in Google to basically control all of your apps - but that's sort of already happening on Android because people are generally running Google-flavored Android builds which have privileged Google Play Services.

hbn 3y ago
Can't any browser also access your banking info, steal your password, sessions, etc if you're logging into your bank's site with it? And Google already provides the default web browser for Android, the OS web view, and the most popular desktop browser in the world.