Application Layer Transport Security

Von Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt und Julien Boeuf

Die Inhalte entsprechen den zum Dezember 2017 vorliegenden Informationen. Dieses Whitepaper gibt damit den Stand zu dem Zeitpunkt wieder, als es verfasst wurde. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich künftig aber ändern, da wir den Schutz unserer Kunden kontinuierlich verbessern.

Zusammenfassung für CIOs

  • Google Application Layer Transport Security (ALTS) ist ein von Google entwickeltes System zur gegenseitigen Authentifizierung und zur Transportverschlüsselung, das zur Sicherung von RPC-Kommunikation (Remote Procedure Call) in der Google-Infrastruktur verwendet wird. ALTS entspricht in etwa dem Konzept der gegenseitig authentifizierten TLS (Transport Layer Security). Es wurde jedoch weiterentwickelt und so optimiert, dass es den Anforderungen der Rechenzentren von Google genügt.
  • Das ALTS-Vertrauensmodell wurde auf cloudähnliche Containeranwendungen zugeschnitten. Identitäten sind an Entitäten statt an einen bestimmten Servernamen oder Host gebunden. Dieses Vertrauensmodell ermöglicht es, dass Replikation, Load-Balancing und Neuplanung von Mikrodiensten auf allen Hosts nahtlos erfolgen können.
  • ALTS stützt sich auf zwei Protokolle: das Handshakeprotokoll (mit Sitzungswiederaufnahme) und das Aufzeichnungsprotokoll. Diese Protokolle regeln, wie Sitzungen eingerichtet, authentifiziert, verschlüsselt und wieder aufgenommen werden.
  • ALTS ist eine benutzerdefinierte TLS-Lösung, die wir bei Google verwenden. Wir haben ALTS auf unsere Produktionsumgebung zugeschnitten, sodass zwischen ALTS und dem Industriestandard TLS einige Kompromisse erforderlich waren. Weitere Informationen hierzu finden Sie im Abschnitt Vor- und Nachteile.

Einführung

Die Produktionssysteme bei Google bestehen aus einer Konstellation von Mikrodiensten1, die zusammen pro Sekunde O(10) Remote-Prozeduraufrufe (RPCs) ausgeben. Wenn ein Google-Entwickler eine Produktionsarbeitslast2 plant, sind alle von dieser Arbeitslast ausgegebenen oder empfangenen RPCs standardmäßig mit ALTS geschützt. Dieser automatische, konfigurationsfreie Schutz wird von der Google Application Layer Transport Security (ALTS) bereitgestellt. Zusätzlich zu den automatischen Schutzfunktionen, die den Remote-Prozeduraufrufen zugewiesen werden, ermöglicht ALTS auch eine einfache Dienstreplikation, einfaches Load-Balancing und eine einfache Neuplanung der Produktionscomputer. In diesem Whitepaper werden ALTS und die Bereitstellung dieses Verschlüsselungssystems über die Produktionsinfrastruktur von Google erläutert.

Zielgruppe: Dieses Dokument richtet sich an Sicherheitsexperten der Infrastruktur, die wissen möchten, wie die Authentifizierung und die Transportsicherheit nach Bedarf in Google erfolgen.

Voraussetzungen: Zusätzlich zu dieser Einführung werden grundlegende Kenntnisse der Clusterverwaltung bei Google vorausgesetzt.

Sicherheit auf Anwendungsebene und ALTS

Viele Anwendungen, von Webbrowsern bis hin zu VPNs, schützen Daten bei der Übertragung3 auf Basis sicherer Kommunikationsprotokolle wie TLS (Transport Layer Security) und IPSec. Bei Google verwenden wir ALTS, ein gegenseitiges Authentifizierungs- und Transportverschlüsselungssystem, das auf der Anwendungsschicht ausgeführt wird, um die RPC-Kommunikation zu schützen. Durch die Sicherheit auf Anwendungsebene erhalten die Anwendungen eine authentifizierte Remote-Peer-Identität, die eine Implementierung sehr detaillierter Autorisierungsrichtlinien ermöglicht.

Verzicht auf TLS

Es mag ungewöhnlich wirken, dass Google eine eigene Sicherheitslösung wie ALTS einsetzt, wo doch der Internettraffic heutzutage größtenteils mit TLS verschlüsselt wird. Die Entwicklung von ALTS bei Google begann 2007. Zur gleichen Zeit wurde TLS zur Unterstützung vieler Legacy-Protokolle gebündelt, die nicht unseren Mindestsicherheitsstandards entsprachen. Wir hätten unsere Sicherheitslösung entwickeln können, indem wir die benötigten TLS-Komponenten übernommen und die gewünschten Zusätze implementiert hätten. Die Vorteile, ein für Google besser geeignetes System völlig neu zu entwickeln, übertrafen jedoch die Vorteile des Patchens eines vorhandenen Systems. Außerdem ist ALTS für unsere Anforderungen besser geeignet und historisch sicherer als ältere TLS. Im Folgenden sind die wichtigsten Unterschiede zwischen TLS und ALTS aufgeführt.

  • Zwischen den Vertrauensmodellen4 von TLS mit HTTPS-Semantiken und ALTS besteht ein grundlegender Unterschied. Bei TLS sind die Serveridentitäten an einen bestimmten Namen und an ein entsprechendes Namensschema gebunden. Bei ALTS kann dieselbe Identität mit mehreren Namensschemas verwendet werden. Diese Ebene der Indirektion bietet mehr Flexibilität und vereinfacht die Replikation, das Load-Balancing und die Neuplanung von Mikrodiensten zwischen Hosts erheblich.
  • Im Vergleich zu TLS ist ALTS einfacher in der Konzeption und Implementierung. Daher lässt es sich mithilfe manueller Quellcodeüberprüfung oder umfassendem Fuzzing einfacher auf Programmfehler und Sicherheitslücken überprüfen.
  • ALTS verwendet Protokollpuffer, um seine Zertifikate und Protokollnachrichten zu serialisieren. TLS nutzt hingegen X.509-Zertifikate, die mit ASN.1 codiert sind. Die meisten unserer Produktionsdienste verwenden Protokollpuffer für die Kommunikation, manchmal auch für die Speicherung. Damit ist ALTS besser für die Umgebung von Google geeignet.

Design von ALTS

ALTS ist ein hoch zuverlässiges, vertrauenswürdiges System, das Dienst-zu-Dienst-Authentifizierung und Sicherheit bei minimaler Nutzerbeteiligung ermöglicht. Dies konnte nur durch die folgenden Eigenschaften erreicht werden, die Teil des ALTS-Designs sind:

  • Transparenz: Die ALTS-Konfiguration ist für die Anwendungsschicht transparent. Dienst-RPCs werden standardmäßig mit ALTS gesichert. Dadurch können sich Anwendungsentwickler auf die funktionale Logik ihrer Dienste konzentrieren, ohne sich mit der Verwaltung von Anmeldedaten oder Sicherheitskonfigurationen beschäftigen zu müssen. Während eines Dienst-zu-Dienst-Verbindungsaufbaus stattet ALTS die Anwendungen mit einer authentifizierten Remote-Peer-Identität aus, die für detaillierte Autorisierungsprüfungen und Audits verwendet werden kann.
  • Kryptografie auf dem neuesten Stand der Technik: Alle kryptografischen Primitive und Protokolle, die von ALTS verwendet werden, sind bezüglich aktuell bekannter Angriffe auf dem neuesten Stand. ALTS läuft auf Google-gesteuerten Computern. Das bedeutet, dass alle unterstützten kryptografischen Protokolle einfach aktualisiert und schnell bereitgestellt werden können.
  • Identitätsmodell: ALTS führt die Authentifizierung hauptsächlich anhand der Identität und nicht des Hostnamens durch. Bei Google hat jede Netzwerkeinheit (z. B. ein Unternehmensnutzer, ein physischer Computer, ein Produktionsdienst oder eine Arbeitslast) eine zugeordnete Identität. Die gesamte Kommunikation zwischen den Diensten wird gegenseitig authentifiziert.
  • Schlüsselverteilung: Bei ALTS hat jede Arbeitslast eine Identität, die als ein Set von Anmeldedaten ausgedrückt wird. Diese Anmeldedaten werden während der Initialisierung in jeder Arbeitslast ohne Nutzereingriff bereitgestellt. Parallel dazu werden für Computer und Arbeitslasten ein Root of Trust und eine Vertrauenskette für diese Anmeldedaten eingerichtet. Das System ermöglicht die automatische Rotation und Sperrung von Zertifikaten, ohne dass Anwendungsentwickler aktiv werden müssen.
  • Skalierbarkeit: ALTS ist für hohe Skalierbarkeit ausgelegt, um den enormen Umfang der Google-Infrastruktur zu unterstützen. Diese Anforderung führte zur Entwicklung einer effizienten Sitzungswiederaufnahme.
  • Langlebige Verbindungen: Kryptografische Vorgänge für den authentifizierten Schlüsselaustausch sind rechenintensiv. Damit dem Umfang der Google-Infrastruktur Rechnung getragen wird, können Verbindungen nach einem ersten ALTS-Handshake länger aufrechterhalten und so die Systemleistung insgesamt verbessert werden.
  • Einfachheit: TLS unterstützt standardmäßig Legacy-Protokollversionen und eine entsprechende Abwärtskompatibilität. ALTS ist wesentlich einfacher, da Google sowohl Clients als auch Server kontrolliert, die wir für eine native Unterstützung von ALTS entwickelt haben.

ALTS-Vertrauensmodell

ALTS führt die Authentifizierung hauptsächlich nach Identität und nicht nach Host durch. Bei Google hat jede Netzwerkeinheit (z. B. ein Unternehmensnutzer, ein physischer Computer oder ein Produktionsdienst) eine zugeordnete Identität. Diese Identitäten sind in ALTS-Zertifikate eingebettet und werden für die Peer-Authentifizierung während des sicheren Verbindungsaufbaus verwendet. Im von uns angewendeten Modell werden die Produktionsdienste als Produktionseinheiten ausgeführt, die von unseren Site Reliability Engineers (SREs)5 verwaltet werden können. Die Entwicklungsversionen dieser Produktionsdienste werden als Testeinheiten ausgeführt, die sowohl von SREs als auch von Entwicklern verwaltet werden können.

Beispiel: Es gibt ein Produkt mit zwei Diensten, Dienst-Front-End und Dienst-Back-End. SREs können die Produktionsversion dieser Dienste starten: service-frontend-prod und service-backend-prod. Entwickler können zu Testzwecken Entwicklungsversionen dieser Dienste erstellen und starten: service-frontend-dev und service-backend-dev. Die Autorisierungskonfiguration in den Produktionsdiensten wird so konfiguriert, dass den Entwicklungsversionen der Dienste nicht vertraut wird.

ALTS-Anmeldedaten

Es gibt drei Arten von ALTS-Anmeldedaten, die alle im Nachrichtenformat des Protokollpuffers abgefasst sind.

  • Masterzertifikat: Dieses Zertifikat wird von einem Remote-Signaturdienst signiert und zur Überprüfung von Handshakezertifikaten verwendet. Das Masterzertifikat enthält einen öffentlichen Schlüssel, der einem privaten Masterschlüssel zugeordnet ist, z. B. einem RSA-Schlüsselpaar. Mit dem privaten Schlüssel werden Handshakezertifikate signiert. Wenn diese Zertifikate in Kombination mit der unten beschriebenen ALTS-Richtlinie verwendet werden, handelt es sich im Wesentlichen um eingeschränkte Zwischenzertifikate der Zertifizierungsstelle. Masterzertifikate werden normalerweise für Produktionscomputer und Planungstools für Containerarbeitslasten, z. B. den Borgmaster6, ausgestellt.
  • Handshakezertifikat: Dieses Zertifikat wird lokal durch den privaten Masterschlüssel erstellt und signiert. Es enthält die Parameter, die während des ALTS-Handshakes (sicherer Verbindungsaufbau) verwendet werden, z. B. statische DH-Parameter (Diffie-Hellman) und die Handshakechiffren. Außerdem enthält das Handshakezertifikat das Masterzertifikat, von dem es abgeleitet ist, das heißt das Zertifikat, das dem privaten Masterschlüssel zugeordnet ist, der das Handshakezertifikat signiert.
  • Wiederaufnahmeschlüssel: Dieser Schlüssel ist geheim. Er wird dazu verwendet, Wiederaufnahmetickets zu verschlüsseln. Der Schlüssel wird durch eine Wiederaufnahme-IDR identifiziert. Diese ist eindeutig und wird unter allen Produktionsarbeitslasten geteilt, die mit derselben Identität und in derselben Rechenzentrumszelle ausgeführt werden. Weitere Informationen zur Sitzungswiederaufnahme mit ALTS finden Sie unter Sitzungswiederaufnahme.

Abbildung 1 zeigt die ALTS-Zertifikatskette, die aus einem Verifizierungsschlüssel des Signaturdienstes, einem Masterzertifikat und einem Handshakezertifikat besteht. Die Verifizierungsschlüssel des Signaturdienstes sind die Grundlage für das Vertrauen in ALTS. Sie werden auf allen Google-Computern in unseren Produktions- und Unternehmensnetzwerken installiert.

Abbildung 1: ALTS-Zertifikatskette

In ALTS zertifiziert ein Signaturdienst die Masterzertifikate, die wiederum Handshakezertifikate zertifizieren. Da Handshakezertifikate häufiger erstellt werden als Masterzertifikate, entlastet diese Architektur den Signaturdienst. Die Zertifikatsrotation bei Google erfolgt häufig, insbesondere bei Handshakezertifikaten7. Die häufige Rotation kompensiert die statischen Schlüsselaustauschpaare, die in den Handshakezertifikaten8 enthalten sind.

Zertifikatsausstellung

Die Entitäten im Netzwerk müssen mit Handshakezertifikaten versehen sein, um an einem sicheren ALTS-Handshake teilnehmen zu können. Zuerst erhält der Aussteller ein vom Signaturdienst signiertes Masterzertifikat und gibt es optional an die Entität weiter. Dann wird ein Handshakezertifikat erstellt und vom zugehörigen privaten Masterschlüssel signiert.

Wenn Zertifikate an Computer und Nutzer ausgestellt werden, ist der Aussteller in der Regel unsere interne Zertifizierungsstelle (Certificate Authority, CA). Wenn Zertifikate an Arbeitslasten ausgestellt werden, ist der Aussteller in der Regel der Borgmaster. Der Aussteller kann jedoch auch jede andere Entität sein, z. B. ein eingeschränkter Borgmaster für eine Testzelle in einem Rechenzentrum.

Abbildung 2 zeigt, wie ein Masterzertifikat mit dem Signaturdienst erstellt wird. Der Prozess besteht aus den folgenden Schritten:

Abbildung 2: Zertifikatsausstellung

  1. Der Zertifikatsaussteller sendet eine Anfrage für die Signierung des Zertifikats (Certificate Signing Request, CSR) an den Signaturdienst. Diese Anfrage fordert den Signaturdienst auf, ein Zertifikat für die Identität A zu erstellen. Diese Identität kann etwa ein Unternehmensnutzer oder die Identität eines Google-Produktionsdienstes sein.
  2. Der Signaturdienst legt den Aussteller des Zertifikats (in der CSR enthalten) auf den Antragsteller (in diesem Fall den Zertifikatsaussteller) fest und signiert es. Zur Erinnerung: Der entsprechende öffentliche (verifizierende) Schlüssel des Signaturdienstes ist auf jedem Google-Computer installiert.
  3. Der Signaturdienst sendet das signierte Zertifikat zurück.
  4. Ein Handshakezertifikat wird für die Identität A erstellt und durch den privaten Schlüssel signiert, der dem Masterzertifikat zugeordnet ist.

Wie im obigen Ablauf dargestellt, sind bei ALTS der Aussteller und der Unterzeichner eines Zertifikats zwei verschiedene logische Entitäten. In diesem Fall ist der Aussteller die Zertifikatsaussteller-Entität, während der Unterzeichner der Signaturdienst ist.

In ALTS gibt es drei allgemeine Kategorien von Zertifikaten: Nutzer, Computer und Arbeitslast. In den folgenden Abschnitten wird beschrieben, wie diese verschiedenen Zertifikate in ALTS erstellt und verwendet werden.

Nutzerzertifikate

Bei Google wird ALTS zur Sicherung der Remote-Prozeduraufrufe (Remote Procedure Calls, RPCs) verwendet, die von Nutzern an Produktionsdienste ausgegeben werden. Ein Nutzer muss ein gültiges Handshakezertifikat zur Verfügung stellen, um einen RPC auszugeben. Beispiel: Alice möchte eine Anwendung verwenden, um einen ALTS-sicheren RPC auszugeben. Sie kann sich bei der internen Zertifizierungsstelle von Google authentifizieren. Dazu verwendet Alice ihren Nutzernamen, ihr Passwort und ihre Bestätigung in zwei Schritten. Durch diesen Vorgang erhält Alice ein Handshakezertifikat, das 20 Stunden gültig ist.

Computerzertifikate

Jeder Produktionscomputer in den Rechenzentren von Google besitzt ein computereigenes Masterzertifikat. Dieses Zertifikat wird dazu verwendet, Handshakezertifikate für Kernanwendungen auf diesem Computer zu erstellen, z. B. Computerverwaltungs-Daemons. Die primäre Identität, die in ein Computerzertifikat eingebettet ist, bezieht sich auf den typischen Zweck des Computers. Zum Beispiel können Computer, die unterschiedliche Arten von Produktions- und Entwicklungsarbeitslasten ausführen, unterschiedliche Identitäten haben. Die Masterzertifikate können nur von Computern verwendet werden, die verifizierte Softwarestacks ausführen. In einigen Fällen beruht das Vertrauen auf benutzerdefinierter Sicherheitshardware9. Alle Masterzertifikate des Produktionscomputers werden von der Zertifizierungsstelle ausgestellt und alle paar Monate rotiert. Außerdem werden alle Handshakezertifikate alle paar Stunden rotiert.

Arbeitslastzertifikate

Ein entscheidender Vorteil von ALTS ist, dass es auf der Idee einer Arbeitslastidentität basiert. Dies vereinfacht die Replikation, den Lastenausgleich und die Neuplanung von Diensten auf mehreren Computern. Für die Clusterverwaltung und die Zuweisung von Computerressourcen in großem Maßstab verwenden wir in unserem Produktionsnetzwerk ein System mit dem Namen Borg10. Die Art und Weise, wie Borg Zertifikate ausstellt, ist Teil der computerunabhängigen Implementierung von Arbeitslastidentitäten durch ALTS.

Jede Arbeitslast in unserem Produktionsnetzwerk wird in einer Borg-Zelle ausgeführt. Jede Zelle enthält einen logischen Zentralcontroller namens Borgmaster und mehrere Agent-Prozesse namens Borglets, die auf jedem Computer in dieser Zelle ausgeführt werden. Arbeitslasten werden mit zugehörigen Handshake-Arbeitslastzertifikaten initialisiert, die vom Borgmaster ausgestellt wurden. Abbildung 3 zeigt den Vorgang einer Arbeitslastzertifizierung in ALTS mit Borg.

Abbildung 3: Erstellung eines Handshakezertifikats im Google-Produktionsnetzwerk

Der Borgmaster ist jetzt bereit, Arbeitslasten zu planen, die ALTS verwenden sollen. Die folgenden Schritte werden ausgeführt, wenn ein Client eine Arbeitslast so plant, dass sie als gegebene Identität auf Borg ausgeführt wird.

  1. Auf jedem Borgmaster sind ein computereigenes Masterzertifikat und ein zugehöriger privater Schlüssel (nicht im Diagramm dargestellt) vorinstalliert.
  2. ALTSd11 generiert ein Borgmaster-Handshakezertifikat und signiert es mit dem privaten Schlüssel des Computermasters. Damit kann der Borgmaster ALTS-sichere RPCs ausstellen.
  3. Der Borgmaster erstellt ein Basis-Masterzertifikat für Arbeitslasten und den entsprechenden privaten Schlüssel. Dann initiiert er eine Anfrage (einen ALTS-gesicherten RPC), um dieses Basis-Masterzertifikat für Arbeitslasten durch den Signaturdienst signieren zu lassen. Dadurch führt der Signaturdienst den Borgmaster als Aussteller dieses Zertifikats auf.
  4. Der Borgmaster überprüft, ob der Client berechtigt ist, Arbeitslasten als die Identität auszuführen, die in der Arbeitslastkonfiguration angegeben ist. Falls ja, plant der Borgmaster die Borg-Arbeitslast auf dem Borglet und gibt ein Arbeitslast-Handshakezertifikat und den entsprechenden privaten Schlüssel aus. Dieses Zertifikat wird vom Basis-Masterzertifikat für Arbeitslasten verkettet. Das Arbeitslast-Handshakezertifikat und dessen privater Schlüssel werden dann sicher über einen gegenseitig authentifizierten ALTS-geschützten Kanal zwischen Borgmaster und Borglet an das Borglet übermittelt. Der Borgmaster rotiert sein Basis-Masterzertifikat für Arbeitslasten und stellt etwa alle zwei Tage neue Handshakezertifikate für alle laufenden Arbeitslasten aus. Darüber hinaus erhält jede Arbeitslast, die als derselbe Nutzer in derselben Zelle ausgeführt wird, denselben Wiederaufnahmeschlüssel und dieselbe Kennung (IDR), die vom Borgmaster bereitgestellt werden.
  5. Wenn die Arbeitslast einen ALTS-sicheren RPC durchführen muss, verwendet sie das Arbeitslast-Handshakezertifikat im Handshakeprotokoll. Die IDR wird außerdem als Teil des Handshakes verwendet, um die Sitzungswiederaufnahme zu initiieren. Weitere Informationen zur Sitzungswiederaufnahme mit ALTS finden Sie unter Sitzungswiederaufnahme.

ALTS-Richtlinien durchsetzen

Die ALTS-Richtlinie ist ein Dokument, das auflistet, welche Aussteller berechtigt sind, bestimmte Kategorien von Zertifikaten für bestimmte Identitäten auszustellen. Das Dokument wird an jeden Computer in unserem Produktionsnetzwerk verteilt. Zum Beispiel ist es gemäß ALTS-Richtlinie erlaubt, dass die CA Zertifikate für Computer und Nutzer ausstellt. Außerdem kann der Borgmaster Zertifikate für Arbeitslasten ausstellen.

Wir haben festgestellt, dass die Erzwingung der Richtlinie während der Zertifikatsüberprüfung und nicht während der Zertifikatsausstellung einen flexibleren Ansatz darstellt. Auf diese Weise können verschiedene Richtlinien für verschiedene Bereitstellungstypen erzwungen werden. Beispielsweise möchten wir, dass eine Richtlinie in einem Testcluster toleranter ist als eine in einem Produktionscluster.

Während des ALTS-Handshakes schließt die Zertifikatsvalidierung eine Überprüfung der ALTS-Richtlinie ein. Die Richtlinie stellt sicher, dass der Aussteller, der in dem zu validierenden Zertifikat aufgeführt ist, berechtigt ist, dieses Zertifikat auszustellen. Wenn dies nicht der Fall ist, wird das Zertifikat zurückgewiesen und der Handshakevorgang schlägt fehl. Abbildung 4 zeigt, wie die Erzwingung einer Richtlinie in ALTS funktioniert. Setzen Sie das Szenario in Abbildung 2 voraus und nehmen Sie an, dass Mallory (ein Unternehmensnutzer, der seine Berechtigungen eskalieren möchte) ein Masterzertifikat an den Netzwerkadministrator senden möchte. Dabei handelt es sich um eine leistungsstarke Identität, die das Netzwerk neu konfigurieren kann. Selbstverständlich ist Mallory in der ALTS-Richtlinie nicht dazu berechtigt, diesen Vorgang durchzuführen.

Abbildung 4: Zertifikatsausstellung und -nutzung

  1. Mallory stellt ein Masterzertifikat für die Identität des Netzwerkadministrators aus und lässt es vom Signaturdienst signieren. Dieser Vorgang ist den ersten drei Schritten in Abbildung 2 ähnlich.
  2. Mithilfe des privaten Masterschlüssels, der dem Masterzertifikat zugeordnet ist, erstellt und signiert Mallory lokal ein Handshakezertifikat für den Netzwerkadministrator.
  3. Wenn Mallory versucht, die Identität des Netzwerkadministrators mithilfe des erstellten Handshakezertifikats anzunehmen, wird der Vorgang durch Erzwingen der ALTS-Richtlinie an dem Peer, mit dem Mallory zu kommunizieren versucht, blockiert.

Zertifikatssperrung

Bei Google wird ein Zertifikat ungültig, wenn es abläuft oder in unserer Zertifikatssperrliste (Certificate Revocation List, CRL) enthalten ist. In diesem Abschnitt werden die Mechanismen der internen Zertifikatssperrung von Google beschrieben, die sich zum Zeitpunkt der Erstellung dieses Dokuments noch im Testlauf befinden.

Alle Zertifikate, die für Nutzer in Unternehmensumgebungen ausgestellt werden, haben einen täglichen Ablaufzeitstempel, der die Nutzer dazu zwingt, sich täglich neu zu authentifizieren. Viele der an Produktionscomputer ausgegebenen Zertifikate verwenden keine Ablaufzeitstempel. Wir vermeiden Zeitstempel für Produktionszertifikate, da diese zu Ausfällen durch Zeitsynchronisierungsprobleme führen können. Stattdessen verwenden wir die CRL als Quelle für die Zertifikatsbehandlung mit Rotation und Vorfallreaktion. Abbildung 5 zeigt, wie die CRL funktioniert.

Abbildung 5: Erstellung des Masterzertifikats mit Sperrkennung

  1. Wenn eine Instanz unserer Zertifizierungsstelle initialisiert wird12, kontaktiert sie den CRL-Dienst und fragt nach einem Sperrkennungsbereich. Eine Sperrkennung ist 64 Bit lang und besteht aus zwei Komponenten: einer 8-Bit-Zertifikatskategorie (z. B. Nutzer- oder Computerzertifikat) und einer 56-Bit-Zertifikatskennung. Der CRL-Dienst wählt einen Bereich dieser Kennungen aus und gibt diesen an die Zertifizierungsstelle zurück.
  2. Wenn die Zertifizierungsstelle eine Anfrage für ein Masterzertifikat erhält, erstellt sie das Zertifikat und bettet eine Sperrkennung aus diesem Bereich ein.
  3. Parallel dazu ordnet die Zertifizierungsstelle das neue Zertifikat der Sperrkennung zu und sendet diese Informationen an den CRL-Dienst.
  4. Die Zertifizierungsstelle stellt das Masterzertifikat aus.

Welche Sperrkennungen den Handshakezertifikaten zugewiesen werden, hängt davon ab, wie das Zertifikat verwendet werden soll. Zum Beispiel erben Handshakezertifikate für Unternehmensnutzer die Sperrkennung des Masterzertifikats des Nutzers. Bei Handshakezertifikaten für die Borg-Arbeitslasten wird die Sperrkennung durch den Bereich der Sperrkennungen des Borgmasters zugewiesen. Dieser Kennungsbereich wird dem Borgmaster vom CRL-Dienst in einem ähnlichen Prozess wie in Abbildung 5 zugewiesen. Wenn ein Peer an einem ALTS-Handshake beteiligt ist, überprüft er eine lokale Kopie der CRL-Datei, um sicherzustellen, dass das Remote-Peer-Zertifikat nicht gesperrt ist.

Der CRL-Dienst kompiliert alle Sperrkennungen in eine einzige Datei. Diese Datei kann an alle Google-Computer übertragen werden, die ALTS verwenden. Während die CRL-Datenbank mehrere hundert Megabyte groß ist, umfasst die generierte CRL-Datei aufgrund verschiedener Komprimierungstechniken nur wenige Megabyte.

ALTS-Protokolle

ALTS stützt sich auf zwei Protokolle: das Handshakeprotokoll (mit Sitzungswiederaufnahme) und das Aufzeichnungsprotokoll. Nachstehend finden Sie einen allgemeinen Überblick über beide Protokolle. Diese allgemeinen Beschreibungen enthalten jedoch keine detaillierten Spezifikationen der Protokolle.

Handshakeprotokoll

Das ALTS-Handshakeprotokoll ist ein Diffie-Hellman-basiertes authentifiziertes Schlüsselaustauschprotokoll, das sowohl die Perfect Forward Secrecy (PFS) als auch die Sitzungswiederaufnahme unterstützt. Die ALTS-Infrastruktur stellt sicher, dass jeder Client und Server über ein Zertifikat mit den entsprechenden Identitäten und einen ECDH-Schlüssel (Elliptic Curve Diffie-Hellman) verfügt, der mit einem vertrauenswürdigen Signaturdienst-Verifizierungsschlüssel verkettet ist. In ALTS ist die PFS nicht standardmäßig aktiviert, da diese statischen ECDH-Schlüssel häufig aktualisiert werden, um die Forward Secrecy zu erneuern, auch wenn sie nicht für einen Handshake verwendet wird. Während eines Handshakes verhandeln der Client und der Server auf sichere Weise einen freigegebenen Durchgangsverschlüsselungsschlüssel und das Aufzeichnungsprotokoll, das der Verschlüsselungsschlüssel schützen soll. Beispiel: Der Client und der Server könnten einem 128-Bit-Schlüssel zustimmen, der zum Schutz einer RPC-Sitzung mit AES-GCM verwendet wird. Der Handshake besteht aus vier serialisierten Protokollpuffer-Nachrichten, von denen eine Übersicht in Abbildung 6 zu sehen ist.

Abbildung 6: ALTS-Handshakeprotokoll-Nachrichten

  1. Der Client initiiert den Handshake, indem er eine ClientInit-Nachricht sendet. Diese Nachricht enthält das Handshakezertifikat des Clients und eine Liste der handshakespezifischen Chiffren und Aufzeichnungsprotokolle, die der Client unterstützt. Wenn der Client versucht, eine beendete Sitzung wiederaufzunehmen, enthält es eine Wiederaufnahmekennung und ein verschlüsseltes Wiederaufnahmeticket für den Server.

  2. Bei Empfang der ClientInit-Nachricht überprüft der Server das Clientzertifikat. Ist dieses gültig, wählt der Server eine Handshakechiffre und ein Aufzeichnungsprotokoll aus der vom Client bereitgestellten Liste aus. Der Server verwendet eine Kombination aus Informationen in der ClientInit-Nachricht und eigenen lokalen Informationen, um das DH-Austauschergebnis zu berechnen. Dieses Ergebnis wird zusammen mit dem Transkript des Protokolls als Eingabe für die Schlüsselableitungsfunktionen13 verwendet, um die folgenden geheimen Sitzungsschlüssel zu generieren:

    • Einen geheimen Aufzeichnungsprotokollschlüssel M, der zur Verschlüsselung und Authentifizierung von Nutzlastnachrichten verwendet wird.
    • Einen geheimen Wiederaufnahmeschlüssel R, der in künftigen Sitzungen in einem Wiederaufnahmeticket verwendet wird.
    • Einen geheimen Authentifikatorschlüssel A.

    Der Server sendet eine ServerInit-Nachricht mit seinem Zertifikat, der ausgewählten Handshakechiffre, dem Aufzeichnungsprotokoll und einem optionalen verschlüsselten Wiederaufnahmeticket.

  3. Der Server sendet eine ServerFinished-Nachricht mit einer Handshakeauthentifizierung14. Der Wert für diesen Authentifikator wird mithilfe eines hashbasierten Nachrichten-Authentifizierungscodes (Hash-based Message Authentication Code, HMAC) berechnet, der wiederum über eine vordefinierte Bitfolge und den geheimen Authentifikatorschlüssel A berechnet wird.

  4. Sobald der Client ServerInit empfängt, überprüft er das Serverzertifikat, berechnet das DH-Austauschergebnis ähnlich wie der Server und leitet die gleichen geheimen Schlüssel M, R und A ab. Der Client verwendet den abgeleiteten Schlüssel A, um den Authentifikatorwert in der empfangenen ServerFinished-Nachricht zu überprüfen. An diesem Punkt des Handshakevorgangs kann der Client den Schlüssel M zum Verschlüsseln von Nachrichten verwenden. Da der Client nun in der Lage ist, verschlüsselte Nachrichten zu senden, können wir sagen, dass ALTS über ein Protokoll verfügt, das mit nur einem RTT-Handshake arbeitet.

  5. Am Ende des Handshakes sendet der Client eine ClientFinished-Nachricht mit einem ähnlichen Authentifikatorwert (siehe Schritt 3), der über eine andere vordefinierte Bitfolge berechnet wird. Bei Bedarf kann der Client ein verschlüsseltes Wiederaufnahmeticket für zukünftige Sitzungen enthalten. Sobald diese Nachricht vom Server empfangen und verifiziert wurde, ist das ALTS-Handshakeprotokoll abgeschlossen, und der Server kann Schlüssel M dazu verwenden, weitere Nutzlastnachrichten zu verschlüsseln und zu authentifizieren.

Das Handshakeprotokoll wurde von Thai Duong aus dem internen Sicherheitsanalyseteam von Google überprüft und mit dem ProVerif-Tool15 von Bruno Blanchet unter Mithilfe von Martin Abadi formell verifiziert.

Aufzeichnungsprotokoll

Der Abschnitt Handshakeprotokoll beschreibt, wie wir das Handshakeprotokoll dazu verwenden, einen geheimen Schlüssel für das Aufzeichnungsprotokoll auszuhandeln. Dieser geheime Protokollschlüssel dient zur Verschlüsselung und Authentifizierung des Netzwerktraffics. Die Schicht des Stapels, der diese Vorgänge ausführt, wird als ALTS-Aufzeichnungsprotokoll (ALTS Record Protocol, ALTSRP) bezeichnet.

Das ALTS-Aufzeichnungsprotokoll enthält eine Reihe von Verschlüsselungsschemas mit unterschiedlichen Schlüsselgrößen und Sicherheitsfunktionen. Während des Handshakes sendet der Client seine Liste bevorzugter Schemas, sortiert nach Präferenz. Der Server wählt das erste Protokoll in der Clientliste aus, das der lokalen Konfiguration des Servers entspricht. Diese Methode der Schemaauswahl ermöglicht sowohl Clients als auch Servern unterschiedliche Verschlüsselungseinstellungen und ermöglicht es uns, Verschlüsselungsschemas schrittweise zu implementieren (oder zu entfernen).

Framing

Frames sind die kleinsten Dateneinheiten in ALTS. Jede ALTSRP-Nachricht kann, je nach Größe, aus einem oder mehreren Frames bestehen. Jeder Frame enthält die folgenden Felder:

  • Length: Ein vorzeichenloser 32-Bit-Wert, der die Länge des Frames in Byte angibt. Dieses 4-Byte-Längenfeld ist nicht als Teil der gesamten Framelänge enthalten.
  • Type: Ein 32-Bit-Wert, der den Frametyp angibt, z. B. Datenframe.
  • Payload: Die tatsächlich authentifizierten und optional verschlüsselten Nutzlastdaten, die gesendet werden.

Die maximale Länge eines Frames beträgt 1 MB plus 4 Längenbyte. Bei aktuellen RPC-Protokollen begrenzen wir die Framelänge weiter, da kürzere Frames weniger Speicher für die Zwischenspeicherung benötigen. Größere Frames könnten auch von einem potenziellen Angreifer während eines Denial-of-Service-Angriffs (DoS) ausgenutzt werden, um einen Server „auszuhungern“. Neben der Begrenzung der Framelänge beschränken wir auch die Anzahl der Frames, die mit dem gleichen geheimen Aufzeichnungsprotokollschlüssel M verschlüsselt werden können. Das Limit hängt vom Verschlüsselungsschema ab, das zum Ver- und Entschlüsseln der Framenutzlast verwendet wird. Sobald dieses Limit erreicht ist, muss die Verbindung geschlossen werden.

Nutzlast

In ALTS enthält jeder Frame eine Nutzlast, die integritätsgeschützt und optional verschlüsselt ist16. Ab der Veröffentlichung dieses Artikels unterstützt ALTS die folgenden Modi:

  • AES-128-GCM-, AES-128-VCM: AES-GCM- bzw. AES-VCM-Modi mit 128-Bit-Schlüsseln. Diese Modi schützen die Vertraulichkeit und Integrität der Nutzlast mithilfe des GCM- und des VCM-Schemas17.
  • AES-128-GMAC, AES-128-VMAC: Diese Modi unterstützen nur Integritätsschutz mit GMAC und VMAC für die Tagberechnung. Die Nutzlastdaten werden im Klartext mit einem kryptografischen Tag übertragen, das ihre Integrität schützt.

Bei Google verwenden wir je nach Bedrohungsmodell und Leistungsanforderungen unterschiedliche Schutzmechanismen. Wenn sich die kommunizierenden Entitäten innerhalb derselben physischen Grenze befinden, die von Google oder im Auftrag von Google kontrolliert wird, wird nur der Integritätsschutz verwendet. Diese Entitäten können je nach der Vertraulichkeit ihrer Daten immer noch optional auf eine authentifizierte Verschlüsselung aktualisieren. Wenn sich die kommunizierenden Entitäten in unterschiedlichen physischen Grenzen befinden, die von Google oder im Auftrag von Google kontrolliert werden, und die Kommunikation über das Wide Area Network verläuft, wird die Sicherheit der Verbindung automatisch auf authentifizierte Verschlüsselung aktualisiert, unabhängig vom gewählten Modus. Google wendet für Daten, die übertragen werden, verschiedene Schutzmaßnahmen an, wenn die Daten außerhalb einer von Google oder im Auftrag von Google kontrollierten physischen Grenze übertragen werden, da dieselben strengen Sicherheitsmaßnahmen nicht angewendet werden können.

Jeder Frame ist separat integritätsgeschützt und optional verschlüsselt. Beide Peers verwalten sowohl Anfrage- als auch Antwortzähler, die sich während des normalen Betriebs synchronisieren. Wenn der Server Anfragen empfängt, die nicht in der richtigen Reihenfolge sind oder wiederholt auftreten, schlägt die Verifizierung der kryptografischen Integrität fehl und die Anfrage wird abgelehnt. In ähnlicher Weise lässt der Client eine wiederholte oder falsch geordnete Antwort fallen. Da beide Peers die Zähler verwalten (im Gegensatz zu ihren Werten im Frameheader), werden darüber hinaus zusätzliche Byte in der Leitung gespeichert.

Sitzungswiederaufnahme

ALTS ermöglicht es Nutzern, frühere Sitzungen wiederaufzunehmen, ohne umfangreiche asymmetrische kryptografische Vorgänge ausführen zu müssen. Die Sitzungswiederaufnahme ist eine Funktion, die in das ALTS-Handshakeprotokoll integriert ist.

Der ALTS-Handshake ermöglicht Clients und Servern, Wiederaufnahmetickets sicher auszutauschen und im Cache zu speichern. Diese können dann zur künftigen Wiederaufnahme von Verbindungen18 verwendet werden. Jedes zwischengespeicherte Wiederaufnahmeticket wird durch eine Wiederaufnahmekennung (IDR) indexiert, die für alle Arbeitslasten mit derselben Identität und in derselben Rechenzentrumszelle eindeutig ist. Diese Tickets werden unter Verwendung symmetrischer Schlüssel verschlüsselt, die ihren entsprechenden Kennungen zugeordnet sind.

ALTS unterstützt zwei Arten der Sitzungswiederaufnahme:

  1. Serverseitige Sitzungswiederaufnahme: Ein Client erstellt und verschlüsselt ein Wiederaufnahmeticket, das die Serveridentität und den abgeleiteten geheimen Wiederaufnahmeschlüssel R enthält. Das Wiederaufnahmeticket wird am Ende des Handshakes in der ClientFinished-Nachricht an den Server gesendet. In zukünftigen Sitzungen kann der Server die Sitzung wiederaufnehmen, indem er das Ticket in der Nachricht ServerInit an den Client zurücksendet. Bei Empfang des Tickets kann der Client sowohl den geheimen Wiederaufnahmeschlüssel R als auch die Identität des Servers wiederherstellen. Diese Informationen kann er dann zur Wiederaufnahme der Sitzung verwenden.

    Die Wiederaufnahmekennung (IDR) ist immer mit einer Identität und nicht mit bestimmten Verbindungen verknüpft. In ALTS können mehrere Clients dieselbe Identität im selben Rechenzentrum haben. Dadurch können Clients die Sitzungen mit Servern wiederaufnehmen, mit denen sie möglicherweise noch nicht kommuniziert haben, z. B. wenn ein Load-Balancer den Client an einen anderen Server verweist, auf dem dieselbe Anwendung ausgeführt wird.

  2. Clientseitige Sitzungswiederaufnahme: Am Ende eines Handshakes sendet der Server ein verschlüsseltes Wiederaufnahmeticket in der Nachricht ServerFinished an den Client. Dieses Ticket enthält den geheimen Wiederaufnahmeschlüssel R und die Identität des Clients. Der Client kann dieses Ticket zur Wiederaufnahme einer Verbindung mit einem beliebigen Server verwenden, der die gleiche IDR hat.

Bei Wiederaufnahme einer Sitzung wird der geheime Wiederaufnahmeschlüssel R verwendet, um neue geheime Sitzungsschlüssel M', R' und A' abzuleiten. M' wird dazu verwendet, Nutzlastnachrichten zu verschlüsseln und zu authentifizieren. A' wird dazu verwendet, ServerFinished- und ClientFinished-Nachrichten zu authentifizieren. R' ist in einem neuen Wiederaufnahmeticket gekapselt. Beachten Sie, dass der gleiche geheime Wiederaufnahmeschlüssel R nie mehr als einmal verwendet wird.

Vor- und Nachteile

KCI-Angriffe

Im Design ist das ALTS-Handshakeprotokoll anfällig für KCI-Angriffe (Key Compromise Impersonation). Wenn ein Angreifer den privaten DH-Schlüssel oder den Wiederaufnahmeschlüssel einer Arbeitslast manipuliert, kann er mit dem Schlüssel andere Arbeitslasten mit dieser Arbeitslast imitieren19. Dies ist in unserem Wiederaufnahme-Bedrohungsmodell explizit der Fall, da die von der Instanz einer Identität ausgegebenen Wiederaufnahmetickets von anderen Instanzen dieser Identität verwendet werden können.

Es gibt eine Variante des ALTS-Handshakeprotokolls, die vor KCI-Angriffen schützt. Diese wäre allerdings nur in Umgebungen sinnvoll, in denen eine Wiederaufnahme nicht erwünscht ist.

Datenschutz für Handshakenachrichten

ALTS ist nicht dafür ausgelegt, zu verschleiern, welche internen Identitäten kommunizieren. Entsprechend werden Handshakenachrichten nicht verschlüsselt, um die Identitäten der Peers zu verbergen.

Perfect Forward Secrecy

Die Perfect Forward Secrecy (PFS) wird in ALTS standardmäßig unterstützt, aber nicht standardmäßig aktiviert. Wir verwenden stattdessen eine häufige Zertifikatsrotation, um für die meisten Anwendungen eine Forward Secrecy einzurichten. Mit TLS 1.2 (und früheren Versionen) ist die Sitzungswiederaufnahme nicht durch PFS geschützt. Wenn PFS zusammen mit ALTS aktiviert wird, ist PFS auch für wiederaufgenommene Sitzungen aktiviert.

Zero-Round-Trip-Verfahren zur Wiederaufnahme

TLS 1.3 bietet Sitzungswiederaufnahmen, die das Zero-Round-Trip-Verfahren (0-RTT) erfordern. Dieses Verfahren bietet jedoch weniger Sicherheit20. Wir haben uns daher entschieden, keine 0-RTT-Option in ALTS zu verwenden, da RPC-Verbindungen bei Google in der Regel langlebig sind. Folglich wäre die Verringerung der Kanaleinstellungslatenz kein guter Kompromiss für die zusätzliche Komplexität und/oder reduzierte Sicherheit, die 0-RTT-Handshakes erfordern.

Weitere Referenzen

Fußnoten

1Ein Mikrodienst ist ein Architekturstil, der eine Anwendung als eine Sammlung von lose gekoppelten Diensten organisiert, die Geschäftsfunktionen implementieren.
2Eine Produktionsarbeitslast ist eine Anwendung, die Google-Entwickler für die Ausführung in den Rechenzentren von Google planen.
3Weitere Informationen dazu, wie Google Daten bei der Übertragung schützt, finden Sie in unserem Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.
4Ein Vertrauensmodell ist das Verfahren, bei dem Anmeldedaten und Identitäten von einem Sicherheitsprotokoll identifiziert, verteilt und rotiert werden.
5Einige Dienste werden direkt von Entwicklern verwaltet.
6Der Borgmaster ist für die Planung und Initialisierung von Google-Produktionsarbeitslasten verantwortlich. Weitere Informationen finden Sie unter Large-scale cluster management at Google with Borg.
7Weitere Informationen zur Häufigkeit von Zertifikatsrotationen finden Sie unter Verschlüsselung bei der Übertragung in Google Cloud.
8Wenn ein Schlüssel manipuliert ist, kann von einem Angreifer nur der Traffic für die Lebensdauer dieses Schlüsselpaars ermittelt werden.
11ALTSd: Ein Daemon, der neben anderen ALTS-Vorgängen auch für die Erstellung von Handshakezertifikaten zuständig ist.
12In der Praxis hat die Zertifizierungsstelle Zugriff auf die privaten Schlüssel des Signaturdienstes, wodurch die beiden logischen Entitäten zu einer einzigen physischen Entität werden.
13Insbesondere HKDF-Extract und HKDF-Expand, wie in RFC-5869 definiert.
14Die Implementierung des ALTS-Handshakeprotokolls verkettet ServerInit- und ServerFinished-Nachrichten zu einer Einzelleitungsnutzlast.
16Die Nutzlastverschlüsselung wird als Teil des Aufzeichnungsprotokolls im Handshake ausgehandelt.
17Das 128-Bit-AES-GCM-Schema basiert auf NIST 800-38D und AES-VCM wird ausführlich unter AES-VCM, An AES-GCM Construction Using an Integer-Based Universal Hash Function erläutert.
18Die Wiederaufnahme von Sitzungen beinhaltet einfache symmetrische Vorgänge nur dann, wenn keine sitzungsspezifischen Parameter beteiligt sind.