Code Signing — wat is het, codeondertekening en hoe werkt het
Code Signing (codeondertekening) — een mechanisme voor digitale ondertekening van uitvoerbare bestanden, dat de authenticiteit van de ontwikkelaar en de integriteit van de applicatie garandeert. In Android moet elk APK-bestand worden ondertekend met een certificaat voordat het op een apparaat wordt geïnstalleerd of in Google Play wordt gepubliceerd. Volgens Google, 2024 ondersteunt Android vier generaties ondertekeningsschema's: van v1 op basis van JAR tot v4 voor streaming-installatie.
Belangrijkste
- Code Signing — digitale handtekening van code, die auteurschap en integriteit van de applicatie bevestigt.
- In Android gebeurt ondertekening via keystore — een opslagplaats voor sleutels en certificaten.
- Schema v2 (APK Signature Scheme) — de belangrijkste standaard sinds Android 7.0, die alle bytes van APK beschermt.
- Sleutelrotatie (v3, Android 9.0+) maakt het mogelijk de ondertekeningssleutel te wijzigen zonder de app te verwijderen.
- Google Play gebruikt Play App Signing voor gecentraliseerd sleutelbeheer.
Wat is Code Signing?
Code Signing — een cryptografisch proces waarbij de ontwikkelaar uitvoerbare code ondertekent met zijn digitale certificaat. De handtekening wordt gemaakt met behulp van asymmetrische encryptie: met de privésleutel van de ontwikkelaar wordt een digitale handtekening gegenereerd en de openbare sleutel wordt in het certificaat ingebed. Iedereen kan de handtekening verifiëren met de openbare sleutel, maar wijziging van de code zonder de handtekening te verbreken is onmogelijk.
In mobiele ontwikkeling vervult codeondertekening drie functies. Eerste — authenticatie: gebruiker en platform kunnen de ontwikkelaar van de app identificeren. Tweede — integriteit: elke wijziging van APK na ondertekening maakt de handtekening ongeldig. Derde — vertrouwde update: het platform staat alleen updates toe van APK's die zijn ondertekend met hetzelfde certificaat als de geïnstalleerde versie.
Juridische status
Digitale handtekening van Android-apps heeft juridische betekenis. In overeenstemming met de wetgeving van de Russische Federatie (63-FZ) en de Europese eIDAS, wordt een gekwalificeerde elektronische handtekening gelijkgesteld aan een handgeschreven handtekening. Echter, ondertekening van APK met een zelfondertekend certificaat (gebruikelijke praktijk in Android) is niet gekwalificeerd — het bevestigt integriteit, maar niet de identiteit van de ontwikkelaar vanuit juridisch oogpunt.
Ondertekeningsschema's van Android: v1, v2, v3, v4
Android ondersteunt vier APK-ondertekeningsschema's, die elk de problemen van de vorige versie oplossen en nieuwe mogelijkheden toevoegen. Alle schema's kunnen naast elkaar bestaan in één APK — dit is nodig voor achterwaartse compatibiliteit met oudere Android-versies.
Schema v1 (JAR-ondertekening) verscheen in Android 1.0. Het ondertekent afzonderlijke bestanden in het APK-archief via vermeldingen in META-INF/MANIFEST.MF. Nadeel: men kan APK wijzigen (bestanden toevoegen of verwijderen) en alleen de gewijzigde bestanden opnieuw ondertekenen, zonder de handtekening van de andere aan te tasten. Dit maakt v1 kwetsbaar voor bepaalde aanvallen. Schema v2 (APK Signature Scheme), geïntroduceerd in Android 7.0, ondertekent het hele APK-bestand volledig, inclusief alle bytes behalve de handtekening zelf, wat de mogelijkheid van selectieve wijziging elimineert.
| Schema | Android | Kenmerk | Sleutelrotatie |
|---|---|---|---|
| v1 (JAR) | 1.0+ | Ondertekening van elk bestand | Nee |
| v2 | 7.0+ | Ondertekening van hele APK | Nee |
| v3 | 9.0+ | Ondertekening + rotatie | Ja |
| v4 | 11.0+ | Streaming + ADB | Ja |
v3: rotatie van ondertekeningssleutels
Schema v3, geïntroduceerd in Android 9.0, lost een oud probleem op: wat te doen als de ondertekeningssleutel is gecompromitteerd of verlopen? Voorheen betekende het wijzigen van de ondertekeningssleutel dat de app als nieuw werd beschouwd — deze kon niet over de bestaande worden geïnstalleerd. v3 voegt een rotatiemechanisme toe: in APK kan een bewijs van sleutelwijziging (proof-of-rotation) worden opgenomen, ondertekend met de oude sleutel. Het systeem controleert de keten en staat update toe van de app die is ondertekend met de nieuwe sleutel.
Keystore en certificaten
Keystore — beveiligde container met privésleutels en certificaten voor het ondertekenen van apps. In Android-ontwikkeling wordt het formaat JKS (Java KeyStore) of PKCS12 gebruikt. Keystore wordt gemaakt met het hulpprogramma keytool, dat deel uitmaakt van JDK. Elke sleutel in de opslagplaats wordt geïdentificeerd door een alias en beschermd met een wachtwoord.
Het certificaat in keystore bevat openbare sleutel en informatie over de eigenaar: naam van de organisatie, land, geldigheidsduur. Voor Android-apps kan het certificaat zelfondertekend zijn — Google vereist geen certificeringsinstantie (CA), wat Android onderscheidt van iOS. De geldigheidsduur van het certificaat moet echter minstens 25 jaar zijn, omdat de app met dezelfde sleutel wordt bijgewerkt.
bash
# Nieuwe keystore maken voor ondertekening
keytool -genkey -v -keystore my-release.keystore \
-alias my-app-alias \
-keyalg RSA \
-keysize 2048 \
-validity 10000
# Inhoud van keystore bekijken
keytool -list -v -keystore my-release.keystoreSleutelformaten
Android ondersteunt twee algoritmen voor ondertekeningssleutels: RSA en ECDSA. RSA met sleutelgrootte 2048 bits — de facto standaard, ondersteund door alle versies van Android. ECDSA (Elliptic Curve Digital Signature Algorithm) met curve P-256 biedt dezelfde cryptografische sterkte bij een kleinere sleutelgrootte. Vanaf Android 9.0 wordt ECDSA aanbevolen, omdat het sneller is in verificatie op mobiele apparaten.
Configuratie van ondertekening in de build
In Android Gradle Plugin wordt ondertekening geconfigureerd via het blok signingConfigs in build.gradle op moduleniveau. Voor debug-builds maakt Android Studio automatisch een debug-keystore met bekende wachtwoorden. Voor release-builds geeft de ontwikkelaar het pad naar zijn keystore, de alias van de sleutel en wachtwoorden op. Het wordt aanbevolen wachtwoorden in aparte configuratiebestanden te bewaren, uitgesloten van versiebeheer.
Moderne praktijk is gecentraliseerd beheer van ondertekening via CI/CD. Jenkins, GitLab CI of GitHub Actions kunnen keystore opslaan als beveiligd artefact en wachtwoorden als omgevingsgeheimen. Dit voorkomt lekkage van sleutels via de repository en vereenvoudigt het wijzigen van de sleutel wanneer nodig.
groovy
// build.gradle (moduleniveau) — configuratie van ondertekening
android {
signingConfigs {
release {
storeFile file("my-release.keystore")
storePassword System.getenv("KEYSTORE_PASSWORD")
keyAlias System.getenv("KEY_ALIAS")
keyPassword System.getenv("KEY_PASSWORD")
}
}
buildTypes {
release {
signingConfig signingConfigs.release
}
}
}Ondertekening met meerdere schema's
Voor maximale compatibiliteit moet APK worden ondertekend met alle drie schema's (v1 + v2 + v3). Android Gradle Plugin neemt standaard alle schema's op. APK alleen met v2 ondertekend, wordt niet geïnstalleerd op Android 6.0 en lager. APK alleen met v1 heeft de integriteitsvoordelen van v2 niet op Android 7.0+. Het opnemen van alle schema's vergroot de APK-grootte niet meer dan 1–2% en garandeert compatibiliteit met elk apparaat.
Play App Signing en sleutelbeheer
Play App Signing — Google Play-service die gecentraliseerd de ondertekeningssleutels van apps beheert. De ontwikkelaar uploadt naar Google Play Console een APK ondertekend met de uploadsleutel (upload key), en Google Play ondertekent het opnieuw met de distributiesleutel (distribution key) voordat het aan gebruikers wordt geleverd. Dit beschermt de distributiesleutel tegen verlies of compromittering.
Voordelen van Play App Signing: beveiliging — de distributiesleutel wordt bewaard in beveiligde Google-opslag; rotatie — sleutelwijziging kan via de console worden aangevraagd; herstel — bij verlies van de uploadsleutel kan een nieuwe worden gegenereerd. Nadeel: voor apps die bestonden vóór de invoering van Play App Signing vereist de overgang het maken van een nieuwe app, omdat de oude distributiesleutel al wordt gebruikt.
bash
# Vingerafdruk van certificaat verkrijgen (SHA-256)
keytool -list -v -keystore my-release.keystore \
-alias my-app-alias | grep "SHA256"
# APK-handtekening controleren via apksigner
apksigner verify --verbose app-release.apkHerstel van sleutel
Als de ondertekeningssleutel verloren is en Play App Signing niet wordt gebruikt, is herstel van de updatemogelijkheid onmogelijk — u moet een nieuwe app maken met een nieuwe pakketnaam. Dit is een van de belangrijkste redenen om Play App Signing te gebruiken. Google raadt aan een back-up van keystore te bewaren in beveiligde offline opslag (geëncrypteerde USB-drive, bankkluis).
Verificatie van handtekening op apparaat
Bij installatie van APK voert Android verificatie van de handtekening uit in verschillende stappen. Eerste — controle van certificaat: niet verlopen, formaat correct. Tweede — controle van handtekening: komt cryptografische handtekening overeen met APK-inhoud. Derde — vergelijking van certificaat met geïnstalleerde versie: als de app al op het apparaat staat, moet het certificaat overeenkomen, anders wordt installatie geblokkeerd.
Het verificatiesysteem is ingebouwd in PackageManagerService. Bij verwerking van een installatieverzoek haalt PMS de handtekening uit APK, controleert deze met de klasse android.util.PackageParser en vergelijkt deze met de opgeslagen handtekening van de geïnstalleerde app (als die bestaat). Bij niet-overeenkomst krijgt de gebruiker de fout „INSTALL_FAILED_UPDATE_INCOMPATIBLE”. Dit mechanisme voorkomt vervangingsaanvallen (malware kan een legitieme app niet updaten met zijn eigen versie).
Controle door ontwikkelaar
De ontwikkelaar kan zelf de handtekening van APK controleren met het hulpprogramma apksigner uit Android SDK Build Tools. Het commando apksigner verify --verbose app.apk toont met welke schema's APK is ondertekend, of certificaten geldig zijn en of handtekeningen overeenkomen met de inhoud. Voor programmatische verificatie van de handtekening van een geïnstalleerde app wordt PackageManager.getPackageInfo() gebruikt met de vlag GET_SIGNATURES.
kotlin
// Programmatische controle van handtekening van geïnstalleerde app
fun getAppSignature(context: Context, packageName: String): String? {
val pm = context.packageManager
val info = pm.getPackageInfo(
packageName,
PackageManager.GET_SIGNATURES
)
return info.signatures?.firstOrNull()?.toCharsString()
}Beste praktijken voor beveiliging van ondertekening
Beveiliging van de ondertekeningssleutel — kritisch aspect van Android-ontwikkeling. Compromittering van de sleutel stelt een aanvaller in staat updates van uw app met zijn eigen code te ondertekenen. Basisregels: bewaar de sleutel nooit in de repository, gebruik niet dezelfde sleutel voor verschillende apps, stuur de sleutel niet via onbeveiligde kanalen (e-mail, messengers).
Aanbevolen praktijk is scheiding van sleutels. Gebruik een aparte sleutel voor elke app en een aparte sleutel voor upload naar Google Play (upload key). Voor debug-builds maakt Android Studio een gedeelde debug.keystore — deze kan niet worden gebruikt voor release-builds. De geldigheidsduur van het certificaat moet 25–30 jaar zijn (huidige standaard, bevestigd door Google).
| Praktijk | Aanbeveling |
|---|---|
| Opslag sleutel | Geëncrypteerde drager, CI/CD geheimen |
| Certificaatduur | Minstens 25 jaar |
| Algoritme | RSA 2048+ of ECDSA P-256 |
| Scheiding | Aparte sleutel per app |
| Reservering | Offline kopie van keystore |
Audit van handtekeningen
Controleer regelmatig de integriteit van de ondertekeningsketen. Bij wisseling van medewerkers die toegang hebben tot sleutels, update dan de upload key via Google Play Console. Gebruik hulpmiddelen zoals Google Play Integrity API om te controleren of uw app niet is vervalst op gebruikersapparaten. De API retourneert gegevens over handtekening en integriteit en stuurt deze naar de server voor verificatie.
Veelgestelde vragen
Wat is Code Signing in Android?
Code Signing — is de digitale handtekening van een APK-bestand die bevestigt dat de app is gemaakt door een specifieke ontwikkelaar en niet is gewijzigd na ondertekening. Zonder handtekening wordt APK niet geïnstalleerd op het apparaat.
Hoe maak ik een sleutel voor ondertekening van een Android-app?
Gebruik het hulpprogramma keytool uit JDK: keytool -genkey -v -keystore my-release.keystore -alias my-alias -keyalg RSA -keysize 2048 -validity 10000. De verkregen keystore vermeldt u in build.gradle in het blok signingConfigs.
Wat gebeurt er als ik de ondertekeningssleutel verlies?
Als de sleutel verloren is en u gebruikt geen Play App Signing, wordt update van de app onmogelijk. U moet een nieuwe app maken in Google Play met een nieuwe pakketnaam. Gebruik Play App Signing om uzelf te beschermen tegen sleutelverlies.
Wat is het verschil tussen ondertekeningsschema's v1 en v2?
v1 ondertekent elk bestand in APK afzonderlijk — een aanvaller kan een bestand wijzigen en alleen dat opnieuw ondertekenen. v2 ondertekent de hele APK volledig — elke wijziging maakt de handtekening ongeldig, wat een hoger beveiligingsniveau biedt.
Wat is Play App Signing?
Play App Signing — een Google Play-service die gecentraliseerd de distributiesleutel van apps bewaart. De ontwikkelaar uploadt APK ondertekend met upload key, en Google ondertekent het opnieuw voordat het aan gebruikers wordt geleverd, waardoor de sleutel wordt beschermd tegen verlies of diefstal.
Samenvatting
- Code Signing — verplichte digitale handtekening van APK, die authenticiteit en integriteit van de app garandeert.
- Android ondersteunt vier ondertekeningsschema's: v1 (JAR), v2 (APK Signature), v3 (sleutelrotatie) en v4 (streaming).
- Keystore — beveiligde container met sleutels, gemaakt via keytool met RSA 2048+ algoritme.
- Sleutelrotatie (v3, Android 9.0+) maakt het mogelijk de ondertekeningssleutel te wijzigen zonder de app te verwijderen.
- Play App Signing beheert gecentraliseerd distributiesleutels via Google Play Console.
- Verificatie van handtekening bij installatie blokkeert vervangingsaanvallen: niet-overeenkomst van certificaat = fout INSTALL_FAILED.
- Sleutelveiligheid: aparte sleutel per app, duur 25+ jaar, offline kopie, geen sleutels in repository.
We ontwikkelen een mobiele applicatie turnkey
IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.
Lees ook