Abbildung 7-1 Eine Zertifikatsanforderung nach PKCS#10 [PKCS]
Immer mehr Programme verwenden zur sicheren Übertragung ihrer Daten Kommunikationsprotokolle wie SSL, S-HTTP oder PEM. Dadurch steigt aber auch die Nachfrage nach Zertifikaten, die bei einer sicheren Kommunikation von beiden Partnern benötigt werden. Es en tstehen deshalb zur Zeit viele Organisationen, die die Ausstellung dieser Zertifikate vornehmen.
Dieses Kapitel befaßt sich mit dem Konzept einer Zertifizierungsstelle. Als erstes werden Zertifikate, deren Kodierung und Übertragung zwischen Computersystemen behandelt. Danach werden die Anforderungen an eine Software für eine Zertifizierungsstelle besc hrieben, und der dritte Abschnitt befaßt sich mit einer konkreten Realisierung eines Softwarepaketes für Zertifizierungsstellen.
Die Hauptaufgabe einer Zertifizierungsstelle besteht darin, die Zugehörigkeit eines öffentlichen Schlüssels zu einem bestimmten Namen zu bescheinigen. Unter Name versteht man in diesem Zusammenhang die in X.501 definierte Struktur mit folgendem Aufbau:
Eine Zertifizierungsstelle erhält nun Zertifikatsanforderungen, die aus dem öffentlichen Schlüssel und dem Namen seines Besitzers bestehen. Als nächstes müssen diese Daten gemäß der Policy der Zertifizierungsinstanz überprüft werden. Sind die Angaben in Or dnung, so wird ein neues Zertifikat erzeugt und zur anfordernden Stelle zurückgesendet. Alle ausgestellten Zertifikate müssen auch archiviert und verwaltet werden.
Bevor eine Zertifizierungsstelle neue Zertifikate erzeugen kann, muß sie zunächst selbst ein Zertifikat besitzen, mit dem die erstellten Zertifikate überprüft werden können. Sie kann für diesen Zweck eine Zertifikatsanforderung an eine andere Zertifizierun gsstelle schicken oder sich selbst ein Zertifikat ausstellen.
Ein Zertifikat ist eine Art digitaler Ausweis, der auch entsprechend oft „hergezeigt“ werden muß. Das bedeutet, Zertifikate müssen häufig zwischen verschiedenartigen Computersystemen hin und her transportiert werden.
Zertifikate müssen daher plattformunabhängig beschrieben und für die Übertragung eindeutig kodiert werden. Am weitesten verbreitet ist die Beschreibung von Zertifikaten mit der in X.509 definierten Sprache ASN.1 und zur Kodierung für die Übertragung wird D ER verwendet.
ASN.1 (Abstract Syntax Notation One) ist ein von der internationalen Standardisierungsorganisation (ISO) genormter Standard (im Standard ITU-T X.208 definiert), mit dem Daten und Informationen systemübergreifend spezifiziert werden können. Dazu werden grun dlegende Datentypen (INTEGER, BOOLEAN, BITSTRING, usw.) und zusammengesetzte Datentypen (SEQUENCE, SET, CHOICE, usw.) für die Abbildung der realen Informationen verwendet [GORA92].
Zur Übertragung der in ASN.1 definierten Objekte ist auch eine Transfersyntax notwendig, die der abstrakten Syntax konkrete Kodierungs- und Dekodierungsregeln zuordnet. Ein solches Kodierungssystem ist zum Beispiel in X.209 definiert, und wird als BER (Bas ic Encoding Rules) bezeichnet. BER erlaubt es, ein und dasselbe ASN.1 Objekt auf verschiedene Art und Weise zu kodieren.
Bei der Kodierung von Zertifikaten wird deshalb ein anderes Kodierungssystem, DER (Distinguished Encoding Rules), verwendet. DER ist eine Untermenge von BER, wobei jedoch jedem ASN.1 Objekt eine eindeutige Kodierung zugeordnet wird. DER kodierte ASN.1 Date nstrukturen liegen in einer binären Form vor, und können direkt übertragen oder gespeichert werden.
Es gibt aber auch Übertragungsprotokolle, wie zum Beispiel SMTP, die nicht transparent sind. Dabei dürfen bestimmte Zeichen oder Zeichenketten nicht in den zu übertragenden Daten vorkommen. In diesem Fall werden die DER kodierten Zertifikate zusätzlich BAS E64 (in RFC 1521 definiert) kodiert und ergeben dann ein Zertifikat im PEM Format, das nur ASCII Zeichen enthält.
Als Beispiel für die abstrakte Definition von Datenstrukturen mit ASN.1 ist hier ein Zertifikat nach X.509 Version 3 angegeben:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
TBSCertificate ::= SEQUENCE {
version [ 0 ] Version DEFAULT v1(0),
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL,
extensions [ 3 ] Extensions OPTION AL
}
Außer neue Zertifikate zu erstellen, müssen Zertifizierungsinstanzen auch noch andere Aufgaben erledigen, die im folgenden erklärt werden.
Die Erzeugung eines asymmetrischen Schlüsselpaares bildet die wichtigste Funktion einer Zertifizierungsstelle. Da bereits die Faktorisierung einer 428 Bit langen Zahl gelungen ist, soll die Länge der erzeugten Schlüssel mindestens 768 Bit, besser 1024 Bit betragen.
Ein wichtiges Kriterium bei der Erzeugung eines Schlüsselpaares, ist die wirkliche Zufälligkeit der benötigten Primzahlen. Sind die erzeugten Primzahlen vorhersehbar, oder ist die Erzeugung nachvollziehbar, so kann der geheime Schlüssel von einem Angreifer einfacher gefunden werden. Die Erzeugung wirklicher Zufallszahlen ist deshalb eine sehr wichtige Anforderung an die Software für Zertifizierungsstellen.
Der erzeugte geheime Schlüssel der Zertifizierungsstelle ist das zentrale Instrument dieses Sicherheitssystems. Er muß daher in einer geeigneten Weise verwahrt und geschützt werden. Auf jeden Fall soll der geheime Schlüssel mit einem symmetrischen Verfahre n verschlüsselt und mit einem Paßwort geschützt abgespeichert werden. Am sichersten ist allerdings die Verwahrung des Schlüssels auf einer sogenannten Smartcard. Dabei wird der Schlüssel auf einer Chip-Karte gespeichert, die dann ähnlich wie eine Bankomat- Karte vor unbefugtem Zugriff geschützt werden kann.
Eine alternative Möglichkeit ist die Verwendung einer Diskette oder eines ähnlichen Mediums statt einer Smartcard. Diese Medien sind aber meist wesentlich unhandlicher und anfälliger auf äußere Einwirkungen wie Hitze oder Magnetfelder. Außerdem können dies e Medien mit jedem beliebigen Computer, der ein entsprechendes Laufwerk besitzt, eingesehen und kopiert werden.
In einer Zertifizierungshierarchie besitzt nur die oberste Zertifizierungsstelle ein selbst signiertes Zertifikat (self signed certificate). Alle anderen Zertifizierungsinstanzen müssen von einer anderen Stelle zertifiziert werden.
Für die Anforderung eines Zertifikates wird eine spezielle Datenstruktur (Zertifikatsanforderung, certificate request) generiert, mit dem eigenen geheimen Schlüssel signiert und zur Zertifizierungsstelle gesendet.
Aufbau einer Zertifikatsanforderung
Abbildung 7-1 Eine Zertifikatsanforderung nach PKCS#10 [PKCS]
Die Felder der Anforderung haben dabei die folgende Bedeutung:
Diese Daten werden nun mit dem eigenen geheimen Schlüssel unterschrieben. Diese Unterschrift gewährleistet, daß der Sender der Zertifikatsanforderung auch der Besitzer des geheimen Schlüssels ist, und die Daten auf dem Übertragungsweg nicht verändert werde n können.
Als nächstes wird diese Anforderung über ein geeignetes Übertragungsmedium an die darüberliegende Zertifizierungsstelle gesendet. Dort wird dann aus dieser Anforderung das eigentliche Zertifikat erzeugt und zurückgeschickt.
Dieses neue Zertifikat bildet nun gemeinsam mit dem geheimen Schlüssel die Grundlage für die Ausstellung eigener Zertifikate.
Es gibt zwei mögliche auslösende Ereignisse für die Erzeugung eines neuen Zertifikates:
Beim Erzeugen eines Zertifikates nach X.509 werden die entsprechenden Felder (siehe Abschnitt 4.4.2) ausgefüllt und mit dem geheimen Schlüssel der Zertifizierungsstelle unterschrieben. Auf zwei Felder muß bei der Erzeugung eines Zertifikates jedoch besonde rs geachtet werden:
Es ist daher zu erwarten, daß eine Software früher oder später Zertifikate erhält, deren Erweiterungen sie nicht verarbeiten kann. Falls dieser Fall eintritt, können unbekannte Erweiterungen, die als nicht kritisch markiert sind einfach ignoriert werden. H andelt es sich jedoch um kritische Erweiterungen, so darf das dazugehörige Zertifikat nicht bearbeitet werden.
Nichtbekannte Erweiterungen sollen aber zumindest in einer geeigneten Form angezeigt werden, damit der Benutzer der Software die Informationen in den Erweiterungen zumindest sehen und falls möglich interpretieren kann.
Bekannte Erweiterungen sollen in der Software vollständig beschrieben und konfigurierbar sein. Es soll auch einstellbar sein, welche Erweiterungen bei der Erzeugung eines Zertifikates verwendet werden müssen.
Für Zertifizierungsstellen, die an der Spitze einer Zertifizierungshierarchie stehen, gibt es keine darüberliegende Stelle, von der sie zertifiziert werden könnten. Deshalb müssen sie Zertifikate erstellen, die von ihnen selbst unterschrieben sind.
Selbst signierte Zertifikate werden aber auch von Organisationen benötigt, die ein Zertifizierungssystem nur intern verwenden wollen und keine Verbindung zur „Außenwelt benötigen“.
Bei selbst signierten Zertifikaten muß der Name des Ausstellenden gleich dem Namen des Zertifikatsinhabers sein. Weiters soll die Seriennummer eines selbst signierten Zertifikates Null betragen. Die Gültigkeitsdauer eines solchen Zertifikates kann beliebig gewählt werden.
Die wichtigste Tätigkeit in diesem Zusammenhang ist die Prüfung der Identiät, die gemäß der Policy der Zertifizierungsstelle zu erfolgen hat.
Hat diese Überprüfung erfolgreich stattgefunden, so wird aus der Zertifikatsanforderung das Zertifikat erzeugt, archiviert und über einen sicheren Kanal zum Absender der Anforderung zurückgesendet.
Außerdem ist bei der Ausstellung von Zertifikaten zu berücksichtigen, daß das erzeugte Zertifikat nicht länger als das Zertifikat des Ausstellers gültig sein kann.
Bei der Erzeugung von Zertifikaten wird angenommen, daß sie bis zum Ende ihrer Gültigkeit verwendet werden. Es gibt aber auch viele Umstände, die es notwendig machen, ein Zertifikat vor Ablauf seiner Gültigkeitsdauer für ungültig zu erklären (zu widerrufen ). Zu solchen Umstände gehören Namensänderungen, eine Veränderung der Verbindung zwischen Zertifizierungsstelle und Inhaber (zum Beispiel arbeitet ein Angestellter nicht mehr bei einer Firma) oder Probleme mit dem geheimen Schlüssel (Schlüssel verloren, ei n anderer kennt den geheimen Schlüssel, usw.).
Eine Zertifizierungsstelle muß daher periodisch eine Liste der widerrufenen Zertifikate (CRL) erzeugen und öffentlich verfügbar machen. In welchen Zeitabständen eine neue Liste erzeugt wird, ist in der Policy der Zertifizierungsstelle festgelegt.
Die Zertifizierungssoftware muß deshalb die Möglichkeit bieten ein erzeugtes Zertifikat für ungültig zu erklären und zu widerrufen. Weiters muß die Möglichkeit bestehen, in periodischen Abständen automatisch eine CRL zu generieren und öffentlich zur Verfüg ung zu stellen.
Die von einer Zertifizierungsstelle ausgestellten Zertifikate müssen auch archiviert werden. Dies ist notwendig, da einerseits Zertifikate öffentlich zugänglich sein müssen, und andererseits Zertifikate für ungültig erklärt werden können. Beim Widerrufen v on Zertifikaten werden dann die entsprechenden Daten wieder benötigt.
Die gespeicherten Zertifikate sollen möglichst einfach zu verwalten sein. Wichtig sind auch Suchfunktionen, die das Auffinden von Zertifikaten, welche bestimmte Kriterien erfüllen, ermöglichen. Am besten eignet sich daher eine Datenbank für die Speicherung von Zertifikaten.
Bei der Überprüfung von Zertifikaten sind oft weitere Zertifikate notwendig. Diese können dann bei den entsprechenden Zertifizierungsstellen angefordert werden.
Die Zertifizierungssoftware muß deshalb die von ihr ausgestellten Zertifikate über geeignete Schnittstellen öffentlich zur Verfügung stellen.
Für die verschiedenen Anforderungen, die an eine Zertifizierungsstelle gestellt werden sind mehrere Interfaces zur Kommunikation mit der Außenwelt erforderlich.
Es ist dabei zu beachten, daß hier nur die notwendige Funktionalität der Schnittstellen allgemein beschrieben wird. Die zugrundeliegenden Protokolle und Formate zur Übertragung der Daten werden nicht beschrieben.
Für die Ausstellung einzelner Zertifikate ist ein Command-Line Interface nicht geeignet. Es müssen viele Parameter angegeben werden, und der ganze Zertifizierungsprozeß ist sehr unübersichtlich.
Soll aber die Funktionalität der Zertifizierungssoftware auch für andere Programme verwendbar sein, so ist dies nur über eine Command-Line Schnittstelle möglich. Müssen zum Beispiel sehr viele Zertifikate auf einmal erzeugt werden, so kann der Sicherheits- Beauftrage ein kleines Programm schreiben, welches das Programm für die Erzeugung neuer Zertifikate einfach entsprechend oft aufruft.
Der Betrieb der Zertifizierungsstelle soll auch über ein Programm mit graphischer Benutzeroberfläche möglich sein. Das Programm soll dabei einfach und logisch zu bedienen sein. Alle benötigten Informationen müssen übersichtlich am Bildschirm dargestellt we rden.
Als einer der wichtigsten Dienste im Internet sollen folgende Funktionen der Zertifizierungsstelle auch über das WWW verfügbar sein:
Die Anforderung von Zertifikaten soll auch über EMail möglich sein. Diese Schnittstelle ist vor allem für jene Programme, die nicht direkt mit der Zertifizierungsstelle kommunizieren können, sehr wichtig.
Natürlich kann ein Programm auch direkt das EMail Interface der Zertifizierungsstelle unterstützten.
Dieser Abschnitt beschreibt die konkrete Realisierung einer im Rahmen der Diplomarbeit entwickelten Zertifizierungsstelle. Für die Implementation wurde die plattformunabhängige und objektorientierte Programmiersprache Java verwendet.
Die entwickelte Software besteht aus einer Klassenbibliothek und aus dem darauf aufbauenden Programm zum Betrieb einer Zertifizierungsstelle.
Die Grundlage der Zertifizierungssoftware bildet eine Klassenbibliothek. Sie stellt die benötigte Funktionalität zum Betrieb einer Zertifizierungsstelle zur Verfügung.
Grundsätzlich sind alle Klassen ihrer Verwendung nach einer von drei Ebenen zuzuordnen.
Abbildung 7-2 Struktur der Klassenbibliothek
Die Basis-Klassen stellen die benötigten grundlegenden Funktionen zur Verfügung. In Java werden zusammengehörende Klassen zu Paketen zusammengefaßt. Die Basis-Klassen bestehen aus vier solchen Paketen.
Dieses Paket enthält die benötigten kryptographischen Grundfunktionen. Dazu gehören symmetrische Verschlüsselungsverfahren und Hashfunktionen. Alle Algorithmen sind entsprechend ihrer Spezifikationen implementiert.
| Art | Algorithmus |
|---|---|
| block cipher | DES, Tripple DES, IDEA |
| stream cipher | RC4 |
| Betriebsarten für alle block cipher | CBC-Mode, ECB-Mode |
| Hash Funktionen | SHA, SHA-1, MD5 |
Tabelle 7-1 Implementierte Algorithmen
Das Paket RSA enthält alle notwendigen Klassen zur Verschlüsselung von Daten nach dem RSA-Verfahren.
Diese Klasse dient zur Bearbeitung ganzer Zahlen beliebiger Länge. Neben den Grundfunktionen Addition, Subtraktion, Multiplikation und Division enthält sie Vergleichsoperationen, die Modulo Operation usw.
Unter anderem wurden folgende mathematischen Verfahren implementiert:
Berechnung des größten gemeinsamen Teilers, Modulomultiplikation,
Moduloexponentiation, Berechnung der multiplikativen Inversen.
Weiters enthält diese Klasse die benötigten Methoden zur Bearbeitung der in den PKCS Standards (1, 5, 8, und 10) definierten Datenstrukturen.
Bei dieser Implementation wird eine ungerade Zufallszahl generiert, und so lange um zwei erhöht, bis es sich um eine Primzahl handelt. Da es ungefähr n/(ln n) Primzahlen kleiner n gibt, führt dieses Verfahren relativ schnell zum Erfolg.
Der Primzahlentest wird in zwei Schritten durchgeführt. Zuerst wird geprüft, ob die Zahl kleine Faktoren in Form von Primzahlen zwischen 2 und 8161 besitzt. Besteht die Zahl diesen Test, so handelt es sich mit einer Wahrscheinlichkeit von 88% um eine Primz ahl. Nun wird der kleine Satz von Fermat (siehe Abschnitt 5.1.2) mit der zu prüfenden Zahl und den ersten vier Primzahlen angewandt. Besteht sie auch diesen Test, so handelt es sich mit sehr hoher Wahrscheinlichkeit um eine Primzahl.
Auf die Generierung starker Primzahlen wurde verzichtet, da bei neueren Faktorisierungsverfahren die Verwendung starker Primzahlen keine Vorteile mehr bringt.
Die Erzeugung der Zufallszahlen ist der kritische Teil dieser Klasse. Der zu benutzende Zufallsgenerator wird daher als Parameter übergeben.
Dieses Paket enthält Klassen für die Behandlung von ASN.1 kodierten Daten. Es können ASN.1 Datenstrukturen erzeugt und analysiert werden. Außerdem enthält dieses Paket Methoden zur Behandlung DER- oder BASE64-Kodierter Datenstrukturen.
Das Paket Utilities schließlich enthält Klassen, die entweder von allen anderen Paketen benötigt werden oder die sich in keines der oberen Pakete einordnen lassen. Dazu zählen hauptsächlich Formatkonvertierungen und die Verwaltung von Objekten.
Hierbei handelt es sich um anwendungsorientierte Klassen, welche einen einfachen Umgang mit den zu erwartenden Datenstrukturen ermöglichen. Diese Klassen werden verwendet, falls mit der Klassenbibliothek neue Programme erstellt werden.
Bei allen dieser Klassen kann eine Instanz aus einer Datei im PEM oder DER Format werden.
Weiters besitzen alle Klassen eine Methode zur Speicherung der ASN.1 Datenstrukturen entweder im PEM oder im DER Format.
Dient zur Handhabung öffentlicher Schlüssel, die im PKCS#1 Format „RSAPublicKey“ vorliegen.
Dient zur Handhabung geheimer Schlüssel, die im PKCS#1 Format „RSAPrivateKey“ vorliegen. Der geheime Schlüssel kann dabei auch mit IDEA oder DES-CBC verschlüsselt abgespeichert werden.
Diese Klasse besitzt weiters eine Methode zur Erzeugung eines neuen Schlüsselpaares, wobei die Länge des Modulus in Bit angegeben werden kann. Der für die Primzahlenerzeugung benötigte Zufallsgenerator wird von der aufrufenden Methode als Parameter übergeb en.
Diese Klasse repräsentiert ein Zertifikat nach X509. Dabei kann das Zertifikat auch im etwas modifizierten Netscape Format vorliegen.
Es können Zertifikate erzeugt, verifiziert und analysiert werden. In der aktuellen Version können nur X.509 Version 0 Zertifikate erzeugt werden. Die Bearbeitung und Anzeige von Version 3 Zertifikaten ist aber möglich.
Mit dieser Klasse können selbst unterschriebene Zertifikatsanforderungen erstellt und bearbeitet werden.
Diese Klasse dient zur allgemeinen Handhabung von ASN.1 Objekten. Bei der Initialisierung wird das ASN.1 Objekt auf Korrektheit überprüft, und danach kann auf alle Komponenten der Datenstruktur zugegriffen werden.
Das sind Klassen, die mit Command-Line Parameter aufgerufen, wie gewöhnliche Programme verwendet werden können. Sie können aber auch wie gewöhnliche Klassen in anderen Programmen weiterverwendet werden.
Mit diesem Programm können ASN.1 kodierte Datenstrukturen auf ihre Korrektheit überprüft und am Bildschirm ausgegeben werden.
Mit dem Programm genkey kann ein neues RSA-Schlüsselpaar erzeugt werden. Die zur Generierung benötigten Zufallszahlen werden dabei durch Messung des Intervalls zwischen hintereinanderfolgenden Tastaturanschlägen gewonnen.
Der geheime Schlüssel kann auch mit IDEA oder DES-CBC verschlüsselt abgespeichert werden.
Dieses Programm dient zur Bearbeitung von X509 Zertifikaten. Es kann die Signatur des Zertifikates überprüfen und den Inhalt gewünschter Datenfelder sowie einen Fingerabdruck (fingerprint) des Zertifikates ausgeben.
Die Klasse NetscapeCertRequest kann im Gegensatz zu den bisher vorgestellten Klassen nicht als eigenständiges Programm verwendet werden. Diese spezielle Klasse wurde als Erweiterung für den vom W3C entwickelten Web-Server „Jigsaw“ konzipiert.
Jigsaw ist ein in Java geschriebener Web-Server, der sehr einfach dynamisch um neue Ressourcen erweitert werden kann [ABS96]. Unter einer Ressource versteht man in diesem Zusammenhang ein Objekt, welches beliebige Daten oder Datenstrukturen in eine für den Server standardisierte Form bringt, so daß diese Daten mittels HTTP über ein Netzwerk übertragen werden können. Die Richtung der Datenübertragung spielt in diesem Fall keine Rolle.
Weiters ermöglicht es Jigsaw den Ressourcen, verschiedene Attribute registrieren und verwalten zu lassen. Diese Attribute können dann vom Serveradministrator über ein graphisches User-Interface konfiguriert werden. Die Ressource NetscapeCertRequest definie rt folgende Attribute für die sofortige Ausstellung von Zertifikaten:
Die Aufgabe dieser Klasse ist die Entgegennahme und Bearbeitung von Zertifikatsanforderungen, die vom Web-Browser „Netscape Navigator™“ generiert wurden.
Wird mit einem Zertifikat zum Beispiel nur die Eindeutigkeit der EMail Adresse innerhalb dieser Zertifizierungsstelle bestätigt, so kann diese Überprüfung sofort stattfinden und das erzeugte Zertifikat wird direkt als Antwort an diese Anfrage zurückgeschi ckt und vom Browser in die Datenbank übernommen.
Bei strengeren Verfahrensweisen für die Ausstellung eines Zertifikates muß die Zertifikatsanforderung abgespeichert und später von einer Person bearbeitet werden. Die erfolgreiche Ausstellung des Zertifikates und weitere Informationen können dann dem Inhab er per EMail mitgeteilt werden.
Die Verarbeitung einer Netscape Zertifikatsanforderung läuft in folgenden Schritten ab:
Als erstes werden die empfangenen Daten dekodiert und in die ASN.1 Datenstruktur „SignedPublicKeyAndChallange“ umgewandelt. Als nächstes wird diese selbst unterschriebene Datenstruktur auf ihre Korrektheit überprüft. Ist die Datenstruktur in Ordnung, so ka nn gemäß der Policy weiterverfahren werden.
Dieses Programm ermöglicht einen einfachen Betrieb einer Zertifizierungsstelle. Alle notwendigen Informationen werden übersichtlich am Bildschirm dargestellt und der ganze Zertifizierungsablauf ist logisch aufgebaut und einfach nachvollziehbar.
Das Programm wurde als eine Anwendung der zuvor beschriebene Klassenbibliothek implementiert und stellt lediglich eine graphische Benutzeroberfläche für die bereits erklärten Funktionen zur Verfügung. Interessant in diesem Zusammenhang ist nur die Implemen tierung des Zufallszahlengenerators, der bei der Erzeugung eines neuen Schlüsselpaares Verwendung findet.
Für die Erzeugung einer zufälligen Zahlenfolge wurde die lineare Kongruenzmethode (Linear Congruential Method), beschrieben von Donald E. Knuth in [KNU81] verwendet. Nach der Initialisierung mit einem zufälligen Wert liefert dieses Verfahren eine Folge von zufälligen Zahlen, die aber vom Initialisierungswert abhängen. Es ist daher wichtig, einen „wirklich zufälligen“ Startwert zu finden.
Dieser Zufallszahlengenerator verwendet die laufend auftretenden Ereignisse eines Programmes mit graphischer Benutzeroberfläche zur Erzeugung eines zufälligen Startwertes. Mögliche Ereignisse sind zum Beispiel:
Man kann erkennen, daß in relativ kurzer Zeit viele solcher Ereignisse stattfinden. Wird das Programm gestartet und sofort die Schlüsselerzeugung gewählt, so haben schon ungefähr 80 Ereignisse stattgefunden.
Jedes dieser Ereignisse wird dem Zufallsgenerator zugeführt. Dieser bestimmt dann folgende Parameter:
Bei jedem Aufruf wird der aktuelle MD5-Hashwert durch Hinzufügen dieser Werte aktualisiert.
Wird schließlich ein neuer Startwert benötigt, so wird für die Erzeugung eines neuen Zufallszahlengenerators der aktuelle Wert der Hashfunktion verwendet.
Nach dem Start des Programmes wird die aktuelle Konfiguration zur Erzeugung neuer Zertifikate angezeigt. Issuer Name zeigt dabei den Namen dieser Konfiguration. Weiters wird die Gültigkeitsdauer der erezugten Zertifikate sowie die Seriennummer des nächsten auszustellenden Zertifikates angezeigt.
Abbildung 7-3 Certification Authority - Hauptfenster
Es wird nun die Funktionalität des Programms anhand der Menüleiste erklärt.
Dieses Menü enthält alle Funktionen zur Bearbeiten von Zertifikaten. Es enthält folgende Menüpunkte:
Abbildung 7-5 zeigt den Dialog zur Erzeugung eines selbst signierten Zertifikates. Es müssen nur der Name des Zertifikatsinhabers und das Schlüsselpaar angegeben werden. Wie aus Abbildung 7-4 ersichtlich kann entweder ein existierender Schlüssel geladen od er ein neuer generiert werden.
Außerdem ist die Erzeugung eines Zertifikates im Netscape Format möglich.
Es wird eine Zertifikatsanforderung erzeugt und im DER oder PEM Format abgespeichert. Diese Anforderung muß nun an die nächsthöhere Zertifizierungsstelle in der Hierarchie geschickt werden.
Mit dieser Funktion können eingehende Zertifikatsanforderungen behandelt werden. Dabei wird mit dem aktiven Zertifikat und den Daten der Anforderung ein neues Zertifikat erstellt. Da alle Daten automatisch gesetzt werden, muß nach einer entsprechenden Kont rolle die Zertifizierung nur mehr betätigt werden. Das erzeugte Zertifikat wird wieder im PEM oder DER Format gespeichert.
Der Dialog zur Erzeugung des Zertifikates ist gleich wie der Dialog in Abbildung 7-5 aufgebaut. Nur die Namen von Aussteller und Inhaber sind verschieden.
Mit dieser Funktion ist es möglich einen öffentlichen Schlüssel zu zertifizieren. Die fehlenden Daten des Zertifikatsinhabers müssen aber vom Sicherheitsadministrator selbst eingetragen werden.
Abbildung 7-4 Auswahl eines Schlüssels
Abbildung 7-5 Erzeugung eines neuen Zertifikats
Dieser Dialog (Abbildung 7-6) dient zur Verwaltung der Parameter für die Zertifikate der Zertifizierungsstelle, mit denen neue Zertifikate erzeugt werden können.
Es muß ein Zertifikat und der dazugehörige geheime Schlüssel sowie die Gültigkeitsdauer der erzeugten Zertifikate und die nächste zu verwendende Seriennummer angegeben werden. Im laufenden Betrieb wird die Seriennummer automatisch weitergezählt. Nach der E ingabe eines Namens für diese Konfiguration können die Angaben mit dem „Add“ Button übernommen werden.
Das aktuell ausgewählte Zertifikat wird nach Verlassen des Dialogs als aktiv gesetzt und für die Ausstellung neuer Zertifikate verwendet.
Hier können die Standard-Verzeichnisse für erzeugte Zertifikate und Zertifikatsanforderungen angegeben werden.
Abbildung 7-6 Verwaltung der Aussteller-Zertifikate
Mit den Utilities können die jeweiligen Datenstrukturen angezeigt und falls erwünscht in ein anderes Format umgewandelt werden. Der Menüpunkt „Generate Key Pair“ dient zur Erzeugung eines neuen Schlüsselpaares.
Die Zertifizierungssoftware wird nach Abschluß dieser Diplomarbeit weiterentwickelt. Es sind unter anderem folgende Verbesserungen und Erweiterungen geplant: