Heute haben wir den Geo Key Manager vorgestellt: Eine Funktion, die Kunden eine noch nie dagewesene Kontrolle darüber gibt, wo ihre privaten Schlüssel gespeichert werden, wenn sie zu Cloudflare hochgeladen werden. Diese Funktion baut auf einer früheren Cloudflare-Innovation namens Keyless SSL und einem neuartigen kryptografischen Zugriffskontrollmechanismus auf, der sowohl auf identitätsbasierter Verschlüsselung als auch auf Broadcast-Verschlüsselung basiert. In diesem Beitrag erklären wir die technischen Details dieser Funktion, welche die erste ihrer Art in der Branche ist. Wir beschreiben ferner, wie Cloudflare sein bestehendes Netzwerk und seine Technologien genutzt hat, um sie zu entwickeln.
Schlüssel in unterschiedlichen Gebieten
Cloudflare hat Keyless SSL vor drei Jahren eingeführt und damit großen Erfolg gehabt. Mit Keyless SSL können Kunden die Vorteile des Cloudflare-Netzwerks in vollem Umfang nutzen und gleichzeitig ihre privaten HTTPS-Schlüssel in ihrer eigenen Infrastruktur aufbewahren. Keyless SSL ist vor allem bei Kunden in solchen Branchen sehr beliebt, in denen es Vorschriften zur Kontrolle des Zugangs zu privaten Schlüsseln gibt, wie z. B. der Finanzbranche. Außerhalb dieser regulierten Branchen hat sich Keyless SSL langsamer durchgesetzt, zum Teil, weil die Kunden dafür eigene Software (den Schlüsselserver) innerhalb ihrer Infrastruktur betreiben müssen.
Standardkonfiguration
Keyless SSL
Einer der motivierenden Anwendungsfälle für Keyless SSL war die Erwartung, dass Kunden einem Dritten wie Cloudflare ihre privaten Schlüssel nicht anvertrauen könnten. Wir haben festgestellt, dass dies sehr selten vorkommt; die meisten Kunden vertrauen Cloudflare ihre privaten Schlüssel an. Wir haben jedoch festgestellt, dass Kunden manchmal eine Möglichkeit wünschen, mit der sie das Risiko, das mit der Aufbewahrung ihrer Schlüssel an verschiedenen Orten in der Welt verbunden ist, verringern können.
Genau hier kann sich der Geo Key Manager als besonders wertvoll erweisen: Er ermöglicht den Kunden, die Offenlegung ihrer privaten Schlüssel auf bestimmte Standorte zu beschränken. Die Funktion ähnelt Keyless SSL, aber die Kunden müssen keinen Schlüsselserver innerhalb ihrer eigenen Infrastruktur betreiben. Stattdessen hostet Cloudflare diese Server an den Orten ihrer Wahl. Dadurch wird die Implementierung von Keyless SSL weniger komplex. Gleichzeitig bietet es Nutzern die Kontrolle, auf die sie Wert legen. Der Geo Key Manager funktioniert einfach, ohne dass Software erforderlich ist.
Kurze Auffrischung: Die Hintergründe von Keyless SSL
Keyless SSL wurde bei Cloudflare entwickelt, um HTTPS sicherer zu machen. Inhalte, die über HTTPS bereitgestellt werden, sind sowohl verschlüsselt als auch authentifiziert. Somit können sie von Datenspionen oder Angreifern nicht gelesen oder verändert werden. HTTPS verwendet ein Protokoll namens Transport Layer Security (TLS), damit diese Daten geschützt bleiben.
TLS besteht aus zwei Phasen: einer Handshake-Phase und einer Datenaustauschphase (Data Exchange Phase). In der Handshake-Phase werden die kryptographischen Schlüssel ausgetauscht und ein gemeinsames Geheimnis festgelegt. Im Rahmen dieses Austauschs weist der Server seine Identität gegenüber dem Client mit einem Zertifikat und einem privaten Schlüssel nach. In der Datenaustauschphase werden gemeinsame Schlüssel aus dem Handshake zur Verschlüsselung und Authentifizierung der Daten verwendet.
Ein TLS-Handshake kann natürlich in zwei Komponenten unterteilt werden:
Die Verarbeitung des privaten Schlüssels
Alles andere
Die Verarbeitung des privaten Schlüssels ist für den TLS-Handshake von entscheidender Bedeutung: Sie ermöglicht es dem Server zu beweisen, dass er ein bestimmtes Zertifikat besitzt. Ohne dieses Verfahren kann der Client nicht wissen, ob der Server authentisch ist oder nicht. Bei Keyless SSL wird die Verarbeitung des privaten Schlüssels vom Rest des Handshakes getrennt. Bei einem Keyless SSL-Handshake führt der Server die Verarbeitung des privaten Schlüssels nicht lokal durch, sondern ruft über einen Remote-Vorgang einen anderen Server (den so genannten Schlüsselserver) auf, der den privaten Schlüssel kontrolliert.
Mit Keyless SSL können Sie die Bedenken logisch trennen, so dass eine Kompromittierung des Webservers nicht zu einer Kompromittierung des privaten Schlüssels führt. Diese zusätzliche Sicherheit hat ihren Preis. Der per Remote-Vorgang durchgeführte Aufruf vom Server zum Schlüsselserver kann die Latenzzeit des Handshakes erhöhen und den Verbindungsaufbau verlangsamen. Die zusätzlichen Latenzkosten entsprechen der Umlaufzeit vom Server zum Schlüsselserver, die bis zu einer Sekunde betragen kann, wenn sich der Schlüsselserver auf der anderen Seite der Welt befindet.
Glücklicherweise gelten diese Latenzkosten nur für das erste Mal, wenn Sie eine Verbindung zu einem Server herstellen. Sobald der Handshake abgeschlossen ist, ist der Schlüsselserver nicht mehr beteiligt. Wenn Sie sich erneut mit einem Standort verbinden, müssen Sie die Latenzkosten auch nicht bezahlen, da für die Wiederaufnahme einer Verbindung mit Fortsetzung der TLS-Session der private Schlüssel nicht erforderlich ist.
Latenzzeit entsteht nur für die erste Verbindung.
Wenn Sie sich eingehender mit diesem Thema befassen möchten, lesen Sie diesen Beitrag, den ich 2014 geschrieben habe.
Mit Keyless SSL als Grundbaustein haben wir uns daran gemacht, den Geo Key Manager zu entwickeln.
Geo Key Manager: Gestaltung der Architektur
Cloudflare verfügt über einen im wahrsten Sinne des Wortes internationalen Kundenstamm. Wir haben die Erfahrung gemacht, dass Kunden je nach Weltregion andere regulatorische und gesetzliche Vorgaben erfüllen müssen und unterschiedliche Risikoprofile bezüglich der Platzierung ihrer privaten Schlüssel aufweisen. Es gibt keine Lösung, die für alle Länder der Welt passt. In diesem Bewusstsein haben wir ein sehr flexibles System entwickelt, mit dem Kunden entscheiden können, wo Schlüssel aufbewahrt werden.
Als erstes Problem galt es, die Zugangskontrolle zu lösen. Wie können wir die Anzahl der Standorte begrenzen, an die ein privater Schlüssel gesendet wird? Cloudflare verfügt über eine Datenbank, die die Benutzereinstellungen aufnimmt und sie an alle Edge-Standorte sicher und sehr schnell verteilt. Dieses System ist jedoch dafür optimiert, eine gesamte Datenbank weltweit zu synchronisieren; es zu modifizieren, um Schlüssel selektiv an verschiedene Standorte zu verteilen, stellte für Cloudflare eine zu große architektonische Veränderung dar. Stattdessen beschlossen wir, die Idee eines kryptografischen Zugangskontrollsystems (Cryptographic Access Control – CAC) zu untersuchen.
In einem CAC-System werden die Daten verschlüsselt und überall verteilt. Der Zugriff auf Daten ist nur möglich, wenn Sie den Entschlüsselungsschlüssel besitzen. Indem wir die Entschlüsselungsschlüssel nur an bestimmte Standorte senden, können wir den Zugriff auf die Daten wirksam einschränken. Wir könnten zum Beispiel die privaten Schlüssel der Kunden einmal verschlüsseln – direkt nach dem Hochladen – und die Verschlüsselungsschlüssel über das bestehende System zur Datenbankreplikation an jeden Standort senden.
Wir hatten schon früher mit CAC-Systemen experimentiert, vor allem mit dem Projekt Red October. Mit Red October können Sie einen Teil der Daten so verschlüsseln, dass mehrere Personen zur Entschlüsselung erforderlich sind. So funktioniert auch PAL, unsere Docker Secrets-Lösung. Das Red-October-System ist jedoch aus einer Reihe von Gründen schlecht für Geo Key Manager geeignet:
Je mehr Orte Sie verschlüsseln, desto größer wird der Verschlüsselungsschlüssel
Es gibt keine Möglichkeit, einen Schlüssel „überall außer an einem bestimmten Ort“ zu verschlüsseln, ohne ihn neu zu verschlüsseln, wenn neue Orte hinzukommen (was wir häufig machen)
Es muss ein sicheres Register für die öffentlichen Schlüssel der einzelnen Rechenzentren geben.
Der Geo Key Manager sollte so gestaltet werden, dass er seinen Nutzern eine präzise Kontrolle bietet und mit dem wachsenden Netzwerk von Cloudflare skaliert werden kann. Wir haben die folgenden Anforderungen formuliert:
Benutzer können aus einer Reihe von vordefinierten Regionen auswählen, in denen sie ihre Schlüssel haben möchten (EU, USA, höchste Sicherheitsstufe usw.)Benutzer können bestimmte Standorte von Rechenzentren außerhalb der ausgewählten Regionen hinzufügen (z. B. alle US-Standorte plus Toronto)
Die Nutzer können ausgewählte Rechenzentren in den von ihnen gewählten Regionen auswählen, die keine Schlüssel versenden dürfen (z. B. alle Standorte in der EU außer Paris)
Ein Schlüssel sollte schnell entschlüsselt und einfach gespeichert werden können, unabhängig davon, wie kompliziert die Konfiguration ist
Der Aufbau eines Systems, das diese Anforderungen erfüllt, gibt den Kunden die Freiheit zu entscheiden, wo ihre Schlüssel aufbewahrt werden. Gleichzeitig bietet es die nötige Skalierbarkeit, um auch in einem wachsenden Netzwerk nützlich zu sein.
Identitätsbasierte Verschlüsselung
Das kryptografische Werkzeug, mit dem wir diese Anforderungen erfüllen können, heißt identitätsbasierte Verschlüsselung.
Im Gegensatz zur traditionellen Public-Key-Kryptographie, bei der jede Partei einen öffentlichen und einen privaten Schlüssel hat, ist bei der identitätsbasierten Verschlüsselung Ihre Identität ihr öffentlicher Schlüssel. Dies ist ein sehr wichtiges Konzept, da es Ihnen ermöglicht, Daten an eine Person zu verschlüsseln, ohne dass Sie vorher den öffentlichen Schlüssel dieser Person erhalten müssen. Anstelle einer großen, zufällig aussehenden Zahl kann ein öffentlicher Schlüssel buchstäblich eine beliebige Zeichenfolge sein, z. B. Dies ist ein sehr wichtiges Konzept, da es Ihnen ermöglicht, Daten an eine Person zu verschlüsseln, ohne dass Sie vorher den öffentlichen Schlüssel dieser Person erhalten müssen. Anstelle einer großen, zufällig aussehenden Zahl kann ein öffentlicher Schlüssel buchstäblich eine beliebige Zeichenfolge sein, z. B. „[email protected]“ oder „beebob“. Die identitätsbasierte Verschlüsselung ist nützlich für E-Mails, wo man sich vorstellen kann, eine Nachricht mit der E-Mail-Adresse einer Person als öffentlichem Schlüssel zu verschlüsseln. Vergleichen Sie dies mit der Komplexität der Verwendung von PGP, wo Sie den öffentlichen Schlüssel einer Person finden und überprüfen müssen, bevor Sie eine Nachricht senden. Bei der identitätsbasierten Verschlüsselung können Sie sogar Daten an jemanden verschlüsseln, bevor dieser den mit seiner Identität verbundenen privaten Schlüssel besitzt (der von einer zentralen Schlüsselgenerierungsstelle verwaltet wird).
Public Key-Kryptographie (PGP, etc.)
Identitätsbasierte Verschlüsselung
Die identitätsbasierte Verschlüsselung wurde von Shamir in den 80er Jahren vorgeschlagen, war aber erst mit dem Vorschlag von Boneh and Franklin im Jahr 2001 voll einsatzfähig. Seitdem wurde eine Vielzahl interessanter Verfahren entdeckt und angewandt. Das zugrundeliegende kryptografische Verfahren, das eine effiziente identitätsbasierte Verschlüsselung ermöglicht, heißt Elliptic Curve Pairings, ein Thema, das einen eigenen Blogbeitrag verdient.
Unser System basiert auf der Kombination von zwei Primitiven:
Identity-Based Broadcast Encryption (IBBE)
Identity-Based Revocation (IBR)
Identity-Based Broadcast Encryption (IBBE) ist wie eine Positivliste. Sie ermöglicht es, ein Stück Daten zu nehmen und es an eine Gruppe von Empfängern zu verschlüsseln. Die spezifische Konstruktion, die wir verwenden, stammt aus einem Artikel von Delerablee aus dem Jahr 2007. Entscheidend ist, dass die Größe des Chiffretextes nicht von der Anzahl der Empfänger abhängt. Das bedeutet, dass wir Daten effizient verschlüsseln können, ohne dass sie größer werden, egal wie viele Empfänger es gibt (oder in unserem Fall PoPs).
Identity-based Revocation (IBR) ist wie eine Blockierliste. Sie ermöglicht es, Daten so zu verschlüsseln, dass sie von allen Empfängern entschlüsselt werden können, mit Ausnahme einer vordefinierten Gruppe von Empfängern, die ausgeschlossen sind. Die von uns verwendete Implementierung stammt aus Abschnitt 4 eines Artikels von Attrapadung et al. aus dem Jahr 2011. Auch hier hängt die Größe des Cipher-Textes nicht von der Anzahl der ausgeschlossenen Identitäten ab.
Diese beiden Primitive können kombiniert werden, um ein sehr flexibles kryptografisches Zugangskontrollsystem zu schaffen. Erstellen Sie dazu zwei Gruppen von Identitäten: eine Identität für jede Region und eine Identität für jeden Standort des Rechenzentrums. Sobald diese Gruppen festgelegt sind, erhält jeder Server den identitätsbasierten privaten Verschlüsselungsschlüssel für seine Region und seinen Standort.
Auf diese Weise können Sie den Zugriff auf den Schlüssel in Bezug auf die folgenden Gruppen konfigurieren:
Gruppe von Regionen, an die verschlüsselt werden soll
Gruppe von Standorten innerhalb der Region, die ausgenommen werden sollen
Gruppe von Standorten außerhalb der Region, darunter
So können Sie einen Kundenschlüssel verschlüsseln, damit eine bestimmte Zugangskontrollrichtlinie (Regionen, Blockierliste, Positivliste) durchgesetzt werden kann:
Erstellen eines Verschlüsselungsschlüssels (Key Encryption Key– KEK)
Teilen in zwei Hälften KEK1, KEK2
KEK1 mit IBBE verschlüsseln, um die Gruppe der Regionen (Positivliste Regionen) einzuschließen
KEK2 mit IBR verschlüsseln, um Orte in den unter 3 definierten Regionen auszuschließen (Blockierliste Colo)
KEK mit IBBE verschlüsseln, um Standorte einzubeziehen, die nicht in den in 3 definierten Regionen liegen (Positivliste Colo)
Senden aller drei Verschlüsselungsschlüssel (KEK1)region, (KEK2)exclude, (KEK)include an alle Standorte
Dies kann wie folgt veranschaulicht werden mit
Regionen: USA und EU
Blockierliste Colos: Dallas und Paris
Positivliste Colos: Sydney und Tokio
Die Standorte innerhalb der Liste der zulässigen Regionen können die Hälfte des Schlüssels (KEK1) entschlüsseln, und müssen ebenfalls außerhalb der Blockierliste liegen, um die andere Hälfte des Schlüssels (KEK2) zu entschlüsseln. In diesem Beispiel haben Paris und Dallas nur Zugriff auf KEK1, da sie KEK2 nicht entschlüsseln können. Diese Standorte können den KEK nicht rekonstruieren und daher den privaten Schlüssel nicht entschlüsseln. Jeder andere Standort in der EU und den USA kann KEK1 und KEK2 entschlüsseln, so dass sie KEK zur Entschlüsselung des privaten Schlüssels konstruieren können. Tokio und Sydney können den KEK aus der Zertifikatsliste entschlüsseln und zur Entschlüsselung des privaten Schlüssels verwenden.
Damit wird der private TLS-Schlüssel in der gesamten EU und den USA mit Ausnahme von Dallas und Paris sowie in Tokio und Sydney verfügbar sein. Das Ergebnis ist die folgende Karte:
Dank dieses Konzepts können die Kunden für jedes einzelne Rechenzentrum entscheiden, wo sie auf ihre privaten Schlüssel zugreifen können. Wenn jemand eine Verbindung zu einem Rechenzentrum herstellt, das den privaten Schlüssel nicht entschlüsseln kann, wird diese SSL-Verbindung über Keyless SSL abgewickelt, wobei sich der Schlüsselserver an einem Ort befindet, der Zugriff auf den Schlüssel hat. Der Geo Key Code findet automatisch das nächstgelegene Rechenzentrum, das auf den entsprechenden privaten TLS-Schlüssel zugreifen kann, und verwendet Keyless SSL, um den TLS-Handshake mit dem Client abzuwickeln.
Erstellen eines Schlüsselserver-Netzwerks
Jedes Mal, wenn Sie Keyless SSL für eine neue Verbindung verwenden, entstehen Latenzkosten für die Verbindung zum Schlüsselserver. Mit Geo Key Manager wollten wir diese Latenzkosten so weit wie möglich reduzieren. In der Praxis bedeutet dies, dass wir wissen müssen, welcher Schlüsselserver am schnellsten antwortet.
Um dieses Problem zu lösen, haben wir ein Overlay-Netzwerk zwischen allen unseren Rechenzentren eingerichtet, um die Latenz zu messen. Jedes Rechenzentrum hat eine abgehende Verbindung zu jedem anderen Rechenzentrum. Alle paar Sekunden senden wir einen „Ping“ (eine Nachricht im Keyless SSL-Protokoll, keine ICMP-Nachricht) und messen, wie lange der Server braucht, um einen entsprechenden „Pong“ zu senden.
Wenn sich ein Client mit einer Website hinter Cloudflare in einem Rechenzentrum verbindet, das den privaten Schlüssel für diese Website nicht entschlüsseln kann, verwenden wir Metadaten, um herauszufinden, welche Rechenzentren Zugriff auf den Schlüssel haben. Wir wählen dann das Rechenzentrum aus, das nach unseren Messungen die geringste Latenz aufweist, und verwenden den Schlüsselserver dieses Rechenzentrums für Keyless SSL. Wenn der Standort mit der niedrigsten Latenzzeit überlastet ist, können wir einen anderen Standort mit höherer Latenzzeit, aber mehr Kapazität wählen.
Anhand der Daten dieser Messungen wurde die folgende Karte erstellt, die die zusätzlichen Latenzzeiten für Besucher aus aller Welt bei der ausschließlich auf die USA beschränkten Konfiguration aufzeigt.
Zusätzlich entstehende Latenzzeit, wenn die Schlüssel nur in den USA liegen dürfen. Grün: keine Latenzkosten,
Gelb: < 50 ms,
Rot: > 100 ms
Fazit
Wir arbeiten ständig an Innovationen, um unseren Kunden leistungsstarke Funktionen zu bieten, die einfach zu bedienen sind. Mit Geo Key Manager nutzen wir Keyless SSL und die Kryptographie des 21. Jahrhunderts, um die Sicherheit privater Schlüssel in einem zunehmend komplizierten geopolitischen Umfeld zu verbessern.