Academic Paper: Feng, J. (2026). Broken By Design: A Longitudinal Analysis of Cryptographic Failures in Alipay Mobile Payment Infrastructure. IACR Cryptology ePrint Archive, Report 2026/526.

Broken By Design: Why One of the World's Largest Payment Apps Still Runs on Crypto from 2004

By Jiqiang Feng, Innora AI Security Research Lab — March 2026

The Question That Started Everything

What happens when one of the largest payment applications — serving over 1 billion users — signs its APK with cryptography that was deprecated before the iPhone existed?

That question led us down a 6-week research path that uncovered a systematic pattern of cryptographic failures in Alipay's mobile payment infrastructure — not theoretical weaknesses, but practical, reproducible attacks backed by 15 proof-of-concept demonstrations and an academic preprint published on IACR ePrint.

What We Found

Alipay's APK signing certificate was issued on December 16, 2009 using md5WithRSAEncryption with a 1024-bit RSA key. To put this in context:

• MD5 collisions had been demonstrated since 2004 — five years before this certificate was issued
• RSA-1024 was formally deprecated by NIST in 2013
• The certificate is valid until 2051 — 42 more years of accumulated risk

This isn't a subtle vulnerability. It's a foundational architectural decision that compounds every year it remains unaddressed.

The Numbers

| Finding | Impact | |---------|--------| | MD5 identical-prefix collision | Reproducible in 9 seconds via FastColl (Stevens, 2006) | | RSA-1024 factoring | Estimated cost: $50K–$100K via Number Field Sieve | | Hardcoded DES keys | Zero entropy — plaintext ASCII strings in the binary | | Batch GCD factoring | 28 RSA private keys recovered from public certificate data | | SHA-1 collision | Projected cost in 2026: $5,000–$8,000 | | APK v1 signature bypass | 5 distinct attack vectors exclusive to v1-only signing |

Why This Matters Beyond Alipay

Our analysis didn't stop at Alipay's certificate. We collected 123 APK signing certificates from major mobile applications and ran a Batch GCD analysis (following Heninger et al., 2012). The results were startling:

• 28 TLS server keys (not APK signing keys) were fully factored from public certificate data — no shared primes were found among the 123 APK signing certificates themselves
• 8 shared prime factors were found across independent keys
• 5 key reuse groups indicated systemic PRNG weakness across the ecosystem

This isn't an Alipay-specific problem. It's an ecosystem-wide pattern of weak key generation that affects applications across fintech, e-commerce, and social media.

The Architecture of Failure

The most important question isn't "how do we attack this?" but "why does this still exist?"

APK signing certificates are permanent. Unlike TLS certificates that rotate annually, an APK signing key is tied to the application's identity on Google Play and device trust stores. Rotating it means breaking update chains for over a billion installed devices.

This creates a paradox: the more successful an application becomes, the harder it is to fix its cryptographic foundation. Alipay's 2009 certificate isn't still in use because nobody knows it's weak — it's still in use because replacing it is an infrastructure-level challenge that touches every user's device.

Understanding this dynamic is crucial for the industry. It suggests that the standard advice — "just rotate your keys" — ignores the real engineering constraints of mobile payment platforms at scale.

Responsible Disclosure

Responsible disclosure was initiated on February 25, 2026, with four rounds of private reports submitted through March 7. The vendor responded on March 10, 2026, explicitly classifying all reported issues as "normal functionality" with no remediation planned.

Per CERT/CC coordinated disclosure guidelines, when a vendor explicitly declines to address reported vulnerabilities, the reporter may proceed with public disclosure. We published the academic paper on IACR ePrint on March 16 and released the research repository with all sensitive data fully redacted.

The full disclosure timeline is available in the repository.

Part of a Larger Picture

This cryptographic analysis is the third component of a comprehensive security assessment of Alipay's mobile infrastructure:

| Layer | Research | Key Findings | |-------|----------|-------------| | Runtime | DeepLink + JSBridge Analysis | 17 vulnerabilities (CVSS 9.3), GPS extraction, transfer manipulation | | SDK | SecurityGuard SDK Reverse Engineering | 9 CVEs (MITRE #2005801), AVMP VM bypass, 97% unprotected APIs | | Cryptography | Hash Collision Lab | 15 PoCs, 28 keys factored, IACR 2026/526 |

Together, these three research threads document 32+ security findings across runtime, SDK, and cryptographic layers of a single payment application.

Recommendations

For application developers relying on legacy APK signing infrastructure:

1. Migrate to APK Signature Scheme v3 with key rotation capability
2. Use RSA-4096 or Ed25519 with SHA-256 for new signing certificates
3. Replace DES/3DES with AES-256-GCM using hardware-backed key storage
4. Audit key generation for PRNG quality — Batch GCD can detect shared factors at scale
5. Plan certificate rotation as a multi-year infrastructure project, not a quick fix

Read the Paper

The full academic paper is available at IACR ePrint 2026/526. All proof-of-concept code is open source at github.com/sgInnora/hash-collision-lab.

Jiqiang Feng is the founder of Innora AI, an independent security research lab focused on mobile payment infrastructure, AI security, and cryptographic analysis.

Related from Innora Security Research:

• 31 Vulns in 48 Hours: Our AI-Assisted Audit Methodology
• Nora Scan — Vulnerability Mining Engine
• Our Verified CVE Discoveries