Einblick in den Geo Key Manager v2: Neukonzeption der Zugriffskontrolle für dezentrale Systeme

Im Dezember 2022 haben wir das Closed Beta der neuen Version des Geo Key Managers angekündigt. Der Geo Key Manager v2 (GeoV2) ist der nächste Schritt in unserem Bemühen, unseren Kunden eine sichere und flexible Kontrolle der Verteilung ihrer privaten Schlüssel nach geografischem Standort zu bieten. Unser ursprüngliches System, der Geo Key Manager v1, begann 2017 als Forschungsprojekt. Doch mit Weiterentwicklung der Kundenbedürfnisse und unserem eigenen Wachstum erkannten wir, dass wir zur Bereitstellung einer besseren Nutzererfahrung erhebliche Verbesserungen vornehmen mussten.

Zu den größten Herausforderungen, mit denen wir beim Geo Key Manager v1 (GeoV1) konfrontiert waren, gehörte die Starrheit unserer Zugriffskontrollrichtlinien. Die Kunden forderten eine umfassendere Datenlokalisierung, was oft durch gesetzliche Bestimmungen gefördert wurde. Intern verstärkten Ereignisse wie der Konflikt in der Ukraine die Notwendigkeit, den Zugriff auf sensibles Schlüsselmaterial schnell einschränken zu können. Die zugrundeliegende Kryptografie des Geo Key Managers v1 war eine Kombination aus identitätsbasierter Broadcast-Verschlüsselung und identitätsbasiertem Widerruf, die eine Teilmenge der von der attributbasierten Verschlüsselung (Attribute-Based Encryption – ABE) angebotenen Funktionen simulierte. Die Ersetzung durch ein etabliertes ABE-Schema behebt die Inflexibilität unserer Zugriffskontrollrichtlinien und bietet eine sicherere Grundlage für unser System.

Während unser vorheriges Schema die künftige Flexibilität durch das Einfrieren der Menge der teilnehmenden Rechenzentren und Richtlinien eingeschränkt hatte, lässt sich das System nun durch die Verwendung von ABE leicht an künftige Anforderungen anpassen. So konnten wir von Performance-Steigerungen profitieren, die sich aus zusätzlichen, nach der Instanziierung hinzugefügten Rechenzentren ergaben, und das Verfahren zur Bearbeitung von Änderungen an Attributen und Richtlinien erheblich vereinfachen. Darüber hinaus hatten den GeoV1 einige verwirrende Performance-Probleme geplagt, die eine hohe Latenz und einen mühsamen manuellen Schlüsselrotationsprozess mit sich brachten. Der GeoV2 ist unsere Antwort auf diese Herausforderungen und Einschränkungen des GeoV1.

Dieser Blogbeitrag konzentriert sich zwar auf unsere Lösung für die geografische Schlüsselverwaltung, aber die hier gewonnenen Erkenntnisse lassen sich auch auf andere Anforderungen an die Zugriffskontrolle anwenden. Lösungen für die Zugriffskontrolle werden traditionell mit einer hochverfügbaren zentralen Autorität implementiert, um den Zugriff auf Ressourcen zu kontrollieren. Wie wir sehen werden, lässt sich dieser Single Point of Failure mit ABE vermeiden. Da uns keine groß angelegten ABE-basierten Zugriffskontrollsysteme bekannt sind, hoffen wir, dass unsere Diskussion Ingenieuren dabei helfen kann, die Verwendung von ABE als Alternative zur Zugriffskontrolle mit minimaler Abhängigkeit von einer zentralen Autorität in Betracht zu ziehen. Um dies zu erleichtern, haben wir unsere ABE-Implementierung in unsere Open Source-Kryptobibliothek CIRCL aufgenommen.

Bevor wir auf den GeoV2 zurückkommen, wollen wir einen kleinen Umweg einschlagen und uns das Problem näher anschauen, das es zu lösen gilt.

Nehmen wir folgendes Beispiel: Ein großes europäisches Geldinstitut möchte seine privaten TLS-Schlüssel nur innerhalb der Europäischen Union speichern. Die Bank ist Kundin von Cloudflare, weshalb wir TLS-Handshakes für sie durchführen. Unter anderem, um den besten Schutz vor DDoS-Angriffen bieten, die Performance durch Caching verbessern und Web Application Firewalls unterstützen zu können, müssen wir TLS-Verbindungen für die Bank beenden.

Um dies zu tun, benötigen wir Zugriff auf ihre privaten TLS-Schlüssel1. Die Steuerungsebene, über die der API-Traffic abgewickelt wird, verschlüsselt den hochgeladenen privaten Schlüssel des Kunden mit einem öffentlichen Master-Schlüssel, der von allen Rechnern weltweit gemeinsam genutzt wird. Anschließend wird der Schlüssel in einer weltweit verteilten Schlüssel-Werte-Datenbank, Quicksilver, abgelegt. Somit verfügt jeder Rechner in jedem Rechenzentrum der Welt über eine lokale Kopie des privaten TLS-Schlüssels des Kunden.

Der Kunde lädt sein TLS-Zertifikat und seinen privaten Schlüssel hoch, damit beide in allen Rechenzentren gespeichert werden

In unserem Beispiel möchte die Bank jedoch, dass ihr Schlüssel nur in Rechenzentren innerhalb der Europäischen Union gespeichert wird. Um dies zu ermöglichen, haben wir drei Möglichkeiten.

Die erste Option besteht darin, sicherzustellen, dass nur Rechenzentren in der EU diesen Schlüssel erhalten und den Handshake beenden können. Alle anderen Rechner leiten TLS-Anfragen zur Verarbeitung an einen Server in der EU weiter. Dies würde voraussetzen, dass jeder Rechner nur einen Teil des gesamten in Quicksilver gespeicherten Schlüsselsatzes erhält. Das stellt zentrale Designentscheidungen in Frage, die Cloudflare im Lauf der Jahre getroffen hat und die davon ausgehen, dass der gesamte Datensatz auf jedem Rechner repliziert wird.

Beschränkung der Kundenschlüssel auf Rechenzentren in der EU

Eine weitere Option besteht darin, die Speicherung nicht in Quicksilver, sondern im zentralen Rechenzentrum abzulegen. So könnten wir jedes Mal die richtige Zugriffskontrollrichtlinie durchsetzen und sicherstellen, dass nur bestimmte Rechner auf bestimmte Schlüssel zugreifen können. Dies würde jedoch dem Zweck eines globalen Netzwerks von vornherein zuwiderlaufen: die Verringerung der Latenz und die Vermeidung eines Single Point of Failure im Zentrum.

Speicherung von Schlüsseln im zentralen Rechenzentrum, wo eine komplizierte Anwendungslogik zur Durchsetzung von Richtlinien angewandt wird

Eine dritte Option ist die Verwendung der Public-Key-Verschlüsselung. Statt eines Master-Schlüsselpaars erhält jedes Rechenzentrum sein eigenes Schlüsselpaar. Im Hauptrechenzentrum wird der private Schlüssel des Kunden mit den Schlüsseln aller Rechenzentren, die ihn nutzen dürfen, verschlüsselt. In diesem Beispiel können nur Rechner in der EU auf den Schlüssel zugreifen. Nehmen wir an, es gibt 500 Rechenzentren mit jeweils 50 Rechnern. Von diesen 500 Rechenzentren befinden sich 200 in der EU. Während 100 Schlüssel mit 1 kB insgesamt 100 x 500 x 50 x 1 kB (weltweit) verbrauchten, werden sie jetzt das 200-fache und im schlimmsten Fall bis zu 500-fache verbrauchen. Dadurch erhöht sich der Speicherplatz, der für die Schlüssel auf jedem Rechner benötigt wird, um einen ganz neuen Faktor – vorher war der Speicherplatz lediglich eine Funktion der Anzahl der registrierten Kundenschlüssel; jetzt ist er zwar immer noch eine Funktion der Anzahl der Kundenschlüssel, aber zusätzlich multipliziert mit der Anzahl der Rechenzentren.

Zuweisung eindeutiger Schlüssel an jedes Rechenzentrum und Ummantelung von Kundenschlüsseln mit EU-Rechenzentrumsschlüsseln

Leider sind alle drei Optionen aus jeweils anderen Gründen nicht erstrebenswert. Sie würden entweder eine Änderung der grundlegenden Annahmen erfordern, die wir hinsichtlich der Architektur von Cloudflare getroffen haben, die Aufgabe der Vorteile der Verwendung eines hochgradig dezentralen Netzwerks oder eine quadratische Erhöhung des von dieser Funktion verwendeten Speichers bedeuten.

Bei näherer Betrachtung der dritten Option stellt sich die Frage, warum nicht zwei Schlüsselpaare anstelle eines einzigen für jedes Rechenzentrum erstellt werden. Ein Paar würde für alle EU-Rechenzentren gelten und eines für alle Nicht-EU-Rechenzentren. Auf diese Weise muss das zentrale Hauptrechenzentrum den Schlüssel des Kunden nicht für jedes EU-Rechenzentrum einzeln, sondern insgeamt nur zweimal verschlüsseln. Dies ist eine gute Lösung für die Bank in der EU. Doch sie lässt sich nicht skalieren, wenn wir anfangen, weitere Richtlinien hinzuzufügen. Nehmen wir ein Beispiel: Ein Rechenzentrum in New York City könnte über einen Schlüssel für die Richtlinie „country: US“, einen anderen für „country: US or region: EU“, einen weiteren für „not country: RU“ und so weiter … verfügen. Das wird recht unübersichtlich. Und jedes Mal, wenn ein neues Rechenzentrum bereitgestellt wird, müssen alle Richtlinien auf den Prüfstand gestellt und die entsprechenden Schlüssel zugewiesen werden.

Ein Schlüssel für jede Richtlinie und ihre Negation

Die Erfindung von RSA im Jahr 1978 leitete die Ära der modernen Public-Key-Verschlüsselung ein. Doch jeder, der schon GPG verwendet oder mit Zertifizierungsstellen zu tun gehabt hat, kennt die Schwierigkeiten bei der Verwaltung einer Public-Key-Infrastruktur, die Schlüssel mit Nutzeridentitäten verbindet. 1984 stellte Shamir die Frage, ob es möglich ist, ein Verschlüsselungssystem mit öffentlichem Schlüssel zu schaffen, bei dem dieser Public Key eine beliebige Zeichenfolge sein kann. Seine Motivation für diese Frage war die Vereinfachung der E-Mail-Verwaltung. Anstatt eine E-Mail an Olaf mit Olafs öffentlichem Schlüssel zu verschlüsseln, könnte Anna sie mit Olafs Identität [email protected] verschlüsseln. Im Jahr 2001 fanden Boneh und Franklin schließlich heraus, wie das funktionieren kann.

Die Broadcast-Verschlüsselung wurde erstmals 1993 von Fiat und Naor vorgeschlagen. Sie ermöglicht es, die gleiche verschlüsselte Nachricht an alle zu senden, die aber nur von Personen mit dem richtigen Schlüssel entschlüsselt werden kann. Um auf unsere dritte Option zurückzukommen: Anstatt den Schlüssel des Kunden mit dem Schlüssel jedes EU-Rechenzentrums zu verschlüsseln, könnten wir die Broadcast-Verschlüsselung verwenden, um eine einzigartige Verschlüsselung des Kundenschlüssels zu erstellen, die nur von EU-Rechenzentren entschlüsselt werden kann. Damit würde das Speicherproblem gelöst.

Der Geo Key Manager v1 verwendete eine Kombination aus identitätsbasierter Broadcast-Verschlüsselung und identitätsbasiertem Widerruf zur Implementierung der Zugriffskontrolle. Kurz gesagt wird für jede Region und jeden Rechenzentrumsstandort ein Satz von Identitäten festgelegt. Dann wird jedem Rechner ein identitätsbasierter privater Schlüssel für seine Region und seinen Standort zugewiesen. Auf diese Weise kann der Zugriff auf den Schlüssel des Kunden über drei Gruppen gesteuert werden: die Gruppe der Regionen, die verschlüsselt werden sollen, die Gruppe der Standorte innerhalb der Region, die ausgeschlossen werden sollen, und die Gruppe der Standorte außerhalb der Region, die einbezogen werden sollen. Der Schlüssel des Kunden könnte nach diesem Prinzip beispielsweise so verschlüsselt werden, dass er in allen Regionen mit Ausnahme einiger weniger spezifischer Standorte verfügbar ist, und auch an einigen Standorten außerhalb dieser Regionen. In diesem Blogbeitrag beschäftigen wir uns ausführlich mit diesem Ansatz.

Leider ging dieses Schema nicht ausreichend auf die Bedürfnisse der Kunden ein. Die beim ersten kryptografischen Setup verwendeten Parameter, z. B. die Liste der Regionen, Rechenzentren und deren Attribute, waren fest im System verankert und konnten nicht ohne Weiteres geändert werden. Wer etwa nach dem Brexit das Vereinigte Königreich aus der EU-Region ausschließen oder eine neue Region auf Grundlage eines neuen Compliance-Standards unterstützten möchte, den die Kunden benötigen, hat dann einfach Pech gehabt. Die Verwendung einer vorgegebenen statischen Standortliste erschwerte auch den schnellen Widerruf des Rechnerzugangs. Darüber hinaus konnten Entschlüsselungsschlüssel nicht an neue Rechenzentren zugewiesen werden, die nach dem Setup eingerichtet wurden, was eine Beschleunigung der Anfragen verhinderte. Diese Einschränkungen gaben den Anstoß für die Integration der attributbasierten Verschlüsselung (Attribute-Based Encryption – ABE) im Geo Key Manager.

Im Jahr 2004 schlugen Amit Sahai und Brent Waters ein neues Kryptosystem vor, das auf Zugriffsrichtlinien beruht und als attributbasierte Verschlüsselung (Attribute-Based Encryption – ABE) bekannt ist. Im Wesentlichen wird eine Nachricht mit einer Zugriffsrichtlinie und nicht mit einer Identität verschlüsselt. Die Nutzer erhalten einen privaten Schlüssel, der auf ihren Attributen basiert, und können die Nachricht nur dann entschlüsseln, wenn ihre Attribute den Richtlinien entsprechen. Dies ermöglicht eine flexiblere und detailliertere Zugriffskontrolle als herkömmliche Verschlüsselungsmethoden.

Kurze Geschichte der Public-Key-Verschlüsselung

Die Richtlinie kann entweder an den Schlüssel oder an den Chiffretext gebunden werden, was zu zwei Varianten von ABE führt: die auf Schlüsselrichtlinien und Attributen basierende Verschlüsselung (Key-Policy Attribute-Based Encryption – KP-ABE) und die auf Chiffretextrichtlinien und Attributen basierende Verschlüsselung (Ciphertext-Policy Attribute-Based Encryption – CP-ABE). Es gibt Kompromisse zwischen diesen beiden Varianten, aber sie sind funktional äquivalent, da sie Duale voneinander sind. Konzentrieren wir uns auf CP-ABE, da dieses Modell der realen Welt der Zugriffskontrolle näherkommt. Stellen Sie sich ein Krankenhaus vor, in dem ein Arzt die Attribute „role: doctor“ (Rolle: Arzt) und „region: US“ (Region: USA) hat, während eine Krankenschwester die Attribute „role: nurse“ (Rolle: Krankenschwester) und „region: EU“ (Region: EU) hat. Ein Dokument, das gemäß der Richtlinie „role: doctor or region: EU“ verschlüsselt ist, kann sowohl vom Arzt als auch von der Krankenschwester entschlüsselt werden. Mit anderen Worten: ABE ist wie ein Zauberschloss, das sich nur für Personen öffnet, die über die richtigen Attribute verfügen.

.tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-amwm{font-weight:bold;text-align:center;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}

Policy	Semantics
country: US or region: EU	Decryption is possible either in the US or in the European Union
not (country: RU or country: US)	Decryption is not possible in Russia and US
country: US and security: high	Decryption is possible only in data centers within the US that have a high level of security (for some security definition established previously)

Richtlinie

Semantik

country: US or region: EU

Die Entschlüsselung kann entweder in den USA oder in der Europäischen Union erfolgen

not (country: RU or country: US)

Die Entschlüsselung kann nicht in Russland und den USA erfolgen

country: US and security: high

publicKey, masterSecretKey := cpabe.Setup()

policy := cpabe.Policy{}
policy.FromString("country: US or region: EU")

ciphertext := publicKey.Encrypt(policy, []byte("secret message"))

attrsParisDC := cpabe.Attributes{}
attrsParisDC.FromMap(map[string]string{"country": "FR", "region": "EU"}

secretKeyParisDC := masterSecretKey.KeyGen(attrsParisDC)

plaintext := secretKeyParisDC.Decrypt(ciphertext)

assertEquals(plaintext, "secret message")

Die Entschlüsselung kann nur in Rechenzentren innerhalb der USA erfolgen, die ein hohes Sicherheitsniveau aufweisen (für einen zuvor festgelegten Sicherheitsstandard)

Es gibt viele verschiedene ABE-Schemata mit unterschiedlichen Merkmalen. Das von uns gewählte Schema muss ein paar Anforderungen erfüllen:

1. Negation Wir wollen in der Lage sein, boolesche Funktionen zu unterstützen, die aus AND, OR und NOT bestehen, auch bekannt als nicht monotone boolesche Funktionen. Während praktisch jedes Schema AND und OR beherrscht, ist NOT seltener zu finden. Die Negation macht es einfacher, bestimmte Länder oder Rechner auf die Sperrliste zu setzen.

2. Wiederholte Attribute Schauen wir uns die Richtlinie „organization: executive or (organization: weapons and clearance: top-secret)“ an. Das Attribut „organization“ wird in der Richtlinie wiederholt. Schemata mit Unterstützung für Wiederholungen erhöhen die Ausdrucksfähigkeit und Flexibilität bei der Erstellung von Richtlinien erheblich.

3. Schutz vor Angriffen mit ausgewähltem Chiffretext Die meisten Schemata werden in einer Form präsentiert, die nur dann sicher ist, wenn der Angreifer die zu entschlüsselnden Nachrichten nicht auswählt (CPA). Es gibt zwar Standardverfahren, um ein solches Schema in eines umzuwandeln, das auch dann sicher ist, wenn der Angreifer die Chiffretexte manipuliert (CCA), dies geschieht aber nicht automatisch. Wir wenden die bekannte Boneh-Katz-Transformation auf das von uns gewählte Schema an, um es gegen diese Klasse von Angriffen zu immunisieren. In unserem nächsten Blogbeitrag werden wir einen Sicherheitsbeweis für das Ende-zu-Ende-Schema vorlegen.

Insbesondere auf die Negation sollte noch etwas näher eingegangen werden. Damit ein Attribut erfüllt ist, wenn es negiert wird, muss der Name gleich bleiben, aber der Wert muss sich ändern. Es ist in etwa so, als würde das Rechenzentrum „Ich habe ein Land, aber es ist definitiv nicht Japan“ anstelle von „Ich habe kein Land“ sagen. Das mag kontraintuitiv erscheinen, aber es ermöglicht die Entschlüsselung, ohne dass jeder Attributwert untersucht werden muss. Außerdem lassen sich so die Attribute sicher schrittweise einführen. Auf Grundlage dieser Kriterien haben wir uns für das Schema von Tomida et al. (2021) entschieden.

Die Implementierung eines solchen komplexen kryptografischen Schemas kann eine beträchtliche Herausforderung darstellen. Die Annahme eines diskreten Logarithmus, die der traditionellen Public-Key-Kryptografie zugrunde liegt, reicht nicht aus, um die Sicherheitsanforderungen von ABE zu erfüllen. ABE-Schemata müssen sowohl die Chiffretexte als auch die attributbasierten geheimen Schlüssel schützen. Demgegenüber legt die herkömmliche Public-Key-Kryptografie nur Sicherheitsbeschränkungen für die Chiffretexte fest, während es sich bei dem geheimen Schlüssel lediglich um eine ganze Zahl handelt. Um dies zu erreichen, werden die meisten ABE-Verfahren mit Hilfe einer mathematischen Operation konstruiert, die als bilineare Paarbildung bekannt ist.

Die Geschwindigkeit, mit der wir Paarbildungsoperationen durchführen können, bestimmt die grundlegende Performance unserer Implementierung. Effizienz ist vor allem bei der Entschlüsselung wünschenswert, wo sie verwendet werden, um den attributbasierten geheimen Schlüssel mit dem Chiffretext zu kombinieren, um den Klartext wiederherzustellen. Zu diesem Zweck verlassen wir uns auf unsere hoch optimierten Pairing-Implementierungen in unserer Open-Source-Bibliothek für kryptografische Suiten, CIRCL, die wir in einem früheren Blogbeitrag ausführlich besprochen haben. Außerdem werden die verschiedenen Schlüssel, Attribute und der Chiffretext, der die Zugriffsstruktur einbettet, als Matrizen und Vektoren ausgedrückt. Wir haben lineare Algebra-Routinen verfasst, um Matrizen-Operationen wie Multiplikation, Transponierung und Umkehrung zu handhaben. Diese sind notwendig, um die Strukturen nach Bedarf zu handhaben. Wir haben auch Serialisierung, umfangreiche Tests und Benchmarking hinzugefügt. Schließlich haben wir unsere Konvertierung in ein CCA2 resistentes Schema implementiert.

Zusätzlich zur Kernkryptografie mussten wir entscheiden, wie wir Richtlinien ausdrücken und darstellen wollten. Letztendlich entschieden wir uns für die Verwendung von Zeichenketten für unsere API. Das ist zwar für Programme vielleicht weniger praktisch als Strukturen, aber die Nutzer unseres Schemas müssten ohnehin einen Parser implementieren. Wenn wir das für sie tun, scheint uns das ein Weg zu sein, für eine stabilere Schnittstelle zu sorgen. Das bedeutet, dass das Frontend unserer Richtliniensprache aus booleschen Ausdrücken in Form von Zeichenketten besteht, z. B. „country: JP or (not region: EU)“, während das Backend ein monotoner boolescher Schaltkreis ist, der aus Drähten und Gattern besteht. Monotone boolesche Schaltkreise umfassen nur AND- und OR-Gatter. Um NOT-Gatter zu behandeln, haben wir den Drähten positive oder negative Werte zugewiesen. Jedes NOT-Gatter kann aufgrund des De-morganschen Gesetzes, das die Umwandlung einer Formel wie „not (X and Y)“ in „not X or not Y“ ermöglicht, direkt auf einem Draht platziert werden, und das Gleiche gilt für die Disjunktion.

Es folgt eine Demonstration der API. Die zentrale Stelle führt Setup aus, um den öffentlichen und den geheimen Master-Schlüssel zu erzeugen. Der öffentliche Master-Schlüssel kann von jedem verwendet werden, um eine Nachricht mittels einer Zugriffsrichtlinie zu verschlüsseln. Mit dem geheimen Master-Schlüssel, der sich im Besitz der zentralen Stelle befindet, werden geheime Schlüssel für Nutzer auf Grundlage ihrer Attribute generiert. Die Attribute selbst können Out-of-Band geliefert werden. In unserem Fall stützen wir uns bei der Bereitstellung und Validierung von Attributen auf die Datenbank für die Rechnerbereitstellung. Diese attributbasierten geheimen Schlüssel werden sicher an die Nutzer verteilt, z. B. über TLS, und zur Entschlüsselung von Chiffretexten verwendet. Die API enthält auch Hilfsfunktionen zur Überprüfung der Entschlüsselungsfähigkeiten und zur Extraktion von Richtlinien aus Chiffretexten, um die Benutzerfreundlichkeit zu verbessern.

Solution	Flexible policies	Fault Tolerant	Efficient Space	Low Latency	Collusion-resistant	Changes to machines
Different copies of Quicksilver in data centers	✅		✅	✅	✅	✅
Complicated Business Logic in Core	✅		✅		✅	✅
Encrypt customer keys with each data center’s unique keypair	✅	✅		✅	✅
Encrypt customer keys with a policy-based keypair, where each data center has multiple policy-based keypairs		✅		✅	✅
Identity-Based Broadcast Encryption + Identity-Based Negative Broadcast Encryption(Geo Key Manager v1)		✅	✅	✅
Attribute-Based Encryption(Geo Key Manager v2)	✅	✅	✅	✅	✅	✅

Wir kehren nun zu unserem ursprünglichen Beispiel zurück. Diesmal ist die zentrale Stelle im Besitz des geheimen Master-Schlüssels. Jeder Rechner in jedem Rechenzentrum legt seine Attribute der zentralen Stelle vor, die nach einer Überprüfung einen eindeutigen attributbasierten geheimen Schlüssel für diesen bestimmten Rechner generiert. Die Schlüsselausgabe erfolgt bei der ersten Inbetriebnahme eines Rechners, wenn Schlüssel rotiert werden müssen oder wenn sich ein Attribut geändert hat, jedoch nie innerhalb des kritischen Pfads eines TLS-Handshakes. Diese Lösung ist auch vor Absprachen sicher, d. h. zwei Rechner ohne die entsprechenden Attribute können ihre Schlüssel nicht kombinieren, um ein Geheimnis zu entschlüsseln, das sie einzeln nicht entschlüsseln könnten. Beispielsweise können sich ein Rechner mit dem Attribut „country: US“ und ein anderer mit „security: high“ nicht zusammentun, um eine Ressource mit der Richtlinie „country: US and security: high“ zu entschlüsseln.

Entscheidend ist, dass diese Lösung reibungslos skaliert werden und auf Änderungen bei den Rechnern reagieren kann. Wenn ein neuer Rechner hinzukommt, kann die zentrale Stelle ihm einfach einen geheimen Schlüssel ausstellen, da die Teilnehmer des Schemas im Gegensatz zu unserem früheren Identitätsübermittlungsschema bei der Einrichtung nicht im Voraus festgelegt werden müssen.

Scheme	Secret key(bytes)	Public key(bytes)	Overhead of encrypting 23 bytes (ciphertext length - message length)	Overhead of encrypting 10k bytes (ciphertext length - message length)
RSA-2048	1190 (PKCS#1)	256	233	3568
X25519	32	32	48	48
GeoV1 scheme	4838	4742	169	169
GeoV2 ABE scheme	33416	3282	19419	19419

Schlüsselverteilung

Scheme	Generating keypair	Encrypting 23 bytes	Decrypting 23 bytes
RSA-2048	117 ms	0.043 ms	1.26 ms
X25519	0.045 ms	0.093 ms	0.046 ms
GeoV1 scheme	75 ms	10.7 ms	13.9 ms
GeoV2 ABE scheme	1796 ms	704 ms	62.4 ms

Wenn ein Kunde sein TLS-Zertifikat hochlädt, kann er eine Richtlinie angeben. Dann verschlüsselt die zentrale Stelle seinen privaten Schlüssel gemäß der festgelegten Richtlinie mit dem öffentlichen Master-Schlüssel. Der verschlüsselte Kundenschlüssel wird dann in Quicksilver gespeichert und an alle Rechenzentren verteilt. In der Praxis gibt es hier eine indirekte Ebene, auf die wir in einem späteren Abschnitt eingehen werden.

Verschlüsselung mit öffentlichem Master-Schlüssel

Wenn ein Nutzer die Website des Kunden besucht, holt sich der TLS-Terminierungsdienst in dem Rechenzentrum, das die Anfrage zuerst erhält, den verschlüsselten privaten Schlüssel des Kunden bei Quicksilver. Wenn die Attribute des Dienstes nicht den Richtlinien entsprechen, schlägt die Entschlüsselung fehl und die Anfrage wird an das nächstgelegene Rechenzentrum weitergeleitet, das die Richtlinie erfüllt. Das Rechenzentrum, das den Schlüssel erfolgreich entschlüsseln kann, führt die Signatur durch, um den TLS-Handshake abzuschließen.

Entschlüsselung mit attributbasiertem geheimen Schlüssel (vereinfacht)

Die folgende Tabelle fasst die besprochenen Vor- und Nachteile der verschiedenen Lösungen zusammen:

.tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

Lösung

Flexible Richtlinien

Fehlertolerant

Key	Purpose	CA in core	Core	Network
Master Public Key	Encrypts private policy keys over an access policy	Generate	Read
Master Secret Key	Generates secret keys for machines based on their attributes	Generate,Read
Machine Secret Key / Attribute-Based Secret Key	Decrypts private policy keys stored in global KV store, Quicksilver	Generate		Read
Customer TLS Private Key	Performs digital signature necessary to complete TLS handshake to the customer’s website		Read (transiently on upload)	Read
Public Policy Key	Encrypts customers’ TLS private keys		Generate, Read
Private Policy Key	Decrypts customer’s TLS private keys	Read (transiently during key rotation)	Generate	Read

Effiziente Speicherplatznutzung

Geringe Latenz

Sicher vor Absprachen

Änderungen an Rechnern möglich

Verschiedene Quicksilver-Kopien in Rechenzentren

✅

✅

✅

✅

✅

Komplizierte Geschäftslogik im Zentrum

✅

✅

✅

✅

Verschlüsselung von Kunden-Schlüsseln mit dem einmaligen Schlüsselpaar jedes Rechenzentrums

✅

✅

✅

✅

Verschlüsselung von Kunden-Schlüsseln mit einem Richtlinien-basierten Schlüsselpaar, wobei jedes Rechenzentrum über mehrere Richtlinien-basierte Schlüsselpaare verfügt

✅

✅

✅

Idenntitätsbasierte Broadcast-Verschlüsselung + identitätsbasierte negative Broadcast-Verschlüsselung(Geo Key Manager v1)

✅

✅

✅

Attributsbasierte Verschlüsselung(Geo Key Manager v2)

✅

✅

✅

✅

✅

✅

Wir charakterisieren die Performance unseres Schemas anhand von Messwerten, die an ECRYPT angelehnt sind. Wir setzen die Attributgröße auf 50, was deutlich höher ist als für die meisten Anwendungennötig, aber für Benchmarking-Zwecke als Worst-Case-Szenario dient. Wir führen unsere Messungen auf einem Laptop mit Intel Core i7-10610U CPU @ 1,80GHz durch und vergleichen die Ergebnisse mit RSA mit 2048-Bit-Sicherheit, X25519 und unserem vorherigen Schema.

.tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

Schema

Geheimer Schlüssel (Bytes)

Public key(bytes)

Overhead der Verschlüsselung von 23 Bytes(Chiffretext-Länge – Nachrichtenlänge)

Overhead der Verschlüsselung von 10.000 Bytes(Chiffretext-Länge – Nachrichtenlänge)

RSA-2048

1190 (PKCS#1)

256

233

3568

X25519

32

32

48

48

GeoV1 scheme

4838

4742

169

169

GeoV2 ABE scheme

33416

3282

19419

19419

Verschiedene attributbasierte Verschlüsselungsschemata sind für unterschiedliche Performance-Profile optimiert. Einige können eine schnelle Schlüsselgenerierung aufweisen, während andere einer schnellen Entschlüsselung den Vorzug geben. In unserem Fall ist uns nur die schnelle Entschlüsselung wichtig, da dies der einzige Teil des Prozesses ist, der im kritischen Pfad einer Anfrage liegt. Alles andere geschieht Out-of-Band, wo der zusätzliche Overhead akzeptabel ist.

.tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

Schema

Erzeugung des Schlüsselpaars

Verschlüsselung von 23 Bytes

Entschlüsselung von 23 Bytes

RSA-2048

117 ms

0.043 ms

1.26 ms

X25519

0.045 ms

0.093 ms

0.046 ms

GeoV1 scheme

75 ms

10.7 ms

13.9 ms

GeoV2 ABE scheme

1796 ms

704 ms

62.4 ms

Wir haben die attributbasierte Verschlüsselung verwendet, um das zu implementieren, was allgemein als attributbasierte Zugriffskontrolle (Attribute-Based Access Control – ABAC) bekannt ist.

ABAC ist eine Erweiterung der bekannteren rollenbasierten Zugriffskontrolle (Role-Based Access Control – RBAC). Um zu verstehen, warum ABAC relevant ist, lassen Sie uns kurz auf die Ursprünge dieses Modells eingehen. Im Jahr 1970 führte das US-Verteidigungsministerium die benutzerbestimmbare Zugriffskontrolle (Discretionary Access Control – DAC) ein. DAC ist die Art und Weise, wie Unix-Dateisysteme implementiert sind. DAC reicht jedoch nicht aus, wenn man die gemeinsame Nutzung einschränken will, da der Eigentümer der Ressource anderen Nutzern die Erlaubnis erteilen kann, auf die Ressource in einer Weise zuzugreifen, mit der der zentrale Administrator nicht einverstanden ist. Um dieses Problem zu lösen, führte das Verteidigungsministerium die obligatorische Zugriffskontrolle (Mandatory Access Control – MAC) ein. DRM ist ein gutes Beispiel für MAC. Auch wenn Sie die Datei besitzen, haben Sie nicht das Recht, sie an andere weiterzugeben.

Bei RBAC handelt es sich um eine Implementierung bestimmter Aspekte von MAC. ABAC ist eine Erweiterung von RBAC, die 2017 vom NIST definiert wurde, um die zunehmenden Eigenschaften von Nutzern zu berücksichtigen, die nicht auf ihre Rollen beschränkt sind, z. B. Tageszeit, Nutzeragent usw.

RBAC/ABAC sind jedoch lediglich eine Spezifikationen. Traditionell werden sie mit einer zentralen Stelle implementiert, um den Zugriff auf eine Ressource zu kontrollieren, doch das ist nicht zwangsläufig der Fall. Die attributbasierte Verschlüsselung ist ein hervorragender Mechanismus zur Implementierung von ABAC in dezentralen Systemen.

Es mag zwar verlockend sein, alle Fehler dem DNS zuzuschreiben, aber die Schlüsselrotation ist ein weiterer starker Anwärter. Die Erfahrung mit dem eher manuellen und fehleranfälligen Schlüsselrotationsverfahren des Geo Key Managers v1 hat uns gelehrt, eine robuste und einfache Schlüsselrotation ohne Auswirkungen auf die Verfügbarkeit zu einem ausdrücklichen Designziel für den Geo Key Manager v2 zu machen.

Um die Schlüsselrotation zu vereinfachen und die Performance zu verbessern, führen wir eine indirekte Ebene in den Prozess der Verschlüsselung des Kundenschlüssels ein. Wenn ein Kunde seinen privaten TLS-Schlüssel hochlädt, verschlüsseln wir ihn nicht mit dem öffentlichen Master-Schlüssel, sondern erzeugen ein X25519-Schlüsselpaar, den so genannten Richtlinienschlüssel (Policy Key). Die zentrale Stelle fügt dann den öffentlichen Teil dieses neu erzeugten Schlüsselpaares und die zugehörige Kennzeichnung der Richtlinie in eine Datenbank ein. Anschließend verschlüsselt sie die private Hälfte des Richtlinien-Schlüsselpaars gemäß der zugehörigen Zugriffsrichtlinie mit dem öffentlichen Master-Schlüssel. Der private Schlüssel des Kunden wird mit dem öffentlichen Schlüssel der Richtlinie verschlüsselt und in Quicksilver gespeichert.

Wenn ein Nutzer auf die Website des Kunden zugreift, ruft der TLS-Beendigungsdienst in dem Rechenzentrum, das die Anfrage erhält, den verschlüsselten Richtlinienschlüssel ab, der mit der Zugriffsrichtlinie des Kunden verknüpft ist. Entsprechen die Attribute des Rechners nicht der Richtlinie, schlägt die Entschlüsselung fehl und die Anfrage wird an das nächstgelegene Rechenzentrum weitergeleitet, das die Richtlinie erfüllt. Ist die Entschlüsselung erfolgreich, wird der Richtlinienschlüssel verwendet, um den privaten Schlüssel des Kunden zu entschlüsseln und den Handshake abzuschließen.

.tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

Schlüssel

Ziel

CA im Hauptrechenzentrum

Hauptrechenzentrum

Netzwerk

Öffentlicher Master-Schlüssel

Verschlüsselt private Richtlinienschlüssel mittels einer Zugriffsrichtlinie

Generieren

Lesen

Geheimer Master-Schlüssel

Erzeugt geheime Schlüssel für Rechner auf Grundlage ihrer Attribute

Generieren,Lesen

Geheimer Rechner-Schlüssel / attributbasierter geheimer Schlüssel

Entschlüsselt private Richtlinien-Schlüssel, die in der globalen Schlüssel-Werte-Datenbank Quicksilver abgelegt sind

Generieren

Lesen

Privater Kunden-TLS-Schlüssel

Vollzieht die zum Abschluss des TLS Handshake mit der Website des Kunden erforderliche digitale Signatur

Lesen (vorübergehend beim Upload)

Lesen

Öffentlicher Richtlinienschlüssel

Verschlüsselt private TLS-Schlüssel des Kunden

Generieren,Lesen

Privater Richtlinienschlüssel

Entschlüsselt die privaten TLS-Schlüssel des Kunden

Lesen (vorübergehend während der Schlüsselrotation)

Generieren

Lesen

Richtlinienschlüssel werden jedoch nicht für jeden Zertifikats-Upload eines Kunden generiert. Wie in der Abbildung unten dargestellt, wird der Richtlinienschlüssel wiederverwendet, wenn ein Kunde eine Richtlinie anfordert, die bereits im System vorhanden ist und somit über einen zugehörigen Richtlinienschlüssel verfügt. Da die meisten Kunden dieselben wenigen Richtlinien verwenden, z. B. die Beschränkung auf ein Land oder auf die EU, ist die Zahl der Richtlinienschlüssel um ein Vielfaches geringer als die der Kundenschlüssel.

Richtlinienschlüssel

Diese gemeinsame Nutzung von Richtlinienschlüsseln ist für die Schlüsselrotation äußerst nützlich. Bei der Rotation der Master-Schlüssel (und damit der geheimen Rechnerschlüssel) müssen nur die wenigen Richtlinienschlüssel, mit denen der Zugriff auf die Kundenschlüssel kontrolliert wird, neu verschlüsselt werden, nicht aber die Schlüssel jedes einzelnen Kunden. Das reduziert die Anforderungen an Rechenleistung und Bandbreite. Darüber hinaus verbessert sich durch das Zwischenspeichern von Richtlinienschlüsseln beim TLS-Terminierungsdienst die Performance, weil seltener Entschlüsselungen innerhalb des kritischen Pfads erforderlich sind.

Dies ist vergleichbar mit der hybriden Verschlüsselung, bei der mit Hilfe der Public-Key-Kryptographie ein gemeinsamer symmetrischer Schlüssel erstellt wird, der dann zur Verschlüsselung von Daten verwendet wird. Der Unterschied besteht darin, dass es sich nicht um symmetrische Schlüssel handelt, sondern um X25519-Schlüsselpaare – ein asymmetrisches Schema, das auf elliptischen Kurven basiert. Dieses arbeitet zwar nicht so schnell wie symmetrische Schemata wie AES, aber die traditionelle Elliptische-Kurven-Kryptografie funktioniert wesentlich schneller als die attributbasierte Verschlüsselung. Der Vorteil besteht darin, dass die zentrale Stelle keinen Zugriff auf geheimes Schlüsselmaterial benötigt, um Kundenschlüssel zu verschlüsseln.

Die andere Komponente der robusten Schlüsselrotation besteht darin, dass mehrere Schlüsselversionen verwaltet werden: Die neueste Schlüsselgeneration wird für die Verschlüsselung verwendet, aber die letzte und die vorherige Version können für die Entschlüsselung genutzt werden. Wir verwenden ein System von Zuständen, um Schlüsselübergänge und die sichere Löschung älterer Schlüssel zu verwalten. Außerdem verfügen wir über ein umfassendes Überwachungssystem, das uns alarmiert, wenn ein Rechner nicht die richtige Schlüsselgeneration verwendet.

Der Geo Key Manager litt unter einer hohen Tail-Latenz, die gelegentlich die Verfügbarkeit beeinträchtigte. Jeff Deans Artikel „The Tail at Scale“ bietet eine aufschlussreiche Lektüre darüber, wie selbst eine im hohen Latenzbereich p99 im Cloudflare-Maßstab Schaden anrichten kann. Obwohl wir die Server- und Client-Komponenten unseres Dienstes überarbeitet haben, hat sich die p99-Latenz nicht verändert. Diese Anpassungen, z. B. die Umstellung von Worker-Pools auf eine Goroutine pro Anfrage, vereinfachten den Dienst, da sie Tausende von Codezeilen entfernten. Durch verteiltes Tracing konnten wir die Verzögerungen eingrenzen: Sie traten zwischen dem Senden einer Anfrage durch den Client und dem Empfangen der Anfrage durch den Server auf. Aber wir konnten nicht weiter nachforschen. Letztes Jahr verfassten wir sogar einen Blogbeitrag, in dem wir unsere Debugging-Bemühungen beschrieben, ohne jedoch eine konkrete Lösung zu finden.

Schließlich wurde uns klar, dass es eine indirekte Ebene zwischen dem Client und dem Server gibt. Unsere Rechenzentren auf der ganzen Welt sind sehr unterschiedlich groß. Um zu vermeiden, dass kleinere Rechenzentren mit einer Flut von Verbindungen konfrontiert werden, beauftragten größere Rechenzentren einzelne Zwischenrechner mit der Weiterleitung von Anfragen an andere Rechenzentren unter Verwendung der Go-net/rpc-Bibliothek.

Nachdem wir die Weiterleitungsfunktion auf dem Zwischenserver in die Nachverfolgung einbezogen hatten, wurde das Problem sichtbar. Es gab eine lange Verzögerung zwischen der Ausgabe der Anfrage und ihrer Verarbeitung. Dabei war der Code lediglich ein Aufruf einer integrierten Bibliotheksfunktion. Warum verzögerte er also die Anfrage?

Letztendlich fanden wir heraus, dass während der Serialisierung der Anfrage eine Sperre aufrechterhalten wurde. Das net/rpc-Paket unterstützt kein Streaming, unser paketorientiertes benutzerdefiniertes Anwendungsprotokoll, das wir vor der Einführung von gRPC geschrieben haben, hingegen schon. Um diese Lücke zu schließen, haben wir eine Anfrage ausgeführt und in der Serialisierungsfunktion auf die Antwort gewartet. Das war zwar eine zweckmäßige Methode, um den Code zu schreiben, führte aber zu einem Performance-Engpass, da immer nur eine Anfrage gleichzeitig weitergeleitet werden konnte.

Unsere Lösung bestand darin, Kanäle für die Koordination zu verwenden, sodass mehrere Anfragen ausgeführt werden konnten, während wir auf die Antworten warteten. Als wir diese Lösung einführten, konnten wir eine drastische Verringerung der Latenz feststellen.

Die Ergebnisse der Behebung von RPC-Fehlern in einem Remote-Colocatiion-Standort in Australien

Leider können wir die Lichtgeschwindigkeit (noch) nicht noch weiter erhöhen. Kunden, die möchten, dass ihre Schlüssel nur in den USA aufbewahrt werden, während ihre Website-Nutzer in Australien sind, müssen bei der Reise über den Pazifik einige Verzögerungen in Kauf nehmen. Aber dank der Sitzungs-Tickets betreffen diese Verzögerungen nur neue Verbindungen.

Auch die Betriebszeit wurde erheblich gesteigert. Rechenzentren, die nach der kryptografischen Initiierung eingerichtet wurden, konnten nun am System teilnehmen. Das bedeutete auch, dass Rechenzentren, die eine bestimmte Richtlinie nicht erfüllten, über eine größere Auswahl an zufriedenstellenden Nachbarn verfügten, an die sie die Signierungsanfrage weiterleiten konnten. Dies erhöhte die Redundanz im System und kam vor allem Rechenzentren in Regionen ohne ausgezeichnete Internetanbindung zugute. Das nachstehende Diagramm zeigt die erfolgreichen Untersuchungen, die über einen Zeitraum von zwei Tagen auf allen Rechnern weltweit durchgeführt wurden. Beim GeoV1 sehen wir, dass Websites mit Richtlinien für die Regionen USA und EU an einem Punkt auf unter 98 % fallen, während beim GeoV2 die Betriebszeit selten unter 4,9 Sekunden Verfügbarkeit sinkt.

Betriebszeit nach Schlüsselprofil in den USA und der EU für den GeoV1 und den GeoV2 sowie IN für den GeoV2

Herzlichen Glückwunsch, dass Sie es bis hierher geschafft haben. Genau wie Sie hat auch die angewandte Kryptografie einen langen Weg hinter sich. Doch nur ein Bruchteil davon schafft es, die Barriere zwischen Forschung und praktischer Anwendung zu überwinden. Die Überbrückung dieser Kluft kann dazu beitragen, neue Möglichkeiten zum Schutz sensibler Daten zu schaffen. Die attributbasierte Verschlüsselung selbst ist in den letzten Jahren sehr viel effizienter und mit mehr Funktionen ausgestattet worden. Wir hoffen, dass dieser Beitrag Sie ermutigt, ABE für Ihre eigenen Anforderungen an die Zugriffskontrolle in Betracht zu ziehen – insbesondere, wenn Sie mit dezentralen Systemen arbeiten und nicht von einer hochverfügbaren zentralen Stelle abhängig sein wollen. Wir haben unsere Implementierung von CP-ABE in CIRC quelloffen zur Verfügung gestellt und planen die Veröffentlichung eines Berichts mit weiteren Einzelheiten.

Wir freuen uns auf die zahlreichen Produktverbesserungen für den Geo Key Manager, die durch diese neue kryptographische Grundlage ermöglicht werden. Wir planen, diesen ABE-basierten Mechanismus nicht nur für die Speicherung privater Schlüssel, sondern auch für andere Arten von Daten zu verwenden. Wir arbeiten daran, ihn benutzerfreundlicher zu gestalten und für die Nutzung durch interne Dienste zu verallgemeinern.

Wir möchten Watson Ladd für seine Beiträge zu diesem Projekt während seiner Zeit bei Cloudflare danken.

......

¹Zwar trifft dies für die meisten Kunden zu, aber wir bieten Keyless SSL an, womit Kunden, die ihre eigenen Schlüsselserver betreiben können, die Möglichkeit erhalten, ihre privaten Schlüssel lokal zu speichern.