Der Inhalt dieses Dokuments wurde im Mai 2024 zum letzten Mal aktualisiert und stellt den Stand zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.
In diesem Dokument werden die Infrastrukturkontrollen beschrieben, die Google verwendet, um die Integrität des Bootvorgangs auf Produktionsmaschinen mit Titan zu erzwingen. Diese Kontrollen basieren auf einem Measured Boot-Prozess und sorgen dafür, dass Google seine Rechenzentrumsmaschinen über den gesamten Boot-Stack hinweg nach Sicherheitslücken wiederherstellen und die Maschinen von willkürlichen Bootstatus zurück zu bekanntermaßen fehlerfreien Konfigurationen führen kann.
Einführung
Der Sicherheitsstatus eines Rechners im Rechenzentrum hängt stark von der Konfiguration der Maschine beim Booten ab. Der Bootvorgang der Maschine konfiguriert die Hardware der Maschine und initialisiert ihr Betriebssystem, während dafür gesorgt wird, dass die Maschine sicher in der Produktionsumgebung von Google ausgeführt werden kann.
Bei jedem Schritt des Bootvorgangs implementiert Google branchenführende Kontrollen, um dazu beizutragen, dass der von uns erwartete Bootstatus erzwungen wird und die Sicherheit von Kundendaten gewährleistet ist. Diese Kontrollen sorgen dafür, dass unsere Maschinen in der vorgesehenen Software gestartet werden. Dadurch können wir Sicherheitslücken entfernen, die den anfänglichen Sicherheitsstatus der Maschine beeinträchtigen könnten.
In diesem Dokument wird der Bootvorgang beschrieben und es wird gezeigt, wie unsere Steuerelemente während des Bootvorgangs funktionieren. Die Hauptziele unserer Kontrollen sind:
- Über Root of Trust-Hardware Vertrauen in Maschinenanmeldedaten herstellen
- Maschinenanmeldedaten für eine Bootrichtlinie verschlüsseln, die zulässige Firmware- und Softwareversionen angibt
- Bootrichtlinie durch gemessenen Bootvorgang auf Maschinen erzwingen
Hintergrund
In diesem Abschnitt werden die Begriffe Maschinenanmeldedaten, Root of Trust-Hardwarekomponenten, versiegelte Anmeldedaten und kryptografisches Versiegeln definiert und jeweils Kontext dafür bereitgestellt.
Maschinenanmeldedaten
Eine der zentralen Komponenten im Computerverwaltungssystem von Google ist unsere Anmeldedateninfrastruktur. Diese besteht aus einer internen Zertifizierungsstelle (Certificate Authority, CA) und anderen Elementen der Steuerungsebene, die für die Koordinierung der Rotation von Anmeldedaten für die Anmeldedaten verantwortlich sind.
Maschinen in der Produktionsflotte von Google führen beim Einrichten sicherer Kanäle die gegenseitige Authentifizierung durch. Zur Durchführung der gegenseitigen Authentifizierung besitzt jede Maschine die öffentlichen CA-Schlüssel von Google. Jede Maschine hat auch ein eigenes Paar aus öffentlichen/privaten Schlüsseln sowie ein Zertifikat für dieses Schlüsselpaar.
Das öffentliche/private Schlüsselpaar jeder Maschine wird zusammen mit dem von der Zertifizierungsstelle signierten Zertifikat als Maschinenanmeldedaten bezeichnet. Diese werden von der Maschine für die Authentifizierung bei anderen Maschinen in der Flotte verwendet. Im Produktionsnetzwerk prüfen Maschinen vor dem Austausch von Traffic, ob die öffentlichen Schlüssel anderer Maschinen von der Zertifizierungsstelle von Google zertifiziert wurden.
Root of Trust-Hardwarekomponenten und kryptografisches Versiegeln
Im selben Maße, wie Computergeräte immer komplexer werden, wächst auch die Angriffsfläche jedes Geräts. Um dieser Entwicklung Rechnung zu tragen, werden Geräte immer häufiger mit Root of Trust-Hardwarekomponenten (RoTs) ausgestattet, also kleinen, vertrauenswürdigen Ausführungsumgebungen, mit denen sensible Daten für die Maschine geschützt werden. RoTs tauchen auch in Mobilgeräten wie Laptops oder Smartphones und in herkömmlicheren Geräten wie Desktop-PCs auf.
Die Rechenzentrumsmaschinen von Google bieten benutzerdefinierte, von Google entwickelte Root of Trust-Hardwarekomponenten, die in die tiefsten Schichten der einzelnen Maschinen eingebunden sind. Diese werden als Titan bezeichnet. Wir verwenden Titan in Verbindung mit einem Mechanismus namens kryptografisches Versiegeln, um dafür zu sorgen, dass jede Maschine die von uns erwartete Konfigurations- und Softwareversion ausführt.
Das kryptografische Versiegeln ist ein von Titan angebotener Dienst, der zum Schutz von Secrets verwendet wird. Die Versiegelungsfunktionen von Titan ähneln denen in der Spezifikation Trusted Platform Module (TPM), die von der Trusted Computing Group veröffentlicht wird. Die kryptografische Versiegelung von Titan hat einen zusätzlichen Vorteil, da Titan eine bessere Fähigkeit der Messung und Attestierung von Low-Level-Firmware bietet.
Das kryptografische Versiegeln umfasst die folgenden beiden Kontrollen:
- Verschlüsselung sensibler Daten
- Eine Richtlinie, die erfüllt sein muss, bevor die Daten entschlüsselt werden können
Versiegelte Anmeldedaten
Die Anmeldedateninfrastruktur von Google verwendet das kryptografische Versiegeln, um Maschinenanmeldedaten im Ruhezustand mit einem Schlüssel zu verschlüsseln, der von den Root of Trust-Hardwarekomponenten der Maschine gesteuert werden. Der verschlüsselte private Schlüssel der Anmeldedaten und das entsprechende Zertifikat werden als versiegelte Anmeldedaten bezeichnet. Neben Maschinenanmeldedaten verwendet Google diesen Versiegelungsmechanismus, um auch andere sensible Daten zu schützen.
Jede Maschine kann nur dann ihre Maschinenanmeldedaten entschlüsseln und darauf zugreifen, wenn sie eine Entschlüsselungsrichtlinie erfüllen kann, die angibt, welche Software die Maschine gestartet haben muss. Durch das Versiegeln der Maschinenanmeldedaten in einer Richtlinie, in der der gewünschte Release des Betriebssystem-Kernels angegeben ist, wird sichergestellt, dass die Maschine nur dann an ihrem Maschinencluster teilnehmen kann, wenn sie die erforderliche Kernel-Version gestartet hat.
Die Entschlüsselungsrichtlinie wird durch einen Prozess namens Measured Boot durchgesetzt. Jede Ebene im Boot-Stack misst die nächste Ebene. Die Maschine attestiert diese Messkette am Ende des Starts. Diese Messung ist häufig ein kryptografischer Hash.
Versiegelungsprozess für Anmeldedaten
In diesem Abschnitt wird der von Google-Maschinen verwendete Prozess für die Versiegelung von Anmeldedaten und für Measured Boot beschrieben. Das folgende Diagramm veranschaulicht diesen Ablauf.
Die folgenden Schritte laufen ab, um die Anmeldedaten einer Maschine für eine bestimmte Bootrichtlinie zu versiegeln:
- Die Maschinen-Automatisierungsinfrastruktur von Google initiiert ein Softwareupdate auf der Maschine. Sie leitet die gewünschten Softwareversionen an die Anmeldedateninfrastruktur weiter.
- Die Google-Anmeldedateninfrastruktur fordert einen Versiegelungsschlüssel von Titan an, der in einer Weise richtliniengebunden ist, dass Titan ihn nur verwendet, wenn die Maschine in der gewünschten Software gestartet wird.
- Die Anmeldedateninfrastruktur vergleicht die Richtlinie des zurückgegebenen Schlüssels mit dem Intent, der von der Maschinen-Automatisierungsinfrastruktur kommuniziert wird. Wenn die Anmeldedateninfrastruktur überzeugt ist, dass die Richtlinie mit dem Intent übereinstimmt, gibt sie zertifizierte Maschinenanmeldedaten an die Maschine aus.
- Die Anmeldedateninfrastruktur verschlüsselt diese Anmeldedaten mithilfe des in Schritt 2 erworbenen Versiegelungsschlüssels.
- Die verschlüsselten Anmeldedaten werden auf dem Laufwerk zur Entschlüsselung durch Titan bei nachfolgenden Startvorgängen gespeichert.
Measured Boot-Vorgang
Der Boot-Stack von Google-Maschinen besteht aus vier Ebenen, die im folgenden Diagramm dargestellt werden.
Die Layer sind:
- Nutzerbereich: Anwendungen wie Daemons oder Arbeitslasten.
- Systemsoftware: Ein Hypervisor oder Kernel. Die niedrigste Softwareebene, die eine Abstraktion von Hardwarefeatures wie Netzwerke, das Dateisystem oder virtuelle Arbeitsspeicher für den Userspace bereitstellt.
- Boot-Firmware: Die Firmware, die den Kernel initialisiert, z. B. als ein BIOS und Bootloader.
- Root of Trust-Hardwarekomponenten: ein Titan-Chip in Google-Maschinen, der die Firmware und andere Low-Level-CPU-Dienste kryptografisch misst.
Während des Bootvorgangs misst jede Ebene die nächste Ebene, bevor die Kontrolle an diese Ebene übergeben wird. Der versiegelte Berechtigungsnachweis des Computers wird dem Betriebssystem nur dann zur Verfügung gestellt, wenn sich alle während des Starts erfassten Messungen nach der Entschlüsselungsrichtlinie des versiegelten Berechtigungsnachweises richten, wie in der Anmeldedatenstruktur von Google angegeben. Wenn die Maschine daher Vorgänge mit ihren versiegelten Anmeldedaten ausführen kann, ist dies ein Hinweis darauf, dass die Maschine ihre Measured Boot-Richtlinie erfüllt. Dieser Prozess ist eine Form der impliziten Attestierung.
Wenn eine Maschine Software startet, die vom beabsichtigten Status abweicht, kann die Maschine mit den Anmeldedaten, die sie für den Betrieb innerhalb der Flotte benötigt, keine Vorgänge entschlüsseln und ausführen. Solche Maschinen können erst dann an der Arbeitslastplanung teilnehmen, wenn die Maschinenverwaltungsinfrastruktur automatisierte Reparaturaktionen auslöst.
Wiederherstellung nach Sicherheitslücken im Kernel
Angenommen, auf einer Maschine wird die Kernel-Version A ausgeführt, aber Sicherheitsexperten haben festgestellt, dass diese Kernel-Version eine Sicherheitslücke aufweist. In diesen Szenarien patcht Google die Sicherheitslücke und führt eine aktualisierte Kernel-Version B in der Flotte ein.
Neben dem Patchen der Sicherheitslücke gibt Google auch neue Maschinenanmeldedaten für jede Maschine in der Flotte aus. Wie unter Versiegelungsprozess für Anmeldedaten beschrieben, sind die neuen Maschinenanmeldedaten an eine Entschlüsselungsrichtlinie gebunden, die nur erfüllt ist, wenn die Kernel-Version B auf der Maschine startet. Jede Maschine, auf der der vorgesehene Kernel nicht ausgeführt wird, kann die neuen Maschinenanmeldedaten nicht entschlüsseln, da die Messungen der Boot-Firmware die Bootrichtlinie der Maschine nicht erfüllen. Als Teil dieses Prozesses werden auch die alten Anmeldedaten widerrufen.
Daher können diese Maschinen erst dann an ihrem Maschinencluster teilnehmen, wenn ihr Kernel so aktualisiert wurde, dass er dem Intent der Steuerungsebene entspricht. Durch diese Kontrollen wird sichergestellt, dass Maschinen, auf denen die Kernel-Version A mit der Sicherheitslücke ausgeführt wird, keine Jobs oder Nutzerdaten empfangen können, bis sie auf die Kernel-Version B aktualisiert wurden.
Nach Sicherheitslücken in der Boot-Firmware wiederherstellen
Angenommen, es gibt eine Sicherheitslücke in der Boot-Firmware und nicht im Kernel des Betriebssystems. Dieselben Kontrollen, die unter Wiederherstellung nach Sicherheitslücken im Kernel beschrieben werden, helfen Google bei einer Wiederherstellung nach einer solchen Sicherheitslücke.
Der Titan-Chip von Google misst die Boot-Firmware einer Maschine, bevor sie ausgeführt wird, damit Titan feststellen kann, ob die Boot-Firmware die Boot-Richtlinie der Maschinenanmeldedaten erfüllt. Computer, auf denen nicht die vorgesehene Boot-Firmware ausgeführt wird, können keine neuen Anmeldedaten erhalten, und diese Maschine kann nicht an ihrem Maschinen-Cluster teilnehmen, bis sich die Boot-Firmware nach der Absicht der Steuerungsebene richtet.
Wiederherstellung nach Sicherheitslücken in der Root-of-Trust-Firmware
RoTs sind nicht immun gegen Sicherheitslücken, aber die Boot-Kontrollen von Google ermöglichen sogar auf dieser Ebene des Boot-Stacks die Wiederherstellung nach Fehlern, innerhalb des änderbaren Codes des RoT.
Der Boot-Stack von Titan implementiert einen eigenen sicheren Measured Boot-Ablauf. Wenn ein Titan-Chip eingeschaltet wird, misst seine Hardware kryptografisch den Bootloader von Titan, der wiederum die Firmware von Titan misst. Ähnlich wie der Kernel und die Boot-Firmware der Maschine wird die Titan-Firmware kryptografisch mit einer Versionsnummer signiert. Der Bootloader von Titan validiert die Signatur und extrahiert die Versionsnummer der Titan-Firmware, wobei die Versionsnummer in das hardwarebasierte Schlüsselableitungs-Subsystem von Titan eingespeist wird.
Das Hardware-Subsystem von Titan implementiert ein versioniertes Schlüsselableitungsschema, wobei die Titan-Firmware mit Version X chipspezifische Schlüssel abrufen kann, die an alle Versionen kleiner oder gleich X gebunden sind. Die Titan-Hardware erlaubt es der Firmware mit Version X, auf Schlüssel zuzugreifen, die an Versionen gebunden sind, die kleiner oder gleich X sind, aber nicht größer als X sind. Alle fest an Titan gebundenen Secrets, einschließlich der Maschinenanmeldedaten, werden mit einem versionierten Schlüssel verschlüsselt.
Attestierungs- und Versiegelungsschlüssel sind für jeden Titan-Chip eindeutig. Eindeutige Schlüssel erlauben es Google, nur den Titan-Chips zu vertrauen, bei denen erwartet wird, dass sie in einem Google-Rechenzentrum ausgeführt werden.
Das folgende Diagramm zeigt Titan mit Versionsschlüsseln. Auf den Schlüssel "Version X+1" kann nicht von der Firmware der Version X zugegriffen werden, jedoch auf alle Schlüssel, die älter sind als dieser.
Bei einer schwerwiegenden Sicherheitslücke in der Titan-Firmware führt Google einen Patch mit einer höheren Versionsnummer ein und gibt dann neue Maschinenanmeldedaten aus, die an die höhere Titan-Firmwareversion gebunden sind. Alle älteren, anfälligen Titan-Firmwares können diese neuen Anmeldedaten nicht entschlüsseln. Wenn eine Maschine also Vorgänge mit seinen neuen Anmeldedaten in der Produktion ausführt, kann Google mit Sicherheit bestätigen, dass der Titan-Chip der Maschine die aktuelle Titan-Firmware ausführt.
Root of Trust-Authentizität gewährleisten
Die in diesem Dokument beschriebenen Kontrollen basieren auf der Funktionalität der Root of Trust-Hardwarekomponenten selbst. Die Anmeldedateninfrastruktur von Google stützt sich auf Signaturen, die von diesen RoTs ausgegeben werden, um zu wissen, ob die Maschine die beabsichtigte Software ausführt.
Daher ist es von entscheidender Bedeutung, dass die Anmeldedateninfrastruktur bestimmen kann, ob eine Root of Trust-Hardwarekomponente echt ist und ob der RoT aktuelle Firmware ausführt.
Zum Zeitpunkt der Herstellung eines jeden Titan-Chips wird er mit eindeutiger Entropie programmiert. Die Low-Level-Boot-Routine von Titan wandelt diese Entropie in einen gerätespezifischen Schlüssel um. Ein Secure Element auf der Titan-Fertigungsanlage bestätigt diesen chipspezifischen Schlüssel per Endorsement, sodass Google ihn als legitimen Titan-Chip erkennt.
Das folgende Diagramm veranschaulicht diesen Endorsement-Prozess.
In der Produktion verwendet Titan seinen gerätespezifischen Schlüssel, um jede Signatur, die es ausgibt, per Endorsement zu unterstützen. Titan-Chips nutzen einen ähnlichen Ablauf wie Device Identifier Composition Engine (DICE). Das Endorsement enthält die Versionsinformationen der Titan-Firmware. Diese Attestierung verhindert, dass ein Angreifer die Identität einer von einem Titan-Chip ausgegebenen Signatur annimmt und ein Rollback auf ältere Titan-Firmware sowie die Übernahme der Identität neuerer Titan-Firmware durchführt. Mit diesen Kontrollen kann Google prüfen, ob die von Titan empfangenen Signaturen von authentischer Titan-Hardware ausgegeben wurden, die authentische Titan-Firmware ausführt.
Auf der Bootintegrität aufbauen
In diesem Artikel wurden die Mechanismen beschrieben, die gewährleisten, dass die Anwendungsprozessoren von Maschinen den vorgesehenen Code starten. Diese Mechanismen basieren auf einem Measured Boot-Ablauf, in Verbindung mit einem Root of Trust-Hardwarekomponenten-Chip.
Das Bedrohungsmodell von Google umfasst Angreifer, die sich physisch am Bus zwischen der CPU und dem RoT positionieren, mit dem Ziel, die entschlüsselten Anmeldedaten der Maschine auf unzulässige Weise abzurufen. Um dieses Risiko zu minimieren, treibt Google die Entwicklung eines standardbasierten Ansatzes zur Vereitelung aktiver Interposer voran. Dabei werden die TPM und DPE APIs von Trusted Computing Group und der integrierte Caliptra-Root of Trust zusammengeführt.
Nächste Schritte
- Informationen dazu, wie Google dazu beiträgt, die Integrität komplexer Boot-Stacks von verteilten Maschinen zu gewährleisten, finden Sie unter Remote-Attestierung verteilter Maschinen.
- Eine Übersicht über die Sicherheitsinfrastruktur von Google finden Sie in der Übersicht über das Sicherheitsdesign der Google-Infrastruktur.
- Weitere Informationen dazu, wie Google mit Titan-Sicherheitslösungen zu Branchenstandards beiträgt, finden Sie im Vortrag TPM Attested Boot in Big, Distributed Environments auf dem YouTube-Kanal der Trusted Computing Group.
Autoren: Jeff Andersen, Kevin Plybon