Titan-Hardware-Chip

Der Inhalt dieses Dokuments wurde im Januar 2025 zum letzten Mal aktualisiert und stellt den Stand zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google können sich aber in Zukunft ändern da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.

Der Titan-Chip ist ein speziell entwickelter Chip, der den Hardware-Root of Trust für Plattformen in Google Cloud Rechenzentren festlegt. Der Titan-Chip ist ein energiesparender Mikrocontroller, der auf Plattformen wie Servern, Netzwerkinfrastruktur und anderen Peripheriegeräten in Rechenzentren eingesetzt wird.

Der Titan-Chip ist eine wichtige Komponente der Titanium-Hardware sicherheits architektur, die eine grundlegende Sicherheitsebene bietet, die vor physischen Angriffen und Bedrohungen für Nutzerdaten schützt. Mit dem Titan-Chip kann Google die Plattform-Firmware und -Konfiguration sicher identifizieren und messen. Er wurde entwickelt, um vor Angriffen auf privilegierte Software und Rootkits zu schützen, und zwar ab dem Startvorgang der Maschine.

In diesem Dokument werden die Chiparchitektur und die Sicherheitsvorteile des Titan-Chips beschrieben. Der Titan-Chip unterstützt eine minimale Trusted Computing Base (TCB), die dem Chip folgende Vorteile bietet:

• Ein Hardware-Root of Trust, der eine starke Identität für eine Maschine schafft
• Integritätsprüfung der Plattform-Firmware sowohl beim Start als auch beim Update
• Remote-Credential-Sealing-Abläufe, die das System zur Verwaltung von Maschinenanmeldedaten von Google unterstützen

Die Titan-Chip-Familie

Die ersten Titan-Chips wurden 2014 entwickelt. In späteren Generationen wurden die Erfahrungen aus iterativen Fertigungs-, Integrations- und Bereitstellungsprozessen berücksichtigt. Weitere Informationen dazu, wie Google sein Wissen über den Titan-Chip in die Open-Source-Hardware-Sicherheitscommunity eingebracht hat, finden Sie unter opentitan.org.

Titan-Chips enthalten die folgenden Komponenten:

• Sicherer Prozessor
• Kryptografischer Coprozessor für AES und SHA
• Hardware-Zufallszahlengenerator
• Ausgefeilte Schlüsselhierarchie
• Eingebetteter statischer RAM (SRAM), Flash und ROM

Titan-Fertigungsidentität

Während des Fertigungsprozesses des Titan-Chips werden die Chips in einen sicheren Raum in der Outsourced Semiconductor Assembly and Test (OSAT)-Einrichtung gebracht, damit sie mit ihrer Identität bereitgestellt werden können. Dieser Raum entspricht den ISO- und Common Criteria-Standards. Er verfügt über vier redundante Kameras (alle Ecken) und eine Tür mit Badge-Leser, die nur in betrieblichen Notfällen geöffnet werden darf. Wenn die Chips bereitgestellt werden, befinden sich keine Personen im Raum. Der Vorgang ist vollständig automatisiert.

Die Geräte werden über ein Gehäuse in einer Wand eingeführt und in einen automatisierten Handler eingesetzt. Jeder Handler ist mit einem Titan-Chip ausgestattet, der als Scribe bezeichnet wird. Der Scribe enthält die Bereitstellungs-Firmware und verfügt über eine serielle Peripherieschnittstelle (SPI), Reset- und universelle asynchrone Empfänger-Sender-Verbindungen (UART) zum zu testenden Gerät (DUT), dem Titan-Chip, der gerade gefertigt wird. Der Scribe ist mit Epoxidharz überzogen und mit manipulationssicheren Markierungen versehen. Der automatische Handler führt das DUT in ein Nagelbett, wo es eingeschaltet wird. Der Scribe setzt das DUT zurück, stellt ihm die Ausführungs-Firmware zur Verfügung und führt den Bereitstellungsprozess aus.

Während des Bereitstellungsprozesses überprüft das DUT die Bereitstellungs-Firmware mit einem öffentlichen Schlüssel, der in sein Mask-ROM eingebettet ist. Die Firmware verwendet den True Random Number Generator (TRNG) des Chips, um ein internes Gerätesecret zu generieren, das in die Sicherungen des Chips eingebrannt wird. Dieses Secret ist die Grundlage für alle Schlüsselableitungen, die der Chip in Zukunft ausführt. Der Scribe kennt dieses Secret nicht. Das DUT generiert ein Personalisierungsmanifest, das seinen eindeutigen öffentlichen Schlüssel enthält, der aus dem internen Gerätesecret abgeleitet wurde. Das Personalisierungsmanifest wird mit einem Klassenschlüssel authentifiziert, der in die Register Transfer Level (RTL) des DUT eingebettet ist. Der Scribe erfasst das Personalisierungsmanifest über SPI und signiert es dann mit einem Schlüssel, der für diesen Scribe eindeutig ist. Das Personalisierungsmanifest wird dann hochgeladen und in einer Google-Registrierungsdatenbank gespeichert.

Jeder Signaturschlüssel des Scribe wird bei einer persönlichen Zeremonie registriert, wenn der Scribe in Betrieb genommen wird. Außerdem speichert der Scribe seinen privaten Signaturschlüssel nur im flüchtigen Speicher. Wenn der Scribe also aus der sicheren Einrichtung entfernt wird, verliert er den Signaturschlüssel bei einem Stromausfall. Jeder Scribe muss bei jedem Einschalten eine eindeutig verpackte Kopie seines Signaturschlüssels von einem Google-Dienst abrufen. Die verpackte Kopie des Signaturschlüssels eines bestimmten Scribe wird erstellt, wenn der Scribe ursprünglich offline von einem k-of-n-Quorum registriert wurde, und kann nur von diesem Scribe entpackt werden.

Wenn Titan-fähige Plattformen in das Google-Produktionsnetzwerk integriert werden, können die Backend-Systeme überprüfen, ob diese Plattformen mit authentischen Titan-Chips ausgestattet sind. Dazu wird der eindeutige öffentliche Schlüssel von Titan mit der Datenbank der erfassten Personalisierungsmanifeste verglichen. Weitere Informationen zur Verwendung des Titan-Identitätssystems durch Dienste finden Sie unter Prozess zum Versiegeln von Anmeldedaten.

Titan-Chips verwenden ihre gerätespezifischen Schlüsselpaare, um ihre Firmware auf ähnliche Weise wie die Device Identifier Composition Engine (DICE) zu attestieren. Die ursprünglichen Titan-Chips wurden mit einem benutzerdefinierten Google-Design zertifiziert, da diese Chips vor der Einführung relevanter Branchenstandards hergestellt wurden. Die Erfahrung von Google bei der Herstellung und Bereitstellung sicherer Hardware motiviert uns, uns stärker an Standardisierungsprozessen zu beteiligen. Neuere Standards wie DICE, Trusted Platform Module (TPM) und Security Protocol and Data Mode (SPDM) enthalten Änderungen, die unsere Erfahrung widerspiegeln.

Titan-Integration

Wenn der Titan-Chip in eine Plattform integriert wird, bietet er Sicherheitsschutz für einen Anwendungsprozessor (AP). Titan kann beispielsweise mit einer CPU gekoppelt werden, auf der Arbeitslasten ausgeführt werden, einem Baseboard Management Controller (BMC) oder einem Beschleuniger für Arbeitslasten wie maschinelles Lernen.

Titan kommuniziert über den SPI-Bus mit dem AP. Titan befindet sich zwischen dem AP und dem Flash-Chip der Boot-Firmware des AP. So kann Titan jedes Byte dieser Firmware lesen und messen, bevor die Firmware beim Start ausgeführt wird.

Die folgenden Schritte werden ausgeführt, wenn eine Titan-fähige Plattform eingeschaltet wird:

1. Titan hält die CPU im Reset-Modus, während der interne Anwendungsprozessor von Titan unveränderlichen Code (das Boot-ROM) aus dem eingebetteten schreibgeschützten Speicher ausführt.
2. Titan führt einen integrierten Selbsttest aus, um zu prüfen, ob der gesamte Speicher (einschließlich des ROM) manipuliert wurde.
3. Das Boot-ROM von Titan überprüft die Firmware von Titan mithilfe der Public-Key-Kryptografie und mischt die Identität der überprüften Firmware in die Schlüsselhierarchie von Titan ein.
4. Das Boot-ROM von Titan lädt die überprüfte Firmware von Titan.
5. Die Titan-Firmware überprüft den Inhalt des Flash-Chips der Boot-Firmware des AP mithilfe der Public-Key-Kryptografie. Titan blockiert den Zugriff des AP auf den Flash-Chip der Boot-Firmware, bis die Überprüfung abgeschlossen ist.
6. Nach der Überprüfung setzt der Titan-Chip den AP zurück, sodass der AP gestartet werden kann.
7. Die AP-Firmware führt eine zusätzliche Konfiguration durch, zu der auch das Starten weiterer Boot-Images gehören kann. Der AP kann Messungen dieser Boot-Images erfassen und zur sicheren Überwachung an Titan senden.

Mit diesen Schritten wird die Integrität der ersten Anweisung erreicht, da Google die Boot-Firmware und das Betriebssystem, die auf der Maschine gestartet wurden, anhand der ersten Anweisung identifizieren kann, die während des Startvorgangs ausgeführt wird. Bei APs mit CPUs, die Microcode-Updates akzeptieren, kann Google anhand des Startvorgangs auch feststellen, welche Microcode-Patches vor der ersten Anweisung der Boot-Firmware abgerufen wurden. Weitere Informationen finden Sie unter Measured Boot Prozess.

Dieser Ablauf ähnelt dem Startvorgang, der von Plattformen mit einem TPM ausgeführt wird. Titan-Chips enthalten jedoch Funktionen, die in der Regel nicht auf Standard-TPMs verfügbar sind, z. B. die interne Firmware-Selbstattestierung von Titan oder die Sicherheit beim Upgrade der AP-Firmware, wie in den folgenden Abschnitten beschrieben.

Standard-TPM-Integrationen können anfällig für physische Interposer-Angriffe sein. Neuere Titan-Integrationen bei Google minimieren diese Angriffe durch die Verwendung integrierter Roots of Trust. Weitere Informationen finden Sie unter TPM Transport Security: Defeating Active Interposers with DICE (YouTube).

Sicheres Upgrade der Titan-Firmware

Die Firmware des Titan-Chips wird mit einem Schlüssel signiert, der in einem Offline-HSM gespeichert ist, das durch quorum-basierte Kontrollen geschützt ist. Das Boot-ROM von Titan überprüft die Signatur der Titan-Firmware bei jedem Start des Chips.

Die Titan-Firmware wird mit einer Sicherheitsversionsnummer (SVN) signiert, die den Sicherheitsstatus des Images angibt. Wenn ein Firmware-Image eine Korrektur für eine Sicherheitslücke enthält, wird die SVN des Images erhöht. Die Titan-Hardware ermöglicht es dem Produktionsnetzwerk, die SVN der Titan-Firmware stark zu attestieren, auch wenn ältere Firmware möglicherweise Sicherheitslücken aufwies. Mit dem Upgrade-Prozess können wir diese Sicherheitslücken in großem Maßstab beheben, auch wenn sie die Firmware von Titan selbst betreffen. Weitere Informationen finden Sie unter Wiederherstellung nach Sicherheitslücken in der Root-of-Trust Firmware.

Google hat zur neuesten Version der TPM Library-Spezifikation beigetragen, die jetzt Funktionen enthält, mit denen andere TPMs ähnliche Zusicherungen zur Selbstattestierung bieten können. Weitere Informationen finden Sie im Abschnitt „TPM Firmware-Limited and SVN-Limited Objects section (PDF) der Version 1.83 der TPM Architecture-Spezifikation. Diese TPM-Funktionen wurden in unseren neuesten Titan-Chips implementiert und bereitgestellt.

Sicheres Upgrade der AP-Firmware

Neben der Firmware von Titan signieren wir auch die Firmware, die auf dem AP ausgeführt wird, kryptografisch. Titan überprüft diese Signatur im Rahmen des Plattform-Startvorgangs. Außerdem wird diese Signatur bei jedem Update der AP-Firmware überprüft. So wird sichergestellt, dass nur authentische AP-Firmware-Images auf den Flash-Chip der Boot-Firmware des AP geschrieben werden können. Dieser Überprüfungsprozess minimiert Angriffe, bei denen versucht wird, dauerhafte Backdoors zu installieren oder die Plattform unbootfähig zu machen. Die Signaturüberprüfung bietet auch einen umfassenden Schutz für die Plattformen von Google, falls eine CPU eine Sicherheitslücke in ihrem eigenen Microcode-Authentifizierungsmechanismus aufweist.

Nächste Schritte

Weitere Informationen zum Prozess zur Überprüfung der Startintegrität