Transparenz bei Android Mainline-Modulen

Um das Vertrauen in das Android-Betriebssystem weiter zu stärken, werden wir in unserem Transparenzlogbuch jedes Android-Betriebssystemmodul (Mainline) auflisten, das als Update über Google Play angeboten wird. Wir veröffentlichen das Transparenzlogbuch, um die Behauptungen zu überprüfen, die wir zu diesen Modulen aufstellen. Vorinstallierte Module werden nicht explizit aufgeführt, da sie bereits von der Pixel Binary Transparency abgedeckt sind von Pixel Binary Transparency.

Bedrohungsmodell

Transparenzsysteme können verwendet werden, um Angriffe auf die Lieferkette zu erkennen und so zu verhindern. Wir veranschaulichen dies anhand einiger Beispiele.

Angenommen, ein Angreifer ändert böswillig ein Mainline-Modul (das entweder eine APEX oder APK Datei sein kann) und schafft es sogar, es mit dem Signatur schlüssel zu signieren, der für die Verteilung über Google Play verwendet wird. Jeder, der ein fragwürdiges Modul erhält, kann das Binary Transparency-Logbuch abfragen, um die Authentizität des Moduls zu überprüfen. Er wird feststellen, dass Google die entsprechenden Modulmetadaten nicht dem Logbuch hinzugefügt hat, und weiß, dass er dem kompromittierten Betriebssystemmodul nicht vertrauen sollte.

Da die Veröffentlichung im Logbuch ein separater Prozess vom Releaseprozess mit Signierung ist, wird die Hürde für den Angreifer höher, da er nicht nur den Schlüssel kompromittieren muss.

Wir planen, dieses Logbuch auch in ein öffentliches Netzwerk von Zeugen zu integrieren, das ein Standard-Zeugenprotokollverwendet. Wir empfehlen externen, unabhängigen Parteien, die Integrität dieses öffentlich zugänglichen Logbuchs zu überwachen. Diese Parteien können die Append-only-Eigenschaft des Logbuchs bestätigen und jede Manipulation melden.

Die Existenz eines solchen Transparenzsystems und die zusätzliche Erkennbarkeit von Angriffen schrecken böswillige Aktivitäten ab. Wenn ein Betriebssystemmodul kompromittiert wird, Nutzer aber nur den Modulen vertrauen, die im Logbuch enthalten sind, muss das kompromittierte Modul öffentlich zugänglich gemacht werden. Dadurch steigt die Wahrscheinlichkeit, dass das kompromittierte Modul entdeckt wird, und es können Maßnahmen ergriffen werden, um die Verteilung zu verhindern.

Modell des Anspruchstellers

Das Modell des Anspruchstellers ist ein Framework, mit dem Rollen und Artefakte in einem überprüfbaren System definiert werden. Im Fall der Transparenz von Android-Mainline-Modulen behaupten wir, dass der Hash einer in diesem Logbuch aufgezeichneten Moduldatei eine bestimmte Version eines offiziellen Android-Moduls darstellt, das für die öffentliche Nutzung bestimmt ist.

  • ClaimMainlineModule: (Ich, Google, behaupte, dass $hashModule für $mainlineModule ist.) Dabei gilt:
    • $hashModule ist ein kryptografischer Hash (z.B. SHA256) der Betriebssystemmoduldatei einer bestimmten Version von $mainlineModule.
    • $mainlineModule ist entweder ein APEX- oder ein Android-Paket (APK), aus dem ein Betriebssystemmodul besteht, das von Google erstellt, signiert und verteilt wird.

Jeder mit einer Kopie von $mainlineModule kann diese Behauptung überprüfen. Auf der Überprüfungsseite finden Sie eine detaillierte Anleitung für diesen Prozess. Diese Schritte gelten sowohl für reguläre APKs als auch für Mainline-Module (die entweder APK- oder APEX-Dateien sein können).

Loginhalte

Wenn Google eine neue Version eines Mainline-Moduls veröffentlicht, wird dem Mainline Modules Transparency Logbuch ein entsprechender Eintrag hinzugefügt.

Jeder Eintrag in diesem Logbuch enthält vier Metadatenelemente:

  1. Der Hash des APK oder APEX eines signierten Android-Mainline-Moduls. Dies ist ein Hex-String des SHA256-Digests der gesamten Datei.
  2. Die Beschreibung des oben genannten Hash-Typs. Dies ist ein String.
  3. Der Paketname des Moduls. Dies ist ein String.
  4. Die Versionsnummer (versionCode) des Moduls. Dies ist eine positive Ganzzahl.

Das Format eines Logbucheintrags ist die Verkettung der vier Informationen mit einem Zeilenumbruchzeichen (\n), wie im Folgenden dargestellt:

hash\nhash_description\npackage_name\npackage_version\n

Da ein Mainline-Modul entweder eine APK- oder eine APEX-Datei sein kann, kann die Hash-Beschreibung entweder SHA256(APK) oder SHA256(APEX) sein.