Der Inhalt dieses Dokuments wurde im Oktober 2023 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 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 einer Rechenzentrumsmaschine wird beim Booten ermittelt. 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 gezeigt, wie unsere Kontrollen bei jedem Schritt des Bootablaufs funktionieren.
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 des Maschinenverwaltungssystems von Google ist unsere Anmeldedaten-Infrastruktur, die aus einer internen Zertifizierungsstelle (Certificate Authority, CA) und anderen Elementen der Steuerungsebene besteht, die für die Koordinierung der Abläufe zur Rotation von Anmeldedaten zuständig sind.
Maschinen in der Produktionsflotte von Google führen bei der Einrichtung sicherer Kanäle eine 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 einem Versiegeln mit einem Trusted Platform Module (TPM) vergleichbar, einer Spezifikation, die von der Trusted Computing Group veröffentlicht wurde. Das kryptografische Versiegeln hat jedoch einige zusätzliche Vorteile. Titan verfügt über eine verbesserte Fähigkeit der Messung und Attestierung von Low-Level-Firmware.
Das kryptografische Versiegeln umfasst die folgenden beiden Kontrollen:
- Verschlüsselung sensibler Daten
- Eine Richtlinie, die erfüllt werden 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 private Schlüssel für die verschlüsselten 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 erzwungen. Jede Ebene im Boot-Stack misst die nächste Ebene und die Maschine bestätigt diese Kette von Messwerten am Ende des Bootvorgangs. 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 Bootvorgängen gespeichert.
Measured Boot-Vorgang
Der Boot-Stack von Google-Maschinen besteht aus vier Ebenen, die im folgenden Diagramm dargestellt werden.
Die Ebenen sind:
- Userspace: 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. Die versiegelten Anmeldedaten der Maschine werden dem Betriebssystem nur zur Verfügung gestellt, wenn alle Messungen, die während des Bootvorgangs erfasst werden, der Entschlüsselungsrichtlinie der versiegelten Anmeldedaten entsprechen, wie in der Google-Anmeldedateninfrastruktur 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 an der Arbeitslastplanung teilnehmen, wenn die Infrastruktur für die Maschinenverwaltung automatisierte Reparaturaktionen auslöst.
Wiederherstellung nach Sicherheitslücken im Kernel
Angenommen, eine Maschine führt die Kernel-Version A aus, aber Sicherheitsexperten stellen fest, 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. Im Rahmen dieses Vorgangs werden auch die alten Maschinenanmeldedaten 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.
Wiederherstellung nach Sicherheitslücken in Boot-Firmware
Angenommen, es gibt eine Sicherheitslücke in der Boot-Firmware anstelle des Betriebssystem-Kernels. 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. So kann Titan feststellen, ob die Boot-Firmware die Bootrichtlinie der Maschinenanmeldedaten erfüllt. Maschinen, die nicht die beabsichtigte Boot-Firmware ausführen, können keine neuen Maschinenanmeldedaten abrufen und diese Maschine kann erst dann an ihrem Maschinencluster teilnehmen, wenn ihre Boot-Firmware dem Intent der Steuerungsebene entspricht.
Wiederherstellung nach Sicherheitslücken in 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 den Titan-Bootloader kryptografisch, 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. Ältere, anfällige Titan-Firmware kann 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-Bootroutine von Titan wandelt diese Entropie zu einem 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. Dabei wird ein Ablauf verwendet, der der Device Identifier Composition Engine (DICE) ähnelt. 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.
- Weitere Sicherheits-Whitepaper finden Sie unter Whitepaper zum Thema Sicherheit.
Autoren: Jeff Andersen, Kevin Plybon