APK-Signaturschema v3

Android 9 unterstützt die APK-Schlüsselrotation , mit der Apps ihren Signaturschlüssel im Rahmen eines APK-Updates ändern können. Um die Rotation praktisch zu gestalten, müssen APKs das Vertrauensniveau zwischen dem neuen und dem alten Signaturschlüssel angeben. Um die Schlüsselrotation zu unterstützen, haben wir das APK-Signaturschema von Version 2 auf Version 3 aktualisiert, damit die neuen und alten Schlüssel verwendet werden können. V3 fügt dem APK-Signaturblock Informationen zu den unterstützten SDK-Versionen und eine Rotationsnachweisstruktur hinzu.

Hinweis : Die Drehung der APK-Schlüssel wird vor der Veröffentlichung von Android 11 nicht empfohlen. Entwickler haben die Möglichkeit, das Schlüssel-Upgrade von Google Play für Neuinstallationen zu verwenden. Entwickler, die bei Play App Signing registriert sind, können über die Play-Konsole ein Upgrade anfordern.

APK Signing Block

Um die Abwärtskompatibilität mit dem APK-Format v1 aufrechtzuerhalten, werden APK-Signaturen v2 und v3 in einem APK-Signaturblock gespeichert, der sich unmittelbar vor dem ZIP-Zentralverzeichnis befindet.

Das v3 APK Signing Block-Format ist das gleiche wie in v2 . Die v3-Signatur der APK wird als ID-Wert-Paar mit der ID 0xf05368c0 gespeichert.

APK Signature Scheme v3 Block

Das v3-Schema ist dem v2-Schema sehr ähnlich. Es hat das gleiche allgemeine Format und unterstützt die gleichen IDs , Schlüsselgrößen und EC-Kurven des Signaturalgorithmus .

Das v3-Schema fügt jedoch Informationen zu den unterstützten SDK-Versionen und der Rotationsnachweisstruktur hinzu.

Format

Der Block APK Signature Scheme v3 wird im APK Signing Block unter der ID 0xf05368c0 .

Das Format des Blocks APK Signature Scheme v3 folgt dem von v2:

• Sequenz mit Längenpräfix des signer mit Längenpräfix:
  • signed data Längenpräfix:
    • Sequenz mit Längenpräfix von Digests mit digests :
      • signature algorithm ID (4 Bytes)
      • digest (mit Längenpräfix)
    • Längenpräfixierte Sequenz von X.509- certificates :
      • X.509- certificate Längenpräfix (ASN.1 DER-Formular)
    • minSDK (uint32) - Dieser Unterzeichner sollte ignoriert werden, wenn die Plattformversion unter dieser Nummer liegt.
    • maxSDK (uint32) - Dieser Unterzeichner sollte ignoriert werden, wenn die Plattformversion über dieser Nummer liegt.
    • Längenpräfix-Sequenz von additional attributes mit Längenpräfix:
      • ID (uint32)
      • value (variable Länge: Länge des zusätzlichen Attributs - 4 Bytes)
      • ID - 0x3ba06f8c
      • value - Rotationsnachweisstruktur
  • minSDK (uint32) - Duplikat des minSDK-Werts im Abschnitt mit signierten Daten - wird verwendet, um die Überprüfung dieser Signatur zu überspringen, wenn sich die aktuelle Plattform nicht in Reichweite befindet. Muss mit dem signierten Datenwert übereinstimmen.
  • maxSDK (uint32) - Duplikat des maxSDK-Werts im Abschnitt mit signierten Daten - wird verwendet, um die Überprüfung dieser Signatur zu überspringen, wenn sich die aktuelle Plattform nicht in Reichweite befindet. Muss mit dem signierten Datenwert übereinstimmen.
  • Längenpräfix-Sequenz von Längenpräfix- signatures :
    • signature algorithm ID (uint32)
    • signature Längenpräfix über signed data
  • public key Längenpräfix (SubjectPublicKeyInfo, ASN.1 DER-Formular)

Proof-of-Rotation- und Self-Trusted-Old-Certs-Strukturen

Mit der Proof-of-Rotation-Struktur können Apps ihr Signaturzertifikat drehen, ohne für andere Apps blockiert zu werden, mit denen sie kommunizieren. Um dies zu erreichen, enthalten App-Signaturen zwei neue Daten:

• Behauptung für Dritte, dass das Signaturzertifikat der App überall dort vertrauenswürdig ist, wo ihre Vorgänger vertrauenswürdig sind
• Ältere Signaturzertifikate der App, denen die App selbst noch vertraut

Das Rotationsnachweisattribut im Abschnitt mit signierten Daten besteht aus einer einfach verknüpften Liste, wobei jeder Knoten ein Signaturzertifikat enthält, mit dem frühere Versionen der App signiert wurden. Dieses Attribut soll die konzeptionellen Rotationsnachweise und selbst vertrauenswürdigen Datenstrukturen für alte Zertifikate enthalten. Die Liste ist nach Versionen sortiert, wobei das älteste Signaturzertifikat dem Stammknoten entspricht. Die Proof-of-Rotation-Datenstruktur wird erstellt, indem das Zertifikat in jedem Knoten das nächste in der Liste signiert und somit jedem neuen Schlüssel der Nachweis erbracht wird, dass er genauso vertrauenswürdig sein sollte wie der / die ältere (n) Schlüssel.

Die Self-Trusted-Old-Certs-Datenstruktur wird erstellt, indem jedem Knoten Flags hinzugefügt werden, die seine Mitgliedschaft und Eigenschaften in der Gruppe angeben. Beispielsweise kann ein Flag vorhanden sein, das angibt, dass das Signaturzertifikat an einem bestimmten Knoten zum Abrufen von Android-Signaturberechtigungen vertrauenswürdig ist. Mit diesem Flag können anderen vom älteren Zertifikat signierten Apps weiterhin eine Signaturberechtigung erteilt werden, die von einer mit dem neuen Signaturzertifikat signierten App definiert wurde. Da sich das gesamte Rotationsnachweisattribut im Abschnitt mit den signierten Daten des Felds v3 signer befindet, wird es durch den Schlüssel geschützt, der zum Signieren der enthaltenen apk verwendet wird.

Dieses Format schließt mehrere Signaturschlüssel und die Konvergenz verschiedener Ahnen-Signaturzertifikate zu einem aus (mehrere Startknoten zu einer gemeinsamen Senke).

Format

Der Rotationsnachweis wird im Block APK Signature Scheme v3 unter der ID 0x3ba06f8c . Sein Format ist:

• Längenpräfix-Sequenz von Längenpräfix- levels :
  • Vorzeichenbehaftete signed data (mit vorherigem Zertifikat - falls vorhanden)
    • X.509- certificate Längenpräfix (ASN.1 DER-Formular)
    • signature algorithm ID (uint32) - Algorithmus, der von cert in der vorherigen Ebene verwendet wurde
  • flags (uint32) - Flags, die angeben, ob und für welche Vorgänge dieses Zertifikat in der Struktur "self-trusted old-certs" enthalten sein soll.
  • signature algorithm ID (uint32) - muss mit der signature algorithm ID aus dem Abschnitt mit den signierten Daten in der nächsten Ebene übereinstimmen.
  • signature Längenpräfix über den oben signed data

Mehrere Zertifikate

Android behandelt derzeit eine mit mehreren Zertifikaten signierte APK mit einer eindeutigen Signaturidentität, die von den umfassenden Zertifikaten getrennt ist. Somit bildet das Rotationsnachweisattribut im Abschnitt mit vorzeichenbehafteten Daten einen gerichteten azyklischen Graphen, der besser als einfach verknüpfte Liste angesehen werden kann, wobei jeder Satz von Unterzeichnern für eine bestimmte Version einen Knoten darstellt. Dies erhöht die Komplexität der Rotationsnachweisstruktur (Multi-Signer-Version unten). Insbesondere die Bestellung wird zum Problem. Darüber hinaus ist es nicht mehr möglich, APKs unabhängig voneinander zu signieren, da in der Proof-of-Rotation-Struktur die alten Signaturzertifikate die neuen Zertifikate signieren müssen, anstatt sie einzeln zu signieren. Beispielsweise könnte eine mit Schlüssel A signierte APK, die mit zwei neuen Schlüsseln B und C signiert werden möchte, nicht dazu führen, dass der B-Signierer nur eine Signatur von A oder B enthält, da dies eine andere Signaturidentität als B und C ist bedeuten, dass die Unterzeichner koordinieren müssen, bevor sie eine solche Struktur aufbauen.

Rotationsnachweisattribut für mehrere Unterzeichner

• Längenpräfix-Sequenz von Längenpräfix- sets :
  • signed data (vom vorherigen Satz - falls vorhanden)
    • Länge von certificates Längenpräfix
      • X.509- certificate Längenpräfix (ASN.1 DER-Formular)
    • Sequenz der signature algorithm IDs (uint32) - eine für jedes Zertifikat aus dem vorherigen Satz in derselben Reihenfolge.
  • flags (uint32) - Flags, die angeben, ob und für welche Vorgänge sich diese Gruppe von Zertifikaten in der Struktur "Self-Trusted-Old-Certs" befinden soll.
  • Längenpräfix-Sequenz von Längenpräfix- signatures :
    • signature algorithm ID (uint32) - muss mit der signature algorithm ID aus dem Abschnitt mit den signierten Daten übereinstimmen
    • signature Längenpräfix über den oben signed data

Mehrere Vorfahren in Rotationsnachweisstruktur

Das v3-Schema verarbeitet auch nicht zwei verschiedene Schlüssel, die für dieselbe App auf denselben Signaturschlüssel gedreht werden. Dies unterscheidet sich vom Fall einer Akquisition, bei der das erwerbende Unternehmen die erworbene App verschieben möchte, um mithilfe des Signaturschlüssels Berechtigungen zu teilen. Die Erfassung wird als unterstützter Anwendungsfall angesehen, da die neue App durch ihren Paketnamen unterschieden wird und eine eigene Rotationsnachweisstruktur enthalten könnte. Der nicht unterstützte Fall, dass dieselbe App zwei verschiedene Pfade hat, um zum selben Zertifikat zu gelangen, bricht viele der Annahmen, die im Design der Schlüsselrotation getroffen wurden.

Überprüfung

In Android 9 und höher können APKs gemäß dem APK-Signaturschema v3, v2 oder v1 überprüft werden. Ältere Plattformen ignorieren v3-Signaturen und versuchen, v2-Signaturen und dann v1 zu überprüfen.

Abbildung 1. Überprüfungsprozess der APK-Signatur

Überprüfung des APK-Signaturschemas v3

1. Suchen Sie den APK-Signaturblock und überprüfen Sie Folgendes:
   1. Zwei Größenfelder des APK-Signaturblocks enthalten denselben Wert.
   2. Auf das zentrale ZIP-Verzeichnis folgt unmittelbar der ZIP-Datensatz zum Ende des zentralen Verzeichnisses.
   3. Auf das ZIP-Ende des zentralen Verzeichnisses folgen keine weiteren Daten.
2. Suchen Sie den ersten Block des APK-Signaturschemas v3 im APK-Signaturblock. Wenn der v3-Block vorhanden ist, fahren Sie mit Schritt 3 fort. Andernfalls können Sie die APK mithilfe des v2-Schemas überprüfen.
3. Für jeden signer im APK Signature Scheme v3 Block mit einer minimalen und maximalen SDK-Version, die sich in Reichweite der aktuellen Plattform befindet:
   1. Wählen Sie die stärksten unterstützte signature algorithm ID von signatures . Die Reihenfolge der Stärken hängt von jeder Implementierungs- / Plattformversion ab.
   2. Überprüfen Sie die entsprechende signature von signatures anhand signed data mit dem public key . (Es ist jetzt sicher, signed data zu analysieren.)
   3. Überprüfen Sie, ob die minimalen und maximalen SDK-Versionen in den signierten Daten mit den für den signer angegebenen übereinstimmen.
   4. Stellen Sie sicher, dass die geordnete Liste der Signaturalgorithmus-IDs in digests und signatures identisch ist. (Dies soll das Entfernen / Hinzufügen von Signaturen verhindern.)
   5. Berechnen Sie den Digest von APK-Inhalten mit demselben Digest-Algorithmus wie den Digest-Algorithmus, der vom Signaturalgorithmus verwendet wird.
   6. Stellen Sie sicher, dass der berechnete Digest mit dem entsprechenden digest aus digests identisch ist.
   7. Stellen Sie sicher , dass SubjectPublicKeyInfo des ersten certificate von certificates identisch ist mit public key .
   8. Wenn das Rotationsnachweisattribut für den signer überprüfen Sie, ob die Struktur gültig ist und dieser signer das letzte Zertifikat in der Liste ist.
4. Die Überprüfung ist erfolgreich, wenn genau ein signer in Reichweite der aktuellen Plattform gefunden wurde und Schritt 3 für diesen signer .

Achtung : APK darf nicht mit dem Schema v1 oder v2 überprüft werden, wenn in Schritt 3 oder 4 ein Fehler auftritt.

Validierung

Führen Sie die CTS-Tests PkgInstallSignatureVerificationTest.java in cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ , um zu testen, ob Ihr Gerät v3 ordnungsgemäß unterstützt.