Supply-Chain Risk: App Signing Key Custody & Targeted Update Threat Model

[JMHBM]

Is there an existing request for feature?

• I have searched the existing issues

What feature would you like?

`Hello,

I’m writing as a privacy-focused researcher to raise a concern about a structural supply-chain risk that affects privacy-critical applications distributed through centralized app stores.

To be clear at the outset: I am not alleging malicious intent by any party, nor suggesting that abuse is occurring. This is strictly a threat-model discussion about capability and risk surface, not behavior.

The Issue: Developer Signing Key Custody

When an application’s signing keys are held or managed by a third-party distribution platform, a narrow but serious attack vector becomes possible: selective, targeted delivery of modified binaries to a very small subset of users, while the rest of the user base receives the standard, uncompromised build.

Because such binaries would be:

• correctly signed with the legitimate key
• delivered through the official update channel
• indistinguishable at the OS and store level

they would appear fully authentic to the device and to users.

Practical Limits of Hash Verification

In theory, users could verify binaries via cryptographic hashes. In practice, however:

• the overwhelming majority of users do not verify hashes on every update
• those who do typically compare against the hash provided by the same distribution platform
• independent cross-channel verification (e.g., GitHub vs. store vs. reproducible builds) is extremely rare in real-world usage

This creates a circular trust model where distribution, signing, and hash authority are consolidated. Even without any intent to misuse it, this consolidation weakens the absolute security guarantees expected of privacy-critical software.

Threat Model Implications

The concern is not mass compromise, but precision compromise — a model that modern threat actors and state-level adversaries already prefer.

From a user-trust and threat-model perspective, this leaves projects with a difficult but important choice:

• maintain maximum convenience at the cost of an expanded supply-chain trust boundary, or
• accept distribution inconvenience in order to preserve full cryptographic independence and eliminate this class of risk entirely

I believe users of privacy-focused software deserve transparency about this tradeoff, and projects deserve the opportunity to consciously choose where they stand.

I’m sharing this in good faith because your work matters, and because silent erosion of threat models is far more dangerous than open discussion.

Thank you for your time and for the work you do.

Respectfully,

JMHBM
jmhbm@duck.com
Signal: JMH_BM.01
Session: 05f5bce930e0a18e99d31ca4aba360bd4ef959f9633af0c3476fab674104a03000
`

Anything else?

No response

[KeeJef]

Thanks for prompting this discussion, you are correct that this is a real risk with the modern Google Play distribution model. Unfortunately, it's not something we can change retroactively without Google changing their app distribution policy.

From Session’s first release on Google Play, the app has been packaged and published as an Android App Bundle (AAB). Under Google Play’s rules, AAB distribution has always required enrollment in Play App Signing, with custody of the final signing key held by Google. Once this model is enabled for a Play app, it cannot be reverted, so this constraint applies to Session’s Play Store distribution going forward.

AABs do provide meaningful distribution benefits that are particularly relevant to many Session users, including significantly reduced update sizes via device-specific delivery. This is important for users in regions with limited bandwidth or unreliable connectivity.

Importantly, Session does not need to be installed from Google Play at all. There are multiple non-Play distribution methods for Session, including direct APK downloads via GitHub and the getsession.org website, an official Session F-Droid repository, and an unofficial build in the main F-Droid repository.

For these non-Play releases, independent verification is possible without relying on Play controlled keys. Hashes of all release artifacts are signed with a developer-controlled GPG key, allowing downloaded APKs to be hashed and validated directly against those signatures.

At the same time, it’s important to recognize that Google Play remains by far the dominant distribution channel on Android. Removing Session entirely from Google Play would significantly reduce its accessibility, and would likely result in a net loss of real-world privacy by limiting adoption of a privacy-preserving tool. Given these constraints, the approach Session has taken is to offer multiple distribution channels and allow users to choose the option that best aligns with their own threat model.

[JMHBM]

Thanks for the detailed and thoughtful response — I appreciate the clarity and candor.

I agree with your characterization of the current constraints around AAB + Play App Signing, and I think Session’s multi-channel distribution strategy is reasonable under today’s enforcement model. Where my concern sharpens is specifically around Android’s forward trajectory, not current behavior.

The core issue I’m trying to surface is that, on Android 13+ and beyond, the threat model is shifting from distribution trust to runtime legitimacy, via mechanisms like Remote Key Provisioning (RKP) and the Play Integrity API.

Right now, alternative distribution paths (GitHub APKs, F-Droid, etc.) remain viable because integrity signals are not yet universally binding. However, once integrity checks become mandatory or baseline across the ecosystem — which appears to be the direction Android is moving — the presence of an “official” Google Play build becomes a structural liability.

Specifically:

1. As long as a Play Store version exists, Google has a canonical reference artifact for the package name and version lineage.
2. Under strict integrity enforcement, sideloaded builds of the same package may fail integrity checks not because they are malformed or malicious, but because they are non-canonical — i.e., they do not match the Play-registered artifact.
3. In that scenario, alternative distribution paths become functionally second-class or non-viable on Android, regardless of developer-controlled signing, reproducible builds, or GPG-verified hashes.

This is why I raised the idea of Play Store removal before enforcement hardens. The intent isn’t purity or ideology, but to avoid being permanently anchored to a canonical Play artifact that future integrity policy may silently enforce against.

To be clear: I’m not claiming this is happening today, nor that Google is acting maliciously. I’m pointing out an asymmetry in reversibility:

• Adoption and accessibility can be rebuilt.
• Canonicalization under a mandatory integrity system is irreversable once fully enforced.

Session’s current approach is transparent and defensible under present conditions, and I appreciate that you explicitly acknowledge the risk rather than dismiss it. My concern is simply that once integrity enforcement crosses a certain threshold, the mitigation paths you describe may stop working in practice — and the failure mode will look like user error rather than policy.

I’m raising this in good faith, and I appreciate you engaging seriously with the discussion.

Also, Remote Key Provisioning (RKP) begins rolling out next month and is projected to be fully enforced globally by October this year.

This only affects Android. Sessoin on other devices remains perfectly fine. Although, with the recent news of Google integrating Gemini into the entire Apple Intelligence ecosystem, I'm sure it's only a matter of time before the iOS app becomes threatened as well.