„Konzeption einer Public Key Infrastructure für die FHTW“

Transcription

Freie wissenschaftliche Arbeit
zur Erlangung des akademischen Grades eines
Diplom-Informatikers (FH)
über das Thema
„Konzeption einer Public Key
Infrastructure für die FHTW“
eingereicht im Fachbereich 4, Studiengang Internationale Medieninformatik der
Fachhochschule für Technik und Wirtschaft Berlin
Kristian Rabe, Matrikelnr. s0329986
Betreuer: Prof. Dr. Messer
Berlin, Oktober 2003
Inhaltsverzeichnis
I
Inhaltsverzeichnis
Danksagung .................................................................................................................... II
Abkürzungsverzeichnis ...............................................................................................III
Abbildungsverzeichnis..................................................................................................IV
Tabellenverzeichnis ....................................................................................................... V
1.
Einleitung................................................................................................................ 8
1.1
Zielsetzung der Arbeit ................................................................................... 12
1.2
Vorgehensweise und Gliederung ................................................................... 13
1.3
Einführung in die Kryptographie................................................................... 14
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.4
2.
Symmetrische Verschlüsselung .............................................................. 15
Asymmetrische Verschlüsselung............................................................ 16
Hashalgorithmen..................................................................................... 18
Digitale Signatur ..................................................................................... 19
Nichtabstreitbarkeit................................................................................. 20
Zertifikate................................................................................................ 20
Vertrauensmodelle .................................................................................. 21
Public Key Infrastructure............................................................................... 22
State of the Art PKI ............................................................................................. 25
2.1
2.1.1
2.1.2
2.1.3
2.2
2.2.1
2.2.2
2.2.3
2.3
2.3.1
2.3.2
2.3.3
PKI-Entwicklungen in Bildungseinrichtungen.............................................. 25
Humboldt Universität Berlin .................................................................. 25
Technische Universität Berlin ................................................................ 26
Technische Fachhochschule Berlin ........................................................ 26
Kommerzielle PKI-Entwicklungen................................................................ 27
RSA Security .......................................................................................... 27
Entrust Technologies .............................................................................. 27
Baltimore Technologies.......................................................................... 28
Non-Profit-PKI-Entwicklungen..................................................................... 28
Bundesamt für Sicherheit in der Informationstechnik (BSI) .................. 28
TeleTrusT Deutschland e.V.................................................................... 29
National Security Agency (NSA) ........................................................... 29
Inhaltsverzeichnis
3.
I
Die FHTW PKI .................................................................................................... 30
3.1
Wozu überhaupt eine eigene PKI?................................................................. 30
3.2
Anwendungszenarien für die Fachhochschule .............................................. 31
3.2.1
3.2.2
3.2.3
3.2.4
4.
Single Sing-On (SSO)............................................................................. 32
Verschlüsselter E-Mailverkehr ............................................................... 34
Notenabfragesystem für Studenten......................................................... 38
Einführung von sicheren Remote-Zugriffen........................................... 39
Prozesse und Lebenszyklen................................................................................. 40
4.1
Low Level Zertifizierung............................................................................... 42
4.2
Medium Level Zertifizierung......................................................................... 51
4.3
High Level Zertifizierung .............................................................................. 53
4.4
Sperren von Zertifikaten ................................................................................ 55
4.4.1
4.4.2
4.4.3
4.4.4
Sperrung durch die Certification Authority ............................................ 55
Sperrung durch den Benutzer ................................................................. 56
Temporäres Sperren von Zertifikaten ..................................................... 57
Erneuerung von Zertifikaten................................................................... 57
5.
Organisatorische Details zur PKI ...................................................................... 58
6.
Aufbau der Zertifikate und Sperrlisten............................................................. 65
6.1
Schlüsselzertifikate ........................................................................................ 66
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.2
Sperrlisten ...................................................................................................... 72
6.2.1
6.2.2
6.3
Felder eines Schlüsselzertifikats............................................................. 67
Schlüsselerweiterungen für Schlüsselzertifikate .................................... 68
Richtlinienerweiterungen eines Schlüsselzertifikats .............................. 69
Teilnehmer und Ausstellerinformationen eines Schlüsselzertifikats...... 70
Zertifizierungspfad Erweiterungen ......................................................... 71
Felder einer Sperrliste............................................................................. 74
Sperrlistenerweiterungen ........................................................................ 75
Attributzertifikate........................................................................................... 77
7.
Risiken und Probleme beim Einsatz von PKI ................................................... 81
8.
Certification Practice Statement ........................................................................ 83
9.
Ausblick ................................................................................................................ 86
Eidesstattliche Erklärung............................................................................................. 87
Literaturverzeichnis ..................................................................................................... 88
Anhang........................................................................................................................... 93
Danksagung
II
Danksagung
Ich möchte mich bei folgenden Personen für die erfolgreiche Realisierung dieser
Diplomarbeit bedanken:
Prof. Dr. Burkhard Messer für die sehr gute Unterstützung als Betreuer während der
Diplomarbeit. MVP – Most Value Professor. Michael Bell von der HU Berlin für
wertvolle Einsichten in den praktischen Betrieb einer Public Key Infrastructure. Theorie
klingt toll, Praxis ist etwas ganz anderes. Meiner Familie und meinen Großeltern für all
die Unterstützung während des Studiums, vor allem wenn einmal Not am Mann war.
Meiner Mitbewohnerin und guten Freundin Jana Reins, die mich während meiner
Diplomarbeit ertragen musste und auch immer einen guten Ratschlag hatte. dooy4oo
und im besonderen Carsten Luther, da ich ohne das Praktikum bei Euch mein Studium
nicht so schnell hätte beenden konnte. Ich hatte sehr viel Spaß bei euch und hab viel
gelernt. Herr Luchterhand und Jana Praprotnik für die Fehlerkorrektur meiner Arbeit.
Ohne euch hätte ich wohl allein einen Monat gebraucht, um alle Fehler zu finden.
Robert Kallwies für viele Hinweise und Anregungen zu meiner Diplomarbeit,
insbesondere wegen meinem anfangs zu allgemeinen Schreibstil. Daniel „Honke“
Henze für die gelungene Zusammenarbeit während der Diplomzeit. Noch einmal Robert
und Honke, Oliver Thiel und John Holzmann für einige lustige Abende, die die stressige
Zeit erträglich gemacht haben. Hoffentlich bleibt das weiterhin so. Ronny „Sanchez“
Dethloff, Fabian „Fab5Freddy“ Renner und Maik Surber ebenfalls für Ablenkung und
einfach nur Fun, vor allem beim Snowboarden und Skifahren. Keep on rockin!!!
Alexander Weißbach, Franziska Lenz, Jana Praprotnik, Jana Reins, Daniel Heilmann
und Michael Pape für all die schönen Urlaubserzählungen und Fotos. Ich wäre auch
gern in Costa Rica, Bulgarien, Schweden, Zypern oder Japan gewesen, musste aber an
meinem Diplom arbeiten. Anstatt mir in Berlin zur Seite zu stehen, lasst ihr Euch lieber
die Sonne auf den Bauch scheinen ☺. Gino „Ginelli“ Fuchs möchte ich dafür danken,
dass er einer der wenigen war, der nicht weg gefahren und in Berlin geblieben ist – altes
Arbeitstier. Anja Wienecke für all die schönen Urlaubskarten aus all den verschiedenen
Orten. Ich hoffe, wir sehen uns in Kanada.
Ein großes Dankeschön geht auch an:
Mario „Debian God“ Fürderer und Michael Weis aus Vöhrenbach (ohne IRC wüsstet
ihr heute noch nicht wo Berlin liegt), Ralf „Hawk” Habicht (das lustigste Gollum wo
gibt auf die Welt). Sandra Viig Rassmussen (DK Power), Swen Stötzer (Arena !!!),
Manuel Nater (alter Schwede), Janine Lohse und Matthias Seidel (unsere Botschafter
im Land der Dummheit) und Jan Fornfeist (heiratet einfach ohne was zu sagen) und an
alle, die jetzt nicht ausdrücklich namentlich erwähnt wurden.
Abkürzungsverzeichnis
Abkürzungsverzeichnis
AA ..................... Attribute Authority
CA...................... Certification Authority
CPS .................... Certification Practice Statement
CRT.................... Certificate Revokation Tree
ECC.................... Elliptic Curve Cryptosystem
LDAP ................. Lightweight Directory Access Protocol
MAC .................. Message Authentification Code
MDC .................. Modification Detection Code
PKI ..................... Public Key Infrastructure
PMI .................... Privilege Management Infrastructure
PSE..................... Personal Security Environment
OTP.................... One Time Password
RA...................... Registration Authority
RFC.................... Request For Comment
RSA.................... Rivest, Shamir, Adleman
SE....................... Security Environment
SSL..................... Secure Socket Layer
SSO .................... Single Sign-On
USB.................... Universal Serial Bus
III
Abbildungsverzeichnis
IV
Abbildungsverzeichnis
Abb.1
Symmetrische Verschlüsselung .................................................................... 15
Abb.2
Asymmetrische Verschlüsselung.................................................................. 16
Abb.3
Kryptografischer Hashalgorithmus............................................................... 18
Abb.4
Erzeugen einer digitalen Signatur................................................................. 19
Abb.5
Public Key Infrastructure Bausteine ............................................................. 22
Abb.6
Single Sign-On als Beispiel .......................................................................... 33
Abb.7
E-Mail Verschlüsselung mit Hashfunktion................................................... 34
Abb.8
E-Mailentschlüsselung mit Hashfunktion..................................................... 35
Abb.9
Abstrakte Abbildung der Fachhochschulstruktur ......................................... 40
Abb.10
Teil der Erstzertifizierung, E-Mail Konto und OTP Liste Variante 1 .......... 44
Abb.11
Erstzertifizierung Low Level Variante 1 ...................................................... 46
Abb.12
Teil der Erstzertifizierung, E-Mail Konto und OTP Liste Variante 2 .......... 48
Abb.13
Erstzertifizierung Low Level Variante 2 ...................................................... 50
Abb.14
Generieren einer Passwortliste...................................................................... 62
Abb.15
Mechanismus für Passwortliste .................................................................... 63
Abb.16
Aufbau und Funktionsweise eines Sperrbaumes .......................................... 73
Abb.17
Zusammenspiel von Schlüssel- und Attributzertifikat.................................. 79
Abb.18
Konzept für Anwendung von Attributzertifikaten bei Single Sign-On ........ 80
Tabellenverzeichnis
V
Tabellenverzeichnis
Tab.1
RSA Laboratories Bullentin Nr.13, April 2000............................................ 14
Tab.2
Aufbau eines Zertifikats (X.509 V3) ............................................................ 66
Tab.3
Felder eines Schlüsselzertifikats ................................................................... 67
Tab.4
Schlüsselerweiterungen für Schlüsselzertifikate........................................... 68
Tab.5
Richtlinienerweiterungen eines Schlüsselzertifikats..................................... 69
Tab.6
Teilnehmer und Ausstellerinformationen eines Schlüsselzertifikats............ 70
Tab.7
Zertifizierungspfad Erweiterungen ............................................................... 71
Tab.8
Aufbau einer Sperrliste ................................................................................. 73
Tab.9
Felder einer Sperrliste ................................................................................... 74
Tab.10
Sperrlisten Erweiterungen Teil 1 .................................................................. 75
Tab.11
Sperrlisten Erweiterungen Teil 2 .................................................................. 76
Tab.12
Aufbau eines Attributzertifikats.................................................................... 77
Tab.13
Felder eines Attribut Zertifikats.................................................................... 78
State of the Art PKI
8
1. Einleitung
Cybercrime, Wirtschaftsspionage, Viren und Trojanische Pferde, Spoofing von EMailadressen oder des Domain Name Systems, das Mitlesen fremder E-Mails, gehackte
Webseiten, falsch konfigurierte und implementierte Hard- und Software, dies ist nur
ein kleiner Teil, der das Internet, Firmennetzwerke und Computer in einem unsicheren
Licht dastehen lässt.
Das Lesen von aktuellen Berichten über IT-Sicherheit und die in dem Zusammenhang
bestehenden Probleme lässt auch technisch versierte Menschen schnell das Vertrauen in
Technik und Software verlieren. Fragwürdig ist, warum es so viele Sicherheitslöcher in
teurer Software gibt, bzw. wieso fast jeder von IT-Sicherheit spricht, aber es nur wenige
richtig umsetzen.
Hundertprozentige Sicherheit kann es nie geben, auch wenn uns die Werbung täglich
etwas anderes versprechen will. Die Wirtschaft verfährt in vielen Fällen lieber nach dem
Motto: ‚Es gab noch nie große Probleme mit der IT-Sicherheit bei uns. Solange nichts
passiert, können wir das Geld für die IT-Sicherheit unserer IT-Infrastruktur sparen.’
Die Hoffnungen, die in das Internet gesetzt wurden, haben sich nicht vollständig
bestätigt und die Boomjahre in der Informationstechnologie sind erst einmal vorbei.
Firmen wagen keine größeren finanziellen Investitionen, das Geld sitzt nicht mehr
locker. IT-Sicherheit ist jedoch ein Bereich in den auch in wirtschaftlich guten Zeiten
eher wenig investiert wird.
Natürlich ist es fahrlässig, vertrauensvolle Kundendaten oder Firmeninterna nicht
ausreichend zu schützen. Schnell ist der mühevoll aufgebaute gute Ruf dahin und das
Vertrauen der Kunden weg.
Auch für Privatpersonen kann IT-Sicherheit lohnenswert sein, zum Beispiel beim
Signieren und Verschlüsseln von E-Mails oder um den eigenen Laptop mit
verschlüsselter Festplatte vor unbefugtem Zugriff zu schützen. Über das Projekt
ELSTER kann jeder Bürger seine Steuerklärung online ausfüllen und signiert an die
Finanzämter schicken.
Es gibt einfache und komplizierte Möglichkeiten eine IT-Infrastruktur sicherer zu
gestalten und Angreifern das Eindringen in Systeme schwer zu machen. Angreifern das
Handwerk zu legen ist kompliziert, ausgehend vom Standpunkt, da auszugehen ist, dass
potentielle Angreifer immer mit fast unbegrenzten Ressourcen und Wissen agieren
können1 und laut Murphys Gesetz immer schlauer sind als man denkt.
Absolute Sicherheit ist auch nur das Wunschdenken einiger findiger
Marketingstrategen. Allenfalls halten sich Sicherungsmaßnahmen und Angriffstaktiken
die Waage und führen ein Kopf-an-Kopf-Rennen um neue Entwicklungen.
1
Murphys erstes Gesetz der Kryptografie
9
Geht es nach führenden Firmen in der Informationstechnologie, sollen bald
Kühlschrank, Toaster und sogar Bügeleisen vernetzt miteinander kommunizieren. Ob es
auch dort zu gefährlichen Angriffen kommt, bleibt abzuwarten.
Aus diesem Grund ist es besser, Software richtig zu implementieren und Netzwerke
dem aktuellen Sicherheitsbedarf anzupassen. Doch genau darin liegt oftmals die
Schwierigkeit. Selbst Banken und Kreditkartenunternehmen sind oft kleine und große
Fehler beim Implementieren bzw. beim Betreiben von sicheren Arbeitsumgebungen
unterlaufen.
So gelang es Hackern zum Beispiel immer wieder Bankkonten auszuspionieren und zu
manipulieren oder ganze Listen von Kreditkartennummern zu entwenden. Beliebt ist
auch das Stehlen fremder Identitäten und deren Missbrauch. Dank unzureichender
Sicherheitsmaßnahmen bleiben sogar große Firmen wie Ebay nicht davon verschont. 1
Um im zum größten Teil anonymisierten Internet etwas mehr Vertrauen und damit auch
Sicherheit zu erreichen, ist die Einführung von Zertifikaten auf Basis einer Public Key
Infrastructure ein möglicher Lösungsansatz. Konzepte und Lösungen sind hierfür
bereits seit längerer Zeit vorhanden. Leider bedarf es noch großer Anstrengungen sowie
Akzeptanz bei den Benutzern, um solche Systeme bezahlbar und interoperabel
durchzusetzen.
Durch Zertifikate können sich zum Beispiel Bank- oder E-Commerce-Server gegenüber
dem Benutzer glaubhaft zu erkennen geben. Mit dieser Maßnahme ist es möglich
Vertrauen zu Kunden aufzubauen, welche den bisherigen Systemen misstrauisch
gegenüberstanden. Eine Verbreitung dieser Technologie hat dann zur Folge, dass ein
kleiner Schritt in Sachen größere IT-Sicherheit getan wird.
Das bringt wiederum Vorteile für die Public Key Infrastructure (PKI) Technologie
selbst. Durch die immer größer werdende Verbreitung der Public Key Infrastructure
Technologie kommen immer mehr Menschen mit der noch relativ unbekannten und
neuen Technologie in Kontakt und können so Vorurteile, Ängste und Bedenken durch
eigene Erfahrungen im Umgang mit der Technologie beseitigen.
Die Sicherheit im Computerbereich allgemein profitiert ebenfalls davon.
Kommunikationswege können sicherer gestaltet werden und digitale Signaturen können
bei entsprechender technischer Infrastruktur in Zukunft den gleichen rechtlichen Status
wie eine eigenhändige Unterschrift erhalten. Das Signaturgesetz hierfür wurde bereits
novelliert.
E-Commerce und E-Government Prozesse können mit Hilfe von Public Key
Infrastructure Technologie schon in ihrer Grundstruktur sicher werden. Zum Beispiel
planen Finanzämter bereits mit Hilfe von PKI die Abgabe der Steuererklärung und
anderer wichtiger Finanzinformationen online zu ermöglichen. Eine Zertifizierung nach
dem Signaturgesetz würde die Onlinehändler rechtlich besser stellen als bisher. Zudem
profitieren Kunden und Händler vom größeren Vertrauen zueinander.
1
Quelle: c't 16-2003, S_ 32 Online-Auktion.htm (www.heise.de)
10
Es scheint, der Einsatz von Public Key Infrastructure bringt nur Vorteile. Warum hat
sich die Technologie noch nicht stärker durchgesetzt? Dies resultiert vor allem daher,
dass PKI eine sehr komplexe und schwierige Technologie ist, bei der es keine Fehler in
der Implementierung geben darf. Je größer eine PKI am Ende realisiert wird, desto mehr
Personal ist für den Betrieb nötig.
Für Registrierungsprozesse, Sperrlisten und Zertifikatserstellung muss Personal
angestellt werden. Bestimmte Certification Authority Prozesse benötigen zudem ein
Vieraugenprinzip von Certification Authority Administratoren. Zudem müssen Banken
und Börsenzertifikate beispielsweise rund um die Uhr, möglichst sekundengenau,
abrufbar und aktuell sein.
Diese Aktualität der Zertifikate und Sperrlisten 24 Stunden am Tag aufrecht zu erhalten,
inklusive Urlaubsvertretungen und Ausfällen bei Krankheit, treibt die Kosten für den
Betrieb einer PKI in die Höhe. Das Geld muss dann durch PKI-Anwendungen und
Geschäftsprozesse direkt oder indirekt refinanziert werden.
Allgemein sind nicht die Anschaffungskosten von Hard- und Software für die hohen
finanziellen Belastungen im IT-Bereich verantwortlich. Der Betrieb von IT-Anlagen
und der Support verbrauchen einen Großteil der Finanzen. Dies ist bei einer Public Key
Infrastructure nicht anders. Sicherheit kostet Geld und wird es nicht umsonst geben.
Durch geeignete Anwendungen können diese Kosten jedoch gesenkt werden.
Einnahmequellen bieten sich auch an, wenn Serverzertifikate gegen Geld auch für
andere Unternehmen ausgestellt werden.
Die Hochschullandschaft in Deutschland befindet sich seit Jahren in einer finanziell
angespannten Lage. Umso wichtiger ist es, bei der Einführung von neuen und teuren
Techniken und Infrastrukturen, vorher ein gutes Konzept zu erarbeiten. Mit Hilfe eines
Konzeptes kann festgestellt werden, ob sich für die neue Technologie brauchbare
Anwendungen finden lassen, ob sich das Konzept finanziell tragen lässt, wo eventuell
Probleme bei der Umsetzung liegen und in welchen Schritten die spätere Realisierung
stattfinden sollen. Dieses Konzept soll später dazu beitragen, eine erfolgreiche
Realisierung zu ermöglichen.
Für Fachhochschulen bieten sich bei der Nutzung einer Public Key Infrastructure vor
allem Einsparungen durch die Umstrukturierung fachhochschulinterner Prozesse, wie
beispielsweise Benachrichtigungen bei Auswahlgesprächen und die Verteilung
offizieller Nachrichten der Fachhochschule, an.
Durch Authentifizieren, Signieren, Ver- und Entschlüsseln von E-Mails und die
Benutzung von sicheren Netzwerkverbindungen können viele Arbeitsprozesse an einer
Fachhochschule wesentlich schneller und kostengünstiger auf elektronischem Weg
erledigt werden als bisher. Dadurch können Bereiche wie die Fachhochschulverwaltung,
die Personalabteilung sowie Hochschulleitung, Angestellte und die Fachbereiche viel
Geld und Zeit sparen.
11
Elektronische Prozesse lassen sich auch von zu Hause erledigen, was eine
Serviceverbesserung für Studenten und Mitarbeiter bedeutet. Teure und langwierige
Arbeitsabläufe werden optimiert, gestrafft und kostengünstiger gestaltet. Die
Fachhochschule gewinnt nebenbei noch Prestige, da der Einsatz von neuer Technologie
natürlich auch für mögliche Studienanfänger und Firmen interessant sein kann.
Das oberste Ziel einer Public Key Infrastructure ist es, die Sicherheit innerhalb und
außerhalb von Netzwerken zu erhöhen. Rechner von Fachhochschulen sind oft Ziel von
destruktiven Subjekten, auch Studenten sammeln oft erste Erfahrungen im Ausnutzen
von Sicherheitslücken an der Fachhochschule.
Mit Hilfe einer PKI kann die allgemeine Sicherheit der Netzwerke an der
Fachhochschule erhöht werden. Laborrechner und andere Computer an der
Fachhochschule können besser vor Eindringlingen geschützt werden. Gerade
Laborrechner sind durch den Übungsbetrieb innerhalb der Labore oft unzureichend
geschützt.
An Hochschulen soll auch Forschung betrieben werden. Eine Hochschule sowie ihre
Studenten profitieren früher oder später immer vom selbst aufgebautem Know-How.
Natürlich ist es auch für Studenten interessant in den Kontakt mit neuen Technologien
zu kommen. Sie profitieren später durch erworbenes Wissen und praktische
Erfahrungen bei zukünftigen Arbeitgebern.
Die Einführung einer Public Key Infrastructure an einer Fachhochschule ist auch eine
Modernisierung der vorhandenen IT-Infrastruktur als ein zusätzlicher Baustein. Zudem
ist die Verbreitung der PKI-Technologie an Fachhochschulen noch nicht sonderlich
fortgeschritten. Es lässt sich also mit einem guten Konzept und einer erfolgreichen
Realisierung eine gewisse Vorreiterrolle auf diesem Gebiet erreichen.
All diese Gründe tragen dazu bei, ein Konzept zur Einführung einer Public Key
Infrastructure an der Fachhochschule für Technik und Wirtschaft zu entwerfen.
12
1.1 Zielsetzung der Arbeit
In der Diplomarbeit wird ein Konzept für eine Public Key Infrastructure an der
Fachhochschule für Technik und Wirtschaft (FHTW) in Berlin erarbeitet. Im Projekt
Musical werden im Rahmen des Teilprojektes Trust die Sicherheitsaspekte von Musical
bearbeitet. An der FHTW soll hierfür eine Public Key Infrastructure eingeführt werden.
Mithilfe dieses Konzeptes soll es später den Mitarbeitern der FHTW ermöglicht
werden, schnell und einfach eine Public Key Infrastructure aufzubauen. Der Autor geht
in seinem Teil der Diplomarbeit auf die organisatorischen Sachverhalte beim Aufbau
einer PKI ein. Schwerpunkte sind Registrierungs- und Sperrprozesse, Zertifikatsaufbau
sowie mögliche Anwendungen.
Das organisatorische Konzept soll den zukünftigen Betreibern der PKI die Einarbeitung
in die Thematik erleichtern und das Lesen von diversen Fachbüchern zum Thema
verringern. Um jedoch vertiefendes Wissen im Bereich Verschlüsselung und Public Key
Infrastructure zu erhalten, wird das Studieren von Fachliteratur auf jedem Fall
empfohlen.
In dieser Arbeit werden keine Techniken oder Technologien erklärt oder ausgewählt. Es
handelt sich um ein Konzept mit Beispielen für einzelne Bereiche. Diese Beispiele sind
keine technischen Ausarbeitungen, die so umgesetzt werden können. Sie dienen
lediglich zur Begründung des Gesamtkonzepts. Ein technisches Beispiel für die
Umsetzung dieses Konzeptes bietet die Diplomarbeit von Daniel Henze.
Beide Diplomarbeiten zusammen stellen das Gesamtkonzept für eine mögliche PKI an
der FHTW dar. Das gemeinsame Ziel ist es, anhand beider Diplomarbeiten eine PKI an
der FHTW zu realisieren und in Betrieb zu nehmen.
Ein weiteres Ziel bei der Erstellung dieses Konzeptes war es, das Konzept so zu
gestalten, dass es auch für andere Fachhochschulen interessant sein kann. So könnte
dieses Konzept auch in leicht abgewandelter Form an anderen Fachhochschulen
umgesetzt werden.
13
1.2 Vorgehensweise und Gliederung
Um den Einstieg in die Thematik PKI dem Leser zu erleichtern, werden zuerst
grundlegende Begriffe und Bausteine der Public Key Infrastructure erklärt. Zudem
erhält der Leser eine Einführung in die Verschlüsselungsmechanismen und Techniken.
Jedoch wird die Thematik Verschlüsselung und PKI nicht komplett erklärt, da dies den
Rahmen der Diplomarbeit sprengen würde. Dazu wird das Lesen weiterer Fachliteratur
empfohlen. Interessante Bücher hierzu finden sich im Literaturverzeichniss.
Tiefergehende Literaturhinweise gibt es auch am Ende der jeweiligen Kapitel.
Der Autor betrachtet dann den Ist-Zustand von PKI an Universitäten mit dem
Schwerpunkt Berlin und gibt einen Ausblick auf andere bedeutende kommerzielle und
nichtkommerzielle PKI-Projekte. Es wird sich herausstellen, dass nur wenige
Fachhochschulen und Universitäten sich mit PKIs beschäftigt haben und die fast alle
Realisierungen im experimentellen Stadium sind. Dies gilt auch für die dazugehörenden
PKI-Konzepte, so dass mit der vorliegenden Konzeption für die FHTW in einigen
Bereichen Neuland betreten werden musste.
Desweiteren erstellt der Autor eine Anforderungsanalyse für eine PKI an der FHTW mit
möglichen Anwendungsprozessen und Einsatzmöglichkeiten, welche an Beispielen
erklärt werden.
Es wird das Konzept für eine PKI an der FHTW vorgestellt und detailliert beschrieben.
Die drei Level mit ihren Besonderheiten werden erklärt. Dazu werden einige
Registrationsprozesse ausführlich erläutert. Die hier definierten Prozesse sind dabei
genau auf die Begebenheiten der Fachhochschule abgestimmt. Einige Bausteine der
Public Key Infrastructure werden zusätzlich beschrieben.
Darüber hinaus betrachtet der Autor die besonderen Schwierigkeiten einer PKI an
Universitäten und Fachhochschulen, wie zum Beispiel Aufbau und Funktionsweise der
verschiedenen Zertifikate (Schlüsselzertifikate, Sperrlisten, Attributzertifikate).
Nach Gesprächen mit Betreibern der Bridge-CA stellte sich heraus das
Attributzertifikate zwar theoretisch beschrieben sind, praktisch aber keine Verwendung
finden. Deshalb werden Attributzertifikate in diesem Konzept eine Rolle bei einer
möglichen Single Sign-On Lösung spielen.
Ebenfalls wird auf den Aufbau und die Verwendung von Certificate Policy und
Certification Practice Statement eingegangen.
Am Ende wird der Autor noch offen gebliebene Sachverhalte ansprechen und einen
möglichen Ausblick auf weitere Aufgaben im Zusammenhang mit dieser Diplomarbeit
und dem Aufbau der PKI aufzeigen.
14
1.3 Einführung in die Kryptografie
Public Key Kryptografie basiert auf einem öffentlichen und dem dazugehörigen
geheimen Schlüssel, welche gemeinsam ein Schlüsselpaar ergeben. Durch eine
vertrauenswürdige dritte Instanz (meist ein so genanntes Trustcenter oder eine
Certification Authority) wird die Identität des Schlüsselpaarbesitzers geprüft und
bestätigt.
Die öffentlichen Schlüssel werden einer Identität eindeutig zugeordnet, von der CA
digital signiert, in einem Zertifikat gespeichert und für andere Personen zum Abruf
bereit gestellt. Eine Identität ist ein Objekt (Person, Computer, Software) welches auf
bestimmte Informationen wie beispielsweise die Herkunft oder die Zugehörigkeit
überprüft worden ist.
Damit können sichere Kommunikationswege aufgebaut werden, ohne dass sich die
beteiligten Personen vorher kennen müssen. Das System steht und fällt mit der
Vertrauenswürdigkeit der Zertifizierungsinstanz. Diese muss Verhaltensregeln in Ihrer
Policy festlegen und befolgen sowie ihren eigenen geheimen Schlüssel vor Missbrauch
und Kompromittierung schützen.
Schlüssel werden benötigt, um Daten zu verschlüsseln und gesicherte
Kommunikationswege aufzubauen. Verschlüsselungsalgorithmen funktionieren ohne
entsprechende Schlüssel nicht. Ein Schlüssel ist eine Bitkette in einer bestimmten
Länge, die zum Verschlüsseln von Daten in einem kryptografischen Prozess angewandt
wird. Natürlich darf die Schlüssellänge nicht zu kurz gewählt werden, damit es
potentiellen Angreifern nicht zu einfach gemacht wird, den Schlüssel zu
kompromittieren.
Symmetrischer
Schlüssel
ECCSchlüssel
RSASchlüssel
∆t bis zur Kompromittierung
Anzahl der
Computer
Speicher
56
112
420
Weniger als 5
Minuten
10.000
Trivial
80
160
760
600 Monate
4.300
4GB
96
192
1020
3 Millionen
Jahre
114
170 GB
128
256
1620
10E16 Jahre
0,16
120 TB
Tab. 1: RSA Laboratories Bulletin Nr.13, April 2000, Quelle: RSA Laboratories Bulletins Bulletin #13
A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths.htm
Die Tabelle zeigt Richtwerte aus dem Jahr 2000 und welche Schlüssellänge bei
symmetrischer und asymmetrischer Verschlüsselung verwendet werden sollte, um
ausreichend geschützt zu sein. Um heutzutage sicher und vertrauensvoll arbeiten zu
können, werden für die symmetrische Verschlüsselung mindestens 96 Bit und bei
asymmetrischer Verschlüsselung mindestens 1024 Bit (besser 2048 Bit) Schlüssellänge
von führenden kryptografischen Unternehmen empfohlen.
15
Ein Schlüssel allein reicht nicht aus, es fehlt das Schloss. Schlösser sind in diesem Fall
kryptografische Verfahren, welche in symmetrische und asymmetrische
Verschlüsselungsverfahren eingeteilt werden.
1.3.1
Symmetrische Verschlüsselung
Bei der symmetrischen Verschlüsselung wird derselbe Schlüssel zur Ver- und
Entschlüsselung der Daten verwendet. Das Problem bei diesem Verfahren liegt im
Schlüsselaustausch.
Da beide Kommunikationspartner den selben Schlüssel benutzen, muss es einen
sicheren Weg geben, den Schlüssel zu übertragen, ohne dass dieser kompromittiert
werden kann. Neben diesem Nachteil kommt hinzu, dass sich eine symmetrische
Verschlüsselung nicht für digitale Signaturen eignet und auch die Funktionalität der
Nichtabstreitbarkeit fehlt.
Bei der Verwendung von mehreren symmetrischen Schlüsseln wird zudem ein
ausgereiftes Key-Management benötigt. Symmetrische Verschlüsselungsverfahren
haben aber auch Vorteile. Sie arbeiten sehr schnell und das Ergebnis sind sehr
kompakte verschlüsselte Datenpakete.
Abb.1: Symmetrische Verschlüsselung, Quelle: [NaDuJo]
Die bekanntesten symmetrischen Verschlüsselungsverfahren sind DES, IDEA und
Rijndael. Der sicherste Algorithmus überhaupt ist One Time Pad, leider ist er jedoch
unbrauchbar für mittlere und große Datenmengen, weil der Schlüssel gleich lang sein
muss wie die zu verschlüsselnde Datenmenge.
1.3.2
16
Asymmetrische Verschlüsselung
Bei der asymmetrischen Verschlüsselung wird mehr als ein Schlüssel verwendet. Es
wird ein Schlüsselpaar generiert, wobei ein Schlüssel öffentlich gemacht wird und ein
Schlüssel geheim bleibt. es ist nicht möglich von einem auf den anderen Schlüssel zu
schließen.
Bei der symmetrischen Verschlüsselung besteht das Problem des Schlüsselaustausches
für die Kommunikationspartner. Bei der asymmetrischen Verschlüsselung wird das
Problem durch einen privaten und einen öffentlichen Schlüssel gelöst, welche durch
Primfaktorzerlegung erzeugt werden.
Das Konzept hierzu stammt von Whitfield Diffie und Martin Hellmann. Entsprechend
wurde das Verfahren unter dem Namen Diffie-Hellmann-Verfahren bekannt. Mit
diesem Verfahren wird nur das Schlüsselaustauschproblem gelöst, es handelt sich nicht
um ein asymmetrisches Verschlüsselungsverfahren.
Bei der asymmetrischen Verschlüsselung werden die Daten mit einem der beiden
Schlüssel (geheim oder öffentlich) verschlüsselt. Die Daten können nur mit dem
dazugehörigen zweiten Schlüssel (geheim oder öffentlich) entschlüsselt werden.
Dadurch dass ein Schlüssel öffentlich für jeden abrufbar ist, wird das
Schlüsselaustauschproblem der symmetrischen Verschlüsselung gelöst.
Somit können zwei völlig unbekannte Personen sicher miteinander kommunizieren,
ohne dass sie vorher Schlüssel austauschen mussten. Zudem unterstützt die
asymmetrische Verschlüsselung digitale Signaturen und die Nichtabstreitbarkeit. Leider
ist die asymmetrische Verschlüsselung nicht ganz perfekt.
Abb.2: Asymmetrische Verschlüsselung, Quelle: [NaDuJo]
17
So dauert das Verschlüsseln der Daten wesentlich länger als bei der symmetrischen
Verschlüsselung. Die verschlüsselten Daten sind durch Overheadinformationen nach
der kryptografischen Prozedur größer als vorher.
Eine Symbiose aus asymmetrischer und symmetrischer Verschlüsselung kombiniert die
Vorteile beider Varianten und nähert sich einer idealen Lösung sehr stark. Die Nachteile
der beiden Verschlüsselungsverfahren werden dabei kompensiert.
So können die ausgetauschten Daten mit einem symmetrischen Schlüssel verschlüsselt
werden. Die Verschlüsselung erfolgt schnell und es werden kompakte Datenpakete
erzeugt. Der symmetrische Schlüssel wird mit dem öffentlichen Schlüssel der
Empfangsperson verschlüsselt.
Dieses sogenannte Envelope-Verfahren (digitaler Umschlag) ermöglicht einen sicheren
symmetrischen Schlüsselaustausch zwischen den Komunikationspartnern. Auf diese
Weise können sowohl der symmetrische Schlüssel als auch die Nachricht selbst sicher
übertragen werden.
Der Empfänger der Nachricht entschlüsselt den digitialen Umschlag und erhält den
symmetrischen Schlüssel mit dem er die verschlüsselte Botschaft entschlüsseln kann.
Zusammen mit Hash- und Timestamp Funktionen bildet eine Kombination aus
symmetrischer und asymmetricher Verschlüsselung die Grundlage für eine Public Key
Infrastructure.
Der bekannteste Algorithmus der asymmetrischen Verschlüsselung ist RSA, entwickelt
von Ron Rivest, Adi Shamir und Leonard Adleman. Es ist das mit Abstand wichtigste
und bekannteste Public Key Verfahren. Alle anderen Verfahren besetzen Nischen,
wurden kompromittiert oder finden keine praktische Anwendung, beispielsweise das
Verfahren auf Basis elliptischer Kurven (Elliptic Curve Cryptosystem - ECC).
1.3.3
18
Hashalgorithmen
Hashalgorithmen nehmen größere Datenmengen oder Dokumente und erzeugen daraus
einen sogenannten Diggest oder Fingerprint. Sie werden deshalb auch als
Komprimierungsalgorithmen bezeichnet.
Es gibt die Möglichkeit Modifikationserkennungswerte (MDC) von Nachrichten zu
bilden, mit denen der Empfänger die Integrität der Nachricht überprüfen kann. Wird der
Hashwert zusätzlich mit dem geheimen Schlüssel verschlüsselt, kann der Empfänger
mit dem öffentlichen Schlüssel des Absenders sowohl die Integrität als auch die
Herkunft der Nachricht überpüfen.
Ein kryptografischer Hash-Algorithmus sorgt zudem dafür, dass zwei unterschiedliche
Dateien niemals den gleichen Hashwert erhalten. Außerdem muss der Algorithmus
jederzeit verhindern, dass vom Hashwert auf den Klartext geschlossen werden kann.
Abb.3: Kryptografischer Hashalgorithmus, Quelle: [NaDuJo]
Bekannte kryptografische Hashalgorithmen sind SHA-1, RIPE-MD-160 und MD5,
wobei letzterer als nicht sicher gilt und aufgrund seiner Schlüssellänge von 128 Bit für
sicherheitskritische Anwendungen von führenden kryptografischen Unternehmen nicht
mehr empfohlen wird. 160 Bit gelten heutzutage als untere Grenze bei Schlüssellängen
für Hashalgorithmen – ebenfalls empfohlen von kryptografischen Experten. 1
1
Quelle: Empfehlung_Geeignete_Kryptoalgorithmen.pdf (www.secorvo.de)
1.3.4
19
Digitale Signatur
Bei der digitalen Signatur handelt es sich nicht um eine eingescannte Unterschrift des
Absenders oder Ähnliches. Vielmehr wird eine Nachricht mit dem geheimen Schlüssel
des Absenders verschlüsselt und an den Empfänger gesandt. Der Empfänger kann mit
dem öffentlichen Schlüssel des Absenders die Nachricht wieder entschlüsseln.
Da nur der Absender im Besitz des geheimen Schlüssels sein sollte, kann der
Empfänger davon ausgehen, dass die Nachricht wirklich vom Absender stammt. Mit
einem zusätzlichen Hashwert gewährleistet der Absender auch die Integrität der
Nachricht.
Digitale Signaturen müssen fälschungssicher sein. Zudem muss für den Empfänger die
Echtheit der Signatur überprüfbar sein. Sie darf nicht von einem Dokument auf ein
anderes übertragen werden können. Des Weiteren sollte das Dokument nicht unbemerkt
verändert werden können.
Abb.4: Erzeugen einer digitalen Signatur, Quelle: [NaDuJo]
In Deutschland trat 1997 das Signaturgesetz in Kraft, um digitalen Signaturen einen
ähnlichen Status vor Gericht zu geben wie einer Unterschrift von Hand.
Signaturgesetzkonforme Signaturen sind also rechtskräftig vor Gericht, jedoch nicht in
allen Fällen. Durch die hohen Anforderungen des Signaturgesetzes gelten diese
Signaturen als weitgehend sicher.
1.3.5
20
Nichtabstreitbarkeit
Dokumente können mit Hilfe von Signaturen vor Manipulation geschützt werden. Es
gibt jedoch Fälle, wo dies nicht ausreicht. Wenn ein Vertrag unterschrieben werden soll
und beide Vertragspartner sicher gehen wollen, dass der jeweils andere nicht behaupten
kann, den Vertrag nicht unterschrieben zu haben, wird ein weiteres Element benötigt:
die Angabe des Zeitpunktes.
Mit Hilfe der Zeit erhält die digitale Signatur die Eigenschaft der Nichtabstreitbarkeit.
Die Zeit kann vor oder nach der Generierung des Hashwertes hinzugefügt werden. Das
Schwierige ist hierbei einen zuverlässigen, vertrauenswürdigen und genauen Zeitgeber
zu finden, beispielsweise eine Atomuhr.
Zudem müssen die Betreiber der Zeitgeber zuverlässig und unabhängig sein, um eine
Manipulation der Uhrzeit zu verhindern. Die Zeitgeber selber signieren also ihre
herausgegebenen Uhrzeiten und werden von einer Certification Authority zertifiziert.
1.3.6
Zertifikate
Zertifikate sind Dokumente, die einen öffentlichen Schlüssel einer bestimmten Person
oder einem Objekt zuordnen und eine Vertrauensbasis schaffen. Dazu wird die Person
oder das Objekt von einer vertrauenswürdigen dritten Instanz nach bestimmten Regeln
authentifiziert und zertifiziert.
Die Certification Authority beglaubigt die öffentlichen Schlüssel der Identitäten und
fügt diese mit anderen Informationen in ein Zertifikat ein. Das Zertifikat wird von der
Certifiaction Authority mit ihrem geheimen Schlüssel signiert.
Zertifikate erleichtern den Umgang mit den verschiedenen Schlüsseln und erhöhen die
Glaubwürdigkeit der Schlüssel. Zertifikate können schnell und einfach gesperrt werden,
ohne dass jeder Kommunikationspartner einzeln informiert werden muss. Das
Vertrauensniveau steigt ebenfalls, vorausgesetzt beide Komunikationspartner vertrauen
der jeweiligen Certification Authority.
1.3.7
21
Vertrauensmodelle
Die Authentizität von öffentlichen Schlüsseln lässt sich ohne zusätzliche Infrastruktur
nur schwer feststellen. Wem der öffentliche Schlüssel gehört, lässt sich mit
Vertrauensbeziehungen darstellen und lösen.
Direct Trust
Direct Trust ist das einfachste Vertrauensmodell. Ein Benutzer vertraut nur seinen
direkten bekannten Nachbarn. Dessen Vertrauensbeziehungen zu weiteren Benutzern
werden nicht anerkannt. Direct Trust ist nur begrenzt, für wenig anspruchsvolle
Applikationen anwendbar.
Web of Trust
Das Vertrauensmodell Web of Trust basiert auf der Pretty Good Privacy (PGP)
Technologie. Jeder Benutzer beglaubigt per Zertifikat die öffentlichen Schlüssel ihm
vertrauter Personen. Diese Personen stehen in weiteren Vertrauensverhältnissen zu
anderen Personen. Den daraus entstehenden indirekten Beziehungen wird ebenfalls
vertraut.
In der Praxis ist das Web of Trust jedoch nicht vollständig vernetzt und es entstehen
Lücken und Inseln des Vertrauens. Der große Nachteil des Web of Trust ist die geringe
Kontrolle der gegenseitig ausgestellten Zertifikate und der damit entstehenden
indirekten Vertrauensverhältnisse.
Hierachical Trust
Eine vertrauenswürdige dritte Partei (Trusted Third Party – TTP) wird von allen
Zertifikatsbesitzern so akzeptiert, dass auch ihnen unbekannte Zertifikate der selben
Certification Authority vertraut werden. Über Policies werden Regeln zum Zertifizieren
herausgegeben, an die sich die Certification Authority und die Zertifikatsbesitzer halten
müssen. Dadurch wird nachprüfbares Vertrauen gegenüber allen Teilnehmern
aufgebaut.
22
1.4 Public Key Infrastructure
Eine Public Key Infrastructure (PKI) ermöglicht mit Hilfe von Zertifikaten eine sichere
Authentifizierung, Autorisierung und Kommunikation zwischen Personen und Objekten
sowie eine sichere Verschlüsselung von Daten für sicherheitsrelevante Strukturen.
Diese Infrastruktur lässt sich in mehrere Bausteine einteilen, die unterschiedliche
Sicherheitsanforderungen haben.
Abb. 5: Public Key Infrastructure Bausteine
Security Environment
Das Security Environment bedarf des größtmöglichen Schutzes innerhalb der Public
Key Infrastructure. Hier sind die privaten Schlüssel und sensible Daten der Certification
Authority hinterlegt. Mit diesen Schlüsseln werden sämtliche von der Certification
Authority ausgestellten Zertifikate, sowie die Root Zertifikate der CA selbst, digital
signiert.
Werden die Schlüssel kompromittiert, müssen alle Zertifikate der CA gesperrt werden.
Aus diesem Grund sind diese Schlüssel meist in speziell entwickelten
Hardwaremodulen gespeichert, aus denen die Schlüssel nicht ausgelesen werden
können. Die Hardware ist oft noch zusätzlich in einem zugangsbeschränkten Raum
untergebracht.
Key Management
Das Key Management ist ein sehr wichtiger Teil innerhalb der Public Key
Infrastructure. Hier werden die Schlüsselpaare, Schlüssel, Passwörter sowie EinmalPasswörter (OTP) generiert.
Sichere und zufällig erstellte kryptografische Schlüssel oder Passwörter lassen sich
nicht leicht generieren, weshalb dieser Teil oft von den Betreibern einer PKI
übernommen wird. Zudem werden im Key Management alle Schlüssel für das Key
Recovery und alle Authentifizerungsinformationen verwaltet.
23
Certification Authority
Die Certification Authority wird auch als das Herzstück jeder PKI bezeichnet. Hier
werden sämtliche Schlüsselzertifikate ausgestellt, gesperrt und archiviert. Zudem
werden Sperrlisten von ungültigen Zertifikaten erstellt, signiert und immer wieder
aktualisiert.
Alle von der Certification Authority ausgestellten Zertifikate sind von der CA im
Rahmen ihrer Policy beglaubigt, solange die Certification Authority die Zertifikate nicht
sperrt bzw. die Zertifikate nicht ablaufen.
Attribute Authority
Die Attribute Authority (AA) kann direkt in der CA realisiert werden oder extra als
eigenständige Einheit implementiert werden. Von einer AA werden sogenannte
Attributzertifikate ausgestellt, gesperrt und archiviert.
In den Attributzertifikaten stehen Sonderinformationen oder besondere
Autorisierungsrechte. Die Attributzertifikate werden mit dem dazugehörigen
Schlüsselzertifikat verknüpft, welche einen Zusammenhang zwischen einem
öffentlichen Schlüssel und einer Identität herstellen.
Der Unterschied zwischen Attribut- und Schlüsselzertifikaten liegt in ihrer
Veröffentlichung. Schlüsselzertifikate sind öffentliche Zertifikate die jedem zugänglich
gemacht werden können.
Attributzertifikate beinhalten zum Teil schützenswerte Informationen und werden
deshalb nicht veröffentlicht. Sie sind also nur einem kleinen Teil wie beispielsweise
Systemadministratoren, Laboringenieuren und dem Besitzer des Zertifikats zugänglich.
Time Stamp Service
Time Stamp Services sind genaue, zuverlässige und vertrauenswürdige Zeitgeber. Sie
signieren Dokumente oder Hashwerte mit einer Uhrzeit und erfüllen damit die
Funktionalität der Nichtabstreitbarkeit innerhalb einer Public Key Infrastructure.
Time Stamp Services sind selbst von einer Certification Authority zertifiziert worden,
um dem Kunden vertrauensvoll die Dienste anbieten zu können.
Registration Authority
Die Registration Authority dient zur Erfassung und Überprüfung aller nötigen Daten
eines Antragstellers für ein Zertifikat. Weiterhin werden hier auch Sperrungen von
Zertifikaten geprüft und veranlasst sowie Smardcards und Token initialisiert.
Eine Registration Authority kann innerhalb einer Certification Authority realisiert oder
als eigenständiger Bestandteil einer Public Key Infrastructure konzipiert werden.
24
Directory Service
Ein Verzeichnisdienst realisiert die Zugriffe auf Zertifikate und Sperrlisten. Über einen
solchen Dienst lassen sich Identitäten suchen, wobei immer darauf geachtet werden
muss, dass nicht jede Person Zugriff auf sämtliche Informationen bekommt, da sonst ein
Verzeichnisdienst leicht für Spammer und Social Engineering missbraucht werden
kann.
X.500 ist der OSI Directory Standard, welcher von der International Organization for
Standardization (ISO) und der International Telecommunication Union (ITU) definiert
wurde. Da X.500 sehr komplex und schwierig ist, wurde daraufhin das Lightweight
Directory Access Protocol (LDAP) entwickelt, das auf X.500 basiert.
Lokale Registration Authority
Eine lokale Registration Authority (LRA) hat die selben Aufgaben wie eine Registration
Authority. Der Unterschied liegt im Standpunkt der lokalen RA. Diese kann zum
Beispiel in einer Zweigstelle eines großen Unternehmens einer anderen Stadt stehen. So
können die dort ansässigen Mitarbeiter zu ihrer lokalen RA gehen und müssen nicht zur
RA in die Firmenzentrale kommen.
Responder
Ein Responder ist ein lokaler Server zum Verteilen von Zertifikaten und Sperrlisten. Er
gleicht in seiner Funktionalität einem Verzeichnisdienst, ist aber meist ausserhalb der
Public Key Infrastructure realisiert.
PKI Anwendungen
PKI Anwendungen entscheiden darüber, ob eine PKI benötigt und wie sie genutzt wird.
Bekannte PKI Anwendungen sind zum Beispiel Browser mit SSL/TLS Verbindungen,
Zugangsgeschützte SAP R/3 Anwendungen, verschlüsselter E-Mailverkehr mit
Timestamp Service und digitaler Signatur oder Single Sign-On in größeren Netzwerken.
Personal Security Environment
Das Personal Security Environment ist ein Medium, auf dem der geheime Schlüssel des
Zertifikatsbesitzers gespeichert ist. Die sicherste Variante ist eine kryptografische
Smartcard, aus denen der Schlüssel nicht ausgelesen werden kann. Weitere
Speichermedien sind spezielle USB-Sticks, Security Token, virtuelle Smartcards,
Diskette oder andere Datenträger.
Mehr Informationen zu den Themen Verschlüsselung, PKI und Verzeichnisdienste sind
in folgenden Büchern zu finden: [NaDuJo], [AdaLlo], [Schm1] und [Schn].
25
2. State of the Art PKI
In diesem Kapitel gibt der Autor einen Überblick über den aktuellen globalen Stand der
PKI Technologien an Hochschulen, sowie in nichtkommerziellen und kommerziellen
Bereichen.
Public Key Infrastructure ist ein Wachstumsmarkt und steckt sowohl in der
Entwicklung als auch in der Verbreitung noch in einer frühen Entwicklungsphase.
Große PKI Infrastrukturen zählen zu den Ausnahmen bzw. werden geplant und sind
bisher jedoch noch nicht über einen Probebetrieb hinaus gekommen.
2.1 PKI-Entwicklungen in Bildungseinrichtungen
In der deutschen Hochschullandschaft gibt es immer mehr Bestrebungen für eigene PKI
Infrastrukturen und den Aufbau von Certification Authorities. In dieser Diplomarbeit
werden nur die regionalen Hochschulentwicklungen in Berlin betrachtet, allerdings gibt
es auch in ganz Deutschland bereits bestehende Projekte.
An der Fachhochschule Rosenheim wurde bereits eine Certification Authority auf Basis
von OpenCA in Betrieb genommen. Fachhochschulen haben die Entwicklung eigener
Certification Authorities bisher vernachlässigt. Universitäten sind auf dem Sektor der
Public Key Infrastructure wesentlich fortschrittlicher und führender.
Viele Universitäten betreiben bereits eigene Certification Authorities, wenn auch nur im
Probebetrieb und nur für die eigenen Mitarbeiter und Studenten. Zertifiziert wird sehr
oft für PGP, doch sind auch einige X.509 Zertifikate an Hochschulen erhältlich. Für
Hochschulen ist es in erster Linie wichtig, im Bereich PKI eigenes Know How
aufzubauen und Erfahrungen beim Betrieb von Certification Authorities zu sammeln.
Zudem sehen einige Hochschulen darin zusätzliche Einnahmequellen. Zertifikate
können auch an Firmen und hochschulfremde Einrichtungen verkauft werden.
Außerdem lassen sich bestimmte hochschulinterne Abläufe und Prozesse durch eine
Public Key Infrastructure straffen und verbessern.
2.1.1
Humboldt Universität Berlin
Die HU Berlin hat Anfang 2000 im Rahmen des Projektes „Sicher vernetzte
Universitätsverwaltung und Dezentralisierung (UVsec) damit begonnen, eine
Certification Authority aufzubauen. Die Root-CA der HU Berlin ist von der DFN-PCA
des Deutschen Forschungsnetzes zertifiziert.
Der Prototyp wurde unter Open-SSL realisiert. Mittlerweile wurde der Probebetrieb auf
OpenCA umgestellt. Die HU Berlin sammelt zur Zeit Erfahrungen im Betrieb mit
OpenCA als Software und im Betrieb einer PKI.
26
Hierfür ist es Studenten und Universitätsangehörigen gestattet X.509 Zertifikate zum
Verschlüsseln und Signieren von E-Mails zu beantragen. Es werden allerdings auch
PGP Schlüssel signiert.
Eine Zertifizierung nach dem Signaturgesetz erfolgt nicht. Die HU-Policy richtet sich
nach der DFN-PCA Policy. Zusätzlich wurde die Verwaltung der HU Berlin mit
Smartcards ausgerüstet. Pro Semester erstellt die HU-CA circa 100 Zertifikate für
freiwillige Teilnehmer und die HU-Verwaltung.
In Zukunft ist eine Zertifizierung aller Studenten und Mitarbeiter der Universität
geplant, diese scheitert jedoch im Moment Mangels finanzieller Ressourcen. Geplant ist
auch der spätere Umstieg von der bisherigen Open Source Software auf ein
kommerzielles Produkt für den Regelbetrieb.
2.1.2
Technische Universität Berlin
Die TU Berlin hat gerade mit dem Aufbau eines Trustcenters begonnen. Auch Sie
zertifiziert nach X.509 und ist selbst von der DFN-PCA zertifiziert. Die TU Berlin hat
drei Certification Authorities.
Die Root-CA der TU Berlin zertifiziert die folgenden drei Unter-CA’s, eine Server-CA
für Serverzertifikate, welche auch TU-Fremde erwerben können, eine Personen-CA für
Zertifikate der öffentlichen Schlüssel von Personen, sowie eine Objekt-CA zum
zertifizieren von Schlüsseln für Softwareentwickler.
Mit diesen Zertifikaten können Entwickler Softwarepakete signieren. Die Personen-CA
befindet sich momentan im Aufbau und die Objekt-CA ist geplant. Zertifiziert wird mit
Hilfe von Open-SSL. 24 Server Zertifikate wurden bisher von der Server-CA der TU
Berlin herausgegeben.
2.1.3
Technische Fachhochschule Berlin
Die TFH Berlin hat 1999 mit dem Aufbau einer Certification Authority begonnen. Das
Projekt ist mittlerweile eingestellt bzw. gilt als gescheitert. So sind sämtliche CA
Zertifikate nicht mehr gültig und im Jahr 2001 ausgelaufen. Die Gültigkeit der Policy
der TFH-Berlin lief im Jahr 2002 aus.
Einzig über das DFN-PCA lässt sich noch ein gültiges CA-Zertifikat für die TFH Berlin
finden. Dies lässt auf eine rein interne Aufrechterhaltung der CA schließen.
Zertifiziert wurde nach X.509 Standard, wobei der Service laut Webseite der
Certifiaction Authority nicht angeboten werden konnte. PGP Schlüssel wurden
ebenfalls signiert.
27
2.2 Kommerzielle PKI-Entwicklungen
Das sich mit PKI auch Geld verdienen lässt, ist spätestens nach dem erfolgreichen Start
der größten Public Key Infrastructure deutlich geworden. Die US-amerikanische
Postgesellschaft US-Postal hat mit über 500.000 ausgestellten Zertifikaten im Jahr 2000
das größte PKI System weltweit im Produktivbetrieb.
Das Vorzeigebeispiel steht stellvertretend für eine ganze Reihe erfolgreicher PKI
Systeme. In Deutschland haben vor allem die Firmen Secude, Secunet und TC
Trustcenter im Bereich PKI auf sich aufmerksam gemacht. Secude ist vor allem für
seine PKI Anwendungen bekannt, Secunet ist rein beratend im IT-Sicherheitssektor
tätig. TC Trustcenter betreibt eines von drei öffentlichen Trustcentern in Deutschland.
2.2.1
RSA Security
RSA Security wurde 1982 gegründet, um das von Rivest, Shamir und Adleman
erfundene asymmetrische Verschlüsselungs- und Signaturverfahren RSA besser zu
vermarkten.
Aus dem anfänglichen Namen RSA Data Security wurde 1996 durch eine
Firmenübernahme Security Dynamics, die seit 1999 unter dem bis heute gültigen
Namen RSA Security firmieren.
Die Firma ist vor allem bekannt für ihre Secure-ID Karten und macht mit ihrer PKI
Lösung Keon in der Presse auf sich aufmerksam.1 Neben RSA Security entstanden
weitere Firmen Spin-Off’s wie die RSA Laboratories oder Verisign.
Die RSA Laboratories sind eher als eine Forschungs- und Innovationsgesellschaft zu
betrachten. Verisign ist vor allem durch den Betrieb eines eigenen Trustcenters bekannt.
Zudem besitzt Verisign mit Onsite ein erfolgreiches System, das für sehr große PKI’s
konzipiert wurde.
2.2.2
Entrust Technologies
Entrust Technologies ist eine kanadische Firma, spezialisiert auf IT-Security. Mit Ihrer
PKI Lösung Entrust/PKI sind sie derzeit Weltmarktführer auf dem Public Key
Infrastructure Markt. Entrust entwickelt aber auch PKI-Anwendungen wie E-MailVerschlüsselung oder SAP-R/3 Sicherheitslösungen.
Die Firma setzt bei ihren Entwicklungen öfter auch auf propitäre Formate um
bestimmte Funktionalitäten umzusetzen. Über spezielle Schnittstellen können andere
Firmen ihre Produkte kompatibel gestalten und als „Entrust Ready“ zertifizieren lassen.
1
Quelle: IT-SecCity - RSA Security Alternative zu Service Providern von Drittanbietern für SSLZertifikate.htm (www.it-seccity.de)
2.2.3
28
Baltimore Technologies
Baltimore Technologies ist eine irische Firma, die sehr erfolgreich im PKI Markt tätig
ist. Neben eigenen Technologien bietet Baltimore Technologie auch Beratung und
Support im Sicherheitsbereich an. Die PKI Software Unicert ist neben kryptografischer
Hardware und Content-Security-Lösungen das bekannteste Produkt einer ganzen Reihe
von PKI Anwendungen.
Baltimore Technologie setzt mehr auf Standards und interoperable Lösungen bei seinen
Produkten als Konkurrent Entrust Technologie und ist mit dieser Strategie Nummer
zwei auf dem weltweiten PKI Markt geworden.
2.3 Non-Profit-PKI-Entwicklungen
Auch für nicht kommerzielle Organisationen ist PKI ein wichtiger Bereich, in dem vor
allem über große Public Key Infrastructure Landschaften und die flächendeckende
Einführung von Zertifikaten und Signaturen nachgedacht wird.
Staatliche Behörden und Einrichtungen können mit PKI und Zertifikaten in der eigenen
Verwaltung viel Aufwand und über längere Zeit betrachtet, Kosten sparen. Anträge,
Anfragen und Briefe können schneller und sicherer elektronisch erstellt, beantwortet
und verschickt werden. Zudem kann die Sicherheit der IT-Landschaft innerhalb der
Verwaltung mit einer Public Key Infrastructure erhöht werden.
Langwierige Prozesse und Abläufe können anstatt per Papier und Post digital optimiert
werden. Auch der normale Bürger profitiert davon, da viele Behördengänge dank
Zertifikaten wegfallen und statt dessen per E-Mail oder Formular über das Internet
erledigt werden. Zumindest ist das sogenannte E-Governement auf einer solchen Basis
geplant.
2.3.1
Bundesamt für Sicherheit in der Informationstechnik (BSI)
„Das Hauptbetätigungsfeld des BSI umfasst derzeit die Fortentwicklung des "EGovernment" als Unterstützung der Initiative BundOnline 2005, die Bereitstellung der
Dienstleistungen des Computer Emergency Response Teams für Bundesbehörden
("CERT-Bund").“ (www.bsi.de).
Daneben beschäftigt sich das BSI mit
Computerviren, digitalen Signaturen,
Internetsicherheit, IT-Grundschutz, Kritische Infrastrukturen, den Projekten SINA und
SPHINX sowie mit Zertifizierungs- und IT- Sicherheitskriterien. Im Bereich PKI ist
besonders das Projekt SPHINX bedeutsam. Projektziel ist eine sichere digitale Signatur
und Verschlüsselung in der öffentlichen Verwaltung.
29
Als Teilprojekt wird auch eine Verwaltungs-PKI geplant, welche gemeinsam von Bund,
Ländern und Kommunen genutzt wird. Die Verwaltungs-PKI ist Teil der Bridge-CA,
die vom Industrieverband TeleTrusT betrieben wird.
Die Bridge-CA wurde entwickelt, um die vielen verschiedenen PKI Infrastrukturen der
Unternehmen miteinander zu verbinden. Dadurch entsteht ein Netzwerk, welches
sichere und schnelle Kommunikation zwischen Verwaltung, Unternehmen und Bürgern
ermöglicht.
2.3.2
TeleTrusT Deutschland e.V.
Der Industrieverband der deutschen IT-Sicherheitsfirmen gründete 1989 mit dem
TeleTrusT Deutschland e.V. eine Plattform für Lobbyarbeit und die Schaffung von
anerkannten Standards. Der Verein war ein entscheidender Fürsprecher bei der
Schaffung des Signaturgesetzes und schaffte mit Mailtrust sogar einen eigenen
Standard. TeleTrusT ist der Betreiber der Bridge-CA, die eine sichere und authentische
Kommunikation zwischen Unternehmen und öffentlicher Verwaltung ermöglicht.
„Ein Unternehmen meldet sich an und kann nach seiner Aufnahme sofort mit allen
anderen Teilnehmern sicher kommunizieren - ohne mit jedem einzelnen Unternehmen
langwierige Gespräche zu führen oder Verträge schließen zu müssen.“ (www.bridgeca.de)
2.3.3
National Security Agency (NSA)
Der US-amerikanische Geheimdienst National Security Agency (NSA) wurde 1952
vom Verteidigungsministerium der USA gegründet. Die NSA wurde vor allem wegen
ihrer
Hauptaufgabe
berühmt
berüchtigt.
Das
Abhören
sämtlicher
Kommunikationskanäle, um für die Sicherheit der USA zu garantieren.
Der weltweit größte Abnehmer von Computer Hardware setzt auch Rekorde bei seinen
Mitarbeitern. Der größte Arbeitgeber für Mathematiker ist in der Kryptografie dem Rest
der Welt circa 10 Jahre voraus.
Leider nutzt die NSA ihren Einfluss in der Industrie oft, um Hintertürchen in
kryptografische Algorithmen zu implementieren oder ganze Algorithmen geheim zu
halten bzw. bei ihrer Entwicklung darauf zu achten, dass diese nicht zu stark sind.1 PKI
ist jedoch eine Technologie, die Vertrauen in die Technik sowie in die verwendeten
Algorithmen beim Nutzer erzeugen muss.
1
Quelle: c't 19-99, S_ 68 Datenschutz und -sicherheit.htm (www.heise.de)
Die FHTW PKI
30
3. Die FHTW PKI
An der Fachhochschule für Technik und Wirtschaft existiert bisher keine Public Key
Infrastructure. In der vergangenen Zeit wurde des öfteren über PKI Infrastrukturen
nachgedacht. Professor Dr. Burkhard Messer hat sich genauer mit der Idee einer PKI an
der FHTW beschäftigt. Auch im Rahmen anderer Projekte spielen Überlegungen zur
Einführung einer PKI eine Rolle.
Mit dieser Diplomarbeit, soll der Stein für die Realisierung einer PKI ins Rollen
gebracht werden. Damit die Entscheidung für eine PKI von Erfolg gekrönt ist, müssen
die bereits vorhandenen Strukturen und Organisationen der Fachhochschule in das
Konzept miteinbezogen werden.
Darüber hinaus muss das Konzept finanziell erschwinglich sein und einen
arbeitstechnischen Nutzen oder Mehrwert für die Mehrheit der Beteiligten bringen.
Neue Konzepte werden nur von Mitarbeitern akzeptiert, wenn sie in ihrer täglichen
Arbeit davon profitieren.
PKI ist eine Technologie mit der sich Arbeitsprozesse vereinfachen lassen, die
allgemeine Sicherheit erhöht wird und sich auf Dauer auch Kosten sparen lassen. In
dem folgenden Kapitel zeigt der Autor mögliche Anwendungen und Einsatzgebiete
einer PKI an einer Fachhochschule auf und versucht an diesen Beispielen die Vorteile
einer PKI auszuarbeiten und vorzuzeigen. Die Einführung und der Betrieb einer PKI
bringt auch Gefahren bzw. Risiken mit sich, welche im Verlauf dieses Kapitels
aufgezeigt werden.
3.1 Wozu überhaupt eine eigene PKI?
Es gibt viele Gründe die für einen Einsatz von Public Key Infrastructure an einer
Fachhochschule sprechen. Einige Beispiele sind hier aufgeführt und werden auch im
Verlauf dieser Arbeit genauer betrachtet.
•
•
•
•
•
•
•
•
Sicherere Kommunikationsnetze per SSL/TLS, IP-Sec und VPN.
Erhöhen der Sicherheit der IT-Infrastruktur an der Fachhochschule.
Verhindern von destruktivem Verhalten innerhalb der Fachhochschule
beispielsweise in Laboren der Hochschule.
Modernisierung der Infrastruktur der Fachhochschule durch Einsatz neuer
Technologien.
Prozessumstellung unter Nutzung der PKI Technologie.
Verschlüsselter E-Mailverkehr
Aneignung von Know How im Umgang einer neuen Technologie.
Vorteile für Studenten und Mitarbeiter der Fachhochschule durch einfachere
Gestaltung von Anwendungsprozessen.
Die FHTW PKI
31
3.2 Anwendungszenarien für die Fachhochschule
An einer Fachhochschule existieren eine Vielzahl von Anwendungsmöglichkeiten für
eine Public Key Infrastructure. Bei den folgenden Szenarien handelt es sich lediglich
um Konzepte und Ideen und nicht um technische Ausarbeitungen. In diesem Kapitel
werden vier mögliche Anwendungen genauer vorgestellt.
Dazu gehören Single Sign-On und sicherer E-Mailverkehr als Standardanwendungen
sowie zwei mögliche Anwendungen, die Studenten, Mitarbeitern und Professoren die
tägliche Arbeit erleichtern.
Darüber hinaus sind weitere Anwendungsmöglichkeiten für eine Public Key
Infrastructure vorhanden. So können Netzwerke und Internetverbindungen sicherer
gestaltet werden. Etwa durch den Einsatz von SSL/TLS, HTTPS bei
Internetverbindungen und durch Virtual Private Networks und IPSec bei Netzwerken.
Sicherer Zahlungsverkehr mit SET, Mobile Commerce und Onlinebanking(TAN/HBCI)
in der Mensa und bei der Zahlung von Studiengebühren sind möglich.
Forschungsarbeiten, vertrauliche Dokumente oder Programmcode können durch digitale
Wasserzeichen signiert und geschützt werden.
Die Verwaltung, die Studienabteilung, die Personalabteilung und die Fachbereiche der
Fachhochschule können durch Authentifizieren, Signieren und Ver/entschlüsseln sowie
Verwenden eines sicheren Kommunikationskanals viele Arbeitsprozesse schneller und
kostengünstiger elektronisch erledigen, als bisher mit Papier, Post und Porto.
Dies bedeutet natürlich auch eine Serviceverbesserung für Studenten und Mitarbeiter.
Teure und langwierige Arbeitsabläufe werden optimiert, gestrafft und kostengünstiger
gestaltet. Die Fachhochschule gewinnt nebenbei noch Prestige, da der Einsatz von neuer
Technologie natürlich auch für mögliche Studienanfänger und Firmen interessant sein
kann.
Die FHTW PKI
3.2.1
32
Single Sign-On (SSO)
Der Benutzer benötigt nur eine einmalige Authentifikation innerhalb eines Systems und
bekommt damit Zugriff auf Rechner und Applikationen, für die er Rechte erhalten hat.
Somit entfällt das lästige Merken mehrerer Passwörter und Login-Daten. Single SignOn bietet für den Benutzer vor allem mehr Komfort im Umgang mit
Authentifikationsdaten.
Zugangsdaten lassen sich nur sehr schwer in großen unterschiedlichen
Netzwerkstrukturen auf Gültigkeit überprüfen und aktuell halten. Dadurch entstehen
Sicherheitslücken, die durch eine globale Lösung des Problems behoben werden
müssen.
Die Vorteile von Single Sign-On sind damit die einfache, kostengünstige und auf ein
Minimum reduzierte Administration der Zugriffsberechtigungen für Systeme und
Netzwerke. Die Gefahr, dass es zu sogenannten Karteileichen bei bestehenden
Benutzeraccounts kommt, ist geringer.
Der große Nachteil von Single Sign-On ist, dass vorhandene Accounts nicht
kompromittiert werden dürfen. Damit gelangen unautorisierte Benutzer in den Besitz
eines so genannten „Key to the Kingdom“, ein Schlüssel der Zutritt zum System erlaubt.
Nicht autorisierte Benutzer können damit das System manipulieren und ausspionieren,
sofern sie mit entsprechenden Rechten ausgestattet wurden. Aus diesem Grunde sollten
Administratoren und Laboringenieure sich selbst nicht über Single Sign-On
authentifizieren.
Single Sign-On ist bei falscher Benutzung oder Implementierung durchaus als ein
Sicherheitsrisiko einzustufen. Mitarbeiter und Studenten sollten in diesem Fall explizit
auf die richtige Anwendung von Single Sign-On aufmerksam gemacht werden.
An der FHTW existieren seit längerem Überlegungen für eine Einführung von Single
Sign-On. Es gibt auch erste Ansätze, die jedoch nicht flächendeckend realisiert wurden.
So hat der Fachbereich IV bereits verschiedene Labore mit einem Single Sign-On
ausgestattet. Dort kann sich der Student mit einem Login und einem Passwort in
mehreren Laboren anmelden. Über ein flächendeckendes Single Sign-On an der
Fachhochschule ist noch nicht entschieden worden.
Single Sign-On ist ein typischer Anwendungsfall für eine Public Key Infrastructure,
muss damit aber nicht realisiert werden. Es bietet sich jedoch an, bei vorhandener PKI
die sicherheitstechnischen Möglichkeiten für Single Sign-On zu nutzen.
Ein mögliches Szenario besteht aus drei Bausteinen, einer zentralen
Benutzerverwaltung, einer PKI und Single Sign-On. In der zentralen
Benutzerverwaltung werden alle Benutzerdaten, Rollen und Regeln von allen
beteiligten Systemen und Applikationen abgelegt.
33
Die FHTW PKI
Die Folge ist eine effizientere Administration, auch bei sich ständig ändernden ITInfrastrukturen. Ein Verzeichnisdienst wie zum Beispiel LDAP, erfüllt die
Voraussetzungen für eine zentrale Benutzerverwaltung und bietet zusätzlich
Schnittstellen zu Novell- und Microsoftverzeichnissen.
Loginprozess
Login
Zentrale Benutzerverwaltung
erteilt Session Ticket
Autorisierung
Session Ticket
Benutzer
Prüft Zertifikat
T
rüf
e tp
ic k
g
un
Anwendung
Verzeichnisdienst
Abb.6.: Single Sign-On als Beispiel, Quelle: www.trivadis.ch
Durch Single Sign-On allein wird kein Netzwerk sicherer. Bei unzureichender
Verschlüsselung von internen Kommunikationswegen können Passwörter netzintern
abgefangen werden. Oft werden diese sogar noch im Klartext versendet. Für eine
Verschlüsselung der Kommunikationswege mit Secure Socket Layer (SSL) eigenen sich
digitale Zertifikate unter Einsatz einer Public Key Infrastructure.
Mit Hilfe von Zertifikaten werden nicht nur SSL-Verbindungen aufgebaut, sondern
auch Authentifizierungs- und Autorisierungsinformationen verwaltet. Letztere werden
über Privilegien und Rollenkonzepte in sogenannten Attributzertifikaten abgelegt.
Single Sign-On benötigt für eine erfolgreiche Umsetzung eine genaue Planung. Das
Ergebnis ist ein einheitliches und sicheres Verfahren bei der Authentifizierung. Folgen
sind ein erhöhtes Sicherheitsniveau sowie eine spürbare Entlastung der
Systemadministratoren.
Die SSO Technologie ist komplex und bei der Implementierung gibt es viele
verschiedene Lösungswege. Aus diesem Grund wird nicht weiter auf die Thematik
eingegangen, da sie den Rahmen dieser Diplomarbeit sprengen würde. 1
1
Quelle: Zunehmender Bedarf an Single Sign-On-Lösungen.htm (www.trivadis.ch)
Die FHTW PKI
3.2.2
34
Verschlüsselter E-Mailverkehr
Eine Standardanwendung für PKI Infrastrukturen ist der verschlüsselte E-Mailverkehr.
Die Schwierigkeiten im E-Mailverkehr liegen darin, dass der Empfänger sicher gehen
will, dass die E-Mail wirklich vom Absender stammt. Weiterhin will er sicherstellen,
dass die Nachrichten und Dokumente unverändert zum Empfänger gelangen und dass
wichtige Nachrichten verschlüsselt werden und nur der Empfänger diese entschlüsseln
kann.
Eine weitere Funktion ist die Nichtabstreitbarkeit bei elektronisch abgeschlossenen
Verträgen oder Beglaubigungen und Ähnlichem. Die Vorgaben hierfür regelt in
Deutschland das Signaturgesetz. Ziel ist es, die elektronische Signatur mit der eigenen
Unterschrift rechtlich gleichzustellen. Hierfür sind jedoch sehr hohe Maßstäbe durch
das Signaturgesetz geschaffen worden. Allein für die Anschaffung der benötigten
Hardware sowie der Räumlichkeiten für ein Trustcenter, das dem Signaturgesetz
entspricht, fehlen der Fachhochschule die finanziellen Mittel. Hinzukommen würden
weitere Kosten für den Betrieb des Systems. Deshalb ist eine Unterstützung von
Nichtabstreitbarkeit im Sinne des Signaturgesetzes nicht vorgesehen. Die Funktionalität
kann später gegebenenfalls nachgerüstet werden.
Bisher wird der E-Mailverkehr an der FHTW nicht verschlüsselt vorgenommen,
allenfalls sehr selten und auf freiwilliger Basis. Ebenfalls kann bisher nicht zweifelsfrei
nachgewiesen werden, ob ankommende Nachrichten authentisch und integer sind.
Abb.7.: E-Mail Verschlüsselung mit Hashfunktion, Quelle: [NaDuJo]
Die FHTW PKI
35
Durch die Möglichkeit der Verschlüsselung von E-Mails wird das Sicherheitsniveau an
der FHTW erhöht. Vor allem in der Verwaltung der Fachhochschule lassen sich viele
Vorgänge elektronisch gestalten. Das hilft Kosten einzusparen und verringert den
Arbeitsaufwand für die Mitarbeiter.
Ein weiterer Vorteil ermöglicht die Timestamp-Funktionalität. So können Belegarbeiten
oder Anträge pünktlich und nachprüfbar per E-Mail eingesandt werden. Fristen zur
Abgabe von Projekten oder Semesterarbeiten können zeitgenau überprüft werden und
sind nicht mehr manipulierbar.
Abb.8: E-Mail Entschlüsselung mit Hashfunktion, Quelle: [NaDuJo]
Die Verbindung aus asymmetrischer und symmetrischer Verschlüsselung bildet die
Grundvoraussetzung für verschlüsselten E-Mailverkehr. Durch ausgestellte Zertifikate
werden Schlüssel an einzelne Identitäten gebunden und ermöglichen eine eindeutige
Authentifizierung der Empfänger und Absender.
Mit Hilfe der Schlüssel lassen sich je nach Verwendungszweck Texte und Dokumente
verschlüsseln und signieren. Durch den Einsatz von Hashfunktionen können die
Kommunikationspartner die Integrität der E-Mails wahren.
Durch eine Public Key Infrastructure lässt sich ein Zertifikat und die zugehörigen
öffentlichen Schlüssel eindeutig einer Identität zuordnen. Damit ist, solange der private
Schlüssel nicht kompromittiert wird, sichergestellt, dass verschlüsselte E-Mails nur vom
Empfänger selbst bzw. vom Besitzer des privaten Schlüssels entschlüsselt werden
können.
Die FHTW PKI
36
Fallstudie E-Mailverschlüsselung
In einer Fachhochschule basieren viele Prozesse auf nichtelektronischen Abläufen, was
zum
einen
aufgrund
mangelnder
Alternativen
geschieht
oder
weil
Datenschutzrichtlinien und Vertraulichkeit bisher keinen anderen Weg zulassen. Mit
Hilfe einer Public Key Infrastructure können einige dieser Prozesse optimiert werden.
Ein einfaches Beispiel ist der tägliche Briefverkehr an einer Fachhochschule.
Ein Brief der in der Verwaltung geschrieben und an einen Mitarbeiter, Studenten oder
Professoren geschickt wird, muss ausgedruckt, von einem Mitarbeiter unterschrieben, in
einen Briefumschlag getan, ausreichend frankiert und zur Post gebracht werden. Der
geschätzte Arbeitsaufwand liegt bei circa 1-3 Minuten, wobei der Brief mindestens 1
Tag bis zum Empfänger benötigt.
Die elektronische Alternative mit Hilfe einer Public Key Infrastructure kann
folgendermaßen aussehen. Der Mitarbeiter verfasst den Brief am Computer. Er sucht
sich die E-Mailadresse und das Zertifikat des Empfängers aus dem Verzeichnisdienst
heraus. Ist das Zertifikat gültig und nicht in einer Sperrliste zu finden, kann der
Mitarbeiter nun je nach Bedarf die E-Mail oder angehängte Dokumente verschlüsseln.
Dazu benutzt der Mitarbeiter den öffentlichen Schlüssel des Empfängers, der sich in
dem gerade geprüften Zertifikat des Empfängers befindet.
Sind die zu verschlüsselnden Dokumente sehr groß, sollten aus Performancegründen
besser symmetrische Schlüssel zum Verschlüsseln der Dokumente verwendet werden.
Die symmetrischen Schlüssel können dann wiederum mit dem öffentlichen Schlüssel
des Empfängers verschlüsselt werden. Der daraus entstehende digitale Umschlag
(verschlüsselter symmetrischer Schlüssel) wird an die E-Mail angefügt.
Soll zusätzlich die Integrität der E-Mail gewahrt bleiben, kann der Absender eine
Hashfunktion benutzen. Die Hashfunktion erzeugt einen so genannten Message Digest
von der E-Mail. Dieser Message Digest ist einzigartig und es ist nicht möglich vom
Digest auf den ursprünglichen Text zu schließen (Vorraussetzung ist die fehlerfreie
Implementierung eines sicheren Hashalgorithmus).
Der Message Digest kann optional vom Absender mit seinem eigenen privaten
Schlüssel verschlüsselt werden. Somit ist es nicht möglich den Message Digest zu
fälschen, der Empfänger kann den Digest jederzeit selbst überprüfen und mit Sicherheit
davon ausgehen, dass die erhaltene Nachricht nicht von Unbekannten gelesen und
verändert worden ist. Der verschlüsselte Digest wird dann an die E-Mail angehängt.
Der Prozess sieht kompliziert aus, entspricht aber einer einfach zu erlernenden Reihe
von Abläufen die mit ein paar einfachen Mausklicks zu bewerkstelligen sind. Durch die
elektronische Umstellung des Prozesses kann die gesamte Prozedur beschleunigt
werden (circa 1 Minute) und die E-Mail sofort an den Empfänger verschickt werden.
Die FHTW PKI
37
Normalerweise kommt eine E-Mail nach circa zwanzig Minuten beim Empfänger an.
Die Fachhochschule profitiert von der geringeren finanziellen Belastung beim Ablauf
der Prozedur. Es fallen keine Kosten für den Druck des Briefes sowie für Porto und
Verpackung an. Bei vielen Briefen pro Tag ist der Mitarbeiter der Fachhochschule
weniger belastet und kann die gewonnene Zeit für andere Tätigkeiten nutzen.
Durch die Verschlüsselung der E-Mail ist die Vertraulichkeit von Daten weiterhin
gegeben und auch der Datenschutz wird eingehalten. Durch die Verschlüsselung mit
öffentlichen und privaten Schlüsseln können die Daten nur vom Schlüsselbesitzer selbst
entschlüsselt werden.
Dritte haben keinen Zugriff auf diese Daten, sofern sie nicht im Besitz des
entsprechenden Schlüssels sind. Durch die Anwendung von Hashalgorithmen und die
Verschlüsselung von Message Digest sind Dokumente auch vor unerlaubten
Veränderungen durch Dritte geschützt.
Die FHTW PKI
3.2.3
38
Notenabfragesystem für Studenten
Am Ende eines Semesters steht für viele Studenten das Warten auf die Noten in den
belegten Fächern an erster Stelle. Aus Gründen des Datenschutzes werden die Noten
bisher nicht im Internet veröffentlicht. Studenten müssen in der Fachhochschule
vorstellig werden, um die Noten des vergangenen Semesters einsehen zu können.
Die Noten werden jedoch je nach Abgabe durch den Dozenten veröffentlicht. Das
bedeutet für den Studenten einen mehrmaligen Gang zur Fachhochschule. Immerhin
weiss der Student, durch die frühe Kenntnis der Noten, ob er sich auf eine
Wiederholungsprüfung vorbereiten muss oder nicht. Je eher der Student dies weiß,
desto besser und umfangreicher kann er sich auf eine weitere Prüfung vorbereiten.
Durch eine zentrale Datenbank in der alle Dozenten und Professoren ihre Noten
eingeben und der Student jeweils nur seine Noten abrufen darf wird eine komfortable
Plattform geschaffen von der die Dozenten und auch die Studenten profitieren.
Professoren und Dozenten werden weniger stark von Studenten mit Notenanfragen
beansprucht. Studenten müssen nicht mehrere Male in den Semesterferien in der
Fachhochschule vorstellig werden, um alle Noten des vergangenen Semesters zu
erfahren und können sich auf eventuelle Nachprüfungen besser vorbereiten.
Die Noten werden weiterhin direkt von den Professoren und Dozenten an das
Prüfungsamt weitergegeben. Es besteht keine Verbindung von der Notendatenbank zum
Prüfungsamt oder umgekehrt. Das Prüfungsamt kann natürlich weiterhin die
Notenlisten in alternativer Form zur Verfügung stellen.
Um Dozenten keine Mehrarbeit zuzumuten, können diese ihre Noten beispielsweise
über Excel-Dateien in die Datenbank importieren. Dadurch wird die nochmalige
Eingabe aller Noten umgangen und der Dozent kann sich wichtigeren Arbeiten widmen.
Um den datenschutzrechtlichen Bestimmungen gerecht zu werden, darf der Student nur
seine eigenen Noten abrufen. Während der Session wird weder der Name des Studenten
noch seine Matrikelnummer auf dem Bildschirm angezeigt.
Der Student hat keine Möglichkeit schreibend auf die Kopie der Datenbank vom
Prüfungsamt zuzugreifen. Nur Dozenten und Professoren ist es möglich bereits
eingegebene Noten noch einmal zu ändern. Dies ist eventuell nötig nach
Klausurbesprechungen. Die Änderungen vom Dozenten werden jedoch nicht in der
Datenbank vom Prüfungsamt vorgenommen. Alle dortigen Änderungen werden
weiterhin nur von zuständigen Prüfungsamtmitarbeitern durchgeführt.
Die Authentifizierung und Autorisierung der jeweiligen Benutzer kann über Single
Sign-On und Attributzertifikate realisiert werden.
Die FHTW PKI
3.2.4
39
Einführung von sicheren Remote-Zugriffen
„Unter Remote Access versteht man den Fernzugriff auf Anwendungen oder Daten von
Rechnern von einem System aus, das nicht direkt über ein LAN mit diesen Rechnern
verbunden ist.“ (Quelle: http://glossary.ges-training.de)
Remote-Zugriffe an der Fachhochschule sind nicht nur für Administratoren oder
Laboringenieure interessant. Auch für einen Studenten bieten sich einige
Anwendungsbeispiele. Aus finanziellen Gründen teilt sich die Fachhochschule SAP
Lizenzen mit der Fachhochschule Magdeburg. Über spezielle Netzwerkverbindungen in
dem entsprechendem Labor können Studenten so praktische Erfahrungen mit SAP
sammeln.
Ohne Remote-Zugriffe wäre die Fachhochschule nicht in der Lage SAP Kurse
anzubieten und die Ausbildung vieler Studenten würde dadurch qualitativ schlechter
sein. Die Chancen auf dem Arbeitsmarkt wären dadurch schlechter im direkten
Vergleich mit Studenten anderer Hochschulen.
Aber auch andere Software kann über spezielle Applikation Server und RemoteZugriffe genutzt werden. Softwarelizenzen kosten sehr viel Geld und gerade für
Studenten aus technischen Studiengängen sind selbst Studentenversionen nicht
erschwinglich, da in diesen Studiengängen mit vielen verschiedenen Programmen
gearbeitet wird.
Über Remote-Zugänge kann sich der Student auf einen Fachhochschulrechner
einloggen und den Umgang mit dem Programm zu Hause erlernen. Das Programm
selbst läuft lokal auf dem Rechner der Fachhochschule und kann in keiner Weise vom
Benutzer kopiert werden. Der Student profitiert davon, weil er legal den Umgang mit
Software erlernen kann und später auf dem Arbeitsmarkt durch eine bessere Ausbildung
größere Chancen auf einen Anstellung besitzt. Projekte und Belegarbeiten werden in
vielen Fächern während des Semesters angefertigt.
Die Labore sind zu normalen Zeiten oftmals durch Vorlesungen und Übungen belegt.
Über Remote-Zugriffe ist der Student nicht mehr an feste Öffnungszeiten der Labore
gebunden und hat auf die Programme auch nachts oder am Wochenende Zugriff.
Der Zugriff auf das fachhochschulinterne WLAN-Funknetz sowie die Einwahl in das
Internet über das Rechenzentrum der Fachhochschule können über Zertifikate realisiert
werden. Auch für Laboringenieure und Systemadministratoren bieten sichere RemoteZugriffsmechanismen einen Vorteil, da sie oft mit Root-Rechten arbeiten und so ein
Ziel möglicher Netzangriffe sind. Durch eine Fernwartung der Systeme kann eine
höhere Reaktionszeit bei eventuell auftretenden Problemen von Vorteil sein. Auch
können so Fehler vom zuständigen Mitarbeiter behoben werden, wenn dieser nicht vor
Ort ist.
Mehr Informationen zu den Themen Single Sign-On, E-Mail Verschlüsselung und
sichere Netzwerke sind in folgenden Büchern zu finden: [HoPoLo], [BitBri], [BucKöh],
[KlüLas], [8], [9].
Prozesse und Lebenszyklen
40
4. Prozesse und Lebenszyklen
Eine Fachhochschule ist kleiner und weniger komplex als eine Universität, bringt aber
trotzdem viele unterschiedliche Strukturen und Netzwerke und einen großen Verbund
ein. Organisatorisch betrachtet sind das die verschiedensten Ämter und Anlaufstellen
sowie Mitarbeiter, Studenten, Professoren und die Fachhochschulleitung. Technisch
gesehen betrifft es alle Computer und Netzwerke mit den verschiedenen
Betriebsystemen.
Abb. 9: Abstrakte Abbildung der Fachhochschulstruktur
In einer Public Key Infrastructure besitzen alle diese Objekte unterschiedliche
Sicherheitsansprüche. In diesem Konzept wird versucht dem Sicherheitsanspruch aller
Objekte gerecht zu werden. Dabei muss immer beachtet werden, dass das Konzept
finanziell und technisch umsetzbar bleibt.
Neueste Technologien, wie kryptografische Smartcards, sind ohne Sponsoren für alle
Fachhochschulangehörigen nicht finanzierbar. Auch dürfen Personalkosten für den
Betrieb der Public Key Infrastructure nicht allzu hoch steigen. Bedacht werden muss
dabei nebenfalls auch ein mögliches krankheitsbedingtes Fehlen von Personal sowie
eventuelle Urlaubsvertretungen.
Die technischen Konzepte sowie die Registrations- und Zertifizierungsprozesse sollen
auch bei einer Realisierung in Zukunft einfach erweiterbar bleiben und möglichst
unkompliziert gestalten werden. Zudem soll das gesamte Konzept später als Beispiel für
andere Fachhochschulen dienen können.
Dies sind alles Gründe, die in diesem Konzept dazu geführt haben, drei verschiedene
Level für die Zertifizierung einzuführen. Das Hauptaugenmerk lag dabei auf dem
Design des Low Levels. Dieser Level ist für den Massenbetrieb an der Fachhochschule
entworfen worden.
41
Der Level soll vor allem den Studenten ermöglichen, Erfahrungen mit der Technologie
zu sammeln und das Bewusstsein für IT-Sicherheit wecken. Er ist der Level mit der
geringsten Sicherheitsstufe, da hier ein Kompromiss eingegangen werden muss, damit
das Konzept finanziell tragbar bleibt.
Eine flächendeckende Nutzung von Zertifikaten an der Fachhochschule erfordert eine
gewisse Personalstärke zum Betrieb der Public Key Infrastructure. Da vorerst keine
direkte kommerzielle Nutzung der PKI geplant ist, sind hohe Fixkosten beim Betrieb
einer Certification Authority zu vermeiden.
Das Low Level wurde demzufolge nach diesen Maßstäben entworfen. Es gilt einen
Kompromiss zu finden zwischen möglichst geringen Kosten und einer Erhöhung der
Sicherheit für alle Beteiligten. Dabei müssen die Prozeduren und Prozesse sowie der
Aufbau des Systems transparent und jederzeit erweiterbar bzw. veränderbar gestaltet
werden.
Natürlich gibt es auch an der Fachhochschule besonders schützenswerte Bereiche, bei
denen kein Weg um eine teure Infrastruktur herumführt. Hierfür wurde das High Level
entworfen.
Bestimmte Verwaltungsprozesse, die noch nicht digital umgestellt sind, erfordern ein
hohes Sicherheitsniveau bei der digitalen Umstellung. Hinzu kommen
datenschutzrechtliche Aspekte, die bei einer digitalen Umstellung beachtet werden
müssen.
Auch bestimmte Personenkreise benötigen einen höheren Sicherheitslevel als ein
Student. Dazu zählen vor allem die Fachhochschulleitung und Mitarbeiter, die Zugriff
auf wichtige Daten wie Prüfungsergebnisse und Finanzdaten haben.
Im High Level wird vor allem darauf geachtet, dass die privaten Schlüssel der
Teilnehmer bestmöglich gesichert sind.
Das Medium Level ist für langfristige Mitarbeiter der Fachhochschule gedacht.
Professoren und Laboringenieure sowie einige Angestellte werden hier zertifiziert.
Dieser Nutzergruppe kann auch der Kauf eines sichereren Personal Security
Environment (PSE) eher zugemutet werden.
Alle zertifizierten Teilnehmer profitieren hierbei von einer größeren Sicherheit ihrer
eigenen privaten Schlüssel, sowie einer komfortableren Nutzbarkeit der Pubik Key
Infrastructure.
42
4.1 Low Level Zertifizierung
Der Low Level Bereich ist für circa zehntausend Benutzer konzipiert. Studenten,
Mitarbeiter der FHTW sowie Gastdozenten werden hier zertifiziert. Für die
Zertifizierung einer solch großen Nutzeranzahl wird sehr viel Personal benötigt, was die
Kosten für eine Public Key Infrastructure schnell steigen lässt.
Da die finanzielle Situation an Hochschulen generell nicht gut aussieht, muss darauf
geachtet werden, dass dieses Konzept finanziell tragbar bleibt. Für den Low Level
Bereich sind deshalb zwei verschiedene Konzepte entwickelt worden.
Für beide Konzepte wird die Schlüsselgenerierung von den Betreibern der Public Key
Infrastructure übernommen. Die Mehrzahl der Benutzer hat kein größeres technisches
Verständnis, eine richtige Schlüsselgenerierung ist jedoch sehr wichtig und durchaus
kompliziert.
Der Supportaufwand bei einer großen Benutzeranzahl ist für eine Fachhochschule nicht
tragbar und finanzierbar. Erfahrungen im Probebetrieb anderer PKI Infrastrukturen
haben gezeigt, dass selbst Systemadministratoren Probleme bei der
Schlüsselgenerierung hatten.1
Das erste Konzept ist eine Onlinevariante zur Zertifizierung. Aus Kostengründen wurde
dieses Konzept so entworfen, dass fast alle Prozesse online durchführbar sind. Dies hat
den Vorteil, dass weniger Registration Authority Mitarbeiter für die große
Benutzeranzahl benötigt werden.
Das Low Level entspricht dem geringsten Sicherheitsniveau in der Public Key
Infrastructure. Deshalb wird es dem Benutzer überlassen, auf welchem Datenträger er
seine privaten Schlüssel abspeichert. Für eine große Benutzeranzahl ist es nicht
möglich, sehr sichere Datenträger, wie beispielsweise kryptografische Smartcards oder
spezielle USB Sticks, als Personal Security Environment (PSE) anzubieten.
Die Fachhochschule besitzt keine finanziellen Möglichkeiten, für jeden Benutzer ein
solches PSE bereit zu stellen. Der Kaufpreis kann auch nicht den Benutzern in
Rechnung gestellt werden. Die freie Wahl des Speichermediums für private Schlüssel
entspricht dem Low Level.
Benutzer des Low Level Bereiches sollen diesen vor allem einfach und unkompliziert
verstehen und bedienen können. Beide Seiten sollen zudem von einem erhöhten
Sicherheitsniveau profitieren.
1
Michael Bell: leitet den Probetrieb der Zertifizierungsinstanz der Humboldt Universität
Berlin
43
Mögliche Anwendungen für den Low Level Bereich sind das Signieren von
Dokumenten und E-Mails, Authentifizierung sowie Single Sign-On. Die Einführung
weiterer Anwendungen kann später jederzeit realisiert werden.
Die gewählte Schlüssellänge für asymmetrische und symmetrische Verschlüsselungen
richtet sich nach aktuellen Empfehlungen führender kryptografischer Unternehmen und
Verbände. Für das Konzept im Low Level Bereich wurde die Schlüssellänge für
asymmetrische Schlüssel bei 2048 Bit und für symmetrische Schlüssel bei 128 Bit
festgelegt.
Die Gültigkeitsdauer für Zertifikate und Schlüssel im Low Level Bereich beträgt jeweils
sechs Monate. Danach müssen neue Schlüssel generiert werden, was die Ausstellung
eines neuen Zertifikats nach sich zieht.
Für bestimmte Anwendungen, wie das Signieren, sollte die Gültigkeitsdauer der
Schlüssel nicht zu lang gewählt werden. Um eine einfache technische Umsetzung des
Konzepts zu ermöglichen, wurden für Schlüssel und Zertifikate die gleiche
Gültigkeitsdauer festgelegt.
44
Beispiel einer Erstzertifizierung für Low Level Variante 1
Der zukünftige Zertifikatsbesitzer muss ein gültiges E-Mail Konto an der FHTW
besitzen. Dazu füllt der Antragsteller einen Antrag aus und gibt diesen bei der
Registration Authority ab. Bei der Abgabe des Antrages muss sich der Antragsteller mit
seinem Personalausweis sowie einem gültigen Studentenausweis authentifizieren.
Der RA Mitarbeiter überprüft die Angaben auf dem Antrag mit den Ausweisen. Danach
wird der Antrag an einen zuständigen Systemadministrator im Rechenzentrum
übergeben, der das E-Mail Konto erstellt.
Gleichzeitig wird vom RA Mitarbeiter eine Liste mit Einmalpasswörtern (OTP) für den
Antragsteller generiert. Diese werden benötigt, um sich bei Registration Authority
Prozessen zu authentifizieren.
Nach einigen Tagen muss der Antragsteller erneut bei der Registration Authority
vorstellig werden, um die Zugangsdaten für sein E-Mail Konto sowie die Passwortliste
zu erhalten. Alle weiteren Schritte werden vom Antragsteller am heimischen Computer
erledigt.
Abb.10: Teil der Erstzertifizierung, E-Mail Konto und OTP Liste Variante 1
Der Antragsteller begibt sich auf die Webseite der Certification Authority der
Fachhochschule. Der Webserver authentifiziert sich gegenüber dem Antragsteller und
die Kommunikation wird mit Hilfe von Secure Socket Layer (SSL) verschlüsselt.
Auf der Webseite muss ein Formular vom Antragsteller ausgefüllt werden. Erforderlich
ist die Eingabe von Name, Vorname, Studiengang/Fachbereich sowie E-Mail Adresse.
Die E-Mail Adresse wird für Supportzwecke benötigt. Alle anderen Daten werden für
das Zertifikat benötigt. Zudem muss der Einsatzzweck des Zertifikats gewählt werden.
45
Eine Überprüfung, ob der Antragsteller Mitglied der Fachhochschule ist oder eine
andere Berechtigung zur Zertifizierung hat, wurde bereits beim ersten Besuch der
Registration Authority vollzogen. .
Wurden alle erforderlichen Felder auf der Webseite richtig ausgefüllt und überprüft,
sendet der Webserver einen Request an den Schlüsselserver. Dieser beginnt mit der
Erzeugung eines zufälligen Schlüsselpaares. Für beide Schlüssel wird jeweils ein
Hashwert erzeugt und jeder Schlüssel wird zusammen mit seinem Hashwert vom
Schlüsselserver signiert. Zusammen mit einer URL für das Schlüsselpaar wird eine
Kopie des öffentlichen Schlüssels an den Webserver gesendet.
Der Webserver sendet die URL in einer E-Mail an den Antragsteller. Zusätzlich erhält
der Antragsteller durch diese E-Mail einen Statusbericht, inwieweit sein Antrag
bearbeitet worden ist. Durch Auswählen der URL wird eine Secure Socket Layer
Verbindung (SSL) aufgebaut und der Antragsteller muss ein Einmalpasswort eingeben.
Ist dieses Passwort richtig, wird der Download des Schlüsselpaares gestartet.
Wenn die Kopie des öffentlichen Schlüssels an den Webserver übermittelt worden ist,
werden der Hashwert und die Signatur des Schlüssels überprüft. Danach wird über den
öffentlichen Schlüssel zusammen mit allen Formulardaten ein Hashwert gebildet.
Dieser wird zusammen mit den Daten vom Webserver signiert und an den Registration
Authority Server gesendet.
Der RA Server überprüft die Hashwerte und Signaturen aller Datensätze. Durch den RA
Mitarbeiter werden alle Datensätze in Zertifikatsvorlagen umgewandelt, vom
Registration Authority Server signiert und auf einen Wechseldatenträger gespeichert.
Der Certifiaction Authority Mitarbeiter entnimmt den Datenträger aus dem RA Server
und begibt sich zur Certification Authority, wo er den Datenträger wieder einsetzt. Der
Certification Authority Rechner überprüft die Signaturen aller Datensätze und signiert
alle Zertifikatsvorlagen.
Die Zertifikatsvorlagen werden durch die Signatur der Certification Authority zu
vollwertigen Zertifikaten, die ab dem eingetragenen Datum gültig sind. Alle signierten
Zertifikate werden von der Certification Authority wieder auf einen Wechseldatenträger
gespeichert.
Der Certification Authority Mitarbeiter entnimmt den Datenträger wieder der
Certification Authority und fügt diesen in den RA Server ein. Jetzt werden alle
signierten Zertifikate an den Light Directory Access Server (LDAP) gesendet und damit
der Öffentlichkeit zugänglich gemacht. Der RA Server sendet jedem neuen
Zertifikatsbesitzer eine weitere E-Mail in der die Veröffentlichung des Zertifikats
bekannt gegeben wird und wo der Antragsteller sein Zertifikat herunterladen kann.
Treten beim Registrierungsprozess Fehler auf, die zum Abbruch des
Zertifizierungsprozesses führen, beispielsweise wenn die Überprüfung der Hashwerte
oder der Signaturen fehl schlägt, wird der Antragsteller per E-Mail darüber informiert
und um ein erneutes Ausfüllen des Zertifizierungsformulars gebeten. Diese E-Mails
können größtenteils automatisch verschickt werden.
Abb.11: Erstzertifizierung Low Level Variante 1
46
47
Im Low Level Bereich ist es wichtig, einen Massenbetrieb zu ermöglichen, der trotz der
finanziellen Grenzen technisch umsetzbar ist, das allgemeine Sicherheitsniveau an der
Fachhochschule steigert, den Support- und Personalaufwand in Grenzen hält aber
trotzdem möglichst reibungslos funktioniert.
All diese Punkte wurden sowohl in Variante Eins als auch in Variante Zwei
berücksichtigt. Es wurden zwei Varianten entworfen, um zu zeigen, dass mehrere
Lösungsmöglichkeiten im Low Level Bereich existieren. Beide unterscheiden sich in
punkto Kosten, Sicherheit, Personalaufwand sowie Registrierungsprozess.
Die Schlüssellänge bei asymmetrischer und symmetrischer Verschlüsselung sowie die
Gültigkeitsdauer von Zertifikaten und Schlüsseln ist in beiden Varianten gleich. Die
Schlüsselgenerierung wird in beiden Fällen von den Betreibern der Public Key
Infrastructure übernommen.
Unterschiede sind in Variante Eins die freie Wahl des Personal Security Environment
(PSE) durch den Zertifiaktsbesitzer im Gegensatz zur Variante Zwei, wo der
Zertifikatsbesitzer einen Datenträger als PSE bekommt, auf dem zuvor generierte
Schlüsselpaare abgespeichert wurden.
Durch das PSE in Variante Zwei entstehen größere Kosten, hervorgerufen durch die
Materialkosten der Datenträger des Personal Security Environments und durch größeren
Personalaufwand in der Aufbereitung der Datenträger.
48
Beispiel einer Erstzertifizierung für Low Level Variante 2
Zu Beginn der Zertifizierung benötigt der Antragsteller ein gültiges E-Mail Konto an
der Fachhochschule. Dazu wird ein Antrag ausgefüllt und zusammen mit einem
Personal- und Studentenausweis bei einem Registration Authority Mitarbeiter
abgegeben.
Abb.12: Teil der Erstzertifizierung, E-Mail Konto und OTP Liste Variante 2
Der RA Mitarbeiter überprüft die Angaben auf dem Antrag und gibt diesen weiter an
einen zuständigen Systemadministrator des Rechenzentrums. Der Administrator legt das
E-Mail Konto an und übergibt die Zugangsdaten für das E-Mail Konto an den RAMitarbeiter.
Nach einiger Zeit muss der Antragsteller erneut beim RA Mitarbeiter vorstellig werden.
Nach erneuter Vorlage eines Lichtbildausweises bekommt der Antragsteller die
Zugangsdaten für das E-Mail Konto und eine Einmalpasswortliste ausgehändigt.
Zudem entnimmt der RA Mitarbeiter aus einem Behälter einen zufällig gewählten
Datenträger und übergibt diesen an den Antragsteller. Zusätzlich vermerkt der RA
Mitarbeiter in einer Datenbank, dass die Person einen Datenträger erhalten hat.
Auf dem Datenträger sind vorgenerierte Schlüsselpaare sowie Dokumente und
Anleitungen zur Verwendung von Zertifikaten abgelegt.
Der Antragsteller begibt sich an einen speziellen Registration Authority Client, der nur
mit dem RA Server verbunden ist. Ein Programm fordert zum Ausfüllen eines
Formulars auf. Name, Vorname, Studiengang/Fachbereich und E-Mail Adresse werden
hierbei erfasst. Zudem muss der Einsatzzweck des Zertifikats gewählt werden. Die EMail Adresse wird für Support- und Informationszwecke benötigt. Alle anderen
Informationen fließen in das Schlüsselzertifikat ein.
49
Eine Überprüfung, ob der Antragsteller Mitglied der Fachhochschule ist oder eine
andere Berechtigung zur Zertifizierung hat, wurde bereits beim ersten Besuch der
Registration Authority vollzogen. .
Über einen Drucker wird der Zertifizierungsantrag ausgedruckt und muss anschliessend
beim Registration Authority Mitarbeiter unterschrieben werden. Ist alles
vorschriftsmäßig im Programm des RA Clients eingegeben worden, wird der
Antragsteller aufgefordert den Datenträger einzulegen.
Vom Datenträger wird ein öffentlicher Schlüssel ausgelesen. Der RA Client bildet einen
Hashwert über die eingegebenen Daten und den öffentlichen Schlüssel und signiert
diese. Anschließend werden die Daten an den Registration Authority Server gesendet.
Der RA Server überprüft die Signaturen und Hashwerte. Der RA Mitarbeiter erstellt aus
den Daten und dem öffentlichen Schlüssel eine Zertifikatsvorlage, signiert diese und
speichert sie auf einen Wechseldatenträger ab.
Der Datenträger wird vom Certification Authority Mitarbeiter abgeholt und in den
Certification Authority Rechner integriert. Die Signatur der Zertifikatsvorlagen wird
überprüft. Anschließend werden alle Zertifikatsvorlagen von der CA signiert und
erhalten damit den vollwertigen Status eines Zertifikats.
Das Zertifikat ist gültig ab dem Zeitpunkt, der als Anfangsdatum festgelegt ist. Die
signierten Zertifikate werden von der CA erneut auf einen Wechseldatenträger abgelegt.
Der Datenträger wird wieder in den RA Server integriert und alle Zertifikate werden an
den Light Access Directory Protocol Server (LDAP) gesendet. Der Antragsteller erhält
eine E-Mail mit der Information, dass sein Zertifikat zum Abruf bereit liegt.
Abb.13: Erstzertifizierung Low Level Variante 2
50
51
4.2 Medium Level Zertifizerung
Im Medium Level werden alle Professoren und Dozenten zertifiziert, die längerfristig
an der Fachhochschule tätig sind. Sie haben die Wahl zwischen Low Level und Medium
Level Zertifikaten. Des weiteren werden im Medium Bereich Mitarbeiter aus der
Verwaltung sowie Systemadministratoren und bei Bedarf studentische Hilfskräfte
zertifiziert.
Im Gegensatz zum Low Level gibt es im Medium Level ein Personal Security
Environment in Form eines USB Sticks. Auf diesem Stick werden die Schlüsselpaare
sowie die Zertifikate abgelegt. Spezielle USB Sticks für X.509 Zertifikation sind bereits
preisgünstig zu bekommen.
Durch das höhere Sicherheitsniveau im Medium Level ist es zwingend nötig, jedem
Benutzer des Levels ein sicheres Personal Security Environment für seine privaten
Schlüssel zu geben. Die Personal Security Environment werden in jedem höheren Level
sicherer.
Wie im Low Level Bereich sind auch in diesem Level die gleichen Anwendungen
geplant. Das Signieren von E-Mails, die Authentifizierung sowie Single Sign-On.
Zusätzliche Anwendungen für die Public Key Infrastructure können später realisiert
werden.
Die Wahl der Schlüssellänge wird durch Empfehlungen von führenden kryptografischen
Verbänden und Unternehmen gewählt. Für das Konzept im Medium Level wird eine
Schlüssellänge von 2048 Bit bei asymmetrischer Verschlüsselung gewählt. Für die
symmetrische Verschlüsselung wird eine Schlüssellänge von 128 Bit gewählt.
Die Gültigkeitsdauer für Zertifikate und Schlüssel im Medium Level Bereich beträgt
jeweils sechs Monate bzw. bis zum jeweiligen Vertragsende kurzfristig eingestellter
Mitarbeiter. Danach müssen neue Schlüssel generiert werden, was die Ausstellung eines
neuen Zertifikats nach sich zieht.
Für bestimmte Anwendungen, wie das Signieren, sollte die Gültigkeitsdauer der
Schlüssel nicht zu lang gewählt werden. Um eine einfache technische Umsetzung des
Konzepts zu ermöglichen, wurde für Schlüssel und Zertifikat die gleiche
Gültigkeitsdauer festgelegt. 1
1
siehe auch Abb.12 Prozesse, fast identisch abgebildet, es fehlt lediglich der Drucker
52
Fallbeispiel Medium Level
Der Antragsteller muss über ein vorhandenes E-Mail Konto an der FHTW verfügen.
Falls ein solches Konto noch nicht vorhanden ist, muss es durch Ausfüllen eines
Formulares beim Registration Authority Mitarbeiter beantragt werden. Der
Antragsteller kommt mit einem USB Datenträger zum RA Mitarbeiter und weist sich
diesem gegenüber mit einem gültigen Lichtbildausweis aus. Der RA Mitarbeiter
übergibt dem Antragsteller seine Kontodaten, falls noch nicht vorhanden, und eine
Einmalpasswortliste für die Registrierungsprozesse. In einer Datenbank vermerkt der
RA Mitarbeiter alle Personen, die sich per USB Datenträger zertifizieren lassen.
Zusätzlich vereinbaren der Antragsteller und der Registration Authority Mitarbeiter ein
Geheimnis. Bei diesem Geheimnis handelt es sich um ein Passwort bzw. eine längere
Passphrase, welche nur diesen beiden Personen bekannt ist. Das Passwort/Passphrase
wird ebenfalls in der Datenbank hinterlegt. Es ermöglicht dem Zertifikatsbesitzer später
eine telefonische Sperrung vorzunehmen und sich mit dem entsprechenden Geheimnis
zu authentifizieren.
Der Antragsteller begibt sich mit seinem USB Datenträger zu einem speziellen
Registration Authority Client mit USB Anschluss. Der USB Stick wird an einen USB
Port angeschlossen, ein Programm generiert die Schlüsselpaare für den Antragsteller
und speichert dies auf dem USB Stick ab. Am RA Client gibt der Antragsteller in ein
Formular alle Daten zur Zertifizierung ein. Der RA Client liest einen öffentlichen
Schlüssel vom USB Datenträger und bildet über den Schlüssel sowie die eingegebenen
Daten einen Hashwert und signiert die Daten und den Hashwert.
Der Antrag für die Zertifizierung wird über einen angeschlossenen Drucker direkt beim
Registration Authority Mitarbeiter ausgedruckt. Der Antragsteller muss nach dem
Absenden des Formulares den ausgedruckten Zertifizierungsantrag unterschreiben. Der
RA Client sendet die signierten Daten an den RA Server, der die Signatur und den
Hashwert prüft. Ein RA Mitarbeiter erstellt dann auf Basis der eingegebenen Daten und
dem öffentlichen Schlüssel Zertifikatsvorlagen, welche vom RA Server signiert und auf
einem Wechseldatenträger gespeichert werden.
Ein Certification Authority Mitarbeiter nimmt den Datenträger und integriert diesen in
den CA Rechner. Dort werden alle Signaturen der Zertifikatsvorlagen überprüft und
anschließend mit von der Certification Authority signiert. Aus den Zertifikatsvorlagen
sind durch die Signatur der CA vollwertige Zertifikate geworden. Sie sind für den im
Zertifikat festgelegten Zeitraum gültig. Alle signierten Zertifikate werden vom CA
Rechner auf einem Wechseldatenträger gespeichert.
Der CA Mitarbeiter integriert den Datenträger wieder in den Registration Authority
Server. Von dort werden alle Zertifikate an den Light Access Directory Protokoll Server
(LDAP) gesendet. Der Antragsteller wird per E-Mail darüber informiert, dass sein
Zertifikat zum Abruf bereit steht. Treten beim Registrierungsprozess Fehler auf, die
zum Abbruch des Zertifizierungsprozesses führen, beispielsweise wenn die
Überprüfung der Hashwerte oder der Signaturen fehl schlägt, wird der Antragsteller per
E-Mail darüber informiert und um ein erneutes Ausfüllen des Zertifizierungsformulars
gebeten. Diese E-Mails können größtenteils automatisch verschickt werden.
53
4.3 High Level Zertifizierung
Das High Level wurde konzipiert, um der Sicherheit in besonders kritischen Bereichen
gerecht zu werden beziehungsweise die Sicherheit zu erhöhen. Diese Bereiche sind
beispielsweise in der Personalabteilung, im Prüfungsamt und in der
Fachhochschulleitung zu finden.
Zertifiziert werden in diesem Level also vor allem der akademische Senat, der Präsident
der Fachhochschule, der Kanzler sowie Mitarbeiter des Prüfungs- und Personalamtes.
Natürlich gehören auch die Mitarbeiter der Public Key Infrastructure sowie die
Certification Authority zum High Level Bereich.
Als Personal Security Environment wird eine kryptografische Smartcard empfohlen. Sie
bietet momentan den bestmöglichen Schutz für private Schlüssel. Das Auslesen des
privaten Schlüssels ist nur sehr schwer möglich. 1
Wie in den vorher schon beschriebenen Leveln sind auch im High Level Bereich die
gleichen Anwendungen geplant, das Signieren von E-Mails, die Authentifizierung.
Zusätzliche Anwendungen für die Public Key Infrastructure wie zum Beispiel Key
Recovery können später realisiert werden.
Single Sign-On wird aufgrund der nicht vorhandenen Laborzutritte und des hohen
Sicherheitsrisikos für Mitarbeiter im Prüfungs- und Personalamt sowie für die Leitung
der Fachhochschule nicht angeboten.
Die Schlüssellänge für die asymmetrische und symmetrische Verschlüsselung im High
Level ist wie in den anderen beiden Leveln gewählt und richtet sich nach aktuellen
Empfehlungen führender kryptografischer Unternehmen und Verbänden. Für
asymmetrische Verschlüsselung beträgt die Schlüssellänge 2048 Bit und für
symmetrische Verschlüsselung wird eine Schlüssellänge von 128 Bit verwendet.
Schlüssel und Zertifikat besitzen ein Gültigkeitszeitraum von sechs Monaten. Nach
Ablauf des Zeitraumes muss der Zertifikatsbesitzer ein neues Zertifikat beantragen.
Zudem erhält er ein neu generiertes Schlüsselpaar.
Um das Konzept bei einer technischen Umsetzung nicht zu kompliziert zu gestalten,
wurde eine einheitliche Gültigkeitsdauer für Zertifikate und Schlüssel gewählt. Für
bestimmte Anwendungen, wie das Signieren, sollte die Gültigkeitsdauer der Schlüssel
nicht zu lang gewählt werden.
1
Quelle: SecCommerce Fachwissen Technologie Smartcards Physikalische Sicherheit.htm
(www.seccommerce.de)
54
Fallbeispiel High Level
Für High Level benötigt der Antragsteller ein gültiges E-Mail Konto an der
Fachhochschule. Falls dies nicht vorhanden ist, kann es bei einem Registration
Authority Mitarbeiter beantragt werden. Der Antragsteller muss einen Lichtbildausweis
vorzeigen. Der Antrag wird an einen Systemadministrator übergeben, der das E-Mail
Konto erstellt. Der Registration Authority Mitarbeiter übergibt an den Antragsteller die
Zugangsdaten für das E-Mail Konto, eine Einmalpasswortliste und eine leere
kryptografische Smartcard. In einer Datenbank wird vom RA Mitarbeiter festgehalten,
wer wann eine Smartcard bekommen hat.
Der Antragsteller vereinbart mit dem Registration Authority Mitarbeiter ein Geheimnis.
Es handelt sich dabei um ein Passwort bzw. um eine längere Passphrase, die nur den
beiden Personen bekannt ist und die dem Antragsteller die Möglichkeit bietet, seine
Zertifikate per Telefon sperren zu lassen. Das Passwort wird dabei in einer Datenbank
hinterlegt, die nur von einem zuständigen Registration Authority Mitarbeiter abgefragt
werden kann.
Der Antragsteller begibt sich mit seiner Smartcard zu einem speziellen Registration
Authority Client. Dort wird die Smartcard in ein Kartenlesegerät eingeführt. Ein
Programm zur Schlüsselgenerierung wird gestartet, welches die Schlüssel auf die
Smartcard schreibt. Der Antrag für die Zertifizierung wird über einen angeschlossenen
Drucker direkt beim Registration Authority Mitarbeiter ausgedruckt. Der Antragsteller
muss nach dem Absenden des Formulars den ausgedruckten Zertifizierungsantrag
unterschreiben. Vom öffentlichen Schlüssel wird dabei eine Kopie erstellt. Über die
Schlüsselkopie und alle eingegebenen Daten wird ein Hashwert gebildet. Anschließend
signiert der RA Client alle Daten und sendet sie an den Registration Authority Server,
welcher als erstes die Signatur überprüft. Ein Registration Authority Mitarbeiter erstellt
aus den Daten des Antragstellers und dem öffentlichen Schlüssel eine Zertifikatsvorlage
welche vom Registration Authority Server signiert und auf einem Wechseldatenträger
gespeichert wird.
Der Certification Authority Mitarbeiter nimmt den Datenträger und integriert diesen in
den Certification Authority Rechner. Dort werden die Signaturen der
Zertifikatsvorlagen überprüft und anschließend von der CA signiert. Aus den
Zertifikatsvorlagen sind mit der Signatur der CA vollwertige Zertifikate geworden. Alle
signierten Zertifikate werden auf einem Wechseldatenträger gespeichert, der von einem
Certification Authority Mitarbeiter wieder in den RA Server integriert wird. Alle
signierten Zertifikate werden vom RA Server an den Light Access Directory Protocol
Server (LDAP) gesendet. Der Antragsteller erhält eine E-Mail, dass sein Zertifikat
freigegeben wurde.
Treten bei der Überprüfung des Hashwertes oder der Signatur Fehler auf, welche zum
Abbruch des Zertifizierungsvorganges führen, wird der Antragsteller per E-Mail
darüber informiert und um ein erneutes Ausfüllen des Zertifizierungsformulars gebeten.
Diese E-Mails können größtenteils automatisch verschickt werden.1
1
siehe auch Abb.12 Prozesse, fast identisch abgebildet, es fehlt lediglich der Drucker
55
4.4 Sperren von Zertifikaten
Die Abläufe für das Sperren, sowie die Gründe die dazu führen können, sind in allen
drei Levels gleich. Deshalb existieren auch festgelegte Prozesse für die Sperrung von
Zertifikaten. Eine Sperrung kann von der Certification Authority oder vom
Zertifikatsbesitzer vorgenommen werden. Den rein technischen Vorgang des Sperrens
nimmt die Certification Authority vor.
4.4.1
Sperrung durch die Certification Authority
Ein Sperrgrund durch die Certification Authority kann das Key-Sharing sein. Der
Zertifikatsbesitzer hat hierbei wissentlich seinen privaten Key an nicht zertifizierte
Personen weitergegeben und sorgt damit für ein Sicherheitsloch innerhalb des Systems.
Ein Beispiel dafür ist, wenn eine Person an zwei verschiedenen Standorten der
Fachhochschule zur gleichen Zeit an zwei Rechnern eingeloggt ist. Wird dieser Vorfall
von einem Systemadministrator bemerkt, kann er mit den entsprechenden Logfiles die
Sperrung des Zertifikats des verdächtigen Benutzers bei einem Certification Authority
Mitarbeiter beantragen. Der Zertifikatsbesitzer wird per E-Mail über die Sperrung in
Kenntnis gesetzt. Der Sperrgrund ist hier die mutwillige Kompromittierung des privaten
Schlüssels.
In diesem Fall hat der Verdächtige maximal 14 Tage Zeit den Fall zu erklären. Er erhält
eine E-Mail, mit der Bitte den Sachverhalt mit dem zuständigen Laboringenieur oder
Systemadministrator zu klären. Geschieht dies nicht, erfolgt eine Sperrung des
Zertifikats und der Benutzer muss sich zu dem erhobenen Verdacht äußern, bevor er
sich ein neues Zertifikat ausstellen lassen kann.
Lässt sich das Problem zwischen dem Benutzer und dem Systemadministrator klären,
wird das Zertifikat nicht gesperrt. Andernfalls erfolgt die sofortige Sperrung. Der
Benutzer wird von der weiteren Zertifizierung ausgeschlossen und erhält bis auf
weiteres kein neues Zertifikat.
Dieselben Prozeduren gelten auch bei Missbrauch der Zertifikate, zum Beispiel beim
illegalen Downloaden von Copyright geschützter Software, Musik und Filmen, sowie
illegalen Aktivitäten die Sicherheitslöcher ausnutzen oder dazu führen, dass diese
entstehen sowie Denial of Service (DoS) Attacken und ähnlichem.
Sperrung durch die CA bei Exmatrikulation / Ausscheiden von bereits Zertifizierten
Personen (vorzeitig und ungeplant). Die CA wird vom Prüfungsamt/Personalstelle
darüber informiert, dass der Student/Mitarbeiter während des laufenden Semesters nicht
mehr an der FHTW sein wird und damit können seine Zertifikate sofort gesperrt
werden.
Bei triftigen Gründen können Mitarbeiter/Professoren eine Sperrung von Zertifikaten
bei der Registration Authority verlangen. Hierfür gilt es genaue Regeln zu definieren.
Wer bei der Certification Authority eine Sperrung eines anderen Zertifikats verlangt,
muss genau belegen können warum. Dazu muss er persönlich anwesend sein und seine
Gründe dem zuständigen Mitarbeiter vorlegen.
4.4.2
56
Sperrung durch den Benutzer
Der Zertifikatsbesitzer kann seine Zertifikate selbst sperren lassen. Gründe dafür wären,
dass seine privaten Schlüssel kompromittiert sowie das Personal Security Environment
beziehungsweise die privaten Schlüssel verloren gingen oder zerstört wurden.
Der Zertifikatsbesitzer bemerkt selbst, dass sein Privat Key kompromittiert oder zerstört
wurde. Der Benutzer muss sich auf die Certification Authority Webseite begeben. Die
Kommunikationsleitung wird per Secure Socket Layer (SSL) verschlüsselt. Durch die
Eingabe von Namen, eines Sperrgrundes und eines Einmalpasswortes kann die
Sperrung des Zertifikats online erledigt werden.
Im Medium und High Level wäre zudem eine telefonische Sperrung der Zertifikate
möglich. Die hohe Benutzeranzahl im Low Level lässt den organisatorischen Aufwand
hierfür zu groß werden.
Bei einer telefonischen Sperrung muss der Zertifikatsbesitzer beim
Registrierungsprozess ein eindeutiges Geheimnis oder eine Phrase hinterlegen. Dieses
Geheimnis bzw. die Phrase wird telefonisch vom Certification Authority Mitarbeiter
abgefragt. Danach wird nach dem Sperrgrund gefragt und das Zertifikat gesperrt.
Es werden immer alle Zertifikate des Besitzers gesperrt, da sich mit großer
Wahrscheinlichkeit alle Schlüsselpaare im gleichen Personal Security Environment
(PSE) des Zertifikatbesitzers befinden. Somit muss davon ausgegangen werden, dass
die anderen Schlüssel wahrscheinlich auch kompromittiert oder zerstört sind.
Um an neue Zertifikate zu gelangen, muss der Benutzer jedes Mal den
Erstzertifizierungsprozess durchlaufen. Er benötigt dabei kein neues E-Mail Konto,
muss jedoch bei einer Registration Authority vorstellig werden, falls seine
Einmalpasswortliste abgelaufen ist bzw. nur noch ein OTP vorhanden ist.
Zertifikatsbesitzer im Medium und High Level Bereich müssen nach jeder Sperrung bei
der Registration Authority vorstellig werden, Low Level Zertifikatsbesitzer müssen je
nach Variante vorstellig werden, wenn die Einmalpasswortliste aufgebraucht wurde.
Sollte der Zertifikatsbesitzer seine Liste mit Einmalpasswörtern nicht finden und will
trotzdem seine Zertifikate sperren, muss er sich zur Registration Authority im
Rechenzentrum der FHTW begeben und dort seine Zertifikate unter der Vorlage seines
Ausweises sperren lassen.
Dort kann der Zertifikatsbesitzer auch eine neue Liste mit Einmalpasswörtern
generieren lassen. Anschließend durchläuft der Benutzer wieder die Erstzertifizierung
seines jeweiligen Levels.
4.4.3
57
Temporäres Sperren von Zertifikaten
Der Zertifikatsbesitzer erhält die Möglichkeit seine Zertifikate temporär sperren zu
lassen und in dieser Zeit vor Missbrauch zu schützen. Ist der Zertifikatsbesitzer
beispielsweise für einen Mindestzeitraum von 4 Wochen im Urlaub oder studiert ein
Semester im Ausland, befindet sich im Praktikum oder Ähnliches, kann er seine
Zertifikate für diesen Zeitraum bzw. bis zum Ende der Gültigkeit des Zertifikats für
ungültig erklären.
Über das Webinterface der Certification Authority wird eine sichere
Kommunikationsverbindung per SSL aufgebaut. Der Zertifikatsbesitzer authentifiziert
sich und gibt den Zeitraum der gewünschten Sperrung ein, sowie den Grund der
Sperrung. Zum Absenden der Informationen an die Certification Authority muss er ein
Einmalpasswort eingeben. Das Zertifikat wird für den gewählten Zeitraum gesperrt.
Um den Aufwand für die Certification Authority Mitarbeiter möglichst gering zu halten,
sollte der Mindestzeitraum für eine temporäre Sperrung im Low Level möglichst groß
gewählt werden. Um den Sicherheitsanforderungen der anderen beiden Level gerecht zu
werden, sollten hier die Mindestzeiträume für eine temporäre Sperrung klein gewählt
werden.
Die Möglichkeit der temporären Sperrung von Zertifikaten ist eine zusätzliche Leistung
der Certification Authority an ihre Benutzer. Damit wird den Zertifikatsbenutzern mehr
Service geboten. Zudem wird das persönliche Sicherheitsempfinden der
Zertifikatsbesitzer während des Sperrzeitraums erhöht.
4.4.4
Erneuerung von Zertifikaten
Zertifikate besitzen einen festgelegten Gültigkeitszeitraum. Aus diesem Grund müssen
diese, möglichst rechtzeitig, erneuert werden. Das Zertifikat kann vom Besitzer
frühestens 20 Tage vor Ablauf der Gültigkeit erneuert werden. Jeweils zehn Tage, drei
Tage und vierundzwanzig Stunden vor Ablauf des Zertifikats erhält der Benutzer eine
E-Mail mit der Aufforderung, seine ablaufenden Zertifikate zu erneuern. Ist nach
Ablauf dieser Zeit noch keine Erneuerung vollzogen, sind die Zertifikate ungültig.
Da alle ausgestellten Zertifikate inklusive der Schlüssel automatisch zum Semesterende
auslaufen, muss sich der Zertifikatsbesitzer neue Zertifikate ausstellen lassen und neue
Schlüsselpaare genieren lassen. Eine Verlängerung der Zertifikate ist nicht möglich. Der
Zertifikatsbesitzer durchläuft den jeweiligen Registrationsprozess seinen Levels.
Mehr Informationen zu den Themen Prozesse für PKI Systeme sind in folgenden
Büchern zu finden: [NaDuJo], [AdaLlo], [3].
Organisatorische Details zur PKI
58
5. Organisatorische Details zur PKI
Der Rechner, welcher als Certification Authority eingesetzt wird, muss vor
unautorisiertem Zugriff geschützt werden. Das heißt, dass der Zugriff auf diesen
Rechner nur bestimmten Personen gestattet ist. Am einfachsten lässt sich diese
Bedingung damit erfüllen, dass der Computer in einem speziellen Raum aufbewahrt
wird, für den nur bestimmte Personen einen Schlüssel besitzen oder erhalten können.
Zudem sollte der Computer nicht einfach in diesem Raum fest installiert sein. Besser, es
wird ein Notebook als Certification Authority Computer benutzt. Ein Notebook kann
zusätzlich in dem abschließbaren Raum geschützt werden, beispielsweise durch die
Unterbringung in einem sicheren und abschliessbaren Schrank oder Safe.
Der Laptop selbst kann zum Beispiel durch Festplattenverschlüsselungsprogramme wie
Safeguard Easy1 zusätzlich geschützt werden. Auch eine benutzerspezifische
Authentifizierung über das verwendete Betriebsystem ist möglich.
Auf jeden Fall benötigt die Certification Authority den höchstmöglichen Schutz
innerhalb der gesamten Public Key Infrastructure. Es muss unter allen Umständen
verhindert werden, dass die Certification Authority oder ihre Schlüssel kompromittiert
werden können.
Im Konzept wurden RA und CA voneinander getrennt. Kryptographieexperten wie
Bruce Schneier halten eine Variante, die Certification Authority und Registration
Authority für sicherer, da eine Manipulation bei der Zertifizierung schwieriger ist.
Der Entschluss für eine funktionelle Trennung der beiden Authorities lag darin, dass die
Zertifikate nicht sofort an Ort und Stelle erstellt und signiert werden. Zwischen Antrag
und Zertifikatserteilung liegt ein Zeitraum von mehreren Stunden bzw. Tagen.
Der Certifiaction Authority Rechner wird nur für einen bestimmten Zeitraum am Tag
benutzt und wird dann wieder sicher verschlossen und steht somit nicht den ganzen Tag
vielleicht sogar unbeobachtet in der Zertifizierungsstelle.
Die Trennung von CA und RA hat zudem den Vorteil, dass keine automatische
Signierung von Zertifikaten oder Sperrlisten entstehen kann. Die Signierung durch die
Certifiaction Authority benötigt immer eine manuelle Handlung einer zuständigen
Person.
So kann vermieden werden, dass durch eventuelles Auftreten von Trojanern oder Viren,
ein Programmcode eingeschleust wird, der selbstständig eigene Zertifikate erstellt und
die CA veranlasst, diese zu signieren.
1
Quelle: Infinigate ___ Utimaco SafeGuard Easy.htm (www.utimaco.de)
59
Registration Authorities, Clients und lokale RA
An der Fachhochschule wird es neben der großen Registration Authority weitere kleine
lokale Registration Authorities an den verschiedenen Standorten der FHTW geben. Die
lokalen Registration Authorities sind nur für Medium und High Level Benutzer
zugelassen.
Low Level Benutzer müssen immer an der eigentlichen Registration Authority
zertifiziert werden. Die Zertifizierungsprozedur läuft dabei genauso ab wie bei der
Registration Authority.
Die Schlüsselgenerierung wird vom zuständigen Registration Authority Mitarbeiter
übernommen, welcher die Schlüsselpaare direkt auf dem Personal Security
Environment des Zertifizierenden ablegt. Die generierten Schlüssel werden nur auf dem
PSE des Antragstellers gespeichert, einzig vom öffentlichen Schlüssel wird eine Kopie
zu den Antragsdaten des Benutzers angefügt.
Der Antragsteller begibt sich mit seinem Personal Security Environment an einen
lokalen Registration Authority Client und gibt dort alle zur Zertifizierung erforderlichen
Daten ein. Die Antragsdaten werden zusätzlich ausgedruckt und vom Antragsteller
unterschrieben.
Der ausgedruckte Antrag wird von einem zuständigen Registration Authority
Mitarbeiter durch eine Ausweiskontrolle überprüft. Alle Antragsdaten und Schlüssel
werden vom Registration Authority Mitarbeiter signiert und auf einem
Wechseldatenträger gespeichert.
Dieser wird von einem vertrauensvollen Mitarbeiter der Fachhochschule zur
Certification Authority transportiert. Dort werden alle Signaturen geprüft und die
Zertifikate von der Certification Authority signiert und auf einem Wechseldatenträger
gespeichert.
Der Certification Authority Mitarbeiter sorgt dafür, dass alle Zertifikate über das Light
Directory Access Protocol (LDAP) veröffentlicht werden und die Zertifikatsbesitzer per
E-Mail darüber informiert werden.
Bei jedem Registrierungsprozess im High und Medium Level werden alle eingegebenen
Daten zusätzlich ausgedruckt und vom Antragsteller unterschrieben. Mit diesem
unterschriebenen Antrag hat der Benutzer gleichzeitig die Geschäftsordnung und Policy
der Certification Authority anerkannt.
Im Low Level Bereich werden in Variante Eins keine Anträge ausgedruckt und
unterschrieben. Die Anträge können allenfalls in digitaler Form gespeichert werden. In
Variante Zwei können die Anträge durchaus ausgedruckt und vom Antragsteller
unterschrieben werden.
60
Neben den Anträgen erfasst die Registration Authority in einer Datenbank den Namen
des Antragstellers sowie das zugehörige Level und das Datum an dem der Antrag
gestellt wurde. Des Weiteren kann zusätzlich erfasst werden, dass eine
Einmalpasswortliste generiert und ausgegeben wurde.
Es dürfen jedoch nur für die Zertifizierung relevante Daten erfasst werden, wie
beispielsweise Name und Vorname des Antragstellers. Auf keinen Fall dürfen
massenhaft personenbezogene Daten wie Adresse, Geburtstag, Matrikelnummer oder
die Anzahl der bereits studierten Semester erfasst werden, da dies Social Engineering
unterstützt und einen gläsernen Benutzer ermöglicht.
Die Registration Authority Clients sind so gestaltet, dass nur das entsprechende
Personal Security Environment angeschlossen werden kann. Alle anderen Anschlüsse
sind nicht für den Benutzer freigegeben.
Der Client kann nicht einfach neu gestartet werden. Auch ist es nicht möglich, andere
Programme zu starten. Der Client dient nur zur reinen Dateneingabe und zum Auslesen
des öffentlichen Schlüssels vom PSE. Das Starten anderer Programme ist nicht zulässig
und muss technisch unterbunden werden.
Sind alle Daten eines Antragstellers erfasst und eine Kopie vom öffentlichen Schlüssel
erstellt worden, wird über alles ein Hashwert berechnet. Die Daten und der Hashwert
werden vom Client signiert und je nach Prozedur auf einem Wechseldatenträger
gespeichert oder an den Registration Authority Server gesendet.
Registration Authority Server
Der Registration Authority Server dient vor allem als Sammelstelle für alle
Registrierungsdaten. Auf diesem Server werden alle Daten überprüft und anschließend
von einem zuständigen Mitarbeiter zu so genannten Zertifikatsvorlagen umgewandelt.
Der Registration Server darf keine direkte Verbindung ins Internet besitzen. Zudem
muss auch er gut geschützt werden, um eine Veränderung der Zertifizierungsdaten zu
verhindern. Es macht Sinn, den Registration Authority Server in der Nähe der
Certification Authority zu positionieren, jedoch nicht im selben Raum.
Maßnahmen wie Zugriffsschutz, sowohl über das Netzwerk als auch über den normalen
Arbeitsplatz, müssen realisiert werden. Da das Konzept eine Trennung von RA und CA
vornimmt, müssen alle Daten, die für ein Zertifikat nötig sind, einen gültigen Hashwert
und eine gültige Signatur besitzen.
Über den Registration Authority Server wird der Antragsteller per E-Mail über den
Status der Zertifizierung informiert. Zudem werden alle Zertifikate vom RA Server an
den LDAP Server gesendet.
Sperrlisten werden ebenfalls auf dem Registration Authority Server von einem
zuständigen Mitarbeiter erstellt und später von der Certification Authority signiert und
veröffentlicht.
61
Schlüsselserver
Die Generierung der Schlüssel erfolgt je nach Variante bereits vor dem
Zertifizierungsantrag oder während des Zertifizierungsantrages. Im Low Level Bereich
gibt es beide Varianten. Entweder werden Schlüsselpaare auf Vorrat generiert und auf
einem Datenträger abgelegt oder die Schlüssel werden live während des
Registrierungsprozesses erstellt.
Bei der Schlüsselgenerierung ist darauf zu achten, dass jeder Schlüssel eindeutig ist. Es
darf nicht vorkommen, dass Schlüssel doppelt generiert werden. Um dies zu verhindern,
werden bei der Schlüsselgenerierung rein zufällig gemessene Werte hinzugenommen,
die in die Schlüsselgenerierung einfließen. Nützlich sind zum Beispiel Bewegungen mit
der Maus, Zeitmessungen beim Festplattenzugriff, der Zerfall von radioaktivem
Material oder die Eingabedauer zwischen zwei Werten über die Tastatur.
Um für wirklich gute Schlüssel garantieren zu können, wird die Schlüsselgenerierung
nicht den Antragstellern überlassen. Nicht alle Anwender besitzen fundierte
Computerkenntnisse und sind somit mit einer Schlüsselgenerierung überfordert.
Wenn im Low Level Bereich die Schlüssel bereits vorher auf Datenträger gespeichert
werden um anschließend verteilt zu werden, sind die Schlüssel keiner Person
zugeordnet. Diese Zuordnung erfolgt erst wenn der Datenträger an einen Antragsteller
übergeben worden ist.
Es darf im gesamten System der Public Key Infrastructure nie zu einer Kopie eines
privaten Schlüssels kommen. Entweder müssen die Schlüssel direkt auf dem Personal
Security Environment erzeugt werden oder nach der Erzeugung und dem Transfer auf
das PSE gelöscht werden.
Der Speicherbereich muss konsequent gelöscht werden und es darf nicht möglich sein
aus einem gelöschten Bereich die Schlüssel wieder zu rekonstruieren. Jeder private
Schlüssel muss ein Unikat bleiben. Alles andere gilt bereits als Kompromittierung des
privaten Schlüssels.
Im Medium und High Level Bereich werden die Schlüsselpaare direkt von einem
zuständigen Registration Authority Mitarbeiter in unmittelbarer Anwesenheit des
Antragstellers generiert und auf das jeweilige Personal Security Environment (PSE)
abgespeichert. Es existiert keine weitere Kopie des Schlüsselpaares beim Registration
Authority Mitarbeiter.
62
Einmalpasswortliste
Einmalpasswörter (One Time Passwords – OTP) werden benötigt, um sich bei
bestimmten Prozessen zu authentifizieren. Der Download von Schlüsselpaaren oder das
Sperren von Zertifikaten funktioniert online nur mit Hilfe von Einmalpasswörtern.
Jeder Antragsteller bekommt eine eigens für ihn generierte Liste mit
Einmalpasswörtern. Diese Liste wird vom Registration Authority Mitarbeiter erzeugt.
Die Passwortliste ist begrenzt auf eine gewisse Anzahl. Das letzte Passwort wird auf der
Liste speziell markiert und ist reserviert für eine Sperrung aller für den Benutzer
ausgestellten Zertifikate.
Abb.14: Generieren einer Passwortliste
Die Passwortliste muss vom Benutzer der Reihenfolge nach abgearbeitet werden. Sind
alle Passwörter verbraucht, muss der Zertifikatsbesitzer erneut bei einem Registration
Authority Mitarbeiter vorstellig werden und eine neue Liste mit Einmalpasswörtern
beantragen.
Funktionsweise einer Passwortliste
Um zu vermeiden, dass eine Datenbank mit allen Einmalpasswörtern aller Benutzer
entsteht, wird ein spezielles Verfahren benötigt. Eine solche Datenbank wäre ein großen
Sicherheitsrisiko und ein potentielles Angriffsziel für Hacker und andere nicht
autorisierte Personen.
Für die Generierung der Passwörter wird ein zufälliger Startwert benötigt. Dieser
Startwert wird über einen speziellen Algorithmus verschlüsselt. Der verschlüsselte Wert
wird gespeichert und wieder durch den Algorithmus verschlüsselt. Die ganze Prozedur
wird solange wiederholt, bis eine ausreichende Anzahl von verschlüsselten Werten
erreicht ist. Diese immer wieder erneut verschlüsselten Werte sind die so genannten
Einmalpasswörter.
63
Alle Einmalpasswörter werden in umgekehrter Reihenfolge aufgelistet. Der letzte
generierte Wert steht dabei an erster Stelle in der Liste. Trotzdem wird auch hier eine
Datenbank benötigt. Jedoch wird hier jedem Benutzer immer nur ein bestimmtes
Einmalpasswort und nicht alle generierten Passwörter zugeordnet.
Sind fünfzig Passwörter generiert worden, wird das letzte Passwort dem Benutzer in der
Datenbank zugeordnet. Der Zertifikatsbenutzer erhält eine Liste mit neunundvierzig
Einmalpasswörtern, die der Reihenfolge nach verbraucht werden müssen.
Das neunundvierzigste Passwort wird vom Benutzer verwendet und durch den gleichen
Algorithmus gesendet der bei der Erstellung auch verwendet wird. Dadurch wird das
fünfzigste Passwort, welches nur in der Datenbank existiert, erneut generiert. Der
generierte Wert muss mit dem Wert in der Datenbank übereinstimmen, damit der
gewählte Prozess weitergeführt werden kann.
Abb.15: Mechanismus für Passwortliste
Das eingegebene und damit verbrauchte neunundvierzigste Einmalpasswort wird nun in
die Datenbank anstelle des letzten Wortes geschrieben. Somit stehen in der Datenbank
immer nur bereits verbrauchte Passwörter, mit denen kein Missbrauch mehr betrieben
werden kann.
Der Zertifikatsbenutzer streicht das verbrauchte Passwort in seiner Liste ab und muss
bei einer weiteren Passwortabfrage das nachfolgende Passwort benutzen.
64
Es existieren Vorschläge für die Personal Security Environments jedes Levels. Im Low
Level Bereich muss ein Medium gewählt werden, dass für die Fachhochschule
finanzierbar ist und trotzdem für eine gewisse Sicherheit der Schlüsselpaare sorgt.
Mögliche Varianten wären beispielsweise Disketten oder Compact Disks. Bei der
Auswahl des Mediums muss darauf geachtet werden, dass möglichst alle Computer der
Fachhochschule auch mit entsprechenden Lesegeräten ausgestattet sind.
Dies ist bei Disketten und Compact Disks der Fall, wobei die Verbreitung mit CD
Lesegeräten verbreiteter ist, da es zum Beispiel im Mac Labor keine Diskettenlaufwerke
gibt.
Im Medium und High Level Bereich wird die Wahl eines sehr sicheren Mediums
empfohlen, um dem höheren Sicherheitsanspruch der Level gerecht zu werden. Im
Medium Level wird ein USB Stick mit kryptografischen Funktionen empfohlen. Im
High Level wird als Medium eine kryptografische Smartcard empfohlen.
Mehr Informationen zu den Themen Hintergrundinformationen sind in folgenden
Büchern zu finden: [NaDuJo], [Gai], [13], [15], [16].
Aufbau der Zertifikate und Sperrlisten
65
6. Aufbau der Zertifikate und Sperrlisten
Dieses Kapitel entstand in Zusammenarbeit mit Daniel Henze. Durch
Themenüberschneidung finden sich Teile dieses Kapitels auch in seiner Diplomarbeit.
Der X.509 ist ein kryptografischer Standard aus dem Jahr 1988. Bis heute existieren
mehrere Versionen und Profile des Standards. Bei den Profilen handelt es sich um
Standards wie beispielsweise Public Key Infrastructure X.509 (PKIX) und International
Signature Interoperability Specification (ISIS).
Diese Standards definieren eigene Profile, die auf dem X.509 Standard basieren. Bei
Profilen werden unerwünschte Informationen weggelassen und andere Funktionalitäten
hinzugefügt. X.509 wurde leider mit vielen kleinen Fehlern entworfen.
Der X.509 Standard wurde über die Jahre weiterentwickelt und ist mittlerweile in
Version drei verfügbar. In Version zwei wurden Erweiterungen eingeführt, die jedoch
bis heute kaum genutzt werden. Erst in Version drei wurden wirklich nützliche
Neuerungen zum X.509 Standard hinzugefügt.
So war es in Version drei endlich möglich, beliebige Inhaber und Certification
Authority Namen zu vergeben. Unter anderem können hierfür auch E-Mail Adressen
verwendet werden. Schlüssel können in Version Drei des X.509 Standards einem
Verwendungszweck zugeordnet werden. Diese Schlüssel dürfen nur für die definierten
Prozesse verwendet werden.
Zusätzlich können Informationen über die Certificate Policy der jeweiligen Certification
Authority dem Zertifikat hinzugefügt werden. Damit haben die verschiedenen Besitzer
von Zertifikaten bzw. die Certification Authorities selbst die Chance, die Zertifikate auf
die jeweiligen Registrierungsmaßnahmen hin zu überprüfen.
Es gibt zwei verschiedene Zertifikatstypen, die sich wiederum in weitere Zertifikatarten
unterteilen lassen. Zum einen wird in Schlüssel- und Attributzertifikate unterschieden.
In einem Schlüsselzertifikat werden verschiedene überprüfte Informationen sowie der
zugehörige öffentliche Schlüssel einer Identität zusammengefasst.
Attributzertifikate enthalten zusätzliche Autorisierungsinformationen und sind jeweils
an die dazugehörigen Schlüsselzertifikate gebunden. Die Autorisierungsinformationen
geben dem Zertifikatsbesitzer bestimmte Rechte, um Prozesse auszuführen.
Attributzertifikate treten bisher in der Praxis so gut wie gar nicht auf.
Schlüsselzertifikate lassen sich wiederum in Teilnehmer- und Certification Authority
Zertifikate unterteilen. Teilnehmerzertifikate sind reine Benutzerzertifikate. Bei den
Certification Authorisation Zertifikaten handelt es sich um Zertifikate, mit denen
bestimmte Prozesse wie das Signieren von Teilnehmerzertifikaten oder das Ausstellen
von Cross Zertifikaten für andere Certification Authorities möglich werden.
66
6.1 Schlüsselzertifikate
Bei einem Schlüsselzertifikat werden von der Registration Authority geprüfte Daten
eines Teilnehmers zusammen mit einer Kopie seines öffentlichen Schlüssels verbunden.
Schlüsselzertifikate dienen zur eindeutigen Authentifizierung einer Identität (Mensch,
Hardware, Software).
Zur Darstellung von Zertifikaten wird der Beschreibungsformalismus ASN-1
verwendet. Diese Form ist jedoch relativ kompliziert darzustellen. Der grafische Aufbau
eines Zertifikats nach X.509 Version drei sieht folgendermaßen aus:
Versionsnummer (Version Number)
Seriennummer (Serial Number)
Signatur (Signature)
Aussteller (Issuer)
Gültigkeitsdauer (Validity)
Teilnehmer (Subject)
Public Key Informationen des Teilnehmers (Subject Public Key Info)
Kennung des Ausstellers (Issuer Unique Identifier)
Kennung des Teilnehmers (Subject Unique Identifier)
Erweiterungen (Extensions)
Tab.2: Aufbau eines Zertifikats (X.509 V3)
Nachfolgend werden alle Felder eines Schlüsselzertifikats benannt, dessen Funktion
erklärt und ein Beispiel für die mögliche Verwendung an der Fachhochschule aufzeigt.
67
6.1.1
Felder eines Schlüsselzertifikats
Feldbezeichnung Verwendungsbeispiel
Zusätzliche Informationen
Versionsnummer
V3
Die Version drei der X.509 Spezifikation
enthält und unterstützt alle Neuerungen
und Erweiterungen.
Seriennummer
99
Die Seriennummern werden vom jeweilig
Nummer wird einfach hoch verwendeten Krypto Tool Kit automatisch
gezählt.
vergeben. Die Seriennummer muss immer
eindeutig sein und darf sich nie
wiederholen.
Signatur
sha1withRSAEncryption
Es wird der verwendete Hash- sowie der
Signaturalgorithmus angegeben, die zum
signieren des Zertifikats verwendet
werden.
Aussteller
c=DE, cn=FHTW-CA,
o=FHTW Berlin, ou=CA
Hier wird der Aussteller des Zertifikats
angegeben. Der Name des Ausstellers
wird in der X.500 Namensform angegeben.
Gültigkeitsdauer
NotBefore:
20030518143059z
NotAfter:
20130518145900z
In diesem Feld wird mit Hilfe eines Startund Enddatums der Gültigkeitsbereich
eines Zertifikats festgelegt.
Teilnehmer
c=DE, cn=Daniel Henze,
o=FHTW Berlin
Der Name des Objektes, welches durch
das Zertifikat identifiziert wird, ist ebenfalls
im X.500 Format angegeben.
Public Key
Informationen des
Teilnehmers
00:aa:33:ee…
Der öffentliche Schlüssel der zertifizierten
Identität wird in diesem Feld abgelegt. Mit
Hilfe eines Zertifikats kann so der
öffentliche Schlüssel der zertifizierten
Identität zugeordnet werden.
Kennung des
Ausstellers
Seriennummer und Name
oder Hashwert
In diesem Feld kann sich der Aussteller
des Zertifikats identifizieren. Es handelt
sich hierbei um ein optionales Feld.
Kennung des
Teilnehmers
Seriennummer und Name
oder Hashwert
In diesem Feld kann sich der Inhaber des
Zertifikats identifizieren. Es handelt sich
hierbei um ein optionales Feld.
Erweiterungen
Tab.3: Felder eines Schlüsselzertifikats
Es gibt vordefinierte
Standarderweiterungen. Darüber hinaus ist
es möglich zusätzliche Erweiterungen
selbst zu definieren. Alle Erweiterungen
sind mit einer Flagge als kritisch bzw. nicht
kritisch zu markieren. Eine kritische
Markierung hat zur Folge, dass die
Erweiterung geprüft und verarbeitet
werden muss. Kann die Erweiterung nicht
verarbeitet werden, ist das Zertifikat als
ungültig zu betrachten. Nicht kritische
Flaggen können generell ignoriert werden.
68
6.1.2
Schlüsselerweiterungen für Schlüsselzertifikate
„Diese Erweiterungsklasse umfasst Informationen zu den von den Zertifizierungsstellen
und Teilnehmern benutzten Zertifikaten. Sie enthält außerdem Einschränkungen zum
Einsatzzweck der Schlüssel.“ (Quelle: PKI-Security implementieren, RSA Press 2002)
Feldbezeichnung
Verwendungsbeispiel Zusätzliche Informationen
Kennzeichnung des
CA-Schlüssel
entweder Key Identifier
verwenden oder
Kombination aus :
Name der CA (c=DE,
cn=FHTW-CA,
o=FHTW Berlin, ou=CA)
und Seriennummer des
CA Zertifikats (1)
Nutzung nicht
vorgesehen, da Gültigkeit
des Schlüssels =
Gültigkeit des Zertifikats.
Benutzt eine CA mehrere Schlüssel,
beispielsweise in der
Schlüsselübergangsphase, kann der
entsprechende Schlüssel über einen Key
Identifier oder über eine Kombination von
der Seriennummer des CA Zertifikats und
des CA Namens identifiziert werden.
Kennzeichnung des
Nutzung nicht
Teilnehmer-Schlüssels vorgesehen, da Gültigkeit
des Schlüssels =
Gültigkeit des Zertifikats.
Wird ein öffentlicher Schlüssel in
mehreren Zertifikaten verwendet,
beispielsweise bei der Übergangsphase
von zwei Schlüsseln, kann der richtige
Schlüssel über den Key Identifier
herausgefunden werden.
Schlüsseleinsatzzweck KeyCertSign
CRLSign
NonRepudiation
DigitalSignature
KeyEncipherment
DataEncipherment
KeyAgreement
Eine kritische Markierung der einzelnen
Einsatzmöglichkeiten hat zur Folge, dass
die Schlüssel ausschließlich nur für
diesen Zweck benutzt werden dürfen.
Eine nicht kritische Markierung erlaubt
die beliebige Nutzung der Schlüssel für
alle Zwecke. Schlüssel sollten immer
einem bestimmten Einsatzzweck dienen.
erweiterter
Nutzung nicht
Über sogenannte Object Identifier (OIDs)
Schlüsseleinsatzzweck vorgesehen, da keine
können weitere Einsatzzwecke für
anderen Einsatzzwecke
Schlüssel selbst definiert werden.
als die bereits definierten
vorerst verwendet werden.
Gültigkeitsdauer des
privaten Schlüssels
Nutzung nicht
vorgesehen, da Gültigkeit
des Schlüssels =
Gültigkeit des Zertifikats
Um Signaturen auch später noch
verifizieren zu können, kann jedem
privaten Schlüssel ein anderer
Gültigkeitszeitraum gegeben werden als
dem zugehörigen Zertifikat.
CRL Verteilungspunkt
www.ca.fhtwberlin.de/sperrliste
Hier wird angegeben wo sich im Netz
eine Sperrliste befindet. Dies kann eine
URL, IP Adresse oder ein
Verzeichnisserver sein.
Freshest CRL
Nutzung nicht vorgesehen Hier wird immer die neueste CRL
angegeben, welche der Benutzer zur
Zertifikatsüberprüfung einsetzen muss.
Tab.4: Schlüsselerweiterungen für Schlüsselzertifikate
69
6.1.3
Richtlinienerweiterungen eines Schlüsselzertifikats
„Richtlinienerweiterungen ermöglichen die Angabe und Einschränkung von Richtlinien,
die benutzt werden, um die Nutzung von Zertifikaten zu definieren.“ (Quelle: PKISecurity implementieren, RSA Press 2002)
Feldbezeichnung
Verwendungsbeispiel Zusätzliche Informationen
Zertifikatsrichtlinien
Nutzung nicht
vorgesehen. Im PKI
Bereich findet das Feld
keine praktische
Verwendung.
Über das Feld Policy Identifier kann auf
die OID der verwendeten Richtlinien
einer Certificate Policy hingewiesen
werden. CA Betreiber können ihre
Richtlinien bei
Standardisierungsorganisationen
anmelden und eine OID erhalten. Für die
OID können wiederum Ergänzungen wie
der Klartext der Policy oder eine URL,
die auf die Policy zeigt, definiert werden.
Richtlinienzuordnungen Nutzung nicht
vorgesehen. Im PKI
Bereich findet das Feld
keine praktische
Verwendung.
Gilt nur in CA Zertifikaten. Richtlinien der
Certificate Policy der zertifizierten
Certification Authorities werden von der
ausstellenden CA anerkannt.
Tab.5: Richtlinienerweiterungen eines Schlüsselzertifikats
70
6.1.4
Teilnehmer und Ausstellerinformationen eines
Schlüsselzertifikats
Mit Hilfe dieser Erweiterungen ist es möglich, alternative Namensformen für
Zertifikatsteilnehmer auszustellen. So sind E-Mail Adressen, X.400 Adressen, Uniform
Resource Identifier (URL) und IP Adressen als alternative Namensformen möglich.
Feldbezeichnung
Verwendungsbeispiel
Alternativer
Teilnehmername
E-Mail Adresse des
Zertifikatsbesitzers wird
nicht im Schlüsselzertifikat
angegeben, da Spamern
keine validierten E-Mail
Adressen erhalten sollen.
Eine andere Form eines
alternativen Namens ist
bisher nicht vorgesehen.
Hier kann ein Name oder eine
Bezeichnung des Zertifikatsbesitzers in
einer anderen Syntax als X.500
angegeben werden.
Alternativer
Ausstellername
Fachhochschule für
Wirtschaft und Technik zu
Berlin oder
ca.fhtw-berlin.de
Hier kann ein Name oder eine
Bezeichnung des Zertifikatsbesitzers in
einer anderen Syntax als X.500
angegeben werden.
Verzeichnisattribute
des Inhabers
Nutzung nicht vorgesehen. Hier können X.500 Attribute aus dem
Verzeichnisdienst für den Teilnehmer
eingetragen werden, beispielsweise EMail Adressen, Internetadressen oder
Telefonnummern.
Tab.6: Teilnehmer und Ausstellerinformationen eines Schlüsselzertifikats
71
6.1.5
Zertifizierungspfad Erweiterungen
„CertificationPathConstraint-Erweiterungen werden bei der Verifizierung von
Zertifizierungspfaden benutzt. Diese Bedingungen gelten für die Zertifikatstypen, die
eine zertifizierte CA selbst ausstellt, oder für Typen, die in den nachfolgenden
Zertifikaten eines Zertifizierungspfades zulässig sind.“ (Quelle: PKI-Security
implementieren, RSA Press 2002)
Feldbezeichnung
Verwendungsbeispiel
Grundlegende
Einschränkungen
CA=true
(ermöglicht dem CA
Zertifikat andere Zertifikate
zu signieren)
Diese Erweiterung hat nur für CA
Zertifikate eine Bedeutung. Es kann
festgelegt werden, wie viele Stufen im
Zertifizierungspfad unterhalb der CA
vorkommen dürfen und ob ein CA
Zertifikat selbst andere Zertifikate
signieren darf. Es existieren zwei
Erweiterungsfelder – CA und
PathLenConstraint.
PathLenConstraint=0
(gibt den Wert an für die
maximale Anzahl von CAZertifikaten, die auf das
aktuelle Zertifikat im
Zertifizierungspfad folgen
dürfen – Wert 0 heißt,
dass nur
Teilnehmerzertifikate
ausgestellt werden dürfen)
Namenseinschränkungen Nutzung nicht vorgesehen. Diese Erweiterung wird nur für CA
Zertifikate benutzt. Es handelt sich um
Namenseinschränkungen, die von der
CA an die ausgestellten Zertifikate
weitergegeben werden.
Policy Einschränkungen
Nutzung nicht vorgesehen. Diese Erweiterung wird nur für CA
Zertifikate benutzt. Es existieren 2
Erweiterungsfelder –
requireExplicitPolicy (alle im
Zertifizierungspfad folgenden
Zertifikate müssen definierte
Richtlinienkennungen enthalten) und
inhibitPolicyMapping (die
Richtlinienkennung wird für
nachfolgende Zertifikate unterbunden).
Tab.7: Zertifizierungspfad Erweiterungen
Profile wie PKIX und ISIS definieren die Standardfelder und Erweiterungen eines
Zertifikats für sich selbst, inwieweit diese im Profil genutzt werden. Darüber hinaus
definieren die Profile weitere hier nicht erwähnte Erweiterungen.
Für den normalen Gebrauch einer Public Key Infrastructure reichen die vorgegebenen
Standardfelder sowie die Erweiterungen aus. Sollten weitere Funktionalitäten für
Zertifikate benötigt werden, können diese gemäß ISIS eingeführt werden. Es muss
vorher ein Antrag an TeleTrusT gestellt werden.
72
6.2 Sperrlisten
Zertifikate müssen bei bestimmten Vorfällen gesperrt werden. Sperrgründe sind
beispielsweise die Kompromittierung des geheimen Schlüssels oder dessen Verlust. Die
CA muss allen Zertifikatsbesitzern und sich selbst die Möglichkeit geben, jederzeit zu
überprüfen, ob ein Zertifikat gesperrt ist. Für die Realisierung und Veröffentlichung von
Sperrlisten gibt es verschiedene Lösungen.
Die Online Sperrlistenprüfung ist für die Zertifikatsbesitzer sehr komfortabel und
anwenderfreundlich. Um ein Zertifikat zu überprüfen, wird die Seriennummer des
entsprechenden Zertifikats an den Zertifikatsserver gesendet. Dieser überprüft sofort, ob
das entsprechende Zertifikat gesperrt ist. Anschließend wird eine signierte Antwort
generiert und an die Person übermittelt, welche die Sperrinformationen angefordert hat.
Das Verfahren ist sehr schnell, aber leider auch sehr aufwendig und kompliziert in der
Realisierung. Es macht zum Beispiel im Bankgeschäft und Aktienhandel Sinn.
Handelsabschlüsse werden in sekundenschnelle realisiert, deshalb muss sichergestellt
werden, dass die Zertifikate nicht gesperrt sind.
Für viele PKI Anwendungen reicht es jedoch aus, komplette Sperrlisten in größeren
Zeitabständen zu veröffentlichen. Der Nachteil hierbei ist, dass jedesmal die gesamte
Sperrliste vom Benutzer geladen werden muss, falls eine neue abrufbar ist, um ein
einziges Zertifikat überprüfen zu können.
Sind die Sperrlisten groß und das Veröffentlichungsintervall einer Sperrliste klein, ist es
besser Delta Sperrlisten zu verwenden. Bei Delta Sperrlisten lädt der Benutzer einmal
eine vollständige Sperrliste und muss danach lediglich die neuen Update Informationen
laden. Diese sind im Gegensatz zu einer kompletten Sperrliste klein. Delta Sperrlisten
sind bisher noch nicht sehr verbreitet. Jedoch werden sie von führenden PKI Betreibern
sehr befürwortet.
Eine weitere Möglichkeit Sperrlisten zu veröffentlichen sind Sperrbäume (Certificate
Revocation Tree – CRT). Hierbei werden vom Benutzer nur Teile der Sperrliste
geladen. Der Benutzer kann von diesem Teilstück die Signatur überprüfen und gelangt
so über eine Kette zu den gewünschten Sperrinformationen. Bei normalen CRL muss
immer die komplette Sperrliste geladen werden und erst dann kann die Signatur
überprüft werden.
Zwei Sperrlisteneinträge werden dabei immer zusammengefasst und gehashed sowie
signiert. Aus der grafischen Darstellung lässt sich dadurch eine sogenannte
Baumstruktur erkennen. In der unten folgenden Darstellung muss der Benutzer nicht die
komplette Sperrliste laden, sondern benötigt nur einen Ast der Sperrliste. Über den Weg
F2 – E1 – D2 – C3 – B6 – A12 lassen sich die benötigten Sperrinformationen schnell
runterladen.
73
Abb. 16: Aufbau und Funktionsweise eines Sperrbaumes, Quelle: [Schm1]
Sperrlisten sind ebenfalls in X.509 definiert. Die erste Version der Sperrlistendefinition
war nicht ausgereift, weshalb sie überarbeitet und eine zweite Version geschaffen
wurde. In der zweiten Version wurden Erweiterungen eingeführt. Erweiterungen
können sich auf die gesamte Sperrliste oder auf einzelne Einträge innerhalb der
Sperrliste beziehen.
Signatur (Singature)
Aussteller (Issuer)
Dieses Update (This Update)
Nächstes Update (Next Update)
Seriennummer des Benutzerzertifikats
(Subject Serial Number)
Datum der Sperrung
(Date of Revocation)
Grund der Sperrung (Reason Code)
Seriennummer des Benutzerzertifikats
(Subject Serial Number)
Datum der Sperrung
(Date of Revocation)
Grund der Sperrung (Reason Code)
CRL-Erweiterungen (CRL-Extensions)
Tab.8: Aufbau einer Sperrliste
74
6.2.1
Felder einer Sperrliste
Versionsnummer
V2
Um für kritische
Erweiterungen gerüstet zu
sein, wird Version zwei
verwendet.
Es existieren zwei Versionen von
Sperrlisten. Für kritische Erweiterungen
muss Version zwei benutzt werden.
Signatur
Es werden der verwendete Hash- sowie
der Signaturalgorithmus angegeben, die
zum signieren der Sperrliste verwendet
werden.
Aussteller
c=DE, cn=FHTW-CA,
o=FHTW Berlin, ou=CA
Hier wird der Aussteller des Zertifikats
angegeben. Der Name des Ausstellers
wird in der X.500 Namensform
angegeben.
Dieses Update
20030514235430z
Definiert das Ausgabedatum und die
Uhrzeit der aktuellen Sperrliste.
Nächstes Update
20030617200030z
Definiert das Ausgabedatum und die
Uhrzeit der nächsten Sperrliste.
Seriennummer des
Benutzerzertifikats
99
Hier steht die Seriennummer des
gesperrten Zertifikats.
Datum der Sperrung
20030515
Definiert das Sperrdatum für das Zertifikat.
Grund der Sperrung
Unbestimmt
(unspecified)
Mit der Angabe des Sperrgrundes lässt
sich die Ursache der Sperrung eines
Zertifikats identifizieren.
Schlüsselkompromittierung
(Key Compromise)
CA-Kompromittierung
(CA-Compromise)
Kompromittierung des
privaten Schlüssel
(Affiliation Change)
Zertifikat wird erneuert
(Superseded)
Zweck des Zertifikats
ändert sich
(Cessation of Operation)
Aussetzung des Zertifikats
(CertificateHold)
Löschen aus Sperrliste
(Remove from CRL)
CRL-Erweiterungen
Tab.9: Felder einer Sperrliste
6.2.2
75
Sperrlistenerweiterungen
Sperrlistenerweiterungen sind zusätzliche Felder, die sich auf einzelne Felder oder auf
die gesamte Sperrliste beziehen.
Feldbezeichnung
Authority Key Identifier
Es wird ein bestimmter Public Key der CA festgelegt, der zur
Verifizierung der Signatur einer Sperrliste verwendet werden
soll.
Issuer Alternative Name
Hier kann ein Name oder eine Bezeichnung des Herausgebers
einer CRL in einem anderen Format als X.500 angegeben
werden.
CRL Number
Es handelt sich hierbei um eine sequentiell zunehmende
Seriennummer, um dem Sperrlistenbenutzer die Möglichkeit
der Prüfung zu geben, ob alle vorangegangenen Sperrlisten
bereits gesehen wurden.
Hold Instruction Code
Dieses Feld ermöglicht die Definition von Anweisungen für die
Verarbeitung eines Zertifikats, dass mit dem Sperrgrund
„Certificate Hold“ gekennzeichnet wurde.
Invalidity Date
In dieser Erweiterung der CRL kann das Datum festgehalten
werden, an dem der geheime Schlüssel kompromittiert wurde.
CRL Scope
Der Umfang der verschiedenen Sperrlistentypen wird in dieser
Erweiterung definiert.
Einfache CRL
(enthalten Sperreintragsinformationen, die von einer einzelnen
Zertifizierungsstelle ausgestellt werden)
Indirekte CRL
(enthalten Sperreintragsinformationen für mehrere
Zertifizierungsstellen)
Delta CRL
(enthält Updates von bereits veröffentlichten Sperreintragsinformationen)
Indirekte Delta CRL
(enthält Updates von bereits veröffentlichten Sperreintragsinformationen mehrerer Zertifizierungsinstanzen)
Status Referral
Über diese Erweiterung bekommt der Benutzer Links zur
Verfügung gestellt, die zu weiteren Sperrstatusinformationen
führen. Wird die Erweiterung benutzt, enthalten die Sperrlisten
selbst keine Daten zum Sperrstatus.
Tab.10: Sperrlisten Erweiterungen Teil 1
76
Feldbezeichnung
CRL Stream Identifier
Diese Erweiterung ermöglicht es einer Zertifizierungsstelle
mehrere Sperreintragslisten gleichzeitig zu verwenden. CRL
Number und CRL Stream Identifier zusammen, ermöglichen die
Zuteilung einer eindeutigen Bezeichnung für jede Sperrliste von
jeder Zertifizierungstelle.
Ordered List
Durch diese Erweiterung ist es möglich, Zertifikate in einer
bestimmten Reihenfolge innerhalb einer Revoked Certificate List
anzugeben. Sortiert werden kann nach Seriennummer oder nach
Sperrdatum.
Delta Informationen
Diese Erweiterung gibt an, dass neben der normalen Sperrliste
auch eine Deltasperrliste vorhanden ist. Deltasperrlisten
bestehen aus einer großen Sperrliste und darauf folgenden
Updates. So muss nicht immer die komplette Sperrliste
heruntergeladen werden, sondern nur die neuen Informationen.
Issuing Distribution Point
In dieser Erweiterung wird der Verteilerpunkt definiert, der für die
Herausgabe der Sperrliste verantwortlich ist. Zudem werden die
Sperrstatusinformationen der CRL identifiziert.
Only Contains User Certs (Sperrstatusinformationen betreffen
nur Teilnehmerzertifikate)
Only Contains Authority Certs
(Sperrstatusinformationen betreffen nur CA Zertifikate)
Only Some Reasons
(Enthält die Reason Codes der in der Sperrliste definierten
Sperreinträge)
Indirect CRL
(Sperreinträge anderer CAs als der Herausgeber CA sind
möglich)
Only Contains Attribut Certs
(Beinhaltet nur Sperreinträge für Attributzertifikate)
Delta CRL Indicator
Mit dieser Erweiterung wird eine Sperrliste als eine
Deltasperrliste markiert.
Base Update
In dieser Erweiterung wird das Anfangsdatum für die
Sperrstatusinformationen der Delta CRL angegeben.
Tab.11: Sperrlisten Erweiterungen Teil 2
77
6.3 Attributzertifikate
Neben Schlüsselzertifikaten, welche Authentifizierungsinformationen für ein Objekt
beinhalten,
existieren
Attributzertifikate.
Diese
Zertifikate
sind
mit
Autorisierungsinformationen ausgestattet, um einem Objekt innerhalb eines Systems
mit gewissen Rechten auszustatten. Ein Attributzertifikat kann niemals allein existieren,
es benötigt immer ein dazugehöriges Schlüsselzertifikat. Das Objekt muss zunächst
authentifiziert werden, um anschließend autorisiert werden zu können. Ein
Schlüsselzertifikat kann dagegen auch allein existieren.
Wenn von Attributzertifikaten und Autorisierungsinformationen gesprochen wird, fällt
meist der Begriff der Privilege Management Infrastructure (PMI). In der X.509 Version
aus dem Jahr 1997 wurde ein Konzept für Attributzertifikate eingeführt, jedoch bedurfte
es eines stark verbesserten Entwurfs in der 2000er Version von X.509.
Mittlerweile ist die Thematik PMI genauso groß und komplex wie PKI und eine genaue
Betrachtung würde den Umfang dieser Arbeit zu groß werden lassen. Deshalb werden
in dieser Diplomarbeit die Attributzertifikate nur der Vollständigkeit halber kurz
erläutert. Als Beispiel für eine Anwendung für Attributzertifikate an der
Fachhochschule wird Single Sign-On verwendet. Anhand eines kleinen Beispiels wird
der Aufbau und die Funktionsweise der Attributzertifikate erklärt.
Ein Attributzertifikat bestätigt keine Informationen über die Identität des Besitzers. Die
Signatur eines Attributzertifikats sagt nichts über die Verbindung des Besitzers mit
seinem Schlüsselpaar aus. Mit Hilfe des Attributzertifikats werden lediglich die dem
Besitzer des Zertifikats zugeteilten Privilegien und Rechte bestätigt. Es existiert kein
öffentlicher Schlüssel im Attributzertifikat, sondern nur ein Hinweis auf den
Zertifikatsinhaber.
Seriennummer (Serial Number)
Signatur (Signature)
Aussteller (Issuer)
Gültigkeitsdauer (Validity)
Teilnehmer (Subject)
Attribute
Kennung des Ausstellers (Issuer Unique Identifier)
Erweiterungen (Extensions)
Tab.12: Aufbau eines Attributzertifikats
78
Die Felder eines Attributzertifikats
zusätzliche Informationen
Versionsnummer
V2
Version zwei ist die aktuelle Version
für Attributezertifikate.
Seriennummer
99
Die Seriennummer eines Zertifikats
wird in der Regel vom verwendeten
Krypto Tool Kit vergeben.
Seriennummern müssen immer
eindeutig sein.
Signatur
Es wird der verwendete Hash- sowie
der Signaturalgorithmus angegeben,
die zum Signieren des Zertifikats
verwendet werden.
Aussteller
c=DE, cn=FHTW-CA,
o=FHTW Berlin, ou=AA
Der Name der ausstellenden
Attribute Authority wird in diesem
Feld in der X.500 Namensform
angegeben.
Gültigkeitsdauer
NotBefore: 20030518143059z
NotAfter: 20130518145900z
Mit Hilfe eines Start- und Enddatums
wird der Gültigkeitsbereich eines
Zertifikats festgelegt.
Inhaber
c=DE, cn=Kristian Rabe,
o=FHTW Berlin
X.500 oder der vollqualifizierte Name
des Inhabers kann angegeben
werden. Alternativ ist die
Verwendung eines kryptografischen
Hash, um eine Authentifizierung auf
der Basis eines Vergleichs mit dem
passenden, vom Benutzer
bereitgestellten Hash zu
ermöglichen.
Attribute
wird im Laufe des Kapitels
extra erklärt.
Privileg-Attribute können selbst
durch die verwendeten Applikationen
oder das System definiert werden.
eindeutige Kennung
des Ausstellers
Attribut Authority FHTW Berlin In diesem Feld kann der Aussteller
des Zertifikats zusätzliche
Informationen über sich selbst
angeben.
Erweiterungen
Tab.13: Felder eines Attribut Zertifikats
Erweiterungen für Attributzertifikate.
Ermöglicht die Angabe weiterer
Felder im Zertifikat. Damit wird eine
Änderung der Struktur des Zertifikats
verhindert.
79
Attributzertifikate werden von einer Attribute Authority (AA) erstellt und von einer CA
signiert. Die AA arbeitet ähnlich einer Registration Authority. Anstelle von
Authentifizierungsinformationen
werden
von
einer
AA
nur
Autorisierungsinformationen erstellt und vergeben.
Diese Informationen können in verschiedenen Rollen abgelegt und einem
Zertifikatsbenutzer
zugeordnet
werden.
So
erhält
beispielsweise
jeder
Fachhochschulangehörige über Single Sign-On nur Zugang zu seinem Arbeitsplatz oder
speziellen Laborrechnern.
Natürlich können auch Attributzertifikate gesperrt werden. Dabei gelten die gleichen
Mechanismen und Prozeduren wie beim Sperren von Schlüsselzertifikaten. In einzelnen
Bereichen kann sogar auf eine Sperrliste für Attributzertifikate verzichtet werden, da die
Attributzertifikate oft sehr kurzlebig sind.
Abb.17: Zusammenspiel von Schlüssel- und Attributzertifikat, Quelle: [NaDuJo]
Ein konzeptionelles Beispiel für Attributzertifikate an der FHTW ist im Folgenden für
Single Sign-On beschrieben. Eine Kombination von verschiedenen Rollen ermöglicht
eine Autorisierung für verschiedene Computer.
Drei Rollen ergeben dabei eine komplette Attributinformation. Diese besteht aus einer
Permission, einer ID und einem Objekt. Die Objekte bestehen aus allen Computern
bzw. Laboren, die am Single Sign-On System angeschlossen sind. Dabei kann für jedes
Labor eine andere Permission zugeteilt werden. Die ID bleibt immer gleich, da sie
gleichzeitig als Login benutzt werden kann. Permissionrechte reichen von „Kein
Zugang“ bis „Administrator“, wobei Administratorrechte nur in Ausnahmefällen erteilt
werden sollten.
80
Laboringenieure und Systemadministratoren sollten aus Sicherheitsgründen nicht am
Single Sign-On teilnehmen, da sie oft mit weitreichenden Rechten innerhalb eines
Systems ausgestattet sind und eine Kompromittierung des Attributzertifikats ein großes
Sicherheitsloch darstellt.
Um die Anwendung der Attributzertifikate noch einfacher zu gestalten, kann der
Zugang zu allen Laboren defaultmäßig gestattet werden. Für fachspezifische
Speziallabore kann der Zugang defaultmäßig beschränkt sein und nach Vorlage einer
Zutrittsberechtigung kann diese im Zertifikat umgestellt werden.
Abb.18: Konzept für Anwendung von Attributzertifikaten bei Single Sign-On
Ein Zertifikatsbesitzer kann viele dieser Attribute gleichzeitig besitzen.
Attributzertifikate sind oft sehr kurzlebig, da es häufiger passiert, dass sich
Autorisierungsinformationen ändern oder neue dazukommen.
Mehr Informationen zu den Themen Zertifikate und Sperrlisten sind in folgenden
Büchern zu finden: [NaDuJo], [Ber], [Hoc],
Risiken und Probleme beim Einsatz von PKI
81
7. Risiken und Probleme beim Einsatz von PKI
Der Level der Sicherheit richtet sich immer nach dem schwächsten Punkt innerhalb
eines funktionierenden Systems. Existiert eine Sicherheitslücke, nutzen Firewall,
Intrusion Detection Systeme und verschlüsselte Kommunikationswege nur wenig.
Eine Public Key Infrastructure allein trägt nicht zur Verbesserung innerhalb eines
Systems bei. Nur im Zusammenspiel mit anderen Sicherheitstechnologien wie Secure
Socket Layer (SSL), IPsec oder Virtual Private Network (VPN) werden die Stärken
einer Public Key Infrastructure sichtbar.
Bei der Implementierung einer PKI muss darauf geachtet werden, dass keine
Sicherheitslöcher entstehen. Alle eingesetzten kryptografischen Algorithmen müssen
sicher und vor allem fehlerfrei implementiert werden. Die Schlüsselgenerierung muss
zufällig geschehen, pseudozufällige Schlüsselgenerierung sollte vermieden werden. Alle
Prozesse sollten auf Sicherheit optimiert werden und nicht auf die Einsparung von
Kosten oder um mögliche finanziellen Einnahmen zu sichern
Eine Public Key Infrastructure benutzt viele verschiedene Kommunikationswege und
Partner. Diese Kommunikationswege sollten verschlüsselt sein, um das gewünschte
Sicherheitsniveau nicht zu verringern. Benutzer einer Public Key Infrastructure dürfen
im Betrieb nicht durch undurchsichtige oder unlogische Prozesse verwirrt werden.
Einfache Prozessabläufe erleichtern den Betreibern und den Zertifikatsbesitzern den
Umgang mit der Technologie und fördern eine bessere Akzeptanz der Technik. Durch
transparent gestaltete Registrierungs- und Zertifizierungsprozesse, sowie die Benutzung
von sicheren Algorithmen, kann die Certification Authority das Vertrauen bei Ihren
Benutzern steigern.
Ein einziger Implementierungsfehler oder eine Sicherheitslücke können das Ende der
PKI bedeuten. Eine Zertifizierungsinstanz, die kein Vertrauen bei potentiellen
Benutzern wecken kann, ist nutzlos. Deswegen sollten vor Inbetriebnahme einer Public
Key Infrastructure umfangreiche Tests in allen Bereichen erfolgen.
Die Sammlung von personenbezogenen Daten beim Betrieb einer Public Key
Infrastructure ist ebenfalls bedenklich. Beim Registrierungsprozess sollten nur Daten
erfasst werden, die unmittelbar in das Zertifikat hineinkommen. Jegliche andere
Erfassung von zusätzlichen Daten sollte vermieden werden.
Gelingt es einer nicht autorisierten Person Zugang zu den gesammelten Daten zu
bekommen, ist diese im Besitz von genau überprüften personenbezogenen
Informationen. Auch besteht die Gefahr, dass der Zertifikatsbesitzer zu einer gläsernen
Person für bestimmte Mitarbeiter der Certification Authority wird. Dies trägt nicht
unbedingt dazu bei, der CA größeres Vertrauen entgegenzubringen.
Risiken und Probleme beim Einsatz von PKI
82
Aus diesem Grund sollten nur die absolut benötigten Daten erfasst und gespeichert
werden. Daten, die für bestimmte Prüfroutinen benötigt werden, sollten nach der
Überprüfung wieder vollständig gelöscht werden. Zudem sollte der Zertifikatsbesitzer
genau darüber informiert werden, welche Daten von der Certification Authority
gespeichert werden und zu welchem Zweck. Transparenz schafft Vertrauen.
Eine Gefahr bei der Benutzung von PKI Infrastrukturen ist die Speicherung der
geheimen Schlüssel. Diese sollten niemals einfach nur auf dem eigenen Computer
abgespeichert werden. Gerade technisch unversierte Benutzer haben oft gravierende
Sicherheitslücken oder trojanische Pferde in ihren Systemen.
Verbunden mit dem Internet kann der private Schlüssel so beispielsweise von fremden
Personen missbraucht werden, um Dokumente oder Verträge zu signieren, die so nie
vom Zertifikatsbesitzer signiert werden sollten.
In einigen Staaten Amerikas ist der Zertifikatsbesitzer sogar rechtlich für alle
Anwendungen seines eigenen geheimen Schlüssels verantwortlich, egal ob er den
Schlüssel benutzt hat oder sein Schlüssel unbemerkt kompromittiert wurde.
Das schlimmste, was einer Certification Authority passieren kann, ist die
Kompromittierung der eigenen geheimen Schlüssel. Passiert dies, müssen alle
ausgestellten Zertifikate gesperrt werden und jeder Teilnehmer muss sich neu
zertifizieren lassen.
Dieser Vorfall bedeutet für jede kommerzielle Certification Authority das Aus. Der
Vertrauensverlust bei den Benutzern ist kaum zurückzugewinnen. Es muss zudem
verhindert werden, dass es eine unbekannte Person schafft, Schlüssel für Zertifikate
auszutauschen oder sogar ein eigenes Root Zertifikat in die CA zu schleusen.
Der richtige Umgang mit Zertifikaten muss erlernt werden. Viele Zertifikatsbenutzer
werden am Anfang nicht mal wissen, was sie genau beantragt haben und was sie mit
den Zertifikaten anfangen sollen.
Selbst wenn sie später wissen, wozu die ausgestellten Zertifikate benutzt werden,
können am Anfang die wenigsten Personen genau sagen, wie die Zertifikate richtig
angewandt werden. Deshalb ist es wichtig, für potentielle Benutzer der Zertifikate
genaue Ablaufpläne für jede Anwendung zu erstellen.
Diese Schritt für Schritt Anleitungen verringern den Supportaufwand für die Mitarbeiter
der Certification Authority und bringen den Benutzern eine einfache Handhabung der
Applikation.
Mehr Informationen zu den Themen Risiken und Gefahren bei PKI sind in folgenden
Büchern zu finden: [NaDuJo], [4], [5], [13]
Certification Practice Statement
83
8. Certification Practice Statement
Beim Aufbau einer Public Key Infrastructure müssen viele Informationen, Prozeduren
und Prozesse dokumentiert werden. Damit Zertifikatsbesitzer einschätzen können, wie
die Zertifikate und Zertifizierungsabläufe aussehen, gibt es die Certificate Policy.
In einem Certification Practice Statement hingegen stehen PKI interne
Detailinformationen, wie der Aufbau und alle Prozesse, welche nicht für
Zertifikatsbesitzer zugänglich sein sollten. Certificate Policy sind Bestandteile jedes
Certification Practice Statement.
Es ist jedoch möglich, das Certification Practice Statement von einer unabhängigen
Stelle wie beispielsweise dem TÜV überprüfen zu lassen und damit jedem möglichen
Benutzer zu zeigen, dass das Certification Practice Statement einwandfrei ist.
Im Request for Comment (RFC) 25271 wird beschrieben wie der Aufbau dieser beiden
Dokumente aussehen kann. Der RFC 2527 gehört zum PKIX Standard, schreibt aber
nicht vor, was in den Dokumenten enthalten sein muss, sondern gibt nur Empfehlungen
für mögliche Inhalte.
Mit der Certificate Policy zeigt der Betreiber einer Public Key Infrastructure Richtlinien
für die ausgestellten Zertifikate auf. Existieren verschiedene Zertifikate, sollte für jedes
eine eigene Policy aufgestellt werden.
Mit der Einhaltung der Richtlinien wird dem Zertifikatsbesitzer gezeigt, wie viel
Vertrauen jeder in die ausgestellten Zertifikate bringen kann. Gleichzeitig kann der
Zertifikatsbesitzer mehrere Policies auch anderer Anbieter miteinander vergleichen.
Bestandteile einer Policy und eines CPS sind die Einführung, allgemeine Maßnahmen,
Identifizierung und Authentifizierung, betriebliche Maßnahmen, allgemeine und
technische Sicherheitsmaßnahmen, Formate der Zertifikate und Sperrlisten sowie die
Verwaltung des Dokuments.
Inhaltlich werden rechtliche Fragen wie Urheberrecht, Haftung, Garantien und
vertragliche Pflichten geklärt. Außerdem werden die Registrierungsprozesse für den
Antragsteller durchleuchtet. Zu den betrieblichen Maßnahmen zählen Sperrungen,
Zertifizierung, Schlüsselwechsel usw..
Sicherheitsaspekte und Reaktionen in Krisenfällen sind ebenfalls erläutert. Zudem
werden die Zuständigkeit der Mitarbeiter sowie Brandschutz- und Zugangsschutzfragen
geklärt. Weiterhin werden IT-Security Fragen, wie die verschlüsselte Kommunikation
und die Handhabung der Log-Files erklärt.
Die Certificate Policy und das Certification Practice Statement sind beide mit einem
Gültigkeitszeitraum versehen. Wird dieses Datum nicht erneuert, verlieren die
Dokumente ihre Gültigkeit.
1
Quelle: rfc2527.htm (www.ietf.org/rfc)
84
Informationen über ein ausformuliertes Certificate Practice Statement sind schwer zu
finden, da das CPS einer PKI oft detaillierte interne Informationen beinhaltet. Somit ist
das CPS oft nur Mitarbeitern der PKI zugänglich. Damit Zertifikatsbesitzer dem CPS
vertrauen können, lassen PKI Betreiber das Certificate Practice Statement auf
Rechtmäßigkeit von einer unabhängigen Institution, beispielsweise dem TÜV-IT
bestätigen. Der Entwurf eines Certificate Practice Statements basiert auf dem in dieser
Arbeit erstellten Konzepts. Ein vollständiges CPS würde den Umfang der Arbeit
übersteigen, weshalb dieser Entwurf in verkürzter Form dargestellt wird.
Mitarbeiter und Räume der CA/RA
Mitarbeiter für die CA/RA sollten speziell geschult werden und ein Verständnis für
Sicherheit in der Informationstechnologie mitbringen. Es muss darauf geachtet werden,
dass genügend Mitarbeiter zur Verfügung stehen, um eine reibungslose Arbeitsweise
der CA/RA zu garantieren.
Ausgeschiedene Mitarbeiter, dürfen keine Kopien von Schlüsseln oder andere interne
Informationen mitnehmen oder anderen Personen zugänglich machen. Studentische
Hilfsstellen sollten nicht für sicherheitskritische Aufgaben, wie beispielsweise die CA
Schlüsselgenerierung eingeplant werden. Zudem sollten für sicherheitskritische
Aufgaben ein Vier-Augen-Prinzip benutzt werden, das heißt die Schlüsselgenerierung
für CA Schlüssel muss von zwei Mitarbeitern durchgeführt werden. Für die CA/RA
sollten zwei verschiedene Räume benutzt werden. Der RA Raum ist mit einer Theke
ausgestattet, an der sich die Antragsteller zertifizieren lassen können. Zudem ist die
Theke als Anlaufpunkt für Fragen und Probleme mit Zertifikaten zu sehen. Im RA
Raum befinden sich weiterhin alle RA Client Computer, an denen sich die Antragsteller
der verschiedenen Level zertifizieren lassen können.
Der CA Raum sollte ein separater Raum sein, der verschließbar und nur für CA
Mitarbeiter zugänglich ist. In diesem Raum sollte ein verschließbarer Schrank oder ein
Safe stehen, in dem sich der CA Rechner befindet. Es muss sichergestellt werden, dass
es nur sehr schwer möglich ist, den CA Rechner zu kompromittieren. Die Schlüssel für
den CA Raum und den Safe oder Schrank sollten bei einer speziellen Person
ausgeliehen werden können. Bei dieser Person wird die Schlüsselausleihe protokolliert.
Eine geeignete Person hierfür ist beispielsweise der Datenschutzbeauftragte. So kann
jederzeit nachgewiesen werden wer wann Zutritt zum CA Raum hatte.
Geräte
Für den CA Rechner lohnt die Anschaffung eines Notebooks, da dieser leicht in einen
Schrank oder Safe untergebracht werden kann. Zudem darf der CA Rechner niemals an
ein Netzwerk angeschlossen werden. Alle Geräte, die zur PKI gehören, dürfen nicht
unbeaufsichtigt im eingeschalteten Zustand gelassen werden. Details anderer
Komponenten der PKI sind auch in Kapitel 4 und 5 ersichtlich.
Telefon
Für die im Medium- und High Level angebotene telefonische Sperrung muss ein
Telefon angeschlossen werden. Um eine hohe Erreichbarkeit eines Mitarbeiters am
Telefon zu gewährleisten, sollte dieses an der RA Theke platziert sein.
85
Technische Abläufe
Die Technischen Abläufe beziehen sich auf die Zertifizierungs- und Sperrregeln. Zudem
muss genau definiert werden, wie sich die CA bei Missbrauch und falscher Benutzung
der Zertifikate gegenüber dem Zertifikatsbesitzer verhält. Dies wurde bereits
ausführlich im Kapitel 4 beschrieben.
Technik
Die Schlüsselgenerierung wird nicht dem Benutzer überlassen, da der Supportaufwand
von der Fachhochschule nicht gewährleistet und finanziert werden kann. Es ist aber
sichergestellt, dass nur der Zertifikatsbesitzer in den Besitz des jeweiligen privaten
Schlüssels kommen kann. Es werden keine Kopien der Schlüsselpaaren von den CA
Mitarbeitern angefertigt. Nicht verwendete Smartcards werden ebenfalls im Safe des
CA Raumes abgelegt. CDs mit bereits generierten Schlüsselpaaren dürfen nicht
unbeaufsichtigt sein und sollten hinter der Theke im RA Raum im Blickfeld eines RA
Mitarbeiters liegen. Neben Schlüsselpaaren beinhalten die CDs signierte Dokumente
und freie Software, zum Beispiel verschiedene Browser oder E-Mail Programme.
Zertifikate
Die verschiedenen Zertifikatstypen, deren Laufzeit und die verschiedenen
Verwendungszwecke sind bereits in Kapitel 4 und 6 ausführlich beschrieben worden. Es
werden sowohl Schlüssel- als auch Attributzertifikate angeboten. Die Laufzeit der
Zertifikate ist auf 6 Monate oder bis zum Ausscheiden aus der Fachhochschule
begrenzt. Verwendungszwecke sind das Signieren und Authentifizieren von Objekten,
Single Sign-On mit Hilfe von Attributzertifikaten sowie verschlüsselter E-Mail
Verkehr.
Cross-Zertifizierung
Eine Cross-Zertifizierung mit anderen Universitäten, beispielsweise mit der HU Berlin
oder der DFN-PCA werden angestrebt und sollten bei der Umsetzung des Konzepts
beachtet werden. Sind Zertifizierungsregeln, beispielsweise ein persönliches Erscheinen
des Antragstellers bei der RA vorhanden, kann eine vollständige
Zertifikatsbeglaubigung gestattet werden.
Rechtsfragen und Datenschutz
Für die Formulierung dieses Teils des Certificate Practice Statements sollten die
Rechtsabteilung der Fachhochschule und der Datenschutzbeauftragte hinzugezogen
werden. Es sind Fragen der Haftung und des Haftungsauschlusses sowie des
allgemeinen Datenschutzes zu klären und rechtlich einwandfrei zu formulieren.
Mehr Informationen zu den Themen CPS und Policy sind in folgenden Büchern zu
finden: [NaDuJo], [Bar], [14].
Ausblick
9.
86
Ausblick
Das Konzept für eine Public Key Infrastructure an der FHTW wurde in den vorherigen
Kapiteln entworfen, erklärt und erläutert. Die Arbeit soll zeigen, wie komplex eine
Public Key Infrastructure ist, wie die einzelnen Bausteine miteinander funktionieren
und welche Prozesse nötig sind, um einen einwandfreien Betrieb zu garantieren.
Weiterhin soll diese Arbeit aufzeigen, wie PKI an einer Fachhochschule eingesetzt
werden kann und auf welche Art und Weise die Fachhochschule von der neuen
Technologie profitieren kann.
Es wurden Anwendungsbeispiele einer PKI für die Fachhochschule gezeigt und alle
Prozesse für einen Regelbetrieb erläutert. Während der Konzeption wurde ersichtlich,
dass Aufgrund der Begrenzung der Thematik der Diplomarbeit, ein paar Teilgebiete
nicht ausführlich behandelt werden konnten. Für diese Teilgebiete bietet sich die
Möglichkeit, diese in weiteren Arbeiten genauer zu untersuchen und zu beschreiben.
Single Sign-On als Konzept für eine Realisierung an der FHTW wäre ein Bereich der
genauer untersucht werden kann. Auch Attributzertifikate und Privileg Management
Structure (PMI) sind Elemente, die in diesem Konzept nicht bis ins Detail untersucht
und konzeptioniert werden konnten.
Das Anfertigen und Ausformulieren einer Certification Policy und eines Certificate
Practice Statements, muss bei einer Umsetzung des Konzeptes und der Schaffung einer
Public Key Infrastruktur geschehen. All dies sind Schritte, die bis zum Regelbetrieb
einer Public Key Infrastructure von anderen Studenten, in weiteren Diplom- oder
Semesterarbeiten, erörtert werden können.
Kommt es zu einer Umsetzung des Konzeptes wird für jedes Level ein Probebetrieb
empfohlen, um die richtige Implementierung der Algorithmen sowie der gesamten
Hard- und Software zu testen. Dabei sollten Milestones definiert werden, damit das
Projekt nicht im Probebetrieb stecken bleibt und eingestellt wird.
Wird nach dem Probebetrieb ein Regelbetrieb aufgenommen, sollte eine
Crosszertifizierung mit anderen Universitäten und Fachhochschulen, sowie der
Deutsches Forschungsnetz-Policy Certification Authority (DFN-PCA) erreicht werden.
87
Eidesstattliche Erklärung
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig angefertigt habe. Ich
habe mich keiner fremden Hilfe bedient und keine anderen, als die angegebenen
Quellen und Hilfsmittel benutzt. Alle Stellen, die wörtlich oder sinngemäß
veröffentlichten oder nicht veröffentlichten Schriften und anderen Quellen entnommen
sind, habe ich als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher
Form noch keiner Prüfungsbehörde vorgelegen.
Ort, Datum
_____________________________
(Vorname Nachname)
88
Anhang
Literaturverzeichnis
Bücher
[AdaLlo]
Carlisle Adams, Steve Lloyd: Understanding PKI. Addison-Wesley
Professional, 2002
[Aus]
Tom Austin: PKI. A Wiley Tech Brief. John Wiley & Sons, 2000
[Bar]
Scott Barman: Writing Information Security Polices. Sams, 2001
[Ber]
Andreas Bertsch: Digitale Signaturen (Xpert.press). Springer
Verlag, 2001
[BitBri]
Frank Bitzer, Klaus M. Brisch: Digitale Signatur. Grundlagen, Funktion
und Einsatz. Springer Verlag,1999
[BucKöh]
Jörg Buckbesch, Rolf-Dieter Köhler: VPN. Virtuelle Private Netze.
Sichere Unternehmenskommunikation in IP-Netzen. FOSSIL-Verlag
GmbH, 2001
[FerSch]
Niels Ferguson, Bruce Schneier: Practical Cryptography. John Wiley &
Sons, 2003
[Gai]
Gail L. Grant, Commercenet PKI Task Force: Understanding Digital
Signatures: Establishing Trust Over the Internet and Other Networks
(CommerceNet). McGraw-Hill Professional, 1997
[Hoc]
Stephan Hochmann: Elektronische Signatur. BoD GmbH, 2001
[HoPoLo]
Russ Housley, Tim Polk, Carol A. Long: Planning for PKI. Best
Practices Guide for Deploying Public Key Infrastructure. John Wiley &
Sons Inc, 2001
[KlüLas]
Dieter Klünter, Jochen Laser: LDAP verstehen, OpenLDAP einsetzen.
Grundlagen, Praxiseinsatz, Single-sign-on- Systeme. Dpunkt Verlag,
2003
[NaDuJo]
Andrew Nash, William Duane, Celia Joseph: PKI, e-security
implementieren. MITP, 2001
[Rai]
Kapil Raina: PKI Security Solutions for the Enterprise. John Wiley &
Sons, 2003
[Schm1]
Klaus Schmeh: Kryptografie und Public- Key Infrastrukturen im Internet.
Dpunkt Verlag, 2001
[Schm2]
Klaus Schmeh: Safer Net. Kryptografie im Internet und Intranet. dpunktVerlag, 1998
89
Anhang
[Schn]
Bruce Schneier: Applied Cryptography. Protocols, Algorithms, and
Source Code in C. John Wiley & Sons Inc, 1995
[VieMesCha] Jon Viega, Matt Messier, Pravir Chandra: Network Security with
OpenSSL. Cryptography for Secure Communications. O'Reilly &
Associates, 2002
Anhang
90
Literatur aus dem Internet
Sämtliche Dokumente finden sich zusätzlich auf der CD in dem Ordner
Literatur_Diplom mit der jeweiligen Nummer übersichtlich geordnet, falls die Quellen
aus dem Internet nicht mehr erreichbar sind.
[1]
HU Berlin: UVSEC Project der HU Berlin,
http://www.hu-berlin.de/rz/projekte/uvsec/, seit 1999
[2]
Markus P. Beckhaus: PKI – Public Key Infrastructures. Electronic Business und
Web Site Engineering Vorlesung. http://wi.unigiessen.de/gi/dl/down/open/Schwickert/a0c8361702a94b64321a6d625639aa44d
e3e7c67af6f1161d7aefc856a8154f2ade560db5192b700b750b6b6c2f317c3/WI_
VL_eBusiness_SS2003_Beckhaus_PKI.pdf, 2003
[3]
Burkhard Messer: Public Key Infrastructure. http://web.f4.fhtwberlin.de/messer/LV/PKI-SS03/index.html, Vorlesung 2003
[4]
Markus Ruppert, Markus Tak: Sicherheitsmanagement durch generische,
objektorientiere Modellierung einer TrustCenter Software.
http://www.informatik.tu-darmstadt.de/ftp/pub/TI/TR/TI-0103.sicherheitsmanagementfinal.pdf
[5]
Carl Ellison and Bruce Schneier: Ten Risks of PKI: What You’re not Being told
about Public Key Infrastructure.
http://secinf.net/authentication_and_encryption/Ten_Risks_of_PKI_What_Your
e_Not_Being_Told_About_Public_Key_Infrastructure.html, Computer Security
Journal 2000
[6]
Bundesamt für Sicherheit in der Informationstechnik:
Zertifizierungsinfrastruktur für die PKI-1-Verwaltung.
http://www.bsi.de/aufgaben/projekte/sphinx/verwpki/index.htm, 2002
[7]
TrustCenter AG: Sichere Internet-Kommunikation mit Zertifikaten.
http://www.trustcenter.de/set_de.htm, 2001
[8]
Thomas Weber: Systeme und ihr Umfeld - Single Sign-on.
http://www.trivadis.ch/pressemitteilungen/D/130801_single_sign_on.pdf,
SecuMedia-Verlags-GmbH, 2001
[9]
Dr. Sebastian Wirth: Zugangsschutz durch Single-Sign-On? Vorteile und Risiken
einer zentralen Verwaltung von Zugriffsrechten.
http://fhh.hamburg.de/stadt/Aktuell/weitereeinrichtungen/datenschutzbeauftragter/informationsmaterial/informationstechnik
/single-sign-on-pdf,property=source.pdf, 2002
Anhang
91
[10]
Guido Schnider: Digitale Signaturen und Public Key Infrastrukturen (PKI).
http://www.ifi.unizh.ch/ikm/Vorlesungen/Sem_Sich01/Schnider.pdf, 2001
[11]
TU-Berlin: Rahmenkonzept für die Datensicherheit in der Informationstechnik
an der Technischen Universität Berlin. http://www.datensicherheit.tuberlin.de/konzepte/rahmen/, 2002
[12]
Denkbilder: Case Study: PKI bei CREDIT SUISSE FINANCIAL SERVCES.
http://www.denkbilder.ch/docs/PKI_CS.pdf, 2001
[13]
Ilan Shacham: PKI - Theorie und Praxis. Information Security Bulletin.
http://www.chipublishing.com/isbd/backissues/ISBD_2000/ISBD0204/ISBD0204IS.pdf, 2000
[14]
Ingmar Camphausen: Entwurf eines Konzepts für eineZertifizierungsstelle für
dieFreie Universität Berlin. http://userpage.fu-berlin.de/~ingmar/diplomarb/,
TU-Berlin 1999
[15]
Ingmar Camphausen, Stefan Kelm, Britta Liedtke, Lars Weber:
Aufbau und Betrieb einer Zertifizierungsinstanz. http://www.dfncert.de/dfn/berichte/db089/, DFN-PCA 2000
[16]
Businesscase: Wie wird PKI “verkauft”? Über das Abwägen von Chancen und
Risiken der PKI. http://www.fgsec.ch/events/ft2001.03.28/doc/2_PKITagungFGSec_Business_Case_v1.0.pdf, Fachtagung der Fachgruppe Security
FGSec, 2001
[17]
ISIS-MTT Specification: Common ISIS-MTT Specification for PKI
Applications.
http://www.teletrust.de/glossar.asp?id=61040&Sprache=E_&HomePG=0,
TeleTrusT 2001
[18]
Bundesregierung: Verordnung zur elektronischen Signatur Signaturverordnung
– SigV. http://www.bsi.de/esig/basics/legalbas/sigv2001.pdf, 2001
[19]
Secorvo GmbH: Empfehlung „Geeignete Kryptoalgorithmen“
gemäß §17 (1) SigG, www.secorvo.de 2002
Anhang
92
Vollständige Webseiten für Belege
Alle hier gelisteten Dokumente finden sich im Ordner Quellen_Diplom
c't 16-2003, S_ 32 Online-Auktion.htm
c't 19-99, S_ 68 Datenschutz und -sicherheit.htm
Infinigate ___ Utimaco SafeGuard Easy.htm
IT-SecCity - RSA Security Alternative zu Service Providern von Drittanbietern für
SSL-Zertifikate.htm
rfc2527.htm
RSA Laboratories Bulletins Bulletin #13 A Cost-Based Security Analysis of
Symmetric and Asymmetric Key Lengths.htm
SecCommerce Fachwissen Technologie Smartcards Physikalische Sicherheit.htm
Zunehmender Bedarf an Single Sign-On-Lösungen.htm
Anhang
Anhang
Beispiel einer Sperrliste im ASN1. Format der DFN-PCA (www.dfn-pca.de)
Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: /C=DE/O=Deutsches Forschungsnetz/OU=DFN-CERT GmbH/OU=DFN-PCA/CN=DFN
Toplevel Certification Authority/[email protected]
Last Update: Sep 26 14:21:05 2003 GMT
Next Update: Oct 31 14:21:05 2003 GMT
Revoked Certificates:
Serial Number: 1B05B3
Revocation Date: Dec 20 18:05:39 2001 GMT
Serial Number: 1B0AE1
Revocation Date: Mar 25 12:57:33 2002 GMT
Signature Algorithm: md5WithRSAEncryption
15:25:db:b0:54:39:aa:37:56:9e:17:c1:89:53:b1:a6:c6:0d:
7a:b8:63:28:e7:9f:c8:f9:4d:b6:8f:5c:6f:19:a4:a9:e5:5f:
4a:ce:31:ea:80:cd:81:f1:a6:18:f0:36:a4:92:18:fc:f8:3c:
42:bb:48:db:51:ad:3e:84:51:de:b4:d6:f3:5e:75:45:d4:68:
63:65:a5:1f:c7:56:ce:22:41:20:f1:66:a5:e7:f8:c9:a2:e9:
ad:92:33:54:b1:73:8c:eb:ff:73:31:f6:b2:d5:ed:fe:09:42:
47:55:fb:50:b7:3c:b6:a2:3c:0a:8a:cb:27:9b:95:f2:2c:23:
3e:1a:19:32:23:0c:83:e6:4b:da:df:b1:e2:49:39:49:67:46:
0e:40:b9:5b:dc:36:28:ed:4f:5f:66:80:08:ba:ad:f9:6e:bc:
2c:75:04:06:73:da:de:00:49:17:6e:4f:9b:a7:d1:78:e7:73:
1e:75:a7:f9:6a:34:ed:e7:7b:d3:66:1f:64:7d:23:20:b2:b6:
9d:1f:0c:6b:48:4e:a9:99:23:40:54:d5:e9:f6:c3:64:04:44:
f1:dc:b5:d5:27:28:88:75:12:65:af:57:31:94:63:10:16:96:
23:54:49:57:0a:57:c1:12:91:d4:2d:da:c7:2d:fc:bb:0b:dd:
e7:d2:d3:65
-----BEGIN X509 CRL----MIICIjCCAQowDQYJKoZIhvcNAQEEBQAwgawxCzAJBgNVBAYTAkRFMSEwHwYDVQQK
ExhEZXV0c2NoZXMgRm9yc2NodW5nc25ldHoxFjAUBgNVBAsTDURGTi1DRVJUIEdt
YkgxEDAOBgNVBAsTB0RGTi1QQ0ExLTArBgNVBAMTJERGTiBUb3BsZXZlbCBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSY2VydGlmeUBwY2Eu
ZGZuLmRlFw0wMzA5MjYxNDIxMDVaFw0wMzEwMzExNDIxMDVaMCwwFAIDGwWzFw0w
MTEyMjAxODA1MzlaMBQCAxsK4RcNMDIwMzI1MTI1NzMzWjANBgkqhkiG9w0BAQQF
AAOCAQEAFSXbsFQ5qjdWnhfBiVOxpsYNerhjKOefyPlNto9cbxmkqeVfSs4x6oDN
gfGmGPA2pJIY/Pg8QrtI21GtPoRR3rTW8151RdRoY2WlH8dWziJBIPFmpef4yaLp
rZIzVLFzjOv/czH2stXt/glCR1X7ULc8tqI8CorLJ5uV8iwjPhoZMiMMg+ZL2t+x
4kk5SWdGDkC5W9w2KO1PX2aACLqt+W68LHUEBnPa3gBJF25Pm6fReOdzHnWn+Wo0
7ed702YfZH0jILK2nR8Ma0hOqZkjQFTV6fbDZARE8dy11ScoiHUSZa9XMZRjEBaW
I1RJVwpXwRKR1C3axy38uwvd59LTZQ==
-----END X509 CRL-----
93
Anhang
94
Beispiel eines Root Zertifikats im ASN1. Format der DFN-PCA (www.dfn-pca.de)
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1429501 (0x15cffd)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=DE, O=Deutsches Forschungsnetz, OU=DFN-CERT GmbH, OU=DFN-PCA, CN=DFN
Validity
Not Before: Dec 1 12:11:16 2001 GMT
Not After : Jan 31 12:11:16 2010 GMT
Subject: C=DE, O=Deutsches Forschungsnetz, OU=DFN-CERT GmbH, OU=DFN-PCA, CN=DFN
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:c1:79:ae:13:2d:eb:39:a1:c4:ae:68:58:fc:13:
d8:51:bb:52:9e:d3:e4:3a:2f:1d:20:ff:60:a3:c8:
47:1b:2f:0d:69:82:e1:d4:f3:07:22:01:2e:73:a6:
11:f9:64:fb:92:80:a8:06:1a:a3:a7:98:d6:a1:74:
85:1e:16:89:2e:03:8c:2b:27:ee:5d:f3:36:8f:f8:
8b:67:85:e0:49:86:12:4b:01:ca:06:f8:b5:19:53:
4e:17:0e:ee:17:85:5f:e0:ee:e6:a1:68:92:cf:8e:
36:a6:bb:d1:19:70:3a:bd:a5:e7:72:95:c2:33:17:
04:2b:42:2c:54:8a:44:b5:6e:c5:e8:79:f9:29:a4:
9b:e1:6e:3a:6c:04:ba:09:dd:33:69:fb:e0:38:e3:
c9:ff:43:08:e6:87:19:9a:c7:c1:50:e1:f9:5a:72:
e4:dc:b8:6c:a0:92:6e:8b:a3:47:17:79:37:1b:12:
b5:4b:21:0d:56:d3:79:2d:c1:f1:3b:b3:00:96:f2:
c1:85:84:13:b7:ab:a3:1f:bb:59:37:d0:af:c8:af:
48:20:61:ac:d2:77:e9:54:63:01:bf:21:89:5f:48:
bb:2d:93:98:96:28:da:83:f2:0b:c6:b7:78:cd:f1:
8f:d2:ae:d8:85:b7:b5:2d:b3:a5:f8:88:ce:df:71:
bc:53
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
06:0B:FA:B5:F8:48:78:A3:20:B1:0B:3E:CF:A0:D0:C4:D1:7F:7D:D0
X509v3 Authority Key Identifier:
keyid:06:0B:FA:B5:F8:48:78:A3:20:B1:0B:3E:CF:A0:D0:C4:D1:7F:7D:D0
DirName:/C=DE/O=Deutsches Forschungsnetz/OU=DFN-CERT GmbH/OU=DFNPCA/CN=DFN Toplevel Certification Authority/[email protected]
serial:15:CF:FD
X509v3 Key Usage:
Certificate Sign, CRL Sign
Netscape Cert Type:
SSL CA, S/MIME CA, Object Signing CA
X509v3 CRL Distribution Points:
URI:http://www.dfn-pca.de/certification/x509/g1/data/crls/root-ca-crl.crx
URI:http://www.dfn-pca.de/certification/x509/g1/data/crls/root-ca-crl.crl
Netscape Revocation Url:
https://www.dfn-pca.de/cgi/check-rev.cgi?
Netscape CA Policy Url:
http://www.dfn-pca.de/certification/policies/x509policy.html
Anhang
Netscape Comment:
The DFN Top-Level Certification Authority
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.11418.300.1.1
CPS: http://www.dfn-pca.de/certification/policies/x509policy.html
Signature Algorithm: sha1WithRSAEncryption
26:6d:a8:ba:24:cb:7b:9e:4b:9a:bf:2b:f1:2b:32:c6:9f:4e:
06:ca:dd:33:2a:ba:7c:ce:61:11:a7:88:a7:92:db:d8:ee:9f:
af:91:aa:26:62:ed:90:60:2e:dc:1e:ad:2d:96:b3:d7:41:08:
61:7a:d8:e2:5c:66:fe:df:a6:89:b4:70:e4:10:0d:0d:c2:b2:
73:62:71:e0:3e:cb:f1:ef:3d:30:ca:c1:0d:3f:8c:31:7f:de:
ca:b1:25:a6:d3:b4:58:f9:fe:bf:80:84:05:ec:97:bb:09:6d:
f4:47:3a:bb:37:a4:74:34:c0:6c:df:69:89:81:d9:f7:9e:da:
a5:14:dc:37:35:bb:34:e7:41:44:8c:f3:6a:e7:84:5d:6b:09:
49:a3:ce:71:fb:0f:90:25:de:ee:40:ce:32:66:31:e9:46:1b:
f0:82:d7:bd:19:ed:54:a8:25:1d:a4:cb:0b:1f:37:8c:28:9d:
01:f4:68:70:20:8a:8e:24:23:22:3e:02:a3:71:40:6b:9f:a7:
a1:49:7e:f4:3c:eb:d7:be:38:c4:db:e1:73:84:f1:93:c9:39:
12:e3:be:1d:d9:40:80:9c:bf:6a:84:fa:dd:59:7c:c1:8c:eb:
a6:3a:38:49:ba:d4:f5:69:e7:26:f5:e9:63:96:c8:66:87:57:
0d:7a:7d:34
95
Anhang
96
Glossar
Public Key Infrastrucutre
Die Public Key Infrastruktur bildet die Grundlage für den Einsatz von Public Key
Kryptografie. Sie besteht aus vielen Bausteinen, die alle zusammen eine PKI bilden.
Mindestens eine Certification Authority muss vorhanden sein.
Registration Authority
Registrierungsinstanz, die alle angegebenen Daten eines Antragstellers nach
festgelegten Richtlinien überprüft.
Attribute Authority
Autorisierungsinstanz, die einen Zertifikatsbesitzer mit entsprechenden Nutzerrechten
für ein System ausstattet.
Zertifizierungsinstanz, die durch Ausstellen eines Zertifikats ein Objekt beglaubigt.
Dieses Objekt kann sich mit dem Zertifikat gegenüber anderen Objekten
authentifizieren.
Clientseitige Schutzumgebung für sensible Daten. Das PSE kann ein interner oder
externer Datenträger sein.
One Time Password
Einmalpasswort. Diese Art von Passwort kann nur einmalig verwendet werden. Nach
dem Gebrauch ist es absolut wertlos.
Single Sign-On
System bei dem sich Benutzer einmal anmelden und sich gemäß ihren erteilten
Autorisierungsinformationen frei bewegen können, ohne die Eingabe weiterer
Passwörter.
Zertifikat
Mit Hilfe von Zertifikaten wird für ein Objekt ein Zusammenhang zwischen dem
öffentlichen Schlüssel und der Identität des Objektes hergestellt. Es können zudem
Autorisierungsinformationen an ein Schlüsselzertifikat angefügt werden.
Sperrliste
In einer Sperrliste kann ein Benutzer den Status eines Zertifikats überprüfen. Es gibt
mehrere Realisierungsvarianten für Sperrlisten.
Signatur
Verfahren, bei dem die Authentifizierung des Absenders einer Nachricht mit Hilfe von
kryptografischen Methoden sichergestellt wird.
Policy
Eine Policy stellt eine Sammlung von Richtlinien und Bestimmungen dar, nach denen
ein System funktionieren und an das sich Benutzer halten sollen.
Anhang
97
Verschlüsselung
Durch diverse Algorithmen werden Informationen so verändert, das nur bestimmte zum
Empfang der Informationen berechtigte Objekte diese wieder herstellen können.
Online Certificate Status Protocol
Der Status eines einzelnen Zertifikats kann online abgefragt werden. Dies spart Zeit und
der Benutzer muss keine Sperrlisten aus dem Netz laden. Aufwendig und kompliziert in
der Umsetzung.
Lightweight Directory Access Protocol
Verzeichnisdienst, der den Zugriff auf öffentliche Zertifikate und Sperrlisten
ermöglicht. Zudem können Suchanfragen über einen Verzeichnisdienst realisiert
werden.
Entity-Relationship-Modell
Durch ein Entity-Relationship-Modell können Objekte und die Beziehungen zwischen
den Objekten einfach und grafisch dargestellt und modelliert werden.

„Konzeption einer Public Key Infrastructure für die FHTW“

Transcription

Similar documents

Konzept und Nutzen von Certificate Policy und Certification Practice

Über VASCO - Deutsche Messe

bei Leistungserbringung für die

5.2.4 Hinweise der Bundessteuerberaterkammer zum Datenschutz

ERNW Newsletter 34 /November 2010

S-TRUST Sign

TC TrustCenter GmbH Certification Practice Statement and

OPENLiMiT SignCubes Viewer

12.0862.01 - Grosser Rat Basel-Stadt - Kanton Basel

Smartcards

Autorisierungsanleitung für ArcGIS 10.2 for

Smartcards