Android 17 umí ověřit aplikaci dvěma podpisy, klasickým a postkvantovým
Android 17 zavedl schéma podpisu APK v3.2. Instalační balíček v něm nese dva podpisy: jeden klasickým klíčem RSA nebo ECDSA, druhý postkvantovým ML-DSA. Když jeden z nich chybí nebo oba patří do téže rodiny, telefon instalaci odmítne. Vývojáři si klíče většinou vyrábět nemusí, hybridní pár za ně vygeneruje Google Play.
Podpis aplikace je jediná věc, podle které telefon pozná, že aktualizace přišla od téhož vývojáře jako původní instalace. Kdo ten podpis dokáže zfalšovat, dostane do cizího telefonu vlastní kód pod jménem známé aplikace. Proti tomu míří schéma podpisu APK v3.2, které přišlo s Androidem 17: balíček podepsaný podle něj nese dva podpisy místo jednoho.
Jeden klíč klasický, druhý mřížkový
V bloku v3.2 musí být přesně dva podepisující. Jeden použije klasický algoritmus, tedy RSA nebo ECDSA jako dosud, druhý postkvantový ML-DSA. Když jsou oba klasické nebo oba postkvantové, ověření selže. Stejně dopadne balíček, ve kterém se ti dva rozcházejí v rozsahu verzí systému, na které míří. Blok má v podpisové části APK vlastní identifikátor 0x70e1c89f, aby se poznalo, že jde o hybrid.
ML-DSA je zkratka pro podpisový algoritmus postavený na mřížkách, který americký normalizační úřad NIST vydal 13. srpna 2024 jako FIPS 204. Android z něj bere dvě varianty, ML-DSA-65 a ML-DSA-87.
Proč dva klíče, a ne rovnou jeden
Dokumentace Androidu to popisuje jako obranu do hloubky. Dokud nemá nový algoritmus odslouženo v provozu, drží se vedle něj ten prověřený: klasický podpis kryje případnou chybu v čerstvé implementaci mřížkové matematiky, postkvantový míří na stroj, který jednou klasický klíč spočítá. Až se ML-DSA ve velkém osvědčí, má být podle dokumentace možné přejít na jediný postkvantový klíč.
Sbírání zašifrovaných dat na později, kterým se odůvodňuje spěch u šifrování, tu roli nehraje. Padělaný podpis musí útočník vyrobit ve chvíli, kdy se aplikace instaluje, ne o deset let dřív. Dlouhou životnost má něco jiného, totiž řetěz důvěry uvnitř telefonu, a právě na něj se Google v oznámení odvolává, když mluví o odolnosti platformy na desítky let dopředu.
Starší Androidy ten blok přeskočí
Telefon s Androidem 16 a nižším o schématu v3.2 neví a ověří balíček podle staršího podpisu. APK proto musí dál nést i blok v3.0 nebo v3.1 podepsaný jediným klasickým klíčem; dokumentace mu říká K0 a označuje ho za záchrannou síť. U existující aplikace je to její dosavadní podpisový klíč, u nové se K0 vygeneruje vedle nového hybridního páru.
Aby se toho nedalo zneužít, zapisuje podpisový nástroj do staršího bloku dva atributy s hranicemi verzí systému, 0xbf940529 a 0x9f06b79c. Když se telefon do tohoto rozmezí trefí a hybridní blok v balíčku nenajde, instalaci odmítne. Bez toho by útočníkovi stačilo blok v3.2 z APK vystřihnout a systém by se spokojil s klasickým podpisem.
Klíče vyrobí Google Play
Vývojář, který používá Play App Signing, se o nic starat nemusí. Google Play během vydání Androidu 17 vygeneruje podpisové klíče ML-DSA novým aplikacím a těm existujícím, které se přihlásí, a to bez ohledu na to, na jakou úroveň API aplikace míří. Klíče drží v Cloud KMS. Později má jít dodat vlastní klasický i postkvantový klíč a nechat Play jen samotné hybridní povýšení. Google k tomu začne vývojáře vyzývat, aby si podpisové klíče obměňovali nejméně jednou za dva roky.
Podpisy aplikací jsou jen jedna z vrstev
Na ML-DSA přechází v Androidu 17 také ověřený start systému, tedy Android Verified Boot, a začal i převod vzdáleného dokládání stavu zařízení, kde se mění certifikační řetězy KeyMintu. Úložiště klíčů Android Keystore umí na podporovaných zařízeních vygenerovat ML-DSA-65 i ML-DSA-87 přímo v zabezpečeném hardwaru přes běžné rozhraní KeyPairGenerator, takže aplikace, která potřebuje kvantově odolný podpis, si k němu nemusí přibalovat vlastní kryptografii.
Mřížkové klíče jsou přitom výrazně větší než klíče eliptických křivek a v zabezpečeném prostředí telefonu je paměti málo. Google sám tuhle část označuje za velký kus inženýrské práce.
Termín zatím nikde nestojí
Majitel telefonu z toho neuvidí nic. Aplikace se instalují a aktualizují stejně jako dřív, jen ověření navíc projde druhým podpisem. Výrobci a ti, kdo si Android upravují, si implementaci můžou proklepat testem HybridSignatureVerificationTest.java ze sady CTS.
Co v žádném z obou oznámení není, je datum. Android 17 hybridní podpis ověřit umí, Google Play ho umí vyrobit, ale den, od kterého by aplikace bez postkvantového podpisu do Obchodu Play neprošla, nikde uvedený není.
Zdroje: popis schématu podpisu APK v3.2 v dokumentaci AOSP, zápis Security for the Quantum Era na blogu Google Security z 25. března 2026, oznámení Androidu 17 z června 2026 a shrnutí na Privacy Guides.