The State of the Global Public Key Infrastructure

The State of the Global Public Key Infrastructure Testing X.509 certificates over time Projektdokumentation Eingereicht bei Dr. Marc Rennhard Kevin Denver, Klasse KI05b Raphael Jäger, Klasse KI05b Winterthur, 19. Dezember 2007

Abstract Deutsch Im Rahmen einer Projektarbeit an der Zürcher Hochschule für angewandte Wissenschaften (ZHAW) wurde das Programm CertChecker entwickelt. Dabei ging es vor allem darum, gelerntes in die Praxis umzusetzen und dies auch unter dem Druck einer realitätsnahen Produktion zu bewältigen. Ebenfals sollte auf die Wünsche des Businesspartners so weit als möglich eingegangen werden, ohne jedoch den Fokus auf die Kernapplikation zu verlieren. CertChecker soll in der Lage sein, diverse Zertifikate und Certificate Authorities (CA) miteinander zu vergleichen, um damit Aussagen über die Qualität der jeweiligen CA zu ermöglichen. CertChecker ist eine eigentständige in Java entwickelte Applikation, die aus zwei Komponenten besteht. Zum einen eine Stand-Alone-Komponente, welche die X.509 Zertifikate und die dazugehörigen CA s prüft, bewertet und die gesammelten Daten dabei in einer MySQL Datenbank ablegt. Zum andern eine Web-Komponente, um die gesammelten Daten über ein Web-Interface zur Verfügung zu stellen. Dazu wird ein Apache Tomcat Server verwendet. Über dieses Web-Interface kann ein Besucher Grafiken über die Erreichbarkeit der Certificate Revocation Lists (CRL) und der Online Certificate Status Protocol Server (OCSP) der jeweiligen CA s beobachten und miteinander vergleichen. Weiter stellt das Tool auch die jeweiligen Schlüsselstärken und die jeweilige Gültigkeitsdauer der Zertifikate dar. CertChecker ist für all jene interessant, welche schon ein Zertifikat besitzen oder in Zukunft ein Zertifikat erstehen wollen und Näheres über die Qualität der jeweiligen CA s erfahren möchte. i

Abstract Englisch At the Zurich University of Applied Sciences in Winterthur, we developed the application CertChecker as part of a project work. The purpose of this work was to practice skills, which we have learned in theory before. As part of the project, we had to address the wishes of our business partner, but without loosing the focus on the core application. CertChecker should be able to compare different certificates and Certificate Authorities (CA) and make reliable statements about their quality. CertChecker is a stand-alone, Java developed application which consist of two components. On one side, there is the stand-alone part which checks and rates X.509 certificates and theire CA s. The raised data gets stored in a MySQL database. On the other side, there is the web - part to publicise the raised data with a web-interface. To do this, an Apache Tomcat server is used. With this web-interface, an user can see charts about the availability of Certificate Revocation Lists (CRL) and Online Certifica Status Protocol (OCSP) servers for the different CA s and compare them with each other. Furthermore, the application provides the key strength and the validation durability of the different certificates. CertChecker is interesting for all those, who already have a certificate or plan to acquire one in the future, and want to learn more about the quality of a certain CA. ii

Zürcher Hochschule Winterthur Departement Technik, Informatik und Naturwissenschaften Erklärung betreffend das selbständige Verfassen einer Projektarbeit im Departement T Mit der Abgabe dieser Projektarbeit versichert der/die Studierende, dass er/sie die Arbeit selbständig und ohne fremde Hilfe verfasst hat. (Bei Gruppenarbeiten gelten die Leistungen der übrigen Gruppenmitglieder nicht als fremde Hilfe.) Der/die unterzeichnende Studierende erklärt, dass alle zitierten Quellen (auch Internetseiten) im Text oder Anhang korrekt nachgewiesen sind, d.h. dass die Projektarbeit keine Plagiate enthält, also keine Teile, die teilweise oder vollständig aus einem fremden Text oder einer fremden Arbeit unter Vorgabe der eigenen Urheberschaft bzw. ohne Quellenangabe übernommen worden sind. Bei Verfehlungen aller Art treten die Paragraphen 41 und 42 (Unredlichkeit und Verfahren bei Unredlichkeit) der ZHW Prüfungsordnung sowie die Bestimmungen des Disziplinarverfahrens der Hochschulordnung in Kraft. Ort, Datum: Unterschriften:... Das Original dieses Formulars ist bei der ZHW-Version aller abgegebenen Projektarbeiten zu Beginn der Dokumentation nach dem Abstract bzw. dem Management Summary mit Original-Unterschriften und -Datum (keine Kopie) einzufügen. Bri, 01.10.06 Mitglied der Zürcher Fachhochschule

Legal Disclaimer c Zürcher Hochschule für Angewandte Wissenschaften (ZHAW) Die ZHAW behält sich alle Rechte an der vorliegenden Dokumentation und den digitalen Dokumenten auf der CD. Die Arbeit darf ohne schriftliche Genehmigung der Autoren oder der ZHAW in keiner Art und Weise (Fotokopie, Mikrofilm, PDF oder mit Hilfe eines anderen Verfahrens), auch nicht für Zwecke der Unterrichtsgestaltung, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Die Erteilung einer Genehmigung unterliegt einer Bewilligung durch die ZHAW. Die Autoren sowie die ZHAW übernehmen keine Gewähr für die Richtigkeit der Angaben in der vorliegenden Arbeit. Im Weiteren haften die Autoren oder die ZHAW unter keinen Umständen für mittelbare oder unmittelbare Folgeschäden oder besondere Schadensfolgen, die sich aus oder in Verbindung mit der Dokumentation ergeben, gleichgültig, ob diese aufgrund unerlaubter Handlungen, eines Vertrages oder sonstigen Gründen in Verbindung mit dieser Dokumentation entstehen. Linux ist ein registriertes Warenzeichen von Linus Torvalds. Andere Produktnamen, die in dieser Dokumentation erwähnt werden, sind Warenzeichen der/und Markenzeichen von den zugehörigen Firmen. iv

Kontaktadresse Zürcher Hochschule Winterthur c/o Institut für angewandte Informationstechnologie InIT Steinberggasse 13 Postfach 805 CH-8401 Winterthur Tel.: +41 52 267 75 87 Fax: +41 52 267 90 75 E-Mail: info@init.zhwin.ch http://www.zhaw.ch http://www.init.zhaw.ch Name Kürzel Funktion E-Mail Denver Kevin denvekev Student KI05b denvekev@students.zhaw.ch Jäger Raphael jagerrap Student KI05b jagerrap@students.zhaw.ch Rennhard Marc rema Projektbetreuer marc.rennhard@zhaw.ch Hauser Ralf hauser Businesspartner Privasphere hauser@privasphere.com v

Inhaltsverzeichnis 1 Einleitung 1 1.1 Anforderungen................................... 1 1.2 Abgrenzungen.................................... 1 2 Kryptographie 2 2.1 Kryptologie..................................... 2 2.2 Was ist Kryptographie............................... 2 2.3 Secret Key Kryptographie............................. 3 2.3.1 Block Ciphers................................ 3 2.3.2 Stream Ciphers............................... 4 2.4 Public Key Kryptographie............................. 4 2.4.1 Der RSA - Algorithmus.......................... 4 3 Public Key Infrastructure 6 3.1 Was ist Public Key Infrastructur......................... 6 3.2 Digitale Zertifikate................................. 6 3.2.1 Aufbau eines digitalen Zertifikats..................... 6 3.2.2 Extensions digitaler Zertifikate...................... 7 4 Design der Applikation 8 4.1 Functional Requirements.............................. 8 4.1.1 Konfiguration der Applikation...................... 8 4.1.2 Importieren von X.509 Zertifikaten.................... 8 4.1.3 Lesen von X.509 Zertifikat Informationen................ 8 4.1.4 Speichern von X.509 Zertifikaten..................... 9 4.1.5 Testen von CRL Distribution Points................... 9 4.1.6 Testen von OCSP Servern......................... 9 4.1.7 Grafische Darstellung der Resultate................... 9 4.1.8 Auswertung der Testresultate für eine CA................ 9 4.1.9 Zusammenfassung............................. 10 4.2 Suplementary Specifications............................ 12 4.2.1 Functionality................................ 12 4.2.2 Implementation Constraints........................ 12 vi

4.2.3 Free Open Source Components...................... 12 4.3 Domain Model................................... 13 4.4 Architektur..................................... 14 4.4.1 Application Tiers.............................. 14 4.4.2 Application Layers............................. 15 5 Entwicklungsumgebung 16 5.1 Java Applikationen und Libraries......................... 16 5.1.1 Java JDK 5.0................................ 16 5.1.2 Spring Application Framework 2.5.0................... 16 5.1.3 Bouncy Castle Crypto API 1.37..................... 16 5.1.4 JRobin 1.5.8................................ 16 5.1.5 MySQL-Connector/J 3.0.......................... 16 5.1.6 JUnit 4.4.................................. 17 5.2 Datenbanken.................................... 17 5.2.1 MySQL 5.0................................. 17 5.2.2 HSQLDB 1.8.0............................... 17 5.3 Web......................................... 17 5.3.1 Apache Tomcat 5.5.25........................... 17 6 Aufgetauchte Probleme 18 6.1 Vorbereitungsphase................................. 18 6.2 Ausführungsphase................................. 18 7 Rück- / Ausblick 20 7.1 Rückblick...................................... 20 7.2 Ausblick....................................... 20 7.3 Reflexion...................................... 21 Anhang 22 Abbildungsverzeichnis.................................. 22 Tabellenverzeichnis.................................... 23 Abkürzungsverzeichnis.................................. 25 Literaturverzeichnis................................... 25 A Originale Aufgabenstellung 26 B Projektmanagement 28 C Installationshandbuch 38 vii

1 Einleitung Mit CertChecker wurde eine Applikation entwickelt, welche X.509 Zertifikate auswertet und auf verschiedene Kriterien überprüft. In dieser Dokumentation wird auf die einzelnen Teile von CertChecker eingegangen. Dabei stellt das folgende Kapitel-1 die Anforderungen an CertChecker dar. Im Kapitel-2 wird ein Überblick über die Kryptographie gegeben. Kapitel- 3 führt in die Public Key Infrastruktur und die Zertifikate ein und Kapitel-4 behandelt das Design der Applikation. Im Anhang befindet sich zudem ein Installationshandbuch, welches Schritt für Schritt durch die Installation des CertCheckers führt. 1.1 Anforderungen Mit CertChecker soll es möglich sein, Zertifikate zu analysieren, die ausgewerteten Daten zu speichern und dann in entsprechender Form darzustellen. Zertifikate sollen an einem zentralen Ort gespeichert werden und es sollen auch neue Zertifikate einfach eingebunden werden können. Die ausgelesenen Daten sollen separat gespeichert werden, damit nicht bei jedem Durchgang des Programms die kompletten Zertifikate neu interpretiert werden müssen. Dazu kann zum Beispiel eine Datenbank genutzt werden. Die separat gespeicherten Daten sollen von CertChecker ausgewertet und entsprechend dargestellt werden. Dabei sollen sowohl Auswertungen über Zeit als auch statische Methoden zum Zuge kommen. Um das Ganze öffentlich verfügbar zu machen, soll eine Webapplikation geschrieben werden, welche die gesammelten Daten präsentiert. 1.2 Abgrenzungen CertChecker ist in diesem ersten Schritt ein rein statischer Dienst für den Benutzer. Auf Funktionen, wie das Hochladen von eigenen Zertifikaten, wurde bewusst verzichtet. 1

2 Kryptographie Auf den folgenden Seiten werden die Grundbegriffe der Kryptographie in einer kurzen Einführung erläutert. 2.1 Kryptologie Die Kryptologie ist die Wissenschaft von den (offenen) Geheimschriften (Kryptographie), von ihrer unberufenen Entzifferung und von den Vorschriften, die dazu dienen sollen, die unberufene Entzifferung zu erschweren (vgl. [Bauer, 1994]). Kryptologie setzt sich aus den Bereichen: Kryptographie Kryptoanalyse technische Stenographie linguistische Stenographie Maskierung Verschleierung Raster Semagramme zusammen. Im Rahmen dieser Projektarbeit ist jedoch nur die Kryptographie interessant, auf welche in den kommenden Abschnitten auch näher eingegangen wird. 2.2 Was ist Kryptographie Das Wort Kryptographie leitet sich aus den zwei griechischen Wörtern kryptein (verborgen) und graphein (schreiben) ab und ist im ursprünglichen Sinne die Wissenschaft der Verschlüsselung von Informationen. Im allgemeinen verbinden Leute Kryptographie mit der Kunst, Information in eine unverständliche Form zu bringen und mit einer geheimen Methode wieder verständlich zu machen. 2

2.3 Secret Key Kryptographie Bei der Secret Key Kryptographie werden zwei verschiedene Methoden von Ciphers unterschieden. Zum einen sind dies die Block Ciphers (Data Encryption Standard DES, Advanced Encryption Standard AES) zum andern die Stream Chiphers (RC4). Bei der Secret Key Kryptographie wird sowohl zum Verschlüsseln als auch zum Entschlüsseln derselbe Key verwendet. 2.3.1 Block Ciphers Data Encryption Standard (DES) DES wurde 1977 vom National Institute of Standards an Technology (NIST) veröffentlicht und ist der erste weitverbreitete, moderne Cipher. DES arbeitet mit einer Blocklänge von 64 bits und einer Schlüssellänge von 56 bits und war über Jahre hinweg ein sehr erfolgreicher Cipher. Der heute noch gebräuchliche 3DES (sprich: Triple - DES) Cipher ist nichts anderes, als ein dreifacher Gebrauch von DES. Beim Chiffrieren verwendet DES eine einfache Kombination der grundlegenden Verschlüsselungstechniken. Der Chiffrierblock von DES substituiert einen Plaintext zuerst mit dem Schlüssel, um danach eine Permutation durchzuführen. Dieser Vorgang wird 16 mal durchgeführt. DES ist heutzutage eine unsichere Chiffriermethode, da man schon 1999 nur noch eine Zeit von 22 Stunden und 15 Minuten brauchte, um einen DES - Text zu knacken. Daher wird in modernen Systemen auch nur noch der 3DES Algorithmus verwendet. Advanced Encryption Standard (AES) Am 26. November 2001 wurde AES officiel vom NIST publiziert. 1997 startete das NIST einen öffentlichen Wettbewerb für AES und wählte im Oktober 2000 Rijndael - Methode aus. Die Anforderungen an AES waren öffentliche Verfügbarkeit, AES sollte ein Secret Key Block Cipher sein, der sowohl in Hardware als auch Software einfach implementiert werden kann, und AES sollte eine Blocklänge von 128 bit und eine variable Schlüssellänge von k = 128, 192 und 256 bit haben. Für die Verschlüsselung wird jeder Block zunächst in eine zweidimensionale Tabelle mit vier Zeilen geschrieben, deren Zellen ein Byte gross sind. Somit sind die Anzahl Spalten von der jeweiligen Blockgrösse abhängig (4 Spalten bei 128 Bits, 8 Spalten bei 256 Bits). Jeder Block wird nun nacheinander bestimmten Transformationen unterzogen. Dabei werden verschiedene Teile des erweiterten Originalschlüssels nacheinander auf den jeweiligen Klartext - Block angewendet. Die Anzahl dieser Runden variiert und ist von der Schlüssellänge, die verwendet wird, abhängig. 3

2.3.2 Stream Ciphers RC4 RC 4 wurde von Ron Rivest erfunden und wurde von der RSA Data Security Inc. geheim gehalten, bis 1994 der Source Code durch ein unbekanntes Leck bekannt wurde. Durch die 40 bit Exportbestimmungen der USA, die bis vor ein paar Jahren Gültigkeit hatten, galt RC4 als unsicher. Bei Gebrauch mit 128 bit Schlüsseln wird RC4 aber auch heute noch von den Experten als eleganter, sicherer Stream - Cipher angesehen und ist ausserdem extrem schnell. Bei der Chiffrierung wird eine Zufallsfolge aus einem einmalig zu verwendenden Schlüssel erzeugt. Der Klartext wird danach Byte für Byte mit der Zufallsfolge XOR verknüpft. 2.4 Public Key Kryptographie Bei der Secret Key Kryptographie muss man die Nachricht mit dem gleichen Schlüssel entschlüsseln, wie sie verschlüsselt wurde. Dies bringt den Nachteil mit sich, das der Schlüssel irgendwie auch an den Empfänger übertragen werden muss. Bei der Public Key Kryptographie wird dieses Problem elegant umgangen, indem der Empfänger einen öffentlichen Schlüssel zur Verfügung stellt. Will nun jemand etwas an den Empfänger senden, verschlüsselt er die Nachricht mit dem öffentlichen Schlüssel des Empfängers und schickt die verschlüsselte Nachricht. Diese Nachricht kann nun, und das ist der grosse Trick der Public Key Kryptographie, nur mit dem privaten Schlüssel des Empfängers entschlüsselt werden. Bei der Public Key Kryptographie ist vor allem das RSA Kryptosystem weit verbreitet und wir wollen daher auch näher auf ihn eingehen. 2.4.1 Der RSA - Algorithmus RSA ist nach seinen Erfindern, den drei Mathematikern Rivest, Shamir und Adleman, benannt und 1977 entwickelt. Dabei gingen die drei Mathematiker davon aus, das die Faktorisierung einer grossen Zahl in ihre Primfaktoren sehr aufwändig ist, während das Erzeugen durch Multiplikation zweier Primzahlen einfach berechnet werden kann. Sowohl der öffentliche Key (e,n) als auch der private Key (d,n) sind Zahlenpaare, wobei N in beiden Schlüsseln gleich ist und als RSA-Modul bezeichnet wird. e ist der Verschlüsselungsexponent und d der Entschlüsselungsexponent. N, d und e werden nach folgendem Verfahren erzeugt: 1. Man wählt zwei zufällige, stochastisch unabhängige Primzahlen p q 2. Das RSA-Modul berechnet sich mit N = p q 3. Als nächstes braucht man die Eulersche ϕ Funktion von N ϕ(n) = (p 1) (q 1) 4. Nun muss eine zu ϕ(n)teilerfremde Zahl e gewählt werden, für die gilt 1 < e < ϕ(n). 4

5. Als letztes berechnet man d als Multiplikativ Inverses von e bezüglich des Modulus von ϕ(n). Es gilt also e d 1(modϕ(N) 5

3 Public Key Infrastructure Die Public Key Infrastructure bildet die Basis für X.509 Zertifikate und soll nachstehend erläutert werden. 3.1 Was ist Public Key Infrastructur Eine Public Key Infrastruktur(PKI) ist ein kryptographisches System, um digitale Zertifikate auszustellen, zu verwalten und zu prüfen. Dabei wird jedem Benutzer ein Schlüsselpaar zugewiesen, welches sich aus dem Public Key und dem Private Key zusammensetzt. Um eine Zusammengehörigkeit eines Public Keys und einer Benutzerkennung zu beglaubigen und um Missbräuche mit dem Public Key einer Drittperson zu verhindern, werden digitale Zertifikate eingesetzt. 3.2 Digitale Zertifikate Digitale Zertifikate werden nach dem X.509 Standard des ITU-T erstellt und bestätigen die Authentizität eines Public Keys, dessen zulässigen Anwendungs- und Geltungsbereich und den dazugehörigen Benutzer. Das heute am meisten gebrauchte Profil bezieht sich auf den Standard des IETF, welcher in RFC 3280 definiert worden ist. 3.2.1 Aufbau eines digitalen Zertifikats Ein digitales Zertifikat setzt sich normalerweise aus folgenden Informationen zusammen: Die eindeutige Bezeichnung der CA. (engl. Issuer) Regeln und Verfahren zur Ausstellung des Zertifikats Gültigkeitsdauer des Zertifikats Den Public Key, zu dem das Zertifikat gehört. Die eindeutige Bezeichnung des Besitzers des Public Keys (engl. Subject) Erweiterungen, welche Informationen über den Eigentümer des Public Keys enthalten Angaben zum Geltungsbereich des Public Keys Die digitale Signatur der CA 6

3.2.2 Extensions digitaler Zertifikate Die wichtigsten Extensions, welche wir auch im Rahmen dieser Arbeit brauchen, sind die Extensions, welche die Certificate Revocation List (CRL) und das Online Certificate Status Protocol (OCSP) beschreiben. Daher werden diese zwei Punkte hier auch noch genauer beschrieben: Certificate Revocation List (CRL) Zertifikate können verloren und geklaut werden oder es kann einen anderen Grund geben, warum ein digitales Zertifikat nicht mehr gültig ist. Da ein solches Zertifikat nun nach wie vor im Umlauf sein kann, gibt es die sogenannten Certificate Revocation Lists (CRLs). Sobald ein Zertifikat nicht mehr gebraucht werden soll, wird es von der CA in die CRL eingetragen. Diese Liste wird immer dann abgefragt, wenn ein Programm bei der CA anfragt, ob ein bestimmtes Zertifikat gültig ist. Da diese CRL extrem wichtig für die gesammte Funktion der PKI sind, ist diese Extension in den Zertifikaten von zentraler Bedeutung. Online Certificate Status Protocol (OCSP) Genau wie die CRL ist auch das OCSP dazu da, ungültige Zertifikate zu kennzeichnen. Beim OCSP wird der Status eines Zertifikats durch Anfrage an den OCSP - Responder abgefragt. Dieser gibt dann als Antwort entweder good (Zertifikat ist in Ordnung), revoked (Zertifikat ist gesperrt) oder unknown (Zertifikat unbekannt) zurück. OCSP - Responder werden von den CA s betrieben. OCSP ist jedoch bei weitem nicht so verbreitet wie die CRL. Eine CRL ist in jedem Zertifikat zu finden, welches im Umlauf ist, das OCSP wird jedoch selten verwendet. 7

4 Design der Applikation Dieses Kapitel beschreibt die genauen Anforderungen an die CertChecker Applikation. Jedes Feature wird kurz in einem UseCase erläutert und mögliche alternative Szenarios aufgezeigt. Desweiteren wird die Architektur vorgestellt, die dem CertChecker zu Grunde liegt. 4.1 Functional Requirements 4.1.1 Konfiguration der Applikation Main Success Scenario: Die Applikation liest Konfigurationsparameter aus einer lokalen Datei und/oder von der Kommandozeile und verarbeitet diese. Alternative Scenarios: Eine solche Datei kann nicht gefunden werden. Eine Statusmeldung über den Fehler wird ausgegeben und eine Beispiel Konfigurationsdatei wird geschrieben. 4.1.2 Importieren von X.509 Zertifikaten Main Success Scenario: Es stehen X.509 Zertifikate in Form von Dateien auf dem lokalen Rechner bereit, die das Programm nun liest und verarbeitet. Da die Zertifikate in einem speziellen, vorher definierten Verzeichnis liegen, versucht das Programm automatisch, die Zertifikate zu lesen und dem Zertifikate-Pool hinzuzufügen. Dabei können die Zertifikate in verschiedenen Formaten bereitgestellt werden. Alternative Scenarios: Ein Zertifikat konnte nicht importiert werden. Eine Status Meldung über das Scheitern wird ausgegeben und das Programm versucht, andere Zertifikate zu importieren, falls weitere vorhanden sind. 4.1.3 Lesen von X.509 Zertifikat Informationen Main Success Scenario: Aus den vorher importierten Zertifikaten werden alle nötigen Informationen herausgelesen. CRL Distribution Points OCSP Servers Key Usage 8

Public Key Size CA Issuer Certificate SHA-1 Fingerprint 4.1.4 Speichern von X.509 Zertifikaten Main Success Scenario: Die importierten und verarbeiteten Zertifikate werden in permanenter Form abgespeichert. 4.1.5 Testen von CRL Distribution Points Main Success Scenario: Alle CRL Distribution Points werden getestet, ob die angegebene Quelle über das Internet erreichbar ist. Das Testresultat wird zusammen mit der aktuellen Zeit permanent gespeichert. Alternative Scenarios: Es besteht kein Zugang zum Internet. Eine Statusmeldung über das Scheitern wird ausgegeben und der aktuelle Test wird abgebrochen. 4.1.6 Testen von OCSP Servern Main Success Scenario: Alle OCSP Server werden getestet, ob die angegebene Quelle über das Internet erreichbar ist. Das Testresultat wird zusammen mit der aktuellen Zeit permanent gespeichert. Alternative Scenarios: Es besteht kein Zugang zum Internet. Eine Statusmeldung über das Scheitern wird ausgegeben und der aktuelle Test wird abgebrochen. 4.1.7 Grafische Darstellung der Resultate Main Success Scenario: Für jeden getesteten OCSP Server und für jeden CRL Distribution Point werden die gesammelten Testresultate in grafischer Form dargestellt. Dabei werden jeweils zwei Grafiken erstellt: Eine über die Resultate in den letzten 24 Stunden und eine über die Resultate in den letzten 30 Tagen. 4.1.8 Auswertung der Testresultate für eine CA Main Success Scenario: Die gesammelten Testresultate aller CRL Distribution Points und OCSP Servern werden der zugehörigen CA zugewiesen und deren Performance errechnet. 9

4.1.9 Zusammenfassung Scope: Certchecker application Level: User-Goal Primary Actor: User Stakeholder and Interests: User: Möchte die Performance einer CA analisieren. Administrator: Möchte alle Programmvorgänge in einer Log-Datei protokolliert sehen. Preconditions: Die Applikation muss korrekt installiert und konfiguriert worden sein. Success Guarantee (or Postconditions): Neue Zertifikate wurden importiert und dem Pool hinzugefügt. Alle CRL Distribution Points und OCSP Server wurden getestet und die Resultate wurden permanent gespeichert. Die Resultate konnten grafisch dargestellt und als Bild gespeichert werden. Alle Vorgänge wurden in einer Log-Datei festgehalten. Main Success Scenario (or Basic Flow): 1. Certchecker wird gestartet. 2. Kommandozeilen Parameter werden gelesen. 3. Konfigurationsdatei wird gelesen. 4. Laden von benötigten Bibliotheken. 5. Testen, ob eine Verbindung ins Internet besteht. 6. Neue Zertifikate importieren. 7. CRL Distribution Points testen. 8. CRL Resultate speichern. 9. OCSP Server testen. 10. OCSP Resultate speichern. 11. Grafiken erstellen. 12. CA Performance errechnen. Extensions (or Alternative Flows): 3a. Die Konfigurationsdatei kann nicht gefunden oder nicht gelesen werden. 1. Ein entsprechender Eintrag wird in der Log-Datei gemacht. 2. Eine Beispiel Konfigurationsdatei wird geschrieben. 10

3. Das Programm wird beendet. 4a. Das Laden einer zur Laufzeit benötigten Bibliothek schlug fehl. 1. Ein entsprechender Eintrag wird in der Log-Datei gemacht. 2. Das Programm wird beendet. 5a. Es konnte keine Verbindung ins Internet aufgebaut werden. 1. Ein entsprechender Eintrag wird in der Log-Datei gemacht. 2. Das Programm wird beendet. 6a. Es gab einen Fehler beim Importieren eines Zertifikates. 1. Ein entsprechender Eintrag wird in der Log-Datei gemacht. 11

4.2 Suplementary Specifications 4.2.1 Functionality Logging and Error Handling Protokolliere alle Fehler. Configuration Eine Konfigurationsdatei soll es dem Administrator erleichtern, die Applikation zu installieren und zu betreuen. MVC Das Web-Interface soll mit einem MVC Pattern implementiert werden, damit Änderungen am Design leicht vorgenommen werden können, ohne den Code des Web-Interfaces zu ändern. 4.2.2 Implementation Constraints Für die Implementation der Applikation muss die Java Technologie verwendet werden. 4.2.3 Free Open Source Components Die Verwendung von Open Source Java Technologie ist erwünscht und folgende Bibliotheken wären mögliche Kandidaten: JLog - Logging Framework BouncyCastle - Cryptography Framework JUnit - Testing Framework JRobin - RoundRobin like Framework 12

4.3 Domain Model Abbildung 4.1: Domain Model In der obigen Abbildung werden die Schlüssel Konzepte des CertCheckers anhand eines Domänen Modells visualisiert. 13

4.4 Architektur 4.4.1 Application Tiers Abbildung 4.2: Multi-Tier Architektur Das Ziel dieser gewählten Architektur ist es, die Logik so weit wie möglich vom Web-Interface zu trennen. Dieser Entscheid bringt mehrere Vorteile: Sollte der Apache Tomcat Server einmal unerreichbar sein, werden im Hintergrund die Daten weiterhin erhoben. Die Dienste des CertCheckers können auf verschiedene Systeme verteilt werden. Die Netzlast könnte auf verschiedene Systeme verteilt werden, sollte dies einmal nötig sein. 14

4.4.2 Application Layers Abbildung 4.3: Application Layers Die Trennung von Logik und Web-Interface spiegelt sich auch in der Architektur der Java- Packages wieder. Das Graphical UserInterface benötigt lediglich Klassen, um die benötigten Daten aus der Datenbank zu lesen. 15

5 Entwicklungsumgebung Im folgenden Kapitel werden die verwendeten Bibliotheken beschrieben, die verwendet wurden, um die Applikation zu realisieren. Alle diese Bibliotheken sind unter einer GPL oder änlichen Lizenz veröffentlicht worden. 5.1 Java Applikationen und Libraries 5.1.1 Java JDK 5.0 Wir haben CertChecker mit der Java Standard Edition (J2SE 5.0) entwickelt. Die neuste Version des Java Developement Kits befindet sich unter: http://java.sun.com. 5.1.2 Spring Application Framework 2.5.0 Spring ist ein führendes full-stack Java/EE Application Framework, welches die Entwicklung von J2EE Applikationen erleichtert. Das Spring Framework wurde verwendet, um das Web- Interface des CertCheckers zu implementieren. http://www.springframework.org 5.1.3 Bouncy Castle Crypto API 1.37 Die Bouncy Castle Crypto API ist eine Erweiterung für den Java Cryptography Provider und dessen Architektur. Bouncy Castle bietet viele Methoden und Klassen, um mit X.509 Zertifikaten zu arbeiten. http://www.bouncycastle.org 5.1.4 JRobin 1.5.8 JRobin ist eine Portierung der von Tobias Oetliker geschriebenen RRDtool Applikation auf Java. Das RRDtool ist der Industriestandard für die Visualisierung von zeitlich abhängigen Daten. CertChecker verwendet diese Bibliothek, um Grafiken über die Performance der CRL und OCSP Server zu zeichnen. http://www.jrobin.org 5.1.5 MySQL-Connector/J 3.0 MySQL-Connector/J 3.0 ist der offizielle JDBC Treiber für die MySQL Datenbank. Für die Anbindung von CertChecker wurde auf diesen Treiber zurückgegriffen, welcher auf der MySQL Homepage verfügbar ist. http://www.mysql.org 16

5.1.6 JUnit 4.4 Damit CertChecker getestet werden kann, wurde das JUnit Framework verwendet, um JUnit Tests zu schreiben. http://www.junit.org 5.2 Datenbanken Die Stand-Alone Komponente des CertCheckers kann mit einer MySQL oder einer HSQLDB Datenbank verwendet werden. Sollen jedoch die Daten anhand des Web-Interfaces ansprechbar sein, muss eine MySQL Datenbank verwendet werden. Die Konfiguration dazu ist im Installationshandbuch beschrieben. 5.2.1 MySQL 5.0 MySQL ist die weltweit am meisten gebrauchte OpenSource Datenbank. http://www.mysql.org 5.2.2 HSQLDB 1.8.0 HSQLDB ist eine reine Java Datenbank, die ohne Installation auskommt und direkt aus einer Applikation gestartet werden kann. Die Verwendung einer solchen Datenbank ist historisch gewachsen. Bevor eine MySQL Datenbank aufgesetzt wurde, verwendetet CertChecker eine HSQLDB Datenbank, um Daten abzulegen.http://hsqldb.org 5.3 Web 5.3.1 Apache Tomcat 5.5.25 Um CertChecker auch Online verfügbar zu machen, wurde der Apache Tomcat Webserver verwendet. http://www.apache.org 17

6 Aufgetauchte Probleme Keine Arbeit läuft ohne Probleme. Da dies auch bei der vorliegenden Projektarbeit so war haben wir die Probleme analysiert und hier aufgeführt. So soll es Nachfolgern möglich sein, ohne die gleichen Probleme nochmals zu haben mit CertChecker zu arbeiten. 6.1 Vorbereitungsphase Zu Beginn hatten wir einige Mühe, uns in die ganze PKI und Zertifikatswelt einzuarbeiten. Dies vor allem bis wir auch nur einigermassen einen Überblick über die verschiedenen Erweiterungen der Zertifikate und deren Gewichtigkeit hatten. Bei diesem Prozess konnten wir zum Glück auf die reichhaltige Erfahrung von Herr Rennhard zurückgreifen, welcher uns in vielen Fragen weiterhelfen konnte. 6.2 Ausführungsphase Wohl am meisten Probleme an der ganzen Arbeit verursachte der Einsatz des Darstellungstools JRobin. Die mitgelieferte Javadoc API ist sehr unvollständig oder schlecht ausgeführt. Wir haben einige Stunden damit verbracht, bis wir endlich raus hatten, welcher Parameter in welcher Methode was an der Grafik verändert. Um diesen Austestaufwand und andere Probleme für weitere Benutzer zu umgehen, wollen wir hier die wichtigste Methode mit den dazugehörigen Kommentaren abbilden. 18

Listing 6.1: CRLImageGenerator.java 1 private void i n i t ( ) throws IOException, RrdException 2 { 3 // Check i f the d e f i n i t i o n already e x i s t s... 4 i f ( t h i s. e x i s t s ( t h i s. rrdfile ) ) 5 return ; 6 7 this. rrddef = new RrdDef( this. rrdfile, Defaults.RROBIN STARTTIME) ; 8 9 / 10 step S p e c i f i e s the base i n t e r v a l in seconds with 11 which data will be fed into the database. 12 / 13 this. rrddef. setstep ( 3 6 0 0 ) ; 14 15 / 16 DataSource name: type : heartbeat : min :max 17 18 heartbeat Defines the maximum acceptable interval between samples. 19 I f the interval between samples i s less than heartbeat, 20 then an average rate i s calculated and applied for that 21 interval. I f the interval between samples i s longer than 22 heartbeat, then that entire interval 23 i s considered unknown. 24 / 25 this. rrddef. adddatasource ( CRLUptime, DsTypes.DTGAUGE, 26 4000, Double.NaN, Double.NaN) ; 27 28 this. rrddef. adddatasource ( CRLFreshness, DsTypes.DTGAUGE, 29 4000, Double.NaN, Double.NaN) ; 30 31 / 32 Archive function : x f f : steps : rows 33 34 xff The x f i l e s factor defines what part of a consolidation 35 i n t e r v a l may be made up from unknown data while the 36 consolidated value i s s t i l l regarded as known. 37 38 steps Defines how many of these primary data points are used to 39 build a consolidated data point which then goes 40 into the archive. 41 42 rows how many generations of data values are kept in an archive. 43 / 44 45 // Hourly average 46 this. rrddef. addarchive ( ConsolFuns.CFAVERAGE, 0. 5, 1, 1000) ; 47 48 // Daily average 49 this. rrddef. addarchive ( ConsolFuns.CFAVERAGE, 0. 5, 24, 1000) ; 50 51 this. rrddb = new RrdDb( this. rrddef ) ; 52 t h i s. rrddb. c l o s e ( ) ; 53 } 19

7 Rück- / Ausblick Zum Schluss wollen wir noch einen kurzen Rückblick auf die vergangene Projektarbeit sowie einen Ausblick auf eventuelle zukünftige Möglichkeiten geben. 7.1 Rückblick Projekt Die Projektarbeit ist mit wenigen Unterbrüchen sehr gut gelaufen. Insbesondere die Zusammenarbeit mit Herrn Rennhard und die wöchentlichen Sitzungen haben sehr geholfen, den Faden nicht aus den Augen zu verlieren und stetig weiter zu arbeiten. Leider konnten in dieser Projektarbeit die Erwartungen unseres Business Partners, PrivaSphere AG, nicht gedeckt werden. Dies lag sowohl an einer falschen Erwartung der PrivaSphere AG, als auch an einer mangelhaften Information von unserer Seite. Applikation Nach einigem hin und her bei der Applikation ist es uns schlussendlich doch gelungen, Cert- Checker auf einen befriedigenden Status zu bringen. CertChecker läuft mit den Grundfunktionen, wie wir sie am Anfang der Arbeit definiert haben. Es blieb uns leider jedoch keine Zeit mehr, in einem 2. Schritt weitere Funktionen hinzuzufügen. 7.2 Ausblick Projekt Da wir auf die Vorstellung des Businesspartners nicht voll eingehen konnten gibt es die Möglichkeit, in einer zweiten Projektarbeit diese Funktionen voll zu integrieren. Nach einem Gespräch mit Herrn Rennhard hat es sich gezeigt, das sowohl er als auch die PrivaSphere AG an einer solchen weiterführenden Arbeit interessiert wären. Applikation Sollte eine weiterführende Projektarbeit zustande kommen, werden sicherlich die zusätzlichen Funktionen in CertChecker integriert. Auch wird auf die Wünsche des Businesspartners eingegangen und die dort verlangten Ideen eingebunden. So sollte CertChecker am Schluss dann 20

ein mächtiges Tool zum Vergleich, der Überwachung und der Kontrolle der verschiedensten Zertifikate sein. 7.3 Reflexion Raphael Jäger In unserer Projektarbeit haben wir uns mit den Problemen der Public Key Infrastruktur befasst und ein Tool geschrieben, welches die Zuverlässigkeit der Zertifikate miteinander vergleichen soll. Ich für meinen Teil muss eingestehen, dass ich den Arbeitsaufwand massiv unterschätzt habe und ich bin extrem froh, dass ich mit Kevin Denver zusammenarbeiten konnte. Er hat das meiste an Programmierarbeit geleistet und ohne ihn wäre dieses Projekt sicher nicht so zustande gekommen wie es jetzt ist. Ich persönlich habe vor allem viel über die Welt der Zertifikate, Verschlüsselungen und der PKI im allgemeinen gelernt. Da wir unsere Dokumentation in L A TEX gemacht haben, konnte ich sehr viele Erfahrungen mit diesem Tool sammeln, welche mir sicherlich auch in späteren Arbeiten sehr zugute kommen werden. Kevin Denver Ich habe mir diese Projektarbeit bewusst ausgewählt, da ich über eine mehrjährige Erfahrung in der Entwicklung von Java Applikationen und deren Entwicklung für das Web verfüge. Doch bin ich noch nie mit X.509 Zertifikaten in Berührung gekommen, und mit dieser Projektarbeit konnte ich mir neues Wissen und Erfahrungen im Umgang mit solchen digitalen Zertifikaten aneignen. Die Zusammenarbeit mit Dr. Rennhard hat sich als äussert angenehm und umgänglich erwiesen. Auch die Zusammenarbeit mit Raphael Jäger erwies sich als sehr offen und kritikfähig. Was mich sehr überraschte war der Umstand, dass man relativ wenig Informationen über die Handhabung und Verwendung von Zertifikaten, in der Java Programmiersprache, im Internet finden konnte. Das zeigt wie wenig der normale Internetbenützer über die Sicherheitsmechanismen weiss, die im Internet etabliert sind. Ich bin mit unseren erreichten Zielen sehr zufrieden und würde mich freuen, diese Arbeit noch weiter zu führen. 21

Abbildungsverzeichnis 4.1 Domain Model................................... 13 4.2 Multi-Tier Architektur............................... 14 4.3 Application Layers................................. 15 7.1 Gantt Projektplan................................. 28 7.2 Architekturskizze Vorschlag 1........................... 32 7.3 Architekturskizze Vorschlag 2........................... 32 7.4 Filesystem 1..................................... 34 7.5 Filesystem 2..................................... 36 7.6 Database 1..................................... 36 7.7 Database 2..................................... 37 22

Tabellenverzeichnis 7.1 Projektteam..................................... 29 7.2 Funktionen V1 / V2................................ 31 7.3 Features V1 / V2.................................. 34 23

Abkürzungsverzeichnis Abkürzung Beschreibung AES Advanced Encryption Standard CA Certificate Authority CRL Certificate Relocation List DES Data Encryption Standard FTP File Transfer Protocoll IETF Internet Engineering Task Force ITU-T International Telecommunication Union OCSP Online Certificate Status Protocoll PKI Public Key Infrastructure RC4 Ron s Code 4 RSA Rivest, Shamir und Adleman Algorithmus SQL Structured Query Language 24

Literaturverzeichnis [Bauer, 1994] [Hook, 2005] [Kaufman, 2002] [Larman, 2006] Bauer Friedrich L. (1994): Kryptologie. Methoden und Maximen. 2. Auflage, Berlin, Springer Verlag Hook David (2005): Beginning Cryptography with Java, Indianapolis, Wrox Kaufman Charlie, Perlman Radia, Speciner Mike (2002): Network Security. Private Communication in a Public World. 2nd Edition, New Jersey, Prentice Hall PTR Larman Craig (2006): Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3rd Edition, Upper Saddle River, Prentice Hall 25

ZHAW - Projektarbeit 1 Projektarbeit für Kevin Denver (KI) Raphael Jäger (KI) Betreuer: Marc Rennhard Partnerfirma: PrivaSphere AG Kontaktpersonen: Ralf Hauser Ausgabe: 24. September 2007 Abgabe: 21. Dezember 2007 The State of the Global Public Key Infrastructure Einführung und Motivation Digitale Zertifikate nach dem X.509 Standard sind heute die Basis, um authentische und verschlüsselte Kommunikation im Internet zu ermöglichen. Darauf basieren zb verschlüsselte Web-Verbindungen (HTTPS) oder die E-Mail Sicherheit (S-MIME). Digitale Zertifikate werden von einer grossen Zahl (>100) Zertifikatsanbieter (Certification Authority, CA) herausgegeben, dazu gehören Firmen wie Verisign, Thawte oder die Schweizer Post und Swisscom. Untersuchungen des Firmenpartners dieser Arbeit haben gezeigt, dass die von den CAs zur Verfügung gestellten Funktionen nicht immer zuverlässig sind. Dabei es zb um die Abfrage des Status eines Zertifikats via Certificate Revocation Lists (CRL) oder OSCP-Protokoll. Daraus entstand die Motivation für diese PA: einen Web-Dienst anzubieten, der periodisch überprüft, wie zuverlässig die verschiedenen CAs sind und dies über die Zeit darstellt. Dadurch kann jeder Betrachter der Webseite einfach sehen, wie zuverlässig die verschiedenen CAs im Vergleich zueinander sind. Aufgabenstellung Entwickeln Sie im Rahmen dieser Projektarbeit einen Web-Dienst, der die Zuverlässigkeit der verschiedenen CAs über die Zeit darstellt. Dabei sollen Sie folgende Punkte bearbeiten: Arbeiten Sie sich ins Thema digitale Zertifikate ein und studieren Sie, welche Information darin gespeichert wird. Überlegen Sie sich, welche Funktionalität von CAs periodisch überprüft und dargestellt werden soll (zb Verfügbarkeit und Aktualität von CRLs). Zusätzlich kann auch statische 20.09.2007, Marc Rennhard (rema)

ZHAW - Projektarbeit 2 Zertifikatsinformation dargestellt werden, zb die kryptographische Stärke des Public Keys der CA. Überlegen Sie sich, welche zusätzliche Funktionalität der Web-Dienst anbieten soll. Denkbar wäre zb, dass Unternehmen oder Privatpersonen auch selbst Zertifikate "raufladen" könnten, die dann in die Analyse miteinbezogen werden. Implementieren Sie einen Prototypen des Web-Dienstes in Java (zb basierend auf Tomcat, Servlets und JSP). Anmerkung: der Firmenpartner hat bereits einige der möglichen Tests in Java implementiert. Dieser Programmcode kann in der Projektarbeit verwendet werden. Bemerkungen Organisieren Sie sich die benötigten Hard- und Softwarekomponenten selbst. Ihre Ansprechpartner hierfür sind Markus Rohner (E509) und die IT-Dienste des Departements T (E405). Mit dem Betreuer werden regelmässige Meetings abgehalten um den Fortlauf der Arbeit und offene Fragen zu besprechen. Nach zwei Wochen müssen die Studierenden einen Arbeitsplan erstellt haben, der die geplanten Tätigkeiten während der gesamten Projektarbeit inklusive der wichtigsten Milestones erläutert. Dieser Plan ist mit dem Betreuer zu besprechen. Es ist ein schriftlicher Bericht zur Projektarbeit zu erstellen. Der Bericht kann in Deutsch oder Englisch sein und muss einen Abstract sowohl in Deutsch als auch Englisch enthalten. Der Bericht muss alle während der Arbeit durchgeführten Schritte und Gedankengänge klar und nachvollziehbar beschreiben und diese Aufgabenstellung und Ihren Zeitplan enthalten. Dem Bericht ist ebenfalls eine CD-ROM beizulegen, welche den Bericht im Quell- und pdf-format enthält. Es ist wichtig, dass die in der Arbeit entwickelten Softwarekomponenten und Systeme auch später wieder verwendet werden können. Deshalb muss der Bericht die notwendigen Informationen enthalten (verwendete Hardware, Software, Versionen etc.), um die Systeme eindeutig zu reproduzieren. Sämtliche während der Arbeit entwickelte Softwarekomponenten und Konfigurationsfiles sind der CD-ROM beizufügen. 20.09.2007, Marc Rennhard (rema)

Appendix B Abbildung 7.1: Gantt Projektplan 28

Team Name Denver Kevin Jäger Raphael Rennhard Marc Funktion Projektleitung, Webentwicklung, Programmierung, Dokumentation Projektmitarbeiter, Programmierung, Dokumentation Projektbetreuer Tabelle 7.1: Projektteam 29

Sitzungsprotokolle Sitzung vom 26.09.2007 In Zertifikate einarbeiten (X.509, OCSP, CRL) Deadline 21. Dezember 07 PA Meeting entweder Dienstags 10-12 Uhr oder Mittwochs 11.45-12.45 Früh Projektplan mit Milestones Abstract in deutsch und Englisch Bericht in Latex und auf CD-Rom mit Source Sitzung vom 28.09.2007 Features Applikation Früherkennung von Exoten Fehler zurückgeben Code erweitern / verbessern OCSP Check CRL aktuell zeitliches Tracking Hochladen mit momentanen Prüfung. Interessante Zertifikate mit unbekannten Attributen Speichern. nicht validierende CA s speichern Realisierung Applikation Tomcat, Certificates hochladen und bewerten MySQL Round Robin Database RRD - Tool bestehende CA s aus Trust-Store BouncyCastle 30

Sitzung vom 03.10.2007 RFC 3807? / Wikipedia X.509 Entscheidungsstufe (Was wird in einer ersten Stufe implementiert) Milestones weitere Funktionen Version 1 Version 2 Ausgesuchte Zertifikate Upload der Zertifikate Tabelle 7.2: Funktionen V1 / V2 Bis nächsten Mittwoch Theorie fertig Prioritäten festlegen Umfang V1 festlegen neuer Zeitplan Meeting mit PrivaSphere in 2-3 Wochen nach 8 Wochen 31

Sitzung vom 10.10.2007 Zwei verschiedene Versionen präsentiert wie die Architektur aussehen könnte. Zu sehen in Architektur Skizze 1 & 2. Abbildung 7.2: Architekturskizze Vorschlag 1 Abbildung 7.3: Architekturskizze Vorschlag 2 32

CRL Datum Schlüsselstärke CA s / Länge Verfügbarkeit OCSP Schlüssel können z.b wie eine Ampel angezeigt werden. SHA-1 höher bewerten als MD5 Mehrere Zertifikate ansehen bis nächsten Mittwoch 33

Sitzung vom 17.10.2007 CRL meistens CRL Distribution Point / OCSP unter verschiedenen Punkten Features V1 CRL Update OCSP Update Key length Key... Features V2 Zertifikat in CRL s suchen Tabelle 7.3: Features V1 / V2 Keys als Filesystem, in Datenbank History von Up / Downtime. CRL s auch in Filesystem speichern. Abbildung 7.4: Filesystem 1 Meeting mit Herr Hauser abmachen BouncyCastle ansehen. Was ist möglich? Dokumentation UML Bildchen Archtektur 34

Sitzung vom 24.10.2007 BouncyCastle verwenden Freitag um 14.00 Uhr Meeting mit PrivaSphere. Testdaten mitnehmen 35

Sitzung vom 07.11.2007 Interfaces für Herr Hauser jedes Zertifikat separat betrachten Nur gültige Zertifikate checken Email an Admin wenn Zertifikat am ablaufen ist Abbildung 7.5: Filesystem 2 Abbildung 7.6: Database 1 36

Sitzung vom 11.11.2007 Ablauf CertChecker 1. Read import Directory 2. Save new Certs in the database 3. Move Certs to Cert Directory 4. Start parsing the Cert directory and save in database Database Abbildung 7.7: Database 2 37

The State of the Global Public Key Infrastructure Testing X.509 certificates over time Installationshandbuch Eingereicht bei Dr. Marc Rennhard Kevin Denver, Klasse KI05b Raphael Jäger, Klasse KI05b Winterthur, 18. Dezember 2007

Inhaltsverzeichnis 1 Einleitung 1 1.1 Namenskonvention................................. 1 1.2 Verwendete Symbole / Hinweise.......................... 1 2 Der Einstieg in die Installation 2 2.1 Mindestanforderungen............................... 2 2.2 Installation von Java JRE............................. 2 2.3 Installation von Apache Tomcat.......................... 2 2.4 Installation von MySQL Community Server................... 2 3 CertChecker Installation Teil 1 3 3.1 Installation der Stand-Alone Komponente.................... 3 3.2 Konfiguration der MySQL Datenbank...................... 4 3.2.1 Erstellen der Tabellen........................... 4 3.2.2 Erstellen eines Benutzers......................... 4 3.3 Anpassen der Stand-Alone Konfiguration.................... 5 4 CertChecker Installation Teil 2 6 4.1 Installation der Web Komponente........................ 6 4.2 Anpassen der Web Konfiguration......................... 7 4.3 Anpassen der Stand-Alone Konfiguration.................... 8 5 Anwendung 9 5.1 Starten der Stand-Alone Komponente...................... 9 5.2 Importieren von X.509 Zertifikaten........................ 9 5.3 Konfigurationsparameter der Stand-Alone Komponente............ 10 5.4 Webinterface.................................... 11 5.4.1 Einstiegs - Site............................... 11 5.4.2 Zertifikate.................................. 12 5.4.3 CRL Resultate............................... 13 5.4.4 OCSP Resultate.............................. 14 6 Troubleshooting 15 6.1 java.net.socketpermission 127.0.0.1:3306 connect,resolve............ 15 i

7 Anhang 16 A SQL Tabellen................................... 16 ii

1 Einleitung Das vorliegende Installationshandbuch beschreibt die Installation der CertChecker Applikation und die dazu benötigten Dienste. Im ersten Teil wird die Installation der Stand-Alone Komponente beschrieben sowie die Konfiguration der MySQL Datenbank. Im zweiten Teil der Dokumentation wird die Installation der Web-Komponente des Cert- Checkers beschrieben sowie weitere Konfigurationsschritte. Im dritten Teil der Dokumentation wird die generelle Handhabung der Komponenten beschrieben. 1.1 Namenskonvention Das CertChecker Programm besteht aus zwei Komponenten: Einer Stand-Alone Komponente, die in regelmässigen Abständen Daten in eine MySQL Datenbank schreibt und einer Web- Komponente, die diese Daten über das Web aufbereitet und darstellt. 1.2 Verwendete Symbole / Hinweise Nebenstehendes Symbol kennzeichnet eine Textstelle, die sie besonders aufmerksam lesen sollten, da wichtige Informationen gegeben werden. ACHTUNG! Dieses Symbol kennzeichnet einen Hinweis, den sie nicht ignorieren sollten. Hinweise für spezifische Betriebssysteme (beispielsweise Unix) 1

2 Der Einstieg in die Installation 2.1 Mindestanforderungen Bevor sie mit der Installation beginnen können, müssen folgende Mindestanforderungen auf ihrem Rechner erfüllt sein: Java 1.5 oder höher Apache Tomcat 5.5.25 MySQL Community Server 5.0.45 Windows, Mac OSX oder Linux Betriebssystem 2.2 Installation von Java JRE Wenn Sie sich nicht sicher sind, welche Java Version sie besitzen, öffnen Sie eine Konsole und tippen: java -version. Sollte ihre Version tiefer als 1.5 sein, müssen sie ihre Java Installation aktualisieren. Wie sie Java für ihre Platform installieren oder aktualisieren, entnehmen sie folgender Dokumentation: http://java.sun.com/javase/6/webnotes/install/index.html 2.3 Installation von Apache Tomcat Wie sie den Apache Tomcat Server für ihre Platform installieren oder aktualisieren, entnehmen sie folgender Dokumentation: http://tomcat.apache.org/tomcat-5.5-doc/index.html 2.4 Installation von MySQL Community Server Wie sie den MySQL Community Server für ihre Platform installieren oder aktualisieren, entnehmen sie folgender Dokumentation: http://dev.mysql.com/doc/refman/5.0/en/index.html 2

3 CertChecker Installation Teil 1 3.1 Installation der Stand-Alone Komponente Entnehmen sie der beigelegten CD-ROM die Datei: Installation/certchecker-standalone-1.0.zip. Entpacken sie diese in ein beliebiges Verzeichnis auf ihrem Rechner (zbsp. C:/Programme). Im weiteren Verlauf dieser Dokumentation nennen wir diesen Ordner nun $CERTCHECKER. Vor dem Extrahieren der Datei ist es sinnvoll, die Datei auf ihre Integrität zu prüfen. Vergleichen sie dazu den MD5 Hash in der certchecker-standalone-1.0.zip.md5 Datei mit dem Hash, den sie berechnen. Öffnen sie nun eine Konsole und wechseln in das $CERTCHECKER Verzeichnis. Tippen sie folgenden Befehl: java -jar certchecker.jar Folgender Output sollte in der Konsole ausgegeben werden: Couldn t load certchecker.properties. Please check the documentation in order to write a properties file. Sample properties file written to <hier steht ihr CertChecker Verzeichnis> Nun haben sie eine Beispiel-Konfigurationsdatei erstellt, die wir später verwenden können um die Stand-Alone Komponente zu konfigurieren. Bevor wir dies jedoch tun können, müssen wir zuerst noch einen Benutzer für die Datenbank und die SQL Tabellen erstellen. Unter Windows öffnen sie eine Konsole, indem sie auf Start - Ausführen klicken. In das sich öffnende Eingabefeld schreiben sie cmd und bestätigen mit Enter. 3

3.2 Konfiguration der MySQL Datenbank In diesem Abschnitt werden wir die MySQL Datenbank so vorbereiten, dass die Stand-Alone Komponente mit einem eigenen Benutzer Zugriff auf die Datenbank erhält und ihre Daten in die Datenbank ablegen kann. 3.2.1 Erstellen der Tabellen Öffnen sie eine Konsole und tippen sie folgenden Befehl: mysql -u root -p < certchecker-sqltables-1.0.sql Geben sie anschliessend ihr Root-Passwort für die MySQL Datenbank ein, falls sie eines bei der Installation angegeben haben. Nachdem der Befehl ausgeführt wurde, wurde eine Datenbank mit dem Namen certchecker und sieben Tabellen erstellt. Im Anhang A finden sie die genauen Tabellen Definitionen. 3.2.2 Erstellen eines Benutzers Öffnen sie eine Konsole und tippen sie folgenden Befehl: mysql -u root -p Geben sie anschliessend ihr Root-Passwort für die MySQL Datenbank ein, falls sie eines bei der Installation angegeben haben. Tippen sie folgenden Befehl, um einen neuen Benutzer für die Stand-Alone sowie für die Web-Komponente zu erstellen: CREATE USER certchecker usr @ % IDENTIFIED BY change password ; REVOKE ALL ON *.* FROM certchecker usr @ % ; GRANT SELECT, INSERT, UPDATE ON certchecker.* TO certchecker usr @ % ; FLUSH PRIVILEGES; Ändern sie auf jeden Fall das Passwort des Benutzers und merken sie es sich. Wir werden es später brauchen. Nun ist die Konfiguration der MySQL Datenbank abgeschlossen. 4

3.3 Anpassen der Stand-Alone Konfiguration Damit die Stand-Alone Komponente mit dem vorher erstellten Datenbank Benutzer auf die Datenbank zugreifen kann, müssen wir diese Angaben in die Konfigurationsdatei schreiben. Wechseln sie dazu in das $CERTCHECKER Verzeichnis, indem sie zu Beginn die Programmdateien extrahiert haben. Öffnen sie dort mit einem gewöhnlichen Texteditor die certchecker.properties.sample Datei. mysql.username=change this mysql.host=localhost mysql.database=certchecker database.type=mysql mysql.password=change this mysql.port=3306... Ändern sie hier nun die Optionen mysql.username, mysql.password und mysql.database mit den Angaben, die sie vorher bei der Erstellung des MySQL Benutzers verwendet haben. Wenn sie die certchecker-sqltables-1.0.sql nicht manuell verändert haben, so muss der Konfigurationspunkt der Datenbank wie folgt lauten: mysql.database=certchecker. Achten sie darauf, dass sie keine zusätzlichen Leerzeichen einfügen. Speichern sie die Datei und benennen sie sie in certchecker.properties um. Benennen sie diese Datei in certchecker.properties um. Achten sie darauf, dass sie keine zusätzlichen Leerzeichen einfügen. 5

4 CertChecker Installation Teil 2 4.1 Installation der Web Komponente Entnehmen sie der beigelegten CD-ROM die Datei: Installation/certchecker-web-1.0.zip. Entpacken sie diese in ein beliebiges Verzeichnis auf ihrem Rechner. Stoppen sie den Tomcat Server. Wechseln sie in das eben erstellte Verzeichnis und kopieren sie die Datei certchecker.war in das $TOMCAT HOME/webapps/ Verzeichnis ihrer Tomcat Installation. Starten sie den Tomcat Dienst anschliessend neu. Nach dem Neustart sollte Tomcat die.war Datei automatisch geöffnet und ein neues Verzeichnis $TOMCAT HOME/webapps/certchecker angelegt haben. Wie sie den Tomcat Dienst starten und stoppen entnehmen sie bitte der Dokumentation ihrer Plattform. 6

4.2 Anpassen der Web Konfiguration Damit die Web-Komponente ebenfalls auf die Datenbank zugreifen kann, muss die Konfiguration angepasst werden. Öffnen sie die Datei $TOMCAT HOME/webapps/certchecker/WEB-INF/jdbc.properties mit einem gewöhnlichen Texteditor. jdbc.driverclassname=com.mysql.jdbc.driver jdbc.url=jdbc:mysql://localhost:3306/certchecker jdbc.username=change this jdbc.password=change this Ändern sie hier nun die Optionen jdbc.username, jdbc.password und jdbc.url mit den Angaben, die sie vorher bei der Erstellung des MySQL Benutzers verwendet haben. Die letzte Angabe nach dem Slash der jdbc.url ist die Datenbank, in der sich die Tabellen befinden. Wenn sie die certchecker-sqltables-1.0.sql nicht manuell verändert haben, so muss der Konfigurationspunkt der Datenbank wie folgt lauten: jdbc.url=jdbc:mysql://localhost:3306/certchecker. Speichern sie die Datei und starten sie den Tomcat Server neu. Die Installation der Web-Komponente ist nun abgeschlossen. 7

4.3 Anpassen der Stand-Alone Konfiguration Damit die Web-Komponente die Bilder erhält, welche die Stand-Alone Komponente produziert, muss der Ausgabe Pfad für die Bild-Dateien in der Stand-Alone Konfiguration angepasst werden. Öffnen sie wieder mit einem gewöhnlichen Texteditor die Datei: $CERTCHECKER/certchecker.properties. image.directory=change this... Tragen sie hier den vollständigen Pfad zu folgendem Verzeichnis ein: $TOMCAT HOME/webapps/certchecker/images/. Speichern sie die Datei. Vergewissern sie sich, dass der Tomcat Dienst über genügend Rechte verfügt, um die von der Stand-Alone Komponente generierten Bilddateien zu lesen. Ansonsten werden die Bilder im Web-Interface nicht dargestellt. Unter Unix können sie eine neue Gruppe erstellen und den Benutzer, der die Stand-Alone Komponente ausführt, dieser Gruppe hinzufügen. Ändern sie dann das $TOMCAT HOME/webapps/certchecker/images/ Verzeichnis, damit dieses für die Gruppe Lese- und Schreibberechtigung erhält. Die Installation des ChertChecker Programms ist nun vollständig. 8

5 Anwendung 5.1 Starten der Stand-Alone Komponente Der Sinn und Zweck der Stand-Alone Komponente ist es, Daten in einem Interval von einer Stunde in die Datenbank zu schreiben. Dazu können sie unter Unix/Linux das mitgelieferte Script: runhourly.sh starten, welches die Stand-Alone Komponente startet und nach einem ersten Durchgang für eine Stunde schlafen legt. Unter Windows können sie die Stand-Alone Komponente wie folgt starten, um den selben Effekt zu erzielen: java -jar certchecker.jar -t 5.2 Importieren von X.509 Zertifikaten Um Zertifikate in die Stand-Alone Komponente zu importieren, müssen diese lediglich in das $CERTCHECKER/import Verzeichnis kopiert werden. Beim nächsten Ausführen werden die Zertifikate eingelesen und entsprechend abgelegt. 9

5.3 Konfigurationsparameter der Stand-Alone Komponente Diese Parameter können in der $CERTCHECKER/certchecker.properties Datei vorgenommen werden: Parameter Beschreibung database.type MYSQL HSQLDB Welche Datenbank soll für die Speicherung der Daten verwendet werden. Wenn auch die Web-Komponente verwendet werden soll, kann nur MYSQL ausgewählt werden. mysql.host Adresse des Rechners, auf dem die Datenbank installiert ist mysql.port Port der MySQL Datenbank. Default: 3306. mysql.username Username des MySQL Benutzers mysql.password Passwort des MySQL Benutzers mysql.database Datenbank, welche die certchecker Tabellen beinhaltet hsql.file Datei, in der die Daten der HSQLDB Datenbank gespeichert werden soll hsql.username Username des HSQLDB Benutzers hsql.password Passwort des HSQLDB Benutzers cert.directory Verzeichnis, in dem die importierten Zertifikate abgelegt werden sollen image.directory Verzeichnis, in dem die generierten Bilder der Stand-Alone Komponente abgelegt werden sollen cert.keystore dir Verzeichnis, in dem eine KeyStore Datei mit den importierten Zertifikaten abgelegt werden soll cert.keystore pwd Passwort für die KeyStore Datei cert.import dir Verzeichnis, aus dem neue Zertifikate importiert werden certchecker.debug true false Gibt mehr Informationen als üblich aus log.file Datei, in der die Ausgabe der Stand-Alone Komponente gespeichert werden soll certchecker.silent true false Unterbindet jegliche Ausgabe in der Konsole ntp.host Time-Server um die Uhrzeit abzugleichen 10

5.4 Webinterface Im folgenden Kapitel wollen wir das Webinterface zeigen und die verschiedenen Funktionen kurz erläutern. 5.4.1 Einstiegs - Site Mit der Einstiegs - Site wird der Benutzer auf der Webpräsentation von CertChecker begrüsst. Abbildung 5.1: Welcome Auf dieser Welcome - Seite wird nochmals kurz etwas zu CertChecker erklärt. Dabei sieht man auch das Update - Datum, zu welcher Zeit das letzte Update der Zertifikatsdienste gemacht wurde. 11

5.4.2 Zertifikate Auf der Zertifikats - Site werden die verschiedenen Zertifikate dargestellt, welche zu diesem Zeitpunkt in der Datenbank vorhanden waren und welche regelmässig geprüft werden. Abbildung 5.2: Certificates 12

5.4.3 CRL Resultate Die Übersicht der CRL Resultate zeigt, wie aktuell die Liste ist und welche prozentuale Verfügbarkeit die einzelnen Dienste haben. Abbildung 5.3: CRL Resultate Mit einem Klick auf einen der Links kann man sich die Grafik zur Statistik ansehen. Auf Screen 6.4 sieht man die Darstellung der ersten CRL http://crl.thawte.com/thawtesgcca.crl im 30 Tage Überblick. Abbildung 5.4: CRL Grafik 13

5.4.4 OCSP Resultate Genau wie bei den CRL Resultaten sieht man hier die Resultate, welche die jeweiligen OCSP Server liefern. Abbildung 5.5: OCSP Resultate 14