Warum funktioniert Ihr Codesignaturzertifikat nicht für die Play App-Signatur?

In der heutigen Zeit nutzen Entwickler häufig den Google Play Store, um ihre Anwendungen für Google Android zu veröffentlichen. Bei der Veröffentlichung sollten jedoch einige Punkte beachtet werden, um die Sicherheit zu erhöhen. Dazu gehört beispielsweise die Verwendung eines selbstsignierten Zertifikats.

Selbstsignierte Zertifikate werden in der TLS-Welt im Allgemeinen nicht verwendet (außer zu Testzwecken). Im Codesign werden sie jedoch weiterhin verwendet. Insbesondere in der Android-Welt wird der selbstsignierte Schlüssel als „Upload-Schlüssel“ verwendet. Lassen Sie uns untersuchen, wie wir den „Upload-Schlüssel“ sicher generieren, aber bevor es …

Warum ein Standard-Codesignaturzertifikat für die Play-App-Signatur fehlschlägt: Google Play verlangt gemäß RFC 5280, dass das Upload-Schlüsselzertifikat bestimmte Erweiterungen für die Schlüsselverwendung (digitale Signatur) und die erweiterte Schlüsselverwendung (Codesignatur) enthält. Ein selbstsigniertes Zertifikat, das ohne explizite Angabe dieser Erweiterungen erstellt wurde, wird von der Play Console abgelehnt, obwohl es kryptografisch gültig ist. Die Lösung besteht darin, die Erweiterungen bereits bei der Generierung hinzuzufügen, nicht den Zertifikatstyp zu wechseln.

Wichtige Erkenntnisse

• Play-App-Signatur verwendet zwei unterschiedliche Schlüssel: den Upload-Schlüssel (selbstsigniert, dient nur zur Authentifizierung Ihres Uploads bei Google) und den App-Signaturschlüssel (der von Google verwaltet und zum Signieren der verteilten APK-Datei verwendet wird). Dieser Beitrag behandelt ausschließlich den Upload-Schlüssel.
• Die Verwendung eines separaten Upload-Schlüssels anstelle der Wiederverwendung Ihres App-Signaturschlüssels begrenzt den Wirkungsbereich eines Datenlecks: Ein kompromittierter Upload-Schlüssel kann nicht verwendet werden, um APKs zu fälschen, die Ihre App imitieren, da für die Verteilung tatsächlich der Signaturschlüssel von Google zählt.
• Für die hier erwähnten allgemeinen Zertifikats- und PKCS#11/HSM-Konzepte siehe Codesignierung 101: Absicherung Ihrer Software-Lieferkette.

Was ist ein Upload-Schlüssel?

Der Upload-Schlüssel ist die neue Methode zum Hochladen von APKs (Android Package Kit) in die Google Play App Signing, um sie für Nutzer zu veröffentlichen. Der Upload-Schlüssel stellt das Vertrauen zwischen Ihrem Unternehmen und Google her, um ein Android-Paket hochzuladen. Das Android-Paket muss vor dem Hochladen in die Play Console mit dem Upload-Schlüssel signiert werden. Er unterscheidet sich grundlegend vom App-Signaturschlüssel, mit dem das Android-Paket für die Verteilung signiert wird.

Daher verwendet Play App Signing zwei Schlüssel: den App-Signaturschlüssel und den Upload-Schlüssel. In diesem Artikel beziehen wir uns nur auf den Upload-Schlüssel.

Nachfolgend sehen Sie eine Abbildung zur Veranschaulichung des Signaturablaufs in Android:

Warum Upload-Schlüssel verwenden?

Wenn Sie Ihren App-Signaturschlüssel weiterhin für Ihre Releases verwenden, besteht das Risiko, dass der Schlüssel aufgrund menschlicher Fehler verloren geht. Angenommen, Sie verwenden einen separaten Upload-Schlüssel zum Signieren der Binärdateien, die Sie auf Ihrem Computer erstellen.

In diesem Fall kann der Upload-Schlüssel selbst dann nicht von böswilligen Dritten verwendet werden, wenn er kompromittiert ist, um APKs zu erstellen, die Ihre eigenen imitieren. Daher empfiehlt sich die Verwendung eines separaten Upload-Schlüssels.

Verwenden Sie aus Sicherheitsgründen immer die Option „Schlüssel aus Java Keystore exportieren und hochladen“.

Aber wie erstellen wir einen Upload-Schlüssel?

Zum Generieren eines Upload-Schlüssels werden selbstsignierte Zertifikate verwendet. Wir erläutern zunächst die vereinfachte Methode zur Erstellung eines selbstsignierten Schlüssels über OpenSSL und erläutern anschließend die Schwachstelle und Lösung dieses Ansatzes:

Eine einfache Möglichkeit, einen selbstsignierten Schlüssel über OpenSSL zu erstellen 

Generierung des privaten Schlüssels

Zuerst erstellen wir einen privaten Schlüssel. Der folgende Befehl erstellt mit dem OpenSSL-Befehl einen 4096-Bit-RSA-Private-Key (.key):

Wenn der private Schlüssel verschlüsselt werden soll, fügen Sie die Option -des3 zum Befehl hinzu.

Wenn der private Schlüssel verschlüsselt ist, ist zu beachten, dass für jede automatisierte Build- oder CI/CD-Pipeline, die den Upload signiert, die bei der Signierung angegebene Passphrase benötigt wird, da in diesem Kontext keine interaktive Eingabeaufforderung erfolgt. Wägen Sie diesen zusätzlichen Aufwand gegen den Sicherheitsvorteil ab, bevor Sie den Schlüssel für einen automatisierten Workflow verschlüsseln.

Erstellen einer Zertifikatsignieranforderung

Sie benötigen einen Certificate Signing Request (CSR), wenn Sie Ihr Zertifikat signieren lassen möchten. Der CSR enthält Ihren öffentlichen Schlüssel und weitere Informationen (Organisation, Land usw.).

Lassen Sie uns aus unserem vorhandenen privaten Schlüssel eine CSR (upload.csr) erstellen:

Erhalten des Zertifikats von CSR und generiertem Schlüssel

Sobald die CSR und der private Schlüssel generiert sind, besteht der nächste Schritt darin, das Zertifikat zu erstellen. Der folgende Befehl generiert das Zertifikat mit einer Gültigkeit von 365 Tagen:

Das erhaltene Zertifikat liegt im .crt-Format vor und enthält keinen privaten Schlüssel. Wir benötigen jedoch ein .pfx-Format (da es einen privaten Schlüssel enthält), um Dateien zu signieren. Mit dem folgenden Befehl konvertieren wir es in das .pfx-Format:

Diese PFX-Datei soll dann das Android Bundle signieren.

Klingt gut, oder? Die mit diesem Zertifikat signierten Dateien werden jedoch nicht im Playstore akzeptiert. Das liegt daran, dass das selbstsignierte Zertifikat keine Erweiterungen für die Schlüsselverwendung und erweiterte Schlüsselverwendung enthält. Um dies zu überprüfen, öffnen Sie Zertifikate in der MMC (Microsoft Management Console) und laden Sie das Zertifikat-Snap-In. Klicken Sie nach dem Öffnen des Zertifikats auf die Registerkarte Details.

Aber was sind Schlüsselverwendungserweiterungen?

Schlüsselverwendungserweiterungen (KU) definieren den Zweck des in einem Zertifikat enthaltenen öffentlichen Schlüssels. Ein einzelner Schlüssel sollte nur für einen Zweck verwendet werden.

Wie viele Schlüsselverwendungserweiterungen sind verfügbar und welche sollte ich wählen?

Gemäß RFC 5280 (Key Usage) stehen folgende Erweiterungen zur Schlüsselnutzung zur Verfügung:

• Digitale Unterschrift
• Nicht-Zurückweisung
• Schlüsselverschlüsselung
• Datenverschlüsselung
• Schlüsselvereinbarung
• Zertifikatssignierung
• CRL-Signierung
• Nur verschlüsseln
• Nur entziffern

Ähnlich verhält es sich mit der erweiterten Schlüsselverwendung (EKU). Je nach Anwendungsfall müssen die folgenden Werte ausgewählt werden:

Erweiterter Schlüssel	Aktivieren Sie diese Schlüsselverwendungserweiterungen
TLS-Webserver-Authentifizierung	Digitale Signatur, Schlüsselverschlüsselung oder Schlüsselvereinbarung
TLS-Webclient-Authentifizierung	Digitale Signatur und/oder Schlüsselvereinbarung
Signieren Sie (herunterladbaren) ausführbaren Code	Digitale Unterschrift
E-Mail-Schutz	Digitale Signatur, Nichtabstreitbarkeit und/oder Schlüsselverschlüsselung bzw. Schlüsselvereinbarung
IPSEC-Endsystem (Host oder Router)	Digitale Signatur und/oder Schlüsselverschlüsselung bzw. Schlüsselvereinbarung
IPSEC-Tunnel	Digitale Signatur und/oder Schlüsselverschlüsselung bzw. Schlüsselvereinbarung
IPSEC-Benutzer	Digitale Signatur und/oder Schlüsselverschlüsselung bzw. Schlüsselvereinbarung
Zeitstempeln	Digitale Signatur, Nichtabstreitbarkeit.

Für den Anwendungsfall der Codesignierung benötigen wir daher die digitale Signatur als Schlüsselverwendung und die Codesignierung als erweiterte Schlüsselverwendung.

Wie füge ich nun KU- und EKU-Erweiterungen zu meinem Zertifikat hinzu?

Um sie hinzuzufügen, müssen wir den folgenden Befehl in OpenSSL ausführen:

Kennzahlen:

CN = Allgemeiner Name des Zertifikats (im Allgemeinen der Organisationsname bei der Code-Signierung)

C= Ländername

OU = Organisationseinheit (z. B. Engineering, IT usw.)

O=Name der Organisation

Dadurch wird das erforderliche Codesignaturzertifikat mit den Erweiterungen „Schlüsselverwendung“ und „Erweiterte Schlüsselverwendung“ generiert.

Dieses Zertifikat kann jetzt erfolgreich zum Hochladen des Android-Pakets in die Google Play App Signing Console verwendet werden.

Häufig gestellte Fragen

Ist mein bestehendes Enterprise-Codesignaturzertifikat das falsche Werkzeug dafür, oder fehlt mir einfach nur eine Erweiterung?

Es fehlt lediglich eine Erweiterung. Die Play Console lehnt das Zertifikat ab, weil die Erweiterungen „Digital Signature Key Usage“ und „Code Signing Extended Key Usage“ fehlen, nicht weil es der falsche Zertifikatstyp ist. Die Neuerstellung mit dem korrekten Zertifikat wird durchgeführt. -addext Das Problem lässt sich mit flags lösen.

Muss der Upload-Schlüssel derselbe Schlüssel sein, mit dem die endgültig verteilte APK-Datei signiert wird?

Nein. Bei der Play-App-Signatur speichert und verwendet Google den separaten App-Signaturschlüssel, um die App zu signieren, die tatsächlich an die Nutzer ausgeliefert wird. Der Upload-Schlüssel authentifiziert lediglich, dass das von Ihnen eingereichte Paket von Ihnen stammt.

Was passiert, wenn mein Upload-Schlüssel kompromittiert wird?

Google bietet einen Prozess zum Zurücksetzen des Upload-Schlüssels Ihrer App an, da Google und nicht Sie den eigentlichen Signaturschlüssel für die App-Verteilung kontrollieren. Genau darin liegt der Vorteil der Trennung der beiden Schlüssel.

Fazit

Die Lösung besteht nicht in einem anderen Zertifikat, sondern in den richtigen Erweiterungen des bereits bekannten Zertifikats. Legen Sie bei der Generierung „Digitale Signatur“ als Schlüsselverwendung und „Codesignierung“ als erweiterte Schlüsselverwendung fest. Der gleiche OpenSSL-basierte Upload-Workflow funktioniert dann auch für die Signierung von Play-Apps.