© VITALII SHCHERBYNA, 123RF

In einer lebensfeindlichen Umgebung wie dem Hochgebirge muss man sich absichern. Eine Seilschaft kann man durchaus als Chain of Trust verstehen. In der virtuellen Welt ist die PKI ihr Äquivalent.

Was ist eine PKI und wie lässt sie sich einrichten? Das Linux-Magazin geht diesen Fragen in einem zweiteiligen Beitrag nach. Der vorliegende erste Teil erläutert die Grundlagen. Um sie zu verstehen, hilft es, sich vor Augen zu führen, welche gewaltigen Umbrüche sich seit etlichen Jahren in der IT vollziehen.

Früher hatten Firmen ein Rechenzentrum mit einem Netzwerk, das eine Firewall vom Rest der Welt abschirmte. Heute besitzen dieselben Unternehmen oft kein eigenes Rechenzentrum mehr, sondern betreiben ihre Infrastruktur in der Cloud. Manche nutzen weit entfernte Geräte (Internet of Things), mit denen sie Daten einsammeln oder an die sie Steuerbefehle schicken. Und spätestens seit Covid-19 werden mobile Arbeitsplätze immer mehr zur Regel.

Die große Frage in dieser schönen neuen Welt lautet nun: Wie unterscheidet man Freund und Feind? Wem kann man wie weit vertrauen, wenn sich die Netze, in denen sich Mitarbeiter, Dienste und Geräte bewegen, nicht mehr unter der eigenen Kontrolle befinden? Firewalls helfen hier nicht weiter. Auch VPNs sind nur noch bedingt hilfreich, weil man der anderen Seite nicht mehr hundertprozentig trauen kann.

In dieser Situation schlägt die Stunde eines Konzepts, das sich Zero-Trust-Network nennt. Es zielt darauf ab, das Vertrauen auf anderem Weg zu schaffen. Die Grundvoraussetzung dafür ist, dass sich Identitäten von Personen, Diensten und Geräten zweifelsfrei bestimmen lassen. Dafür ließe sich zum Beispiel ein Kerberos-Server verwenden. Das führt allerdings dann zu Problemen, wenn es Geräte gibt, die nicht permanent am Netz hängen oder die nur instabile Verbindungen haben. In diesem Fall ist eine PKI die bessere Wahl. Sie ermöglicht es, die Authentizität von Sender und Empfänger zu überprüfen.

Eine PKI arbeitet dezentral und funktioniert auch offline. Das Konzept der PKI ist schon älter und damit bewährt. Wir benutzen es täglich, etwa beim Surfen im Internet. Darüber hinaus kann sich nicht nur ein Server, sondern auch ein Client mit einem Zertifikat gegenüber einem Server identifizieren. Das macht es möglich, dass Dienste, Geräte oder Personen nur dann untereinander kommunizieren, wenn sie ein Zertifikat von einer Institution besitzen, der sie alle vertrauen.

Asymmetrische Verschlüsselung

Eine Public-Key-Infrastruktur basiert auf asymmetrischer Verschlüsselung, wie sie wohl am häufigsten bei der SSH-Anmeldung mit SSH-Key, beim Verschlüsseln von E-Mails, beim Aufbau eines VPN-Tunnels oder einer HTTPS-Verbindung zum Einsatz kommt. Gerade Letzteres benutzt man Hunderte Male am Tag, ohne darüber nachzudenken, was dabei genau abläuft.

Listing 1 zeigt ein praktisches Beispiel, das einen interessanten Effekt demonstriert: Betrachtet man öffentlichen und privaten Schlüssel, so kann man stets mit dem einen entschlüsseln, was mit dem anderen verschlüsselt wurde. Auf diese Weise vermag ein Nutzer zu beweisen, dass er im Besitz eines privaten Schlüssels ist, der zu einem öffentlichen Schlüssel gehört.

### Schlüssel erstellen:
$ openssl genrsa -out key.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
...................................+++++
................+++++
e is 65537 (0x010001)
### Public-Schlüssel erzeugen:
$ openssl rsa -in key.pem -out key.pub -pubout
writing RSA key
### Die Datei "geheim_text.txt" verschlüsseln:
$ openssl rsautl -in ./geheim_text.txt -out ./geheim_text.txt.enc -pubin -inkey ./key.pub -encrypt
### Der Versuch, die verschlüsselte Datei mit dem öffentlichen Schlüssel zu entschlüsseln, scheitert:
$ openssl rsautl -in ./geheim_text.txt.enc -out ./geheim_text.txt.dec  -inkey ./key.pub -decrypt
unable to load Private Key
139743573030720:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY
### Entschlüsseln der Daten mit dem privaten Schlüssel:
$ openssl rsautl -in ./geheim_text.txt.enc -out ./geheim_text.txt.dec  -inkey ./key.pem -decrypt
# Resultat überprüfen
$ file ./geheim_text.*
./geheim_text.txt:      ASCII text
./geheim_text.txt.dec: ASCII text
./geheim_text.txt.enc: data

Dafür codiert Person A mit dem öffentlichen Schlüssel einen geheimen Text. Den schickt er nun an Person B. Gelingt es dem Empfänger, den Text entschlüsselt zurückzuschicken, weiß Person A, dass Person B den privaten Schlüssel besitzt und offensichtlich den öffentlichen Schlüssel erstellt hat. So funktioniert die SSH-Authentifizierung mit SSH-Keys, wenn man einen öffentlichen Schlüssel auf dem Server in der Datei »authorized_keys« ablegt.

Digitale Signatur

Dreht man das Verschlüsselungsverfahren um und veröffentlicht einen Schlüssel, mit dem man nur entschlüsseln, aber nicht (wieder) verschlüsseln kann, dann lässt sich damit die Autorenschaft nachweisen. Derjenige, dem es gelingt, Dateien so zu verschlüsseln, dass sie sich mit dem öffentlichen Schlüssel dechiffrieren lassen, muss im Besitz des privaten Schlüssels sein.

Das wiederum bedeutet: Weiß man mit Sicherheit, von wem der öffentlichen Schlüssel stammt, kann man auf diesem Weg die Autorenschaft von Dokumenten prüfen. Man muss die Daten mit dem öffentlichen Schlüssel decodieren können; anderenfalls hat der Absender (beziehungsweise Unterzeichner) nicht bewiesen, das er den privaten Schlüssel besitzt. Das ist das Prinzip der digitalen Signatur.

Beide Verfahren, Verschlüsselung und Signatur, sind ihrer Logik nach verwandt, die verwendeten Algorithmen jedoch nicht. Deshalb muss man sich klarmachen, was für ein Schlüsselpaar man generiert und wofür man es verwendet. Will man sowohl verschlüsseln als auch signieren, benötigt man also zwei unterschiedliche Schlüsselpaare.

In der Praxis werden aber in der Regel nicht die Daten selbst ver- und entschlüsselt, sondern nur die Checksummen, also quasi der digitale Fingerabdruck eines Datensatzes. Selbst bei kleinsten Veränderungen an den Daten verändert sich auch diese Checksumme. Der Algorithmus, mit dessen Hilfe man eine solche Prüfsumme generiert, ist wesentlich schneller und damit zeitsparender als der Vergleich der kompletten Datensätze.

Um die Prozedur noch einmal zusammenzufassen: Person A erstellt ein asymmetrisches Schlüsselpaar und übergibt den öffentlichen Schlüssel anschließend auf sicherem Weg an Person B. Person B muss sicher sein, das der Schlüssel wirklich von A stammt.

Person A erstellt die Checksumme eines Datensatzes, den Person B erhalten soll, und verschlüsselt diese Checksumme mit ihrem privaten Schlüssel. Anschließend übermittelt A den Datensatz zusammen mit der verschlüsselten Checksumme an B.

Person B entschlüsselt die Checksumme mit dem öffentlichen Schlüssel. Abschließend erstellt B selbst noch einmal eine Checksumme des übermittelten Datensatzes und vergleicht sie mit der entschlüsselten Checksumme. Stimmen beiden Prüfsummen überein, kann B sicher sein, dass der Datensatz von A stammt und nicht verfälscht wurde.

Das Signaturverfahren ist das Fundament einer PKI. Die Person oder Institution, die die nötigen Zertifikate ausstellt, bezeichnet man im Kontext einer PKI als Certificate Authority oder kurz CA.

Chain of Trust

Ein weiteres wichtiges Konzept in einer PKI stellt die sogenannte Chain of Trust dar. Wenn eine CA ein Zertifikat signiert, beglaubigt sie damit die Richtigkeit der Angaben in diesem Zertifikat. Ein solches Zertifikat enthält einen öffentlichen Schlüssel und Informationen zu dessen Besitzer. Mit dem Schlüssel aus dem Zertifikat signierte Datensätze lassen sich damit einem Autor zuordnen.

In einem Zertifikat kann eine CA auch einer anderen CA das Vertrauen aussprechen, ihrerseits Zertifikate ausstellen zu dürfen. Eine solche CA nennt man dann eine Intermediate-CA. Auf diese Weise lassen sich Aufgaben und Verantwortung delegieren.

Wurde an eine Intermediate-CA die Aufgabe delegiert, für die Durchsetzung von Limits für die Geltungsdauer von Zertifikaten zu sorgen, spricht man von einer Policy-CA. Da die Laufzeit von Zertifikaten nicht länger sein kann als die der ausstellenden CA, lässt sich auf diesem Weg eine bestimmte Geltungsdauer erzwingen. Die Kette der Intermediate-CAs darf damit beliebig lang ausfallen, ohne dass nachgeordnete CAs die Möglichkeit hätten, Zertifikate mit einer längeren Gültigkeitsdauer auszustellen.

In einem Zertifikat kann auch ausdrücklich stehen, dass der Inhaber des signierten Schlüssels seinerseits keine gültigen Zertifikate ausstellen darf. Den Inhaber eines solchen Zertifikats nennt man End Entity. Sein Schlüssel dient nur der Identifikation und dem Nachweis einer Autorenschaft. Eine CA, die nur Zertifikate für End Entities erstellen darf, nennt man Issue-CA.

Als Gegenstück zur End Entity steht am anderen Ende der Chain of Trust die Root-CA, der Ursprung des Vertrauens. Mit dem öffentlichen Schlüssel der Root-CA lässt sich sukzessive zurückverfolgen, ob die Kette lückenlos geschlossen ist. Wurde sie auch nur an einer Stelle unterbrochen, werden alle nachfolgenden Glieder nicht mehr akzeptiert. Der Nachweis dieses lückenlosen Stammbaums erfolgt in einem CA-Bundle. Eine solche Datei enthält alle Intermediate-CA-Zertifikate, die eine lückenlose Rückverfolgung bis zum Root-CA-Zertifikat erlauben.

Abbildung 1 zeigt das Schema einer PKI. Die Person auf der linken Seite hat über eine Policy-CA und eine Issue-CA ein End-Entity-Zertifikat bekommen. Rechts sieht man einen Webservice, der ebenfalls ein End-Entity-Zertifikat besitzt, jedoch über eine jeweils andere Policy-CA und Issue-CA. Da beide End Entities aber dieselbe Root-CA kennen und ihr vertrauen, vertrauen sie auch untereinander den Zertifikaten.

Abbildung 1: Die Elemente der Chain of Trust einer PKI.

In diesem Fall weiß die Person über das Zertifikat vom Server, dass sie mit dem richtigen Service verschlüsselt spricht. Umgekehrt kann auch der Dienst anhand des Client-Zertifikats sicherstellen, dass die Person legitimiert ist, den Service zu nutzen. Wenn nicht nur der Client das Zertifikat des Servers prüft (wie bei HTTPS/SSL), sondern auch anders herum, spricht man von Mutual TLS.

Certificate Signing Request

Damit eine CA einen öffentlichen Schlüssel signieren kann, benötigt sie ein Certificate Signing Request (CSR). Es enthält den öffentlichen Schlüssel und die Informationen, die es damit zu verbinden gilt. Über Form und zum Inhalt eines CSR macht die Policy-CA Vorgaben. Zu den typischen Informationen darin zählen der Name des Zertifikatsinhabers sowie der Name seines Arbeitgebers samt Anschrift und E-Mail-Adresse.

Nimmt die CA den CSR nicht direkt entgegen, sondern über eine vorgelagerte Instanz, die den CSR inhaltlich prüft, nennt man sie eine Registration Authority (RA).

Validation Authority und CRLs

Für den Fall, dass etwas schiefgeht, muss es die Möglichkeit geben, erteilte Zertifikate zu widerrufen – etwa, weil ein Mitarbeiter das Unternehmen verlässt oder eine CA korrumpiert wurde. Für solche Fälle existieren verschiedene Lösungsansätze mit spezifischen Vor- und Nachteilen; keiner davon ist perfekt.

Eine Möglichkeit bietet eine Certificate Revocation List (CRL). Dabei pflegt eine CA eine Liste mit widerrufenen Zertifikaten, signiert die Einträge und macht die Liste öffentlich. Der Nachteil besteht darin, dass die Liste immer länger wird. Da eine CA nur ihre eigenen Zertifikate widerrufen kann und es bei mehreren CAs mehrere CRLs zu verwalten gilt, lässt sich zudem nicht sicherstellen, dass die CRLs nicht veralten, weil sie zu selten aktualisiert werden. Eine CRL ist auch nicht echtzeitfähig.

Ansätze für eine echtzeitfähige Lösung bieten die Protokolle OCSP oder SCVP. Hier befragt man eine Validation Authority (VA) in Echtzeit, ob ein Zertifikat noch gilt. Der Nachteil: Der Dienst muss dazu erreichbar sein. Er könnte aber selbst Opfer eines erfolgreichen Angriffs werden, sodass er wegen Überlastung ausfällt oder falsche Antworten gibt, weil er gekapert wurde. Zudem erfolgt die Kommunikation nicht verschlüsselt, was zu Datenschutzproblemen führen könnte.

Alle diese Lösungsansätze haben das Problem gemeinsam, dass sie nicht offline funktionieren – etwa bei einem Edge-Computing-System, bei einem tagelang untergetauchten Atom-U-Boot oder bei einer abgelegenen Industrieanlage, die nur via Satellit am Netz hängt und auf Datensparsamkeit getrimmt wurde.

Ausblick

Damit kennen Sie nun die wichtigsten Konzepte, Prinzipien und Schwachstellen einer PKI. Im zweiten Teil des Beitrags in der nächsten Ausgabe geht es konkret an den Aufbau einer eigenen PKI. (jcb/jlu)