Apps with signing-metadata findings

What this finding means

Every Android app is signed, and the signature is what ties an update to the app it updates. This category covers properties of that signature which weaken the guarantee: a short key, a debug key, an expired certificate, or reliance on the original v1 JAR signing scheme alone.

We have recorded one of these in 1,009 apps, and all of them are the same property: an RSA key of 1024 bits. The debug-key, expired-certificate and v1-only checks are live and currently match nothing in this corpus.

Why key length is the one that matters here

A 1024-bit RSA key is below every current recommendation and has been deprecated across the industry for over a decade. The practical consequence is about longevity rather than an immediate break: a signing key has to resist attack for as long as the app exists, because whoever can forge the signature can ship an update your users will install.

It is also the hardest of these to fix, which is why it persists. The signing identity cannot simply be replaced; an app signed with a new key is, to Android, a different app. Play App Signing with key rotation is the route through, and it needs planning rather than a build-file change.

A note on something we used to report and no longer do. We previously flagged the algorithm a signing certificate used to sign itself, typically SHA-1. Android pins a signer by the certificate's exact bytes rather than by validating that self-signature, and the v2 and v3 schemes digest the APK with SHA-256 or SHA-512 regardless, so on a self-signed certificate that value is inert. Every app we had flagged already satisfied the remediation we were giving them, so the check was retired and the corpus regraded.

How to fix it

• Enrol in Play App Signing, which lets Google hold a strong app signing key while you rotate your upload key independently.
• Generate new keys as RSA 4096 or EC P-256, and keep them in a hardware-backed store or a KMS rather than a file on a laptop.
• Make sure v2 and v3 signature blocks are present; v1 alone leaves the APK open to tampering tricks the later schemes close.
• Check the signature of the artifact you actually ship, in CI, so a local keystore cannot end up signing a release.
• Treat expiry as a real deadline: a certificate must outlive the app, and Play requires validity well into the future.

How we detect it

Signature blocks and certificates are read from the APK with a parser written for this purpose, which reports the schemes present, the key type and size, and the validity window. No network lookup is involved and nothing about the signature is inferred.