Meteen naar de inhoud

Certificaten voor 47 dagen komen eraan. Ben je er klaar voor?

Handel nu →

Waarom werkt uw codeondertekeningscertificaat niet voor Play App Signing?

Waarom uw codeondertekeningscertificaat niet werkt voor Play App Signing

In de moderne wereld wordt de Google Play Store veelvuldig gebruikt door ontwikkelaars om hun applicaties voor Google Android te publiceren. Bij het publiceren zijn er echter een aantal nuances waarmee rekening moet worden gehouden voor een betere beveiliging. Een daarvan is een zelfondertekend certificaat.

Zelfondertekende certificaten worden over het algemeen niet gebruikt in de TLS-wereld (behalve voor testdoeleinden). Bij co-design wordt het echter nog steeds gebruikt. Vooral in de Android-wereld, waar de zelfondertekende sleutel wordt gebruikt voor de "uploadsleutel". Laten we eens kijken hoe we de "uploadsleutel" veilig kunnen genereren, maar voordat...

Waarom een ​​standaard codeondertekeningscertificaat niet werkt voor Play App Signing: Google Play vereist dat het certificaat voor de geüploade sleutel specifieke Key Usage (Digital Signature) en Extended Key Usage (Code Signing) extensies bevat, conform RFC 5280. Een zelfondertekend certificaat dat is gegenereerd zonder deze extensies expliciet in te stellen, wordt door de Play Console afgewezen, ook al is het cryptografisch geldig. De oplossing is om de extensies toe te voegen tijdens het genereren van het certificaat, niet om van certificaattype te wisselen.

Key Takeaways

  • Voor het ondertekenen van apps in de Play Store worden twee verschillende sleutels gebruikt: de uploadsleutel (zelfondertekend en alleen gebruikt om je upload naar Google te authenticeren) en de app-ondertekeningssleutel (die Google beheert en gebruikt om de gedistribueerde APK daadwerkelijk te ondertekenen). In dit artikel wordt alleen de uploadsleutel behandeld.
  • Door een aparte uploadsleutel te gebruiken in plaats van de ondertekeningssleutel van uw app opnieuw te gebruiken, beperkt u de impact van een lek: een gecompromitteerde uploadsleutel kan niet worden gebruikt om APK's te vervalsen die zich voordoen als uw app, aangezien de ondertekeningssleutel van Google zelf doorslaggevend is voor de distributie.
  • Voor de algemene certificering en PKCS#11/HSM-concepten waarnaar hier wordt verwezen, zie Codeondertekening 101: uw softwareleveringsketen beveiligen.

Wat is een uploadsleutel?

De uploadsleutel is de nieuwe methode om APK's (Android Package Kit) te uploaden naar Google Play App Signing om ze vervolgens voor gebruikers te publiceren. De uploadsleutel creëert een vertrouwensrelatie tussen uw bedrijf en Google om een ​​Android-pakket te uploaden. Het Android-pakket moet worden ondertekend met de uploadsleutel voordat het naar de Play Console kan worden geüpload. Dit verschilt aanzienlijk van de app-ondertekeningssleutel die wordt gebruikt om het Android-pakket te ondertekenen voor distributie.

Play App Signing gebruikt dus twee sleutels: de app-ondertekeningssleutel en de uploadsleutel. In dit artikel verwijzen we alleen naar de uploadsleutel.

Hieronder ziet u een afbeelding ter illustratie van de ondertekeningsstroom in Android:

ondertekeningsstroom in Android

Waarom Upload Key gebruiken?

Als u uw app-ondertekeningssleutel voor uw releases blijft gebruiken, loopt u het risico dat de sleutel door menselijke fouten uitlekt. Stel echter dat u een aparte uploadsleutel gebruikt voor het ondertekenen van de binaire bestanden die u op uw computer produceert.

In dat geval kan de uploadsleutel, zelfs als deze gecompromitteerd is, niet door een kwaadwillende derde partij worden gebruikt om APK's te maken die uw eigen APK's imiteren. Daarom wordt het gebruik van een aparte uploadsleutel als best practice beschouwd.

met behulp van een aparte uploadsleutel

Gebruik vanuit een beveiligingsoogpunt altijd de optie “Exporteer en upload een sleutel vanuit Java Keystore”.

Maar hoe maken we een uploadsleutel?

Zelfondertekende certificaten worden gebruikt om een ​​uploadsleutel te genereren. We bespreken eerst de simplistische manier die doorgaans wordt gebruikt om een ​​zelfondertekende sleutel via OpenSSL aan te maken en bespreken later de kwetsbaarheid en oplossing achter deze aanpak:

Een eenvoudige manier om een ​​zelfondertekende sleutel te maken via OpenSSL 

Generatie van een privésleutel

Eerst maken we een privésleutel aan. De onderstaande opdracht maakt een 4096-bits RSA-privésleutel (.key) aan met de OpenSSL-opdracht:

openssl genrsa -out upload.key 4096

een privésleutel aanmaken

Als we de privésleutel willen versleutelen, voegen we de optie -des3 toe aan het commando.

openssl genrsa -des3 -out upload.key 4096

privésleutel gecodeerd

Als de privésleutel versleuteld is, houd er dan rekening mee dat elke geautomatiseerde build of CI/CD-pipeline die de upload ondertekent, de wachtwoordzin nodig heeft die tijdens het ondertekenen wordt opgegeven, aangezien er in die context geen interactieve prompt is. Weeg deze operationele overhead af tegen het beveiligingsvoordeel voordat u de sleutel versleutelt voor een geautomatiseerde workflow.

Oplossing voor codeondertekening voor bedrijven

Ontvang één oplossing voor al uw cryptografische behoeften op het gebied van softwarecodeondertekening met onze codeondertekeningsoplossing.

Een certificaatondertekeningsaanvraag maken

U hebt een Certificate Signing Request (CSR) nodig als u uw certificaat wilt laten ondertekenen. De CSR bevat uw openbare sleutel en aanvullende informatie (organisatie, land, enz.).

Laten we een CSR (upload.csr) maken van onze bestaande privésleutel:

openssl req -key upload.key -new -out upload.csr

een CSR aanmaken
txt-bestanden uploaden

Certificaat verkrijgen van CSR en sleutel gegenereerd

Zodra de CSR en de privésleutel zijn gegenereerd, is de volgende stap het aanmaken van het certificaat. De onderstaande opdracht genereert het certificaat met een geldigheidsduur van 365 dagen:

openssl x509 -req -days 365 -in upload.csr -signkey upload.key -out upload.crt

Maak een certificaat aan met een geldigheidsduur van 365 dagen.

Het ontvangen certificaat is in .crt-formaat, zonder privésleutel, en we willen een .pfx-formaat (omdat het een privésleutel bevat) om bestanden te ondertekenen. We gebruiken de onderstaande opdracht om het naar pfx te converteren:

openssl pkcs12 -inkey upload.key -in upload.crt -export -out upload.pfx

Zodra het wachtwoord is ingevoerd, wordt het .pfx-bestand gegenereerd.

.pfx-bestand gegenereerd

Dit pfx-bestand moet vervolgens de Android Bundle ondertekenen.

Klinkt goed, toch? De bestanden die met dit certificaat zijn ondertekend, worden echter niet geaccepteerd in de Play Store. Dit komt doordat het zelfondertekende certificaat geen extensies voor Sleutelgebruik en Verbeterd Sleutelgebruik bevat. Om dit te zien, opent u Certificaten in de MMC (Microsoft Management Console) en laadt u de module Certificaten. Klik na het openen van het certificaat op het tabblad Details.

Certificaatgegevens

Maar wat zijn Key Usage Extensions?

Uitbreidingen voor sleutelgebruik (KU) definiëren het doel van de openbare sleutel in een certificaat. Eén sleutel mag slechts voor één doel worden gebruikt.

Hoeveel Key Usage-extensies zijn er beschikbaar en welke moet ik kiezen?

Volgens RFC 5280 (Key Usage) zijn de volgende extensies voor sleutelgebruik beschikbaar:

  • Digitale handtekening
  • Niet-afwijzing
  • Sleutelcodering
  • Gegevensversleuteling
  • Belangrijke overeenkomst
  • Certificaatondertekening
  • CRL-ondertekening
  • Alleen vercijferen
  • Alleen ontcijferen

Voor uitgebreid sleutelgebruik (EKU) moeten, afhankelijk van het gebruiksscenario, de onderstaande waarden worden gekozen:

Uitgebreide sleutelInschakelen voor deze sleutelgebruikextensies
TLS-webserverauthenticatieDigitale handtekening, sleutelversleuteling of sleutelovereenkomst
TLS-webclientauthenticatieDigitale handtekening en/of sleutelovereenkomst
Onderteken (downloadbare) uitvoerbare codeDigitale handtekening
E-mailbeveiligingDigitale handtekening, onweerlegbaarheid en/of sleutelversleuteling of sleutelovereenkomst
IPSEC-eindsysteem (host of router)Digitale handtekening en/of sleutelversleuteling of sleutelovereenkomst
IPSEC-tunnelDigitale handtekening en/of sleutelversleuteling of sleutelovereenkomst
IPSEC-gebruikerDigitale handtekening en/of sleutelversleuteling of sleutelovereenkomst
TijdstempelDigitale handtekening, onweerlegbaarheid.

Daarom hebben we voor het gebruik van codeondertekening een digitale handtekening als sleutelgebruik en codeondertekening als verbeterd sleutelgebruik nodig.

codeondertekening gebruiksvoorbeeld

Hoe voeg ik KU- en EKU-extensies toe aan mijn certificaat?

Om ze toe te voegen, moeten we de onderstaande opdracht in OpenSSL uitvoeren:

openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out server.pem -days 365 -subj /CN=Cert_Name/C=US/OU=Your_OU/O=Your_org_name -addext “keyUsage = digitalSignature” -addext “extendedKeyUsage = Code Signing”

Waar:

CN = Algemene naam van het certificaat (meestal de organisatienaam bij codeondertekening)

C= Landnaam

OU = Organisatie-eenheid (bijv. Engineering, IT, enz.)

O= Organisatienaam

Overzicht van OpenSSL-opdrachten

Dit genereert het benodigde codeondertekeningscertificaat met Key Usage- en Enhanced Key Usage-extensies.

vereist codeondertekeningscertificaat

Dit certificaat kan nu succesvol worden gebruikt om Android-bundels te uploaden naar Google Play App Signing Console.

Veelgestelde Vragen / FAQ

Is mijn bestaande bedrijfsbrede codeondertekeningscertificaat hiervoor niet geschikt, of mist het gewoon een extensie?

Er ontbreekt een extensie. De Play Console weigert het certificaat omdat de extensies 'Digital Signature Key Usage' en 'Code Signing Extended Key Usage' ontbreken, niet omdat het het verkeerde certificaattype is. Ik genereer het certificaat opnieuw met de juiste extensies. -addext Het probleem wordt opgelost met vlaggen.

Moet de uploadsleutel dezelfde sleutel zijn als de sleutel waarmee het uiteindelijke, gedistribueerde APK-bestand wordt ondertekend?

Nee. Bij Play App Signing bewaart en gebruikt Google een aparte app-ondertekeningssleutel om de app te ondertekenen die daadwerkelijk bij de gebruikers terechtkomt. De uploadsleutel bevestigt alleen dat het ingediende pakket van jou afkomstig is.

Wat gebeurt er als mijn uploadsleutel wordt gecompromitteerd?

Google biedt een procedure om de uploadsleutel die aan uw app is gekoppeld, opnieuw in te stellen. Google, en niet u, beheert namelijk de daadwerkelijke app-ondertekeningssleutel die voor distributie wordt gebruikt. Dit is precies het voordeel van het gescheiden houden van de twee sleutels.

Conclusie

De oplossing zit hem niet in een ander certificaat, maar in de juiste extensies op het certificaat dat je al kunt genereren. Stel 'Digitale handtekening' in als sleutelgebruik en 'Codeondertekening' als uitgebreid sleutelgebruik tijdens het genereren, en dezelfde OpenSSL-gebaseerde workflow voor het uploaden van sleutels werkt ook voor het ondertekenen van Play-apps.