Entwurf und prototypische Implementierung eines sicheren E-Mail ...

Entwurf und prototypische
Implementierung eines
sicheren E-Mail-Konzepts im
TU-Projekt „Campuskarte“
Diplomarbeit
Sebastian Zickau
Matrikel-Nr.: 166644
Berlin, den 12. November 2002
Technische Universität Berlin
Fakultät IV - Informatik und Elektrotechnik
Prof. Dr.-Ing. Stefan Jähnichen
Institut für Softwaretechnik und Theoretische Informatik
Betreuer: Dipl.-Inform. Thomas Gebhardt,
Dipl.-Inform. Klaus Nagel
i

Eidesstattliche Erklärung
Die selbständige und eigenhändige Anfertigung versichere ich an Eides statt.
Berlin, den 12. November 2002
______________________
Sebastian Zickau
iii

Danksagung
Für die gute Betreuung der Diplomarbeit möchte ich mich bei allen Mitarbeitern des Security
Teams bedanken, die mich mit viel Rat und großer Hilfe unterstützt haben.
Besonderen Dank gebührt meinen Betreuern Klaus Nagel und Thomas Gebhardt, die mir
u.a. als fachliche Diskussionspartner und Lektoren zur Seite standen.
Für die Funktionalität der Chipkarte ist im Projekt Lutz Suhrbier zuständig, der mir ebenfalls
beim Aufspüren einiger Fehler geholfen hat. Thomas Hildmann und Gerd Schering gaben
mir Unterstützung bei Fragen zum TUB-Trustcenter. Klaus Hamann, der sich im laufenden
Projekt für die Personalisierung der Campuskarten verantwortlich zeigt, beriet mich
ebenfalls in einigen Fachfragen.
Ein Dank gebührt auch meiner Familie und meinen Freunden, die mich mit viel Rückhalt
unterstützten und in Layout- und Lektoratsfragen berieten.
iv

Inhaltsverzeichnis
2EINLEITUNG.............................................................................................................1
2.1ZIELE DER ARBEIT................................................................................................................ 1
2.2ÜBERBLICK UND AUFBAU DER VORLIEGENDEN ARBEIT................................................................2
2.3SICHERHEITSBEDÜRFNISSE.......................................................................................................2
2.4DAS TU-PROJEKT „CAMPUSKARTE“.......................................................................................3
3UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN......................... 4
3.1KRYPTOGRAFIE..................................................................................................................... 4
3.1.1Symmetrische Verfahren.......................................................................................4
3.1.2Asymmetrische Verfahren.....................................................................................5
3.1.3Hybride Verfahren................................................................................................6
3.1.4Hashfunktionen.....................................................................................................6
3.2DIGITALE UNTERSCHRIFTEN....................................................................................................7
3.2.1Signaturen.............................................................................................................7
3.2.2Zertifikate............................................................................................................. 8
3.3AUFBAU DES TUB-TRUSTCENTERS.........................................................................................8
3.3.1TUB-CA................................................................................................................ 9
3.3.2Personen-CA.......................................................................................................10
3.4GESETZLICHER HINTERGRUND...............................................................................................10
3.4.1Bundesdatenschutz- und Signaturgesetz.............................................................10
3.4.2Berliner Datenschutzgesetz................................................................................ 11
3.4.3Dienstvereinbarungen der TU-Berlin.................................................................11
3.4.4TUB-Sicherheitskonzept für sichere E-Mail.......................................................11
3.5DATENMODELL DER CAMPUSKARTE....................................................................................... 12
3.6COMMON CRITERIA.............................................................................................................13
3.7ITSEC.............................................................................................................................13
3.8E-MAIL-STANDARDS...........................................................................................................13
3.8.1S/MIME ..............................................................................................................13
3.8.2PEM....................................................................................................................14
3.8.3PGP.................................................................................................................... 14
3.9MAILTRUST...................................................................................................................... 14
3.10KRYPTOGRAFIE- UND ZERTIFIKATSTANDARDS........................................................................ 15
3.10.1RSA................................................................................................................... 15
3.10.23DES.................................................................................................................16
3.10.3SHA-1 mit RSA................................................................................................. 16
3.10.4X.509-Zertifikate...............................................................................................16
3.11VERHALTEN VON E-MAIL-CLIENTS MIT UNTERSCHIEDLICHEN TESTZERTIFIKATEN........................ 18
3.11.1Netscape Messenger 4.7x................................................................................. 19
3.11.2Microsoft Outlook 2000....................................................................................19
3.12X.500-VERZEICHNIS UND CERTIFICATE REVOCATION LIST..................................................... 20
3.13PUBLIC KEY CRYPTOGRAPHIC STANDARDS........................................................................... 21
3.14HARDWARE- UND TREIBERSTANDARDS................................................................................. 22
3.14.1Open Card Framework.....................................................................................22
3.14.2PC/SC............................................................................................................... 23

INHALTSVERZEICHNIS
3.14.3Welche SmartCard wird eingesetzt?.................................................................24
3.14.4Welche Kartenleser werden eingesetzt?........................................................... 24
3.14.5ISO-7816-Standard...........................................................................................24
3.14.6ASN.1................................................................................................................25
3.14.7M.U.S.C.L.E......................................................................................................25
4ANFORDERUNGSANALYSE FÜR SICHERE E-MAIL................................... 26
4.1BESTEHENDE LÖSUNGEN...................................................................................................... 26
4.2ISP-VORGEHENSMODELL - ERLÄUTERUNGEN.......................................................................... 28
4.3ANFORDERUNGEN................................................................................................................29
4.3.1Nicht funktionale Anforderungen....................................................................... 29
4.3.2Funktionale Anforderungen................................................................................30
4.4PROBLEMBEREICHSMODELL................................................................................................... 30
4.5ANWENDUNGSFALLMODELL...................................................................................................31
4.5.1Anwendungsfalldiagramme................................................................................ 31
4.5.2Anwendungsfallbeschreibung.............................................................................32
4.6SCHNITTSTELLENMODELL...................................................................................................... 34
4.6.1Benutzerschnittstellendefinition......................................................................... 34
4.6.2Systemschnittstellendefinition.............................................................................35
5ANALYSE UND ENTWURF.................................................................................. 36
5.1ANALYSE...........................................................................................................................36
5.1.1Beispielausschnitt einer Logdatei.......................................................................36
5.1.2Aufgerufene Funktionen..................................................................................... 37
5.1.3Unterschiede und Gemeinsamkeiten zur erarbeiteten Lösung........................... 38
5.1.4Sequenzdiagramm...............................................................................................38
5.1.5Aktivitätsdiagramme...........................................................................................39
5.1.6Cryptoki.............................................................................................................. 44
5.2ENTWURF ......................................................................................................................... 45
5.2.1Architekturmodell............................................................................................... 45
5.2.2Vor- und Nachteile des Schichtenmodells.......................................................... 49
5.3ENTWURFSENTSCHEIDUNGEN................................................................................................. 49
5.3.1Unterschied zwischen PKCS#11-Sessionprinzip und Campuskarte.................. 50
5.3.2Auswahl der Schlüssel........................................................................................ 50
5.3.3Aufgaben der Schichten......................................................................................51
5.3.4Erstellen der JavaVM......................................................................................... 52
5.3.5PKCS#11 Flags.................................................................................................. 52
5.3.6Externe Zertifikate.............................................................................................. 53
5.4ABLAUFDARSTELLUNG..........................................................................................................53
6SPEZIFIKATION UND IMPLEMENTIERUNG.................................................56
6.1SPEZIFIKATION.................................................................................................................... 56
6.1.1Native-Code........................................................................................................56
6.1.2Java-Code...........................................................................................................58
6.1.3CampuskarteAppletProxy-Funktionen............................................................... 59
vii

6.2IMPLEMENTIERUNG.............................................................................................................. 61
6.2.1Versionskontrolle durch Einsatz von CVS..........................................................61
6.2.2Die Struktur der Programmsourcen...................................................................61
6.2.3Java Native Interface..........................................................................................62
7INSTALLATION, KONFIGURATION UND TESTS..........................................64
7.1TECHNISCHE VORAUSSETZUNGEN.......................................................................................... 64
7.2INSTALLATION.....................................................................................................................64
7.2.1Über Kryptografische Module-Dialogbox (Netscape Messenger 4.7x)............. 64
7.2.2Über JavaScript-Seite.........................................................................................66
7.2.3Zertifikatsdateien................................................................................................66
7.2.4LDAP für Netscape einrichten............................................................................67
7.3TESTS............................................................................................................................... 68
8ERGEBNISSE UND AUSBLICK........................................................................... 70
8.1FAZIT................................................................................................................................70
8.2KRITISCHE BETRACHTUNGEN................................................................................................ 71
8.2.1Kompromittierung von Schlüsseln......................................................................71
8.2.2Mögliche Angriffe auf Rechner...........................................................................71
8.2.3Virenschutz......................................................................................................... 71
8.3ERWEITERUNGSMÖGLICHKEITEN............................................................................................. 72
8.4AUSBLICK..........................................................................................................................72
9ANHANG.................................................................................................................. 74
9.1GLOSSAR........................................................................................................................... 74
9.2ABKÜRZUNGEN...................................................................................................................78
9.3ABBILDUNGEN.................................................................................................................... 80
9.4TABELLEN..........................................................................................................................81
9.5BIBLIOGRAFIE..................................................................................................................... 82
9.6EINGESETZTE TOOLS ...........................................................................................................86

2 Einleitung
Elektronische Post 1 gehört zu den Diensten des Internets, die am häufigsten genutzt werden.
Täglich werden weltweit Milliarden von E-Mails verschickt. Nach einer Studie des Marktforschungsinstituts
IDC 2 werden es im Jahr 2005 pro Tag durchschnittlich 36 Milliarden sein.
Laut IDC verfügten im Jahr 2000 505 Millionen Menschen über ein E-Mail-Postfach, hier ist
mit einer Verdopplung bis 2005 zu rechnen.
Die heutige Arbeitswelt von Computeranwendern 3 wird bestimmt durch das Lesen,
Aufarbeiten und Beantworten von E-Mails.
Vertrauliche Nachrichten sind sowohl in der Berufswelt sowie im privaten Bereich wichtig
u n d notwendig. Daher ist es erforderlich, dass die digitalen Daten des Senders nur für
den adressierten Empfänger lesbar sind. Demzufolge müssen die Nachrichten geheim sein
und das unbefugte Lesen von Dritten muss ausgeschlossen werden.
Der E-Mail-Dienst bietet im Vergleich zu herkömmlichen Kommunikationsmitteln, wie
Brief, Fax oder Telefon, entscheidende Vorteile. Es ist möglich Dateien zu verschicken, die
in elektronischer Form weiterverarbeitet, archiviert und ausgedruckt werden können.
In der Verwaltung einer großen Institution wie der Technische Universität Berlin fallen
viele personenbezogene Daten an, die aus ethischer und rechtlicher Sicht nur für befugte Personen
bestimmt sind.
Bei der Nutzung von offenen Netzen und unverschlüsselten Leitungen ist es erforderlich,
E-Mails und Datenpakete zu verschlüsseln.
Neben dem kryptografischen Verfahren der Verschlüsselung bildet die elektronische Signatur
eine Möglichkeit, Dokumente mit entsprechenden verbindlichen Unterschriften zu versehen.
Dieses ist ein weiteres Anwendungsgebiet, das in einem öffentlichen Verwaltungsapparat
zusätzliche Flexibilität im Gebrauch von elektronischer Post liefert.
Diese Diplomarbeit entstand im Rahmen des TU-Projekts „Campuskarte“, auf das noch
näher in Abschnitt 2.4 eingegangen wird.
2.1 Ziele der Arbeit
Ziel dieser Arbeit ist eine Anbindung des elektronischen Studierenden- und Dienstausweis
Campuskarte an einen der aktuellen E-Mail-Clients mit dem Resultat, einen sicheren E-Mail-
Dienst für die Nutzer der TUB-Chipkarte zu schaffen.
Dafür wird ein Entwurf konzipiert, der durch eine prototypische Implementierung realisiert
wird. Dieser Prototyp soll eine rechtssichere und benutzerfreundliche Anwendung garantieren.
Ein weiteres Ziel ist eine kritische Auseinandersetzung mit bestehenden sicheren E-Mail-
Systemen.
Rechtliche Grundlagen zum Datenschutz und zu elektronische Signaturen werden ebenfalls
erörtert.
Erläuterungen zu nationalen und internationalen Standards sowie deren Einbindung weisen
auf die Interoperabilität des Systems hin.
1
kurz E-Mail für engl.: Electronic Mail
2
online: http://www.idc.com
3
Wenn in dieser Diplomarbeit die maskulinen Substantive wie ‚Anwender’ oder ‚Sender’ verwendet
werden, dann sollen sie sich auf beide Geschlechter beziehen.
1

EINLEITUNG
2.2 Überblick und Aufbau der vorliegenden Arbeit
In Kapitel zwei erfolgt eine Umfeldanalyse, in der grundlegende Theorien über Kryptografie
erläutert werden und anhand von beschriebenen Standards der Gesamtkontext dargestellt
wird. Eine Beschreibung der Theorie von sicherer E-Mail und eine Darstellung der rechtlichen
Situation in der Bundesrepublik Deutschland im allgemeinen sowie in Berlin und an
der TU-Berlin im speziellen sind ebenfalls Bestandteil des zweiten Kapitels. Hierbei wird
auch auf das Datenmodell der Campuskarte eingegangen, soweit es für den vorliegenden
Kontext erforderlich ist.
Das dritte Kapitel beginnt mit einer Beschreibung bereits entwickelter sicherer E-Mail-
Produkte. Anschließend folgt eine kurze Erläuterung des Vorgehensmodells, mit dessen Hilfe
die Lösung erarbeitet wurde. Daraufhin werden die Anforderungen, die an das System gestellt
werden, genauer spezifiziert.
Der Hauptteil der Analyse bzw. des Entwurfs des gesamten sicheren E-Mail-Konzepts ist
im vierten Kapitel zusammengefasst.
Spezifizierende Beschreibungen sowie Codebeispiele werden im fünften Kapitel dargelegt.
Eine nähere Betrachtung der E-Mail-Clients und ihrer Konfiguration für den sicheren E-
Mail-Einsatz mit der Campuskarte folgt in Kapitel sechs.
Eine ausführliche Darstellung der Ergebnisse, sowie kritische Betrachtungen des Systems
sind Bestandteil des siebenten Kapitels. Mit einem Ausblick wird die Arbeit abgerundet.
Im Anhang befindet sich neben der Bibliografie u.a. ein Abkürzungsverzeichnis und ein
Glossar.
2.3 Sicherheitsbedürfnisse
Die erste Frage, die sich bei den derzeitigen, vielfältigen Computerangriffen stellt, ist die
nach einer genauen Definition der Sicherheitsbedürfnisse eines Computeranwenders.
Zu den vier wichtigsten Sicherheitsbedürfnissen gehören: Authentizität, Vertraulichkeit,
Integrität und Verfügbarkeit.
Authentizität
Authentizität bezeichnet im allgemeinen die Echtheit eines Kommunikationspartners bzw.
eines Dokuments. Dies spiegelt sich u.a. in dem Vertrauen wieder, das man den übermittelten
Daten zuspricht.
Vertraulichkeit
Vertraulichkeit bedeutet, dass Daten, die per Computer übermittelt werden, nur dem Sender
und Empfänger bekannt sein dürfen. Um Vertraulichkeit zu gewährleisten muss das Mitlesen
durch einen Dritten ausgeschlossen werden können.
Integrität
Integrität von Daten befasst sich mit deren Unveränderlichkeit. Bei einem Datenaustausch ist
es von Bedeutung, dass die Daten auf dem Weg vom Absender zum Empfänger nicht verändert
werden. „Integrität betrifft die Beziehung eines Datenelements zu sich selbst im Verlauf
der Zeit.“ (siehe [SCHN01], S. 68) Hierbei unterscheidet sich Integrität von Genauigkeit, d.h.
integre Daten müssen nicht unbedingt der Wahrheit entsprechen.
Verfügbarkeit
2

Das System zum Schutz der geheimen Daten muss jederzeit verfügbar sein. Alle Soft- und
Hardwarekomponenten müssen funktionsfähig und einsatzbereit sein, damit die Schutzmechanismen
dauerhaft eingesetzt werden können.
2.4 Das TU-Projekt „Campuskarte“
Seit Mitte 2000 bereitet die TU-Berlin die Einführung einer SmartCard vor, die als multifunktionaler
Studenten- und Dienstausweis eingesetzt werden soll. Dabei soll der volle
Funktionsumfang einer Java-basierten Chipkarte zum Einsatz kommen. Neben einem optischen
Studierendenausweis und einem Semesterticket für den öffentlichen Personennahverkehr
(ÖPNV), bietet die Campuskarteninfrastruktur Dienste über das Internet an. Zu diesen
Diensten gehören, u.a. die Rückmeldung zu einem neuen Semester, die Anmeldung zu
Prüfungen und Adressänderungen. Die Karte soll außerdem in den Bereichen der Bibliothek
und der Mensa zum Einsatz kommen. Denkbar ist auch die Möglichkeit sich, online an Wahlen
zu beteiligen.
Die Einsparung und Vereinfachung in den Verwaltungsabläufen ist eines der Ziele, die
die TU-Berlin mit der Einführung der Campuskarte verfolgt. Hierzu gehört die Möglichkeit
die Chipkartenauthentifizierung an bestehende Verwaltungsvorgänge wie die „Kosten-
Leistungs-Rechnung 4 “ und das System „Leistung in der Forschung 5 “ anzubinden.
Derzeitige Ziele sind die Schaffung von technischen und organisatorischen Infrastrukturen,
die den Einsatz der Campuskarte ermöglichen. Da das System ein hohes Sicherheitsniveau
fordert, ist außerdem ein TUB eigenes Trustcenter im Aufbau, welches die Zertifikate
und Schlüssel der Nutzer erzeugt und verwaltet.
Ein kurzer Abriss der bislang wichtigsten Meilensteine ist wie folgt zu skizzieren. Der
Projektstart war im Juli 2000, nachdem ein Rahmenpflichtenheft [RAPH00] erarbeitet wurde,
das die Ziele des Projekts verdeutlicht. Verschiedene Modellbeschreibungen, wie u.a. Anforderungsmodell
und Analysemodell folgten bis zum Jahresende. Der damalige Hauptprojektpartner
Motorola lieferte seine ersten Chipkarten im Februar 2001 aus. Mit diesen Testkarten
wurde ein System entwickelt, das am 31. Mai 2001 der Öffentlichkeit präsentiert wurde. Bis
zur zweiten Präsentation im Dezember 2001 wurde das Campuskartesystem und deren Infrastruktur
weiterentwickelt. In diesen Zeitraum fällt auch die Suche nach dem neuen Kartenlieferanten
GemPlus. Ein Zwischenschritt zu der momentan geplanten Rollout-Phase der
SmartCards, war die Einführung eines Semestertickets im Layout einer Chipkarte. Die zurzeit
laufenden Entwicklungen der Vor- und Endpersonalisierung, sowie der TUB-Trustcenter
Aktivitäten, führen zu einem neuen Meilenstein im Projekt.
4
kurz: KLR
5
kurz: LinF; Dieses System verwaltet erbrachte Leistungen (u.a. Lehrveranstaltungen und Diplomarbeitsbetreuungen)
von Lehrkräften
3

3 Umfeldanalyse und theoretische Grundlagen
Die Themen dieses Kapitels handeln von grundlegenden Theorien der Verschlüsselungs- und
Sicherheitssoftware. Neben den erwähnten Standardbeschreibungen, die bei der praktischen
Lösung zum Einsatz kommen, wird auch ein Einblick in den gesetzlichen Rahmen und in die
Campuskarteninfrastruktur gegeben.
Im Rahmen der Arbeit wird häufig von PKI gesprochen. Die Abkürzung PKI steht für
Public Key Infrastructure. Mit ihr wird ein System beschrieben, dass es Computeranwendern
ermöglicht, sicher über Datennetze kommunizieren zu können. Die Infrastruktur besteht aus
verschiedenen Teilkomponenten, u.a. den Endanwendern, den Zertifikaten und der Zertifizierungsstelle.
Als konkretes Beispiel wird in dieser Arbeit das TUB-Trustcenter und die
Campuskarteninfrastruktur beschrieben.
3.1 Kryptografie
Kryptografie ist das Gebiet der Wissenschaft, das sich mit der Ver- und Entschlüsselung von
vertrauenswürdigen Daten beschäftigt. Sie baut in der heutigen Informationsgesellschaft auf
mathematische Verfahren auf, die u.a. Computerdaten schützen können.
Geheimschriften sind schon seit dem 5. Jahrhundert v. Chr. bekannt und halfen vertrauliche
Informationen während Fehden zwischen Griechenland und Persien zu übermitteln. Der
verschlüsselte Datenaustausch z.Z. der zwei Weltkriege führte dazu, dass das Gebiet der
Kryptografie Einzug in heutige moderne Wissenschaften, wie Mathematik und Informatik,
fand. Als Beispiel kann die Chiffriermaschine Enigma genannt werden (näheres siehe
[SING00]).
3.1.1 Symmetrische Verfahren
Bei einem symmetrischen Verschlüsselungsverfahren wird mit dem g l e i c h e n - einem geheimen
- Schlüssel bei der Ver- und bei der Entschlüsselung gearbeitet. Der zu verschlüsselnde
Text wird mit einem nur den zwei Teilnehmern des Datenaustausches bekannten
Schlüssel in der Weise kombiniert, dass ein kryptischer Text entsteht, der ohne Entschlüsselung,
nicht gelesen werden kann. Der Partner, der den verschlüsselten Text erhält, ist auch im
Besitz des geheimen Schlüssels. Er kann den verschlüsselten Text mit dem geheimen
Schlüssel in der Weise kombinieren, dass wieder ein Klartext aus der Nachricht entsteht.
Bei dieser kryptografischen Methode ist es von entscheidender Bedeutung, dass nur der
Sender und der Empfänger im Besitz des Schlüssels sind. Sollte eine dritte Person den
Schlüssel vorliegen haben, so kann sie die geheime Nachricht entschlüsseln und lesen.
Ein weiteres Problem dieser Methode ist, dass sich die beiden Kommunikationspartner
auf einen Schlüssel verständigen müssen, d.h. es muss beiden vor der Übertragung klar sein,
welcher Schlüssel benutzt wird. Durch diesen Informationsaustausch entstehen weitere Sicherheitsrisiken.
Gängige symmetrische Algorithmen sind u.a. DES (Data Encryption Standard), 3DES,
IDEA (International Data Encryption Algorithm), Blowfish und der kürzlich entwickelte AES
(Advanced Encryption Standard), der als Nachfolger des DES-Standards eingesetzt wird.
Die Abbildung 2-3.1 zeigt dieses Verfahren, bei der man erkennt das bei beiden
Methoden der geheime Schlüssel SK (engl.: Secret Key) angewendet wird, d.h. es wird die
Nachricht M (engl.: Message) mit dem selben Schlüssel Ver- (E für engl.: Encrypted) und
Entschlüsselt (D für engl.: Decrypted). Cipher steht für den kodierten Text.
4

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
Message E SK
(M) Cipher D SK
(C) Message
3.1.2 Asymmetrische Verfahren
Abbildung 2-3.1: Symmetrische Verschlüsselung
Durch das asymmetrische Verschlüsselungsverfahren werden einige im vorigen Abschnitt
angesprochene Sicherheitsrisiken umgangen, da bei dieser Methode unterschiedliche Schlüssel
zum Ver- bzw. Entschlüsseln eingesetzt werden. Die zwei Schlüssel werden mit als
„öffentlich“ und „privat“ bezeichnet.
Das mathematische Verfahren, welches hinter dieser Methode steckt, ermöglicht es eine
Nachricht, mit dem öffentlichen Schlüssel des Empfängers zu verschlüsseln. Dieser Schlüssel
ist in der Regel öffentlich zugänglich und darf jedem bekannt sein, deshalb auch die Bezeichnung
„öffentlich“.
Die verschlüsselte Nachricht kann nun an den Empfänger übermittelt werden, der diese wiederum
nur mit seinem „privaten“ Schlüssel entschlüsseln kann.
Bei dieser Methode müssen sich die Kommunikationspartner auf ein Schlüsselpaar einigen.
Anders als bei der symmetrischen Verschlüsselung ist der Schlüssel der zum Verschlüsseln
benutzt wird nicht geheim, nur der Schlüssel beim Empfänger, sein privater, darf nicht
herausgegeben werden.
Die bekannteste asymmetrische Verschlüsselungsmethode ist RSA, benannt nach ihren
Erfindern: Ron Rivest, Leonard Adleman und Adi Shamir. Sie wurde in den 70er Jahren des
letzten Jahrhunderts entwickelt, und basiert auf dem mathematischen Prinzip der Primfaktorzerlegung.
Aufgrund der Verschlüsselungstechnik kann man die Länge von symmetrischen
mit asymmetrischen Schlüsseln nicht zum Qualitätsvergleich heranziehen. Ein anderer
asymmetrischer Algorithmus ist z.B. DH (Diffie-Hellmann), der sich aber nur in Kombination
mit einem digitalen Signaturverfahren, wie DSS 6 , anwenden lässt. Die Verschlüsselung
mit elliptischen Kurven (ECC 7 ), setzt auf neuere mathematische, zum Teil geometrische,
Verfahren. Beim Einsatz einer Public Key Infrastructure wird mit dem asymmetrischen Konzept
gearbeitet.
Die Abbildung 2-3.2 verdeutlicht diese Verschlüsselungsmethode, bei der eine Nachricht
mit dem öffentlichen Schlüssel (PubKey für engl.: Public Key) verschlüsselt wird. Der daraus
erhaltene kodierte Text kann nur mit dem privaten Schlüssel (PrivKey für engl.: Private Key)
des Empfängers entschlüsselt werde, um wieder die Nachricht zu erhalten.
Es ist auch möglich eine Nachricht mit dem privaten Schlüssel zu verschlüsseln und mit
dem öffentlichen wieder zu entschlüsseln. Die Daten sind dann aber nicht geschützt, weil der
öffentliche Schlüssel „jedem“ bekannt ist. Diese umgekehrte Methode wird allerdings bei
elektronischen Signaturen angewendet.
6
steht für „Digital Signature Standard“
7
steht für „Elliptic Curve Cryptography“
5

Message E PubKey
(M) Cipher D PrivKey
(C) Message
3.1.3 Hybride Verfahren
Abbildung 2-3.2: Asymmetrische Verschlüsselung
Das hybride Verschlüsselungsverfahren sieht vor, die symmetrische und asymmetrische Methode
zu kombinieren. Da bei der asymmetrischen Methode lange Schlüssellängen auftreten
und dadurch ein Ver- und Entschlüsselungsvorgang durch hohen Rechenaufwand lange dauern
kann, wird bei der hybriden Variante die Nachricht mit einem kurzen symmetrischen
„geheimen“ Schlüssel (SK) verschlüsselt, z.B. ein DES-Schlüssel.
Der geheime Schlüssel wiederum wird mit einem „öffentlichen“ Schlüssel des Empfängers
verschlüsselt und mit der gesendeten Nachricht mitgeschickt. Auf diese Weise hat der
Empfänger nach der Entschlüsselung des geheimen Schlüssels, mit Hilfe des privaten Schlüssels,
die Möglichkeit die verschlüsselte Nachricht mit dem symmetrischen Schlüssel zu entschlüsseln.
Diese Methode bietet einen geringeren Rechenaufwand als das asymmetrische
Verfahren und gleichzeitig deren Vorteile, d.h. der geheime Schlüssel muss vor der sicheren
Kommunikation n i c h t ausgetauscht werden.
Die Abbildung 2-3.3 verdeutlicht den Einsetzen von zwei Methoden. Es müssen zwei
Daten an den Empfänger übermittelt werden die kodierte Nachricht (Cipher von Message)
und der verschlüsselte geheime Schlüssel (Cipher vom Secret Key).
Message
E SK
(M)
Cipher von
Message
D SK
(C)
Message
E PubKey
(SK)
D PrivKey
(SK)
Cipher vom
SecretKey
3.1.4 Hashfunktionen
Abbildung 2-3.3: Hybride Verschlüsselung
Hashfunktionen bieten die Möglichkeit Daten in der Weise auf einen kleineren Wert abzubilden,
dass ein Ergebniswert resultiert, der nur mit den vorhandenen Daten erzielt werden kann.
Bei einem guten Hashwertalgorithmus ist der Hashwert 8 für jeden Eingabewert anders, und
damit eindeutig. Außerdem lassen sich anhand eines Hashwertes keine Rückschlüsse auf die
Eingabedaten ziehen. Diese Methode wird bei elektronischen Signaturen eingesetzt.
8
wird auch als Prüfsumme oder Kondensat bezeichnet
6

3.2 Digitale Unterschriften
UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
Ein zweiter großer Forschungsbereich in Zusammenhang mit elektronischer Kryptografie
widmet sich dem Erzeugen und Prüfen von digitalen Signaturen.
3.2.1 Signaturen
Um ein elektronisches Dokument digital zu signieren, wird mittels einer Funktion, z.B.
SHA-1, ein Hashwert gebildet, der z.B. an eine E-Mail mit angehangen wird.
Der Empfänger ist nun in der Lage, mittels der gleichen Hashfunktion den Hashwert der
Nachricht erneut zu erzeugen. Sollten die beiden Hashwerte identisch sein, ist davon auszugehen
das die Nachricht auf dem Übertragungsweg nicht verändert wurde, denn für jede Veränderung
innerhalb der Nachricht würde die Hashfunktion einen anderen Wert berechnen.
Damit der Empfänger sicher sein kann, dass die Nachricht vom angegebenen Sender
stammt, verschlüsselt dieser mit seinem privaten Schlüssel die Prüfsumme.
Damit der Empfänger die zwei Hashwerte vergleichen kann wird zunächst die Prüfsumme
mit dem öffentlichen Schlüssel entschlüsselt. Dies ist notwendig, weil man eindeutig nachweisen
möchte, von wem die Nachricht stammt. Die Integrität der Nachricht ist dank der
Eindeutigkeit des Hashwertes auch gesichert.
Das Datenpaket aus Nachricht und verschlüsselter Signatur wird nach den Standards
PKCS#7 und S/MIME zusammengesetzt.
Wegen der Äquivalenz zur herkömmlichen Unterschrift spricht man bei diesem Verfahren
auch von einer elektronischen oder digitalen Signatur (bzw. Unterschrift).
Es stellt sich die Frage, wie der Empfänger sicher sein kann, dass er die Nachricht mit dem
öffentlichen Schlüssel des Senders verifiziert. Als Lösung für dieses Problem kommt der
Einsatz von Zertifikaten zu tragen.
Vorteile einer digitalen Signatur:
Daten können nicht verfälscht werden.
Die digitale Signatur ist nicht fälschbar.
Die digitale Signatur ist einfach prüfbar.
Die digitale Signatur ist nicht abstreitbar.
Bedingungen die für die Sicherheit erfüllt werden müssen:
Der private Schlüssel muss sicher verwahrt werden.
Die verwendeten Verfahren müssen sicher sein.
Bei der Schlüsselerzeugung müssen gute Zufallszahlen verwendet werden.
Die Zertifizierungsstelle muss sicher vorgehen.
Die Signaturumgebung muss sicher sein.
Eine sichere und unverfälschte Darstellung der Daten muss gewährleistet werden.
Mit der Abbildung 2-3.4 wird verdeutlicht, wie eine digitale Signatur gebildet wird. Beim
ersten Schritt wird eine Prüfsumme (CS für engl.: Checksum) gebildet, der dann im zweiten
Schritt mit dem privaten Schlüssel verschlüsselt (E PrivKey (CS)) wird, diese Signatur (engl.:
Digital Signature) wird dann an die Nachricht (Message) angehangen und verschickt.
7

In Abbildung 2-3.5 wird der Vorgang des Verifizierens veranschaulicht. Hierbei wird
wiederum die Prüfsumme über die Nachricht gebildet, die mit der entschlüsselten
übertragenen Prüfsumme verglichen wird. Sollten die Werte übereinstimmen ist die Signatur
der Nachricht korrekt verifiziert worden. Bei Ungleichheit gilt die Signatur der Nachricht
nicht.
Message
Message H(M) Checksum E PrivKey
(CS)
Digital Signature
(encrypted)
Digital Signature
(encrypted)
Abbildung 2-3.4: Erzeugen einer Digitalen Signatur
Message
H(M)
Checksum
=?
Digital Signature
(encrypted)
D PubKey
(DS)
Checksum
3.2.2 Zertifikate
Abbildung 2-3.5: Prüfen einer Digitalen Signatur
Mit einem Zertifikat wird ein öffentlicher Schlüssel vertrauensvoll an eine Person gebunden.
Dieses Vertrauen wird durch die unterzeichnende Instanz gewährleistet, welche die Zertifikate
ausstellt. D.h. es wird der öffentliche Schlüssel mit Zusatzinformationen des Trägers,
u.a. Name und E-Mail-Adresse, digital signiert. Im vorliegenden Fall ist die dritte Stelle, das
im nächsten Kapitel beschriebene TUB-Trustcenter. Damit wird einem Sender das Vertrauen
gegeben, dass ein öffentlicher Schlüssel auch zu der Person gehört, für die er die E-Mail verschlüsselt.
Zertifikate enthalten im allgemeinen einen eindeutigen Namen des Besitzers, Angaben
über den Aussteller, sowie Details über die Kryptografie-Algorithmen.
Der genaue Aufbau von Zertifikaten wird in Kapitel 3.10.4 beschrieben.
3.3 Aufbau des TUB-Trustcenters
Bei der Zuordnung von „öffentlichen“ Schlüsseln zu Personen stellt sich die Frage der vertrauenswürdigen
Zugehörigkeit dieser beiden Komponenten. Wie kann man als Anwender
sicher sein, seinem Gegenüber zu vertrauen. In der PKI haben sich deshalb zwei Schemata
herausgebildet, welche dieses Vertrauen schaffen sollen. Das ist zum einen das sogenannte
8

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
TrustedWeb, d.h. das Vertrauen wird durch einzelne Benutzer, die sich untereinander gegenseitig
zertifizieren, realisiert.
Beim anderen Ansatz, den u.a. auch die TU-Berlin verfolgt, geht man von e i n e r vertrauenswürdigen
obersten Instanz aus. Dieser Instanz sind weitere sogenannte Certification
Authorities (kurz CA) untergeordnet, die dann u.a. auch die Zertifikate mit öffentlichen
Schlüsseln für die Endnutzer ausstellen. Jede in diesem Baum gelegene Zertifizierungsinstanz
wird von übergeordneten CA zertifiziert. Um ein Zertifikat eines Endnutzers zu verifizieren,
und damit trauen zu können, muss man als Nutzer die gesamte Hierarchie der
Zertifizierungskette verifizieren. Hierfür ist eine Kette von Zertifikaten notwendig, an deren
Ende das selbstsignierte Wurzel (engl.: root) CA-Zertifikat steht. Um das Vertrauen in eine
Root-CA zu gewährleisten wird der Fingerprint 9 des Root-Zertifikats veröffentlicht, den jeder
Endanwender nachprüfen kann.
Die Abbildung 2-3.6 verdeutlicht die Baumstruktur der einzelnen CAs. Neben der
Personen-CA gibt es u.a. noch die Object-CA, welche Zertifikate für generierten
Programmcode ausstellt.
DFN-PCA TUB-CA
Infrastruktur-CA TUB-E-Mail-CA Externe-CA
TUB-Server-CA
TUB-Object-CA
Personen-CA
Endnutzerzertifikat
Abbildung 2-3.6: TUB-CA-Baum
3.3.1 TUB-CA
Die Wurzelzertifizierungsinstanz TUB-CA des Trustcenters ist diejenige Instanz, die den
unter ihr liegenden CAs ihre Vertrauenswürdigkeit ausspricht. Die TUB-CA ist mit einem
selbst signierten Zertifikat (Self-Sign-Certificate) ausgestattet, mit dem sie andere Certification
Authorities signieren kann. Der private Schlüssel, mit dem die anderen CAs signiert
werden, ist ein höchst schützenswertes Gut, das unter k e i n e n Umständen bekannt werden
darf, weil damit das gesamte System kompromittiert wäre und es z.B. möglich wäre sich als
ein Angreifer sonst eigene vertrauenswürdige Zertifikate ausstellen könnte. Deshalb ist der
Zugang zum TUB-Trustcenter auch durch hohe Sicherheitsmechanismen geschützt.
Die Root-CA signiert u.a. die Zertifikate der Personen-CA und der Server-CA. Dies sind
untergeordnete CAs, die wiederum Endnutzerzertifikate signieren, welche an Personen und
Applikationsserver ausgegeben werden.
Um ein Zertifikat auf seine Gültigkeit verifizieren zu können, muss die gesamte Zertifikatskette
mit einbezogen werden, d.h. jedes Zertifikat wird von dem Zertifikat der übergeordneten
Instanz geprüft.
9
Mit Fingerprint (zu deutsch: Fingerabdruck) wird der Hashwert bezeichnet, der über ein Zertifikat
gebildet wurde. Er ist nicht signiert. Er wird z.B. in Zeitungen veröffentlicht.
9

3.3.2 Personen-CA
Die Endanwender im Campuskartenprojekt, u.a. Studenten und Mitarbeiter der Universität,
haben zwei bzw. drei für sie ausgestellte Personenzertifikate. Die Aufgaben der einzelnen
Zertifikate werden in einem späteren Abschnitt noch genauer betrachtet.
Für die Ausstellung dieser Zertifikate ist die Personen-CA zuständig. Sie ist die Instanz,
die einen vertrauenswürdigen Bezug zwischen ausgestelltem Zertifikat und Endnutzer herstellt.
In dem Zertifikat sind u.a. Name, E-Mail-Adresse und Abteilung angegeben. Zu jedem,
von der Personen-CA ausgestelltem Zertifikat, wird ein privater Schlüssel erzeugt. Von den
privaten Komponenten der Verschlüsselungsschlüssel der TUB-Mitarbeiter wird ein Backup
im Archivraum des Trustcenters der TU-Berlin sicher verwahrt.
Um die Anbindung an andere Zertifizierungsstellen zu erlauben, besteht für die Personen-
CA die Möglichkeit der Cross-Zertifizierung mit anderen CAs.
Sollte ein Nutzerzertifikat abhanden gekommen oder kompromittiert worden sein, ist das
Trustcenter der TU-Berlin in der Lage, dieses Zertifikat auf einer Widerrufsliste („Certificate
Revocation List“, kurz CRL) zu veröffentlichen, damit es von anderen Nutzern als ungültig
erkannt werden kann. Diese CRL wird von der Personen-CA signiert. Einmal widerrufene
Zertifikate können niemals erneuert, wieder entsperrt oder verlängert werden.
Alte CRLs werde archiviert, um die Gültigkeit von Zertifikaten auch zu einem späteren
Zeitpunkt verifizieren zu können.
Auf einem vom Trustcenter bereitgestelltem Verzeichnisdienst wird mindestens einmal
pro Woche eine aktuelle CRL der TUB-Personen-CA veröffentlicht.
3.4 Gesetzlicher Hintergrund
Der Gesetzgeber sieht vor, dass personenbezogene Daten vertraulich und geheim behandelt
werden müssen. Dazu dienen die Datenschutzgesetze von Bund und Ländern. Im folgenden
wird ein kurzer Überblick über die gesetzliche Situation in Deutschland und Berlin gegeben.
Die Umsetzung an der Technischen Universität Berlin erfolgt durch Dienstvereinbarungen,
die jedem Mitarbeiter bestimmte Verhaltensweisen auferlegen, um einen vertrauenswürdigen
Rahmen für persönliche Daten zu schaffen.
3.4.1 Bundesdatenschutz- und Signaturgesetz
Das Bundesdatenschutzgesetz (BDSG, siehe [BDSG02]) beschreibt die rechtliche Grundlage,
die im Umgang mit personenbezogenen Daten in öffentlichen und nicht-öffentlichen Stellen
zu treffen sind, damit das Recht auf Privatsphäre für jeden einzelnen gewährleistet ist.
Das Signaturgesetz (SigG, siehe [SIGG01]) unterscheidet fortgeschrittene, qualifizierte
und akkreditierte Zertifizierungsstellen und damit auch Zertifikate. Das SigG ist die Umsetzung
einer EU-Richtlinie. Das Trustcenter der TU-Berlin ist als fortgeschrittene Zertifizierungsinstanz
zu sehen.
In §3 des Signaturgesetzes wird eine zuständige Behörde definiert, die für die Erteilung
von Lizenzen, der Ausstellung von Zertifikaten sowie die Überwachung des Signaturgesetzes
eingesetzt wird. Das Bundesamt für Sicherheit in der Informationstechnik 10 (BSI) hat diese
Aufgaben.
Im §16 Absatz 5 der Signaturverordnung (SigV, siehe [SIGV01]) wird gefordert, dass die
zuständige Behörde eine Übersicht im Bundesanzeiger veröffentlicht, in der sie die geeigneten
Algorithmen und Parameter, die u.a. zum Hashen zu signierender Daten und zur Erzeugung
und Prüfung von digitalen Signaturen als geeignet angesehen werden.
10
siehe [BSINFO]
10

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
In Punkt 2 der Veröffentlichung 11 vom 24. August 2001, werden als geeignete 160-Bit
Hashfunktionen die folgenden aus der MD4-Familie angegeben:
RIPEMD-160
SHA-1
Diese beiden Hashfunktionen werden durch die Veröffentlichung in einem Zeitraum bis Ende
2005 als für die Anwendung der digitalen Signatur als geeignet eingestuft.
Als geeignete Signaturalgorithmen werden die folgenden in Punkt 3 angegeben:
RSA
DSA
DSA-Varianten, basierend auf elliptischen Kurven
Eine Bitlänge von 1024 für den Modulus eines RSA-Schlüssels wird bis Mitte 2006 als sicher
eingestuft.
3.4.2 Berliner Datenschutzgesetz
Das Berliner Datenschutzgesetz (BlnDSG) schreibt den Schutz vor, den personenbezogene
Daten im Bereich der Behörden und öffentlichen Stellen des Landes Berlin genießen müssen.
Das Gesetz liegt in der aktuellen Fassung seit dem 5.August 2001 novelliert vor. Näheres
siehe [BLNDSG].
3.4.3 Dienstvereinbarungen der TU-Berlin
In dem Dokument [DTUE98] vom 12. Juni 1998 wird über die Vereinbarungen informiert,
die für das Arbeiten und den Einsatz von Elektronischer Post für TUB-Angestellte getroffen
wurden.
Es wird darin festgelegt, dass elektronische Post „wie normale schriftliche Dienstpost
behandelt“ wird (unter 1.). Unter Punkt 3 „Personenbezogene Daten“ wird deutlich gemacht,
dass „Elektronische Post unter Beachtung der geltenden Rechtsvorschriften, insbesondere
eines anforderungsgerechten und detaillierten Datenschutz- und Datensicherheitskonzeptes,
auch für die Übertragung von Dokumenten mit personenbezogenem Inhalt genutzt werden
kann.“
In Anlage 3 des Dokuments wird das „Versenden von Schreiben, die personenbezogene
Daten enthalten, insbesondere Studenten- und Arbeitnehmerdaten“ nur in verschlüsselter
Form als zulässig eingestuft. Unverschlüsselt dürfen folgende Schreiben verschickt werden:
Formulare, Merkblätter, Ausschreibungen, Veröffentlichungen, etc.
3.4.4 TUB-Sicherheitskonzept für sichere E-Mail
Bevor ein neues Softwaresystem in der TUB-Verwaltung zum Einsatz kommt, müssen seine
Risiken und Lösungsansätze in einem Sicherheitskonzept dargelegt werden. Als Basis gilt die
Zusammenstellung von Gefahren und Maßnahmen des Bundesamtes für Sicherheit in der
Informationstechnik.
11
Veröffentlichung im Bundesanzeiger Nr. 158 – Seite 18.562
11

3.5 Datenmodell der Campuskarte
Neben den Anwenderdaten, wie Statusgruppe, Gültigkeitszeitraum oder Applikationsprofil,
sind auf der Campuskarte Schlüssel und Zertifikate für kryptografische Operationen gespeichert,
auf die durch entsprechende Funktionen zugegriffen werden kann.
Das Datenmodell sieht für Dienstausweise drei Zertifikate und die dazugehörigen Schlüssel
auf der Campuskarte vor. Das Dokument [SUHR00] beschreibt das Datenmodell und ihre
Zugriffrechte genau, ein Auszug folgt in einem späteren Absatz.
Die Zertifikate auf der Karte
Es ist vorgesehen auf der Campuskarte unterschiedliche Zertifikate für verschiedene Aufgaben
mit ihren privaten Schlüsseln zu speichern. Dies sind im einzelnen folgende.
Signatur-Zertifikat
Für den Vorgang des elektronischen Signierens bzw. Verifizierens von Daten ist auf der
Campuskarte ein separates Zertifikat mit dazugehörendem privaten Schlüssel vorgesehen.
Verschlüsselungs-Zertifikat
Der Vorgang der elektronischen Ver- und Entschlüsselung wird mit beim Dienstausweis
durch ein separates Zertifikat mit entsprechendem privaten Schlüssel ausgeführt.
Authentisierungs-Zertifikat
Für den Authentisierungsvorgang gegenüber dem System ist auf der Campuskarte ein separates
Zertifikat mit dazugehörendem privaten Schlüssel vorgesehen.
Es folgt in Auszügen eine Auflistung von Daten der Campuskarte und deren Zugriffsberechtigungen
(siehe [SUHR00]).
mögliche Methoden Karteninhaber
Zertifikat Karteninhaber Encrypt (CHE) cwrv rv
Zertifikat Karteninhaber Sign (CHS) cwrv rv
Statusgruppe (PS) cwr r
Geheimer Schlüssel Encrypt (SKE) cwd d
Geheimer Schlüssel Sign (SKS) cs s
Tabelle 2-3.1: Campuskarten Datenmodell
Legende: c: Initialisierung, w: schreiben, r: lesen, v: verfizieren, s: signieren,
d: entschlüsseln
Unterschied von Studierenden- und Dienstausweisen
Ein zentraler Unterschied zwischen den Studierenden- und den Dienstausweisen ist die Anzahl
der Zertifikate im Datenmodell. Studierende haben nur zwei Zertifikate auf der Karte.
Eines mit dem sie sich authentifizieren können und ein zweites mit dem sie Signaturen u n d
Verschlüsselungen vornehmen.
Hier liegt der Unterschied zu den Mitarbeitern, bei ihnen gibt es zwei getrennte Zertifikate,
jeweils eines für Signatur- und Verschlüsselungsvorgang. Dies ist notwendig, da Daten
anfallen können, die nach dem Ausscheiden des Mitarbeiters aus dem Arbeitsumfeld noch
entschlüsselt werden können. Dies soll unabhängig von der gegebenen Signatur durchführbar
12

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
sein. Dafür wird der SKE (Geheimer Schlüssel Encryption, siehe Tabelle 2-3.1) eines
Mitarbeiter als Backup auf einem Rechner des Trustcenters hinterlegt.
Auch aus rechtlichen Gründen, gibt es von den privaten Schlüsseln der Studierenden
keine Sicherheitskopie.
3.6 Common Criteria
Der genaue Titel der Common Criteria lautet “Gemeinsame Kriterien für die Prüfung und
Bewertung der Sicherheit von Informationstechnik” 12 . Sie liegt seit 1998 in Version 2 vor und
wird als ISO-Standard 15408 geführt. Neben den Staaten Frankreich, Großbritannien,
Kanada, den Niederlanden und den USA wirkte als deutsche Vertretung das BSI bei der Zusammenstellung
dieses Kriterienkataloges mit.
Die Common Criteria stellt eine Weiterentwicklung und ein Angleichen der europäischen
(ITSEC), der US-amerikanischen (Orange-Book, TCSEC) und der kanadischen (CTCPEC)
Kriterien zur Bewertung der Sicherheit bei Informationssystemen dar. Weitere Informationen
befinden sich unter: http://www.commoncriteria.org.
Die Common Criteria 13 gliedert sich in folgende drei Teile:
1. Einführung und allgemeines Modell
2. Funktionale Sicherheitsanforderungen
3. Anforderungen an die Vertrauenswürdigkeit
3.7 ITSEC
ITSEC steht für “Information Technology Security Evaluation Criteria” und wurde am 3.
März 1998 auf europäischer Ebene in Kraft gesetzt. Die Evaluierung mittels ITSEC 14 von IT-
Sicherheitskriterien wird in Funktionalität und Vertrauenswürdigkeit unterschieden. Dabei
wird die Vertrauenswürdigkeit auf Korrektheit und Wirksamkeit hin untersucht. Die
Wirksamkeit wird in niedrig, mittel und hoch eingestuft und die Korrektheit in
Evaluationsstufen von E1 bis E6. Die Evaluierung eines IT-Sicherheitsproduktes beinhaltet
Prüfung und Bewertung. Hierfür liegt das Evaluationshandbuch „Information Technology
Security Evaluation Methodology – ITSEM" vor.
3.8 E-Mail-Standards
Neben den Erläuterungen zum eingesetzten S/MIME Standard, wird auch kurz auf parallel
existierende sichere Mail-Standards eingegangen.
3.8.1 S/MIME
S/MIME steht für “Secure Multipurpose Internet Mail Extension”. Es ist eine Erweiterung
des MIME-Standards, der den Aspekt Sicherheit mit einbringen soll. Die Nachrichten Spezifikation
der aktuellen Version 3 des Standards wird in RFC 15 2633 definiert, die dazugehörige
Zertifikatverwaltung in RFC 2632.
12
engl.: Common Criteria for Information Technology Security Evaluation
13
weitere Informationen befinden sich online unter: http://www.commoncriteria.org.
14
Infos sind online unter http://www.bsi.de/zertifiz/itkrit/itsec.htm abrufbar.
13

S/MIME ist neben OpenPGP das Sicherheitsprotokoll, dass um die Gunst der IETF 16
konkurriert. Bei der Entwicklung wurde von bei dem Standard von Beginn an auf MIME
-Kompatibilität geachtet. Dadurch, dass S/MIME auch auf den patentrechtlich geschützten
Standards RSA und dem früher geheimen Algorithmus RC2 aufbaut, wurde es noch nicht
zum ITEF-Standard erhoben.
In der aktuellen Version 3 wurde darauf geachtet auch auf Verfahren wie DSA, Diffie-
Hellman zurückzugreifen.
S/MIME basiert im Gegensatz zu PGP auf PKIX 17 -Zertifikaten, d.h. es wird eine Trusted
Third Party eingesetzt um Vertrauen zu gewährleisten.
Die Produkte von Netscape und die Varianten von Microsoft Outlook unterstützen den
S/MIME-Standard.
3.8.2 PEM
PEM beschreibt ein Sicherheitsprotokoll für Elektronische Post. Die Abkürzung PEM steht
für „Privacy Enhanced Mail“ und wird in den RFCs 1421-1424 beschrieben. RFC 1421 beschreibt
die Nachricht Prozess Prozeduren. Das zweite Dokument RFC 1422 definiert das
Public-Key Zertifikats Management, das für PEM verwendet wird. RFC 1423 beschreibt die
Algorithmen- und Identitätsdefinitionen. Das vierte Dokument RFC 1424 definiert Nachrichtenformate
und Konventionen für die Benutzerregistrierung und u.a. den Einsatz von
CRLs (Certificate Revokation Lists).
3.8.3 PGP
Die Abkürzung “PGP” steht für „Pretty Good Privacy“ (zu deutsch „Ziemlich Gute
Privatsphäre“). Es beschreibt einen E-Mail-Verschlüsselungs-Standard, der von Philipp
Zimmermann entwickelt wurde, mit der Absicht einer breiten Öffentlichkeit sicheren E-Mail-
Verkehr zu ermöglichen. PGP ist u.a. als kostenlose OpenSource-Software für unterschiedliche
E-Mail-Clients erhältlich. Das Verfahren hinter der Öffentlichen Schlüsselverteilung
basiert bei PGP auf der Idee des Trusted Web. Das Message Exchange Format für
PGP wird in RFC 1991 beschrieben.
Eine PGP-Erweiterung für den E-Mail-Client MS Outlook ist auf dem Markt erhältlich.
3.9 MailTrusT
Die von der Vereinigung TeleTrust 18 Deutschland in Auftrag gegebene Spezifikation Mail-
TrusT (MTT) hat sich zum Ziel gesetzt, eine Basis zu schaffen, auf die sich Hersteller von
Sicherheitskomponenten beziehen können. Das Ziel ist es Software für sichere E-Mail und
sicheren elektronischen Dokumentenaustausch zu entwickeln, die interoperabel ist.
Dieser Standard ist notwendig, weil sich proprietäre Lösungen im Kommunikationsbereich
kaum mehr durchsetzen lassen.
An dem Projekt sind neben deutschen Unternehmen und Institutionen auch Entwickler
und Hersteller aus dem Ausland vertreten.
15
RFC bedeutet „Request For Comments“ und steht für eine Sammlung von Informatik-
Quasistandards, mit denen überwiegend wichtige und zum Teil skurrile Protokolle und
Datenstrukturen definiert werden. Sie genießen dennoch ein verbindliches Ansehen.
16
steht für „Internet Engeneering Task Force“
17
Bezeichnung für Public Key Infrastructures, die mit X.509-Zertifikaten arbeiten
18
Infos online unter: http://www.teletrust.de
14

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
Die MailTrusT-Spezifikation schafft keine neuen Standards, sondern kombiniert schon
bestehenden Spezifikationen zu einem gemeinsamen Bild. Es wird u.a. auf S/MIME, X.509
und PKCS#11 zurückgegriffen. Neben den Formaten für den Dokumentenaustausch werden
auch Richtlinien gesetzt, die die Zertifizierungsinfrastruktur mitsamt Sperrlisten und
Zertifikate und Anbindung einer PSE beschreiben.
3.10 Kryptografie- und Zertifikatstandards
Die angesprochenen Verschlüsselungs- und Signaturmethoden werden durch internationale
Standardisierungen für den privaten und wirtschaftlichen Markt festgelegt. Es folgt ein kurzer
Überblick über die derzeit eingesetzten und wichtigsten Kryptografiestandards, sowie eine
Einordnung dieser in eine Public Key Infrastruktur, die mit Zertifikaten arbeitet.
3.10.1 RSA
Das asymmetrische Verfahren RSA (im Jahre 1978 am MIT vorgestellt) besitzt die Fähigkeit
der Verschlüsselung und in Verbindung mit einem Hashalgorithmus die der digitalen Signatur.
Um das Verfahren nutzen zu können werden zuerst zwei etwa gleich lange Primzahlen (p
und q) miteinander multipliziert. Dies ergibt den Modulus n. Anschließend wird die Eulersche
Totientenfunktion (n) berechnet. Weil p und q Primzahlen sind, ergibt sich
(n) = (p-1)(q-1).
Nun folgt die Berechnung der öffentlichen Komponente e und der geheimen Komponente
d, mit
ed = 1 mod (n).
Das Zahlenpaar e und n bildet den öffentlichen und das Zahlenpaar d und n den geheimen
Schlüssel. Die Primzahlen p und q können gelöscht werden, dürfen aber niemals bekannt
werden.
Um Daten zu verschlüsseln, werden sie in Datenblöcke M kleiner dem Modulus n zerlegt.
Die Formel zur Erzeugung des Schlüsseltextes C ist
C = M e mod n.
Um die einzelnen Blöcke des Schlüsseltextes C wieder zu entschlüsseln, wendet man die
Formel
M = C d mod n
an. Es ist anzumerken, dass bei digitale Signaturen die Daten mit d verschlüsselt und mit
e wieder entschlüsselt werden.
Seine Sicherheit zieht die Methode aus zwei mathematischen Problemen. Zum einen ist
die Faktorisierung in zwei Primzahlen rechnerisch nur sehr aufwendig zu lösen, zum anderen
ist es das diskrete Logarithmusproblem, mit deren Hilfe man aus dem öffentlichen Schlüssel
und einem Klartext den privaten Schlüssel berechnen könnte.
Wie bereits erwähnt benutzt man derzeit Moduluslängen von mindestens 1024 besser
2048 Bit, um nichtmilitärische Daten hinreichend zu schützen.
15

3.10.2 3DES
Der bekannteste symmetrische Verschlüsselungsalgorithmus DES ist international als Quasistandard
anzusehen und ist als ANSI-Standard normiert. Es handelt sich um eine Produktverschlüsselungsmethode
(engl.: product cipher), bei der die elementaren Operationen Substitution
und Permutation Verwendung finden. Außerdem findet bei der Verschlüsselung auch
eine Blockverschlüsselung (engl.: block cipher) statt. Klartext und Ciphertext sind bei DES
gleich lang.
Die Schwäche des DES-Algorithmus liegt in der kurzen Schlüssellänge von nur 56 signifikanten
Bits. Deshalb gibt es u.a. die Erweiterung 3DES (sprich: Triple-DES), die mit zweifacher
oder dreifacher Schlüssellänge, aber dem gleichen Algorithmus arbeitet. Bei dieser
Methode wird ein Block zwei- oder dreimal mit verschiedenen Schlüsseln chiffriert. Die
Länge von symmetrischen Schlüsseln ist im Vergleich zu asymmetrischen Schlüsseln deutlich
kürzer.
3.10.3 SHA-1 mit RSA
SHA-1 (Secure-Hash-Algorithm) arbeitet mit einem Hashwert von 160 Bit und bietet einen
größeren Schutz gegen Brute-Force-Attacken 19 als die Hashwertfunktionen, die mit 128 Bit
arbeiten.
SHA-1 wurde im Zusammenhang mit DSS (Digital Signature Standard) von der NSA 20
und dem NIST 21 entwickelte. Zur Zeit sind keine kryptografischen Attacken gegen SHA-1
bekannt. MD2, MD5 und RIPEMD160 sind weitere bekannte Verfahren, welche von Ron
Rivest entwickelt wurden, mit denen auch Hashwerte erzeugt werden können.
Die Angabe „mit RSA“ besagt, dass der SHA-1 Hashwert mit einem privaten RSA-
Schlüssel verschlüsselt wird und als Signatur an z.B. eine E-Mail mit angehangen wird.
3.10.4 X.509-Zertifikate
Mit einer plattformunabhängige Notation können Daten auf unterschiedlichen Betriebssystemen
dargestellt werden. X.509-Zertifikate bedienen sich hierfür bei der Abstract Syntax Notation
One (ASN.1), welche in einem späteren Kapitel beschrieben wird. Die Kodierung erfolgt
nach den Distinguished Encoding Rules (DER).
Momentan liegt der X.509 Standard in der Version 3 vor, der auch eine Möglichkeit für
Zertifikaterweiterungen vorsieht. Im Campuskarten-Projekt kommt diese aktuelle Version des
Standards zum Einsatz.
Die ASN.1-Struktur eines X.509-Zertifikats sieht wie folgt aus:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
19
Angriffsart, bei der durch Ausprobieren aller Möglichkeiten nach dem richtigen Wert gesucht wird.
Ihnen wird entgegengewirkt, indem man die Kombinationsmöglichkeiten sehr groß wählt, damit mit
verfügbaren technischen Mittel ein Angriff „mit brutaler Gewalt“ zeitlich nicht durchführbar ist.
20
steht für National Security Agency. Sie ist die Behörde der USA, die vor allem durch ihr Echelon-
Programm in Europa für Aufsehen sorgte. Durch ihre undefinierten Aufgabenfelder wird das
Akronym auch scherzhaft mit No Such Agency übersetzt.
21
steht für National Institute of Standards and Technology
16

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
Die Sequenz Certificate beinhaltet im Feld tbsCertificate die Zertifikatsdaten.
Das Datum signatureAlgorithm gibt den Algorithmus für die im Feld
signatureValue enthaltene Signatur an.
Die gesamten Daten, die das Zertifikat enthält werden in der Sequenz TBSCertificate abgelegt.
Sie sieht wie folgt aus:
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer
Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
subjectUniqueID[2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL,
-- If present, version shall be v3
}
Für X.509-Zertifikate gibt es drei Versionsmöglichkeiten. Die Version 3 (v3) enthält alle
angegebenen Komponenten. Bei Zertifikaten nach Version 2 (v2) fehlt der Eintrag
extensions. Ab Version 3 sind u.a. folgende Extensions definiert: KeyUsage
(Schlüsselgebrauch), CertificatePolicies (Zertifikatsrichtlinien),
SubjectAlternativeName (alternativer Name des Zertifikatsinhabers) und
ExtendedKeyUsage (Erweiterte Schlüsselbenutzung). Bei der Version 1 (v1) fehlen
zusätzlich noch die Komponenten issuerUniqueID und subjectUniqueID. Die
Versionsnummer wird als INTEGER kodiert und fängt gemäß ASN.1 beim Zählen mit Null
an, d.h. v2 ist 1.
Wie der Versionstyp wird die CertificateSerialNumber auch als INTEGER kodiert.
Die Seriennummer eines jeden Zertifikates einer Zertifizierungsstelle muss eindeutig
und einmalig sein. Dies ist für die genaue Identifizierung eines Zertifikats innerhalb einer
CRL notwendig.
Im Feld signature wird der verwendete Algorithmus des Zertifikatausstellers kodiert. Der
Inhalt des Feldes muss dem im signatureAlgorithm Feld gleichen.
Das Feld issuer beinhaltet den Namen des Zertifikatausstellers. Der Name ist ein X.500
distinguished name (DN), der sich wiederum aus relative distinguished names (RDNs) zusammensetzt.
RDN-Typen sind u.a. CN, OU, O und C. Diese stehen für common name,
organisational unit, organisation und country.
Die Komponente subject ist ebenfalls nach der ASN.1-Struktur Name kodiert. Es
muss von der CA sichergestellt sein, dass das gleiche subject auch nur für eine Entität
verwendet werden darf.
Im Feld validity wird der Gültigkeitszeitraum für das Zertifikat festgelegt. Ein in der
CA-Hierarchie untergeordnetes Zertifikat muss im Gültigkeitszeitraum des Ausstellerzertifikats
liegen.
17

Der öffentliche Schlüssel eines Zertifikatinhabers wird im Feld
subjectPublicKeyInfo angegeben. Dies können neben dem im Projekt vorliegenden
RSA-Schlüssel auch DAS- oder Diffie-Hellmann-Schlüssel sein.
3.11 Verhalten von E-Mail-Clients mit unterschiedlichen
Testzertifikaten
Es gibt unterschiedliche Möglichkeiten, ein Zertifikat mit Parametern auszustatten. Das
Projekt und diese Arbeit haben sich zum Ziel gesetzt, die sichere E-Mail-Anwendung mit
gängige E-Mail-Clients, wie Netscape Messenger und MS-Outlook, durchzuführen.
Damit die Zertifikate, die vom TUB-Trustcenter generiert werden, auch akzeptiert werden,
muss eindeutig festgelegt werden, inwieweit Standardanwendungen mit u.a. E-Mail-
Extensions umgehen können. Dazu wurden von einem Test-Trustcenter folgende Zertifikattypen
generiert.
Testuser:
Alfred ATester
Berd BTester
E-Mail: alfred@prz.tu-berlin.de
E-Mail: berd@prz.tu-berlin.de
Dateiname
alfred_sign_ext
alfred_sign_noext
alfred_enc_ext
alfred_enc_noext
alfred_sign+enc_ext
alfred_sign+enc_noext
alfred_wrong_E-Mail
Beschreibung
Zertifikat nur zum Signieren mit Erweiterungen für Benutzer
Alfred ATester mit richtiger E-Mail-Adresse
Zertifikat nur zum Signieren ohne Erweiterungen für Benutzer
Alfred ATester mit richtiger E-Mail-Adresse
Zertifikat nur zum Verschlüsseln mit Erweiterungen für Benutzer
Alfred ATester mit richtiger E-Mail-Adresse
Zertifikat nur zum Verschlüsseln ohne Erweiterungen für Benutzer
Alfred ATester mit richtiger E-Mail-Adresse
Zertifikat nur zum Signieren und Verschlüsseln mit Erweiterungen
für Benutzer Alfred ATester mit richtiger E-Mail-Adresse
Zertifikat nur zum Signieren und Verschlüsseln ohne Erweiterungen
für Benutzer Alfred ATester mit richtiger E-Mail-Adresse
Zertifikat für Benutzer Alfred ATester mit falscher E-Mail-Adresse
Tabelle 2-3.2: Testzertifikate
Info: alle Alfred-Test-Zertifikate liegen auch für den Testuser Berd vor; Erweiterung bedeutet,
dass die Zertifikate nur für bestimmte Zwecke (sign oder enc) ausgestellt worden sind
18

3.11.1 Netscape Messenger 4.7x
UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
Anzeige unter „Eigene“ x x x x x x x
Anzeige unter „Messenger“ - x x x x x x
kann signierte Nachricht senden/verifizieren - x x x x x -
kann verschlüsselte Nachricht senden/empfangen - x - x x x -
Legende: x:Ja, -:Nein
Tabelle 2-3.3: Auswertung Netscape Messenger 4.7x
Mit „Anzeige unter ‚Eigene’“ ist gemeint, dass die Zertifikate im Ordner des Benutzers angezeigt
werden. Mit „Anzeige unter ‚Messenger’“ ist gemeint, dass die Zertifikate für den E-
Mail-Einsatz auswählbar sind (siehe Abbildung 6-7.1).
Der Messenger die Zertifikate mit expliziter Erweiterung für andere Aufgaben nicht
akzeptiert.
3.11.2 Microsoft Outlook 2000
Anzeige unter Signaturzertifikate - x x x x x x
Anzeige unter Verschlüsselungszertifikate x - x x x x x
kann signierte Nachricht senden/verifizieren x x x x -
e
n
c
_
e
x
t
e
n
c
_
e
x
t
s
i
g
n
_
e
x
t
e
n
c
_
n
o
e
x
t
s
i
g
n
_
e
x
t
e
n
c
_
n
o
e
x
t
s
i
g
n
_
n
o
e
x
t
s
i
g
n
_
n
o
e
x
t
s
i
g
n
_
e
n
c
_
e
x
t
s
i
g
n
_
e
n
c
_
e
x
t
s
i
g
n
_
e
n
c
_
n
o
e
x
t
s
i
g
n
_
e
n
c
_
n
o
e
x
t
w
r
o
n
g
_
e
m
a
il
w
r
o
n
g
_
e
m
a
i
l
19

kann verschlüsselte Nachricht senden/empfangen x x x x -
Legende: x:Ja, -:Nein
Tabelle 2-3.4: Auswertung MS Outlook 2000
Bei MS Outlook 2000 ist es möglich zwei unterschiedliche Zertifikate anzugeben, jeweils für
Signatur und Verschlüsselung. Deshalb die Unterteilung der Anzeige. Für den Test wurden
immer zwei Zertifikate vom gleichen Typ (ext, noext) eingesetzt, siehe Tabellenfarbgebung.
Durch die Möglichkeit zwei Zertifikate angeben zu können hat Outlook im Vergleich zu
Netscape Messenger mehr Spielraum im Hinblick auf Erweiterungen.
Beide E-Mail-Clients zeigen, dass eine Zertifikat mit einer E-Mail-Adresse, die nicht dem
Absender entspricht, nicht eingesetzt werden kann.
3.12 X.500-Verzeichnis und Certificate Revocation List
Die CRL (zu deutsch Widerrufsliste) ist ein von der CA signierter Datensatz, indem alle
ungültigen Zertifikate aufgelistet sind. Als ungültig wird ein Zertifikat eingestuft, wenn es
kompromittiert wurde, d.h. die Karte mit dem privaten Schlüssel abhanden gekommen oder
dieser bekannt geworden ist.
Das im Projekt eingesetzte X.500-Verzeichnis basiert auf dem LDAP-Protokoll und wird
durch das OpenSource Paket OpenLDAP in der Version 2 bereit gestellt. Die Abkürzung
LDAP steht für „Lightweight Directory Access Protocoll. Die „International Telecommunication
Union“ (ITU) standardisierte den X.500 Verzeichnisdienst, basierend auf dem OSI-7-
Schichtenmodell. Durch LDAP, das auf dem TCP/IP-Protokoll basiert, gewährleistet einen
einfachen Zugriff auf X.500 Verzeichnisse. LDAP wurde von der „Internet Engineering Task
Force“ (IETF) entworfen. Dieses Protokoll wird von den gängigen E-Mail-Clients unterstützt,
z.B. Netscape Messenger und Microsoft Outlook.
Ein Verzeichnis (engl.: Directory) ist eine spezielle Datenbank, die Informationen über
Dienste und Personen speichert und über das Internet zur Verfügung stellt. Es ist mit einem
öffentlichen Adressbuch bzw. Telefonbuch vergleichbar.
Der Zugriff auf ein solches Verzeichnis kann benutzt werden, um Zertifikate mit öffentlichen
Schlüsseln vom gewünschten Kommunikationspartner in seine clientseitige Sicherheitsumgebung
einzubinden.
In einem X.500 Directory ist jeder Eintrag durch seinen Distinguished Name (DN) eindeutig
gekennzeichnet. Die einzelnen DN setzen sich wiederum aus Relative Distinguished
Names (RDN) zusammen (siehe X.509-Zertifikate). Das Verzeichnis ist wie ein Baum hierarchisch
aufgebaut (Directory Information Tree, DIT). Jeder RDN bildet einen Knoten, z.B.
ON. Ein Eintrag wiederum setzt sich zusammen aus Attributtyp und Wert, z.B CN=Sebastian
Zickau. In Abbildung 2-3.7 bedeuten die einzelnen RDNs: C = Country, O = Organization,
OU = Organizational Unit, CN = Common Name.
20

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
C=DE
O=TU-Berlin
. . .
OU=PRZ
. . .
CN=Sebastian
Zickau
CN=Thomas
Gebhardt
CN=Klaus
Nagel
. . .
Abbildung 2-3.7: Zertifikathierarchie
In Kapitel 6 wird beschrieben, wie man die Clients konfiguriert, damit sie auf den TUB-Verzeichnisserver
zugreifen können.
3.13 Public Key Cryptographic Standards
Public Key Cryptographic Standards (PKCS) werden u.a. von den RSA Laboratories spezifiziert
und in regelmäßigen Abständen aktualisiert. RSA veröffentlichte 1991 zum ersten Mal
diese Serie, mit der Absicht eine allgemein gültige Schnittsstelle für die Implementierung von
Public-Key-Anwendungen zu schaffen.
Es sind bis heute 12 PKCS-Standards spezifiziert worden (die Nummerierung von 1-15
beziehen sich noch auf eine spätere Zählweise), die u.a. Richtlinien, Methoden und Formate
von PKI-Lösungen definieren. Es bauen heutzutage andere Standard-Spezifikationen auf
dieser Serie auf. PKCS-Standards sind sehr allgemein gehalten und lassen sich für viele Anwendungen
einsetzen. Die Definitionen müssen deshalb nicht immer zu einer Assoziation mit
elektronischer Post führen, auch wenn das für diese Arbeit der Fall ist.
Es folgt eine kurze Beschreibung der für diese Arbeit wichtigen Standards, mit einer Betonung
auf PKCS#11.
PKCS#1 (RSA Encryption Standard)
Dieser Standard definiert eine Datenverschlüsselungsmethode, die auf dem RSA-Verfahren
basiert. Sie wird für PKCS#7 zur Signaturberechnung und zur Verschlüsselung von temporären
symmetrischen Schlüsseln vorgeschlagen.
PKCS#6 (Extended-Certificate Syntax Standard): Dieser Standard beschreibt ein Format,
um X.509-Zertifikate mit zusätzlichen Attributen zu versehen. Seit der Version 3 hat allerdings
der X.509 Standard selber einen Mechanismus, mit dem man über eigene Zertifikaterweiterungen
zusätzliche Informationen in ein Zertifikat einbringen kann.
PKCS#7 (Cryptographic Message Syntax): Dieser Standard beschreibt in allgemeiner
Form, wie Daten durch kryptografische Verfahren geschützt werden können.
PKCS#10 (Certificate Request Syntax Standard): Dieser Standard definiert ein Format für
Zertifikatanforderungen und bildet die Grundlage für den S/MIME-Typ application/pkcs10.
21

PKCS#15 (Cryptographic Token Information Format Standard): Dieser Standard beschreibt
in einer allgemeingültigen Form, in welchem Format kryptografische Entities, u.a.
private Schlüssel oder Zertifikate auf Token, wie SmartCards, gespeichert werden können.
PKCS#11 (Cryptographic Token Interface): Dieser Standard, abgekürzt mit dem Akronym
Cryptoki, definiert eine allgemeine API für die Anbindung von kryptografischen Token an
eine Sicherheitsumgebung. Die Beschreibung liegt momentan in der Version 2.11 vor.
(weiteres siehe Abschnitt 5.1.6)
3.14 Hardware- und Treiberstandards
Neben den angesprochenen Kryptografie- und E-Mail-Standards baut das Projekt
Campuskarte auch auf einer Reihe von Hardware- und Treiberstandards auf, da in dem
zugrundeliegenden System nicht nur Software, sondern mit der Chipkarte auch Hardware
zum Einsatz kommt.
3.14.1 Open Card Framework
Das OpenCardFramework (OCF) entstand durch die Kooperation 22 verschiedener namhafter
Unternehmen, u.a. GemPlus, Schlumberger und IBM, die einen allgemeinen Standard für den
Zugriff in Java auf SmartCards anbieten wollten. Durch den Einsatz von Java sind die Treiber
plattformunabhängig. Als Treiber müssen z.B. vom Kartenhersteller verschiedene Pakete zur
Verfügung gestellt werden, dies sind u.a. CardService und CardTerminal. Es handelt
sich dabei um reine Java-Implementierungen, welche auf das Vorhandensein einer Java
Virtual Machine angewiesen sind.
Die gesamte Architektur des Campuskartensystems basiert auf OCF. Als Treiber unter
Windows-Betriebssystemen wird eine Bridge verwendet, die sich an die im nächsten Abschnitt
dargestellte PC/SC Schnittstelle koppelt.
Ein Nachteil dieser Architektur ist, dass für jeden Kartenleser eigene OpenCard-Treiber
geschrieben werden müssen, wenn man den vollen Funktionsumfang des OCF nutzen will.
Die gute Anbindung an eine Java-Umgebung ist als Vorteil für diese Architektur zu sehen.
Die Abbildung 2-3.8 zeigt die gesamte OCF-Architektur, mit den einzelnen Abstraktionsschichten
(siehe [OCFP99]).
22
bezeichnet als OpenCard Consortium
22

UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
Abbildung 2-3.8: OCF-Architektur
3.14.2 PC/SC
Der PC/SC 23 -Standard ist eine Initiative Microsofts, die für seine Betriebssysteme einen
allgemeinen Standard für den Zugriff auf SmartCards zur Verfügung stellen will.
Sie wird durch die PC/SC-Workgroup vertreten zu der bekannte Hersteller wie u.a. Sun,
GemPlus und Infineon gehören.
Es handelt sich hierbei im Gegensatz zu OpenCard um einen Native-Standard. Der
Kartenhersteller und der Hersteller des Lesegerätes stellen ein Framework zur Verfügung, das
aus PC/SC-Bibliotheken besteht.
Die derzeitigen Implementierungen der Herstellerseite beschränken sich hauptsächlich auf
die Windows-Welt. Linux/Unix-Anbindungen werden meist nur auf der Basis von
Opensource-Projekten vorangetrieben, siehe dazu das Kapitel 3.14.7 über M.U.S.C.L.E.
Nachteile dieser Architektur sind die dauerhafte Belegung der seriellen Schnittstelle, sowie
zum Teil nicht unterstützte Kartenlesegerätefeatures (Secure PIN-Modus). Die weite
Verbreitung und hohe Akzeptanz bei Hardwareherstellern ist auf die Marktposition von
Microsoft zurückzuführen.
Die Abbildung 2-3.9 soll einen kurzen Eindruck von der Architektur der PC/SC-Schnittstelle
liefern (siehe [PCSCWG]).
23
steht für: Personal Computer / Smart Card
23

Abbildung 2-3.9: PC/SC Architektur
3.14.3 Welche SmartCard wird eingesetzt?
Zur Zeit wird die Campuskarte mittels einer SmartCard der Firma GemPLUS realisiert. Die
Modellbezeichnung ist GemXpresso211PK. Diese Karte verfügt über 32 KB EEPROM
Speicher und einen 8 Bit Prozessor mit separatem CryptoProzessor für Verschlüsselungsfunktionen.
Eine Erweiterung der Speicherkapazität und der Prozessorleistung ist durch das Einführen
von fortschrittlicheren Kartenmodellen bereits in Vorbereitung.
3.14.4 Welche Kartenleser werden eingesetzt?
Für die TUB interne Nutzung der Campuskarte ist vorgesehen Kartenleser der Firmen Kobil
und Cherry einzusetzen. Von Kobil wird der Leser mit der Bezeichnung „Kobil Kaan Professional“
eingesetzt, der mit einer eigenen PIN-Tastatur ausgestattet ist. Beim Kartenleser
SmartBoard der Firma Cherry handelt es sich um eine PC-Tastatur mit eingebautem Kartenleser.
Dieser soll vor allem in öffentlichen PC-Pools zum Einsatz kommen.
Für dieses Vorhaben ist es unabdingbar, dass die Kartenleser einen sicheren PIN-
Eingabemodus (engl.: Secure PIN Entry-Mode) bereitstellen. Dies erfolgt über die korrekte
Installation eines geeigneten Softwaretreibers, der die Kartenleser bei entsprechender
Operation in einen Zustand schaltet, der die Eingabe direkt von der PIN-Tastatur an die Karte
schickt, ohne einen Umweg über den Prozessor. Hierzu werden javabasierte und kartenleserabhängige
OpenCard-Treiber eingesetzt.
3.14.5 ISO-7816-Standard
Der formelle Titel des ISO-7816-Standards lautet „Integration Circuit Cards with Electrical
Contacts“. Dieser Standard gliedert sich in mehrere Teile und stellt den derzeit meistbenutzten
SmartCard-Standard dar. In ihm werden neben physikalische Eigenschaften von Smart-
Cards auch Kommandos und Datenstrukturen beschrieben.
24

3.14.6 ASN.1
UMFELDANALYSE UND THEORETISCHE GRUNDLAGEN
ASN.1 steht für „Abstract Syntax Notation One“ und beschreibt eine allgemeingültige Notation,
die Datenstrukturen in abstrakter Weise und unabhängig von lokalen Gegebenheiten
darstellt (siehe [ASN1]). Diese standardisierte Notation ist nötig, um eine hohe Flexibilität
bei den Software-anwendungen zu erreichen. Auf unterschiedlichen Systemen könnten sonst
lokale Eigenheiten zu einer Inkompatibilität führen, als Beispiel sei hier nur die BigEndian/LittleEndian-Architektur
24 angegeben.
3.14.7 M.U.S.C.L.E.
M.U.S.C.L.E. steht für “Movement for the Use of Smart Cards in a Linux Environment“ und
ist eine OpenSource-Initiative, die sich mit der Treiberanbindung von SmartCards für Unixbasierte
Betriebssysteme auseinandersetzt (siehe [MUSCLE])
Im aktuellen Projekt wird eine MUSCLE-pcsc-lite Anbindung für die Vorpersonalisierung
25 eingesetzt.
24
Auf unterschiedlichen Plattformen kann es zu Differenzen bei der Erkennung von Bitfolgen
kommen, je nachdem, ob beim ersten Bit eines Blocks angefangen wird zu lesen oder beim letzten.
25
Bezeichnung für einen Prozess, beim dem durch das Trustcenter Schlüssel auf der Karte
gespeichert werden
25

4 Anforderungsanalyse für sichere E-Mail
In diesem Kapitel wird ein Überblick über Lösungen gegeben, die momentan auf dem Softwaremarkt
verfügbar sind. Anschließend wird zu der vorliegenden Lösung hingeführt, in dem
nach dem eingesetzten Vorgehensmodell Anforderungen und Anwendungsfälle der zu entwickelnden
Software aufgezeigt werden.
4.1 Bestehende Lösungen
Im Kontext der Arbeit wurden bestehende Lösungen für ein sicheres E-Mail-System, das mit
Chipkarten arbeitet, getestet und ausgewertet.
Zum Einsatz kamen Lösungen von den Firmen GemPlus, Kobil und Utimaco. Die Strategie,
die GemPlus mit dem Tool GemSAFE und Kobil mit SmartKey in Bezug auf Netscape
verfolgen, ist die Anbindung der Karte mittels eines PKCS#11 Treibers. Netscape erlaubt die
Einbindung eines separaten PKCS#11-Moduls, das den kryptografische Funktionen
bereitstellt. Es ist möglich Netscape ohne zusätzliches Kryptomodul zu nutzen, hierbei greift
der E-Mail-Client Messenger auf ein eigenes internes PKCS#11-Modul zurück, das
ausschließlich in Software implementiert ist. Bei der Anbindung zu einer Chipkarte, sind
zwei Module parallel installiert.
Die Anbindung an Produkte Microsofts ist nicht mittels des PKCS#11 Standards möglich.
MS unterstützt diese API nicht direkt. Bei Microsoft Anwendungen, wie Outlook und
Internet Explorer greifen die Komponenten, die eine kryptografische Funktion ausüben auf
sogenannte Cryptographic Service Provider (CSP) zurück. Diese Provider stellen der
Anwendung, basierend auf einer von Microsoft definierten proprietären Schnittstelle, der MS
CryptoAPI, die nötige Funktionalität zur Verfügung.
Neben GemPlus und Kobil kam bei den Outlook Lösungen auch das Produkt SafeGuard
von Utimaco zum Einsatz. Dieses Produkt unterstützt allerdings keine Netscape-Anbindung.
Eine Variante ein bestehendes E-Mail-System mit S/MIME Funktionalität auszustatten ist
die Möglichkeit einen Proxy vor den Client zu installieren. Dieser hat die Aufgabe die E-
Mails, die er aus dem Internet empfängt kryptografisch zu behandeln und an den eigentlichen
Client u.a. unverschlüsselt weiter zu geben. Dieser Proxy verbindet den E-Mail-Client des
Benutzers und den E-Mail-Server im Netz.
Als Beispiel für einen solchen Proxy ist der S/MIME-Wrapper von iaik 26 zu nennen der
diese Funktionalität als Java-Applikation bereit stellt. Hierbei ist jedoch noch keine Smart-
Card-Anbindung gegeben.
Diese Idee lässt sich auch auf der Ebene des E-Mail-Servers verwirklichen. Hierbei sind
die Proxys nicht lokal auf den Anwendungsrechnern, sondern es liegt nur ein Proxy vor, der
den gesamten E-Mail-Verkehr filtert, d.h. entsprechende Verschlüsselungen und Signaturen
zentral vornimmt. Der Nachteil eines solchen Systems ist, dass es einem Angreifer
ermöglicht wird, sollte er in das System eindringen können, z.B. signierte E-Mails im Namen
der Firma oder Behörde auszustellen. Vorteilhaft ist die zentrale Administrationsmöglichkeit.
Eine Erörterung über die Unterschiede und Gemeinsamkeiten zur vorliegenden
Erarbeitung folgt in Kapitel vier.
26
steht für: Institut für Angewandte Informationsverarbeitung und Kommunikationstechnologie und
ist an der Technischen Universität Graz angesiedelt
26

ANFORDERUNGSANALYSE FÜR SICHERE E-MAIL
Vergleichstabelle
Produktname Sign&Crypt SmartKey GemSAFE
Version 3.0 2.0 3.0
Hersteller Utimaco Kobil GemPlus
Plattformen Windows Windows /
Linux / OS/2 Warp
Windows
4 / u.a.
Programme Outlook 97, 2000 Outlook 5, 98, 2000 /
Explorer ab 5.01 /
Netscape ab 4.04
Systemanforderungen P200 Mhz, 64 MB
RAM
30 MB RAM
(Win2000 64MB
RAM), 10 MB HD
Outlook Express 5.0,
2000 / Netscape ab
4.6 / Explorer ab 5.0
PII 400 Mhz, 20 MB
HD, Win2000 64 MB
RAM
Anzahl der
1 oder 2 1 oder 2 1
Zertifikate
Bitlänge der Schlüssel 512 oder 1024 1024 1024
Betrieb auch ohne ja nein nein
SmartCard möglich
Algorithmen RSA RSA RSA
CRL
(CertRevocationList)
ja
nein,
Client intern
nein,
Client intern
Kartenleser CardMan 2011 Kobil Kaan Standard GemPC400, 410, 430
Schnittstelle COM, USB COM und PS/2, USB COM, USB,
PCMCIA
Standards - PKCS#11 PKCS#11
Tokens
SmartCard SLE
66CX160S TCOS
TCOS SmartCard,
Version 1.2 oder 2.02
Authentisierung nein ja ja
Zertifikatsstandard X.509 X.509 X.509
LDAP ansprechbar bei eigener Outlook- Netscape/Outlook
Erweiterung intern
Installation ++ ++ +
PIN/PUK
MasterPIN 6 Stellen, UserPIN 6 Stellen
UserPIN 4-6 Stellen
Tabelle 3-4.1: Auswertung Testsoftware
GemSAFE GPK
8000, 16000
Netscape/Outlook
intern
Admin PIN und User
PIN, min. 4 Stellen
Fazit: Die Auswertung der Software hat ergeben, dass sich die Produkte in wesentlichen
Eigenschaften gleichen. Sie basieren alle auf RSA-Algorithmen mit 1024 Bit Schlüssellänge
und verwenden Standard-X.509-Zertifikate.
Ein Unterschied ist in den unterstützen Plattformen und Systemanforderungen zu erkennen.
Bei den Produkten, die sowohl Netscape-Clients als auch Outlook-Clients erweitern, ist
festzustellen, dass dafür unterschiedliche Anbindungssoftware notwendig ist.
27

4.2 ISP-Vorgehensmodell - Erläuterungen
ISP steht für „Irrational Seperated Process“ und ist vom Namen her im Kontrast zum „Rational
Unified Process“ zu sehen, der von den UML-Entwicklern als Vorgehensmodell propagiert
wird.
Das ISP-Vorgehensmodell ist für die Realisierung von kleineren bis mittleren Softwareprojekten
gedacht. Das TUB-Projekt Campuskarte wird nach dieser Methode realisiert und
kommt deshalb auch bei dieser Arbeit in Teilaspekten zum Einsatz.
Nach dem ISP-Modell werden folgende Phasen der Entwicklung unterschieden:
1. Phase: Anforderungsbeschreibung; Ergebnis: Anforderungsmodell
Das Anforderungsmodell ist eine formale Beschreibung der Funktionen und Randbedingungen,
die für die Aufgabe von Interesse sind.
2. Phase: Analyse; Ergebnis: Analysemodell
Ziel der Analyse ist es das Problembereichsmodell zu verfeinern und ein möglichst
implementierungsunabhängiges Modell zu entwickeln, das durch den Entwurf konkretisiert
wird.
3. Phase: Entwurf; Ergebnis: Entwurfsmodell
Während des Entwurfs werden alle implementierungstechnischen Entscheidungen getroffen.
Bislang wurde die Frage nach dem Was soll das System beantwortet. Jetzt geht es um
die Frage Wie soll es das machen.
Hier werden einzelne Entwurfsentscheidungen erläutert, die es im Laufe der Entwicklung
zu treffen galt. Nach dem ISP-Modell wird in Entwurfsphase ein Detailentwurf erstellt,
der sehr implementierungsnah ist. Dieser Schritt wird in Kapitel 5 mit Spezifikation
bezeichnet.
4. Phase: Implementierung; Ergebnis: Code
In diesem Abschnitt werden implementierungsnahe Entscheidungen erläutert.
5. Phase: Test (ggf. mit Funktionserweiterung)
Die Ergebnisse der Implementierung werden durch Tests geprüft, damit auf evtl. Fehler
eingegangen werden kann.
6. Phase: Inbetriebnahme
Nach einem erfolgreichen Test folgt die Inbetriebnahme, mit dem Ziel evtl. Fehler vor
dem Einsatz zu erkennen.
7. Phase: Einsatz
Als Ergebnis des Modells ist der reale Einsatz der Software zu sehen. Durch den prototypischen
Charakter der vorliegenden Implementierung folgen die Phasen sechs und
sieben zu einem späteren Zeitpunkt.
Das ISP-Modell sieht vor, dass aus jeder Phase in die davorliegende zurückgesprungen werden
kann, damit durch erkannte Fehler nötige Anpassungen gemacht werden können.
Eine ausführlichere Beschreibung findet der Leser in dem Buch [HITZ99].
28

4.3 Anforderungen
ANFORDERUNGSANALYSE FÜR SICHERE E-MAIL
Anforderungen werden nach dem ISP-Modell in funktionale und nicht funktionale Anforderungen
aufgeteilt. Zu den nicht funktionalen Anforderungen gehören diejenigen, die keine
direkte Funktion haben, sondern nur Randbedingungen erfüllen. Zu ihnen gehören folgende
nicht funktionale Anforderungen:
allgemeine Anforderungen an die Software:
Zuverlässigkeit: Die Software ist zuverlässig, wenn Fehler nur selten auftreten und diese
geringe Auswirkungen auf den Ablauf des Programms haben.
Robustheit: Software ist robust, wenn sie bei allen Arten, auch fehlerhafter, externer Kommunikation
sinnvoll reagiert.
Verfügbarkeit: Software ist verfügbar, wenn sie durchgehend jederzeit vom Benutzer verwendet
werden kann.
Benutzungsfreundlichkeit: Wenn die Software durch die Bedienoberfläche sinnvoll und
intuitiv genutzt werden kann, ist die Software benutzungsfreundlich.
Keine zusätzliche Qualifikation von Mitarbeitern: Die Software sollte ohne zusätzliche
Benutzerqualifikation einsetzbar sein.
Systemunabhängigkeit: Die Software sollte auf möglichst vielen unterschiedlichen Systemen
einsetzbar sein.
Hardwareunabhängigkeit: Die Software sollte mit unterschiedlicher Hardware interagieren
können und von dieser nicht beeinflusst werden. Es sollen z.B. alle Kartentreiber und Javakarten
mit der Software arbeiten können.
Geringe Kosten: Durch den Einsatz der Software sollten keine Extrakosten für die Benutzer
und für die Verwaltung, welche die Software einsetzt, entstehen.
4.3.1 Nicht funktionale Anforderungen
Einsatz eines bestehenden E-Mail-Clients: User sollen ihre gewohnte E-Mail-Umgebung
beibehalten, somit ist eine Anbindung an kommerzielle und proprietäre Software nötig. Dies
kann durch Anbindung mittels offener Standards geschehen.
Anbindung der Campuskarte: Als Sicherheitstoken soll die Campuskarte genutzt werden,
da diese für den gesamten Verwaltungsapparat zum Einsatz kommt.
Gesetzes- und TUB-Dienstvereinbarungskonform: Die Software soll gesetzeskonform
entwickelt und eingesetzt werden. Sie soll sich nach Daten- und Signaturgesetzen, sowie nach
Dienstvereinbarungen der Technischen Universität Berlin richten.
29

4.3.2 Funktionale Anforderungen
Im folgenden werden die funktionalen Anforderungen dargestellt.
Netscape Messenger soll eingesetzt werden: Der sich bereits im Einsatz befindliche E-
Mail-Client soll erweitert werden, damit ein Umlernen der vertrauten Umgebung nicht notwendig
ist.
Zwei Zertifikate und Schlüssel bei Dienstausweis: Bei Dienstausweisen sollen unterschiedliche
Schlüssel für Signatur und Verschlüsselung eingesetzt werden.
Linux und Windows sollen unterstützt werden: Es ist bei der Entwicklung auf
Plattformunabhängigkeit zu achten, um ein größeren Einsatzbereich abzudecken.
Standardkartenleser sollen unterstützt werden: Eine breite Palette von Kartenlesern sollen
integrierbar sein, damit der Anwendungsbereich vergrößert wird.
Nationale und internationale Standards: Es ist darauf zu achten, dass offene Standards
zum Einsatz kommen.
Ungültige Zertifikate: Kompromittierte Zertifikate müssen über eine CRL abrufbar sein,
damit Sicherheitsaspekte gewährleistet ist.
LDAP-Verzeichnis: Auf ein LDAP-Verzeichnis mit Zertifikaten der Nutzer muss zugreifbar
sein, damit Fremdzertifikate lokal gespeichert werden können
4.4 Problembereichsmodell
Eine sehr vereinfachte Darstellung der Komponenten, die am System beteiligt sind, sieht man
in der Abbildung 3-4.1. Diese Darstellung wird benutzt, um eine sehr grobe Struktur des Systems
darzustellen.
Eine Hauptaufgabe der Arbeit besteht darin, dieses System noch feiner zu granulieren, zu
analysieren und einen Entwurf entwickeln, der mit der Implementierung in ein reales Anwendungsprogramm
umgesetzt wird.
In folgendem Diagramm (Abbildung 3-4.1) werden in einer sehr abstrakten Form die am
System beteiligten Komponenten dargestellt. An dem System sind unterschiedlich (*) viele
Benutzer beteiligt, die eine vorgegebene Anzahl (n) von Campuskarten besitzen. Die Daten,
die die Nutzer verarbeiten sind variabel (*). Um zu verdeutlichen, dass mehrere Anwender an
einem System arbeiten wurde die Kardinalität (1) gesetzt. In der Praxis werden allerdings
eine Vielzahl von E-Mail-Clients eingesetzt.
30

ANFORDERUNGSANALYSE FÜR SICHERE E-MAIL
1
Netscape
Messenger
1
1
*
Daten
* *
*
Benutzer
* n
n
n
Campuskarte
n
4.5 Anwendungsfallmodell
Abbildung 3-4.1: Diagramm des Problembereichsmodells
Die Anwendungsfalldiagramme geben einen Überblick über die Gesamtfunktionalität der
Anwendung, diese werde durch die Anwendungsfallbeschreibung natürlichsprachlich erläutert.
4.5.1 Anwendungsfalldiagramme
In der folgenden Grafik sind die relevantesten Anwendungsfälle von Sender und Empfänger
dargestellt. Diese Anwendungsfälle spiegeln den Einsatz der entwickelten Software, d.h. auch
der Campuskarte, wieder. Deshalb wurde darauf verzichtet die Anwendungsfälle aufzuzeigen,
die vom E-Mail-Client generell unterstützt werden.
Es ist zu beachten, dass der Anwendungsfall „PIN eingeben“ nicht direkt gefordert wird,
sondern nur im Zusammenhang einer Aktion, wie „Signieren“, auftritt.
verifizierte E-Mail
lesen
Sender
E-Mail signieren
E-Mail verschlüsseln
E-Mail
verschlüsseln
und signieren
verifizierte und
entschlüsselte E-
Mail
lesen
entschlüsselte E-
Mail
lesen
Empfänger
PIN eingeben
PIN eingeben
Abbildung 3-4.2: Anwendungsfalldiagramme
31

4.5.2 Anwendungsfallbeschreibung
Es folgt eine tabellarische Anwendungsfallbeschreibung. Neben den in der Abbildung aufgezeigten
Anwendungsfälle, gehören zu einem sicheren E-Mail-Einsatz weitere Aktionen, die
hier auch beschrieben werden.
Anwendungsfälle:
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
E-Mail verschlüsselt schicken
Public Key und Zertifikat muss vorhanden sein
verschlüsselte E-Mail wurde versandt
kein Public Key/Zertifikat
E-Mail wird nicht verschickt
Sender
1. neue E-Mail wird geöffnet
2. E-Mail wird geschrieben
3. Option „verschlüsseln“ wird ausgewählt
4. verschlüsselte E-Mail wird versandt
E-Mail signiert verschicken
Private Key und Zertifikat muss vorhanden sein
signierte E-Mail wurde versandt
kein Private Key / Zertifikat vorhanden
E-Mail wird nicht verschickt
Sender
1. neue E-Mail wird geöffnet
2. E-Mail wird geschrieben / Empfänger eintragen
3. Option „signieren“ wird ausgewählt
4. PIN-Eingabe
5. signierte E-Mail wird versandt
E-Mail signiert und verschlüsselt verschicken
Public und Private Keys müssen vorhanden sein
signierte und verschlüsselte E-Mail wurde versandt
kein Zertifikat (Public Key) und kein Private Key vorhanden
E-Mail wird nicht verschickt
Sender
1. neue E-Mail wird geöffnet
2. E-Mail wird geschrieben / Empfänger eintragen
3. Optionen „signieren“ und „verschlüsseln“ wird ausgewählt
4. PIN-Eingabe
5. verschlüsselte und signierte E-Mail wird versandt
E-Mail verifizieren
Zertifikat vorhanden
E-Mail verifiziert
kein Zertifikat vorhanden, Signatur fehlerhaft
32

Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Kurzbeschreibung
ANFORDERUNGSANALYSE FÜR SICHERE E-MAIL
E-Mail konnte nicht verifiziert werden, Anzeige für falsche Signatur
Empfänger
1. signierte E-Mail wird empfangen
2. eine Markierung zeigt korrekte Verifikation an
E-Mail entschlüsseln
Private Key vorhanden
E-Mail ist entschlüsselt und lesbar
Private Key nicht vorhanden/fehlerhaft
E-Mail kann nicht entschlüsselt und gelesen werden, „negativ“-Markierung
Empfänger
1. verschlüsselte E-Mail wird Empfangen
2. verschlüsselte E-Mail wird geöffnet
3. PIN-Eingabe
4. entschlüsselte E-Mail wird angezeigt, mit „positiv“-Markierung
E-Mail verifizieren und entschlüsseln
Zertifikat vorhanden und PrivateKey
E-Mail wurde verifiziert und entschlüsselt
kein Private Key vorhanden und Signatur fehlerhaft
E-Mail kann nicht entschlüsselt und verifiziert werden,
„negativ“-Markierung
Empfänger
1. verschlüsselte und signierte E-Mail wird empfangen
2. verschlüsselte und signierte E-Mail wird geöffnet
3. PIN-Eingabe
4. entschlüsselte und verifizierte E-Mail wird angezeigt, mit
„positiv“-Markierung
verschlüsselte E-Mail an mehrere Empfänger schicken
alle Zertifikate müssen vorliegen
E-Mail wurde verschlüsselt und abgeschickt
nicht alle Zertifikate liegen vor
E-Mail kann nicht verschickt werden
Sender
1. neue E-Mail wird geöffnet
2. E-Mail wird geschrieben / alle Empfänger eintragen
3. Option „verschlüsseln“ wird ausgewählt
4. E-Mail wird verschlüsselt und abgeschickt
Zertifikat vom LDAP-Server holen
Der E-Mail-Client lädt sich ein Benutzerzertifikat vom Verzeichnisdienst
33

Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Anwendungsfall
Kurzbeschreibung
Vorbedingung
Nachbedingung
Fehlersituationen
Nachzustand im
Fehlerfall
Akteure
Standardablauf
Alternativabläufe
E-Mail-Client muss LDAP-Anfrage unterstützen, Zertifikat muss im
Verzeichnisdienst abgelegt sein
Zertifikat lokal im System
LDAP nicht erreichbar, Zertifikat nicht vorhanden
Zertifikat nicht lokal vorhanden
Anwender
1. Anfrage mit E-Mail-Adresse wird an den LDAP-Server gestellt
2. Suchergebnis wird angezeigt
3. Aufnahme des Zertifikats in lokales Verzeichnis bestätigen
PIN eingeben
Zur Ausführung der kryptografischen Funktionen auf der Campuskarte
ist die Authentisierung des Benutzers durch die persönliche PIN
erforderlich
Karte nicht gesperrt
PIN korrekt, Karte nicht gesperrt, Aufruf der kryptografischen Funktion
PIN falsch
nach drei Fehlversuchen ist die Karte gesperrt und kann dann nur
mittels der PUK im Ausgabebüro entsperrt werden
Sender, Empfänger
1. Dialogbox wird angezeigt
2. PIN über Tastatur eingeben
3. Ausführen der kryptografischen Funktion auf der Karte
PIN wird 1 oder 2 Mal falsch eingegeben, Information erscheint, danach
Standardablauf
4.6 Schnittstellenmodell
Im folgenden werden die Benutzer- und Systemschnittstellen beschrieben, die das System
aufweist.
4.6.1 Benutzerschnittstellendefinition
Die Interaktion von Anwendung und Benutzer erfolgt über die vorhandene Anwendung des
Netscape Messengers. Hier werden keine Änderungen vorgenommen, so dass der Benutzer
die gleiche Funktionalität erwarten kann, die ihm dieser E-Mail-Client auch ohne sichere E-
Mail-Anwendung mittels Campuskarte bietet. Dies ist auch eine der Anforderungen die an
das System gestellt wurden, d.h. die Anbindung an eine bestehende Softwarelösung.
Wenn es zur Interaktion mit der Karte kommt, gibt es nur eine Schnittstelle mit dem User.
Dies ist die Abfrage der PIN, die durch ein Javafenster realisiert wird. Sollte die PIN korrekt
verifizierbar sein gibt es kein weiteres Userinterface. Bei einer falschen PIN allerdings wird
einem in einem neuen Fenster ein Warnhinweis angezeigt, der mitteilt wie viele Versuche
verbleiben, um seine richtige PIN einzugeben.
Beim Einsatz eines reinen OCF-Treibers bietet dieser die Möglichkeit über einen sicheren
PIN Eingabe-Modus (engl.: Secure PIN Entry-Modus) die Identifikationsnummer direkt am
Kartenlesegerät einzugeben, hierbei erscheint nur eine Aufforderung am Bildschirm.
34

4.6.2 Systemschnittstellendefinition
ANFORDERUNGSANALYSE FÜR SICHERE E-MAIL
Das zu entwickelnde System besteht aus unterschiedlichen Komponenten. Bei der Interaktion
zwischen diesen Komponenten werden Schnittstellen benutzt. Ein grober Überblick über die
Systemschnittstellen wird in der Abbildung 3-4.3 dargestellt.
Der Benutzer interagiert mit dem System über die vorhanden Oberfläche des E-Mail-
Clients. Da diese Interaktion durch die Benutzerführung des Netscape Messengers vorgegeben
ist, werden hier keine Veränderungen vorgenommen. Der Client wiederum muss bei entsprechenden
Funktionen über den Kartenleser mit der Chipkarte kommunizieren. Diese
Schnittstelle gilt es durch das vorliegende Vorhaben zu realisieren. Eine ausführliche Beschreibung
erfolgt in der Analyse- und Entwurfsphase. An dem System sollen mehrere Benutzer
mit mehreren Campuskarten beteiligt sein, deshalb sind die entsprechenden Multiplizitäten
im Diagramm gesetzt.
Eine weitere Schnittstelle zwischen Benutzer und Campuskarte liegt durch das Eingeben
der Benutzer-PIN vor, siehe Abschnitt 4.6.1. Diese Interaktion läuft ebenfalls über den
Kartenleser ab.
Benutzer
n 1 1 1 1 n
Netscape
Messenger
Kartenleser
Campuskarte
Abbildung 3-4.3: Systemschnittstellen
35

5 Analyse und Entwurf
Ging es bis hierher darum, was das System leisten soll, stellt sich nun die Frage nach dem
wie. Nach einem vollständigen Anforderungsmodell sieht das ISP die Analyse vor. Mit dem
Abschluss eines Analysemodells kann der Entwurf durchgeführt werden, aus dem das Entwurfsmodell
hervorgeht, welches die Grundlage für die Implementierung bildet.
Die Realisierung wird mit dem Akronym „cksem“ abgekürzt, das „Campuskarte Sichere-
E-Mail“ bedeutet. Im folgenden wird auch die Kurzform benutzt, um das System zu
benennen.
5.1 Analyse
Nachdem die Anforderungen und Anwendungsfälle definiert sind, ist es an der Zeit eine
Strategie zu entwerfen, wie das System zu realisieren ist. Dies geschieht in der Analysephase.
Die E-Mail-Anwendung Netscape Messenger bietet die Möglichkeit, über das in
[PKCS11] definierte Interface ein externes Sicherheitsmodul direkt in die vorhanden Software
einzubinden. Diese Vorgabe wird für die Realisierung genutzt. Die Frage ist, wie oder
wie genau wird sie benutzt?
Zum einen ist es wichtig zu erfahren wie Netscape die einzubindende Bibliothek benutzt,
d.h. konkret, welche Funktionen mit welchen Parameter werden aufgerufen, denn nicht alle
der in PKCS#11 definierten Funktionen werden benutzt. Einige Hinweise hierzu gab es in
kleinen Dokumentationen [IPLANE] im WWW, welche jedoch nicht ausreichend waren. Für
eine ausreichende Antwort musste das Verhalten System genauer analysiert bzw. definiert
werden. Hierfür diente zum einen die Ausgabe von Funktionsaufrufen in Logdateien (siehe
Kapitel 5.1.1) und Erfahrungsberichte von Entwicklern in Mailinglisten 27 .
Die Anbindung einer Anwendung, die in nativem Code geschrieben ist mit einer javabasierten
Umgebung ist eine weitere Herausforderung, die es zu lösen galt. Durch die
Verbindungsmöglichkeit zwischen Java und nativen Code über das Java Native Interface
gibt, kristallisierte sich als Lösungsansatz ein Schichtenmodell heraus. Eine detailliertere
Entwurfsbeschreibung befindet sich in den folgenden Abschnitten.
Eine erste Strategie ist, dass die native Schicht, welche mit der Anwendung Netscape
Messenger korrespondiert sehr dünn gehalten werden soll, damit eine leichtere Portierung auf
andere Systeme möglich ist und die gesamte Funktionalität in der Java-Schicht liegt.
5.1.1 Beispielausschnitt einer Logdatei
Folgende Zeilen zeigen eine Logfileausgabe. Dafür wurde eine „leere“ DLL implementiert,
die als PKCS#11-Modul in der Netscape Sicherheitsumgebung registriert wurde. Das
Vorgehen dabei wird in Kapitel sechs erläutert. Zuerst wurden nur die Funktionssignaturen
breit gestellt und Ausgaben für das Logfile. Um weiter fortschreiten zu können, wurden die
einzelnen Methoden nach und nach mit sinnvollen Rückgabewerten gefüllt.
Es soll veranschaulichen, inwieweit diese Angaben für das Auffinden der aufgerufenen
PKCS#11-Funktionen nützlich sind. Es werden u.a. Funktionsnamen, sowie Anzahl und
Werte der Parameter aufgezeigt.
27
PKCS#11-Mailingliste erreichbar mit Link von [PKCS11]
36

...
/* C_GetTokenInfo(): starting... (OK) */
/* C_GetTokenInfo(): slotID: 8409100(OK) */
/* C_GetTokenInfo(): pInfo: 7207804(OK) */
/* C_GetTokenInfo(): ...complete (OK) */
/* C_GetMechanismList(): starting... (OK) */
/* C_GetMechanismList(): slotID: 8409100(OK) */
/* C_GetMechanismList(): pMechanismList: 0(OK) */
/* C_GetMechanismList(): pulCount: 7207744(OK) */
/* C_GetMechanismList(): pMechanismList == NULL_PTR (OK) */
/* C_GetMechanismList(): pulCount = count (OK) */
/* C_GetMechanismList(): starting... (OK) */
/* C_GetMechanismList(): slotID: 8409100(OK) */
/* C_GetMechanismList(): pMechanismList: 8409104(OK) */
/* C_GetMechanismList(): pulCount: 7207744(OK) */
/* C_GetMechanismList(): pMechanismList != NULL_PTR (OK) */
/* C_GetMechanismList(): nach pMechanismList = mType (OK) */
/* C_GetMechanismList(): in != NULL_PTR ...complete (OK) */
/* C_OpenSession(): starting... (OK) */
/* C_OpenSession(): slotID: 8409100(OK) */
/* C_OpenSession(): flags: 4(OK) */
/* C_OpenSession(): pApplication: 8419232(OK) */
/* C_OpenSession(): Notify: 4236336(OK) */
/* C_OpenSession(): phSession: 7207772(OK) */
/* C_OpenSession(): Notify != NULL_PTR (OK) */
/* C_OpenSession(): ...complete (OK) */
/* C_FindObjectsInit(): start... (OK) */
/* C_FindObjectsInit(): hSession: 8419232(OK) */
/* C_FindObjectsInit(): pTemplate: 7207720(OK) */
/* C_FindObjectsInit(): ulCount: 1(OK) */
/* C_FindObjectsInit(): attribute.type: 0(OK) */
/* C_FindObjectsInit(): attribute.pValue: 7207696(OK) */
/* C_FindObjectsInit(): attribute.ulValueLen: 4(OK) */
/* C_FindObjectsInit(): ...complete (OK) */
…
ANALYSE UND ENTWURF
Dies ist nur ein kleiner Ausschnitt eines Logfiles, da die regulären Dateien im Normalfall,
d.h. bei einem Aufruf von durchgehend allen angesprochenen Methoden, mehrere hundert
Kilobyte groß sein können.
Man kann deutlich den Verlauf erkennen, mit dem die einzelnen Funktionen vom Netscape
Messenger aufgerufen werden.
5.1.2 Aufgerufene Funktionen
Durch die Logfileanalyse, konnte herausgefunden werden, welcher Funktionsumfang des
PKCS#11-Standard tatsächlich aufgerufen wurde. Dies sind im einzelnen folgende Funktionen:
C_GetInfo, C_GetFunctionList, C_Initialize, C_Finalize, C_InitToken, C_UnwrapKey,
C_DestroyObject, C_GetAttributeValue, C_FindObjectsInit, C_FindObjects,
C_FindObjectsFinal, C_OpenSession, C_GetSessionInfo, C_SignInit, C_Sign,
C_GetSlotList, C_GetSlotInfo, C_GetMechanismInfo, C_CloseAllSessions
Das Dokument [IPLANE] und die FAQ 28 [NEDEVC] dienten ebenfalls als Grundlage für die
Analyse des E-Mail-Clients.
28
steht für „Frequently Asked Questions“
37

Eine genauere Beschreibung der einzelnen Funktionen wird im Kapitel Spezifikation und
Implementierung gegeben.
5.1.3 Unterschiede und Gemeinsamkeiten zur erarbeiteten Lösung
Ein Unterschied der beschriebenen Produkte (siehe Abschnitt 4.1) zur erarbeiteten Lösung ist,
dass das Campuskartensystem mit dem OpenCard Framework auf der Basis der Programmiersprache
Java aufgebaut ist. Der gesamte Zugriff auf die Karte läuft über die Java
Virtual Machine ab.
Bei den dargestellten Lösungen wird auf die Karte nur über Native-Code zugegriffen,
zum einen ist das eine PKCS#11-Anbindung für den Netscape Messenger zum anderen die
Implementierung eines Cryptographic Service Providers für Microsoft Produkte, wie u.a. MS
Outlook.
Die Gemeinsamkeiten liegen darin, dass das TUB-System auch auf die genannten Standards,
u.a. PKCS#11 und S/MIME, zurückgreift, um eine Integration an bestehende E-Mail-
Clients zu gewährleisten.
Beim Design der Software muss darauf geachtet werden, dass die Funktionen, die auf der
Karte angesprochen werden, sehr allgemein gehalten sind, damit verschiedene Applikationen
diese zu ihren Zwecken nutzen können.
Abbildung 4-5.1 zeigt einen erstes grobes Lösungsmodell, indem eine Javaschicht
zwischen der nativen Anbindung zu den E-Mail-Clients und dem PC/SC-Treibern liegt.
MS Outlook
Netscape
Cryptographic Service Provider
(native)
PKCS#11
(native)
Java-Layer
OCF
PC/SC
Kartenleser
Campuskarte
5.1.4 Sequenzdiagramm
Abbildung 4-5.1: Lösungsansatz
Im Sequenzdiagramm 4-2 wird der Ablauf beim Signieren und Entschlüsseln dargestellt. Es
wird deutlich, dass die Campuskarte nur bei der Benutzung des privaten Schlüssels zum
38

ANALYSE UND ENTWURF
Einsatz kommt, d.h. bei den Aktionen Verifizieren und Verschlüsseln, werden die Aufgaben
vom E-Mail-Client selbstständig vorgenommen.
Dies ist auch verständlich, weil es zum Einsatz von Clients kommen kann, an dem keine
Campuskarteanbindung vorliegt, die aber trotzdem kryptografische Funktionalität bereitstellen.
Sender
Messenger Campuskarte
Campuskarte Messenger
Empfänger
schreibe Nachricht
bilde SHA-1
Wert
hänge
ver. Hash an
Nachricht
sende Hash
sende ver. Hash
verschlüssele
Hash-Wert
mit PrivKey
sende signierte Nachricht
verifiziere
Nachricht
zeige Ergebnis
und Nachricht
schreibe Nachricht
sende verschlüsselte Nachricht
verschlüssele
Nachricht
entschlüssel
Nachricht mit
DES-Key
zeige Ergebnis
sende ver. DES-Key
sende ents. DES-Key
entschlüssele
DES-Key mit
PrivKey
Abbildung 4-5.2: : Sequenzdiagramm – Versenden und Empfangen von sicherer E-Mail
5.1.5 Aktivitätsdiagramme
Die Aktivitätsdiagramme 4-3 bis 4-5 beschreiben die Hauptaufgaben des Systems, bei dem
die Campuskarte zum Einsatz kommt. Die zwei Anwendungsfälle „signieren einer E-Mail“
und „entschlüsseln einer E-Mail“ sind dargestellt. Im Falle von „PIN eingeben“ wird deutlich,
dass es im Fehlerfall zu einer erneuten Abfragen kommen kann. Zur besseren Übersicht
wurden Diagramme getrennt dargestellt.
In Abbildung 4-5.3 wird der Vorgang des Signierens dargestellt. Es wird verdeutlicht,
dass nach dem bilden des Haswertes, dieser an die Karte geschickt wird, bei positiver PIN-
Überprüfung erfolgt die Berechnung der Signatur. Diese wird anschließend an die E-Mail mit
angehangen, die daraufhin zum Empfänger geschickt wird.
Die Abbildung 4-5.4 verdeutlicht den Vorgang des Entschlüssels. Hierbei wird aus der
Empfangenden E-Mail der verschlüsselte Session Key extrahiert und an die Karte geschickt,
auf der er mit dem privaten Schlüssel entschlüsselt wird. Mit dem erhaltene Key wird
daraufhin die Nachricht entschlüsselt.
39

Abbildung 4-5.5 verdeutlicht, dass bei einer falschen PIN-Eingabe der Benutzer noch
zwei weitere Möglichkeiten hat, bevor die Karte gesperrt wird.
40

ANALYSE UND ENTWURF
E-Mail-Text
eingeben
SHA-1 Hashwert
bilden
SHA-1 Hashwert
zur Karte senden
PIN abfragen
PIN falsch
Signatur wird
berechnet
PIN korrekt
Diese Funktion
wird auf der
Campuskarte
ausgeführt
Signatur an E-
Mail-Text
anhängen
signierte E-Mail
abschicken
Abbildung 4-5.3: Aktivitätsdiagramm Signieren einer E-Mail
41

vers. E-Mail-Text
+
vers. SessionKey
empfangen
vers. SessionKey
an Karte schicken
PIN abfragen
PIN falsch
SessionKey
entschlüsseln
PIN korrekt
Diese Funktion
wird auf der
Campuskarte
ausgeführt
mit SessionKey
E-Mail-Text
entschlüsseln
Entschlüsseln
erfolgreich
Entschlüsseln nicht
erfolgreich
entschlüsselter
E-Mail-Text
anzeigen
Fehler anzeigen
Abbildung 4-5.4: Aktivitätsdiagramm Entschlüsseln einer E-Mail
42

ANALYSE UND ENTWURF
Eingabe PIN
Prüfe PIN
PIN nicht richtig
PIN richtig
Warnhinweis
Eingabe PIN
Prüfe PIN
PIN richtig
PIN nicht richtig
Warnhinweis
Eingabe PIN
Prüfe PIN
PIN richtig
PIN nicht richtig
Warnhinweis
Abbildung 4-5.5: Aktivitätsdiagramm PIN eingeben
Karte gesperrt
43

5.1.6 Cryptoki
Aufgrund des Einsatzes des PKCS#11-Standards für die zu realisierende Lösung wird dieser
hier näher betrachtet.
Mit Cryptoki-API ist es Applikationen möglich sein auf kryptografische Funktionalität
einer Hard- oder Softwarekomponente zuzugreifen. Diese Komponente wird mit Token
bezeichnet. Der Anwendung soll verborgen bleiben um was für ein Token es sich handelt. Es
können damit z.B. SmartCards, HSMs 29 oder Dateien gemeint sein. Es wurde auch darauf
geachtet, dass es Cryptoki der Applikation ermöglicht gleichzeitig unterschiedliche Token zu
verwenden, aber auch andererseits mehrere Applikationen auf ein Token zugreifen zu können.
Das generelle Modell von Cryptoki sieht vor, dass es Applikationen gibt, die über die
PKCS#11-Schnittstelle auf Slots zugreifen, in denen sich Token befinden, die die kryptografischen
Funktionen bereitstellen. Als Slot wird eine Einheit bezeichnet, das einen Token ansprechen
kann, dies kann z.B. ein Chipkartenleser oder Diskettenlaufwerk sein.
Applikation 1
Applikation n
andere Sicherheitsebenen
Cryptoki
Cryptoki
Slot 1
Slot n
Token 1
Token n
Abbildung 4-5.6: PKCS#11-Token-Modell
Dadurch, dass Cryptoki einen festen Satz von Funktionen definiert, kann eine Applikation
mit unterschiedliche Token arbeiten, die diesen Satz definieren. Somit sind Standardtoken
auswechselbar. In der Realität wird aber nicht jeder Token die volle kryptografische Funktionalität
unterstützen. Dies ist aber auch nicht nötig, da die meisten Applikationen nur mit einer
Basis-Funktionalität arbeiten und nicht jeder Mechanismus benötigt wird.
Cryptoki wird im allgemeinen unter Windows Betriebsystemen als dynamische ladbare
Bibliothek (engl.: dynamic linked library, DLL), bzw. als shared library unter Linux, implementiert.
Eine statische Anbindung an die Anwendung ist auch möglich.
Wie schon angedeutet, sieht die Umgebung für Cryptoki folgendermaßen aus. Von der
Anwendung wird ein Token benutzt das in einem Slot präsent ist. Beim Datenaustausch wird
eine Session (Sitzung) aufgebaut. Man unterscheidet read-only (R/O) und read/write (R/W)
Sessions. Diese Sessions ermöglichen den Zugriff auf Objekte und Funktionen, die das Token
bereit stellt. Objekte können Attribute haben, die sie charakterisieren. Funktionen können
durch Angabe von Mechanismen unterschiedliche Bedeutung erlangen.
29
steht für “Hardware Security Module”
44

ANALYSE UND ENTWURF
Objekt
Data Schlüssel Zertifikat
Öffentlicher
Schlüssel
Privater
Schlüssel
Geheimer
Schlüssel
Abbildung 4-5.7: PKCS#11-Objekt-Modell
Es wurde schon dargestellt, dass Funktionen und verwendeter Algorithmus getrennt werden.
Es ist möglich eine Verschlüsselungsfunktion z.B. mit einem asymmetrischen oder symmetrischen
Verfahren durchzuführen.
Die einzelnen Funktionen (z.Z. gibt es über 60) des Standards kann man in verschiedene
Gruppen einteilen. Neben den Initialisierungsfunktionen gibt es Methoden, die Slots und Token
verwalten. Für Sessions und deren Informationen sind eigene Funktionen definiert. Für
Objekte, wie z.B. Schlüssel und Zertifikate, und auch für kryptografische Funktionen gibt es
eine separate Gruppe.
5.2 Entwurf
Die in der Analyse getroffene strategische Entscheidung, dass wir die Aufgabe durch ein
Schichtenmodell lösen wollen, wird im Entwurf durch konkretere Schritte beschrieben. Im
Entwurf wird die Taktik festgelegt, nach der vorgegangen wird um das Ziel zu erreichen.
Es erfolgt eine Aufteilung der Aufgaben, die in den einzelnen Schichten zu bearbeiten
sind.
5.2.1 Architekturmodell
Die Abbildung 4-5.8 zeigt auf welche Komponenten der Lösung zu implementieren sind. Der
PKCS#11-Proxy übernimmt die Kommunikation mit Netscape Messenger, der über die Security
Library angesprochen wird. Über ein Interface wird die Anbindung zu Javakomponenten
geregelt. Diese Komponenten laufen alle in einer JavaVM und unterteilen sich in Javabibliotheksklassen,
OCF-Klassen, CKAppletProxy-Klassen (nähere Erläuterungen siehe Kapitel
Spezifikation und Implementierung) und der Klassen die mit dem PKCS#11-Proxy
interagieren.
45

EMBED Visio.Drawing.5
Netscape-
Messenger
zu implementieren
JavaVM
PKCS#11-
Netscape Security
Library
PKCS#11-dll/so-
Proxy
Java-PKCS#11-
Stub
CKAppletProxy
JavaLibraries
OCF
PC/SC
Kartenleser
Campuskarte
Abbildung 4-5.8: Verteilung der Komponenten
Das Diagramm (Abbildung 4-5.9) stellt den Lösungsansatz als Schichtenmodell dar. Dabei
stellen die Schichten unterschiedliche Komponenten dar, u.a. werden Hard- und
Softwareschichten in gleicher Weise veranschaulicht.
Ein wichtiger und zentraler Aspekt der Arbeit ist es, die Durchgängigkeit von Campuskarte
zur Anwendung zu realisieren. In dem Diagramm wird verdeutlicht welche Komponenten
zu erstellen sind, welche anzupassen sind und welche in ihrer Struktur beibehalten
werden können bzw. müssen. Es kristallisierte sich heraus, dass für die Anbindung an den
Netscape Messenger eine DLL zu implementieren ist, die dem PKCS#11-Standard entspricht.
Zur Netscape Messenger-Seite hin implementiert der Programmteil den Standard. Da die vom
Security Team entwickelte Karte eine Eigenentwicklung in ihrem Programmcode ist, muss
die Java-Seite, die mit der Karte kommuniziert, unserer vorliegenden Situation angepasst,
d.h. entwickelt, werden.
Um die Lösung zu realisieren, muss die Karte die entsprechenden kryptografischen
Funktionen zur Verfügung stellen. Hierbei handelt es sich um Methoden, die Verschlüsselungen
mit den 1024 Bit RSA-Schlüsseln ausführen. Dies wird im Diagramm mit dem Ausdruck
„anpassen“ beschrieben.
Durch die Vorgabe einen Standard-E-Mail-Client zu benutzen, darf an ihm nichts
verändert oder angepasst werden. Diese Schicht der Lösung ist also starr vorgegeben.
Unveränderte Komponenten sind im Diagramm folgende Schichten: Kartenlesegerät, PC/SC-
Treiber, Open Card Framework, Java Native Interface und Netscape Messenger.
Java bietet die Möglichkeit über ein definiertes Interface Daten zwischen nativen
Programmen und Javaklassen auszutauschen, nähere Erläuterungen werden in Kapitel fünf
gegeben.
Es folgen Erläuterungen zu den Aufgaben der einzelnen Schichten.
Campuskarte: Der tragbare Token führt u.a. die kryptografischen Funktionen mit den privaten
Schlüsseln aus. Er wird über eine Java-Proxy-Klasse (CampuskarteAppletProxy) angesprochen,
siehe Kapitel 6.1.3. Die Funktionalität musste für die vorliegende Aufgabe erweitert
werden.
Kartenlesegerät: Ein Hardwaremodul, dass über den entsprechenden Treiber Daten an die
Campuskarte überträgt.
46

Campuskarte
(anpassen)
Kartenlesegerät
PC/SC-Bridge
OpenCardFramework
CampuskarteAppletProxy
(anpassen)
Java-PKCS#11 Layer
(zu implementieren)
Java Native Interface (JNI)
Native-PKCS#11 Layer (DLL)
(zu implementieren)
Netscape Messenger
Schwerpunkt
dieser Arbeit
für die Arbeit
anzupassen
fest
vorgegeben
Abbildung 4-5.9: Schichtenmodell für Lösung
48

ANALYSE UND ENTWURF
5.2.2 Vor- und Nachteile des Schichtenmodells
Aus der Sicht der Softwarearchitekten bietet ein Schichten- oder auch Layermodell neben
verschiedene Vorzüge auch unumgängliche Nachteile.
Viele der folgenden allgemeinen Vorteile treffen auch auf das vorliegende Modell zu.
Wiederverwendung von Schichten: Schichten die eine wohldefinierte Abstraktion enthalten
und ausgereifte Schnittstellen besitzen, können in anderen Kontexten wiederverwendet werden.
Unterstützung für eine Standardisierung: Programmierschichten, die sich auf allgemeine
Standards berufen können ohne Änderungen ausgetauscht werden. Im vorliegenden Fall können
Applikationen, die ebenfalls PKCS#11 konform sind mit der Software korrespondieren.
Abhängigkeiten bleiben lokal: Bei Änderungen an Hardware- oder Applikationsschnittstellen
muss nur jeweils die betroffene Schicht angepasst werden.
Austauschbarkeit: Implementierungen einzelner Softwareschichten kann durch semantisch
äquivalente Programmcode ausgetauscht werden.
Aufteilung von Teilaufgaben in verschiedenen Abstraktionsschichten: Im vorliegenden
Fall werden einige Teilaufgaben in der nativen Schicht gelöst, andere im Javalayer. Diese
Zerlegung in Teilaufgaben bietet mehr Flexibilität und kann z.B. die Performanz erhöhen.
Neben den erwähnten Vorteilen, zeichnen sich bei einem Layermodell auch folgende
Nachteile ab.
Kaskaden veränderten Verhaltens: Bei der Änderung des Verhaltens einer Schicht müssen
größere Anpassungen u.U. an mehreren Schichten erfolgen.
Geringe Effizienz: Ein Schichtenmodell ist weniger effizient als eine rein monolitische Lösung.
Hinzu kommt, dass Daten mehrfach transformiert werden müssen, was zu einer erhöhten
Fehleranfälligkeit führen kann.
Unnötige Arbeit: Die Performanz des Gesamtsystems nimmt ab, wenn niedrige Layer viele
oder redundante Arbeiten durchführen.
Schwierigkeiten bei Granulation: Die richtige Wahl zwischen wenigen oder vielen
Schichten ist oft schwierig. Eine geringe Anzahl von Schichten nutzt das Potenzial nicht völlig
aus, wobei eine zu große Zahl die Komplexität stark erhöht.
5.3 Entwurfsentscheidungen
Durch das Anforderungsmodell und der Ergebnisse aus der Analyse kam es zu Fragen, die
eine Entwurfentscheidung verlangten. Im folgenden werden die einzelnen Entscheidungen
erläutert, die es zu treffen galt.
49

5.3.1 Unterschied zwischen PKCS#11-Sessionprinzip und Campuskarte
Der PKCS#11 Standard (siehe Abschnitt 5.1.6) basiert auf dem Prinzip von Sessions, d.h.
nach einer Authentisierung gegenüber dem Token ist dieser in einem Bearbeitungszustand. In
diesem Zustand (Session) können kryptografische Funktionen auch mehrmals ausgeführt
werden, ohne dass es einer erneuten Anmeldung bedarf.
Mit der Campuskarte ist dieses Prinzip nur in Verbindung mit einem Onlinedienst
möglich. Bei den Kryptofunktionen verfolgt sie die Strategie, dass man sich für jede Methode
neu authentisieren muss, wenn sie von einem Programm aufgerufen wird.
Dies steht im Unterschied zum Authentisierungsverfahren gegenüber der Campuskarteninfrastruktur,
bei dem ein Secret Key (hier ein 3DES-Schlüssel) vereinbart wird mit dem
Daten symmetrisch verschlüsselt werden sollten sie zwischen Campuskarte und Anwendung
ausgetauscht werden.
Die Daten, die nicht zum Authentisierungsverfahren genutzt werden, dürfen nicht für die
Karte verschlüsselt werden, weil auf der Gegenseite kein entsprechender Partner (hier E-
Mail-Client) vorliegt der die Daten entschlüsseln könnte. Deshalb wurde die jeweilige Authentifizierung
für die kryptografischen Methoden der Karte eingeführt.
Aus Sicht des Benutzers und unter dem Aspekt der Benutzerfreundlichkeit ist es sinnvoller,
ein Sessionprinzip wie es der Cryptoki-Standard vorsieht durchzuführen.
5.3.2 Auswahl der Schlüssel
Das System, d.h. speziell die Campuskarte, trifft selbstständig die Entscheidung, welcher
Schlüssel beim Ausführen der kryptografischen Funktionen benutzt wird. Dies ist notwendig,
um zu gewährleisten, dass zum Entschlüsseln von Dokumenten mittels Dienstausweis, derjenige
Schlüssel benutzt wird, der im Trustcenter in einer Datenbank gespeichert ist. Der private
Schlüssel wird dort hinterlegt, um gegebenenfalls beim Ausscheiden eines Mitarbeiters
evtl. vorhandene TUB-interne Dokumente wieder entschlüsseln zu können. Dies ist auch der
Hauptgrund für das Einführen der „Eigenentscheidung“.
Hiermit ist auch die Entscheidungshilfe festgelegt, nachdem die Karte die Schlüsselwahl
durchführt, bevor eine Kryptofunktion aufgerufen wird, wird der Personenstatus kartenintern
abgefragt und erst dann wird entschieden welcher Schlüssel für die Methode angewendet
wird (siehe hierzu folgende Abbildung).
Im Falle eines Studenten ist die Wahl des Schlüssels eindeutig, weil er nur im Besitz des
Signaturschlüsselpaares ist, mit ihm werden auch Daten ver- und entschlüsselt. Dieser
Schlüssel ist geheim, d.h. nur der Student ist in seinem Besitz. Sollte deshalb der Studierendenausweis
abhanden kommen, ist der private Schlüssel unwiederbringlich verloren, d.h.
verschlüsselte Dokumente können nicht wieder entschlüsselt werden.
50

ANALYSE UND ENTWURF
Campuskarte
signiere Hash
signierter Hash
PIN verifizieren
signiere Hash mit privSignKey
verifiziere Hash
verifizierter Hash
PIN verifizieren
verifiziere Hash mit privSignKey
verschlüssele Daten
verschlüsselte Daten
PIN verifizieren
wenn PS = "Student"
dann
verschlüssele Daten mit pubSignKey
sonst
verschlüssele Daten mit pubEncKey
entschlüssele Daten
entschlüsselte Daten
PIN verifizieren
wenn PS = "Student"
dann
entschlüssele Daten mit pubSignKey
sonst
entschlüssele Daten mit pubEncKey
Abbildung 4-5.10: Entscheidung der Schlüsselwahl bei Kartenfunktionen
5.3.3 Aufgaben der Schichten
In einer frühen Phase der Entwicklung gab es die Entscheidung, dass das System nur eine
dünne Schicht des nativen Codes hat, d.h. es sollte die Funktionalität in der Javaschicht haben.
Während der Analyse hatte sich jedoch herausgestellt, dass es für viele PKCS#11
Funktionen praktikabler ist, sie vollständig im nativen Programmierteil zu realisieren. Für
den Aufruf von Methoden, die nur zu Konfigurationszwecken gedacht sind, ist es zum einen
performanter sie in einem schnellen nativen Teil abzuarbeiten, zum anderen verlangen diese
Funktionen keine kryptografischen oder andere komplizierte Berechnungen, die den Einsatz
einer hohen Programmiersprache rechtfertigen würden.
Das Ergebnis dieser Entwurfsentscheidung ist in einem ersten prototypischen
Implementierungsschritt nur die Funktionen in Java zu implementieren, die tatsächlich einen
Campuskartenzugriff verlangen.
Dies sind im einzelnen die PKCS#11-Funktionen C_UnwrapKey und C_Sign. Die
Funktion C_UnwrapKey wird beim Vorgang der Entschlüsselung einer Nachricht
aufgerufen, d.h. es wird mit ihr ein 3DES-Schlüssel mittels des Private Keys der Karte
51

entschlüsselt. C_Sign wird beim Erstellen einer digitalen Signatur aufgerufen, bei der
ebenfalls ein privater Schlüssel zum Einsatz kommt.
5.3.4 Erstellen der JavaVM
Zum Ausführen des Kartenzugriffs über Javamethoden ist es erforderlich, dass eine virtuelle
Java Maschine gestartet wird. Dieser Aufruf ist an mehreren Positionen im Ablauf einer Sitzung
möglich.
Die Entwurfsentscheidung sieht vor, dass die JVM nur dann gestartet wird, wenn es auch
tatsächlich zu einem Kartenzugriff kommt. Da es kein Sessionkonzept gibt, wird die Java
VM bei jedem Aufruf der Methoden C_Sign und C_UnwrapKey neu gestartet.
Durch den enormen Ressourcenverbrauch einer Virtuellen Maschine ist es nicht perfomant
diese z.B. beim Aufruf der Methode C_Initialize zu initialisieren, weil dadurch
eine ständige Systembelastung auftreten würde.
5.3.5 PKCS#11 Flags
Im PKCS#11 Standard ist vorgesehen, dass einzelne Token- und Bibliothekseigenschaften
durch das Setzen von Flags (beginnend mit CKF_) aufgezeigt werden. Eine
Entwurfsentscheidung musste für einige von ihnen getroffen werden.
Für alle Funktionen die nicht implementiert sind verlangt das Programm, dass es als
Rückgabewert CKR_FUNCTION_NOT_SUPPORTED erhält.
Beim Aufruf der Funktion C_GetSlotInfo wird für die prototypische Version das
CKF_REMOVABLE_DEVICE Flag nicht gesetzt. Dafür muss aber das Flag
CKF_TOKEN_PRESENT gesetzt sein, damit der Aufruf von weiteren Funktionen möglich
ist. Im vorliegenden Fall handelt es sich um ein „tragbares“ Token, dass nicht immer im Leser
(Slot) verbleibt. Diese beschriebene Designentscheidung wurde getroffen um die technische
Machbarkeit leichter zu demonstrieren.
Beim Aufruf der Funktion C_GetTokenInfo wird das Flag
CKF_WRITE_PROTECTED gesetzt, damit die Netscape Security Library dieses Token nicht
für die Generierung von Schlüsseln benutzt. Dies ist nötig, weil die Campuskarte diese
Funktionalität nicht bietet.
Die Kombination der zwei Flags CKF_LOGIN_REQUIRED und
CKF_USER_PIN_INITIALIZED wird von Netscape unterschiedlich gedeutet. Im vorliegenden
Fall werden beide Flags auf false gesetzt, weil damit sicher gestellt ist, dass die Campuskarte
ihr eigenen PIN-Abfragemechanismus benutzt. Eine Auflistung über Bedeutung der
anderen Kombinationen, sowie weitere Hinweise findet der Leser im Dokument [IPLANE].
Eine Übersicht wird in Tabelle 4-5.1 dargelegt.
Flag Wert Bedeutung
CKF_REMOVABLE_DEVICE false Ist es ein tragbares Token? Wegen
Vereinfachung auf false gesetzt
52

ANALYSE UND ENTWURF
CKF_TOKEN_PRESENT true Ist das Token im Leser? Wegen
Vereinfachung auf true gesetzt
CKF_WRITE_PROTECTED true Ist das Token schreibgeschützt? Ja, denn
es können keine privaten Schlüssel auf
dem Token generiert werden.
CKF_LOGIN_REQUIRED false Ist eine Anmeldung erforderlich? Dies
übernimmt OCF, deshalb false.
CKF_USER_PIN_INITIALIZED false Ist PIN initialisert? Dies übernimmt
OCF, deshalb false.
5.3.6 Externe Zertifikate
Tabelle 4-5.1: Übersicht Flags
Zur Zeit ist es aus technischen Gründen nicht realisierbar, Zertifikate auf der Campuskarte
abzulegen, deshalb muss die Entscheidung getroffen werden, wie damit umzugehen ist.
Im vorliegenden Fall wird diese Problematik dadurch umgangen, dass die Zertifikate aus
einer lokalen Datei gelesen werden, die vom PKCS#11-Modul angesprochen wird. Hierfür
liegen die Zertifikate in einem definierten Verzeichnis, mit definierten Namen. Die Zertifikate
müssen im binären DER-Format vorliegen, damit sie vom E-Mail-Client interpretierbar
sind.
Diese Lösung ist in einer späteren Version der Software anzupassen, wenn es die Kapazität
der eingesetzten Karten erlaubt die Zertifikate auch direkt im Datenmodell abzulegen. In
Abbildung 4-5.11 wird dargelegt, wie die einzelnen PKCS##11-Funktionen
(C_GetAttributeValue und C_Sign) auf unterschiedliche Daten (Schlüssel, Zertifikat)
zugreifen.
lokaler Computer
Messenger
signierte Email
Empfänger
PKCS#11-DLL
Methode
C_GetAttribute
Value sucht u.a.
nach Zertifikaten
Methode C_Sign
führt die
Signaturfunktion
aus
LDAP
Möglichkeit (nicht
implementiert)
lokale Datei mit
Benutzerzertifikat
CampusKarte
mit privatem
Schlüssel und
Signaturfunktion
5.4 Ablaufdarstellung
Abbildung 4-5.11: lokales Zertifikat
Im folgenden wird exemplarisch ein Ablauf beschrieben, wie die Soft- und Hardware bei der
Entschlüsselung einer E-Mail vorgeht:
1. Zuerst wird eine verschlüsselten E-Mail in Netscape Messenger aufgerufen.
53

Dies wird nicht vorher angezeigt, man erkennt es am öffnen der PIN-Eingabe.
2. Intern wird u.a. die Funktion C_Unwrapkey aufgerufen, ihr wird ein 128 langes
Bytearray übergeben, dies ist der Secret Key des hybriden Verfahrens.
3. In C_Unwrapkey wird die JavaVM gestartet, damit der Kartenzugriff über OCF
möglich ist, dies erfolgt mittels der AufrufAPI des Java Native Interfaces (JNI).
4. In C_Unwrapkey wird die Klasse „mykey_mng.class“ gesucht, realisiert durch JNI.
5. Die Java-Methode C_UnwrapKey wird gesucht, sie hat den gleichen Namen, wie die
C-Funktion. Dies wird auch durch JNI ermöglicht.
6. Die Methode C_UnwrapKey wird aufgerufen, dabei wird ein Bytearray (der
verschlüsselte Secret Key) übergeben.
7. Die Kartenproxyfunktion decryptRSA wird aufgerufen (mit dem übergebenen
Bytearray).
8. Die PIN-Eingabe wird von der Karte gefordert (durch ein Eingabefenster erkennbar).
9. Die Karte gibt ein entschlüsseltes Bytearray zurück, dies ist 24 Bytes lang (entspricht
Länge eines 3DES-Schlüssels).
10. Das Bytearray wird an Native-Schicht zurückgegeben. Das Array und die Arraylänge
wird „kurz“ über ein Objekthandle verwaltet.
11. Die Funktion C_GetAttributeValue wird aufgerufen, um den Wert des 3DES-
Schlüssels abzufragen
12. Netscape Messenger entschlüsselt intern die E-Mail mit vorliegendem 3DES-
Schlüssel.
13. C_DestroyObject wird aufgerufen, um den nicht mehr benötigten Secret Key zu
löschen
14. Die entschlüsselte E-Mail wird angezeigt (mit „positiv“-Markierung).
Um einen kurzen Eindruck zu erlangen, welche Funktionen in welcher Reihenfolge aufgerufen
werden, die einzelnen Phasen im Überblick.
Bei der Initialisierung der Bibliothek werde nacheinander folgende Funktionen aufgerufen:
1. C_GetFunctionList
2. C_Initialize
3. C_GetInfo
4. C_GetSlotList
5. C_GetSlotInfo
6. C_GetTokenInfo
7. C_GetMechanismList
8. C_OpenSession
9. C_FindObjectsInit
10. C_FindObjects
11. C_FindObjectsFinal
12. C_GetAttributeValue
13. C_GetSessionInfo
Wenn eine E-Mail signiert wird, erfolgt der Aufruf von:
1. C_SignInit
2. C_Sign
Bei der Entschlüsselung einer Nachricht werden diese sechs Methoden benutzt:
1. C_FindObjectsInit
2. C_FindObjects
3. C_FindObjectsFinal
54

4. C_UnwrapKey
5. C_GetAttributeValue
6. C_DestroyObject
ANALYSE UND ENTWURF
Wenn die DLL nicht mehr benötigt wird, werden als Abschluss folgende zwei Funktionen
aufgerufen:
1. C_CloseAllSessions
2. C_Finalize
55

6 Spezifikation und Implementierung
In diesem Kapitel werden die in der Analyse und im Entwurf getroffenen Entscheidungen
genauer spezifiziert und durch die beschriebene Implementierung in die Praxis umgesetzt.
6.1 Spezifikation
Im ISP-Vorgehensmodell gibt es keinen eigenes Spezifikationskapitel. Im Modell ist dafür
der Detailentwurf vorgesehen. Um den Übergang zwischen Entwurf und Implementierung
deutlicher darstellen zu lassen wurde der Punkt der Spezifikation dazwischen platziert.
6.1.1 Native-Code
Im folgenden werden die Funktionen beschrieben, die auf der nativen Seite implementiert
wurden. Diese sind in der Programmiersprache C realisiert.
Da diese Methoden dem PKCS#11-Standard entsprechen müssen, sind die Aufrufsignaturen
festgelegt. Die Sourcen sind angelehnt an die Programmstruktur des GNU PKCS#11-
Moduls, siehe [GNUP11], aus dem auch teilweise Hilfsfunktionen übernommen wurden, z.B.
die Debugfunktion CI_LogEntry.
In Tabelle 5-6.1 werden die PKCS#11-Funktionen beschrieben, die tatsächlich von Netscape
Messenger aufgerufen werden.
PKCS#11-Funktion
C_CloseAllSessions
C_DestroyObject
C_Finalize
C_FindObjects
C_FindObjectsFinal
C_FindObjectsInit
C_GetAttributeValue
C_GetFunctionList
C_GetInfo
C_GetMechanismList
C_GetSessionInfo
C_GetSlotInfo
C_GetSlotList
Beschreibung
wird bei Beendigung der Anwendung aufgerufen, alle
Sessionhandles werden gelöscht
wird hier von der Anwendung benutzt um einen SessionKey
nach erfolgreicher Entschlüsselung zu löschen
wird aufgerufen, wenn die Cryptoki-Bibliothek nicht mehr
gebraucht wird
wird von Applikation benutzt, um z.B. nach Zertifikaten und
Schlüsseln auf Token zu Suchen
beendet einen C_FindObjects-Aufruf
initialisiert einen C_FindObjects, dabei wird ein
Template des Objektes übergeben, nach dem gesucht wird
gibt für ein angegebenes Objekt den Wert des angeforderten
Attributs zurück
gibt eine vollständige Cryptoki-Funktionsliste zurück, auch
wenn diese nicht alle von der Hardware unterstützt werden
gibt generelle Informationen über die Cryptoki-Bibliothek
zurück
gibt die Mechanismen zurück, die vom Token unterstützt
werden
gibt Informationen über eine Session zurück
gibt Informationen über den eingesetzten Slot an die Anwendung
zurück
gibt IDs für Slots zurück, die von der Anwendung genutzt
werden können
56

C_GetTokenInfo
C_Initialize
C_OpenSession
C_Sign
C_SignInit
C_UnwrapKey
SPEZIFIKATION UND IMPLEMENTIERUNG
gibt Informationen über ein Token zurück, die von der Anwendung
genutzt werden kann
wird von Anwendung als erstes aufgerufen, um die Bibliothek
zu starten
öffnet eine Session zwischen Anwendung und Slot
wird hier benutzt, um ein Datenblock (Hashwert) zu signieren,
hier mittels Campuskarte und Javaschicht
Initialisierungsmethode des Signaturvorganges, bei dem u.a.
der Mechanismus und die Schlüssel-ID angegeben werden,
mit denen C_Sign durchgeführt wird
wird aufgerufen, um ein verschlüsselten SessionKey wieder
zu entschlüsseln, dies erfolgt hier mit Hilfe der Campuskarte
über die Javaschicht
Tabelle 5-6.1: Aufgerufene PKCS#11-Funktionen
exemplarisch wird anhand einer vollständigen Funktionssignatur die Vorgehensweise bei
PKCS#11-Funktionen gegeben
Bsp. C_Sign
/* C_Sign */
CK_DEFINE_FUNCTION(CK_RV, C_Sign)(
CK_SESSION_HANDLE hSession,
CK_BYTE_PTR pData,
CK_ULONG
ulDataLen,
CK_BYTE_PTR pSignature,
CK_ULONG_PTR
pulSignatureLen
)
hierbei ist:
hSession – eine long-Wert, der die Session eindeutig bestimmt
pData – ist ein Pointer zu einem Bytefeld, im vorliegenden Fall der SHA-1 Hashwert
ulDataLen – die Länge des Hashwertes, hier 35 Bytes (15 Bytes SHA-Header + 20 Bytes
SHA-Hashwert)
pSignature – Pointer, der am Ende der Funktion auf die errechnete Signatur zeigt
pulSignatureLen – Pointer auf die Länge der errechneten Signatur, wegen vorliegendem
RSA-Schlüssel hier 128 Bytes (1024Bit)
Die folgende Funktion wird benutzt, um ein Zertifikat aus einer Datei einzulesen.
CK_DEFINE_FUNCTION(void, CI_ReadCert)(
)
Nachfolgende Methoden wurden für Debug- und Analysezwecke eingeführt, d.h. sie sind für
die Anwendung aus Sicht des PKCS#11-Standards nicht relevant:
// Gibt einen String aus fuer ein CK_ATTRIBUTE_TYPE zurueck
CK_DEFINE_FUNCTION(CK_CHAR, CI_GetAttributeTypeAsString)(
CK_ATTRIBUTE_TYPE attributeType
)
57

Gibt einen String aus fuer eine CK_OBJECT_CLASS zurueck
CK_DEFINE_FUNCTION(CK_CHAR, CI_GetObjectClassAsString)(
CK_OBJECT_CLASS objectClass
)
6.1.2 Java-Code
Die Klassen und Methoden, die über das Java Native Interface von der Native-Seite in Java
aufgerufen werden haben die gleichen Bezeichnungen. Sie unterscheiden sich nur entsprechend
der durch die Programmiersprache definierten Endung.
Der Programmcode auf der Javaschicht besteht aus den Klassen mysign.class und
mykey_mng.class, diese sind für die kryptografischen Funktionen konzipiert und übertragen
die Daten von der Native-Seite zur Campuskarte. Als Hilfsklasse fungiert
Logfile.class, welche die Debugausgaben in ein Logfile, hier benutzt
myjavalog.txt, übernimmt. Diese Datei wird auch in anderen Paketen der Campuskartensoftware
zur Analyse benutzt. Die Javaklassen gehören alle zum Package
campuskarte.cksem und werden mit dem Makefileaufruf „make“ übersetzt.
die Signatur zentraler Javamethoden:
public static byte[] C_Sign(byte[] ba) throws Exception
ba – ein Bytearray, das die zu signierenden Daten enthält, im vorliegenden Fall ist dies ein
SHA-1-Hashwert nach PKCS#1 Spezifikation (Länge 20 Bytes, der Header wird vom
SignatureProxy erzeugt, siehe nächsten Abschnitt)
Rückgabewert: Bytearray, des RSA-verschlüsselten (signierten) Eingabewertes, Länge 128
Bytes
public static byte[] C_UnwrapKey(byte[] ba) throws Exception
ba – ein Bytearray, das die zu entschlüsselnden Daten enthält, hier ist dies ein RSAverschlüsselter
3DES-Schlüssel (Länge 128 Bytes)
Rückgabewert: Bytearray, das die RSA-entschlüsselten Daten enthält
Beide Methoden sind als static definiert. Sie erwarten beide ein Bytearray als Eingabeparameter,
welches im nativen Code generiert und dann an die Javamethoden übergeben wird.
Dieses Array liegt jeweils in einer Form vor mit der die Karte bzw. der CampuskarteAppletProxy
arbeiten kann, das bedeutet sie müssen innerhalb der Methode nicht angepasst
werden. Es wird jedoch methodenintern geprüft, ob es sich um die richtige Länge handelt. Im
Falle con C_Sign sind dies 20 Bytes und im Falle von C_UnwrapKey sind dies 128 Bytes.
Ebenso verhält es sich mit den Rückgabewerten, die auch jeweils ein Bytearray repräsentieren.
Diese Felder werden wieder dem nativen Code übergeben, in dem sie dann an das
Programm weitergeleitet werden. Die Länge der Rückgabewerte ist aufgrund der Schlüssellänge
der RSA-Paare definiert. Die Methode C_Sign gibt 128 Bytes zurück, welches der Moduluslänge
entspricht. Ein entschlüsselter 3DES-Schlüssel hat die Länge von 168 Bit, mit Paritybits
entspricht das einer Länge von 24 Bytes, dies ist auch die Länge des Rückgabewertes
der C_Unwrapkey-Methode.
58

SPEZIFIKATION UND IMPLEMENTIERUNG
In Beiden Klassen gibt es eine Methode, die das Interface CHVDialog des Open Card
Frameworks implementiert, um eine eigene Anzeige für die PIN-Eingabe zu generieren, damit
nicht der vorgegebene Standarddialog benutzen werden muss.
Diese Methode hat folgende Signatur:
public String getCHV(int chvNumber)
chvNumber – Der int-Wert gibt den Index für die entsprechende PIN an,
im vorliegenden Fall ist “0” der Index der Standard-PIN
Die Hilfsklasse für die Logfileasugabe enthält enthält folgende zwei Methoden:
public static void createlogfile(String logname) throws Exception
logname – Der String repräsentiert Pfad und Name der Logfiledatei,
z.B. “c:\myjavalog.txt”
public static void writelog(String information) throws Exception
information -
Der String repräsentiert einen Logfileeintrag, dieser wird dann im
Logfile mit Datum und Uhrzeit eingetragen,
z.B. “Exception in Methode: C_Sign”
6.1.3 CampuskarteAppletProxy-Funktionen
In diesem Abschnitt werden die Methoden beschrieben, die direkt den Zugriff auf die Karte
durchführen, dies soll zur besseren Veranschaulichung des Schichtenkonzepts der vorliegenden
Lösung beitragen. Für das bessere Verständnis vom Zusammenspiel der einzelnen Programmierschichten
sind sie hier kurz erläutert.
Die Methoden sind Bestandteil einer Klassenhierarchie, die alle als Proxyfunktionalität
agieren für die eigentlichen Funktionen, die direkt auf der Karte ausgeführt werden. Eine
Ausführliche Darstellung der Cardlet 30 -Funktionen findet sich in [SUHR02].
Funktionen, die direkt Daten mit der Karte austauschen sind:
im SignatureProxy:
public byte[] signHash(PrivateKeyRef key, byte[] data)
data – Bytearray, das den Hashwert repräsentiert, der signiert werden soll
key – ein Schlüsselreferenzierungs-Objekt, im vorliegenden Fall wird null übergeben,
damit die Karte aufgrund des Personenstatus selbst die Entscheidung trifft, welchen
Schlüssel sie benutzt, um die Funktion auszuführen.
Rückgabewert: ein Bytearray, die Daten data PKCS#1-verschlüsselt (signiert)
Das Kommando wird auf der Karte mit folgenden Parametern aufgerufen:
30
In Anlehnung an Java Applets wird der Code auf der JavaCard auch Cardlet genannt.
59

Parameter Beschreibung
CLA CLA_CAMPUSKARTE
INS INS_SIGN_HASH
P1 00h oder Schlüsselreferenz Byte 1
P2 00h oder Schlüsselreferenz Byte 2
LC
Länge der übertragenden Daten
DATA SHA1-Hashwert im DER-Format
Tabelle 5-6.2: Parameter für Signaturfunktion
Der Parameter DATA erwartet den Hashwert im DER Format, der im PKCS#1 definierte
SHA1-Header wird durch den AppletProxy vorangestellt. Insgesamt hat er eine Länge von 35
Bytes (15 Bytes definierter SHA1-Header und 20 Bytes Hashwert) und ist hexadezimal, wie
folgt definiert:
30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 | SHA1-Hashwert (20 bytes).
Der Rückgabewert dieser Funktion ist bei einer erfolgreichen Durchführung des Kommandos
ein Bytearray mit 128 Bytes, dies entspricht dem digitalen Signaturwert des PKCS#1-Standards.
im CryptoProxy:
public byte[] decryptRSA(PrivateKeyRef key, byte[] data)
data – Bytearray, das die Daten repräsentiert, die entschlüsselt werden sollen
key – ein Schlüsselreferenzierungs-Objekt, Erklärung s.o.
Rückgabewert: ein PKCS#1-entschlüsseltes Bytearray
Das Kommando wird auf der Karte mit folgenden Parametern aufgerufen:
Parameter
CLA
INS
P1
P2
LC
DATA
Beschreibung
CLA_CAMPUSKARTE
INS_DECRYPT
00h
00h
Länge der zu entschlüsselnden Daten
zu entschlüsselnde Daten (max. 128 Bytes)
Tabelle 5-6.3: Parameter für Entschlüsselungsfunktion
Durch die Einschränkungen des JavaCard-APIs ist die maximale Länge der RSA Verschlüsselung
auf 117 Bytes begrenzt (Länge des Modulus des RSA-Schlüssels in Bytes minus 11).
Es kann daher ein RSA-Block mit maximal 128 Bytes Länge entschlüsselt werden.
Mit welchem Schlüssel die Methode durchgeführt wird hängt vom Personenstatus (PS)
des Datenmodells Campuskarte des Karteninhabers ab. Ist im Personenstatus ein „s“ für Student
gesetzt, wird die Entschlüsselung mit dem privaten Signaturschlüssel (SKS) durchgeführt,
andernfalls mit dem privaten Verschlüsselungsschlüssel (CHE).
60

SPEZIFIKATION UND IMPLEMENTIERUNG
Der Rückgabewert im Fehlerfall für alle Funktionen ist:
SW1 SW2 Beschreibung
ISO7816 SW_SECURITY_STATUS_NOT_SATISFIED Die PIN wurde nicht verifiziert
oder ein sonstiger Fehler ist
aufgetreten
6.2 Implementierung
Tabelle 5-6.4: Rückgabewert im Fehlerfall
Die Umsetzung der Spezifikation wurde auf einem Microsoft NT 4.0 System durchgeführt
mittels der Programmierumgebung Microsoft Visual C++. Eine bash-Shell 31 unter Windows
wurde für Kommandozeilentools, wie make und CVS, eingesetzt.
6.2.1 Versionskontrolle durch Einsatz von CVS
Die Sourcen des gesamten Projekts werden durch die Opensource Software CVS verwaltet.
CVS steht für „Concurrent Version System“, weitere Informationen über Versionen und Befehlen
finden sich unter www.cvshome.org. Die Entscheidung für CVS folgt aus den Erfahrungen,
die im Laufe des Projekts gezogen worden sind und dadurch, dass es eine leichte
Einbindung in den bereits erstellten Programmcode gibt. Als Vorteile des CVS-Systems sind
die guten Verwaltungsmöglichkeiten von verteiltem Benutzercode und die Möglichkeiten von
verzweigten Quellcodebäumen zu nennen.
Bei der Verwaltung der Dateien muss darauf geachtet, ob es sich um ASCII oder Binärdateien
handelt. Das Hauptverzeichnis auf dem Server ist „secteam“, unter dem alle anderen
Projektdateien und Verzeichnisse liegen. Die Verzeichnisse für das cksem-Modul liegen unter
„secteam/campuskarte/cksem“ und „secteam/campuskarte/cksem/Debug“. Die Struktur
der Programmsourcen werden in Abschnitt 6.2.2 beschrieben.
Für CVS gibt es auch bereits grafische Benutzerschnittstellen, mit denen z.B. unter Windows
leichter gearbeitet werden kann. In dieser Arbeit kam das Kommandozeilentool zum
Einsatz, das über eine bash-Shell angesprochen wurde.
6.2.2 Die Struktur der Programmsourcen
Es folgt eine tabellarische Auflistung der Programmsourcen mit ihren dazugehörigen Verzeichnissen.
Alle Dateien liegen auf dem CVS-Server des Projektes in dem Hauptverzeichnis
„secteam/campuskarte/“.
Unterverzeichnis Dateien Beschreibung
cksem
Makefile,
myXXX.c,
myXXX.h,
myXXX.java
cksem.XXX
zum Übersetzen der Javaklassen
C-Native-Dateien
C-Header-Dateien
Java-Dateien
Konfigurationsdateien für Visuell C++
31
hierfür wurde „cygwin“ eingesetzt, mit der man ein Komandozeilen Tool zur Verfügung hat, in
dem sich u.a. Linuxbefehle ausführen lassen, Quelle siehe Kapitel 9.6
61

Debug
cksem.dll
cksem_install.html
Enddatei nach Übersetzung der
Sourcen
Installationsseite mit JavaScript
cert7.db
key3.db
secmod.db
modutil.exe
pk11test.exe
regress.exe
Tabelle 5-6.5: Struktur der Programmsourcen
Testprogramme und Hilfsdateien zur
Simulation u.a. von Anmeldung der
DLL, bereitgestellt von Netscape bzw.
Mozilla
Info: myXXX steht für Dateinamen des Native- bzw. Java-Codes, z.B. mysign.c
6.2.3 Java Native Interface
Mit dem Java Native Interface (JNI) können Java-Funktionen aus einer nativen Programmiersprache
aufgerufen werden und umgekehrt. Es ist dafür auch möglich eine Virtuelle Maschine
32 (VM) für die Javaklassen zu starten.
Dieses Interface wurde zur Realisierung des Schichtenmodells der Aufgabe genutzt, um
über das auf Java basierende OpenCardFramework von Netscape Messenger aus auf die
Campuskarte, die ebenfalls javabasiert ist, zuzugreifen.
JNI stellt eine Reihe von Grundfunktionen zur Verfügung, mit denen nach dem Starten
einer Virtuellen Maschine nach Klassen und Methoden in jar-Dateien gesucht werden kann.
Da der native Teil der Software eine DLL darstellt, die in der Programmiersprache C geschrieben
wurde, werden die entsprechenden JNI-Funktionen für diese Sprache genutzt.
Um eine VM zu starten ist die Angabe von folgendem Codesegment nötig:
options[0].optionString = "-Djava.class.path= c:\\. . .
options[1].optionString = "-verbose:jni";
memset(&vm_args, 0, sizeof(vm_args));
vm_args.version = JNI_VERSION_1_2;
vm_args.nOptions = 2;
vm_args.options = options;
status = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
Hierbei ist mit der Angabe des Wertes der Option “java.class.path“, der Pfad zu den eigenen
Klassendateien gemeint, die dann über das JNI angesprochen werden. Zum starten der VM
wird die DLL „jvm.dll“ benötigt, die im Systempfad stehen muss, sofern die Zuordnung nicht
dynamisch im Programmcode durchgeführt wird. Die Variable status ist vom Typ long
und gibt einen Wert zurück, der im Fehlerfall einen negativen Wert vom Typ JNI_ERR
angibt. Im Erfolgsfall ist dies 0. Der Aufruf JNI_CreateVM gibt einen Zeiger jvm auf die
VM zurück. Der Zeiger env verweist auf die ausführende Umgebung. Mit dem Array
options können verschiedene Variablen beim Aufruf gesetzt werden, siehe hierzu auch
[HORS00]. Die wichtigste Funktion der Aufruf-API, die mit dem Zeiger jvm ausgeführt
werden kann ist die zum Beenden der Virtuellen Maschine:
32
wird auch als JavaVM oder JVM bezeichnet
62

(*jvm)->DestroyJavaVM(jvm);
SPEZIFIKATION UND IMPLEMENTIERUNG
Zum Aufruf einer statischen Methode ist es zunächst unerlässlich die entsprechende Klasse
zu finden, dazu wird der Zeiger env und die JNI-Funktion FindClass benutzt. Anschließend
wird die Methoden-ID der entsprechender Methoden-Signatur gesucht, durch
GetStaticMethodID. Hierbei bedeutet die Angabe "([B)[B", dass die Methode
C_Sign ein Bytearray als Eingabeparameter und als Rückgabewert erwartet. Erst danach
kann der Aufruf der statische Methode durch die JNI-Funktion
CallStaticObjectMethod erfolgen. Die letzte Variable (jbaData) der Aufrufparameter
ist das Bytearray, das der Javamethode übergeben wird. Der Rückgabewert (das Bytearray)
der Javamethode wird in die Variable returnedJbaData geschrieben, die vom
JNI-Typ jbyteArray ist.
class_mysign=
(*env)->FindClass(env,"campuskarte/cksem/mysign");
id_C_Sign=
(*env)->GetStaticMethodID(env,class_mysign,"C_Sign","([B)[B");
returnedJbaData=(jbyteArray)
(*env)->CallStaticObjectMethod
(env,class_mysign,id_C_Sign,jbaData);
Um ein Bytearray als Eingabeparameter und als Rückgabewert durch die Javamethoden verarbeiten
zu können müssen diese durch entsprechende JNI-Funktionen jeweils in den nativen
bzw. javabasierten Typ umgewandelt werden. Hierzu werden folgende Aufrufe benutzt:
(*env)->SetByteArrayRegion
(env, (jbyteArray)jbaData, 0 , 20, (jbyte*)byteDataArray);
(*env)->GetByteArrayRegion
(env, returnedJbaData, 0, 128, pSignature);
Für die PKCS#11-Funktionen ist die Angabe der Vektorlänge entscheidend. Um diesen Wert
eines Javaarrays zu erhalten, gibt es folgenden JNI-Aufruf:
*pulSignatureLen=
(CK_ULONG)(*env)->GetArrayLength(env,returnedJbaData);
63

7 Installation, Konfiguration und Tests
Aus der Implementierung folgt der Programmcode, der laut ISP-Modell zur Testphase führt.
Bevor das System getestet und eingesetzt werden kann, muss es nach folgenden Ausführungen
richtig installiert und konfiguriert werden.
7.1 Technische Voraussetzungen
Für ein Anwendungssystem sind folgende technische Komponenten erforderlich. Ein
Kartenleser mit funktionierendem OCF-Treiber, d.h. es kann über die PC/SC-Bridge oder
direkt über OCF, angebunden sein. Hierzu gehört auch die Installation einer Java Runtime
Environment, vorzugsweise Version 1.3.1_0x, dass ebenfalls von OCF benötigt wird. Als E-
Mail-Client muss ein Netscape Messenger der Version 4,7x vorhanden sein. Eine neuere
Version, z.B. Mozilla oder Netcsape 7, ist theoretisch auch benutzbar.
Als JavaCard wird eine aktuelle Campuskarte benötigt, welche mit dem aktuellen Cardlet
initialisiert und mit Anwenderdaten personalisiert sein muss. Die dazugehörigen Signaturund/oder
Verschlüsselungszertifikate müssen in einem DER-Dateiformat vorliegen.
7.2 Installation
Für die Installation der Dynamic Linked Library „cksem.dll“ gibt es mehrere Wege, die in
den zwei folgenden Unterabschnitten beschrieben werden. Für den Einsatz der Software ist es
allerdings notwendig noch weitere Soft- bzw. Hardwarekomponenten zu installieren.
Ein Kartenleser mit entsprechenden Treibern ist Voraussetzung für die
Kartenkommunikation. Die Javaklassen für diese Kommunikation müssen ebenfalls auf dem
Anwendersystem installiert sein. Zu ihnen gehören natürlich die cksem-Klassen, die sich im
jar-File cksem.jar befinden. Hilfsklassen, die für das Open Card Framework benutzt werden,
sind ebenfalls nötig. Diese werden im Zusammenhang mit der Campuskarteninstallation, mit
dem auch das Java JRE installiert wird, durchgeführt.
7.2.1 Über Kryptografische Module-Dialogbox (Netscape Messenger 4.7x)
Netscape Messenger bietet dem Benutzer durch eine Dialogbox die Unterstützung ein neues
kryptografisches Modul zu installieren. Hierfür muss das Fenster mit den Security Infos geöffnet
werden, dies ist entweder über den Menüpunkt Communicator/Tools/Security Info
möglich oder durch Anklicken des Sicherheitsbuttons (kleines Schloss) in der Fußzeile des
Browsers.
In diesem geöffneten Fenster wählt man den Menüpunkt „Cryptographic Modules“ aus.
dadurch werden einem auf der rechten Seite die bereits installierten Module angezeigt, hierzu
gehört auch das interne PKCS#11 Modul von Netscape, dass Grundfunktionen ausführt, die
Netscape auch ohne externes Modul anbietet (siehe Abbildung 6-7.1).
64

INSTALLATION, KONFIGURATION UND TESTS
Abbildung 6-7.1: Auflistung der kryptog. Module bei Netscape 4.7x
Nach de Betätigung des Buttons „Add“ öffnet sich für den Benutzer eine zweite Dialogbox,
in dem der Name des Sicherheitsmoduls und deren Pfad eingetragen werden muss (siehe
Abbildung 6-7.2). In die erste Zeile wird ein geeigneter Name für das Modul eingetragen, der
frei wählbar ist, z.B. „cksem“ oder „Campuskarten Security Modul“. In die zweite Zeile muss
der vollständige Pfad (plus Dateiname) zum Sicherheitsmodul angegeben werden. Dieser ist
lautet nach der Installation der Campuskartensoftware wie folgt:
C:\Programme\Campuskarte\cksem\pkcs11\cksem.dll
Der Pfad und der Dateiname sind nicht frei wählbar, sondern beziehen sich auf die vorhandene
Datei (DLL).
Die Installation bei Mozilla und Netscape 7 verläuft ähnlich. Bei diesen Programmen
wird über den Menüpunkt „Bearbeiten/Einstellungen/Privatsphäre & Sicherheit/Zertifikate/Sicherheitseinrichtungen
verwalten“ ein externes Modul angemeldet. Der
Vorteil ist, dass durch eine Dateiselectorbox nach der DLL auf der Festplatte gesucht werden
kann.
65

Abbildung 6-7.2: Dialogfeld zum Eintragen eines neuen kryptog. Moduls bei Netscape 4.7x
7.2.2 Über JavaScript-Seite
Im Verzeichnis secteam/campuskarte/cksem/Debug befindet sich die Datei „ckseminstall.html“,
mit der es möglich ist das kryptografische Modul „cksem.dll“ über die Funktionalität
einer JavaScript-Seite zu installieren und zu löschen.
Bei dieser Methode ist darauf zu achten, dass sich der Browser im Verzeichnis der Anwendungs-DLL
befindet, da ansonsten die Datei „cksem.dll“ nicht von JavaScript gefunden
wird. Dies wird z.B. erreicht, in dem man über den Menüpunkt Datei-Seite laden die Datei
der html-Seite auswählt.
Der Einsatz von Javascript ist aus sicherheitsrelevanter Sicht nicht geeignet, weil es der
Skriptsprache möglich ist verschiedene ungewünschte und vom Benutzer nicht kontrollierbare
Funktionen auszuführen, welche das EDV-System kompromittieren bzw. angreifen
kann. Im vorliegenden Fall wird der Einsatz von JavaScript damit begründet, dass die html-
Datei nicht über das Internet geladen wird und es dem ungeübten Anwender erleichtert werden
soll, das angegebene Sicherheitsmodul zu installieren.
Das Modul wird mit dem Namen „cksem“ in die Liste der kryptografischen Module eingetragen,
nach Betätigung des Buttons „Register cksem PKCS#11“. Um das Modul zu löschen,
muss es unter dem Namen „cksem“ im Modul eingebunden sein. Das Löschen erfolgt
durch Betätigung des Buttons „Deregister cksem PKCS#11“.
Im Fehlerfall gibt es einen Warnhinweis an den Benutzer, der durch eine Fehlernummer
noch genauer spezifiziert wird.
Fehlernummer Bedeutung
-5 es wurde schon mal versucht ein Modul ohne Neustart zu installieren
-10 Modul unter diesem Namen schon installiert

INSTALLATION, KONFIGURATION UND TESTS
lich bekannt sein dürfen, ist es auch kein Sicherheitsrisiko, diese lokal auf der Festplatte zu
speichern, damit sie vom E-Mail-Client benutzt werden können.
Die derzeitige Lösung sieht vor die Zertifikate aus einer DER-Datei zu lesen, welche über
die cksem-DLL angesprochen wird. Hierzu müssen die Zertifikate mit einem allgemein definiertem
Namen in einem angegebenen lokalen Verzeichnis liegen.
Diese Angaben lauten für die Mitarbeitervariante mit zwei Zertifikaten, wie folgt:
C:\Programme\Campuskarte\cksem\pkcs11\MySignatureCertificate.der
und
C:\Programme\Campuskarte\cksem\pkcs11\MyEncryptionCertificate.der
Für die Variante der anderen Benutzer mit einem Zertifikat, ist dieses, wie folgt abzulegen:
C:\Programme\Campuskarte\cksem\pkcs11\MySignatureCertificate.der
Damit die Endanwenderzertifikate korrekt verifiziert werden können müssen ebenfalls die
Zertifikate der TUB-CA und der TUB-Perosnen-CA im Austellerverzeichnis (Signers) installiert
sein. Diese werden nach der Einführung des TUB-Trustcenters über eine Internetseite
direkt anwählbar sein.
7.2.4 LDAP für Netscape einrichten
Um auf die Daten, d.h. u.a. E-Mail-Adressen und Zertifikate, des LDAP 33 Servers der TU-
Berlin zugreifen zu können, müssen beim Browser, z.B. Netscape Communicator, einige
Grundangaben gemacht werden.
Es muss die URL des Servers angegeben werden. Der Standardport für LDAP Server ist
389. Als Einstiegspunkt (engl.: Search Root) ist eine DN-Angabe im Zertifikat gemeint, hier
kann z.B. C=DE angegeben werden (siehe Abbildung 6-7.3).
33
vgl.: Kapitel 3.12
67

7.3 Tests
Abbildung 6-7.3: Dialogbox für LDAP-Eigenschaften bei Netscape 4.7x
Mit dem Aufzeigen einer signierten Mail, bei dem eine kryptografische Schlüsselfunktion
zum Einsatz kommt, und ihrer ASN.1-Struktur sowie der dazugehörigen S/MIME-Struktur
wird ein Test des Systems beschrieben.
Der folgende Ausschnitt zeigt eine signierte E-Mail als ASN.1-Struktur. Erzeigt wurde
diese lesbare Form mit dem Tool GUIdumpASN (siehe Abschnitt 9.6). Die hier angegebenen
letzten Zeilen (ab OCTET STRING) zeigen die 128 Byte lange Signatur (128 Bytes), die von
der Karte generiert wurde.
...
3310 30 13: SEQUENCE {
3312 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
3323 05 0: NULL
: }
3325 04 128: OCTET STRING
: 90 DC 41 85 F5 A4 5A 0F EB E0 F7 B3 9B 48 FC 94
: F4 58 A4 53 4E F1 2C 82 84 4C 14 E3 6D 2F EF 40
: FF 9C 47 07 8F 55 BA 0E F6 AB D0 CD 7D B9 A8 02
: 23 91 41 D8 47 DF 5C 1E 7D 7A 8E 4E 24 92 A3 51
: DC E2 57 BC 21 95 E1 0D DC 7D 8B C0 00 27 87 73
: 5E 09 53 48 12 78 D6 9A E9 17 3E C0 51 8B 28 6D
: 9C 6B 60 64 91 22 91 BB CC 06 4A D4 65 D1 5D F7
: 92 30 2A DF 32 5A FD 42 53 87 AD 93 0D 75 88 07
: }
: }
: }
: }
Folgend ist ein Auszug einer signierten E-Mail dargestellt. Dieser Aufbau entspricht einer
S/MIME-Nachricht. S/MIME definiert für die verschiedenen kryptografische Versionen einen
eigenen Content-Type, hier multipart/signed. Mit protocol wird der MIME-Typ
angegeben, der ein übertragenes Signaturobjekt bezeichnet. Dies ist ein PKCS#7-Objekt vom
68

INSTALLATION, KONFIGURATION UND TESTS
Hinhaltstyp SignedData, und wird mit application/x-pkcs7-signature angegeben,
der auch indirekt durch die Dateinamenendung .p7s spezifiziert wird, siehe unten. Der
Parameter micalg (message integrity check algorithm) gibt den verwendeten Signaturalgorithmus
an. Diese Information wird für die Verifikation benötigt. Im vorliegenden Fall ist
es der beschriebene SHA-1 Algorithmus. Die Datei der signierten E-Mail hat den Namen
smime.p7s.
From - Tue Sep 17 13:38:50 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path:
X-Sieve: cmu-sieve 2.0
Received: from localhost (localhost [127.0.0.1])
by mail2.prz.tu-berlin.de (Postfix on SuSE Linux E-Mail Server 3.1) with
ESMTP id 3438B2BF12
for ; Fri, 13 Sep 2002 14:00:29 +0200 (CEST)
Received: from prz.tu-berlin.de (zen.prz.tu-berlin.de [130.149.238.132])
by mail2.prz.tu-berlin.de (Postfix on SuSE Linux eMail Server 3.1) with
ESMTP id 45D832BF07
for ; Fri, 13 Sep 2002 14:00:27 +0200 (CEST)
Message-ID:
Date: Fri, 13 Sep 2002 13:56:33 +0200
From: Sebastian Zickau
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: zickau@prz.tu-berlin.de
Subject: sign test
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms0FD4587FD57EF948C7BCF7ED"
X-Virus-Scanned: by AMaViS perl-11 on mail.prz.tu-berlin.de
This is a cryptographically signed message in MIME format.
--------------ms0FD4587FD57EF948C7BCF7ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
sign this
--------------ms0FD4587FD57EF948C7BCF7ED
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
69

8 Ergebnisse und Ausblick
In diesem Kapitel wird ein Fazit gezogen, bei dem auch kritische Betrachtungen des Systems
erörtert werden. Mit einer Beschreibung der Erweiterungsmöglichkeiten und einem Ausblick
wird der inhaltliche Teil der Arbeit abgeschlossen.
8.1 Fazit
Als zentrales Ergebnis lässt sich festhalten, dass die geforderte Anbindung der Campuskarteninfrastruktur
an einen bestehenden E-Mail-Client auch praktisch umsetzbar ist.
Dies ist möglich, weil sich bestehende Standards und erweiterte Campuskartenfunktionen
in Einklang bringen lassen. Die Vorgabe von Netscape Messenger, ein PKCS#11-Modul zu
entwickeln, hat sich als eine realistische Erweiterungsmöglichkeit des E-Mail-Clients herausgestellt.
Durch dieses Interface konnte auch aufgezeigt werden, dass sich die Campuskarte an
eine internationale Standardstruktur anpassen lässt.
Die implementierte API, die eine Standardfunktionalität nach außen bietet, kann auch von
anderen Programmen angesprochen werden, wenn sie eine derartige Schnittstelle bereitstellen.
Die erfolgreiche Verwendung von unterschiedlichen Schlüsseln für verschiedene
kryptografische Funktionen ist eine Eigenschaft, die nicht in allen derzeitig existierenden E-
Mail-Clients umgesetzt ist. Der Funktionsumfang des verwendeten E-Mail-Programms wird
dahingehend erweitert.
Die Arbeit hat den Grundstein gelegt, um den Einsatz des Systems für die Nutzer der
Campuskarte in der TUB-Verwaltung und unter den Studierenden einzuführen. Es wurde
aufgezeigt, dass die Karte mit gesetzeskonformen Schlüssellängen arbeitet, die einen rechtssicheren
Einsatz erlauben.
Hierbei ist es wünschenswert auch andere E-Mail-Clients zu erweitern, damit diese auch
mit der Campuskarte zusammenarbeiten können. Es wurde bereits mehrfach auf eine Erweiterung
von MS Outlook eingegangen. Es ergeben sich verschiedene Lösungsansätze, zum
einen eine parallele Entwicklung eines Cryptographic Service Providers, der direkt die vorhandene
Javaschicht nutzt oder zum anderen die Implementierung einer Zwischenschicht, die
auf dem bestehenden PKCS#11-Modul eine CSP-Funktionalität aufbaut.
Die Software kann sich auch mit Systemen agieren, die nicht mit der Campuskarte
ausgestattet sind. Das ist möglich, weil beim sicheren E-Mail-Konzept auf dem
Quasistandard S/MIME aufgebaut wurde, der von führenden Herstellern von E-Mail-Clients
unterstützt wird. PGP steht immer noch und seit kurzem wieder durch die
Weiterentwicklungen der PGP Corporation 34 in Konkurrenz zu dem RFC-Standard S/MIME.
Auch auf internationaler Ebene ist es durch das MTT-Projekt verstärkt zu einer Vereinheitlichung
von Benutzerumgebungen gekommen, auf die im Projekt durch Wahl der Zertifikatattribute
eingegangen wurde, um auch hier eine möglichst große Interoperabilität zu
gewährleisten.
Ein Anteil von Java in der Lösung ermöglicht auch eine Anpassung an andere Betriebssysteme
zu vollziehen, indem keine komplette Neuimplementierung notwendig ist.
Es wurde aufgezeigt, dass die Verwendung von sicherheitsbedenklichem JavaScript für
die Installation der Software nicht zwingend erforderlich ist.
34
online: http://www.pgp.com
70

8.2 Kritische Betrachtungen
ERGEBNISSE UND AUSBLICK
Bevor das System in der Praxis eingesetzt wird, ist es notwendig auch auf Schwachstellen
kritisch hinzuweisen. Für den realen Einsatz ist eine benutzungsfreundliche, stabile und performante
Software zu gewährleisten.
Der Einsatz von SUNs Java und deren Virtueller Maschine aufgrund des Open Card
Frameworks beansprucht eine hohe Systemleistung. Dies resultiert aus den hohen
Ressourcenanforderungen, die eine JavaVM an ein System stellt.
Ein weiterer Punkt ist der Lösungsansatz des Schichtenmodells. Ein Zusammenspiel von
unterschiedlichen Programmiersprachen und den gegebenen anderen Hard- und Softwareschichten
öffnet ein Feld von Fehleranfälligkeit, weil für den Betrieb ein reibungsloses Zusammenspiel
notwendig ist.
Momentane Einschränkungen, wie das fehlende Sessionkonzept auf der Karte und die
notwendige Speicherung von Zertifikaten in lokalen Dateien, sind durch angepassten Programmcode
oder mit leistungsfähigeren Karten zu beheben.
8.2.1 Kompromittierung von Schlüsseln
Durch die Bereitstellung einer Certificate Revokation List durch das Trustcenter der Technischen
Universität Berlin gibt es die Möglichkeit, sich die aktuellen Sperrungen von öffentlichen
Schlüsseln im E-Mail-Programm anzeigen zu lassen. Durch diesen Onlinedienst ist gewährleistet,
dass sich aktuelle Änderungen in der Gültigkeit von Schlüsseln schnell verbreiten
können.
Dies ist eine Vorsichts- und Hinweismaßnahme, welche einer Kompromittierung von
Schlüsseln entgegenwirken soll. Dazu ist es aber unabdingbar, dass im Falle einer Kompromittierung
schnellstmöglich dem Trustcenter oder einem ihm angeschlossenen Dienst dieser
Sachverhalt mitgeteilt wird, damit die Sperrlisten aktualisiert werden können.
Eine erteilte Signatur kann z.B. anhand ihres Datums für ungültig deklariert werden,
sollte der Schlüssel zu dem angegebenen Zeitpunkt bereits als nicht vertrauenswürdig eingestuft
worden sein.
8.2.2 Mögliche Angriffe auf Rechner
Ein Angriff auf das System, der denkbar wäre, ist ein Austausch der DLL bzw. Java-Klassen.
Diese könnten im Programmcode dahingehend geändert werden, dass sie eine kompromittierende
Funktionalität bereitstellen würden. Zum Ziel könnte der Angreifer das Mitlesen von
Informationen haben, wie z.B. der PIN oder den E-Mails, oder die Speicherung eines privaten
Schlüssels beabsichtigen. Da dieser die Karte allerdings nie „verlässt“, ist dieses Angriffsziel
durch das Austauschen der Binärdateien nicht zu erreichen.
Die Rechner, die in der TUB-Verwaltung zum Einsatz kommen, sind durch abgeschlossene
Türen und durch Passwörter geschützt. Ein entsprechender Umgang mit Hard- und
Software wird in den Dienstvereinbarungen beschrieben.
Eine weitere Möglichkeit dieses Angriffziel auszuschließen, ist das der Programmcode
und die ausführbaren Dateien mit elektronische Signaturen versehen werden, die vom TUB-
Trustcenter ausgestellte und vom Anwender verifiziert werden können.
8.2.3 Virenschutz
Im Zusammenhang mit der Übermittlung von elektronischer Post wird häufig von Attacken
auf lokale Rechner durch Viren informiert. Es ist klarzustellen, dass durch den Einsatz dieser
71

oder einer anderen sicheren E-Mail-Software sich die Problematik in bezug auf Viren im
Internet nicht ändert. Ein System wird nicht gegen Viren und Trojaner geschützt, indem es
verschlüsselte Nachrichten einsetzt.
Auch die Möglichkeit signierte Nachrichten verifizieren zu können schließt nicht aus,
dass sich Viren in Programmen und Dateien befinden können, die als Anhang geschickt werden.
Viren verbreiten sich meist in Unwissenheit des Absenders, d.h. ein ungewollt verschickter
Virus kann auch in einer signierten und gleichzeitig verschlüsselten E-Mail auftreten.
Vorgehensweisen zum Virenschutz werden u.a. in der Dienstvereinbarung [DTUE98] der
TUB beschrieben.
8.3 Erweiterungsmöglichkeiten
Das Aufzeigen der technischen Machbarkeit der Aufgabe führte dazu, dass das System mit
Einschränkungen realisiert wurde. Es bieten sich daher Erweiterungsmöglichkeiten an, die
die Software abgerundeter erscheinen lassen würden. Das Lesen der Zertifikate und anderer
Informationsdaten direkt von der Karte oder das Einführen von mehr Java- und OCF-Funktionalität
sind dafür zwei Beispiele.
Eine Anpassung für andere Betriebssysteme, z.B. Linux bzw. Unix, wäre eine praktische
Alternative. Da einige Schichten der Software in plattformunabhängigem Java geschrieben
wurden, ist dies teilweise realisiert. Die Anpassung des nativen Programmierteils wäre hier
durchzuführen.
Das Erweitern der Kartenbefehle und Programmstruktur zu einer ISO 7816 konformen
Standardkarte wäre ein größerer Schritt, der aber Änderungen in anderen Projektbereichen
nach sich ziehen würde.
8.4 Ausblick
Die im vorigen Kapitel angesprochenen Erweiterungsmöglichkeiten für das System sind auch
als Ausblick für die gesamte Aufgabe gedacht.
Mit dem notwendigen Erstellen eines Sicherheitskonzeptes für die Technische Universität
Berlin wird ein weiterer Schritt getan, um diese akademische Arbeit in einen praktischen und
einsetzbaren Kontext zu rücken.
Die realisierten Methoden für kryptografische Funktionen auf der Karte können selbstverständlich
noch in anderer Software zum Einsatz kommen. Hierbei ist, auch im Rahmen einer
Diplomarbeit geplant, einen Secure-Shell-Einsatz mittels Campuskarte zu realisieren. Weitere
Anwendungsfelder wären das Verschlüsseln und Signieren von Dokumenten oder ganzen
Festplatteneinheiten. Anwendungen dieser Art mit der Campuskarte sind in Vorbereitung.
Durch die eingeführten Funktionen wäre es auch möglich einen vereinfachten 35
Authentisierungsvorgang durchzuführen, bei dem nur die RSA-Schlüssel und Funktionen
zum Einsatz kommen.
Die Länge eines 1024 Bit Schlüssels ist nicht dauerhaft 36 als sicher anzusehen, deshalb
wird es in der Zukunft notwendig sein, längere Schlüssel einzusetzen. Dies ist unabhängig
von der Programmstruktur umsetzbar, da diese unabhängig von der Mächtigkeit des privaten
Schlüssels konzipiert ist.
35
im Gegensatz zum jetzigen speziell entwickelten Authentisierungsverfahren zu sehen, das durch
den Einsatz von exklusiven Methoden ausgeführt wird
36
vgl. Kapitel 3.4
72

ERGEBNISSE UND AUSBLICK
Der Sicherheitsaspekt in öffentlichen und offenen Datennetzen wird immer relevanter
Dies erkennt man u.a. daran, dass auf der Basis des Signaturgesetzes immer mehr Geschäfte 37
in Politik und Wirtschaft durch den Einsatz von elektronischen Datenverarbeitungsanlagen
abgewickelt werden.
Die in dieser Arbeit aufgezeigten Möglichkeiten bieten im Rahmen der Campuskarte ein
Konzept für den sicheren E-Mail-Einsatz an der TU-Berlin.
37
wie z.B. Bankgeschäfte über das Internet via SmartCard und die Einführung von rechtsgültigen
Online-Formularen mit der Initiative BundOnline2005
73

9 Anhang
9.1 Glossar
Abstract Syntax Notation
One
Application Programming
Interface
Asymmetrische Verschlüsselung,
Public Key Encryption
Authentifizierung, Authentication
Certificate Revocation List
Certification Authority
Chiffre
Cipher Block Chaining
Common Name
Cryptographic Application
Programming Interface
Cryptographic Token Interface
Data Encryption Standard
Digest
Digitale / Elektronische
Signatur, Digital Signature
Standard zur abstrakten und plattformunabhängigen Beschreibung
von Datenstrukturen
Programmierschnittstelle eines Softwaresystems
Verschlüsselungsverfahren, das auf einer 2 Schlüsselmethode
basiert, bekanntester ist das RSA-Verfahren
eindeutige Identifikation eines Kommunikationsteilnehmers
oder des Ursprungs von Daten
eine öffentliche zugängliche Liste, die alle Zertifikate angibt,
die vor ihrem Ablaufdatum als ungültig (widerrufen) erklärt
worden sind; wird von einer Zertifizierungsstelle verwaltet
Einrichtung einer PKI, die Zertifikate ausstellt und an Nutzer
weiter gibt
andere Bezeichnung für Verschlüsselungsverfahren, d.h.
Transformation von Klartext in Schlüsseltext
Modus, um einen Block-Chiffre mit einem Feedback-Mechanismus
auszustatten, dabei wird jeder Klartextblock vor seiner
Verschlüsselung mit dem letzten Ciphertextblock XOR-verknüpft
Attribut eines PKI-Zertifikats, in dem z.B. der Benutzername
gespeichert werden kann
eine Programmierschnittstelle unter Microsoft Windows, die
kryptografische Funktionalität zuständig ist, kurz: CryptoAPI
Name des RSA-PKCS#11 APIs, der Objekten, wie Smart-
Cards, eine allgemeine Programmierschnittstelle liefert
der am häufigsten verwendete symmetrische Algorithmus zum
Verschlüsseln (Produktverschlüsselung) von Daten; internationaler
Quasistandard
siehe Hash-Funktion
Ein mit dem PrivateKey verschlüsselter Hashwert, der die Integrität
und den Ursprung von Daten sicherstellen soll
74

ANHANG
Distinguished Encoding
Rules
Distinguished Name
Einwegfunktion
Elliptic Curve Cryptography
Entschlüsselung
Faktorisierung
Geheimer Schlüssel, Secret
Key, Symmetric Key
Hash-Funktion
Integrität, Integrity
International Data Encryption
Algorithm
Untermenge von Basic Encoding Rules; für die eindeutige
Kodierung von ASN.1-Strukturen
Attribut eines PKI-Zertifkats
Funktion, die sich einfach zu berechnen ist, deren Umkehrung
aber sehr schwer zu berechnen ist; siehe Hash-Funktion
Gebiet der asymmetrischen Kryptografie, der sich auf mathematischen
elliptischen Kurven stützt
Umkehrfunktion, um aus einem Geheimtext wieder einen
Klartext zu erzeugen
Zerlegung einer Zahl in Primfaktoren
Schlüssel eines symmetrischen Verfahrens, der sowohl für die
Ver- wie für die Entschlüsselung eingesetzt wird; ist in jedem
Fall vor Dritten geheim zu halten
eine mathematische Funktion, die Daten beliebiger Länge auf
einen repräsentativen Wert (Hash) kürzerer Länge abbildet, der
in der Regel eindeutig ist, d.h. es ist schwierig zwei unterschiedliche
Daten auf den gleichen Hashwert abzubilden; wird
bei digitalen Signaturen eingesetzt; Umkehrfunktion ist
schwierig zu berechnen
Sicherheitsbezeichnung für unveränderte Daten
symmetrischer 64-Bit-Blockchiffre-Algorithmus
Internet Mail Consortium
Internet Message Protocol
Internet Protocol
Internet Standard Organisation
Java Cryptographic Architecture
Java Cryptographic Extension
Java Development Kit
Java Virtual Machine
Protokoll zur Übertragung von elektronischer Post
Basisprotokoll zur Übertragung von Daten im Internet
Institution zur Entwicklung internationaler Normen und Standards
Schnittstelle zur Entwicklung von kryptografischen Funktionen
für die Java-Plattform
Schnittstelle, die die JCA mit kryptografischen Funktionen
ergänzt, die den Exportbestimmungen der USA unterliegen
Umgebung für die Erstellung von Java-Programmen
Umgebung in der Java-Programme ausgeführt werden
75

Klartext
Kryptoanalyse
Kryptografie
Kryptologie
Lightweight Directory
Access Protocol (LDAP)
Multipurpose Internet Mail
Extension (MIME)
Objektbezeichner, Object
Identifier
Öffentlicher Schlüssel,
Public Key
Padding
Post Office Protocol
Pretty Good Privacy
Privacy Enhanced Mail
Privater Schlüssel, Private
Key
Public Key Cryptographic
Standards
Public Key Infrastructure
Public Key Infrastructure
X.509
Registration Authority
Request For Comment
unverschlüsslte(r) Text/Daten
Disziplin, die sich mit der Berechnung von Verschlüsselungsverfahren
und Kryptografie beschäftigt
Gebiet, das sich mit der Geheimhaltung, dem Schutz von vertraulichen
Daten und unautorisierten Veränderungen durch
Verschlüsselung beschäftigt
Fachgebiet der Kryptografie und Kryptoanalyse
Standard für den Zugriff auf X.500-Verzeichnisse
Format zur Übertragung von Daten, jeglicher Form, über das
SMTP-Protokoll
ASN.1-Typ zur eindeutigen Identifikation von Informationsobjekten
der Schlüssel eines asymmetrischen Verschlüsselungssystem,
der vom Sender (der Welt) bekannt sein darf, um Daten zu
verschlüsseln bzw. zu verifizieren
Auffüllen von nichtbelegten Bits in Blöcken, um eine vorgeschriebene
Länge zu erreichen
Protokoll zum Übertragen von E-Mail-Nachrichten
von Philip Zimmermann entwickelter sicherer E-Mail-Dienst,
basiert auf WebOfTrust
Sicherheitsprotokoll für elektronische Post
der Schlüssel eines asymmetrischen Verschlüsselungssystem,
der nur dem Eigentümer bekannt sein darf, um Daten zu entschlüsseln
bzw. zu signieren
von den RSA-Laboratories Standardserie, die sich mit elektronischer
Verschlüsselung beschäftigen
eine Infrastruktur die auf einer asymmetrischen Verschlüsselungsmethode
basiert und Zertifikate für die Verteilung der
öffentlichen Schlüssel benutzt
eine Public Key Infrastucture, die auf dem Standard der X.509
Zertifikate beruht
Einrichtung, die Benutzerdaten für eine PKI registriert
Sammlung von Standardisierungsdokumenten für die Informatik
76

ANHANG
Rivest, Shamir, Adelman
Schlüssel, Key
Schlüsselpaar, Key Pair
Schlüsseltext, Chiffrat,
Ciphertext
Secure Hash Algorithm
Secure Multipurpose Internet
Mail Extension
Simple Mail Transfer Protocol
Sitzungsschlüssel, Session
Key
Smart Card / Java Card
Trusted Third Party
Verbindlichkeit, Non Reputation
Wiederruf eines Zertifikats
Zertifikat, Certificate
Zertifizierungsstelle, Certificate
Authority
Namen der Erfinder des RSA-Algorithmus
hier Bitfolge, mit deren Hilfe Daten ver- und entschlüsselt
werden können
Paar, bestehend aus öffentlichem und privaten Schlüssel, bei
der asymmetrischen Verschlüsselung
verschlüsselter Klartext
Hashfunktion, die bei der elektronischen Signatur benutzt
wird, internationaler Standard
sichere Variante des MIME-Standards
Protokoll zum Senden von elektronischer Post
Schlüssel in einem symmetrischen Verschlüsselungssystem,
der nur bei e i n e m Nachrichtenaustausch verwendet wird
Bezeichnung für Chipkarten, die auf der Programmiersprache
Java aufbauen
Institution der vollständig vertraut wird, die u.a. private
Schlüssel erzeugt und Zertifikate verwaltet, sie ist von Sender
und Empfänger unabhängig, dieser dritten Stelle vertrauen
beide
ein Attribut eines Datums von Zertifikaten, das besagt, dass
der Sinn des entsprechenden Datums nicht abstreitbar ist
Erklärung der Ungültigkeit eines Zertifikats, weil z.B. der private
Schlüssel kompromittiert wurde, wird in einer CRL Liste
angegeben
Datei, die einer Person einen öffentlichen Schlüssel zuordnet;
wird von Zertifizierungsstelle erstellt
Institution, welche Zertifikate, CRLs und Schlüssel erstellt und
verwaltet; ihr wird im hohen Maße vertraut
77

9.2 Abkürzungen
ASN.1 Abstract Syntax Notation One
BER Basic Encoding Rules
CA Certificate Authority
CAPI Cryptographic Application Programming Interface
CBC Cipher Block Chaining
cksem Campuskarte Sichere E-Mail
CN Common Name
CP Certification Policy
CPS Certification Practice Statement
CRL Certificate Revocation List
Cryptoki Cryptographic Token Interface
DER Distinguished Encoding Rules
DES Data Encryption Standard
3DES Triple Data Encryption Standard (Triple-DES)
DLL Dynamic Linked Library
DN Distinguished Name
ECC Elliptic Curve Cryptography
IDEA International Data Encryption Algorithm
IMAP Internet Message Protocol
IMC Internet Mail Consortium
IP Internet Protocol
ISO Internet Standard Organisation
JCA Java Cryptographic Architecture
JCE Java Cryptographic Extension
JDK Java Development Kit
JRE Java Runtime Environment
JVM Java Virtual Machine
LDAP Lightweight Directory Access Protocol
MIME Multipurpose Mail Extension
OCF Open Card Framework
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
PIN Personal Identification Number
PKCS Public Key Cryptographic Standards
PKI Public Key Infrastructure
PKIX Public Key Infrastructure X.509
POP Post Office Protocol
PSE Personal Secure Environment
PUK PIN Unblocking Key
RA Registration Authority
RFC Request For Comment
RSA Rivest, Shamir, Adelman
S/MIME Secure Multipurpose Mail Extension
SDK Software Development Kit
SHA Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol
SPKI Simple Public Key Infrastructure
78

TTP Trusted Third Party
X.509 Ein ITU-Standard
ANHANG
79

9.3 Abbildungen
ABBILDUNG 2-3.1: SYMMETRISCHE VERSCHLÜSSELUNG......................... 5
ABBILDUNG 2-3.2: ASYMMETRISCHE VERSCHLÜSSELUNG.......................6
ABBILDUNG 2-3.3: HYBRIDE VERSCHLÜSSELUNG........................................ 6
ABBILDUNG 2-3.4: ERZEUGEN EINER DIGITALEN SIGNATUR...................8
ABBILDUNG 2-3.5: PRÜFEN EINER DIGITALEN SIGNATUR.........................8
ABBILDUNG 2-3.6: TUB-CA-BAUM........................................................................9
ABBILDUNG 2-3.7: ZERTIFIKATHIERARCHIE............................................... 21
ABBILDUNG 2-3.8: OCF-ARCHITEKTUR...........................................................23
ABBILDUNG 2-3.9: PC/SC ARCHITEKTUR........................................................24
ABBILDUNG 3-4.1: DIAGRAMM DES PROBLEMBEREICHSMODELLS.... 31
ABBILDUNG 3-4.2: ANWENDUNGSFALLDIAGRAMME................................ 31
ABBILDUNG 3-4.3: SYSTEMSCHNITTSTELLEN..............................................35
ABBILDUNG 4-5.1: LÖSUNGSANSATZ............................................................... 38
ABBILDUNG 4-5.2: : SEQUENZDIAGRAMM – VERSENDEN UND
EMPFANGEN VON SICHERER E-MAIL.............................................................39
ABBILDUNG 4-5.3: AKTIVITÄTSDIAGRAMM SIGNIEREN EINER E-MAIL.
41
ABBILDUNG 4-5.4: AKTIVITÄTSDIAGRAMM ENTSCHLÜSSELN EINER
E-MAIL....................................................................................................................... 42
ABBILDUNG 4-5.5: AKTIVITÄTSDIAGRAMM PIN EINGEBEN....................43
ABBILDUNG 4-5.6: PKCS#11-TOKEN-MODELL............................................... 44
ABBILDUNG 4-5.7: PKCS#11-OBJEKT-MODELL............................................. 45
ABBILDUNG 4-5.8: VERTEILUNG DER KOMPONENTEN............................ 46
ABBILDUNG 4-5.9: SCHICHTENMODELL FÜR LÖSUNG..............................48
ABBILDUNG 4-5.10: ENTSCHEIDUNG DER SCHLÜSSELWAHL BEI
KARTENFUNKTIONEN.......................................................................................... 51
80

ANHANG
ABBILDUNG 4-5.11: LOKALES ZERTIFIKAT................................................... 53
ABBILDUNG 6-7.1: AUFLISTUNG DER KRYPTOG. MODULE BEI
NETSCAPE 4.7X........................................................................................................ 65
ABBILDUNG 6-7.2: DIALOGFELD ZUM EINTRAGEN EINES NEUEN
KRYPTOG. MODULS BEI NETSCAPE 4.7X........................................................66
ABBILDUNG 6-7.3: DIALOGBOX FÜR LDAP-EIGENSCHAFTEN BEI
NETSCAPE 4.7X........................................................................................................ 68
9.4 Tabellen
TABELLE 2-3.1: CAMPUSKARTEN DATENMODELL.....................................12
TABELLE 2-3.2: TESTZERTIFIKATE..................................................................18
TABELLE 2-3.3: AUSWERTUNG NETSCAPE MESSENGER 4.7X..................19
TABELLE 2-3.4: AUSWERTUNG MS OUTLOOK 2000..................................... 20
TABELLE 3-4.1: AUSWERTUNG TESTSOFTWARE.........................................27
TABELLE 4-5.1: ÜBERSICHT FLAGS..................................................................53
TABELLE 5-6.1: AUFGERUFENE PKCS#11-FUNKTIONEN........................... 57
TABELLE 5-6.2: PARAMETER FÜR SIGNATURFUNKTION......................... 60
TABELLE 5-6.3: PARAMETER FÜR ENTSCHLÜSSELUNGSFUNKTION....60
TABELLE 5-6.4: RÜCKGABEWERT IM FEHLERFALL.................................. 61
TABELLE 5-6.5: STRUKTUR DER PROGRAMMSOURCEN...........................62
TABELLE 6-7.1: FEHLERBEDEUTUNG BEI REGISTRIERUNG................... 66
81

9.5 Bibliografie
[ASN1]
[BDSG02]
[BLNDSG]
[BSINFO]
[BUSC98]
[CORO00]
[DTUE98]
[GNUP11]
[GORD98]
ASN.1 Information Site
(online: http://asn1.elibel.tm.fr/en/index.htm)
Bundes Datenschutzgesetz, 19. Juli 2002 (online:
http://www.datenschutz-berlin.de/recht/de/bdsg/bdsg01.htm)
Berliner Datenschutzgesetz, 05. August 2001 (online:
http://www.datenschutz-berlin.de/recht/bln/blndsg/blndsg_nichtamt.htm)
Bundesamt für Sicherheit in der Informationstechnik, http://www.bsi.de
F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-orientierte
Software-Architektur – Ein Pattern-System, Addison-Wesley, Bonn,
Paris [u.a.], 1998
V. Coroamă: Flexible Anbindung von SmartCards an eine Java-Sicherheitsumgebung
– Entwurf und Implementierung eines Hardware-Providers für die
Java Cryptographiy Architecture, Technische Universität Darmstadt, 2000
Dienstvereinbarung über den Einsatz Elektronischer Post in der Technischen
Univeristät Berlin:
(online: http://www.datensicherheit.tu-berlin.de/info/tub/dv/1998-06-12-email.html)
GNU PKCS#11 Implementation (online: http://gpkcs11.sourceforge.net/)
Rob Gordon: Essential JNI Java Native Interface, Prentice Hall PTR,Upper
Saddle River, New Jersey, 1998
[GUTM00] P. Gutman: X.509 Style Guide, Auckland, 2000
(online: http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.tx)
[HERB02]
[HILD98]
[HITZ99]
[HORS00]
[HORS99]
R. Herbst: Verlegt Private Keys vor Zugriff schützen, in iX Juni 2002, Seite
139
T. Hildmann: Entwicklung eines sicheren, erweiterten E-Mail-Systems, Technische
Universität Berlin, 1998
M. Hitz, G. Kappel: UML@WORK - Von der Analyse zur Realisierung,
dpunkt Verlag, Heidelberg, 1999
C. S. Horstmann, G. Cornell: Core Java 2 Band 2 Expertenwissen, The Sun
Microssystems Press Java Series Markt+Technik Verlag, München, 2000
C. S. Horstmann, G. Cornell: Core Java 2 Band 1 Grundlagen, The Sun Microssystems
Press Java Series Markt+Technik Verlag, München, 1999
82

ANHANG
[IPLANE]
[ISISMT]
[JAPI131]
[KERN88]
[LIPP00]
[MOZILL]
[MUSCLE]
[NEDEVC]
iPlanet Dokumente
(online: http://docs.sun.com/source/816-6150-10/pkcs.htm#1020808)
ISIS-MTT (online: http://www.teletrust.de/teletrust.asp?id=61040)
Java Dokumentation der 1.3.1 API von Sun:
(online: http://java.sun.com/j2se/1.3/docs/api/)
B. W. Kernighan, D. M. Ritchie: Programmieren in C - Zweite Ausgabe ANSI
C , Carl Hanser Verlag, München, Wien , 1988
P. Lipp, J. Farmer, D. Bratko W. Platzer, A. Sterbenz: Sicherheit und
Kryptographie in Java, Einführung, Anwendung und Lösungen,
Addison-Wesley, München, 2000
Mozilla Projekt (online: http://www.mozilla.org)
M.U.S.C.L.E. Projekt (online: http://www.linuxnet.com)
Netscape Developer Center
(online: http://devedge.netscape.com/)
PKCS#11-FAQ (online:
http://developer.netscape.com/support/faqs/pkcs_11.html)
[OCFP99] Open Card Framework 1.2 Programmer´s Guide Forth Edition, IBM, 1999
(online: http://www.opencard.org/index-docs.shtml)
[PCSCWG]
[PETZ00]
PC/SC Workgroup Spezifikation (online: http://www.pcscworkgroup.com)
C. Petzold: Windows Programmierung Das Entwicklerhandbuch zur Win32-
API 5. Auflage, Microsoft Press Deutschland, Unterschleißheim, 2000
[PKCS1] PKCS#1: The RSA Cryptography Standard, RSA Laboratories, Version 2.1,
2002 (online: http://www.rsasecurity.com/rsalabs/pkcs/)
[PKCS11]
[PKCS15]
[PKCS7]
[RANK99]
PKCS#11: Cryptographic Token Interface Standard, RSA Laboratories, Version
2.11, 2001
(online: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html)
PKCS#15: The Cryptographic Token Information Syntax Standard, RSA Laboratories,
Version 1.1, 2000
(online: http://www.rsasecurity.com/rsalabs/pkcs/)
PKCS#7: Cryptographic Message Syntax Standard, An RSA Laboratories
Technical Note, Version 1.5, 1993 (online:
http://www.rsasecurity.com/rsalabs/pkcs/)
W. Rankl, W. Effing: Handbuch der Chipkarten – Aufbau – Funktionsweise
Einsatz von Smart Cards, Hanser Fachbuchverlag, 1999
83

[RAPH00]
[RFC2632]
[RFC2633]
[RFC2634]
[RFC3280]
[SCHN01]
[SCHN96]
[SCHR01]
Rahmen-Pflichtenheft – Chipkartenbasierte Dienstleistungssysteme an den
Berliner und Brandenburger Hochschulen, Version 2, Berlin, 2000
RFC 2632 S/MIME Version 3 Certification Handling, B. Ramsdell (Ed.), Juni
1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell (Ed.), Juni
1999
RFC 3634 Enhanced Security Services for S/MIME, P. Hoffmann (Ed.), Juni
1999
RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, R. Housley, W. Polk, W. Ford, D. Solo, April
2002
B. Schneier: Secrets & Lies – IT-Sicherheit in einer vernetzten Welt,
dpunkt.verlag, Heidelber, 2001
B. Schneier: Angewandte Kryptographie, Protokolle, Algorithmen und
Sourcecode in C, Addison-Wesley, Bonn, Reading [u.a.], 1996
D. Schramm: Entwicklung einer flexiblen Java-basierten S/MIME-Erweiterung
für Outlook, Technische Universität Darmstadt, 2001
[SEEG00] J. Seeger: Anchormen IMAP-fähige Mail-Clients, in iX Juli 2000, Seite 44
[SEST00]
[SIGG01]
C. Sesterhenn: Design und Implementierung eines Kryptographie-Plugin für
E-Mail-Clients basierend auf S/MIME und Java, Technische Universität
Darmstadt, 2000
Gesetz über Rahmenbedingungen für elektronische Signaturen, 2001 (online:
http://jurcom5.juris.de/bundesrecht/sigg_2001/index.html)
[SIGV01] Verordnung zur elektronischen Signatur, 2001
(online: http://jurcom5.juris.de/bundesrecht/sigv_2001/)
[SING00]
[SUHR00]
[SUHR02]
[SUHR99]
[SWDK01]
S. Singh: Geheime Botschaften – Die Kunst der Verschlüsselung von der Antike
bis in die Zeiten des Internet, Carl Hanser Verlag, München, Wien, 2000
Lutz Suhrbier: Smartcard-Datenmodell Anforderungen, Technische Universität
Berlin, 2000
L. Suhrbier: Dokumentation des Cardlets Campuskarte, Technische Universität
Berlin, 2002
L. Suhrbier: Entwicklung eines Benutzerszenarios für sichere Email, Technische
Universität Berlin, 1999
Spektrum der Wissenschaft Dossier 4/2001: Kryptographie
84

ANHANG
[VEST01]
[VOUC97]
[ZIMM99]
T. Vest: Design und Implementierung eines Crypto Service Providers zur Anbindung
der Java Cryptographic Architecture an das Windows CryptoAPI am
Beispiel der CDC-Provider, Technische Universität Darmstadt, 2001
M. Voucko: Kapselung von Sicherheitsfunktionalität durch kryptographische
Token, Technische Universität Darmstadt, 1997
P. Zimmermann, C. Creutzig, A. Buhl: PGP – Pretty Good Privacy - Der
Briefumschlag für Ihre elektronische Post, FoeBuD e.V., Bielefeld, 4. Auflage,
1999
85

9.6 Eingesetzte Tools
Dies ist eine Auflistung der zum Teil erwähnten Tools und Programmierhilfen, die zum
Erstellen des praktischen Anteils der Arbeit eingesetzt wurden. Unter den URLs finden sich
die Programme bzw. Informationen dazu.
GUIdumpASN
online: http://www.geminisecurity.com/guidumpasn.html
modutil
online: http://www.mozilla.org/projects/security/pki/pkcs11/netscape/pk11test.html
CVS
online: http://www.cvshome.org/
Visual C++
online: http://msdn.microsoft.com/visualc/
cygwin
online: http://www.cygwin.com/
make
online: http://www.gnu.org/manual/make/html_node/make_toc.html
Visio Professional
online: http://www.microsoft.com/office/visio/
TaskInfo2000
online: http://www.iarsn.com/
86