Implementierung des Austausches kryptographischer Komponenten ...
Implementierung des Austausches kryptographischer Komponenten ... Implementierung des Austausches kryptographischer Komponenten ...
Austausch der kryptographischen Komponenten 44 Die Klasse Dialogs hängt eng mit der Klasse Status zusammen. In dieser Klasse wird z.B. der Zustand der gedrückten Tasten gespeichert. Dieser kann von anderen abgefragt werden. Damit wird der bekannte Model-View-Conroller (MVC) Ansatz implementiert. 5.7.2 Die Klasse Stat. Alle relevanten (wie z.B. Löschen oder Hinzufügen von Zertifikaten oder Providern) Handlungen, die im Laufe des Komponentenaustausches stattfinden, werden als eine Zeichenkette in einer Instanz dieser Klasse gespeichert. Am Ende des Austausches wird diese Instanz an die Methode showSummeryInfo der Klasse Dialogs übergeben. Diese Methode zeigt die relevanten Informationen an. 5.7.3 Die Klasse UpdateInProgress. Diese Klasse dient zur Visualisierung des Austauschprozesses. Die Klasse ist als ein Thread mit niedrigster Priorität realisiert. Die Klassen Update, ClientUpdate, ICCUpdate , die an dem Komponentenaustausch teilnehmen, halten gleiche Referenz auf Instanz dieser Klasse. Die Informationen, die dem Benutzer angezeigt werden sollen, werden als Parameter an die Methode outputTF übergeben, die diese Informationen in einem separaten Fenster anzeigt. Abb. 14
Austausch der kryptographischen Komponenten 45 5.7.4 Die Klasse Resolver. Diese Klasse führt Umwandlung von Algorithmusnamen zu Algorithmus OID und umgekehrt. Damit stellt sie die gleiche Funktionalität wie die Klasse codec.util.JCA zur Verfügung. Allerdings funktioniert die letzte nur dann, wenn die JCA Provider mit entsprechenden Algorithmen installiert sind. Andersfalls werden Ausnahmen ausgelöst. Im Gegenteil, die Klasse Resolver funktioniert unabhängig von installierten Providern. 5.7.5 Transportklassen. Wie oben schon erwähnt wurde, spezifiziert das Trust Center die Links (URL’s) mit Internet Adressen, wo sich die neuen kryptographische Komponenten befinden. Der Transportmechanismus (oder einfach Internet Protokoll) ist aus Flexibilitätsgründen nicht weiter spezifiziert. Bei konkreter Implementierung des Komponentenaustausches, sind zwei Möglichkeit implementiert: • HTTP und • FTP Protokolle. Die Klassen, die diese Aufgaben implementieren, befinden sich in Java – Package smime.transport. Zu den Klassen gehören: • Interface Load • Die Klasse LoadHTTP und • Die Klasse LoadFTP Die Interface Load enthält zwei Methoden: • setRequestParameter, die Anfrageparameter geeignet für spezifische Protokolle vorbereitet. Z.B. für HTTP Anfrage werden die Parameter PSE und WinNT in dieser Methode zu Zeile ?source=PSE&os=WinNT gewandelt und an das spezifizierte in UpdateComponent Link angehängt. • get lädt die neue kryptographische Komponente über Internet. Die beiden anderen Klassen sind die Implementierungen von dieser Interface für HTTP bzw. FTP Protokolle. Für die aktive HTTP- Anbindung wurde außerdem ein Servlet entwickelt , das die Anfrageparameter auswerten kann und in Abhängigkeit davon eine neue passende Komponente auswählen kann. Um Servlet ausführen zu können, braucht man einen servletfähigen Web – Server. Für diese Zwecke wurde Tomcat-Jakarta 3.2. Servletengine eingesetzt.
- Seite 1 und 2: Technische Universität Darmstadt F
- Seite 3 und 4: 4.1 Die Klasse CAAdminDialog.......
- Seite 5 und 6: Vorwort 5 Vorwort. Gegenstand diese
- Seite 7 und 8: Einführung 7 • kompromittieren e
- Seite 9 und 10: Einführung 9 Komponenten einer PKI
- Seite 11 und 12: Einführung 11 mit lokal gespeicher
- Seite 13 und 14: Definition der Datenstruktur 13 Dab
- Seite 15 und 16: Definition der Datenstruktur 15 Der
- Seite 17 und 18: Definition der Datenstruktur 17 2.4
- Seite 19 und 20: Definition der Datenstruktur 19 Die
- Seite 21 und 22: Definition der Datenstruktur 21 pri
- Seite 23 und 24: Definition der Datenstruktur 23 cer
- Seite 25 und 26: Definition der Datenstruktur 25 3.2
- Seite 27 und 28: Definition der Datenstruktur 27
- Seite 29 und 30: Implementierung des Trust Center Ad
- Seite 31 und 32: Implementierung des Trust Center Ad
- Seite 33 und 34: Implementierung des Trust Center Ad
- Seite 35 und 36: Implementierung des Trust Center Ad
- Seite 37 und 38: Austausch der kryptographischen Kom
- Seite 39 und 40: Austausch der kryptographischen Kom
- Seite 41 und 42: Austausch der kryptographischen Kom
- Seite 43: Austausch der kryptographischen Kom
- Seite 47 und 48: Einbindung des UMP in CDC Plugin f
- Seite 49 und 50: Einbindung des UMP in CDC Plugin f
- Seite 51: Literaturverzeichnis 51 Literaturve
Austausch der kryptographischen <strong>Komponenten</strong> 44<br />
Die Klasse Dialogs hängt eng mit der Klasse Status zusammen. In dieser Klasse wird z.B. der<br />
Zustand der gedrückten Tasten gespeichert. Dieser kann von anderen abgefragt werden. Damit wird<br />
der bekannte Model-View-Conroller (MVC) Ansatz implementiert.<br />
5.7.2 Die Klasse Stat.<br />
Alle relevanten (wie z.B. Löschen oder Hinzufügen von Zertifikaten oder Providern) Handlungen, die<br />
im Laufe <strong>des</strong> <strong>Komponenten</strong>austausches stattfinden, werden als eine Zeichenkette in einer Instanz<br />
dieser Klasse gespeichert. Am Ende <strong>des</strong> <strong>Austausches</strong> wird diese Instanz an die Methode<br />
showSummeryInfo der Klasse Dialogs übergeben. Diese Methode zeigt die relevanten<br />
Informationen an.<br />
5.7.3 Die Klasse UpdateInProgress.<br />
Diese Klasse dient zur Visualisierung <strong>des</strong> Austauschprozesses. Die Klasse ist als ein Thread mit<br />
niedrigster Priorität realisiert. Die Klassen Update, ClientUpdate, ICCUpdate , die an dem<br />
<strong>Komponenten</strong>austausch teilnehmen, halten gleiche Referenz auf Instanz dieser Klasse. Die<br />
Informationen, die dem Benutzer angezeigt werden sollen, werden als Parameter an die Methode<br />
outputTF übergeben, die diese Informationen in einem separaten Fenster anzeigt.<br />
Abb. 14
Change language