Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 7 Min.

PKI (Teil 1): PKI-Workshop, Teil 1: Grundlagen der Public-Key-Infrastruktur: In der Seilschaft


Linux Magazin - epaper ⋅ Ausgabe 2/2021 vom 07.01.2021

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 Public Key Infrastructure (PKI) ihr Äquivalent. Olaf Radicke


Artikelbild für den Artikel "PKI (Teil 1): PKI-Workshop, Teil 1: Grundlagen der Public-Key-Infrastruktur: In der Seilschaft" aus der Ausgabe 2/2021 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 2/2021

© VITALII SHCHERBYNA, 123RF

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 ...

Weiterlesen
epaper-Einzelheft 6,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 2/2021 von README. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
README
Titelbild der Ausgabe 2/2021 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 2/2021 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 2/2021 von Kernel 5.10: Ext4 kann Fast Commits, XFS löst Jahr-2038-Problem: Jahresendspurt. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Kernel 5.10: Ext4 kann Fast Commits, XFS löst Jahr-2038-Problem: Jahresendspurt
Titelbild der Ausgabe 2/2021 von Der leichtfüßige Webserver Hiawatha: Genügsamer Präsenter. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Der leichtfüßige Webserver Hiawatha: Genügsamer Präsenter
Titelbild der Ausgabe 2/2021 von Den schlanken Webserver Lighttpd aufsetzen: Flotter Lieferservice. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Den schlanken Webserver Lighttpd aufsetzen: Flotter Lieferservice
Vorheriger Artikel
Load Balancer: Software statt Appliances: Load Balancer im Vergle…
aus dieser Ausgabe
Nächster Artikel Recht: EU will Daten-Governance-Gesetz: Datenschätze teilen
aus dieser Ausgabe

... 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 macht es möglich, die Authentizität von Sender und Empfänger zu überprüfen.

Eine Public Key Infrastructure 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 ermöglicht es, dass Dienste, Geräte oder Personen nur dann miteinander 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 VPNTunnels oder bei 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 gehört. Dafür codiert Person A mit dem öffentlichen Schlüssel einen geheimen Text. Den schickt sie 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.

Umgekehrt: 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 zwangsläufig im Besitz des privaten Schlüssels sein.

Das wiederum bedeutet nichts weniger als: 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 dekodieren können; andernfalls hat der Absender (man könnte auch sagen: der Unterzeichner) nicht nachgewiesen, dass er sich im Besitz des privaten Schlüssels befindet. 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 den meisten Fällen nicht die Daten selbst verund entschlüsselt, sondern lediglich 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 fraglichen 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.

Das Konzept der Chain of Trust

Ein weiteres wichtiges Konzept in einer Public Key Infrastructure stellt die sogenannte Chain of Trust dar. Wenn eine Certifcate Authority 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.

Es ist auch durchaus möglich, dass in einem Zertifikat ausdrücklich vermerkt ist, dass der Inhaber des signierten Schlüssels seinerseits keine gültigen Zertifikate ausstellen darf. Den Inhaber eines solchen Zertifikats nennt man dann eine End Entity. Sein Schlüssel dient dann ausschließlich der Identifikation und dem Nachweis einer Autorenschaft. Eine Certificate Authority, 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 sogenannte Root-CA. Sie ist der Ursprung des Vertrauens. Mit dem öffentlichen Schlüssel der Root-CA lässt sich sukzessive zurückverfolgen, ob die Kette überall lückenlos geschlossen ist. Wurde sie auch nur an einer einzigen Stelle unterbrochen, werden alle nachfolgenden Glieder nicht mehr akzeptiert.

Der Nachweis eines solchen lückenlosen Stammbaums erfolgt in einem CA-Bundle. Eine solche Datei enthält alle Intermediate-CA-Zertifikate, die eine lückenlose Rückverfolgung bis hinunter zum Root-CA-Zertifikat erlauben.

Abbildung 1 zeigt das Schema einer Public Key Infrastucture. 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. Ist dieser Nachweis erbracht, dann weiß die Person über das Zertifikat vom Server, dass sie mit dem richtigen Service verschlüsselt spricht.

Umgekehrt kann aber auch der Dienst anhand des Client-Zertifikats sicherstellen, dass die fragiche Person legitimiert ist, den Service zu nutzen. Wenn nicht nur der Client das Zertifikat des Servers prüft, wie das etwa bei HTTPS/ SSL der Fall ist, sondern auch anders herum, dann spricht man von Mutual TLS, also gegenseitiger TLS.

1 Die Elemente der Chain of Trust einer PKI.


Der 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 die 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 weil eine CA korrumpiert wurde. Für solche Fälle existieren verschiedene Lösungsansätze mit spezifischen Vorund Nachteilen; keiner davon ist perfekt.

Eine Möglichkeit bietet eine Certificate Revocation List oder kurz 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 zwei Protokolle OCSP und 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. Außerdem 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: Teil 2 des PKI-Workshops

Diese Einführung hat Ihnen die wichtigsten Prinzipien, Konzepte und auch Schwachstellen einer PKI vorgestellt. Auf diese Grundkenntnisse wird der zweite Teil dieser kleinen Artikelserie aufbauen. In der nächsten Ausgabe wird es dabei konkret um die Praxis gehen: Wie bewerkstelligt man den Aufbau einer eigenen PKI? (jcb/jlu)