Ce contenu a été mis à jour pour la dernière fois en mai 2024, et correspond à l'état des connaissances à sa date de rédaction. Les règles et les systèmes de sécurité Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.
Ce document décrit les contrôles d'infrastructure que Google utilise pour appliquer l'intégrité du processus de démarrage sur les machines de production Titan. Ces contrôles, basés sur un processus de démarrage mesuré, permettent de s'assurer que Google peut récupérer les machines de son centre de données en cas de failles via sa pile de démarrage et renvoyer les machines de l'état de démarrage arbitraire vers des configurations connues.
Introduction
La stratégie de sécurité d'une machine de centre de données dépend fortement de la configuration de votre machine au démarrage. Le processus de démarrage de la machine configure le matériel de la machine et initialise son système d'exploitation, tout en garantissant qu'elle peut s'exécuter en toute sécurité dans l'environnement de production de Google.
À chaque étape du processus de démarrage, Google met en œuvre des contrôles de pointe pour garantir l'état de démarrage attendu et garantir la sécurité des données client. Ces contrôles garantissent que nos machines démarrent dans le logiciel prévu, ce qui nous permet de supprimer les failles susceptibles de compromettre la stratégie de sécurité initiale de la machine.
Ce document décrit le processus de démarrage et montre comment nos contrôles fonctionnent pendant le processus de démarrage. Les principaux objectifs de nos contrôles sont les suivants :
- Établir la confiance dans les identifiants des machines via les racines de confiance matérielles
- Sceller les identifiants de machine selon une règle de démarrage spécifiant les versions de micrologiciel et de logiciel autorisées
- Appliquer la règle de démarrage sur les machines via un processus de démarrage mesuré
Contexte
Cette section définit et fournit des informations sur les termes identifiants de la machine, racine de confiance matérielle, identifiants scellés et scellement cryptographique.
Identifiants machine
L'un des composants centraux du système de gestion des machines de Google est notre infrastructure d'identifiants, qui consiste en une autorité de certification (CA) interne et d'autres éléments du plan de contrôle chargés de coordonner les flux de rotation des identifiants.
Les machines du parc de production de Google effectuent une authentification mutuelle lors de l'établissement de canaux sécurisés. Pour effectuer une authentification mutuelle, chaque machine possède les clés publiques CA de Google. Chaque machine possède également sa propre paire de clés publique/privée, ainsi qu'un certificat pour cette paire de clés.
La paire de clés publique/privée de chaque machine, ainsi que le certificat signé par l'autorité de certification, sont appelés identifiants de machine. Ces identifiants permettent à la machine de s'authentifier auprès d'autres machines du parc. Dans le réseau de production, les machines vérifient que les clés publiques des autres machines sont certifiées par l'autorité de certification de Google avant d'échanger du trafic.
Racines matérielles de confiance et scellement cryptographique
À mesure que les appareils informatiques se perfectionnent, la surface d'attaque de chaque appareil s'accroît également. C'est pourquoi les appareils disposent de plus en plus de racines matérielles de confiance (RoTs), de petits environnements d'exécution fiables qui protègent les données sensibles de la machine. Les RoT apparaissent également sur les appareils mobiles tels que les ordinateurs portables ou les téléphones mobiles, ainsi que sur des appareils plus conventionnels, tels que les ordinateurs de bureau.
Les machines de centre de données Google disposent de racines de confiance matérielles personnalisées conçues par Google, intégrées aux couches les plus profondes de chaque machine, appelées Titan. Nous utilisons Titan, ainsi qu'un mécanisme appelé scellement cryptographique, pour garantir que chaque machine exécute les versions de configuration et de logiciel attendues.
Le scellement cryptographique est un service proposé par Titan qui permet de protéger des secrets. Les fonctionnalités de scellement de Titan sont semblables à celles de la spécification Trusted Platform Module (TPM), publiée par le Trusted Computing Group. Le scellement cryptographique de Titan présente un avantage supplémentaire, car il offre une meilleure capacité à mesurer et à attester d'un micrologiciel de bas niveau.
Le scellement cryptographique comprend les deux contrôles suivants:
- Chiffrement des données sensibles
- Une stratégie qui doit être remplie pour que les données puissent être déchiffrées
Identifiants scellés
L'infrastructure d'identification de Google utilise le scellement cryptographique pour chiffrer les identifiants machine au repos avec une clé contrôlée par la racine de confiance matérielle de la machine. La clé privée d'identifiant chiffrée et le certificat correspondant sont appelés identifiants scellés. Outre les identifiants de machine, Google utilise ce mécanisme de scellement pour protéger également d'autres données sensibles.
Chaque machine ne peut déchiffrer et accéder à ses identifiants de machine que si elle remplit une règle de déchiffrement qui spécifie le logiciel que la machine doit démarrer. Par exemple, le scellement des identifiants d'une machine sur une stratégie spécifiant la version souhaitée du noyau du système d'exploitation contribue à garantir que la machine ne peut pas participer à son cluster, sauf si elle a démarré la version du noyau souhaitée.
La règle de déchiffrement est appliquée via un processus appelé démarrage mesuré. Chaque couche de la pile de démarrage mesure la couche suivante, et la machine atteste de cette chaîne de mesures à la fin du démarrage. Il s'agit souvent d'un hachage cryptographique.
Processus de scellement des identifiants
Cette section décrit le scellement des identifiants et le processus de démarrage mesuré utilisés par les machines Google. Le diagramme suivant illustre ce flux.
Pour sceller des identifiants de machine à une stratégie de démarrage particulière, procédez comme suit:
- L'infrastructure d'automatisation de machine de Google lance une mise à jour logicielle sur la machine. Elle transmet les versions logicielles prévues à l'infrastructure d'identification.
- L'infrastructure d'identification de Google demande une clé de scellement à Titan, liée par des règles, de sorte que Titan ne l'utilise que si la machine démarre dans son logiciel prévu.
- L'infrastructure d'identification compare la stratégie de la clé renvoyée à l'intent qui lui est communiqué par l'infrastructure d'automatisation de la machine. Si l'infrastructure d'identification reconnaît que, la règle correspond à l'intent, elle envoie des identifiants de machine certifiés à la machine.
- L'infrastructure d'identification chiffre ces identifiants à l'aide de la clé de scellement obtenue à l'étape 2.
- Les identifiants chiffrés sont stockés sur le disque pour le déchiffrement via Titan lors des démarrages suivants.
Processus de démarrage mesuré
La pile de démarrage des machines Google se compose de quatre couches, représentées dans le schéma suivant.
Les couches sont les suivantes:
- Espace utilisateur: applications telles que des daemons ou charges de travail.
- Logiciel système: hyperviseur ou noyau. Niveau de logiciel le plus bas qui fournit une abstraction sur les fonctionnalités matérielles telles que la mise en réseau, le système de fichiers ou la mémoire virtuelle dans l'espace utilisateur.
- Micrologiciel de démarrage : micrologiciel qui initialise le noyau, tel qu'un BIOS et un bootloader.
- Racine matérielle de confiance: dans les machines Google, une puce Titan qui mesure de manière cryptographique le micrologiciel et d'autres services de processeur de bas niveau.
Au cours du démarrage, chaque couche mesure la couche suivante avant de lui transmettre le contrôle. Les identifiants scellés de la machine ne sont disponibles pour le système d'exploitation que si toutes les mesures capturées lors du démarrage sont conformes à la stratégie de déchiffrement des identifiants scellés, comme spécifié par l'infrastructure d'identifiants de Google. Par conséquent, si la machine peut effectuer des opérations avec ses identifiants scellés, cela signifie qu'elle respecte ses règles de démarrage mesurées. Ce processus est une forme d'attestation implicite.
Si une machine démarre un logiciel qui s'écarte de l'état souhaité, elle ne peut pas déchiffrer ni effectuer d'opérations avec les identifiants dont elle a besoin pour fonctionner dans le parc. Ces machines ne peuvent pas participer à la planification des charges de travail tant que l'infrastructure de gestion des machines ne déclenche pas des actions de réparation automatisées.
Récupération à la suite de failles dans le noyau
Supposons qu'une machine exécute la version de noyau A, mais que les chercheurs en sécurité détectent que cette version de noyau présente une faille. Dans ces scénarios, Google corrige la faille et déploie une version de noyau B mise à jour dans le parc.
En plus de corriger la faille, Google émet également de nouveaux identifiants pour chaque machine du parc. Comme décrit dans la section Processus de scellement des identifiants, les nouveaux identifiants de la machine sont liés à une stratégie de déchiffrement qui n'est remplie que si la version du noyau B démarre sur la machine. Les machines qui n'exécutent pas le noyau prévu ne peuvent pas déchiffrer les nouveaux identifiants de la machine, car les mesures du micrologiciel de démarrage ne respectent pas les règles de démarrage de la machine. Dans le cadre de ce processus, les anciens identifiants de machine sont également révoqués.
Par conséquent, ces machines ne peuvent participer à leur cluster de machine qu'une fois leur noyau mis à jour, conforme à l'intent du plan de contrôle. Ces contrôles vous permettent de vous assurer que les machines exécutant la version vulnérable du noyau A ne peuvent pas recevoir de jobs ni de données utilisateur tant qu'elles ne sont pas mises à niveau vers la version B du noyau.
Récupération à la suite de failles dans le micrologiciel de démarrage
Supposons qu'il existe une faille dans le micrologiciel de démarrage au lieu du noyau du système d'exploitation. Les contrôles décrits dans la section Résoudre les failles du noyau aident Google à récupérer de telles failles.
La puce Titan de Google mesure le micrologiciel de démarrage d'une machine avant son exécution, afin que Titan puisse déterminer si celui-ci respecte les règles de démarrage des identifiants de la machine. Une machine qui n'exécute pas le micrologiciel de démarrage prévu ne peut pas obtenir de nouveaux identifiants, et cette machine ne peut pas participer à son cluster tant que son micrologiciel de démarrage n'est pas conforme à l'intent du plan de contrôle.
Récupération des failles dans le micrologiciel de confiance racine
Les RoT ne sont pas immunisées contre les failles, mais les contrôles de démarrage de Google permettent la reprise après bugs, même au niveau de cette couche de la pile de démarrage, dans le propre code modifiable du RoT.
La pile de démarrage de Titan met elle-même en œuvre un flux de démarrage sécurisé et mesuré. Lorsqu'une puce Titan s'allume, son matériel mesure de manière cryptographique le bootloader de Titan, qui à son tour mesure le micrologiciel de Titan. Comme le micrologiciel de démarrage et le noyau de la machine, le micrologiciel Titan est signé de manière cryptographique avec un numéro de version. Le bootloader de Titan valide la signature et extrait le numéro de version du micrologiciel Titan, qui alimente le numéro de version vers le sous-système de dérivation de clé matérielle de Titan.
Le sous-système matériel de Titan met en œuvre un schéma de dérivation de clé avec version, dans lequel le micrologiciel Titan avec la version X peut obtenir des clés uniques aux puces et associées à toutes les versions inférieures ou égales à X. Le matériel Titan permet au micrologiciel avec la version X d'accéder aux clés liées à des versions inférieures ou égales à X, mais qui ne sont pas supérieures à X. Tous les secrets scellés à Titan, y compris les identifiants de la machine, sont chiffrés à l'aide d'une clé avec version.
L'attestation et la clé de scellement sont uniques à chaque puce Titan. Les clés uniques permettent à Google de n'approuver que les puces Titan censées s'exécuter dans un centre de données Google.
Le schéma suivant illustre Titan avec des clés de version. La clé de version X+1 n'est pas accessible par le micrologiciel de la version X, mais toutes les clés plus anciennes sont accessibles.
En cas de faille grave dans le micrologiciel Titan, Google déploie un correctif avec un numéro de version plus élevé, puis émet de nouveaux identifiants de machine liés à la version du micrologiciel Titan supérieure. Les anciens micrologiciels Titan vulnérables ne peuvent pas déchiffrer ces nouveaux identifiants. Par conséquent, si une machine effectue des opérations avec ses nouveaux identifiants en production, Google peut certifier que la puce Titan de la machine démarre un micrologiciel à jour.
Assurer l'authenticité de la racine de confiance
Les contrôles décrits dans ce document s'appuient sur le fonctionnement de la racine de confiance matérielle elle-même. L'infrastructure d'identification de Google s'appuie sur les signatures émises par ces racines de confiance pour déterminer si la machine exécute un logiciel prévu.
Il est donc essentiel que l'infrastructure d'identification puisse déterminer si une RoT matérielle est authentique et si elle exécute un micrologiciel à jour.
Lorsque chaque puce Titan est fabriquée, elle est programmée avec une entropie unique. La routine de démarrage de bas niveau de Titan transforme cette entropie en clé propre à l'appareil. Un élément sécurisé de la ligne de fabrication Titan approuve cette clé unique de puce de sorte que Google la reconnaisse comme une puce légitime Titan.
Le schéma suivant illustre ce processus d'approbation.
En production, Titan utilise sa clé unique à l'appareil pour approuver toutes les signatures qu'elle émet. Les puces Titan utilisent un flux semblable à DICE (Device Identifier Composition Engine). L'approbation inclut les informations de version du micrologiciel Titan. Cette approbation permet d'empêcher un pirate informatique d'emprunter l'identité d'une signature émise par une puce Titan, d'effectuer un rollback vers une ancienne version du micrologiciel Titan et d'emprunter l'identité d'un micrologiciel Titan plus récent. Ces contrôles aident Google à vérifier que les signatures reçues de Titan ont été émises par du matériel Titan authentique exécutant le micrologiciel Titan authentique.
Mettre en œuvre l'intégrité au démarrage
Ce document décrit les mécanismes permettant de s'assurer que les processeurs d'applications des machines démarrent le code prévu. Ces mécanismes reposent sur un flux de démarrage mesuré, associé à une puce de racine matérielle de confiance.
Le modèle de gestion des menaces de Google inclut les pirates informatiques qui peuvent s'implanter physiquement sur le chemin entre le processeur et le RoT, dans le but d'obtenir de manière incorrecte les identifiants déchiffrés de la machine. Pour réduire les risques, Google favorise le développement d'une approche basée sur la norme pour déjouer les intrus actifs, en rassemblant les API TPM et DPE du Trusted Computing Group et la racine de confiance Caliptra intégrée.
Étapes suivantes
- Pour savoir comment Google contribue à garantir l'intégrité des piles de démarrage des machines complexes et désagrégées, consultez la section Attestation à distance des machines désagrégées.
- Pour en savoir plus sur la sécurité de Google, consultez la page Présentation de la conception de la sécurité sur l'infrastructure de Google.
- Pour en savoir plus sur la manière dont Google contribue aux solutions de sécurité Titan aux standards de l'industrie, consultez la conférence TPM Attested Boot in Big, Distributed Environments (démarrage certifié TPM dans les environnements distribués de grande taille) sur la chaîne YouTube de Trusted Computing Group.
Auteurs: Jeff Andersen, Kevin Plybon