In de moderne wereld, Google Play App Wordt veel gebruikt door ontwikkelaars om hun applicaties te publiceren met Google Android. Bij het publiceren ervan moeten echter een paar nuances in acht worden genomen voor een betere beveiliging. Een voorbeeld hiervan 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...

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:

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.

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

Als we de privésleutel willen versleutelen, voegen we de volgende code toe: -des3 optie aan de opdracht.

openssl genrsa -des3 -out upload.key 4096

Een bijwerking van de wachtwoordzin in de privésleutel is dat Apache de wachtwoordzin elke keer nodig heeft wanneer de webserver start. Dit is uiteraard niet altijd praktisch, omdat de persoon die de gegevens invoert niet altijd aanwezig is om de wachtwoordzin in te typen, bijvoorbeeld na een herstart of crash.

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

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.

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.

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?

Vanaf RFC 5280 (sleutelgebruik)Hieronder zijn de volgende uitbreidingen voor toetsgebruik 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 sleutel	Inschakelen voor deze sleutelgebruikextensies
TLS-webserverauthenticatie	Digitale handtekening, sleutelversleuteling of sleutelovereenkomst
TLS-webclientauthenticatie	Digitale handtekening en/of sleutelovereenkomst
Onderteken (downloadbare) uitvoerbare code	Digitale handtekening
E-mailbeveiliging	Digitale handtekening, onweerlegbaarheid en/of sleutelversleuteling of sleutelovereenkomst
IPSEC-eindsysteem (host of router)	Digitale handtekening en/of sleutelversleuteling of sleutelovereenkomst
IPSEC-tunnel	Digitale handtekening en/of sleutelversleuteling of sleutelovereenkomst

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

Uitgebreide sleutel	Inschakelen voor deze sleutelgebruikextensies
IPSEC-gebruiker	Digitale handtekening en/of sleutelversleuteling of sleutelovereenkomst
Tijdstempel	Digitale handtekening, onweerlegbaarheid.

Voor het gebruik van codeondertekening hebben we dus nodig: Digitale handtekening als sleutelgebruik en codeondertekening als verbeterd sleutelgebruik

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