Pour renforcer la confiance dans l'OS Android, nous nous engageons à répertorier tous les modules de l'OS Android (appelés Mainline) proposés sous forme de mise à jour via Google Play dans notre journal de transparence. Nous publions le journal de transparence pour vérifier les affirmations que nous faisons concernant ces modules. Les modules préinstallés ne sont pas explicitement listés, car ils sont déjà couverts par la transparence binaire Pixel.
Modèle de menace
Les systèmes de transparence peuvent être utilisés pour détecter et dissuader les attaques de la chaîne d'approvisionnement. Voici quelques exemples.
Supposons qu'un pirate modifie de manière malveillante un module Mainline (qui peut être un fichier APEX ou APK) et parvienne même à le signer avec la clé de signature utilisée pour la distribution via Google Play. Toute personne recevant un module douteux peut interroger le journal de transparence binaire pour vérifier son authenticité. Elle constatera que Google n'a pas ajouté les métadonnées de module correspondantes au journal et saura qu'elle ne doit pas faire confiance au module d'OS compromis.
Étant donné que la publication dans le journal est un processus distinct du processus de publication avec signature, cela rend la tâche du pirate plus difficile que de simplement compromettre la clé.
Bien que nous prévoyions également d'intégrer ce journal dans un réseau public de témoins à l'aide d'un protocole de témoin standard, nous encourageons les tiers externes et indépendants à surveiller l'intégrité de ce journal accessible au public. Ces parties peuvent attester de la propriété d'ajout uniquement du journal et signaler toute falsification.
L'existence d'un tel système de transparence et la détection supplémentaire des attaques découragent les activités malveillantes. Si un module d'OS est compromis, mais que les utilisateurs ne font confiance qu'à ceux qui figurent dans le journal, le module compromis devra être exposé publiquement. Cela augmente la probabilité de découvrir l'existence des modules compromis et de prendre des mesures pour supprimer leur distribution.
Modèle de demandeur
Le modèle de demandeur est un framework utilisé pour définir les rôles et les artefacts dans un système vérifiable. Dans le cas de la transparence des modules Mainline Android, l'affirmation que nous faisons est que le hachage d'un fichier de module enregistré dans ce journal représente une version spécifique d'un module Android officiel destiné à un usage public.
- ClaimMainlineModule : (I, Google, claim that
$hashModuleis for$mainlineModule), où :
Toute personne disposant d'une copie de $mainlineModule peut vérifier cette affirmation.
La page de validation fournit des instructions détaillées
pour ce processus.
Ces étapes s'appliquent à la fois aux APK standards et aux modules Mainline (qui peuvent être des fichiers APK ou APEX).
Contenu du journal
Lorsque Google publie une nouvelle version d'un module Mainline, il ajoute une entrée correspondante au journal de transparence des modules Mainline.
Chaque entrée de ce journal contient quatre métadonnées :
- Le hachage de l'APK ou de l'APEX d'un module Mainline Android signé. Il s'agit d'une chaîne hexadécimale du condensé SHA256 de l'ensemble du fichier.
- La description du type de hachage ci-dessus. Il s'agit d'une chaîne.
- Le nom du package du module. Il s'agit d'une chaîne.
- Le numéro de version (versionCode) du module. Il s'agit d'un entier non nul.
Le format d'une entrée de journal est la concaténation des quatre informations avec un caractère de saut de ligne (\n), comme illustré ci-dessous :
hash\nhash_description\npackage_name\npackage_version\n
Étant donné qu'un module Mainline peut être un fichier APK ou APEX, la description du hachage peut être SHA256(APK) ou SHA256(APEX).