Android app signing in practice
Why the most-installed apps on Play carry the weakest signing keys — and why the SHA-1 and MD5 certificates in the same corpus are not the problem they look like.
Published 2026-10-21 · apk-scanner.com research
Historical snapshot · 2026-10-21. Figures and checks describe the published study, not current exposure. Verification applies to the date the check ran. Current methodology
What this measures
Every APK on Google Play is signed, and Android decides whether an update is genuine by comparing the new package’s signer against the signer of the copy already installed. There is no certificate authority in that decision: the platform pins the exact public key and refuses an update signed by anything else. That single design choice is what makes app signing worth studying as a population, because it means a signing key is close to permanent — and the key an app carries today records the defaults of the year it was minted, not the defaults of today.
This study reads the signing block of the most recent public scan of each app in the corpus: 6,731 apps, counted live. It reports what the certificate and signature blocks contain. It does not evaluate how a key is stored, who controls it, or whether a developer has ever lost one — none of which an APK can show.
The finding: 1024-bit keys, concentrated in the largest apps
1,038 apps (15.4%) are signed with a 1024-bit RSA key. That size has been below public guidance for over a decade; NIST disallowed it for new signatures from 2014. It is the one number here that describes a real weakness, because forging an update means possessing or deriving the private key, and 1024-bit RSA is the size at which deriving it stops being unthinkable for a well-funded attacker.
The distribution is the interesting part. Among apps with 100 million or more installs, 173 of 495 (34.9%) use a 1024-bit key — 2.3× their share of the corpus as a whole. Widening to 10 million installs and above: 542 of 1,803. The pattern runs opposite to intuition. The apps with the most users to protect are the ones most likely to be protected by the weakest key.
Why the biggest apps have the oldest keys
Install counts accumulate, so a very large install base is mostly evidence of age, and age is what decides key size. Measured against the year each certificate became valid:
| Key size | Apps | Certificate years | Mean year |
|---|---|---|---|
| 1,024-bit RSA | 1,038 | 2008–2021 | 2012 |
| 2,048-bit RSA | 2,055 | 2008–2026 | 2016 |
| 4,096-bit RSA | 3,558 | 2009–2026 | 2022 |
New 1024-bit keys have effectively stopped appearing, while recent certificates are almost entirely 4096-bit. This is consistent with Play App Signing, which Google has required for new apps since August 2021 and under which the app signing key is generated by Google rather than by the developer: it replaces a per-developer choice with one policy. The corpus cannot confirm that mechanism — an APK does not say who generated its key — but the timing matches, and the uniformity of recent keys is hard to explain as thousands of independent decisions.
Signature Scheme v3 (Android 9 and later) does provide a rotation path, through a proof-of-rotation lineage that lets an app move to a new key while remaining verifiable. 6,283 apps here carry a v3 block, so the mechanism is widely available. The 1024-bit population shows it is also largely unused. Rotation is an option these apps have, not a constraint they are under.
What looks alarming here and is not
1,525 apps have a certificate whose own signature uses SHA-1, and 89 use MD5. Read quickly, that sounds like 1,614 apps relying on broken hashes. It is not, and the reason is the design described at the top: Android does not validate a certificate chain for app signing, so a certificate’s self-signature is never checked as a trust statement. Breaking that hash would let an attacker produce a different certificate, not a different app signature, and the platform compares the key — not the certificate’s paperwork. The APK signature itself is covered by the scheme version, which is where SHA-256 does the work.
This project has acted on that distinction before: a check that flagged weak certificate self-signature algorithms was retired, because it generated a finding that implied a risk the platform does not carry. The figures are published here as a description of the ecosystem, not as a defect count.
Similarly, 6,701 of 6,731 certificates are self-signed (99.6%). For Android that is the normal and expected case, not a finding. A CA-issued certificate would buy an app nothing, because no CA is consulted.
What is reassuringly absent
Three failure modes that would be serious do not appear in this corpus: 0 apps are signed with the v1 (JAR) scheme alone, which is the configuration the Janus vulnerability needed; 0 ship an expired certificate; and 0 are signed with a debug key. 6,714 apps carry a v2 block and 6,283 a v3 block. Store-level requirements appear to be doing their job here, and a study that only reported weaknesses would have hidden that.
One key, several developer names
58 signing keys in the corpus are shared by apps published under more
than one developer name, covering 220 apps, with the largest single group
at 23 apps. A shared key means those apps are, to Android, the same
signer: they can be granted signature-level permissions in one another and can
update one another’s installed copies.
What this does not establish is why. A publisher renaming itself, a studio shipping under several labels, an acquisition, and a white-label build service all produce the same observation, and the store listing is not enough to separate them. It is recorded here because a reviewer evaluating one app in such a group should know the boundary is shared.
Method and limits
One scan per app, the most recent public one, read from its recorded signing block. Counts move as the crawler re-scans, so they are computed when this page is served rather than written into the text.
- v4 signatures are out of scope by construction. A v4 signature lives in
a separate
.idsigfile alongside the APK, not inside it, so its absence here says nothing about v4 adoption. - 74 apps use DSA keys, for which no key size is recorded; they sit outside the RSA size breakdown rather than being counted as strong or weak. 6 apps report an RSA size other than 1024, 2048 or 4096, including a few non-standard values that look like generation artefacts.
- Install figures are Play’s lower-bound buckets (“1,000,000+”), so tiers are counts of apps in a bucket, never a sum of users.
- A certificate’s validity start is when the key was minted, which under Play App Signing is when Google created it — not when the developer first shipped. It is a good proxy for key vintage and a poor one for app age.
- This describes signing only. It is not a judgement about any named app, and a weak signing key is not evidence that an app has been tampered with.
Per-app signing details appear on each report under its evidence sections; see how scanning works and evidence limits.