Lade Inhalt...

Aufbau und Funktion von Public Key Infrastrukturen

Studienarbeit 2018 30 Seiten

Informatik - Internet, neue Technologien

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

1 Motivation und Einführung
1.1 Motivation
1.2 Ziel und Abgrenzung
1.3 Einführung

2 Zertifikate
2.1 Einführung
2.2 Standards für digitale Zertifikate
2.3 Aufbau eines X.509 Zertifikats
2.3.1 Erläuterung der Felder
2.4 Weitere Anwendungsfälle für Zertifikate
2.5 Resümee

3 Vertrauensmodelle
3.1 Einführung
3.2 Graphische Veranschaulichung
3.3 Direct Trust
3.4 Web of Trust
3.5 Hierarchical Trust
3.5.1 Flache Zertifizierungshierarchie
3.5.2 Strikt hierarchisches Modell
3.5.3 Cross-Zertifizierung
3.5.4 Bridge-CA
3.6 Bewertung der Vertrauensmodelle und grundlegende Dienste einer PKI
3.7 Resümee

4 Funktionsweise einer Public Key Infrastruktur (PKI)
4.1 Abgrenzung Trust Center und Certification Authority (Zertifizierungsin­stanz) (CA)
4.2 Aufbau eines Trust Centers
4.2.1 Graphische Veranschaulichung
4.2.2 Zertifizierungsstelle (ZS)
4.2.3 Registration Authority (RA)
4.2.4 Zertifikatserver / Certificate Repository
4.2.5 Time Stamp Authority (TSA)
4.2.6 Personal Security Environment (PSE)
4.3 Darstellung der Funktionsweise

5 Angriffsvektoren auf eine PKI
5.1 Einführung
5.2 Hash Kollisionen
5.3 Berechnung von Private Keys
5.4 Verlust des Private Keys
5.5 Import von unglaubwürdigen Zertifikaten
5.6 Kompromittierung eines Trust Centers
5.7 Resümee

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Motivation und Einführung

1.1 Motivation

Wenn man sich überlegt, was Wissen bedeutet, wäre eine mögliche Beschreibung: Wis­sen ist eine Folge von Erfahrungen, die sich über Jahre summieren und welche täglich automatisch um Eindrücke erweitert werden. So gilt es, sich in einem Zeitalter wo Fake News und zielgerichtete Werbung zur Manipulation des Wissens an der Tagesordnung sind, Z.B. die Datenaffäre um Cambridge Analytica, vor Augen zu halten, welche Quellen als glaubhaft einzustufen sind. Die Skepsis gegenüber Facebook Beiträgen und Co. hat bei vielen zugenommen, jedoch gelten Beiträge beispielsweise der Arbeitsgemeinschaft der öffentlich-rechtlichen Rundfunkanstalten der Bundesrepublik Deutschland (ARD) bei vielen als glaubhaft. Die Tragweite des Problems ist jedoch noch weitaus größer als den meisten bewusst ist. Was oft vernachlässigt wird, ist die Frage, ob die Inhalte der visua- lisierten Webseite der ARD überhaupt von dieser kommen. Wer stellt sicher, dass bei der Eingabe der URL www.ard.de im Browser, Informationen von dem Server der ARD über­tragen werden und nicht im Routing Prozess der Datenpakete jemand anderes sich als der Server der ARD ausgibt? (Dieses Verfahren wird auch als Man-in-the-Middle (MITM) be­zeichnet) Zu diesem Zweck wurde die sogenannte PKI entwickelt. Diese findet tagtäglich, meist vollkommen unbewusst, etliche Male Anwendung. Daher betrachtet diese Arbeit eben jene PKI, um eine weitere Erfahrung zu vermitteln. [7] [11, S.l-16]

1.2 Ziel und Abgrenzung

Ziel dieser Arbeit ist es, einen möglichst genauen Einblick zum Aufbau und der Funktion einer PKI zu vermitteln, daher beschränkt sie sich auf die PKI. So werden Kenntnisse Z.B. zu Hashfunktionen vorausgesetzt.

1.3 Einführung

Ein Ansatz, um das Problem des MITM vorzubeugen, ist es, die Kommunikation mit­tels kryptographischer Verfahren zu verschlüsseln. Bei der Verwendung einer PKI werden dieser dabei folgende Aufgaben zuteil: ״Generierung und anschließende Zertifizierung von Schlüsselpaaren, sowie die Verteilung von öffentlichen Schlüsseln. “[18, s.ll] Um diesen Herausforderungen gerecht zu werden, gilt es, die in der Kryptographie verwendeten öf­fentlichen Schlüssel, um einige Informationen zu erweitern. Außerdem müssen sie auf si­diere und zuverlässige Weise publiziert werden, was zu der Verwendung von Zertifikaten führt, welche in Kapitel 2 erläutert werden.[16, s.442-443]

Zur Signatur solcher Zertifikate finden unterschiedliche Vertrauensmodelle Anwendung. Diese und die hierbei zu lösenden Herausforderungen: Authentizität, Verbindlichkeit, Durchsetzen einer Policy sowie das sperren von Schlüsseln werden in Kapitel 3 betrach­tet.

Ausgehend von der Betrachtung aus Kapitel 3, wird die zum Betrieb der PKI notwendige Infrastruktur, anhand des Aufbaus eines Trust Centers in Kapitel 4 erläutert und die Funktion im Anschluss mittels eines Beispiels vertieft.

Zum Abschluss werden in Kapitel 5 mögliche Angriffsvektoren auf eine PKI dargestellt, um die Schwachstehen in der Praxis aufzuzeigen.

2 Zertifikate

2.1 Einführung

Der Dreh- und Angelpunkt in der PKI sind sogenannte Zertifikate. Generell kann ein Zertifikat als eine Art Ausweis angesehen werden, der die Identität von Personen oder Diensten beglaubigt. Hierzu eine mögliche Definition: ״Ein digitales Zertifikat ist eine signierte Datenstruktur, die neben einem öffentlichen Schlüssel noch den Namen seines Besitzers enthält. Das Zertifikat sorgt somit für eine sichere Zuordnung des Schlüssels zu einem Subjekt.“[18, S.14] Zuerst zu dem Schlüssel. Wie eingangs erwähnt, ist die heutige Internetkommunikation zumeist verschlüsselt, um Z.B. einem MITM Angriff vorzubeugen. Damit eine Nachricht verschlüsselt werden kann, benötigen die Teilnehmer jeweils den öffentlichen Schlüssel des anderen. Wie in der Motivation geschildert, besteht jedoch die Gefahr, dass zum Zeitpunkt des Austausches, eben jener Schlüssel von einem Angreifer durch seinen eigenen ersetzt wird. Daher gilt es zu wissen, wem der Schlüssel gehört. Diese Information, sowie einige Metadaten, können der Datenstruktur eines Zertifikats entnommen werden. [11, S.10]

2.2 Standards für digitale Zertifikate

Markant bei der Betrachtung von Standards für digitale Zertifikate ist, dass viele auf dem X.509 Standard aufbauen, wie Z.B. PKCS und PKIX. Eine Alternative stellt der Open- PGP Standard dar, welcher aus dem Pretty Good Privacy Programm hervorging.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: entnommen aus [17, S.574]

״Einer der am weitesten verbreiteten Standards für digitale Zertifikate ist X.509v3, “[18, S.15] welcher im Request for Comments (RFC) 5280 festgelegt ist. Eigentlich war X.509v3 als Teil des X.500 Standards gedacht, welcher einen weltweiten Verzeichnisbaum mit ein­deutigem Namen für Objekte wie Länder, Organisationen, Orte, Personen etc. definieren sollte. ״X.500 konnte sich bis heute nicht auf breiter Front durchsetzen. Der Zertifikats­standard nach x.509 hingegen schon “[18, s.15] Infolgedessen, wird der Aufbau eines X.509 Zertifikats betrachtet.[8, s.455-456][18, s.15]

2.3 Aufbau eines X.509 Zertifikats

Abbildung in dieser Leseprobe nicht enthalten

2.3.1 Erläuterung der Felder

Version

Es gibt drei unterschiedliche Versionen von X.509 Zertifikaten. Abhängig von der Versi­on, variiert die Anzahl der Felder. Je höher die Version, um so mehr Felder werden im Zertifikat ergänzt. Daher legt das erste Feld fest, um welches Format des Zertifikats es sich handelt.[!, s. 19][13][14]

Seriennummer des Zertifikats

Zur leichteren Handhabung eines Zertifikats, vergibt die ausstellende CA eine Seriennum­mer. Hierbei handelt es sich um einen ganzzahligen Wert, der einmalig und somit eindeutig je CA ist. [1, s.19] [13] [14]

Algorithmus und Parameter

Zur Prüfung der Echtheit, bildet der Empfänger über den Inhalt des Zertifikats einen Hashwert, welcher im Anschluss mit der entschlüsselten Signatur der CA verglichen wird. Damit die beiden Werte bei Echtheit übereinstimmen, müssen sowohl die CA als auch der Empfänger den gleichen Algorithmus verwenden. Daher wird der Hash Algorithmus, welcher von der CA verwendet wurde und ggf. zugehörige Parameter vermerkt. [1, S.19- 20] [13] [14]

Name des Ausstellers

Damit nachvollziehbar ist, durch welche CA das Zertifikat ausgestellt und beglaubigt wur­de, wird der Name des Ausstellers vermerkt. Basierend auf der X.500 Namenskonvention. [1, s.20-22] [13] [14]

Gültigkeitszeitraum

Es macht Sinn die Gültigkeit eines Zertifikats zeitlich zu beschränken, da die verwende­ten Verfahren mit der Zeit an Sicherheit einbüßen können. Genauere Informationen und mögliche Angriffsvektoren hierzu finden sie in Kapitel 5. [1, s.22-23] [13] [14]

Name des Subjekts

Da das Zertifikat einem Besitzer zugeordnet wird, ist es elementar diesen auch kenntlich zu machen. Basierend auf der Notation der X.500 Namenskonvention, wird daher ein Eintrag vorgenommen. [1, s.23-25][13][14]

Informationen zum öffentlichen Schlüssel des Subjekts

Ziel des Zertifikats ist es, eine eindeutige Identifizierung und Schlüsselzuordnung zu ge­währleisten. Hierzu benötigt man den öffentlichen Schlüssel des Subjekts, welcher durch das Zertifikat dem Subjekt eindeutig zugeordnet wird. [1, S.25] [13] [14]

Eindeutiger Bezeichner des Ausstellers

Da die x.500 Namenskonvention gegen ihre ursprüngliche Definition leider nicht eindeutig ist, wurde ab Version 2 des X.509 Zertifikats ein optionales Feld eingeführt, das verwendet wird, um die CA eindeutig zu kennzeichnen. [1, s.25-26][13][14]

Eindeutiger Bezeichner des Subjekts

Auch ist das Subjekt durch die x.500 Namenskonvention nicht immer eindeutig gekenn­zeichnet. Für den Fall, dass der x.500 Name mehrfach verwendet wurde, ist daher ab Version 2 des x.509, genau wie beim Aussteller auch, ein optionales Feld für eine eindeu­tige Bezeichnung des Subjekts vorhanden. [1, s.25-26][13][14]

Erweiterungen

״Erweiterungen erlauben zusätzliche Informationen in das Zertifikat zu verpacken, ohne das Zertifikatsformat ändern zu müssen. “[13] Somit soll verhindert werden, dass bei zu­künftigen Anforderungen immer wieder eine neue Version des X.509 Standards definiert werden muss, über ein sogenanntes Critical Bit kann gekennzeichnet werden, ob die In­terpretation des jeweiligen Erweiterungswertes eine notwendige Bedingung darstellt oder optional ist. ״Die Erweiterungen gliedern sich in drei Hauptkategorien: Informationen über Schlüssel und Aufbaurichtlinien, Subjekt- und Sender Attribute sowie Einschrän­kungen des Zertifikats Weges. “[14] Für eine detaillierte Beschreibung der Erweiterungen, auf die an dieser Stehe nicht eingegangen werden soll, empfiehlt sich der RFC 5280. [1, s.26-27] [13] [14]

Digitale Signatur der Zertifizierungsstelle

Die CA bildet einen Hashwert über den Inhalt des Zertifikats und verschlüsselt diesen mit ihrem privaten Schlüssel. Verfügt der Empfänger eines Zertifikats nun über den öffentli­chen Schlüssel der ausstehenden CA, so kann er die Signatur entschlüsseln. Für den Fall, dass der resultierende Hashwert mit dem eigens errechneten übereinstimmt, ist klar, dass die Signatur tatsächlich mit dem privaten Schlüssel der CA signiert ist und das Zertifikat nicht verändert wurde. Ausnahmen bilden Kollisionen bei Hashfunktionen. [1, S.57]

2.4 Weitere Anwendungsfälle für Zertifikate

Nicht nur bei der verschlüsselten Kommunikation spielen Zertifikate eine Rolle, sondern auch bei der digitalen Signatur und vielen weiteren Anwendungsfällen, wie Z.B. sicheres Speichern und Archivieren. Da dies jedoch den Rahmen dieser Arbeit sprengen würde, werden diese nicht weiter behandelt.[3, S.55]

2.5 Resümee

Nachdem der Aufbau und Zweck von Zertifikaten erläutert wurde, ist offensichtlich ge­worden, dass Zertifikate das Problem des Vertrauens nur verschieben. Es stellt sich die Frage, wer die Rolle der CA einnimmt und weshalb man dieser vertrauen schenkt. Hierzu gibt es verschiedene Vertrauensmodelle.

3 Vertrauensmodelle

3.1 Einführung

Aus dem Kapitel Zertifikate stellte sich die Frage, wer die Rolle der CA einnehmen kann. Im Fokus steht, welche Stelle das Vertrauen der Kommunikationspartner genießt. Hierzu gibt es mehrere Modelle, die nachfolgend behandelt werden.

3.2 Graphische Veranschaulichung

Abbildung in dieser Leseprobe nicht enthalten

3.3 Direct Trust

Direct Trust ist wohl das einfachste und auch intuitivste Vertrauensmodell, da die Kom­munikationspartner gegenseitig ihre Identität überprüfen, in dem sie über einen zweiten Kommunikationsweg ihre öffentlichen Schlüssel austauschen. Dieser Prozess wird schnell sehr aufwendig. Verdeutlicht wird dies bei der Vorstellung, dass bei jedem Aufruf einer neuen Webseite der Vorgang wiederholt werden müsste. Auch ist die Signatur des eigenen Zertifikats eher fraglich, was die Vorstellung eines selbst ausgestellten Ausweis wohl am einfachsten verdeutlicht. [17, s.565-566] [18, S.25]

3.4 Web of Trust

Der selbst ausgestellte Ausweis aus Direct Trust, existiert bei Web of Trust nicht. Anstelle dessen, wird das Zertifikat durch einen anderen Teilnehmer signiert, der als Vertrauens­würdig gilt und somit das Vertrauen scheinbar vererbt. Das Problem hierbei ist, dass Vertrauen nicht vererbbar ist. Betrachtet man die unterschiedlichen Interessen der Men­sehen, so mag ein Individuum kein Interesse haben, einem bestimmten Subjekt zu schaden und scheint daher für dieses vertrauenswürdig. Doch das gilt deshalb noch lange nicht für alle anderen Subjekte in dem Vertrauensnetz.[6, s. 120-121][18, S.26]

3.5 Hierarchical Trust

Bei Hierarchical Trust werden Zertifikate ausschließlich durch eine dritte unabhängige Instanz, beispielsweise eines Trust Centers, ausgestellt. Diese wird zumeist als Zertifizie­rungsinstanz bezeichnet. Wie durch den Begriff Trust Center (TC) schon nahe gelegt, wird im Gegensatz zu den vorherigen Vertrauensmodellen nun eine Infrastruktur zum Betrieb benötigt, daher auch die Bezeichnung PKI. Die Zertifikatshierarchie kann hierbei unterschiedliche Ausprägungen einnehmen, welche im Folgenden betrachtet werden. [16, s.567-568] [18, S.27]

3.5.1 Flache Zertifizierungshierarchie

Eine recht triviale Zertifizierungshierarchie stellt die flache (einstufige) Zertifizierungs­hierarchie dar, hierbei gibt es eine große Menge an Teilnehmern, die alle von einer CA zertifiziert werden. [16, s.569] [18, S.27]

3.5.2 Strikt hierarchisches Modell

An der Spitze des strikt hierarchischen Modells steht die Wurzel CA. Diese signiert ihr Zertifikat selbst und die Zertifikate der eine Stufe unter ihr folgenden Zertifizierungsstel­len. Diese wiederum können weitere Zertifizierungsstellen zertifizieren. Das Modell wird immer weiter geführt, so dass sich eine baumartige Struktur ergibt. Gilt es ein Zertifikat zu prüfen, wird mit der Suche nach einem Pfad in der Baumstruktur begonnen.

Abbildung in dieser Leseprobe nicht enthalten

Die Teilnehmer kennen den Schlüssel der (eigenen) CA und vertrauen den damit signierten Zertifikaten. Da jedoch kein direkter Pfad gefunden wird, betrachtet er eine Ebene höher im Baum, Z.B. CA 1, welche ursprünglich (seine eigene) CA beglaubigt hat. Nun werden alle Knoten von CA 1 abwärts geprüft. Kommt es erneut nicht zu einem validen Pfad, wiederholt sich das Prozedere bis zur Root CA. Im dargelegten Fall wird beim Abstieg von CA 2 ein Pfad gefunden, womit CA в und dem von ihr ausgestellten Zertifikat vertraut wird. [5]

3.5.3 Cross-Zertifizierung

Da es in der Realität viele voneinander unabhängige Zertifizierungsstellen gibt, wie Z.B. im World Wide Web, entsteht die Notwendigkeit für eine CA ihren Teilnehmerkreis zu erweitern. Ein Beispiel könnte etwa die Fusion zweier Unternehmen sein. Hierzu stellen sich die Zertifizierungsstellen gegenseitig Zertifikate aus und beglaubigen damit den öf­fentlichen Schlüssel des jeweils anderen. Beispiel in der Anwendung: CA 1 stellt CA 2 ein Zertifikat aus und umgekehrt, Client 1 besitzt den öffentlichen Schlüssel von CA 1, jedoch nicht von CA 2. Client 2 besitzt den öffentlichen Schlüssel von CA 2, jedoch nicht von CA 1. Möchte nun Client 1 das Zertifikat von Client 2 prüfen, so holt er sowohl das Zertifikat der CA 2 als auch das von Client 2 ein, um die Echtheit zu prüfen. Da das Zertifikat der CA 2 eine Signatur von CA 1 enthält, wird auch allen von CA 2 signierten Zertifikaten vertraut. Dasselbe gilt auch für die andere Richtung. [16, S.570]

3.5.4 Bridge-CA

Wenn eine CA sich nicht direkt in ein hierarchisches Modell einbinden lassen möchte, da die Unterordnung Z.B. aus Prestigegründen nicht gewollt ist, besteht die Möglichkeit, eine sogenannte Bridge-CA zu nutzen, um ähnlich der Cross-Zertifizierung, seinen Teilnehmer­kreis zu erweitern. Beispielsweise wird eine solche Bridge-CA durch den Bundesverband IT-Sicherheit e.v. (TeleTrust) betrieben. [10]

3.6 Bewertung der Vertrauensmodelle und grundlegende Dienste einer PKI

Nach der Betrachtung der Vertrauensmodelle, sollen diese unter Zuhilfenahme passender Kriterien bewertet werden. Dabei stellt sich die Frage, welche grundlegenden Dienste wir von einer PKI erwarten.

Authentizität

Authentizität in der konkreten Anwendung wird als Authentisierung bezeichnet. Wird eine Authentisierung geprüft, so handelt es sich um eine Authentifizierung. Kern dessen ist sicherzustellen, dass es sich bei einem Subjekt oder einem Objekt, um den Kommuni­kationsteilnehmer handelt, welches es vorgibt zu sein.[18, 12] [4]

Schlüsselmanagement

In Hinsicht auf Vertrauensmodelle, ist hierbei vor allem die Sperrung von Schlüssel von Bedeutung. So soll es möglich sein, bei einer Kompromittierung der privaten Schlüsseln, diese zu widerrufen. [18, S.12]

Durchsetzen einer Policy

Es soll möglich sein, gewisse Richtlinien durchzusetzen, Z.B. ausschließlich Schlüssel ei­ner bestimmten Länge werden angewandt oder wie die Identität bei der Vergabe eines neuen Zertifikats festgestellt wird. Diese Vereinbarungen werden in einer Policy festge­halten. Eine Zertifizierung einer solchen Policy, etwa durch das Bundesamt für Sicherheit in der Informationstechnik (BSI), kann hierbei Gewissheit über die Rechtsverbindlichkeit schaffen. [9]

Verbindlichkeit

Der Begriff Verbindlichkeit bringt zum Ausdruck, dass keine Möglichkeit besteht, nach einer Authentisierung die ausgewiesene Identität anzufechten. [16, S.570]

Bewertung Direct Trust

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Bewertung Direct Trust [17, s.565-566]

Bewertung Web of Trust

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.2: Bewertung Web of Trust [17, S.567]

Bewertung Hierachical Trust

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.3: Bewertung Web of Trust [17, S.568]

3.7 Resümee

Ein wichtiger Aspekt ist die Anwendung einer rechtsverbindlichen Policy, da die Vergabe der Zertifikate auf Grundlage der Identitätsprüfung beruht. Folgendes Beispiel soll die hierbei entstehende Problematik verdeutlichen.

Beispiel: Der Personalausweis einer Person wird ungültig, woraufhin diese einen Neuen bei der zuständigen Gemeinde beantragt. Die Vertrauenswürdigkeit der Person stellt hierbei keine Rolle, ergo auch Kriminelle bekommen einen Personalausweis!

Dieser Vorgang kann gleichgesetzt werden mit der Vergabe von Zertifikaten bei Hierachical Trust. Womit die Gefahr besteht, dass der Verantwortliche einer CA nicht vertrauenswiir- dig agiert. [15]

Bei Betrachtung der einzelnen Vertrauensmodelle, unter dem Aspekt der fest gelegten Kri­terien, kann die Aussage getroffen werden, dass Hierachical Trust, dass wohl geeignetste Modell darstellt. Daher wird im Anschluss, die zum Betrieb dieses Modells nötige Infra­struktur, anhand des Aufbau eines Trust Centers erläutert.

4 Funktionsweise einer PKI

4.1 Abgrenzung Trust Center und CA

Häufig findet man in der Literatur sowohl den Begriff TC, als auch den der CA. Beide Bezeichnungen sind ein Synonym für eine Zertifizierungsinstanz, wobei es sich bei ei­nein TC zumeist um eine baulich besonders gesicherte Einrichtung handelt. Dies kann beispielsweise durch Zugangskontrollen, Alarmanlagen oder Verwendung von besonderen Baumaterialien realisiert sein. Interessant ist hierbei, dass der Begriff TC eine rein deut­sehe Bezeichnung ist, welche im englischsprachigen Raum kaum bis gar keine Verwendung findet.[17, S.575]

4.2 Aufbau eines Trust Centers

Ein TC stellt eine unabhängige Instanz dar, welche die Signatur der Zertifikate über­nimmt. Zudem stellt das TC wichtige und optionale Infrastruktur-Komponenten, sowie Dienste in einer PKI bereit. Daher wird es in der Literatur auch als Trusted Third Par­ty (TTP) benannt. Um einen reibungslosen Arbeitsablauf in einem TC zu gewährleisten, empfiehlt es sich, dieses in die nachfolgenden Komponenten zu unterteilen. Dies bringt zudem den Vorteil, dass Aufgabenbereiche in Form von Rollen erstellt werden können, welche meist nur einen Teil der Berechtigungen innerhalb des Trust Centers benötigen und beugt somit eventuellen Missbrauch oder Manipulationen vor. [18, s.21-22] 4.2.1 Graphische Veranschaulichung

Abbildung in dieser Leseprobe nicht enthalten

Die Zertifizierungsstelle (ZS) stellt die beantragten Zertifikate aus. Je nach Angebot des Betreibers und Kundenwunsch, generiert sie unter Zuhilfenahme eines Schlüsselgenerators auch den Private und Public Key des zu Zertifizierenden. Falls Z.B. die Zertifikate zur verschlüsselten Datenspeicherung genutzt werden, kann es auch sinnvoll sein, den Private Key in diesem Schritt in einer Datenbank zu hinterlegen, um zu einem späteren Zeitpunkt Key Recovery durchführen zu können. [18, s.23][17, S.576]

4.2.3 Registration Authority (RA)

Eine Registration Authority (RA) nimmt alle Anträge auf Zertifizierung entgegen. Da­bei stellt sie die Identität der zu zertifizierenden Person sicher. Dies kann beispielsweise durch persönliches Vorsprechen oder Postident-Verfahren geschehen. Abhängig von den angebotenen Diensten und dem Kenntnisstand der zu zertifizierenden Person, kann die RA bei der Antragstellung unterstützen oder auch bereits generierte Anfragen, welche Z.B. mittels OpenSSL oder Keytool erstellt wurden, entgegennehmen. Ein Beispiel für das Erstellen einer solchen Anfrage wäre wie folgt möglich.

1 openssl req -new -nodes -out req.pem

Hierbei wird optimalerweise auch geprüft, ob alle Eingaben valide sind. Alle relevanten Daten werden dann an die ZS weitergegeben. Die RA ist eine optionale Komponente des Trust Centers und kann auch als Teilaufgabe in der ZS angesiedelt werden. Jedoch kann es auch mehrere RAs zu einer ZS geben, Z.B. als Außenstellen, um das persönliche Vorsprechen regional zu ermöglichen.[18, s.22][17, S.579]

4.2.4 Zertifikatserver / Certificate Repository

Ein Certificate Repository (CR) beinhaltet von der CA signierte Zertifikate und ermög­licht allen Teilnehmern den Abruf der Zertifikate zur Prüfung. Somit wird eine gewisse Sicherheit, was die Aktualität der Zertifikatsinformationen betrifft, gewährleistet. Zu­dem werden Sperrfisten verwaltet, welche ungültig Zertifikate kennzeichnen, dies kann beispielsweise durch das Bekanntwerden des Private Keys vonnöten sein.[18, s.23][17, s.577-578]

4.2.5 Time Stamp Authority (TSA)

Aufgabe einer Time Stamp Authority (TSA) ist es, ein gemeinsames Verständnis der Zeit zwischen Nutzern zu schaffen. Erfolgt bei digitalen Signaturen ein Widerruf eines Zertifi­kats, so gilt es zu wissen, welche Transaktionen vor und welche nach dem Widerruf gesell­allen. Dies ist notwendig, da sichergestellt werden soll, wem eine Transaktion zuzuordnen ist. Hierzu wird mit der TSA eine vertrauenswürdige Instanz geschaffen, welche Signatu­ren mit Zeitstempeln versieht und somit einen klaren zeitlichen Ablauf gewährleistet. [17, s.578-579]

4.2.6 Personal Security Environment (PSE)

Eine Personal Security Environment (PSE) beinhaltet die Zertifikate und Private Keys eines Nutzers, dies kann beispielsweise mit Chipkarten, USB-Tokens oder auch Softwa­recontainer (sogenannte Soft PSE) gelöst werden. Doch beschränkt sich die Funktionali- tat nicht nur auf das Speichern der Zertifikate und Private Keys, darüber hinaus kann auch der kryptographische Prozess selbst aus Performancegründen an die PSE ausgelagert werden. Hierzu werden Hardware Security Module (HSM) verwendet, über eine geeigne­te Schnittstelle werden die Daten dem HSM übergeben, welches dann autonom Z.B. die Signatur oder Verschlüsselung übernimmt. [18, s.23][17, s.580-582]

4.3 Darstellung der Funktionsweise

Die Darstellung der Zusammenarbeit aller Komponenten soll im Folgenden die Funktion der PKI verdeutlichen. Hierzu wird folgendes Szenario angenommen:

Die Firma Mustermann möchte gerne eine Webseite betreiben, über die ein Online Shop eingebunden sein soll. Um die Zugangsdaten der Nutzer zu schützen und damit Manipula­tionen durch Dritte zu vermeiden, entschließt sich der Verantwortliche https zu verwenden. Er beantragt bei einem TC seiner Wahl ein Zertifikat. Da er technisch versiert ist und den Java Keystore verwenden möchte, erstellt er hierzu eine Certificate Request mit Keytool. Dabei verbleibt der Private Key der Firma direkt in dem Keystore, welcher die PSE dar­stellt. Mit dem erzeugten Certificate Request und passenden Ausweisdokumenten wird er bei der RA vorstellig, welche seine Identität verifiziert und den Certificate Request auf Korrektheit überprüft. Anschließend übergibt die RA die Anfrage an die ZS. Diese stellt nun das Zertifikat aus, welches mit dem Private Key der ZS signiert ist. Danach erfolgt eine Eintragung im CR, um allen Teilnehmern den Abruf des Zertifikats zur Prüfung zu ermöglichen, sowie die Übergabe des Zertifikats selbst an den Verantwortlichen der Firma Mustermann. Dieser hinterlegt nun das erhaltene Zertifikat im Keystore, damit es von der Java Applikation verwendet werden kann. Nach der Inbetriebnahme des Systems, besucht nun ein Benutzer die Webseite der Firma Mustermann. Der Server der Firma Mustermann sendet ihm hierbei das verwendete Zertifikat. Da der Benutzer ein Root Certifikat ver­wendet, welches die CA des verwendeten Trust Centers beglaubigt, vertraut er nun auch der Firma Mustermann.

Um den Widerruf von validen getätigten Transaktionen zu verhindern, fordert ein Zu­lieferer der Firma Mustermann, dass Bestellungen signiert und mit einem Zeitstempel einer TS A versehen werden müssen. Der Verantwortliche der Firma Mustermann kann die entsprechenden Dokumente ebenfalls mit dem ausgestellten Zertifikat signieren und mit einem Zeitstempel seiner TSA versehen lassen. Kommt es zu einem Verlust des Priva­te Keys, Z.B. weil das Firmennetz kompromittiert wurde, so teilt die Firma Mustermann dies, im besten Fall unverzüglich, dem TC mit, welches dann im CR einen entsprechenden Eintrag in der Sperrliste vornimmt und somit das Zertifikat als ungültig erklärt.

5 Angriffsvektoren auf eine PKI

5.1 Einführung

Abschließend sollen mögliche Angriffsvektoren und Schwachstellen einer PKI aufgezeigt werden.

5.2 Hash Kollisionen

Wie in Abschnitt 2.3.1 erwähnt, wird zur Signatur des Zertifikats ein Hashwert über den Inhalt gebildet, welcher anschließend mit dem Private Key der CA verschlüsselt wird und somit die Echtheit des Zertifikats bestätigt. Daraus folgt: besäße man ein Zertifikat, wel­ches den gleichen Hashwert besitzt wie ein bereits von einer CA signiertes, so kann die Signatur kopiert werden und beglaubigt damit ein zweites Zertifikat. Da Hashfunktionen immer auf eine gewisse Ausgabelänge beschränkt sind, folgt zudem, dass bei beliebiger Eingabe zwangsläufig Kollisionen auftreten können. Abhängig von dem verwendeten Al­gorithmus, können diese mehr oder weniger zielgerichtet herbeigeführt werden. [19] [20]

5.3 Berechnung von Private Keys

Wird versucht, den Private Key eines Teilnehmers oder einer CA zu errechnen, kann der verwendete Schlüsselgenerator hierbei einen möglichen Angriffsvektor darstellen. Werden etwa die Schlüssel nicht so zufällig generiert wie angedacht, so kann dies den Brute Forcing Prozess erheblich beschleunigen. Bei Anwendung guter Generatoren und ausreichender Schlüssellängen, ist der Aufwand den Schlüssel zu errechnen für die derzeit verwendeten Techniken sehr hoch, jedoch könnte dies, etwa durch neue Technologien Z.B. Quanten­computer Technik, in Zukunft stemmbar sein. [2]

5.4 Verlust des Private Keys

In Hinsicht auf die PSE spielen auch konventionelle Hacking Methoden, wie Trojaner oder Socialengineering eine Rolle. Durch genannte Techniken, kann es einem Angreifer durchaus gelingen an den Private Key zu gelangen.

5.5 Import von unglaubwürdigen Zertifikaten

Nur selten werden die verwendeten Zertifikate überprüft. So ist es durchaus denkbar, dass bei der Installation eines neuen Browsers oder auf Rechnern vorinstallierter Softwa­re, Zertifikate enthalten sind, welche Dienste beglaubigen denen wir gar nicht vertrauen möchten. Auch ein Angreifer könnte bei Zugriff auf einen Rechner ein solches Zertifikat hinterlegen. [11, S.7]

5.6 Kompromittierung eines Trust Centers

Einer der schwerwiegendsten Angriffsvektoren stellt die Kompromittierung eines Trust Centers dar. Dies kann Z.B. durch mutwilliges Handeln einzelner Personen innerhalb des Trust Centers geschehen. Eine verbindliche Policy und Aufteilung der Kompetenzen inner­halb des Trust Centers, können dem zumindest teilweise entgegenwirken. Doch auch die Berechnung oder der Verlust des Private Keys, können als Angriffsvektoren genutzt wer­den. Besonders verlierend ist hierbei, dass durch die Kompromittierung eines Trust Cen­ters die Vertrauenskette sehr vieler Teilnehmer, gegebenenfalls vollkommen unbemerkt, gebrochen wird. [15]

5.7 Resümee

Trotz der Schwächen, welche bei der Verwendung einer PKI existieren, sollten heutzutage verschlüsselte Verbindungen im World Wide Web der Normalfall sein, um eine Manipula­tion unseres Wissens vorzubeugen. Dies hat sich unter anderem die gemeinnützige Internet Security Research Group (ISRG) zur Aufgabe gemacht. Konkret wurde hierzu eine CA namens Let’s Encrypt eingerichtet, welche es jedem ermöglicht sich kostenlos zertifizieren zu lassen. [12]

Literaturverzeichnis

[1] r. V. . 126 and D. Cooper. Internet X.509 public key infrastructure certificate and certificate revocation list (cri) profile, 2008. URL https://tools.ietf.org/html/ rfc5280. Zuletzt zugegriffen am 03.04.2018. 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1

[2] H. Böck. Quantencomputer: Das ende von rsa und CO., 2014. URL https ://www. golem.de/news/quantencomputer-das-ende-von-rsa-und-co-1401-103697. html. Zuletzt zugegriffen am 19.06.2018. 5.3

[3] T. Brand, s. Groß, I. Geis, B. Lindgens, and B. Zöller. Steuersicher archivieren. Gabler Verlag, 2011. 2.4

[4] A. Czernik. Authentisierung, authentifizierung und autorisierung,

2016. URL https://www.datenschutzbeauftragter-info.de/

authent is ierung-aut hent if izierung-und- autorisierung/. Zuletzt zugegriffen am 15.06.2018. 3.6

[5] C. Eilers. Kryptographie - identitätspriifung, teil 3 - hier­archische Zertifizierungssysteme, 2016. URL https ://www.

ceilers-news.de/serendipity/795-Kryptographie-Identitaetspruefung, -Teil-3-Hierarchische-Zertifizierungssysteme.html. Zuletzt zugegriffen am 07.06.2018. 3.5.2

[6] w. Ertel. Angewandte Kryptographie. Hauser, 2012. 3.4

[7] Z. D. Fernsehen. Glaubwürdigkeit verschiedener medien, 2016. URL https ://www. zdf.de/zdfunternehmen/angebote-112.html. Zuletzt zugegriffen am 04.06.2018. 1.1

[8] D. Fox. E-mail-sicherheit kriterien, standards und lösungen. Datenschutz und Da­tensicherheit - DuD 25, 2001. 2.2

[9] В. für Sicherheit in der Informationstechnik. Sicheres e-government, 2018. URL https ://www.bsi.bund.de/DE/Themen/DigitaleGesellschaft/EGovernment/ VerwaltungsPKIVPKI/Wurzelzertifizierungsstelle/CertificatePolicy/ certificatepolicy_node.html. 3.6

[10] B. für Sicherheit in der Informationstechnik. Teletrust european bridge-ca, 2018. URL https ://www.bsi.bund.de/DE/Themen/DigitaleGesellschaft/EGovernment/ VerwaltungsPKIVPKI/EuropeanBridgeCA/europeanbridgeca_node.html. 3.5.4

[11] J. Harrie. Man-in-the-middle angriffe auf internetkommunikation, 2014. URL https ://www.cdc.informatik.tu-darmstadt.de/fileadmin/user_upload/ Group_CDC/Documents/Lehre/SS13/Seminar/CPS/cps2014_submission_3.pdf.

Zuletzt zugegriffen am 04.07.2018. 1.1, 2.1, 5.5

[12] s. R. G. (ISRG). How it works, 2018. URL https://letsencrypt.org/ how-it-works/. Zuletzt zugegriffen am 25.06.2018. 5.7

[13] C. it Security GmbH. X.509 Zertifikate, 2018. URL https://www.cryptas.com/ cryptas/wissen-unterstuetzung/pki-grundlagen/x509־zertifikate.html.

Zuletzt zugegriffen am 03.04.2018. 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1

[14] Marcus Blomenkamp, Ralf Brand, Dennis Cieplik. Kryptographie und siche­re kommunikation in heterogenen netzwerken: Ipsec, 2002. URL https ://www. techfak.uni-bielefeld.de/~walter/vpn/ch08s02.html. Zuletzt zugegriffen am 25.06.2018. 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1, 2.3.1

[15] D. Schirrmacher. Ssl-zertifizierungsstellen stellen hunderte Zertifikate für phishing-seiten aus, 2015. URL https://www.heise.de/security/meldung/ SSL-Zertifizierungsstellen-stellen-hunderte-Zertifikate-fuer-Phishing-Seiten html. Zuletzt zugegriffen am 20.06.2018. 3.7, 5.6

[16] K. Schmeh. Kryptografie, dpunkt.verlag, 2007. 1.3, 3.5, 3.5.1, 3.5.3, 3.6

[17] К. Schmeh. Kryptografie Verfahren, Protokolle, Infrastrukturen, dpunkt.verlag, 2016.

2.2, 3.3, 3.1, 3.2, 3.3, 4.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.6

[18] p. Seiler. Konzept und Auflau einer prototypiechen Piiblic Key Infrastruktur auf Basis von FlexiTrust. Diplomarbeit, Technische Universität Darmstadt, Darmstadt, 2001. Zuletzt zugegriffen am 03.04.2018. 1.3, 2.1, 2.2, 3.3, 3.4, 3.5, 3.5.1, 3.6, 3.6, 4.2, 4.2.2, 4.2.3, 4.2.4, 4.2.6

[19] M. Stevens, A. Lenstra, and B. de Weger. Chosen-prefix collisions for md5 and colliding X.509 certificates for different identities. In M. Naor, editor, Advances in Cryptology - EUROCRYPT 2007, volume 4515 of Lecture Notes in Computer Science, pages 1-22, Berlin, 2007. Springer Verlag. 5.2

[20] w. Xiaoyun and Y. Hongbo. How to break md5 and other hash functions. In R. Cramer, editor, Advances in Cryptology - EUROCRYPT 2005, pages 19-35, Ber­lin, Heidelberg, 2005. Springer Berlin Heidelberg. ISBN 978-3-540-32055-5. 5.2

Details

Seiten
30
Jahr
2018
ISBN (Buch)
9783668800885
Sprache
Deutsch
Katalognummer
v441443
Institution / Hochschule
Hochschule für angewandte Wissenschaften Kempten
Note
1,3
Schlagworte
zertifikate PKI Vertrauensmodelle Angriffsvektoren auf eine PKI Funktionsweise einer Public Key Infrastruktur Public Key Infrastruktur Public Key Infrastrukturen Trust Center CA Certification Authority X.509 RFC 5280

Autor

Teilen

Zurück

Titel: Aufbau und Funktion von Public Key Infrastrukturen