Ondertekening van Android-apps: hoe het werkt en waarom het ertoe doet

Elke keer dat u een app op uw Android-telefoon installeert, vindt er op de achtergrond een stille maar kritische beveiligingscontrole plaats. Uw telefoon verifieert de digitale handtekening van het APK-pakket. Deze cryptografische handdruk voorkomt dat kwaadwillende hackers uw apps met malware 'vergiftigen' en zorgt er tegelijkertijd voor dat ontwikkelaars updates kunnen pushen zonder hun identiteit te verliezen.

Als je apps schrijft, is ondertekenen iets dat je gewoon goed moet doen; als je gewoon graag aan Android sleutelt, is dit een van de meest bevredigende onderdelen van het systeem om te begrijpen. Hoe dan ook, hoe app-ondertekening werkt is de moeite waard. Hieronder lopen we door de technologie, hoe de ondertekeningsschema's zijn geëvolueerd en hoe u online kunt certificaten handmatig verifiëren.

Wat is app-ondertekening?

In de kern is app-ondertekening een proces waarbij een ontwikkelaar een Privésleutel gebruikt om een ​​handtekeningblok voor de bestanden van zijn app te genereren. De bijbehorende Openbare sleutel wordt vervolgens ingesloten in de APK in de map META-INF. Wanneer uw telefoon de app probeert te installeren, gebruikt deze de openbare sleutel om te controleren of de handtekening overeenkomt met de inhoud van het bestand.

Dit levert twee belangrijke eigenschappen op:

1. Onveranderlijkheid: Als een enkele byte van de app-code wordt gewijzigd (bijvoorbeeld door een Trojaans paard), komt de handtekening niet langer overeen met het bestand en weigert Android het te installeren.
2. Bewijs van identiteit: Als een app een bestaande app probeert bij te werken, moeten de handtekeningen overeenkomen. Dit is de reden waarom je een gemanipuleerde Facebook-app niet over de officiële app kunt installeren.

Evolutie van ondertekeningsschema's

Google heeft het ondertekeningsmechanisme voortdurend geüpgraded om zowel de snelheid als de veiligheid te verbeteren:

• V1 (Jar-ondertekening): Ondertekent individuele bestanden binnen de APK (ZIP). Dit is langzaam omdat het besturingssysteem elk bestand moet uitpakken en controleren. Het is ook kwetsbaar voor bepaalde ZIP-manipulaties.
• V2 (APK-handtekeningschema): Ondertekent het volledige binaire blok van de APK. Om te verifiëren is het niet uitpakken nodig, waardoor het ongelooflijk snel gaat. Het werd geïntroduceerd in Android 7.0 (Nougat).
• V3 (sleutelrotatie): Breidt V2 uit door een "reeks" toetsen toe te voegen. Hiermee kan een ontwikkelaar bewijzen dat een nieuwe sleutel de geautoriseerde opvolger is van een oudere sleutel. Geïntroduceerd in Android 9.0 (Pie).
• V4 (Streaming-ondertekening): Speciaal ontworpen voor incrementele installaties, waardoor apps kunnen worden geverifieerd terwijl ze nog worden gedownload via USB of Wi-Fi.

Waarom certificaten belangrijk zijn voor sideloading

Wanneer u een APK downloadt van een niet-officiële bron, is de Certificaat hashen uw beste vriend. Een certificaatvingerafdruk (zoals een SHA-256-hash) identificeert op unieke wijze de ondertekeningssleutel van de ontwikkelaar. Elke app behoudt dezelfde ondertekeningssleutel voor al zijn updates, zodat u de vingerafdruk van een APK kunt vergelijken met de gepubliceerde waarde van de ontwikkelaar om te bevestigen dat deze echt is.

Als u vermoedt dat een APK nep is, moet u deze via onze Online APK-verificatie uitvoeren. Onze tool laat u zien:

• De Algemene naam (CN) van de ondertekenaar (bijvoorbeeld 'Android').
• De Geldigheidsperiode van het certificaat.
• De SHA-1/SHA-256-vingerafdrukken.

Hoe Android een handtekening verifieert tijdens de installatie

De stap "verifieer het certificaat" wordt zo vaak verdoezeld dat het de moeite waard is om door te nemen wat het besturingssysteem eigenlijk doet als je op een APK tikt en Android besluit of het wordt geïnstalleerd:

1. Open de APK als ZIP en zoek het ondertekeningsblok. Voor v2/v3-handtekeningen is dit een gestructureerd blok direct vóór de centrale map; voor het oudere v1-schema is dit de inhoud van META-INF/*.RSA, *.DSA of *.EC.
2. Bereken SHA-256-samenvattingen van elke andere byte van de APK. Het ondertekeningsblok is uitgesloten van zijn eigen samenvatting; al het andere wordt gehasht in gedefinieerde brokken.
3. Controleer de samenvatting van elk deel met de samenvattingen die zijn vastgelegd in het ondertekeningsblok. Als er zelfs maar één byte is gewijzigd sinds de ontwikkelaar het bestand heeft ondertekend, komen de samenvattingen niet overeen en wordt de installatie afgewezen met de algemene foutmelding 'App niet geïnstalleerd'.
4. Controleer of het ondertekeningsblok zelf is geproduceerd met de privésleutel van het certificaat. De publieke sleutel van het certificaat wordt gebruikt om de cryptografische handtekening in het blok te controleren. Een succesvolle controle betekent dat degene die het bestand heeft ondertekend, in het bezit was van de privésleutel die aan dit certificaat is gekoppeld.
5. Vergelijk de certificaatvingerafdruk met een bestaande installatie met dezelfde pakketnaam. Als het pakket al is geïnstalleerd en de nieuwe APK is ondertekend met een ander certificaat, wordt de installatie afgewezen met INSTALL_FAILED_UPDATE_INCOMPATIBLE. Dit is de belangrijkste verdediging van het besturingssysteem tegen nabootsing van identiteit: een kwaadwillende actor kan uw bankapp niet vervangen door een eigen exemplaar, tenzij hij ook de ondertekeningssleutel van de bank heeft gestolen.

Niets van dit alles bewijst dat de ontwikkelaar betrouwbaar is, alleen dat het bestand dat u gaat installeren byte-identiek is aan wat ze hebben ondertekend en dat geen enkele andere partij ermee heeft geknoeid. Vertrouwen in de ontwikkelaar is een afzonderlijke beslissing, die u neemt door te beslissen vanaf welke bronnen u installeert.

Wat ‘signatuurmismatch’ werkelijk betekent

De meest voorkomende verrassing die mensen tegenkomen bij sideloading is de fout 'signature mismatch' bij het updaten. Dit is wat er feitelijk gebeurt:

• Je hebt App X versie 1.0 geïnstalleerd vanuit de Play Store.
• Je downloadt App X-versie 1.1 van een niet-Play-bron.
• Het besturingssysteem ziet dezelfde pakketnaam (com.example.app), maar de APK is ondertekend met een ander certificaat (de ondertekeningssleutel van de zijbron, niet die van de oorspronkelijke uitgever). Het weigert te installeren.

In de praktijk gebeurt dit op twee manieren:

1. De APK van derden is echt van een andere uitgever, bijvoorbeeld een 'gemodificeerde' of 'gepatchte' kopie. Het weigeren van de installatie is het juiste gedrag; Als u het installeert, zou dit betekenen dat u een vreemde dezelfde gegevens toevertrouwt die de app van uw bank al heeft aangeraakt.
2. De APK van derden is een herupload van de officiële APK, maar het Play App Signing-systeem van Google ondertekent de download van elke gebruiker met de sleutel uploaden-wrapper van de gebruiker. Twee apparaten kunnen soms enigszins verschillende handtekeninggegevens zien voor dezelfde conceptuele app-versie. In dat geval komt de certificaatvingerafdruk in de root nog steeds overeen; u kunt dit verifiëren met onze APK-verificatie.

Als de certificaatvingerafdruk echt verschilt van uw bestaande installatie, is de enige uitweg om eerst de huidige kopie te verwijderen (waarbij de gegevens verloren gaan) voordat u de vervanging sideloadt, en nooit om handtekeningverificatie uit te schakelen.

Uw eigen ondertekeningssleutel genereren (voor ontwikkelaars)

Als u Android-apps bouwt, moet u uiteindelijk uw eigen builds ondertekenen. De standaardopdracht van één regel die keytool van een Java SDK gebruikt, is:

keytool -genkeypair -v \
        -keystore my-release.keystore \
        -alias my-app -keyalg RSA -keysize 2048 \
        -validity 10000

Twee dingen om te weten:

• De geldigheid is van belang: 10.000 dagen (ongeveer 27 jaar) is de conventionele waarde, omdat het besturingssysteem updates die zijn ondertekend met een bijna verlopen of verlopen sleutel als gecompromitteerd beschouwt. Genereer eenmalig een sleutel met een lange levensduur en bescherm deze.
• Eenmaal gepubliceerd, kun je niet meer eenvoudig van sleutel wisselen. Het v3-ondertekeningsschema voegt sleutel rotatie toe als een expliciete functie: een oud certificaat "zegent" een nieuw certificaat via een opgeslagen bewijs, waardoor het besturingssysteem updates van de nieuwe sleutel kan accepteren terwijl de identiteitscontinuïteit behouden blijft. Zonder v3 betekent het verlies van de originele sleutel dat alle bestaande installaties verloren gaan.

Voor sideloaded testbuilds is een niet-ondertekende debug-keystore prima; gebruik voor productie een met een wachtwoord beveiligde sleutelopslag met een lange geldigheid die is opgeslagen in de offline back-up.

Veelvoorkomende valkuilen bij het ondertekenen

1. Zelfondertekende certificaten: De meeste Android-apps zijn zelfondertekend. In tegenstelling tot SSL voor websites is er geen centrale autoriteit voor het ondertekenen van Android-apps. U moet de ontwikkelaar rechtstreeks vertrouwen.
2. Debug-certificaten: Apps die zijn gebouwd om te testen, gebruiken een generieke 'debug'-sleutel. Deze apps mogen nooit openbaar worden gemaakt en worden door veel beveiligingsfilters geblokkeerd.
3. Sleutelverlies: Als een ontwikkelaar zijn privésleutelarchief kwijtraakt, kan hij nooit zijn app opnieuw updaten. Ze zouden een "nieuwe" app moeten uitbrengen met een andere pakketnaam.

Het juiste ondertekeningsschema kiezen voor uw doel-SDK

App-ondertekening ondersteunt stilletjes een groot deel van de Android-beveiliging. Zodra de relatie privé/publieke sleutel klikt, kunt u een sideloaded app op zijn merites beoordelen en bevestigen dat wat u installeert niet is gewijzigd sinds de ontwikkelaar deze heeft ondertekend. Zie onze gids voor het XAPK-formaat voor meer informatie over de interne onderdelen van Android.