Übersicht
Android 13 unterstützt das APK-Signaturschema 3.1, eine Verbesserung des bestehenden APK-Signaturschemas 3. Das Schema v3.1 behebt einige der bekannten Probleme mit dem APK-Signaturschema v3 in Bezug auf die Drehung. Insbesondere unterstützt das Signaturschema der Version 3.1 das Targeting auf SDK-Versionen, wodurch die Auslieferung auf eine spätere Version der Plattform ausgerichtet werden kann.
Das Signaturschema von Version 3.1 verwendet eine Block-ID, die unter Android 12 oder niedriger nicht erkannt wird. Daher wendet die Plattform das folgende Verhalten für Unterzeichner an:
- Auf Geräten mit Android 13 oder höher wird der rotierende Unterzeichner im Block „v3.1“ verwendet.
- Auf Geräten mit älteren Android-Versionen wird der rotierende Unterzeichner ignoriert und stattdessen der ursprüngliche Unterzeichner im V3-Block verwendet.
Bei Apps, deren Signaturschlüssel noch nicht rotiert wurde, sind keine weiteren Maßnahmen erforderlich. Wenn diese Apps die Bildschirmausrichtung ändern, wendet das System standardmäßig das Signaturschema v3.1 an.
Blockierung der v3.1-Signatur
Der Signaturblock der Version 3.1 hat denselben Inhalt wie der Signaturblock der Version 3. Mit der neuen Block-ID werden diese Signaturen jedoch nur auf Geräten mit Android 13 und höher erkannt. So können Entwickler ihre Signaturschlüssel sicher wechseln, ohne sich um APKs mit mehreren Zielen kümmern zu müssen, da der ursprüngliche Signaturschlüssel verwendet werden kann, um die APK im Signaturblock von Version 3 und der neue Signaturschlüssel im Signaturblock von Version 3.1 zu signieren. Außerdem kann die Plattform alle vorhandenen Bestätigungscodes für den V3-Signaturblock wiederverwenden, wenn eine V3.1-Signatur verifiziert wird.
Standardmäßig verwendet die apksig
-Bibliothek den Signaturblock der Version 3.1, wenn in der Signaturkonfiguration ein rotierter Schlüssel und eine Herkunft angegeben sind. Wenn die minSdkVersion
einer App niedriger als Android 13 ist und ein rotierter Schlüssel verwendet wird, muss auch der ursprüngliche Signaturschlüssel angegeben werden, damit er zum Signieren der APK im V3-Signaturblock verwendet werden kann. Das ähnelt dem aktuellen Verhalten, bei dem der ursprüngliche Unterzeichner erforderlich ist, wenn das APK auf eine Version vor Android 9 ausgerichtet ist.
Um die Ausrichtung der Schlüsselrotation ab einer bestimmten SDK-Version zu unterstützen, werden in der apksig
-Bibliothek neue APIs bereitgestellt, mit denen eine Mindest-SDK-Version für die Rotation festgelegt werden kann. Wenn eine SDK-Version niedriger als Android 13 als Mindestversion für die Rotationsunterstützung angegeben wird, wird der ursprüngliche v3-Block verwendet. Der Signaturblock für Version 3.1 wird nur bei Bildschirmausrichtung verwendet, wenn die Mindest-SDK-Version für die Bildschirmausrichtung auf Android 13 oder höher festgelegt ist. Der V3-Signaturblock enthält ein neues Attribut für den Schutz vor dem Entfernen der Mindest-SDK-Version bei der Rotation.
APK enthält Lineage | Wert von „rotation-min-sdk-version“ | v3-Signaturblock | Signaturblock der Version 3.1 |
---|---|---|---|
Nein | Standard- oder beliebiger Wert (unten durch x dargestellt) | Mit dem ursprünglichen Unterzeichner signiert, Targeting auf Android 9 und höher | Nicht verfügbar |
Ja | Standard | Mit dem ursprünglichen Unterzeichner signiert, Ausrichtung auf Android 9 bis 12L | Mit wechselndem Unterzeichner signiert, Ausrichtung auf Android 13 und höher |
Ja | x < 33 (Android 13) | Mit wechselndem Unterzeichner signiert, Ausrichtung auf Android 9 und höher | Nicht verfügbar |
Ja | x >= 33 (Android 13) | Von ursprünglichem Unterzeichner signiert, Ausrichtung auf Android 9 – (x-1) | Unterzeichnet mit gedrehtem Unterzeichner, Ausrichtung auf x+ |
Probleme mit der Rotation
Die folgenden drehungsbezogenen Probleme wurden auf der Plattform behoben:
Fehlerkorrekturen in Android 12
- Die Plattform gewährt einer anfragenden App nur dann eine Signaturberechtigung, wenn der aktuelle Unterzeichner einer der Apps zur Signaturreihenfolge gehört oder der aktuelle Unterzeichner der anderen App ist. So wird verhindert, dass einer anfragenden App eine Signaturberechtigung gewährt wird, wenn die beiden Apps die Best Practices für Signaturschlüssel einhalten und verschiedene Signaturschlüssel rotieren.
- Mit der APK-Rollback-Funktion der Plattform konnte ein APK, dessen Signaturschlüssel gerade rotiert wurde, nur dann rückgängig gemacht werden, wenn der vorherige Schlüssel in der Signaturabfolge die Rollback-Funktion hatte. Diese Funktion macht jedoch den Zweck der Rotation zunichte, da ein neues Paketupdate mit dem vorherigen Signaturschlüssel signiert und der rotierte Schlüssel rückgängig gemacht werden kann.
- Ein APK, das nur mit dem rotierten Schlüssel signiert und später mit einem APK aktualisiert wurde, das mit dem ursprünglichen Schlüssel und dem rotierten Schlüssel signiert ist, zeigt auf Geräten mit Android 11 und niedriger nur den rotierten Schlüssel in der Abfolge an.
Fehlerkorrekturen für Android 11
PackageManager#checkSignatures
wurde nicht richtig aktualisiert, um die ursprünglichen Signaturschlüssel von zwei Paketen zu prüfen. Dadurch war die Instrumentierung für Apps, die einen rotierten Signaturschlüssel verwenden, mit dem Instrumentierungs-APK, das den ursprünglichen Signaturschlüssel verwendet, nicht mehr möglich.- Pakete unter einer
sharedUserId
teilen sich die Signaturabfolge. Wenn eine App mit einer aktualisierten Signaturabfolge in einersharedUiserId
installiert oder aktualisiert wird, ersetzt die Abfolge dieser App die gemeinsame Abfolge für diesharedUserId
. Wenn also die Signaturabfolge einer App A -> B war und eine App in dersharedUserId
mit der Abfolge B -> C aktualisiert wird, wird die Abfolge dersharedUserId
durch B -> C ersetzt. Ebenso konnten die Berechtigungen eines früheren Unterzeichners in der Stammreihe nicht aktualisiert werden, es sei denn, die Stammreihe der Unterschrift wurde geändert.
v4-Integration
Beim V4-Signaturschema wird die Signaturkonfiguration verwendet, die für apksigner bereitgestellt wurde. Bei mehreren Signaturkonfigurationen, die für die Rotation bereitgestellt wurden, wird die zuletzt rotierte Signaturkonfiguration verwendet. Vor der Einführung von Version 3.1 enthielt Version 3 nur diese aktuelle Konfiguration für die rotierende Signatur. Daher konnte Version 4 diese Konfiguration unverändert verwenden. So konnte das Signaturschema von Version 4 die Rotation unterstützen, da in den SigningInfos der rotierende Signaturschlüssel verwendet wurde. Die SigningInfo-Version 4 enthält zwar nicht die vollständige Signaturabfolge, kann diese aber aus dem Signaturblock der Version 3 abrufen, um der Plattform Zugriff auf die Abfolge für alle Signaturabfragen zu gewähren. Wenn Version 3.1 verwendet wird, um die Rotation für die angegebene „rotation-min-sdk-version“ zu steuern, enthält die generische Version 3-Konfiguration sowohl die ursprüngliche Signaturkonfiguration als auch die neueste rotierte Signaturkonfiguration. Es wurde eine Erweiterung des Signaturschemas der Version 4 erstellt, die zusätzliche Blöcke mit Signaturinformationen für jede der Signaturkonfigurationen aus dem Block der Version 3.1 enthält.
Zertifizierungsstufe
Führen Sie die PkgInstallSignatureVerificationTest.java
CTS-Tests in cts/hostsidetests/appsecurity/src/android/appsecurity/cts/
aus, um Ihre Implementierung von Version 3.1 zu testen.
Weitere Informationen zu Tests finden Sie in Version 3 im Abschnitt Überprüfung.