APK-Signaturschema v3.2

Mit Android 17 (API-Level 37) wird das APK-Signaturschema v3.2 eingeführt, ein hybrides Signaturschema, das den Übergang des Android-Ökosystems zur Post-Quanten-Kryptografie (PQC) unterstützen soll.

Da die Branche PQC-Algorithmen in großem Maßstab einsetzt, bietet das v3.2-Schema eine umfassende Verteidigung. Sie müssen APKs sowohl mit einem klassischen Algorithmus wie RSA oder ECDSA als auch mit einem PQC-Algorithmus signieren. Dieser hybride Ansatz verwendet klassische Kryptografie, um Ihr APK zu schützen und gleichzeitig vor Bedrohungen durch Quantencomputer zu schützen.

Zweck und Details

Das v3.2-Schema funktioniert als standardmäßiger, branchenkonformer Übergangsmechanismus. Mit diesem hybriden Ansatz profitieren Sie von den quantenresistenten Vorteilen von PQC und können sich gleichzeitig auf die bewährte Sicherheit klassischer Signaturalgorithmen verlassen. Sobald die neu standardisierten PQC-Algorithmen in großem Maßstab betriebliche Reife erreicht haben, können Sie von dieser Hybridkonfiguration zu einem einzelnen PQC-Signaturschlüssel wechseln. Die Plattformunterstützung für das v3.2-Signaturschema beginnt mit Android 17. Bei niedrigeren Android-Versionen wird der v3.2-Block übersprungen und frühere Schemas für die Signaturprüfung verwendet.

Um die Sicherheit zu gewährleisten und Downgrade-Angriffe während dieses Übergangs zu verhindern, erzwingt das v3.2-Schema die folgenden Verhaltensweisen:

  • Neues Schlüsselmaterial:Für den Übergang zu einem Hybridblock müssen neue klassische und PQC-Schlüssel generiert werden. Verwenden Sie kein Schlüsselmaterial zwischen Hybrid- und Nicht-Hybridkonfigurationen wieder.
  • Implizite Rotation:Die Plattform behandelt den Hybridblock als implizite Schlüsselrotation. Die Plattform fügt den neuen klassischen Schlüssel als vorletzten Schlüssel der vorhandenen Signaturkette der App hinzu und behandelt den neuen PQC-Schlüssel als aktuelle Signaturidentität der App.
  • Gemeinsame Kette:Damit die implizite Rotation erfolgreich ausgeführt werden kann, müssen sowohl der neue klassische Schlüssel als auch der neue PQC-Schlüssel im Hybridblock dieselbe Signaturkette haben. Sie müssen die vorhandene Signaturkette der App – entweder ein einzelner ursprünglicher Schlüssel oder eine Kette zuvor rotierter Schlüssel – für beide neuen hybriden Signierer duplizieren. Die Plattform verwendet diese gemeinsame Kette, um zu prüfen, ob die Entität, die die App auf das Hybridschema umstellt, der rechtmäßige Inhaber der aktuellen Signaturidentität der App ist.
  • Einschränkung für einzelne PQC-Signierer:Während der ersten Einführung von PQC beschränkt Android die Verwendung von PQC-Algorithmen ausdrücklich auf den v3.2-Hybridblock. Die Plattform prüft keine PQC-Konfiguration mit einem einzelnen Signierer mit früheren Signaturschemas wie v2, v3.0 oder v3.1.
  • Zurückwechseln:Wenn Sie von einem v3.2-Hybridblock zu einem Block mit einem einzelnen Signierer wechseln – entweder einem klassischen Signierer oder einem PQC-Signierer, wenn dies in einer zukünftigen Version unterstützt wird –, prüft die Plattform, ob sowohl die klassischen als auch die PQC-Schlüssel aus dem Hybridblock in der neuen Signaturkette vorhanden sind und den neuen einzelnen Signierer bestätigen.

Best Practices für den Übergang

Um die Kompatibilität mit niedrigeren Android-Versionen aufrechtzuerhalten und einen sicheren Upgrade-Pfad während des Übergangs zur PQC-Signierung zu bieten, müssen APKs weiterhin einen standardmäßigen v3.0- oder v3.1-Signaturblock enthalten, der mit einem einzelnen klassischen Schlüssel signiert ist. Da nur Android 17 (API-Level 37) und höher das v3.2-Hybridschema unterstützen, können Geräte mit niedrigeren Versionen die App mit dieser Anforderung prüfen und installieren.

Klassische Fallback-Konfiguration

Implementieren Sie eine klassische Fallback-Konfiguration, um während des PQC-Übergangs ein betriebliches Sicherheitsnetz zu bieten.

  • Vorhandene Apps:Der aktuelle Signaturschlüssel der App, K0, dient als natürliche Grundlage für diesen Fallback.
  • Neue Apps:Generieren Sie neben den neuen Hybridschlüsseln C_K1 und PQC_K1 einen klassischen Basissignaturschlüssel, K0, um die anfängliche Identität festzulegen.

In beiden Szenarien muss das APK einen standardmäßigen v3.0- oder v3.1-Signaturblock enthalten, der mit dem klassischen Schlüssel K0 signiert ist, sowie den v3.2-Hybridblock, der mit den neuen Hybridschlüsseln C_K1 und PQC_K1 signiert ist.

Bei der ersten Bereitstellung des v3.2-Schemas sollte die Signaturkette für den Hybridblock die ROLLBACK-Funktion für K0 gewähren. Wenn Probleme bei der Bereitstellung auftreten, kann die App mit dieser Funktion auf eine klassische Signatur zurückgreifen, ohne dass Nutzerupdates unterbrochen werden. Sobald genügend Laufzeitdaten bestätigen, dass die Hybridbereitstellung stabil ist, empfehlen wir, die ROLLBACK-Funktion in nachfolgenden Updates zu entfernen, um Ihre neuen Schlüssel vollständig zu schützen.

Anforderungen an die langfristige Konfiguration

Sie müssen diese hybride Signaturkonfiguration so lange beibehalten, wie Ihre App auf eine Plattformversion ausgerichtet ist, die ausschließlich das Hybridschema unterstützt. Auch wenn eine Plattformversion PQC-Schlüssel mit einem einzelnen Signierer unterstützt, müssen Sie alle APKs, die auf eine Version ausgerichtet sind, für die der v3.2-Hybridblock erforderlich ist, mit beiden Schlüsseln signieren.

APK-Signaturschema v3.2-Block

Im APK-Signaturblock wird der v3.2-Signaturblock zusammen mit allen v2-, v3.0- und v3.1-Signaturblöcken gespeichert.

Die v3.2-Blockstruktur ähnelt v3.0, verwendet aber eine neue Block-ID, 0x70e1c89f, um anzugeben, dass es sich um einen Hybridblock handelt. Ein gültiger v3.2-Block muss genau zwei Signierer enthalten.

Unterstützte Algorithmen

Das v3.2-Schema unterstützt zunächst die folgenden PQC-Signaturalgorithmen:

  • ML-DSA-65
  • ML-DSA-87

Diese werden mit klassischen Standardsignaturalgorithmen wie den in v3.0 und v3.1 unterstützten Algorithmen kombiniert, um den Hybridblock zu bilden.

Format

Im APK-Signaturblock wird der APK-Signaturschema v3.2-Block unter der ID 0x70e1c89f gespeichert.

Das Format des v3.2-Blocks ist mit v3.0 identisch, aber die Sequenz der Signiererelemente auf oberster Ebene muss genau zwei Einträge enthalten, die auf dieselbe SDK-Version ausgerichtet sind:

  • Sequenz mit Längenpräfix von Signierern mit Längenpräfix:
    • Signierer mit Längenpräfix (klassisch)
    • Signierer mit Längenpräfix (PQC)

Jeder Signierer verwendet das Standardformat v3:

  • Signierte Daten mit Längenpräfix:
    • Sequenz mit Längenpräfix von Digests mit Längenpräfix:
    • Signaturalgorithmus-ID (4 Byte)
    • Digest (mit Längenpräfix)
    • Sequenz mit Längenpräfix von Zertifikaten:
    • X.509-Zertifikat mit Längenpräfix (ASN.1 DER-Form)
    • minSDK (uint32)
    • maxSDK (uint32)
    • Sequenz mit Längenpräfix von zusätzlichen Attributen mit Längenpräfix:
    • ID (uint32)
    • Wert (variable Länge: Länge des zusätzlichen Attributs – 4 Byte)
  • minSDK (uint32)
  • maxSDK (uint32)
  • Sequenz mit Längenpräfix von Signaturen mit Längenpräfix:
    • Signaturalgorithmus-ID (4 Byte)
    • Signatur mit Längenpräfix über signierte Daten
  • Öffentlicher Schlüssel mit Längenpräfix (SubjectPublicKeyInfo, ASN.1 DER-Form)

Überprüfung

Unter Android 17 (API-Level 37) und höher prüft die Plattform zur Überprüfung der v3.2-Signatur sowohl die klassischen als auch die PQC-Signierer, bestätigt ihre Kompatibilität und prüft die implizite Rotationskette. Bei Plattformversionen unter Android 16 (API-Level 36) verarbeitet die Plattform diesen hybriden Signaturblock nicht und verwendet stattdessen frühere Schemas.

Der Gesamtprozess sieht so aus:

  1. Suchen Sie den APK-Signaturschema v3.2-Block (ID 0x70e1c89f).
  2. Prüfen Sie, ob der Block genau zwei Signierer enthält. Wenn es weniger oder mehr als zwei sind, schlägt die Überprüfung fehl.
  3. Prüfen Sie, ob ein Signierer einen klassischen Signaturalgorithmus und der andere einen PQC-Signaturalgorithmus verwendet. Wenn beide klassisch oder beide PQC sind, schlägt die Überprüfung fehl.
  4. Prüfen Sie, ob beide Signierer auf denselben SDK-Bereich (minSdkVersion und maxSdkVersion) ausgerichtet sind.
  5. Führen Sie für jeden der beiden Signierer die Standardprüfung v3 aus:
    1. Wählen Sie die stärkste unterstützte Signaturalgorithmus-ID aus den Signaturen aus.
    2. Prüfen Sie die entsprechende Signatur aus den Signaturen anhand der signierten Daten mit dem öffentlichen Schlüssel.
    3. Prüfen Sie, ob minSdkVersion und maxSdkVersion in den signierten Daten mit den unsignierten minSdkVersion und maxSdkVersion übereinstimmen.
    4. Analysieren Sie die Zertifikate und prüfen Sie, ob das erste Zertifikat mit dem öffentlichen Schlüssel übereinstimmt.
    5. Analysieren Sie zusätzliche Attribute, um Strukturen für den Rotationsnachweis zu extrahieren.
  6. Prüfen Sie die Signaturkette (Rotationsnachweis):
    1. Prüfen Sie, ob beide Signierer identische vorherige Signaturketten haben.
    2. Die Kettenlängen müssen übereinstimmen und alle Zertifikate und Fähigkeitsflags, die zu den aktuellen Signierern führen, müssen identisch sein.
    3. Wenn die Ketten übereinstimmen, führen Sie die Ketten zusammen: Behandeln Sie das Zertifikat des klassischen Signierers als Vorgänger des Zertifikats des PQC-Signierers und weisen Sie den PQC-Signierer als aktuellen Endknoten zu.
  7. Prüfen Sie die Inhalts-Digests:
    1. Wiederholen Sie die Digests-Zuordnung für beide Signierer.
    2. Prüfen Sie, ob die berechneten Digest-Werte für alle übereinstimmenden Digest-Algorithmen zwischen den klassischen und PQC-Signierern identisch sind.
  8. Verwenden Sie die übereinstimmenden Digests der geprüften Signierer, um die Integrität der APK-Inhalte zu prüfen (ähnlich wie bei v2 und v3).
    1. Wenn die App bereits installiert ist, prüfen Sie die Kette des Paketupdates:
    2. Aktualisierung von einem einzelnen Signierer: Wenn die installierte App mit einem einzelnen klassischen Schlüssel signiert wurde, muss dieser Schlüssel in der Signaturkette des neuen Hybridblocks als Vorgänger der hybriden Signierer vorhanden sein.
    3. Aktualisierung von einem hybriden Signierer, um hybrid zu bleiben: Wenn die installierte App mit einem v3.2-Hybridblock signiert wurde, müssen sowohl der vorherige klassische als auch der vorherige PQC-Schlüssel entweder die aktuellen aktiven Signierer im v3.2-Block des Update-APKs bleiben oder beide müssen in der neuen Signaturkette vorhanden sein, die die neu rotierten Hybridschlüssel bestätigt.
    4. Übergang von einem hybriden Signierer: Wenn die installierte App mit einem v3.2-Hybridblock signiert wurde und das Update-APK wieder zu einem einzelnen Signierer (entweder PQC oder klassisch) wechselt, müssen beide vorherigen hybriden Signierer in der Signaturkette des Update-APKs vorhanden sein und den neuen einzelnen Signaturschlüssel bestätigen.
    5. Ungültige Update-Pfade: Wenn ein Entwickler versucht, eine hybrid signierte App mit nur einem der Hybridschlüssel als einzelnen Signierer ohne ordnungsgemäße Rotation zu aktualisieren, schlägt das Update fehl. Beide Schlüssel müssen ausdrücklich an jedem Übergang beteiligt sein, um Downgrade-Angriffe zu verhindern.
  9. Wenn ein Schritt fehlschlägt, schlägt die Überprüfung fehl.

Schutz vor Entfernung

Um Downgrade-Angriffe auf niedrigere Signaturschemas zu verhindern, enthält das v3.2-Schema ähnliche Attribute zum Schutz vor Entfernung wie frühere Schemaversionen.

Das Signaturtool schreibt zwei spezifische Attribute zum Schutz vor Entfernung in die zusätzlichen Attribute der v3.0- und v3.1-Signaturblöcke. Diese Attribute definieren die genauen SDK-Versionsgrenzen, innerhalb derer der v3.2-Hybridblock vorhanden sein und geprüft werden muss:

  • Attribut für die Mindest-SDK-Version (ID 0xbf940529): Der Wert dieses Attributs gibt die Mindest-SDK-Version an, die vom hybriden Signaturblock unterstützt wird.
  • Attribut für die maximale SDK-Version (ID 0x9f06b79c): Der Wert dieses Attributs gibt die maximale SDK-Version an, die vom hybriden Signaturblock unterstützt wird. Mit diesem Attribut können Sie zu einer Konfiguration mit einem einzelnen Signierer wechseln, wenn für höhere Plattformversionen die hybride Signatur nicht erforderlich ist.

Wenn die Plattform die v3.2-Überprüfung überspringt, weil der Block fehlt oder der SDK-Bereich nicht auf das Gerät zutrifft, prüft die Plattform das APK anhand des nächsten vorhandenen Blocks. Wenn dieser frühere Block diese Attribute zum Schutz vor Entfernung enthält, führt die Plattform die folgenden Prüfungen durch:

  • Prüfung auf Vorhandensein und Bereich:Wenn ein v3.0- oder v3.1-Signaturblock entweder das Attribut für die Mindest-SDK-Version (ID 0xbf940529, Wert X) oder das Attribut für die maximale SDK-Version (ID 0x9f06b79c, Wert Y) enthält, muss der v3.2-Hybridblock im APK vorhanden sein. Die Plattform liest den Hybridblock, um zu prüfen, ob der Ziel-SDK-Bereich mit den durch diese Attribute angegebenen Grenzen übereinstimmt. Wenn der v3.2-Block fehlt oder die internen Zielwerte für die Mindest- und Maximal-SDK-Version nicht X und Y entsprechen, lehnt die Plattform die Installation ab.
  • Erzwingung innerhalb des Bereichs: Wenn die SDK-Version des Geräts innerhalb des gültigen Bereichs liegt, der durch diese Attribute angegeben wird – also größer oder gleich X und kleiner oder gleich Y ist, wenn Sie das Attribut für die maximale SDK-Version angeben –, ist der v3.2-Hybridblock für die Signaturprüfung unbedingt erforderlich. Wenn die Plattform einen v3.0- oder v3.1-Block auf einem Gerät innerhalb dieses Ziel-SDK-Bereichs prüft, lehnt die Plattform die Installation ab, da der v3.2-Block böswillig umgangen oder entfernt wurde.

Durch die Erzwingung dieser Grenzen bestimmt die Plattform, wann ein APK einen v3.2-Block enthalten muss. Wenn der Block entfernt wurde, lehnt die Plattform die Installation ab, um einen Downgrade-Angriff zu verhindern.

Implementierung validieren

Um Ihre Implementierung des v3.2-Signaturschemas zu testen, führen Sie die CTS-Tests HybridSignatureVerificationTest.java aus, die sich in cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ befinden.

Diese Tests decken eine umfassende Reihe von Szenarien ab, darunter erfolgreiche Installationen, Updates von Versionen, die nur klassisch signiert sind, Rollback-Übergänge mit der ROLLBACK-Funktion und Prüfungen von Maßnahmen zur Abschwächung von Angriffen durch Entfernung.