Puce matérielle Titan

Ce contenu a été mis à jour pour la dernière fois en janvier 2025, et correspond à l'état des connaissances à sa date de rédaction. Il est possible que les règles et les systèmes de sécurité de Google changent par la suite, car nous améliorons continuellement la protection de nos clients.

La puce Titan est une puce spécialement conçue pour établir la racine matérielle de confiance pour les plates-formes dans les Google Cloud centres de données. Il s'agit d'un microcontrôleur basse consommation déployé sur des plates-formes telles que des serveurs, une infrastructure réseau et d'autres périphériques de centre de données.

La puce Titan est un composant important de l'architecture de sécurité matérielle Titanium, qui fournit une couche de sécurité de base permettant de se protéger contre les attaques physiques et les menaces pesant sur les données utilisateur. Elle permet à Google d'identifier et de mesurer de manière sécurisée le micrologiciel et la configuration de la plate-forme. Elle est conçue pour se protéger contre les attaques logicielles privilégiées et les rootkits, à partir du processus de démarrage de la machine.

Ce document décrit l'architecture de la puce et les avantages de sécurité qu'elle offre. Elle est compatible avec une base de calcul fiable minimale qui lui permet d'offrir les avantages suivants :

La famille de puces Titan

Les premières puces Titan ont été conçues en 2014. Les générations ultérieures ont intégré l'expérience acquise lors des processus itératifs de fabrication, d'intégration et de déploiement. Pour en savoir plus sur la manière dont Google a partagé ses connaissances sur la puce Titan avec la communauté de sécurité matérielle Open Source, consultez opentitan.org.

Les puces Titan incluent les composants suivants :

  • Processeur sécurisé
  • Coprocesseur cryptographique AES et SHA
  • Générateur de nombres aléatoires matériels
  • Hiérarchie de clés sophistiquée
  • RAM statique (SRAM), mémoire flash et ROM intégrées

Identité de fabrication Titan

Lors du processus de fabrication de la puce Titan, les puces sont déplacées dans une pièce sécurisée de l'installation d'assemblage et de test de semi-conducteurs externalisée (OSAT, Outsourced Semiconductor Assembly and Test) afin de pouvoir être provisionnées avec leur identité. Cette pièce est conforme aux normes ISO et aux critères communs. Elle dispose de quatre caméras redondantes (une dans chaque angle) et d'une porte avec lecteur de badge qui ne doit être ouverte qu'en cas d'urgence opérationnelle. Aucun humain n'est présent dans la pièce lorsque les puces sont provisionnées. Le processus est entièrement automatisé.

Les appareils entrent par un boîtier situé sur un mur et sont insérés dans un gestionnaire automatisé. Chaque gestionnaire est équipé d'une puce Titan appelée Scribe. Le Scribe inclut un micrologiciel de provisionnement et dispose d'une interface périphérique série (SPI, Serial Peripheral Interface), d'une réinitialisation et de connexions émetteur-récepteur asynchrone universel (UART, Universal Asynchronous Receiver-Transmitter) à l'appareil testé (DUT, Device Under Test), qui est la puce Titan en cours de fabrication. Le Scribe est recouvert d'époxy et comporte des marquages inviolables uniques. Le gestionnaire automatisé introduit le DUT dans un lit de clous, où il s'allume. Le Scribe libère le DUT de la réinitialisation, lui fournit le micrologiciel d'exécution et exécute le processus de provisionnement.

Pendant le processus de provisionnement, le DUT vérifie le micrologiciel de provisionnement à l'aide d'une clé publique intégrée à sa ROM de masque. Le micrologiciel utilise le générateur de nombres aléatoires (TRNG, True Random Number Generator) de la puce pour générer un secret d'appareil interne, qu'il grave dans les fusibles des puces. Ce secret est la racine de toutes les dérivations de clés que la puce exécutera à l'avenir. Le Scribe ne connaît pas ce secret. Le DUT génère un fichier manifeste de personnalisation qui inclut sa clé publique unique dérivée du secret d'appareil interne. Le fichier manifeste de personnalisation est authentifié par une clé de classe intégrée au niveau de transfert de registre (RTL, Register Transfer Level) du DUT. Le Scribe récupère le fichier manifeste de personnalisation via SPI, puis le signe à l'aide d'une clé unique à ce Scribe. Le fichier manifeste de personnalisation est ensuite importé et stocké dans une base de données de registre Google.

Chaque clé de signature Scribe est enregistrée lors d'une cérémonie en personne lorsque le Scribe est mis en service. De plus, le Scribe ne conserve sa clé privée de signature que dans une mémoire volatile. Ainsi, si le Scribe est retiré de l'installation sécurisée, il perd la clé de signature en cas de coupure de courant. Chaque Scribe doit récupérer une copie unique de sa clé de signature auprès d'un service Google chaque fois qu'il est mis sous tension. La copie encapsulée de la clé de signature d'un Scribe donné est établie lorsque le Scribe a été enregistré initialement hors connexion par un quorum k sur n, et ne peut être décompressée que par ce Scribe.

Lorsque les plates-formes compatibles avec Titan sont intégrées au réseau de production Google, les systèmes backend peuvent vérifier qu'elles sont équipées d'authentiques puces Titan en comparant la clé publique unique de Titan à la base de données des fichiers manifestes de personnalisation récupérés. Pour en savoir plus sur la manière dont les services utilisent le système d'identité Titan, consultez Processus de scellement des identifiants processus.

Les puces Titan utilisent leurs paires de clés uniques à l'appareil pour attester de leur micrologiciel d'une manière semblable à DICE (Device Identifier Composition Engine). Les puces Titan d'origine ont été certifiées à l'aide d'une conception Google personnalisée, car elles ont été fabriquées avant l'introduction des normes industrielles pertinentes. L'expérience de Google en matière de fabrication et de déploiement de matériel sécurisé nous incite à accroître notre participation aux processus de normalisation. Les normes plus récentes telles que DICE, TPM (Trusted Platform Module) et SPDM (Security Protocol and Data Mode) incluent des modifications qui reflètent notre expérience.

Intégration de Titan

Lorsque la puce Titan est intégrée à une plate-forme, elle offre des protections de sécurité à un processeur d'application (AP, Application Processor). Par exemple, Titan peut être associé à un processeur qui exécute des charges de travail, à un contrôleur de gestion de baseboard (BMC, Baseboard Management Controller) ou à un accélérateur pour des charges de travail telles que le machine learning.

Titan communique avec l'AP à l'aide du bus SPI. Titan s'interpose entre l'AP et la puce flash du micrologiciel de démarrage de l'AP, ce qui lui permet de lire et de mesurer chaque octet de ce micrologiciel avant son exécution au démarrage.

Les étapes suivantes se produisent lorsqu'une plate-forme compatible avec Titan est mise sous tension :

  1. Titan maintient le processeur en mode de réinitialisation pendant que le processeur d'application interne de Titan exécute du code immuable (la ROM de démarrage) à partir de sa mémoire en lecture seule intégrée.
  2. Titan exécute un autotest intégré pour vérifier qu'aucune mémoire (y compris la ROM) n'a été altérée.
  3. La ROM de démarrage de Titan vérifie le micrologiciel de Titan à l'aide de la cryptographie à clé publique et mélange l'identité du micrologiciel vérifié dans la hiérarchie de clés de Titan.
  4. La ROM de démarrage de Titan charge le micrologiciel vérifié de Titan.
  5. Le micrologiciel de Titan vérifie le contenu de la mémoire flash du micrologiciel de démarrage de l'AP à l'aide de la cryptographie à clé publique. Titan bloque l'accès de l'AP à sa mémoire flash du micrologiciel de démarrage jusqu'à ce que le processus de vérification soit terminé.
  6. Une fois la vérification effectuée, la puce Titan libère l'AP de la réinitialisation, ce qui lui permet de démarrer.
  7. Le micrologiciel du PA effectue une configuration supplémentaire, qui peut inclure le lancement d'autres images de démarrage. L'AP peut capturer des mesures de ces images de démarrage et les envoyer à Titan pour une surveillance sécurisée.

Ces étapes permettent d'atteindre l'intégrité de la première instruction, car Google peut identifier le micrologiciel de démarrage et l'OS qui ont été démarrés sur la machine à partir de la toute première instruction exécutée pendant le cycle de démarrage. Pour les AP avec des processeurs qui acceptent les mises à jour de microcode, le processus de démarrage permet également à Google de savoir quels correctifs de microcode ont été récupérés avant la première instruction du micrologiciel de démarrage. Pour en savoir plus, consultez Processus de démarrage mesuré processus.

Ce flux est semblable au processus de démarrage effectué par les plates-formes équipées d'un TPM. Toutefois, les puces Titan incluent des fonctionnalités qui ne sont généralement pas disponibles sur les TPM standards, telles que l'auto-attestation du micrologiciel interne de Titan ou la sécurité de la mise à niveau du micrologiciel de l'AP, comme décrit dans les sections suivantes.

Les intégrations TPM standards peuvent être vulnérables aux attaques physiques par interposition. Les nouvelles intégrations Titan chez Google atténuent ces attaques en utilisant des racines de confiance intégrées. Pour en savoir plus, consultez TPM Transport Security: Defeating Active Interposers with DICE (Sécurité du transport TPM : vaincre les interposeurs actifs avec DICE) (YouTube).

Mise à niveau sécurisée du micrologiciel Titan

Le micrologiciel de la puce Titan est signé par une clé conservée dans un HSM hors connexion, qui est protégé par des contrôles basés sur un quorum. La ROM de démarrage de Titan vérifie la signature du micrologiciel de Titan chaque fois que la puce démarre.

Le micrologiciel de Titan est signé avec un numéro de version de sécurité (SVN, Security Version Number), qui indique l'état de sécurité de l'image. Si une image de micrologiciel inclut un correctif de faille, le SVN de l'image est incrémenté. Le matériel Titan permet au réseau de production d'attester fortement du SVN du micrologiciel de Titan, même si un micrologiciel plus ancien peut avoir présenté des failles. Le processus de mise à niveau nous permet de nous remettre de ces failles à grande échelle, même si elles affectent le micrologiciel de Titan lui-même. Pour en savoir plus, consultez Récupération des failles dans le micrologiciel de confiance racine.

Google a contribué à la dernière version de la spécification de la bibliothèque TPM, qui inclut désormais des fonctionnalités permettant à d'autres TPM de fournir des assurances d'auto-attestation similaires. Pour en savoir plus, consultez la section TPM Firmware-Limited and SVN-Limited Objects (Objets limités par le micrologiciel TPM et le SVN) (PDF) de la version 1.83 de la spécification de l'architecture TPM. Ces fonctionnalités TPM ont été implémentées et déployées sur nos dernières puces Titan.

Mise à niveau sécurisée du micrologiciel du PA

En plus du micrologiciel de Titan, nous signons également de manière cryptographique le micrologiciel qui s'exécute sur le PA. Titan vérifie cette signature dans le cadre du processus de démarrage de la plate-forme. Il vérifie également cette signature chaque fois que le micrologiciel du PA est mis à jour, ce qui garantit que seules les images de micrologiciel de PA authentiques peuvent être écrites dans la mémoire flash du micrologiciel de démarrage du PA. Ce processus de vérification atténue les attaques qui tentent d'installer des portes dérobées persistantes ou de rendre la plate-forme non démarrable. La vérification de la signature offre également une défense en profondeur pour les plates-formes de Google dans le cas où un processeur présente une faille dans son propre mécanisme d'authentification de microcode.

Étape suivante

En savoir plus sur notre processus d'intégrité du démarrage.