I den moderna världen Google Play App används flitigt av utvecklare för att publicera sina applikationer med Google Android. Men när det gäller att publicera det måste man tänka på några nyanser för bättre säkerhet. En sådan är ett självsignerat certifikat.

Självsignerade certifikat används generellt sett inte i TLS-världen (förutom för teständamål). Däremot används de fortfarande inom samdesign. Särskilt i Android-världen, där den självsignerade nyckeln används för "uppladdningsnyckeln". Låt oss utforska hur vi genererar "uppladdningsnyckeln" på ett säkert sätt, men innan den...

Vad är uppladdningsnyckel?

Uppladdningsnyckeln är den nya metoden för att ladda upp APK:er (Android Package Kit) till Google Play App Signing för publicering till användare. Uppladdningsnyckeln skapar förtroende mellan ditt företag och Google för att ladda upp ett Android-paket. Android-paketet måste signeras med uppladdningsnyckeln innan det laddas upp till Play Console. Det är helt annorlunda än den appsigneringsnyckel som används för att signera Android-paketet för distribution.

Därför använder Play App Signing två nycklar: appsigneringsnyckeln och uppladdningsnyckeln. Vi kommer endast att referera till uppladdningsnyckeln i den här artikeln.

Nedan följer en figur som illustrerar signeringsflödet i Android:

Varför använda uppladdningsnyckel?

Om du fortsätter att använda din appsigneringsnyckel för dina utgåvor riskerar du att nyckeln läcker på grund av mänskliga fel. Anta dock att du använder en separat uppladdningsnyckel för att signera de binärfiler du producerar på din dator.

I så fall, även om uppladdningsnyckeln är komprometterad, kan den inte användas av en illvillig tredje part för att skapa APK-filer som utger sig för att vara din egen. Därför anses det vara bästa praxis att använda en separat uppladdningsnyckel.

med hjälp av en separat uppladdningsnyckel

Använd alltid alternativet "Exportera och ladda upp en nyckel från Java Keystore" ur säkerhetssynpunkt.

Men hur skapar vi en uppladdningsnyckel?

Självsignerade certifikat används för att generera en uppladdningsnyckel. Vi kommer först att diskutera det förenklade sättet som vanligtvis används för att skapa en självsignerad nyckel via OpenSSL och senare diskutera bristen och lösningen bakom denna metod:

Ett enkelt sätt att skapa en självsignerad nyckel via OpenSSL

Generering av privat nyckel

Först skapar vi en privat nyckel. Kommandot nedan skapar en 4096-bitars RSA privat nyckel (.key) med OpenSSL-kommandot:

openssl genrsa -out upload.key 4096

Om vi vill att den privata nyckeln ska krypteras, lägg till -des3 alternativ till kommandot.

openssl genrsa -des3 -out upload.key 4096

En bieffekt av den lösenfraserade privata nyckeln är att Apache kräver lösenfrasen varje gång webbservern startar. Detta är uppenbarligen inte alltid praktiskt eftersom personen som matar in informationen inte alltid är i närheten för att skriva in lösenfrasen, till exempel efter en omstart eller krasch.

Skapa en begäran om certifikatsignering

Du behöver en certifikatsigneringsförfrågan (CSR) om du vill att ditt certifikat ska signeras. CSR:n innehåller din publika nyckel och ytterligare information (organisation, land etc.)

Låt oss skapa en CSR (upload.csr) från vår befintliga privata nyckel:

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

Hämtar certifikat från CSR och genererar nyckel

När CSR och privat nyckel har genererats är nästa steg att skapa certifikatet. Kommandot nedan genererar certifikatet med 365 dagars giltighet:

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

skapa certifikat med 365 dagars giltighet

Det mottagna certifikatet är i .crt-format, utan privat nyckel, och vi vill ha ett .pfx-format (eftersom det innehåller en privat nyckel) för att signera filer. Vi använder kommandot nedan för att konvertera det till pfx:

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

När lösenordet har angetts genereras en .pfx-fil.

Denna pfx-fil ska sedan signera Android-paketet.

Låter bra, eller hur? Filer som signerats via detta certifikat accepteras dock inte i Playstore. Detta beror på att det självsignerade certifikatet inte innehåller tilläggen Key Usage och Enhanced Key Usage. För att se detta, öppna Certifikat i MMC (Microsoft Management Console) och ladda snapin-modulen Certifikat. När du har öppnat certifikatet klickar du på fliken Detaljer.

Men vad är nyckelanvändningstillägg?

Nyckelanvändningstillägg (KU) definierar syftet med den publika nyckeln i ett certifikat. En enda nyckel bör endast användas för ett syfte.

Hur många nyckelanvändningstillägg finns tillgängliga, och vilket ska jag välja?

Enligt RFC 5280 (nyckelanvändning), nedanstående nyckelanvändningstillägg är tillgängliga:

Digital signatur
Icke förkastande
Nyckelkryptering
Datakryptering
Viktigt avtal
Certifikatssignering
CRL-signering
Endast kryptering
Endast dechiffrera

På samma sätt måste följande värden väljas för utökad nyckelanvändning (EKU), beroende på användningsfall:

Utökad nyckel	Aktivera för dessa nyckelanvändningstillägg
TLS-webbserverautentisering	Digital signatur, nyckelkryptering eller nyckelavtal
TLS Web-klientautentisering	Digital signatur och/eller nyckelavtal
Signera (nedladdningsbar) körbar kod	Digital signatur
E -postskydd	Digital signatur, oavvislighet och/eller nyckelkryptering eller nyckelavtal
IPSEC-slutsystem (värd eller router)	Digital signatur och/eller nyckelkryptering eller nyckelavtal
IPSEC-tunneln	Digital signatur och/eller nyckelkryptering eller nyckelavtal

På samma sätt måste följande värden väljas för utökad nyckelanvändning (EKU), beroende på användningsfall:

Utökad nyckel	Aktivera för dessa nyckelanvändningstillägg
IPSEC-användare	Digital signatur och/eller nyckelkryptering eller nyckelavtal
Tidsstämpling	Digital signatur, oavvislig.

Således, för användningsfallet kodsignering, behöver vi Digital signatur som nyckelanvändning och kodsignering som utökad nyckelanvändning

Hur lägger jag nu till KU- och EKU-tillägg i mitt certifikat?

För att lägga till dem måste vi köra följande kommando i OpenSSL:

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

Var:

CN = Certifikatets vanliga namn (vanligtvis organisationsnamn vid kodsignering)

C= Landsnamn

OU = Organisationsenhet (t.ex. teknik, IT, etc.)

O= Organisationsnamn