Vertiefung Verteilte Systeme SS Eine PKI - Infrastruktur auf Basis von LDAP und OpenCA. von Alexander Piel Matthias Gabel

Transkript

1 Eine PKI - Infrastruktur auf Basis von LDAP und OpenCA von Alexander Piel Matthias Gabel

2 Inhaltsverzeichnis 1 Einleitung 4 2 Grundlagen Public Key Infrastruktur Allgemeines Geschichte Funktionsweise Digitale Signaturen Vor- und Nachteile Einführung einer Zertifizierungsstelle (CA) S/MIME Lightweight Directory Access Protocol Allgemeines Datenaufbau OpenCA Analyse und Design Allgemein OpenCA und LDAP gekoppelt Funktionsweise Nachteil dieses Szenarios Kommunikation über LDAP

3 3.3.1 Funktionsweise Nachteile dieses Szenarios OpenCA und LDAP getrennt Funktionsweise Hinführende Aufgaben Aufgaben Implementierung Installation von OpenCA und LDAP Einleitung Installation von OpenCA Konfiguration von OpenCA LDAP - Installation und Konfiguration Kommunikation mit dem LDAP - Server Ver- und Entschlüsselung Bearbeitung der vorgestellten Aufgaben Erzeugung eines Wurzelzertifikates Überprüfen und Anzeigen des Zertifikats Request erzeugen Request ansehen Request bearbeiten und signieren Überprüfen des Zertifikats Konvertieren in pkcs#

4 4.4.8 Import des Zertifikats in Firefox und Thunderbird Verifizieren des Zertifikats E - Mail versenden und empfangen Automatisierte Erstellung einer S/MIME - Mail Vorbereitung Das Programm generate Das Programm smime verschlüsseltes Multiuser Chat System Grundlagen Funktionsweise Benutzung des server Programms Programmaufbau des server Programms Das client Programm Zusammenfassung Kapitelzusammenfassung Bewertung Ausblick Literatur 48 3

5 1 Einleitung Heutzutage, wo immer mehr wichtige Dokumente und wichtige Daten über das Internet versandt werden, wird es immer wichtiger, sich gegen unathentifizierte Zugriffe abzusichern. Wichtige Bank- oder Kundendaten von Firmen oder Privatleuten, Geschäftsvorgänge oder natürlich auch militärische Informationen müssen vor dem öffentlichen Zugriff geschützt werden. Hier kommt die Kryptographie zum Einsatz. In sehr vielen Bereichen der virtuellen Kommunikation wird heutzutage Verschlüsselung angewandt. Diese Verschlüsselungsverfahren sind natürlich immer mit der Verwaltung und Speicherung von Schlüsseln verbunden, was einen hohen Verwaltungsaufwand als Resultat haben kann. Dieses Projekt der Vertiefungsveranstaltung Verteilte Systeme setzt sich u.a. mit diesem Thema der verschüsselten Kommunikation auseinander. Das Projekt hat das allgemeine Ziel, eine verschlüsselte und somit sichere Kommunikation zwischen zwei oder mehreren Klienten zu ermöglichen. Um die Kosten der Schlüsselverwaltung möglichst gering zu halten, soll das Verfahren der Private/Public - Key Verschlüsselung als Basis für die Kommunikation dienen. Das Konzept einer Public - Key - Infrastruktur (PKI) wird also angewandt und umgesetzt. Die Schlüsselverwaltung wird von einem zentralen LDAP - Server übernommen, welcher von allen Klienten erreicht werden kann. Des weiteren wird eine Zertifizierungsstelle (Cetrification Authority CA) eingeführt, welche bestätigt, in Form eines Zertifikats, dass ein Klient A wirklich mit dem gewünschten Klienten B kommuniziert. Als Zertifizierungsstelle wird hier OpenCA eingesetzt. Dies ist eine Open - Source Zertifzierungsstelle, welche alle nötigen Funktionen zur Zertifikatsverwaltung bereitstellt. 4

6 2 Grundlagen 2.1 Public Key Infrastruktur Allgemeines Die Public Key Infrastruktur ist auf einem asymmetrischen Verschlüsselungsverfahren aufgebaut. Dies bedeutet, dass jeder Teilnehmer einer Kommunikation zwei verschiedene Schlüssel benötigt. Ein solches Schlüsselpaar besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel eines jeden Teilnehmers muss unbedingt geheim gehalten werden und darf nur dem zugehörigen Klienten bekannt sein. Hiervon ist die Sicherheit des Verschlüsselungssystems abhängig. Der öffentliche Schlüssel wiederum wird in einem öffentlich zugänglichen Bereich abgelegt. Auf diesen können alle Teilnehmer zugreifen. Anders als in einem symmetrischen Verschlüsselungssystem müssen sich die Teilnehmer der Kommunikation keinen gemeinsamen geheimen Schlüssel merken Geschichte Im Vergleich zu der symmetrischen Verschlüsselung ist die asymmetrische Verschlüsselung noch ein sehr junges Teilgebiet der Kryptographie. Während es die symmetrische Verschlüsselng schon zu Zeiten von Caesar gab, existiert die Idee der asymmetrischen Verschlüsselungssysteme erst seit ungefähr 30 Jahren. Die Grundlagen für asymmetrische Verschlüsselungsverfahren wurden vor allem von Diffie, Hellmann und Merkle gelegt. Diffie und Hellmann entwickelten viele Ideen und Prinzipien der asymmetrischen Verschlüsselung, erwähnten in ihrer Veröffentlichung im Jaher 1975 jedoch noch kein exaktes Verfahren. Als im Jahre 1977 von Ronald L. Rivest, Adi Shamir und Leonard M. Aldeman das RSA - Verfahren entwickelt wurde, begann die eigentliche Erfolgsgeschichte der asymmetrischen Verschlüsselungsverfahren. Auch heute noch findet das RSA - Verfahren seine Einsatzgebiete Funktionsweise Will ein Teilnehmer mit einer anderen Person verschlüsselt kommunizieren, so muss er sich zunächst ein Schlüsselpaar generieren oder generieren lassen. Ein solches Schlüsselpaar besteht aus zwei unterschiedlichen, mathematisch verwandten Schlüsseln. Aus der Kenntniss des einen Schlüssels (des Public Keys) darf man den anderen Schlüssel nicht ermitteln können. Um ein solches Schlüsselpaar zu erzeugen werden mathematische Einwegfunktionen verwendet. Darunter versteht man beispielsweise, dass es sehr einfach ist zwei Primzahlen A und B miteinander 5

7 zu multiplizieren und so eine dritte Primzahl C zu erhalten. Aus dieser dritten großeren Primzahl wieder die die beiden Faktoren A und B zu ermitteln ist sehr schwierig. Hierfür gibt es noch kein zuverlässiges und schnelles Verfahren, wenn man die Primzahlen A und B groß genug wählt. Wurde nun dieses Schlüsselpaar erzeugt, so wird einer der beiden Schlüssel (der sogenannte Public Key) öffentlich bekannt gegeben, der andere (Private Key) wird geheim gehalten. Der Sender verschlüsselt nun die zu sendende Nachricht mit Hilfe des öffentlichen Schlüssels des Empfängers. Wurde die Nachricht einmal damit verschlüsselt, so kann sie nur noch von dem Besitzer des Privaten Schlüssels in Klartext umgewandelt werden. Da diesen privaten Schlüssel im Regelfall nur der gewünschte Empfänger der Nachricht kennt, kann auch nur dieser die Nachricht entschlüsseln. Abbildung 1 veranschaulicht das Funktionsprinzip sehr gut. Wir haben hier zwei Teilnehmer, Bob und Alice. Beide generieren sich ein Schlüsselpaar und legen ihren öffentlichen Schlüssel in einem Verzeichnis ab, welches für den anderen zugänglich ist. Will nun Bob eine Nachricht an Alice senden, so verschlüsselt er diese mit dem öffentlichen Schlüssel von Alice, welchen er sich aus dem öffentlich zugänglichen Verzeichnis holt. Alice entschlüsselt die erhaltene Nachricht später mit ihrem privaten, geheimen Schlüssel, welchen sie sich gemerkt hat und geheim hält. Abbildung 1: Public Key Schlüsselverwaltung 6

8 2.1.4 Digitale Signaturen Digitale Signaturen sind kryptografische Verfahren, um die Integrität 1 einer Nachricht sicher zu stellen. Man kann sich eine digitale Signatur wie eine Unerschrift vorstellen, welche als Bit - String an das zu sendende Dokument angehängt wird. Um eine digitale Signatur erzeugen zu können, muss ein asymmetrisches Verschlüsselungsverfahren (z.b. RSA) verwendet werden. Bei der Erzeugung einer digitalen Signatur, wird zunächst mittels einer Hash - Funktion ein Zahlenwert erzeugt, welcher alle Details der Nachricht enthält. Die Nachricht wird sozusagen auf diesen Hashwert komprimiert. Wichig dabei ist, dass eine kollisionfreie Hash - Funktion (z.b. SHA-1) gewählt wird, also eine Funktion bei welcher ein bestimter Hash - Wert niemals doppelt auftreten kann. Dieser muss immer eindeutig sein. Die Signatur einer Nachricht ist dann der mit dem privaten Schlüssel des Senders verschlüsselte Hashwert der Nachricht. Diese erzeugte digitale Signatur wird zusammen mit dem Zertifikat des Senders an die Nachricht angehängt und mit dieser verschickt. Der Empfänger kann die Signatur nun mit seinem öffentlichen Schlüssel des Senders, welchen er aus dem angehängten Zertifikat bekommt, entschlüsseln. Als zweiten Schritt, errechnet der Empfänger selbst erneut mit derselben Hash - Funktion, welche auch zuvor der Sender verwendet hat, den Hashwert der Nachricht. Diesen selbst errechneten Wert vergleicht er mit dem mitgeschickten Hashwert des Senders. Stimmen beide überein, so kann sich der Empfänger sicher sein, dass die Nachricht unterwegs nicht manipuliert wurde. Die Integrität der Nachricht ist sichergestellt. Der Ablauf dieser Hashwert - Bildung und der Signierung der Nachricht ist auf der folgenden Abbildung noch einmal verdeutlicht dargestellt. 1 Integrität einer Nachricht: Garantie, dass diese Daten nicht unauthorisiert und unbemerkt manipuliert, sondern genau so vom Sender abgeschickt wurden 7

9 Abbildung 2: Signaturbildung Vor- und Nachteile Das Public - Key - Verfahren hat als großen Vorteil vor allem die hohe Sicherheit: Nur der Empfänger der Nachricht besitzt den privaten Schlüssel. Somit besitzt nur diese eine Person das Geheimnis und nur sie ist angreifbar. Es sind keine Übertragung von privaten Schlüsseln über ungesicherte Kanäle notwendig. Die zeitliche Entschlüsselung einer Nachricht, ohne das der private Schlüssel bekannt ist, ist nicht möglich. Auch wenn es dafür Verfahren gibt, das Verschlüsselungsverfahren ist zu stark und das Knacken der Verschlüsselung würde mehrere Jahre beanspruchen. Nach einer solchen Zeit ist es nicht mehr weiter wichtig ob die Information geheim bleibt, da deren Aktualität nicht mehr gegeben ist. 8

10 Doch auch dieses Verfahren hat einige Nachteile, welche im folgenden kurz aufgeführt werden: Asymmetrische Verschlüsselungsverfahren sind langsamer als symmetrische Verfahren. Eine Man - in - the - Middle Attacke wäre denkbar. Hierbei positioniert sich ein Angreifer genau zwischen Sender und Empfänger. Fragt der Sender nun den Empfänger nach dessen Public Key, so fängt der Angreifer diese Anfrage ab und sendet seinen eigenen Public Key zurück. Der Sender verschlüsselt damit die geheime Nachricht, in dem Glauben nur der gewünschte Empfänger könnte sie lesen. Der Angreifer empfängt die Nachricht, entschlüsselt sie mit seinem privaten Schlüssel, verschlüsselt sie wieder mit dem öffentlichen Schlüssel des eigentlichen Empfängers und leitet sie dann an diesen weiter. Somit merken beide Kommunikationspartner nichts davon, dass ihre Nachricht von einem dritten mitgelesen wurde. Es muss also sichergestellt sein, dass der erhaltene öffentliche Schlüssel wirklich vom gewünschten Empfänger stammt. Um dies sicherzustellen gibt es so genannte Zertifizierungsstellen. Will man eine Nachricht an mehrere Empfänger senden, so muss diese mit dem öffentlichen Schlüssel eines jeden Epmfängers verschlüsselt werden Einführung einer Zertifizierungsstelle (CA) Das im vorherigen Abschnitt angesprochene Problem der Man - in - the - Middle Attacke lässt sich mit Hilfe von neutralen Zertifizierungsstellen beheben. Der Empfänger Alice holt sich also den öffentlichen Schlüssel nicht direkt vom Sender Bob, sondern lässt sich diesen von der sogenannten Certification Authority (CA) ausliefern. Diese neutrale und vertrauenswürdige Zertifizierungsstelle stellt also quasi ein Zertifikat darüber aus, dass der öffentliche Schlüssel wirklich zu dem gewünschten Teilnehmer gehört. Einer solchen CA muss man natürlich vertrauen. Aus diesem Grund gibt es wieder höhergestellt Zertifizierungsstellen, bei welcher sich eine CA wiederum registrieren und sich ein Zertifikat ausstellen lassen kann. So entsteht eine Vertrauenskette zwischen den einzelnen CAs, an deren Spitze die sogenannte Root - CA steht. Die Man - in - the - Middle Attacke würde nach diesem Funktionsprinzip jedoch noch immer funktionieren, indem sich der Angreifer sowohl als Empfänger, als auch als Trust Center ausgeben würde. Dem kann man jedoch entgegen wirken, indem man annimmt, dass der öffentliche Schlüssel der CA jedem bekannt ist. Fragt nun Alice die Zertifizierungsstelle nach dem öffentlichen Schlüssel des Empfängers Bob, so wird die Antwort der CA, also der öffentliche Schlüssel von Bob, mit dem privaten Schlüssel der Zertifizierungsstelle verschlüsselt. Der Empfänger 9

11 Alice kann nun diese Nachricht mit dem ihr bekannten öffentlichen Schlüssel der CA entschlüsseln und erhält so den öffentlichen Schlüssel des Senders Bob. Ist die Nachricht nicht mit dem privaten Schlüssel der CA verschlüsselt worden, so kommt eine falsche Nachricht heraus und die Kommunikation kann nicht korrekt stattfinden. Die Nachricht der CA ist ein sogenanntes Zertifikat und es bestätigt die Authentizität und Integrität des verschlüsselten öffentlichen Schlüssels. Die Struktur solcher Zertfikate wurde von verschiedenen Stellen (z.b. ITU X.509) entworfen. Beispielsweise können in einem Zertifikat folgende Elemente enthalten sein: eindeutige Identifikationsnummer des Zertifikats Name des Inhabers des Zertifikats Name der Zertifizierungsinstanz Gültigkeitszeitraum öffentlicher Schlüssel des Zertifikatinhabers digitale Signatur der Zertifizierungsinstanz 10

12 2.2 S/MIME S/MIME steht für Secure/Multipurpose Internet Mail Extensions und kann für eine sichere Kommunikation mittels E - Mails dienen. Das System gilt als der Standard für die Verschlüsselung und Signierung von E - Mails und wird von den meisten gängigen Mail Applikationen unterstützt. S/MIME kann sowohl auf symmetrischen, als auch auf asymmetrischen Verschlüsselungsverfahren aufsetzen. Hier soll nun im Weiteren jedoch nur auf die Verwendung von asymmetrischen Verschlüsselungsverfahren näher eingangen werden. Bei asymmetrischen Verschlüsselungsverfahren stützt sich S/MIME auf die Public Key Cryptographic Standards (PKCS). Beispielsweise das RSA- oder das Diffie - Hellmann - Verfahren sind Bestandteile der PKCS, welche Standards für die asymmetrische Verschlüsselung festlegen. In diesen werden des Weiteren noch Standards für das Signieren von Daten festgelegt. Auf dieser Basis aufbauend empfiehlt S/MIME das RSA - Verfahren zur Verschlüsselung. Als weiteres sollten sowohl Sender als auch Empfänger RSA - Signaturen und RSA - Verschlüsselungen mit einer Schlüssellänge zwischen 512 und 1024 Bit verifizieren und verwenden können. In S/MIME sind zwei sogenannte Content Types definiert. Es wird zwischen Multipart/Signed und Multipart/Encrypted unterschieden. bei dem Multipart/Signed - Format enthält eine Mail genau zwei Blöcke. In dem ersten Abschnitt steht die eigentliche unverschlüsselte Nachricht und der zweite Block enthält die Signatur, welche in den meisten Mail Applikationen (z.b. Mozilla Thunderbird) eine PKCS#7 - Signatur ist. Mails, die in diesem Format versandt werden, können von allen Mail Applikationen gelesen werden, auch von denen die kein S/MIME unterstützen. Das zweite Multipart/Encrypted - Format verwendet den ersten Teil einer Mail um Informationen über die Verschlüsselung zu vermitteln im zweiten Block ist die verschlüsselte Nachricht enthalten. Solche Nachrichten können nur von Mail Applikationen entschlüsselt angezeigt werden, die den S/MIME Standard verwenden. Hierzu muss dem Empfänger natürlich der öffentliche Schlüssel des Senders bekannt sein. Besitzt ein Klient A ein Zertifikat eines anderen Klienten B, so kann er diesem eine verschlüsselte Nachricht senden. Hierzu verschlüsselt er die Nachricht mit dem öffentlichen Schlüssel des des Klienten B, welcher im Zertifikat enthalten ist. Der Empfänger B kann die Nachricht dann mit seinem eigenen privaten Schlüssel entschlüsseln. Nur der Besitzer des privaten Schlüssels (hier B) kann die Nachricht somit lesen. 11

13 2.3 Lightweight Directory Access Protocol Allgemeines Das Leightweight Directory Access Protocol, kurz LDAP, ist ein Verzeichnisdienst. Es ist ein offener Standard für einen Informationsdienst auf Basis einer baumähnlichen Datenbankstruktur. Gegenüber einer normalen Datenbank ist der Hauptvorteil die attributsbezogene Speicherung. LDAP ist aus X.500DAP entstanden, benutzt aber statt des OSI - Stacks den TCP/IP - Stack. Ein LDAP - Server könnte beispielsweise Personendaten oder ähnliches enthalten, auf welche dann vom Klienten aus über eine Abfrage zugegriffen werden kann Datenaufbau Im LDAP - Datenaufbau definiert eine Objektklasse eine Sammlung aus verschiedenen Attributen. Ein jedes Objekt wird durch den Distinguished Name (DN) identifiziert. Die Attribute eines solchen Objekts können dazu benutzt werden, einen Verzeichniseintrag zu beschreiben. Es existieren vordefinierte Objektklassen, die man für die Definition von Lokationen, Organisationen beziehungsweise Firmen, Personen oder Gruppen benutzen kann. Mittels einer Objektklasse lässt sich ein Eintrag erzeugen. Ein typischer Eintrag in einen LDAP- Baum sieht etwa so aus: 1 cn=matthias Gabel, ou=it, o=mycompany, c=de Auf den ersten Blick ist zu erkennen, dass das LDAP - Konzept hierarchisch aufgebaut ist. In Form des DN liest es sich von rechts nach links, vergleichbar mit dem Aufbau des Domain Name Services im Internet. Wie bereits erwähnt, wird innerhalb eines DN mit Attributen gearbeitet. Oft gewählte Attribute im Standard - LDAP - Schema sind: Common Name (CN) Organizational Unit (OU) State (S) Country (C) Diese Attribute werden jeweils einer Objektklasse durch Definition zugeteilt. Häufig eingesetzte Objektklassen sind beispielsweise wieder Organization, organizationalunit, Person, organizationalperson und Country. Die definierten Objektklassen entscheiden darüber, was ein Eintrag 12

14 enthalten kann. Der Eintrag einer Person in den LDAP - Baum kann zum Beispiel die E - Mail Adresse oder den öffentlichen Schlüssel einer Person enthalten. 2.4 OpenCA OpenCA ist ein Open - Source Projekt und realisiert eine Zertifizierungsstelle. Dieses Modul kann unter kostenlos heruntergeladen werden. OpenCA benötigt folgende Software - Komponenten, um lauffähig zu sein: OpenLDAP OpenSSL Apache (wir benutzen Apache 2) Apache mod ssl MySQL Das OpenCA - Projekt ist wiederum in verschiedene einzelne Module aufgeteilt. Diese und die Arbeitsweise der wichtigsten Module sollen nun hier etwas genauer erläutert werden. Abbildung 2 auf der folgenden Seite gibt einen allgemein sehr guten Überblick über das Zusammenspiel der Module. All diese Module sind nach der korrekten Installation von OpenCA in dem Ordner /srv/www/htdocs zu finden und mit Hilfe eines Webbrowsers kann man auf das Webinterface eines jeden Moduls zugreifen (z.b. Die wichtigsten Module hier nun in einer Übersicht, mit einer kurzen Erklärung ihrer Arbeitsweise: PUB Über das PUB - Interface können Benutzer beispielsweise Zertifikate beantragen. Dieses Modul ist allgemein für die Erstellung und Bearbeitung der Zertifikate zuständig. Hier kommen Anfragen von Nutzern an und Zertifikate können neu erstellt, verwaltet oder gesucht werden. RA Das RA - Interface (Registration Authority) nimmt alle neuen Zertifikatsanträge entgegen. Diese werden dann an die CA weitergeleitet. Ebenso veröffentlicht die RA neue Zertifikate. 13

15 NODE Das NODE - Interface ist ein zentrales Bindeglied, worüber man alle anderen Schnittstellen der CA erreichen kann. Es gilt als Verbindung zwischen der Registration Authority und der Certification Authority. Des weiteren ist dieses Modul für die Initialisierung der Datenbank und wichtige Backupfunktionen zuständig. CA Die CA erstellt neue Zertifikate und ist sozusagen das Main - Modul einer Zertifizierungsstelle. Dieses Interface kann Zertifikate ausstellen, zurückrufen und CRLs erstellen. CRLs (Cerificate Revocaion List) sind Listen, welche Informationen darüber enthalten, welche Zertifikate noch gültig und welche bereits abgelaufen sind. BATCH Das BATCH - Interface ist eine Maschine, welche automatisch Schlüsselpaare, inklusive Zertifikaten generiert. Abbildung 3: Interner Modulaufbau von OpenCA 14

16 3 Analyse und Design 3.1 Allgemein Als Anwendungsbeispiel hatten wir uns zunächst zwei verschiedene Szenarien überlegt. Diese werden hier nun kurz vorgestellt und mit Vor- und Nachteilen erläuert für welches wir uns später entschieden haben. 3.2 OpenCA und LDAP gekoppelt Bei dem ersten praktischen Szenario wären die verschiedenen Module wie in der folgenden Abbildung miteinander verbunden: Abbildung 4: Erstes Konzept Das OpenCA und das LDAP - Modul sind hier über eine gemeinsame Schnittstelle miteinander verbunden. 15

17 3.2.1 Funktionsweise Als ersten Schitt registriert sich der Klient, welcher an der Kommunikaion teilnehmen möchte, bei der Zertifizierungsstelle (CA). Der Klient stellt die Anfrage auf eine Schlüsselgenerierung und sendet die nötigen persönlichen Daten mit, welcher später in seinem Zertifikat in der CA abgelegt werden. Die CA generiert daraufhin das Schlüsselpaar für diesen Klienten. Der öffentliche Schlüssel des Klienten wird im Verzeichnisdienst abgelegt und der private Schlüssel wird zurück an den Klienten gesendet. Vorraussetzung ist hier, dass die Kommunikation zwischen Klient und CA über einen gesicherten Kanal läuft, da der private Schlüssel des Klienten unbedingt geheim bleiben muss. Andernfalls ist die Sicherheit des kompletten Systems gefährdet. Nach der Registrierung zweier Klienten A und B kann sich beispielsweise der Klient B nun den öffentlichen Schlüssel von Klient A, mit Hilfe einer Anfrage an unsere Server - Schnittstelle, holen. Die Antwort des Servers wird hier mit dem öffentlichen Schlüssel von Klient B verschlüsselt. So kann nur B die Antwort des Servers entschlüsseln. Klient B kann nun eine Nachricht mit Hilfe des öffentlichen Schlüssels von A verschlüsseln und an Klient A senden. Klient A entschlüsselt diese Nachricht mit Hilfe seines privaten Schlüssels Nachteil dieses Szenarios Dieses Szenario wurde nicht von uns implementiert. Es hat nämlich einen sehr entscheidenden Nachteil. Zum einen ist ein Man - in - the - Middle Angriff leicht denkbar. Ein Angreifer könnte sich zwischen einen Klient und unseren Server stellen. Er würde sich somit gegenüber dem Klient als Zertifizierungsstelle ausgeben. Dann würde der Angreifer dem Klienten den öffentlichen Schlüssel von sich selbst mitteilen und der Klient wäre in dem Glauben, es wäre der Schlüssel des Klienten B, mit welchem er eigentlich kommunizieren möchte. So würde Klient A nichts ahnend seine Nachricht mit dem erhaltenen öffentlichen Schlüssel verschlüsseln und diese dann absenden. Der Angreifer würde sie abfangen, sich also auch als Empfänger (Klient B) ausgeben und könnte die Nachricht dann mit Hilfe seines eigenen privaten Schlüssels entziffern und lesen. 16

18 3.3 Kommunikation über LDAP Eine weitere Möglichkeit wäre es, die Zertifizierungsstelle und den LDAP - Server voneinander zu trennen. Die Konstellation der verschiedenen Komponenten hätte hier die Anordnung, wie sie in der folgenden Abbildung gezeigt wird. Abbildung 5: Kommunikation über den LDAP Funktionsweise Bei diesem Konzept besteht zunächst die Vorraussetzung, dass der Kommunikationskanal zwischen der Zertifizierungsstelle und den Klienten gesichert sein muss. Ebenso ist es mit dem Kanal zwischen OpenCA und dem LDAP - Server. Das wichtige und besondere an diesem Konzept ist die Tatsache, dass die öffentlichen Schlüssel aller Teilnehmer nur dem LDAP - Server und sonst niemandem bekannt sein dürfen. Warum dies so wichtig ist, wird nun in dem folgenden Beispiel ersichtlich. Soll nun eine Kommunikation zwischen Klient A nd Klient B stattfinden, so registrieren sich zunächst wieder alle Klienten bei der CA, genauso wie dem vorherigen Konzept. Nachdem dann jeder Klient seinen privaten Schlüssel von der CA erhalten hat und der jeweilige öffentliche Schlüssel der Teilnehmer von der CA aus in dem LDAP - Server abgelegt wurde, kann die Kommunikation beginnen. Will nun der Klient A eine Nachricht an Klient B schicken, so verschlüsselt er diese Nachricht mit seinem eigenen privaten Schlüssel und sendet sie dann an den LDAP - Server. Nur der LDAP - Server kann diese dann mit dem öffentlichen Schlüssel von Klient A entschlüsseln, da nur er diesen Schlüssel kennt. Nachdem er die Nachricht entschlüsselt hat, verschlüsselt er sie direkt wieder mit dem öffentlichen Schlüssel des Empfängers, nämlich dem des Klienten B. 17

19 Sobald B die Nachricht dann erhalten hat, entschlüsselt er diese mit seinem privaten Schlüssel und die Kommunikation ist abgeschlossen Nachteile dieses Szenarios Bei diesem Szenario gibt es zunächst einmal zwei schwerwiegende Nachteile. Zum einen wird hier, wie es eigentlich nicht vorgesehen ist, sowohl mit dem öffentlichen, als auch mit dem geheimen Schlüssel verschlüsselt. Bei einer PKI ist es eigentlich Standard, dass mit dem privaten Schlüssel entschlüsselt und nur mit dem öffentlichen Schlüssel verschlüsselt wird. Ein zweiter, jedoch noch viel gravierender Nachteil ist der, dass die komplette Kommunikation in diese System über den LDAP - Server geht. Alle Nachrichten passieren diesen Flaschenhals ds Systems. Spätestens bei wachsender Klienten - Anzahl wird dies zu einem Problem werden. Vor allem dieser zweite Nachteil ist der Grund dafür gewesen, dass wir uns gegen dieses Konzept entschieden und das folgende Verfahren realisiert haben. 3.4 OpenCA und LDAP getrennt Bei dem dritten möglichen Szenario, welches bei unseren Aufgaben eingesetzt wurde, sind die Zertifizierungsstelle und der LDAP - Server ebenfalls wie beim vorherigen Konzept strikt voneinander getrennt. Die Module sind gemäß der folgenden Abbildung angeordnet: 18

20 Abbildung 6: von uns realisiertes Konzept Funktionsweise Zunächst muss sich jeder Klient erneut bei der Zertifizierungsstelle registrieren. Hier wird das Schlüsselpaar für diesen Klienten erzeugt. Der private geheime Schlüssel wird über einen abhörsicheren Kanal an den Klienten zurückgeschickt. Der öffentliche Schlüssel wird an den LDAP geschickt, welcher diesen abspeichert. Will A nun einen Nachricht an B schicken, so schickt A einen Anfrage an den LDAP - Server. Dieser liefert daraufhin den Public Key des Empfängers B zurück. Dies geschieht alles unverschlüsselt, da diese öffentlichen Schlüssel für alle zugänglich sind und die Anfrage deshalb nicht geheim geschehen muss. Daraufhin verschlüsselt A seine Nachricht mit dem öffentlichen des Empfängers B und sendet diese ab. B kann sie nun mit Hilfe seines geheimen Schlüssels entschlüsseln. 3.5 Hinführende Aufgaben Um eine Zertifizierungsstelle zu testen, können die folgenden Aufgaben nacheinander abgearbeitet werden. Diese befassen sich mit OpenSSL und der darin enthaltenen CA. Die Aufgaben entstammen dem e-learning Modul des Verteilte Systeme Labors der FH Wiesbaden ( Abschnitt Security > E-Commerce). 19

21 3.5.1 Aufgaben 1. Erzeugung eines Wurzelzertifikates Basis einer Public-Key-Infrastruktur ist ein Trustcenter (engl. CA=Certificate Authority, vgl. Abschnitt 3.5). Ein Trustcenter überprüft u.a. Personen nach ihrer wahren Identität und stellt sog. digitale Ausweise (digitale Zertifikate) aus. Im ersten Teil des Praktikums sollen Sie die technische Funktionsweise eines Trustcenters nachvollziehen. Der erste Schritt ist die Generierung eines Wurzelzertifikates für ihr eigenes privates Trustcenter zum Signieren künftiger Zertifikatsanfragen (auch CSRs, engl. Certificate Signing Requests). Erstellen Sie mit Hilfe des OpenSSL-Frameworks unter Linux ein eigenes Wurzelzertifikat. Hierzu müssen Sie ein eigenes RSA-Schlüsselpaar generieren und das Zertifikat mit dem eigenen privaten Schlüssel signieren. Es handelt sich um ein sog. selbstsigniertes Wurzelzertifikat (engl. Root-Certificate). Benutzen die hierzu das Shell-Kommando openssl mit den Parametern req, -newkey, x509 und -out. Als Dokumentation steht Ihnen die Online-Dokumentation des Frameworks unter der Adresse zur Verfügung. Erzeugen Sie dabei einen RSA-Schlüssel mit der Bitschlüssellänge von 2048 Bits. Speichern Sie das Zertifikat in der Datei ca.crt und den privaten RSA-Schlüssel in der Datei caprv.key. Legen Sie hierfür ein dediziertes Verzeichnis in ihrem Home-Verzeichnis an. 2. Überprüfen und Anschauen des Wurzelzertifikates Sie sollten nun ein privaten Schlüssel in der Datei caprv.key haben und das dazugehörige Wurzelzertifikat in der Datei ca.crt. Schauen Sie sich die Datei caprv.key mit dem cat- Befehl oder einem beliebigen Editor ihrer Wahl an (emacs, vi,...). Schauen Sie sich anschließend das selbstsignierte Wurzelzertifikat mit dem Kommando openssl mit dem Parameter x509 an. 3. Erzeugen eines PKCS#10-konformen Zertifikats-Antrages (Certificate-Request) Erstellen Sie nun mit dem Programm openssl einen Zertifikatsantrag (siehe auch PK- CS#10, Abschnitt 3.17). Benutzen Sie hierfür die Parameter req, -newkey, -out, -keyout. Erstellen Sie diesmal einen RSA-Schlüssel mit der Bitschlüssellänge von 1024 Bit und speichern Sie den privaten Schlüssel unter dem Namen <Ihre Initialien><prv.key>. Der Schlüssel von Thomas Mustermann würde also tmprv.key heißen. Erzeugen sie eine Request-Datei mit dem Namen <Ihre Initialien><.req>. Das Zertifikats-Request für Thomas Mustermann würde tm.req heißen. Erzeugen Sie für diese Aufgabe wieder ein eigenes Verzeichnis unter ihrem Home-Verzeichnis. 4. Anschauen des Zertifikatsantrages Schauen Sie sich Ihren Antrag mit dem Programm openssl und den Parametern req, -in und -text an und überprüfen Sie die Daten. Schauen Sie sich den Distinguished Name des Antragsstellers genau an. Schreiben Sie die Felder des DNs des Antragsstellers auf. 20