Diplomarbeit von. 17. Januar 2005

Transkript

1 Anwendung von Digitalen Identitäten an einer Hochschule Diplomarbeit von Hervé Seudié 17. Januar 2005 Betreuer: Vangelis Karatsiolis Technische Universität Darmstadt Fachbereich Informatik Theoretische Informatik Kryptographie und Computer Algebra Prof.Dr. Johannes Buchmann

2 ii Hiermit versichere ich, die vorliegende Arbeit selbstständig und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle aus Quellen entnommenen Stellen sind als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Darmstadt, den 17. Januar 2005 Hervé Seudié

3 iii Danksagung Für die Unterstützung und Hilfe bei der Anfertigung dieser Arbeit geht mein besonderer Dank an Prof. Dr. Johannes Buchmann und seine Mitarbeiter. Insbesondere ist dies Vangelis Karatsiolis, der diese Arbeit betreut hat, von wem ich viel gelernt habe. Ich bedanke mich bei Marcus Lippert und Alexander Wiesmaier, die zusätzliche Hilfsbereitschaft bereitstellten. Weiterhin Alain Pfouga und Anique Lehning, die mir bei dem Korrekturlesen und damit Schreibfehler unterstützt haben. Vielen Dank an meine Familie und meine Freunde für ihre ständige Motivation. Ganz besonderer Dank gilt meinen Eltern und meinen Geschwistern, die mich immer voll unterstützt haben.

4 iv

5 Inhaltsverzeichnis 1 Motivation 1 2 Einleitung 3 3 Sicherheitsgrundlagen Begriffserklärungen Kryptographie Symmetrische Verschlüsselung Public-Key Verschlüsselung Hybride Verschlüsselung Signatur Hash Verfahren PKI Aufgaben einer PKI Komponenten einer PKI PKI-bezogene Standards Einführung in die Technologie von Chipkarten Normen Hardware Arten von Chipkarten Eigenschaften von Chipkarten Sicherheit Angriffe Chipkarten und Digitale Identitäten Standards Anforderungsanalyse für die Integration von Chipkarten als digitale IDs Rechtliche Anforderungen Hochschulrecht Anwendungsbezogene gesetzliche Rahmenbedingungen Technische Anforderungen Sicherheitsanforderungen Wahlkriterien von Kartentypen Getestete Kartenmodelle TCOS Starcos SPK v

6 vi INHALTSVERZEICHNIS Gemplus GPK 16k Cyberflex Access E-gate 32k Cryptoflex 32k Tabellenübersicht Ablauf zur Ausstellung von Digitalen IDs Registrierung und Erzeugung Publizierung Zertifikat auf Karte schreiben Revokation Verlängerung Anwendungen Signatur und Verschlüsselung Authentisierung und Autorisation Windows Logon Zugang zu geschützten Webseiten per Secure Socket Layer (SSL) Sichere digitale Prüfungsverwaltung Landesbibliothek Login in dem Universitätsnetz Anwendungen mit dem kontaktlosen Chip Realisierung von Prototypen Authentifikation, Autorisation auf Webserver mittels SSL Vorraussetzungen Konfiguration Aufbau einer Zertifizierungsinstanz CA Erzeugung von Serverzertifikaten Aufbau User Gruppen mit Zertifikaten Authentisierung und Rechtsvergabe Test (Betrieb) Erkenntnisse 89 A Apache Webserver, Openssl und mod ssl Installation 91 A.1 Installation A.1.1 Installation unter Unix A.1.2 Installation unter Windows A.2 Konfigurationsdatei von Apache

7 Kapitel 1 Motivation Die verschiedenen Aufgaben im Alltag eines Studierenden oder eines Lehrstuhlmitarbeiters sind vielfältig und erfordern einen hohen Organisationsaufwand. Für Studierende besteht dieser Aufwand in der Prüfungsanmeldung, der Rückmeldung vor Beginn jedes Semesters, dem Umgang mit einer vielzahl unterschiedlicher Zugangsberechtigungen, um sich zum Beispiel Vorlesungs- oder Übungsskripten von Webseiten herunterzuladen. Dieser Aufwand spiegelt sich im Lehrstuhl mit einer erhöhten Verwaltung wieder. Die Definition von Zugriffsrechten bildet ein Beispiel unter vielen anderen. Zur Zeit funktioniert dies auf der Basis einer so genannten Basic Authentication: 1 die Passwörter sind für alle Studenten gleich und werden während der Vorlesung an die Tafel geschrieben. Außerdem sorgen die schriftlichen Verwaltungsschritte mit dem Prüfungssekretariat meistens für Verzögerungen in Hinsicht auf die Prüfungsdaten. Der Zugriff auf Internetseiten innerhalb eines Verwaltungsnetzwerks oder zwischen Verwaltungswebservern und Benutzer (Student, Professor) während der Durchführung von Verwaltungsvorgängen ist aber nicht sicher genug: die Identitätsfälschung ist hier auch möglich, weil es zum Beispiel meistens reicht, eine Matrikelnummer zu haben um Aktionen auf den Namen einer Person durchzuführen. Diese Verwaltungsvorgänge enthalten nicht nur Sicherheitsprobleme, sondern auch Aufwandsprobleme. Es muss eine Organisation geben, die sich um die Prüfungsangelegenheiten der Studenten (im Fall der TU-Darmstadt ungefähr Studenten) kümmern muss. Diese Organisation ist für die Prüfungsanmeldung, Auskunft über Leistungsspiegel zuständig. Also eine Zusammenarbeit mit den Studenten auf einer Seite und eine Zusammenarbeit mit den Institutsverantwortlichen auf der anderen. Umständlich für den Student ist es, weil er anwesend sein muss, um beispielsweise eine Prüfungsanmeldung durchzuführen und sich dabei an feste Öffnungszeiten halten muss. Weil der Computer und die Internetkommunikation für effizientere und schnellere Arbeitsabläufe gesorgt haben und immer noch sorgen und dadurch nicht mehr weg zu denken sind, sind die Sicherheitssorgen mit der Wichtigkeit dieser Arbeitsmittel gestiegen. Diese Sicherheitssorgen kommen von bestimmten Schwächen von Internet und Computer. Die Betriebsdaten werden allgemein ungeschützt über das Internet übermittelt. Dies bedeutet: Das Senden von Nachrichten kann bestritten werden, weil allgemein die 1 Einfache Authentifizierung mittels Passwörter 1

8 2 1. Motivation nicht elektronisch signiert wird. Bei manchen Netzwerken ist es möglich für jeden angeschlossenen Teilnehmer alle Daten anderen Teilnehmer empfangen zu können. Die Adresse des Absenders kann meistens frei gewählt werden. Dies führt zu Angriffen. Bekannte Angriffe sind IP Spoofing, 2 Mail-Spoofing 3 und DNS Spoofing. 4 Die Anmeldung am Computer ist meist nicht gesichert, entweder weil man kein oder ein einfaches Passwort gewählt hat, oder weil das Passwort nicht sicher gespeichert ist. Da die Arbeitsmittel Computer und Internet schon in Einsatz sind und für schnellere und sichere Arbeitsabläufen sorgen sollen, überlegt man sich auf einer Seite wie man ihre Nutzung sicherer machen kann und auf der anderen Seite wie man mit Hilfe dieser Arbeitsmittel den Universitätsalltag für deren Nutzer vereinfachen kann. Es wird bereits per kommuniziert und meistens unsigniert: das heißt, dass man per eine Aktion einleiten und diese später abstreiten kann, aufgrund verschiedene Attacken wie Mail-Spoofing. Diese sind nur Beispiele von Alltagssituationen, die unter anderem beachtet werden müssen. Diese Alltagssituationen an der Universität sollten als Anwendungen eines Systems eingeführt werden. Die Suche nach Lösungen für die erfolgreiche sichere Einführung eines solchen Systems ist heutzutage von hohem Interesse und hat diese Diplomarbeit hervorgerufen. 2 Gefälschte IP Adressen der Absender 3 Gefälschte Adressen der Absender 4 Gefälschte DNS Adressen

9 Kapitel 2 Einleitung Digitale Identitäten (auch Digitale IDs genannt) sind elektronische Daten, die als Ausweise benutzt werden können. Sie können zu Authentisierungszwecken im elektronischen Verkehr benutzt werden, wie normale Personalausweise im schriftlichen Verkehr. Die vorgesehenen Anwendungen an einer Universität mit Hilfe von digitalen Identitäten sind: Sichere Computer Anmeldung Sichere Kommunikation Sicherer Zugriff auf WWW-Seiten Anmeldung bei Veranstaltungen Sicherer Zugriff auf Informationen (Zum Beispiel: Prüfungslisten, Vorlesungsunterlagen) Anmeldung an Prüfungen Gebäudezugang Um Digitale Identitäten für die verschiedenen Anwendungen benutzen zu können wird als erstes eine Public Key Infrastruktur (PKI) gebraucht. Eine PKI stellt durch eine sichere Schlüsselverwaltung die nötigen Vorraussetzungen zur Verfügung um ein sicheres System zu betreiben. Die Studenten bekommen Schlüsselpaare (ein geheimer und ein öffentlicher Schlüssel) eindeutig zugeordnet. Für die öffentlichen Schlüssel werden von der PKI Zertifikate für Studenten erstellt, mit denen sie sich authentisieren können: Die Zertifikate stellen eine eindeutige Zuordnung der Identität des Studenten zu seinem öffentlichen Schlüssel dar. Die Authentisierung läuft aber nur im Zusammenhang mit dem privaten Schlüssel. Mehr dazu in Kapitel 3. Die Digitalen IDs bestehen aus einem Zertifikat (Zertifikate dienen nur zu Verifikation der Signatur oder Identifikation) und dem dazugehörigen privaten Schlüssel (der private Schlüssel wird zu Signatur und Verschlüsselung benutzt). Digitale IDs werden zum Teil oder ganz von einem Dienst der PKI erzeugt. Es wird von einer Teilerzeugung gesprochen, wenn der private Schlüssel außer der PKI erzeugt wird und von einer ganzen Erzeugung, wenn alles in der PKI passiert. Die Digitalen IDs werden für ihre Benutzung in PKCS#12 Format (siehe [PKCS12] auf einem durch Passwort geschützten 3

10 4 2. Einleitung Datenträger gespeichert (Rechner, Diskette etc.), oder auf einem Datenträger in dem Informationen über den privaten Schlüssel nicht mehr gewonnen werden können. Die erste Möglichkeit, wofür der Begriff Softtoken 1 steht ist ohne großer Aufwand und hohe Kosten einführbar. Softtokens müssen vor ihrer Benutzung in einem Betriebssystem installiert werden. Wenn man die digitalen Identitäten installiert hat, werden sie in den meisten Fällen von der für die Authentisierung benutzten Software aufgrund Standards problemlos gefunden und eingesetzt. Die Softtokens können aber - und es sollte davon ausgegangen werden, da diese Option zum Beispiel in Windows XP Default ist- so gespeichert werden, dass keine PIN 2 Eingabe aufgefordert wird. Man hat also das Problem hier, dass die Nutzung eines Browsers in einem Öffentlichen PC ohne Benutzergruppen (jeder Benutzer nutzt das Konto Gast) dazu führen kann, dass eigene Zertifikate von Dritten benutzt werden können. Es fehlt dann eine Art PIN Anfrage, um die Authentizität des Besitzers gegenüber dem Browser zu beweisen. Das Sicherheitsniveau kann durch Aktivierung der PIN Aufforderung erreicht werden. In anderen bekannten Betriebssystemen wird die Aufforderung zu PIN Eingabe als Default angeboten. Dieses Sicherheitsniveau ist leider nicht ausreichend angesichts der Anwendungen, die mit Hilfe der Digitalen IDs ausgeführt werden, da die Sicherheit von der Qualität des Passwortes abhängig ist. Die zweite Möglichkeit ist die Benutzung von Hardware, die eine sichere Umgebung für die Speicherungen, Benutzungen und kryptographische Berechnungen bietet. Chipkarten realisieren diese Möglichkeit. Sie sind vor allem sicherer, weil der private Schlüssel nach seiner Speicherung für immer in der Karte bleibt und nicht extrahiert werden kann. Außerdem ist die Benutzung der Karte wie bei Bankkarten mit einer PIN Eingabe verbunden. Die berechtigte Frage ist: wie werden also elektronische Dokumente signiert oder verschlüsselt, wenn der private Schlüssel die Karte nicht verlassen kann? Alle Berechnungen erfolgen in der Karte. Die zu signierenden beziehungsweise verschlüsselnden Daten werden in die Karte geschickt. In der Karte werden sie signiert, beziehungsweise verschlüsselt und anschließend zurückgeschickt. Abhängig von den Betriebssystemen werden Informationen über die Zertifikate gespeichert. Im Fall von Windows Betriebssystem wird dann ein Pointer in dem Rechner installiert. Das Lesen von Daten aus der Karte wird mit korrekter Eingabe eines PIN Codes verbunden. Um den privaten Schlüssel benutzen zu können muss die Karte mit dem System verbunden sein: meistens mit Hilfe eines Kartenlesergeräts. Versucht der Benutzer auf den privaten Schlüssel zuzugreifen, wird er aufgefordert seine PIN anzugeben und wird nur nach korrekter Eingabe dieser PIN, den privaten Schlüssel benutzen können. Nach der Sitzung an dem Rechner könnte der Student - um auf unser vorangängiges Beispiel zurückzukommen- seine Karte einfach herausziehen und wegstecken. Diese neuen Sicherheitsmöglichkeiten, die die Benutzung der Karten bietet ist natürlich mit Kosten und Installationsaufwand verbunden. Wichtig ist natürlich wieviele Anwendungen mit der Kombination, Zertifikate und Chipkarte auf der Basis einer PKI möglich sind. Dann ist die Machbarkeit eines solchen Authentisierungsprozesses an einer großen Hochschule herauszufinden. Als erstes müssen dann aber die Anforderungen an das System definiert worden sein. Das sind die 1 Softtokens werden hier als Digitale Identitäten in PKCS#12 Format, die auf einen Datenträger gespeichert sind und nur mit Passwörter geschützt sind. 2 Personal Identification Number

11 Aufgaben dieser Diplomarbeit. In Kapitel 3 werden die Sicherheitsgrundlagen vermittelt, die für das weitere Verständnis der Arbeit erforderlich sind. In Kapitel 4 wird eine Einführung in die Chipkarte gemacht, die die Vorrausetzung gibt, die verschiedenen Eigenschaften und später in Kapitel 5 die Wahlkriterien von Chipkarten zu verstehen. In Kapitel 5 werden Vorschläge über die Einführung einer PKI und Chipkarte an einer Hochschule gemacht. In Kapitel 6 werden die Machbarkeit, Vorteile und Nachteile verschiedener Anwendungen angesprochen. In Kapitel 7 folgt anschließend die Realisierung von Prototypen einer PKI mit Chipkartensystem. Letztendlich werden Erkenntnisse angesprochen und Ausblicke für die Zukunft gegeben. 5

12 6 2. Einleitung

13 Kapitel 3 Sicherheitsgrundlagen 3.1 Begriffserklärungen Identifikation Die Identifikation oder Identifizierung definiert den Vorgang bei dem sich eine Einheit eindeutig gegenüber einer Instanz ausweist. Die Grenze zwischen Identifikation und Authentisierung ist sehr klein. Um sich eindeutig ausweisen zu können, braucht eine Einheit ein eindeutiges Identitätsmerkmal. Zum Beispiel ist dieses Merkmal ein Personalausweis im Fall eines Bürgers, der in einer Behörde etwas auf seinen Name erledigen möchte. Er legt seinen Ausweis vor. In diesem Ausweis sind Identifikationsmerkmale wie Photo, Name, Geburtsdatum, Größe und Signatur: Die Merkmale zusammen kombiniert ermöglichen eine eindeutige Ausweisung der Person. Warum ist es keine Authentisierung? Es ist erst eine Authentisierung, wenn eine Überprüfung der Richtigkeit beziehungsweise Gültigkeit des Ausweises und aller in ihm enthaltenen Daten erfolgt. Solang die Einheit nicht nachweisen muss, dass sie wirklich die ist, wofür oder für wen sie sich ausgibt, wird von einer Identifikation gesprochen. Nichtsdestotrotz kann die Identifikation als schwache Authentisierung betrachtet werden da Merkmale, die zur Identifikation benutzen werden, manchmal auch für die Authentisierung benutzt werden. Authentisierung Die Authentisierung oder Authentifizierung definiert den Vorgang bei dem eine Einheit seine Identität nachweist. Die Identifikation ist ein Teil der Authentisierung, weil der Vorgang zu Authentisierung eine Identifizierung hervorruft. Nach der Etappe der Identifikation beweist die Einheit während der Authentisierung die Richtigkeit ihrer Behauptung. Dieser Beweis kann unter drei Formen erfolgen: Authentisierung durch Besitz; Besitz einer eindeutigen Chipkarte etc. Authentisierung durch Wissen; Wissen eines PIN s, eines Passwortes etc. Authentisierung mit Biometrischen Merkmalen; Fingerabdruck, Iris etc. Die verschiedenen Formen der Authentisierung können kombiniert angewendet werden um eine starke Authentisierung zu erreichen. Zum Beispiel 7

14 8 3. Sicherheitsgrundlagen reicht nicht immer der Besitz einer eindeutigen Chipkarte, um sich zu authentisieren (schwache Authentisierung bei Gebäudezugang), sondern zusätzlich das Wissen eines PIN s ist notwendig. Autorisation Die Autorisation definiert den Vorgang bei dem entschieden wird, ob eine Einheit Zugriffsrechte auf Service hat und wenn dann welche. Autorisation wird meistens mit Authentisierung verwechselt. Daher die Wichtigkeit die Unterschiede zu erläutern. Bei der Authentisierung wird festgestellt, wer eine Einheit ist, und dann bewiesen, dass es sich wirklich um diese Einheit handelt. Bei der Autorisation wird nach einer Authentisierung die Zugriffsrechte auf Service kontrolliert. Also ist die Authentisierung ein Teil des Prozesses der Autorisation, wenn nicht der gleiche Prozess. Zum Beispiel sind in der Programmierungssprache JAVA der Firma SUN die beiden Prozesse in dem dienst Java Authentication Autorisation Services gekoppelt. Anonymität Die Anonymität definiert die nicht Bestimmbarkeit der Identität einer Einheit an einem Vorgang aufgrund entweder von Nichtbekanntsein: er ist dem System nicht bekannt, Nichtgenanntsein: er tritt gegenüber dem System nicht in Erscheinung oder Namenlosigkeit: er agiert ohne erkennbaren Namen. Privatheit Die Privatheit definiert den Schutz der personenbezogenen Daten, der Privatsphäre, und des informationellen Selbstbestimmungsrechts. Datenintegrität Die Datenintegrität ist der Schutz vor unautorisierter und unbemerkter Datenmodifikation. Verbindlichkeit Die Verbindlichkeit definiert das Vermeiden vom Abstreiten durchgeführter Handlungen. Vertraulichkeit Die Vertraulichkeit definiert den Schutz vor unautorisierter Informationsgewinnung. Keiner darf die vertraulichen Daten lesen, außer der Einheit an wen die Daten geschickt worden sind.

15 3.1. Begriffserklärungen 9 Verfügbarkeit Schutz vor unbefugter Beeinträchtigung der Funktionalität von Komponenten, Diensten etc. Kryptographie Nach [Eck03] ist die Kryptographie, die Lehre von Methoden zur Ver- und Entschlüsselung von Nachrichten zum Zweck der Geheimhaltung von Informationen gegenüber Dritten. Public-Key Infrastruktur Eine Public-Key Infrastruktur ist eine Sicherheitsinfrastruktur, die mittels Public- Key Verfahren sichere Dienste anbietet. Mehr dazu in Abschnitt 3.3. Zertifikate Zertifikate stellen eine verifizierbare Verbindung zwischen einer Einheit und einem öffentlichen Schlüssel her. Sie werden von einer Instanz der PKI genannten Zertifizierungsinstanz in engl. Certification Authority (CA) erstellt. Indirekt wird damit aufgrund des Zusammenhangs zwischen öffentlichem und geheimem Schlüssel auch ein Bezug zwischen Einheit und privatem Schlüssel hergestellt: Dokumente werden mit einem privaten Schlüssel signiert. Wenn man im Besitz des Zertifikates vom Signatar ist, kann man die Signatur verifizieren. Die Vorraussetzung für die Anwendung dieses Vorgangs ist das Vertrauen an die Zertifizierungsinstanz, die die Zertifikate erstellt hat. Zertifikate helfen dabei, auf unsicheren Transportwegen die öffentlichen Schlüssel authentisch auszutauschen. Zertifikate haben die Rolle von Personalausweisen beim Einsatz von Public-Key Kryptographie. Das Bild 3.1 stellt ein Zertifikat nach dem X.509 Standard (siehe [X509]) dar. Digitale IDs Digitale IDs bezeichnen das Paar, Zertifikat und privaten Schlüssel, die zusammen als eine Einheit gespeichert werden und somit genau so zu signieren als auch zum Verschlüsseln benutzt werden können. Sie werden in dem Standard PKCS#12 definiert (siehe [PKCS12]). Personal Security Environment PSE PSE bezeichnen die Umgebung, in der die privaten Schlüssel abgelegt werden (siehe [Bu01]). Der private Schlüssel darf die PSE nie verlassen. Außerdem müssen in der PSE kryptographische Berechnungen wie Verschlüsselung, Entschlüsselung und Signatur machbar sein, da diese Berechnungen die Benutzung des privaten Schlüssels voraussetzen. Aus Sicherheitsgründen werden in vielen Fällen die privaten Schlüssel in der PSE erzeugt. Es wird von Personalisierung der PSE gesprochen, sobald ein privater Schlüssel darin gespeichert ist. Ein Beispiel einer PSE ist die Chipkarte.

16 10 3. Sicherheitsgrundlagen Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5withrsaencryption Issuer: C=DE, L=Darmstadt, O=Certificate Authority, CN=CA/ =ca@tu-darmstadt.de Validity Not Before: Oct 29 17:39: GMT Not After : Oct 29 17:39: GMT Subject: C=DE, L=Darmstadt, O=TUD, OU=FB20, CN=herve/ =herve@tu-darmstadt.de Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c4:40:4c:6e:14:1b:61:36:84:24:b2:61:c0:b5: d7:e4:7a:a5:4b:94:ef:d9:5e:43:7f:c1:64:80:fd: 9f:50:41:6b:70:73:80:48:90:f3:58:bf:f0:4c:b9: 90:32:81:59:18:16:3f:19:f4:5f:11:68:36:85:f6: 1c:a9:af:fa:a9:a8:7b:44:85:79:b5:f1:20:d3:25: 7d:1c:de:68:15:0c:b6:bc:59:46:0a:d8:99:4e:07: 50:0a:5d:83:61:d4:db:c9:7d:c3:2e:eb:0a:8f:62: 8f:7e:00:e1:37:67:3f:36:d5:04:38:44:44:77:e9: f0:b4:95:f5:f9:34:9f:f8:43 Exponent: (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: herve@gmx.de Netscape Comment: mod_ssl generated test server certificate Netscape Cert Type: SSL Server Signature Algorithm: md5withrsaencryption 12:ed:f7:b3:5e:a0:93:3f:a0:1d:60:cb:47:19:7d:15:59:9b: 3b:2c:a8:a3:6a:03:43:d0:85:d3:86:86:2f:e3:aa:79:39:e7: 82:20:ed:f4:11:85:a3:41:5e:5c:8d:36:a2:71:b6:6a:08:f9: cc:1e:da:c4:78:05:75:8f:9b:10:f0:15:f0:9e:67:a0:4e:a1: 4d:3f:16:4c:9b:19:56:6a:f2:af:89:54:52:4a:06:34:42:0d: d5:40:25:6b:b0:c0:a2:03:18:cd:d1:07:20:b6:e5:c5:1e:21: 44:e7:c5:09:d2:d5:94:9d:6c:13:07:2f:3b:7c:4c:64:90:bf: ff:8e Abbildung 3.1: X.509 Zertifikat

17 3.1. Begriffserklärungen 11 Verschlüsselung Die Verschlüsselung beschreibt den Vorgang, bei dem verständliche Texte zu Chiffretexten 1 abgebildet werden. Elektronische Signatur Die elektronische Signatur ist ein elektronischer Nachweis für die Integrität und Authentizität von elektronischen Dokumenten. Sie basiert auf asymmetrischen Verfahren und Hashverfahren, welche in den Abschnitten und erklärt sind. 1 codierte Texte, die zwar verständlich sein können aber den Sinn des zu codierenden Textes verloren haben.

18 12 3. Sicherheitsgrundlagen 3.2 Kryptographie Die Kryptographie ist die Lehre der Verschlüsselung und Entschlüsselung von Informationen. Es gibt zwei große Arten von Verschlüsselungsverfahren: symmetrische und asymmetrische Verschlüsselungsverfahren, die auch in Kombination benutzt werden können Symmetrische Verschlüsselung Symmetrische Verfahren beschreiben kryptographische Algorithmen, die nur einen Schlüssel sowohl zum Verschlüsseln als auch zum Entschlüsseln benutzen. Der Schlüssel muss geheim sein. Die symmetrische Verschlüsselung ist die Verschlüsselung mit Hilfe symmetrischen Verfahren Public-Key Verschlüsselung Asymmetrische Verfahren oder Public-Key Verfahren beschreiben kryptographische Algorithmen, die zwei Schlüssel benutzen- einen öffentlichen und einen geheimen Schlüssel. Asymmetrische Verschlüsselung ist die Verschlüsselung mit Hilfe asymmetrischen Verfahren. Der De Facto Standard für Asymmetrische Verschlüsselung ist das RSA Verschlüsselungsverfahren, genannt nach seinen Erfindern Ron Rivest, Adi Shamir und Len Adleman. Dieses Verfahren ist in PKCS#1 Standard (siehe [PKCS1] definiert und detailliert in [Bu01] von Professor Johannes Buchmann erklärt. Ein kryptographisches Verfahren wird wegen zwei wichtigen Gründen eingesetzt: Sicherheit und Effizienz. Das RSA Verfahren ist so lange sicher, wie es schwierig ist, große Zahlen in Primzahlen zu zerlegen. Es funktioniert folgendermaßen: Die für Schlüsselerzeugung zuständige Einheit wählt nacheinander zufällig zwei große Primzahlen p und q. Das Produkt n der beiden Primzahlen wird gebildet. Die Einheit wählt dann eine Zahl e, so dass gilt: 1 < e < (p-1)(q-1) und gcd(e, (p-1)(q-1)) = 1. Dann berechnet die Einheit eine Zahl d, so dass gilt: 1 < d < (p-1)(q-1) und de 1 mod (p-1)(q-1). Der Öffentliche Schlüssel auch Public Key genannt besteht dann aus dem Paar (n, e) und der geheime Schlüssel ist d. Eine Nachricht m wird verschlüsselt dadurch, dass ihre Zahlendarstellung mit e exponiert wird: c = m e mod n. Sie wird dadurch entschlüsselt, dass der verschlüsselte Text mit d exponiert wird: m = c d mod n = m de mod n = m. RSA ist heutzutage sicher, wenn n mindestens eine 1024 Bit Zahl ist. Für diese Größenordnung ist RSA noch effizient berechenbar. Das Bild 3.2 aus der Vorlesung [Taka02] stellt eine Zusammenfassung des Ablaufs dar Hybride Verschlüsselung Aufgrund der benötigten Rechenzeit bei asymmetrischen Verfahren werden oft symmetrische und asymmetrische Verfahren kombiniert. Dies nennt man Hybridverfahren: Zur sicheren Übertragung des geheimen Schlüssels (für die symmetrische Verschlüsselung) wird dieser mittels asymmetrischer Verschlüsselung

19 3.2. Kryptographie 13 Abbildung 3.2: Szenario zu Verschlüsselung und Entschlüsselung mit RSA. mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Nur der Empfänger kann, da nur er den privaten Schlüssel besitzt, den geheimen Schlüssel, und damit diese Nachricht entschlüsseln. Aus Gründen der Arbeitsgeschwindigkeit wird die weitere Kommunikation symmetrisch mit dem zuvor sicher übertragenen Schlüssel verschlüsselt Signatur Public Key Verfahren werden auch in Kombination zu Hashverfahren (siehe Abschnitt 3.2.5) benutzt um digitale Signatur zu erstellen. Hier hat sich der De Facto Standard RSA auch durchgesetzt. Erst wird der Hashwert h(m) einer Nachricht m mit Hilfe einer Hashfunktion h berechnet. Dann wird dieser Hashwert mit dem privaten Schlüssel d exponiert und dies ergibt die Signatur s: s = h(m) d mod n. Die Signatur s wird zusammen mit der Nachricht selbst geschickt: das Paar (s, m) wird also geschickt. Der Empfänger kann die Signatur dadurch verifizieren, dass er erst den Hashwert h1(m) der Nachricht m berechnet. Dann exponiert er die empfangene Signatur s mit dem öffentlichen Schlüssel e des Senders und vergleicht das Ergebnis mit h1(m): s e mod e = h(m). h(m) = h1(m)? Diese Signaturmethode mit Public Key Verfahren funktioniert aus demselben Grund, weshalb die Public Key Verschlüsselung funktioniert. Der Signatar signiert mit seinem geheimen Schlüssel und der Empfänger verifiziert mit dem öffentlichen Schlüssel des Signatars. Die zusätzliche Benutzung von Hashverfahren garantiert die Integrität der signierten Nachricht: kann das Hashverfahren gebrochen werden, ist die Signatur wertlos. Das Bild 3.3 aus der Vorlesung [Taka02] zeigt ein Szenario einer Signatur mit Verifikation.

20 14 3. Sicherheitsgrundlagen Abbildung 3.3: Szenario einer Signatur und seine Verifizierung Hash Verfahren Hash Verfahren oder Hashfunktionen werden in verschiedenen Bereichen eingesetzt. Im Allgemeinen definieren Hashfunktionen nicht injektive Einweg-Funktionen, 2 die beliebig lange Quellmengen eindeutig auf wesentlich kleine, feste Zielmengen abbilden. In der Kryptographie repräsentieren diese Mengen Texte. Beliebig lange Texte werden unerkennbar mit Hilfe der Hashfunktion zu einem Hashwert (auch digitaler Fingerabdruck oder digital Fingerprint wie message digest in Englisch) gekürzt. Hashfunktionen müssen zusätzlich folgende Kriterien erfüllen: Kollisionsresistenz: Es muss praktisch unmöglich sein, ein Paar Nachrichten (M, M ) zu finden mit der Eigenschaft h(m) = h(m ) angenommen h ist die Hashfunktion. Komprimierung: Beliebig lange Texte müssen sich auf Hashwerte mit beliebig fester Länge abbilden lassen. Heutzutage haben Hashwerte in den meisten Fällen die Länge 160 Bit. Effizienz: Hashwerte müssen schnell berechenbar sein. Zufälligkeit: Ähnliche Quellenelemente sollen zu völlig verschiedenen Hashwerten führen. Im Idealfall verändert das Umkippen eines Bits in der Eingabe durchschnittlich die Hälfte aller Bits im resultierenden Hashwert. Der Hashwert wird in der Kryptographie eingesetzt um Datenintegrität, Authentizität und Reduktion einer Nachricht zu erreichen. Der Sender schickt den Hashwert zusammen mit dem originellen Text zu dem Empfänger. Der Empfänger berechnet den Hashwert von dem Text, den er bekommen hat. Er kann den neuen Hashwert mit dem alten vergleichen, um zu wissen, ob die Daten verändert worden sind. Dies ist nur ausreichend um die Datenintegrität zu gewährleisten aber nicht die Authentizität, weil der Angreifer auch den originellen Text hätte verändern können. Es wäre also sinnvoll den Text zusätzlich zu 2 Einweg-Funktionen sind Funktionen, die nicht effizient umkehrbar sind.

21 3.2. Kryptographie 15 signieren oder den Hashwert zu verschlüsseln um die Authentizität zu gewährleisten. Um die Authentizität gleichzeitig mit der Datenintegrität nur mit der Hashfunktion zu gewährleisten, werden Message Authentication Code MAC benutzt. MAC sind Hashfunktionen, die zusätzlich zu dem Text noch einen geheimen Schlüssel als Eingabewert benutzen. Der geheime Schlüssel ist nur von Sender und Empfänger bekannt. Der Empfänger berechnet einen neuen Hashwert nach dem Empfang von dem Paar (Text, Hashwert) und vergleicht alte und neue Hashwert. Der Hashwert wird auch zur Signaturbildung benutzt anstelle des ganzen Textes zu signieren. Der Hashwert eines Textes ist, außer bei sehr kleinen Texten, kürzer als der Text selbst. Da die Signaturbildung von der Länge des Textes abhängt, dauert eine Signatur des Hashwertes nicht so lange wie die Signatur des Ausgangstextes. Dies ist besonders bei Chipkarten wichtig, da hier die Rechengeschwindigkeit gering ist. Die bekanntesten und am Meisten benutzten kryptographischen Hashfunktionen sind: MD4: Message Digest 4 MD4 wurde 1990 von Ronald L. Rivest veröffentlicht. Der MD4 Hash-Algorithmus wurde mit dem Anspruch entwickelt auf 32 Bit-Rechnern besonders schnell zu laufen und gleichzeitig in der Implementierung einfach zu sein. Dabei sollten natürlich die grundlegenden Anforderungen an Hashfunktionen erhalten bleiben. MD4 erzeugt einen Hashwert mit einer Länge von 128 Bit. Trotz aller Sorgfalt im Design zeigte sich bald, dass das Verfahren unsicher ist. Als besonders problematisch stellte sich die mangelnde Kollisionsbeständigkeit heraus. Im Cryptobytes Journal der Firma RSA (siehe [MD4]) wurde eine Methode veröffentlicht, welche innerhalb einer Stunde zwei bis auf ein Zeichen identische Nachrichten erzeugen konnte, die denselben Hashwert ergaben. Rivest selbst bestätigte die Unsicherheit im RFC 1321: The MD5 Message-Digest Algorithm, so dass selbst RSA vom Einsatz dieses Message Digest abrät. MD4 wurde als Public Domain lizenziert, worauf wohl zurückzuführen ist, dass das verwendete Prinzip zur Basis weiterer Hashfunktionen geworden ist. RIPEMD-160: RACE Integrity Primitives Evaluation Message Digest RIPEMD-160 ist eine Hashfunktion, die eine 160-Bit-Prüfziffer liefert. RIPEMD-160 wurde von Hans Dobbertin, Anton Bosselaers und Bart Preneel in Europa entwickelt und 1996 erstmals publiziert. Es handelt sich dabei um eine verbesserte Version von RIPEMD, welche wiederum auf den Designprinzipien von MD4 basiert und in Hinsicht auf seine Stärke und Performanz dem populäreren SHA-1 gleicht. RIPEMD-160 unterliegt keinerlei Patentbeschränkungen. MD5:Message Digest 5 MD5 liefert einen 128-Bit-Hashwert. MD5 wurde 1991 von Ronald L. Rivest entwickelt. Im August 2004 wurden ernsthafte Sicherheitsmängel in MD5 entdeckt, und viele Systeme, die MD5 verwenden, werden möglicherweise auf sicherere Alternativen umsteigen. SHA-1: Secure Hash Algorithm SHA wurde von der NSA (National Security Agency) zusammen mit dem NIST (National Institute of Standards and Technology)entwickelt. SHA-1 ist eine zum Signieren gedachte sichere Hashfunktion für den Digital Signaturen Standard (DSS). Der Standard wurde Secure Hash Standard (SHS) genannt und spezifiziert den Secure Hash Algorithm (SHA) mit einem Hashwert der Länge 160 Bit für Nachrichten mit einer Größe von bis zu 264 Bit. Der Algorithmus ähnelt im

22 16 3. Sicherheitsgrundlagen Aufbau dem von Ronald L. Rivest entwickelten MD4. Der Secure Hash Algorithmus existiert in zwei Varianten, SHA-0 bzw. SHA-1, die sich in der Anzahl der durchlaufenen Runden bei der Generierung des Hashwertes unterscheiden. SHA-0 hat sich aber als unsicher erwiesen. Prinzipiell wurde von den gleichen Entwurfszielen wie beim MD4 ausgegangen. Mit seinem längeren Hashwert von 160 Bit ist SHA aber widerstandsfähiger gegen Brute-Force Angriffe und Kollisionen. Ein in seinen Details nicht näher beschriebener Design-Fehler im 1993 veröffentlichten Algorithmus wurde im heute gebräuchlichen, 1995 veröffentlichten SHA-1 Algorithmus korrigiert, für den bisher keine wirkungsvollen kryptografischen Angriffe bekannt geworden sind. Durch den Einsatz einer fünften Variablen ist SHA-1 auch im Vergleich zu MD5 resistenter gegen Kollisionen geworden. 3.3 PKI Dieser Abschnitt stellt eine Einführung in Public-Key Infrastruktur dar. Ein genauerer Überblick kann in dem Buch [AdamsLloyd99] gewonnen werden. Public Key Infrastruktur bezeichnet ein System, welches es mit Hilfe Asymmetrische Verschlüsselungsverfahren ermöglicht, Digitale Zertifikate auszustellen, zu verteilen und zu prüfen. Die innerhalb einer PKI ausgestellten Zertifikate sind meist auf Personen oder Maschinen festgelegt und werden zur Absicherung computergestützter Kommunikation verwendet. Der zu Grunde liegende Gedanke ist der folgende: Mit Hilfe eines Public-Key Verschlüsselungsverfahrens können Nachrichten im Internet signiert und verschlüsselt werden. Das Signieren garantiert, dass die Nachricht in dieser Form wirklich vom angegebenen Absender stammt. Allerdings benötigt man hierzu den Public-Key des Absenders. Dieser könnte zum Beispiel per versendet werden. Außerdem beziehen sich die Anwendungen von Zertifikaten schon längst nicht nur um die Bereiche der Verschlüsselung und der Signatur sondern in allen anderen Verwaltungsabläufen, die eine Authentisierung erfordern. Dabei geht es immer darum, seine Zertifikate vorzuzeigen (natürlich wird immer eine Überprüfung des Besitzes des privaten Schlüssels gemacht) um seine Identität nachzuweisen. Möchte man zum Beispiel auf eine Webseite zugreifen, auf die nur Studenten der Informatik Zugriff haben, müsste man ein Zertifikat besitzen, das beinhaltet, dass man tatsächlich ein Informatik Student ist. Es stellt sich genau an diesem Punkt aber die Frage, wie sicher man ist, dass es sich tatsächlich um den Schlüssel des Absenders oder des Benutzers handelt und nicht um eine Fälschung eines Betrügers. Dieses Problem des Schlüsselsaustauschs wird auf verschiedene Vertrauensmodelle gelöst: Direct Trust: Die Authentizität des gesendeten Schlüssels wird von dem Inhaber selbst bestätigt. Die Bestätigung könnte telefonisch oder per Post (nicht die sichersten Wege) erfolgen, aber auch mit einer persönliche Abgabe des Schlüssels. Dieses Vertrauensmodell erfordert leider einen direkten Kontakt zu dem Inhaber des Schlüssels, was nur in kleinen Gruppen möglich ist. Ist ein Schlüssel nicht mehr gültig, muss es jedem persönlich mitgeteilt werden. Außerdem kann der Besitzer eines Schlüssels bestreiten, dass der Schlüssel ihm gehört.

23 3.3. PKI 17 Vertrauenskette oder Indirect Trust: Das Modell der Vertrauenskette ist eine Erweiterung des Direct Trust Modells. Die Mitglieder einer Gruppe signieren gegenseitig ihre öffentlichen Schlüssel. Ein Schlüssel wird vertraut, sobald er von einer vertrauten Person signiert worden ist. Es entsteht somit eine Vertrauenskette. Ein Beispielansatz eines Vertrauensketten Modells ist die PGP Software von Philip Zimmermann. Dieses Modell bringt aber wie das Direct Trust Modell weitere Nachteile mit sich. Die Ungültigkeit eines Schlüssels bleibt weiterhin schwierig mitzuteilen, da es persönlich erfolgen muss. War ein Mitglied der Gruppe nicht vertrauenswürdig, hat dies negative Konsequenzen auf alle anderen, die ihm vertraut haben. Juristisch gesehen ist in diesem Modell die Unleugbarkeit auch möglich. Vertrauenswürdiger Dritte: Der zu verschickende Schlüssel wird selbst mit einem vertrauenswürdigen Schlüssel signiert. Der vertrauenswürdige Schlüssel gehört einer vertrauenswürdigen Institution, die jedem vertraut. Diese Institution bürgt für die richtige Zuordnung, Einheit zu Schlüssel. Auf diese Weise lässt sich eine Hierarchie aus vertrauenswürdigen Institutionen aufbauen. Die Unleugbarkeit des Besitzes eines Schlüssels ist hier nicht möglich. Die Gültigkeit der Schlüssel wird zentral verwaltet. Auf die Echtheit der Schlüssel der obersten Institutionen dieser Hierarchie muss man sich aber verlassen. Eine Gruppe vertrauenswürdiger Institutionen ist meistens in die verarbeitende Computer-Software integriert. Dies ist das Modell, dass in PKI eingesetzt wird Aufgaben einer PKI Die drei Hauptaufgaben einer PKI sind Authentisierung, Datenintegrität und Vertraulichkeit (Diese Begriffe wurden in Abschnitt 3.1 definiert). Authentisierung Authentisierung ist unabdingbar für ein sicheres System. Wie schon im Abschnitt 3.1 gesehen gibt es verschiedene Formen von Authentisierung. Man kann sich durch Besitz, Wissen, mit biometrische Merkmale oder durch andere Merkmale wie Handschrift authentisieren. Die Authentisierung in einer PKI läuft hauptsächlich mit einer Remote Verbindung. Hier ganz anders als bei der Authentisierung ohne PKI, in der Verbindungen verschlüsselt werden, muss nicht die Verbindung verschlüsselt werden um Replay Attacken 3 zu verhindern. Es muss keine Vereinbarungen getroffen werden welche kryptographische Verfahren benutzt werden: eine verschlüsselte Verbindung macht natürlich nur Sinn, wenn jeder Teilnehmer die Verfahren und die nötigen Schlüssel besitzt um die Daten zu verschlüsseln oder entschlüsseln. Es wird tatsächlich keine externe Absicherung der Verbindung gebraucht, weil die Zertifikate nicht geheim sein müssen. Die Sensitiven Daten wie Passwörter oder PIN werden über die Remote Verbindung nicht geschickt. Public-Key Infrastrukturen benutzen Challenge-Response 3 Replay Attacken sind Angriffe, bei denen der Angreifer nach dem Abhören von benutzten Daten in einer Verbindung versucht eine ähnliche Verbindung noch wiederaufzubauen.

24 18 3. Sicherheitsgrundlagen Techniken mit Signatur Unterstützung: Der Remote Server schickt ein Challenge an den Client. Der Client signiert den Challenge und schickt es zurück. Der Server verifiziert die Signatur des Clients mit Hilfe des gespeicherten öffentlichen Schlüssels dieser. Diese Sign-On Authentisierung wird oft benutzt. Es werden keinen sensitiven Daten geschickt, welche ein Angreifer benutzen könnte, um eine Wiedereinspielung zu versuchen. Es werden auch keine Vereinbarung vorher getroffen, darüber welche Verfahren benutzt werden. Datenintegrität Die Datenintegrität gibt die Garantie, darüber dass die Daten nicht unbemerkbar verändert von A nach B geschickt worden sind. Angenommen ein Dokument mit einer digitalen Signatur signiert, kann inhaltlich verändert werden: in einem geschäftlichen Austausch könnte zum Beispiel Verträge gefälscht werden. Ein niedriges Level von Sicherheit kann mittels Cyclic Redundancy Codes CRCs erreicht werden. Das ist eine Technik, die es ermöglicht Manipulationen von Bits zu entdecken, allerdings nur bei Bitsfehlern: diese werden dann meistens nur auftauchen, wenn der Angreifer vorhatte, die Nachricht zu beschädigen. Wenn der Angreifer die ganze Nachricht aber ändern kann, müssen kryptographische Techniken benutzt werden. Die PKI bietet eine Schnittstelle zwischen der Einheit, die Datenintegrität garantieren möchte und die Einheit, die sicher sein möchte, dass die Datenintegrität wirklich garantiert ist. Vertraulichkeit Die Vertraulichkeit garantiert die Datenintegrität. Keine Einheit darf die Daten lesen, wenn diese nicht an ihn geschickt wurden. Die Vertraulichkeit ist in einer PKI Struktur nicht wegdenkbar, weil Daten ständig auf öffentliche Netze fließen und private Schlüssel gespeichert werden. Es resultiert daraus eine kritische Frage: Wie realisiert eine PKI diese Aufgaben? Dafür ist es unvermeidbar die Komponenten einer PKI zu kennen Komponenten einer PKI Registrierungsinstanz in engl. Registration Authority: RA Die Registrierungsinstanz ist die Instanz, die für Zertifikatbeantragungen und Zertifikatverlängerungen zuständig ist. In manchen Fälle erhält die RA Passwörter zum Schutz und zur Sperrung des privaten Schlüssels, wenn beispielsweise das Zertifikat revoziert worden ist. Die RA hat zwei wichtige Aufgaben: Erfassen und Authentisieren der Identität der Benutzer: Die RA bürgt gegenüber der Zertifizierungsinstanz für eine direkte Verbindung zwischen öffentlichem Schlüssel und Identität sowie Attributen der Zertifizierungsinhaber. Aus diesem Grund muss sie sich selbst vor Problemen schützen, in der sie die Identität des Antragsstellers überprüft: zum Beispiel der Antragssteller muss sich mit Personalausweis ausweisen. Weiterhin sorgt die RA dafür, dass die Informationen in dem Zertifikat mit den Informationen von dem Nutzer übereinstimmen. Die gespeicherten Informationen können zu Problemen führen, wenn zum Beispiel zwei Nutzer den gleichen Namen haben: hier muss die RA mit notwendigen Maßnahmen die Konflikte auflösen.

25 3.3. PKI 19 Übertragen der Zertifizierungsanträge an die Zertifizierungsinstanz: Zertifikatsanträge können in einem Registrierungsbüro, über einen Webbrowser, aus vorhandenen Datenbankeinträgen oder als PKCS#1O Anträgen(siehe in [PKCS10] generiert werden. Die Anträge werden dann von der RA signiert und an die Zertifizierungsinstanz verschickt. Dies geschieht über eine direkte Verbindung mit Hilfe der Cryptographic Message Syntax CMS. Zertifizierungsinstanz in engl. Certification Authority: CA Die Certification Authority (CA) nimmt Zertifizierungsanfragen entgegen, überprüft diese, stellt ihren Benutzern Zertifikate aus und verwaltet Statusinformationen aller Vorgänge. Die Zertifikate werden mit dem privaten Schlüssel der CA von der CA signiert. Die Abläufe in einer CA werden in einem Certification Practice Statement (CPS) und die Bedingungen für eine Zertifizierung sowie der Einsatzzweck eines Zertifikats in einer Certificate Policy dokumentiert. Eine CPS kann auch Informationen zur Haftung einer CA bezüglich der Zertifizierung oder Verpflichtungen der Benutzer ( wie Sicherheitsvorgaben) enthalten. Certification Authority CA wird gern mit Certificate Authority - auch CA abgekürztverwechselt. Certification Authority erstellt zwar die Zertifikaten, verwaltet diese aber nicht. Zertifikatsrichtlinien in engl. Certificate Policies Die Richtlinien helfen die Nutzungsakzeptanz Zertifikate zu verwalten. In dem Standard X.509 sind Zertifikat-Richtlinien definiert. Sie beschreiben die Nutzungsgebiete des Zertifikates und die Sicherheitsvoraussetzungen, unter welche sie benutzt werden können. Die Zertifikatsrichtlinien legen auch die Pflichten und Rechte des Benutzers fest. Sie sind von Infrastrukturen und technischen Realisierungen unabhängig: dies ist von großer Bedeutung, da die Entscheidung einer Zertifizierungsinstanz zu vertrauen, dadurch einfach getroffen werden kann. Es gibt auch das CSP. Das CSP definiert die Richtlinien der ganzen Infrastruktur und ist im Gegenteil zu den Zertifikatsrichtlinien sowohl infrastrukturspezifisch, als auch technisch detailliert. Die Zertifikatsrichtlinien sind unter [RFC2527] standardisiert. Verzeichnisdienst Meist direkt an die CA gekoppelt beinhaltet eine PKI einen Verzeichnisdienst zur Veröffentlichung der Zertifikate und Sperrlisten. In den meisten Fällen wird das Leightweight Directory Access Protocol (LDAP) benutzt. LDAP ist eine vereinfachte Form des ITU-T X.500 Directory Access Protocols für die Internet- Protokollfamilie. Das Protokoll wird in [RFC2251], [RFC2252], [RFC2253], - [RFC2254], [RFC2256],[RFC2587], [RFC3494] definiert und aktualisiert. Nach [X500] werden Einträge im Verzeichnisdienst in einer Baumstruktur abgelegt. Die einzelnen Knoten bezeichnen einzelne Elemente, die jeweils durch einen eindeutigen Namen ( Distinguished Name, DN) bezeichnet werden. Ein DN setzt sich aus allen Knotenbezeichnern zusammen, die zwischen der Wurzel und dem Element liegen, dass er bezeichnet. Die einzelnen Bestandteile eines DN sind

26 20 3. Sicherheitsgrundlagen Informationen der Form Attribut = Wert, wobei die Attribute im so genannten LDAP-Schema definiert werden. Attribute sind zum Beispiel: c=de (Country, Land), st=hessen (Staat, Provinz, Bundesland), l=darmstadt (Locality, Stadt, Ort), o=tud (Organisation), ou=fb20 (Organisational Unit, Untereinheit), cn=hervé Seudié (Common Name, gewöhnlicher Name), usercertificate;binary=... (Benutzerzertifikat, Binärformat). Ein Beispiel für einen DN wäre cn=hervé Seudié, ou=fb20, o=tud, st=hessen, c=de. Wenn dem Objekt weitere Informationen hinzugefügt werden, sind diese als zusätzliche Attribute definiert, aber nicht Bestandteil des DN. Zeitstempeldienst in engl. Time Stamping Der Zeitstempeldienst ist einer der wichtigsten Komponenten, wenn es um Unleugbarkeit geht. Der Dienst muss vertraut werden, dass die von ihm markierten Zeiten nicht nur stimmen, aber tatsächlich von ihm gemacht worden sind. Technisch funktioniert es wie folgt: Der Zeitstempeldienst versieht die ihm vorgelegte Dokumente mit einem authentischen Zeitstempel, derer Integrität garantiert ist. Zusätzlich wird der Hashwert des Dokumentes gebildet und dem Zeitserver zum Signieren mit dessen privaten Schlüssel gegeben. So ist mit dem Zeitstempel festzustellen, seit wann es das Dokument gibt, seine Authentizität und seine Integrität. Sperrinstanz in engl. Revocation Authority Zertifikate sind immer so lange gültig wie sie nicht revoziert worden sind. Um zu vermeiden, dass revozierte Zertifikate benutzt werden, läuft eine ständige Überprüfung der Gültigkeit der Zertifikate durch die Zertifizierungsinstanz. Wird das Zertifikat revoziert (durch die CA oder der Besitzer), muss die als solche markiert und so gespeichert werden, dass alle Einheiten, die sich Informationen über die Gültigkeit eines Zertifikates beschaffen möchten, die Revozierung, wenn stattgefunden, problemlos erfährt. Die Instanz, die sich darum kümmert wird Sperrinstanz genannt. Diese Instanz versieht die revozierten Zertifikate durch Benutzung entweder Certificate Revocation Lists CRLs(Listen von revozierten Zertifikaten), die aktualisiert werden können, oder Online Certificate Status Protocol OCSP (mehr dazu in [RFC2560], die bei der Benutzung von Zertifikaten eine Online Überprüfung macht). Recoveryinstanz Zertifikate können aus verschiedenen Gründen revoziert werden: Verlust: Der PSE kann verloren werden und so muss der Besitzer sein Zertifikat revozieren. Ablauf der Gültigkeitsfrist: Die Gültigkeitsfrist des Zertifikates ist abgelaufen und wurde nicht erneuert. Sonstiges: Revozierung eines Zertifikates aufgrund Missachtung Richtlinien oder freiwilligem Trieb. In der Recoveryinstanz werden private Schlüssel gespeichert, wenn sie nicht zu Signaturzwecken benutzt werden. Diese bieten eine Art Key Backup für den Fall

27 3.3. PKI 21 eines Schlüsselverlustes. Somit können verschlüsselte Daten, immer entschlüsselt werden, auch wenn der Besitzer des privaten Schlüssels diesen verloren hat. Aber weil im Fall des Einsatzes einer Recovery Instanz der Besitzer nicht die einzige Einheit ist, die den privaten Schlüssel besitzt, können theoretisch Informationen über persönliche verschlüsselte Daten von einem Dritten gewonnen werden: Zum Beispiel von dem Staat mit juristischen Mitteln. Außerdem muss das Key Backup sicher sein, um die Angreifer daran zu hindern, Informationen darüber zu gewinnen. Im Fall von Signaturzwecken sind Recovery Instanzen nutzlos, weil deren Einsatz die Unleugbarkeit der Signatur ermöglicht PKI-bezogene Standards Standards sind wichtig um die Interoperabilität zwischen Endsystemen zu ermöglichen. Standard von der ITU-T Die International Telecommunication Union - Telecom Standardization Sector (ITU-T) gehört zu den bedeutendsten Standardisierungsorganisationen, die Standards für die IT-Branche festlegen. Die wichtigsten Standards in dem Bereich der PKI sind X.509, X.500 und seine Nachfolger LDAP. X.500 X.500 ist eine hoch komplizierte Verzeichnisstruktur auf der Basis einer Baumstruktur, die verschiedene Informationen verwaltet und eine große Anzahl von Features hat. Dieser Standard definiert unter anderem Protokolle zu Kommunikation zwischen Servern, Zugriffen von Clients zu Verzeichnissen so wie organisierte beschränkte Suche auf interessanten Teilbäumen. Dieser Standard ist die Basis von mehreren Anderen, wie X.509, der erst entstand als die Notwendigkeit Zugriffskontrolle auf das Verzeichnis und starke Authentisierung erkannt worden sind. X.509 X.509 beschreibt ein X.500 basierendes Authentication Framework, in dem ein Zertifikat Format definiert ist, das sehr flexibel ist und immer wieder verfeinert wird. Die letzte Version ist die X.509 v3. Das X.509 Zertifikat ist das heutzutage am meisten benutzte Zertifikatsformat. LDAP Das Lightweight Directory Access Protocol (LDAP) ist eine vereinfachte Form des X.500 Verzeichnisses. Das basiert auf einem Client/Server Modell. Standard von der RSA Laboratories Die Public Key Cryptography Standards (PKCS) der Firma RSA Security Inc. beschreiben alle wichtigen Dinge der Kryptographie, insbesondere deren praktische Verwendung. Sie wurden zusammen mit einigen namenhaften Firmen der IT-Branche festgelegt. Die einzelnen Standards behandeln unabhängige Aspekte der Kryptographie. Die meist benutzten PKCS Standards sind folgende: PKCS#1: RSA Cryptography Standard [PKCS1]. PKCS#7: Cryptographic Message Syntax Standard [PKCS7] PKCS#10: Certification Request Syntax Standard [PKCS10]

28 22 3. Sicherheitsgrundlagen PKIX PKCS#11: Cryptographic Token Interface Standard [PKCS11] PKCS#12: Personal Information Exchange Syntax Standard [PKCS12] PKCS#15: Cryptographic Token Information Format Standard [PKCS15] Die IETF (Internet Engineering Task Force) regelt in ihren RFCs (Request for Comment) alle Standards, die sich um das Internet handeln. Eine Arbeitsgruppe, die Gruppe Public-Key Infrastructure (X.509) mit der Abkürzung PKIX, beschäftigt sich mit dem Aufbau von hierarchischen Public-Key Infrastrukturen im Internet, unter Verwendung von Zertifikaten und Sperrlisten im ITU-T X.509 Format. Neben den bereits erwähnten RFCs hat diese Gruppe auch noch [RFC2510], [RFC2511], [RFC2585] spezifiziert, weitere Standards sind in Vorbereitung. ISIS-MTT Vereinigung zweier Standards ISIS (Industrial Signature Interoperability Specification) des T7 e.v. und MTT (MailTrusT) des TeleTrusT e.v. Er basiert hauptsächlich auf den Standards der ETSI und der IETF-Arbeitsgruppen PKIX und SMIME und will für die Kompatibilität von Signaturanwendungen sorgen, indem er diese Standards enger fasst. Gleichzeitig passt ISIS-MTT diese Standards auch für die Bedürfnisse des deutschen Signaturgesetzes an (siehe [SigV]). Deshalb gibt es auch einige Unterschiede zu PKIX.

29 Kapitel 4 Einführung in die Technologie von Chipkarten Als Chipkarten Anfang der 50er Jahre in den USA verbreitet wurden, enthielten diese Karten noch keinen Chip. Karten wurden benutzt um die Möglichkeit bargeldlos mit seinem guten Namen zu bezahlen [HaCH02]. Auf diesen Karten waren nur der Name des Inhabers und der Firmenname des Kreditsinstitutes vermerkt. Der Fälschungsschutz war komplett abhängig von den visuellen Merkmalen: Unterschrift von dem Karteninhaber und die gedruckten Namen des Inhabers und des Kreditinstitutes. Aus diesem Grund wurden die Karten hochgeprägt bedruckt um sie schwer kopierbar zu machen. Mit der steigenden Anzahl der Kartennutzer ist auch die Gefährdung durch organisiertes Verbrechen gewachsen. Außerdem hat die Zahlungsunfähigkeit mehrerer Kunden die Anzahl der Kartenausgebern negativ beeinflusst. Dies führte zu der Einführung von Magnetstreifen auf die Karten welche maschinenlesbar sind. Magnetstreifen ermöglichen das Speichern und auch das Ändern von Daten. Zum Beispiel können Kontostände nach dem Abheben des Geldes aktualisiert werden, so dass der Kunde nicht behaupten kann, mehr Geld zu haben als er in Wirklichkeit hat. Karten mit Magnetstreifen haben auch einen Nachteil mit sich gebracht: Die auf die Magnetstreifen gespeicherten Daten können mit Hilfe beliebiger Schreib-/Lesemaschinen für Magnetkarten geändert werden. Um die Sicherheit zu gewährleisten müsste eine Online-Verbindung bestehen um die Daten auf der Karte auf Echtheit zu überprüfen. Da so eine Einrichtung hohe Kosten hervorruft, wurde eine Lösung gesucht die auch offline Sicherheit gewährleistet. Karten mit integriertem Computerchip wurden also eingeführt: aus diesem Grund wurden sie Chipkarten genannt. Chipkarten bringen neue Möglichkeiten und Anwendungen mit sich, die auf sicherer Kommunikation basiert: Authentifikation, Elektronische Signatur, Verschlüsselung und vieles mehr. Der integrierte Prozessor (Beispielsweise kryptographische Prozessoren) und das geschützte Speichermedium stärken die Sicherheitsmechanismen. Um die Chipkarten zu bauen, muss man bestimmte Normen respektieren und auf eine Reihe von Eigenschaften aufpassen. Einen genaueren Überblick liefert das Buch [HaCH02]. 23

30 24 4. Einführung in die Technologie von Chipkarten 4.1 Normen Ein nationaler oder internationaler Einsatz der Chipkarten wie bei allen Produkten ist von der Interoperabilität von Chipkarten abhängig. Die Chipkarten, wie Telefonkarten oder Bankkarten, werden in vielen verschieden Bereichen zu alltäglichen Einsätzen. Ein einfaches Szenario kann wie folgt beschrieben werden: Ein Angestellter einer Firma muss sich an der Eingangstür der Firma authentifizieren (Gebäudezugang), dann muss er sich am Eingang seines Büros wieder authentisieren. Dann kommen die Anmeldung an seinem Rechner und die Online Erledigung seiner Arbeit mittels Digitale Identitäten. In jeder Etappe der Authentisierungsstellen muss die Karte zunächst erkannt werden. Sie muss dann die notwendigen Schnittstellen anbieten, die in dem einzelnen System beschrieben sind, damit die Systeme auf die Karten zugreifen können. Läge keine standardisierte Karte vor, würde es für den Anwender bedeuten, dass er für jedes System eine andere Karte braucht. Standardisiert werden die grundlegenden physikalischen Eigenschaften wie die Abmessungen der Karte, die Größe und Lage der Kontakte sowie die elektrischen Eigenschaften. Die grundlegenden Normen liegen heute als ISO-Standards vor und bilden die Basis für weitere, eher anwendungsorientierte Normen. Für die Standardisierung der Chipkarten (in der ISO-Norm als integrated circuit card (ICC) bezeichnet) wurde die bereits existierenden ISO-Standards der Reihen 7810, 7811, 7812 und 7813, in denen die physikalischen Eigenschaften von Identifikationskarten im so genannten ID-1-Format definiert sind, als Basis benutzt. Diese Standards schlossen hochgeprägte Karten und Karten mit Magnetstreifen ein, wie wir sie heute von den Kreditkarten her kennen. Diese Vorgehensweise hat einen problemlosen Übergang von alten Karten (hochgeprägt oder mit Magnetstreifen) auf Chipkarten ermöglicht: Zusätzlich zu der Hochprägung und die Magnetstreifen können andere Funktionselemente wie Hochprägung, Magnetstreifen, Kontakte und Interface-Elemente für kontaktlose Übertragung gleichzeitig in einer Karte integriert werden. Ein Überblick über die verschiedenen Standards zeigt die Tabelle 4.1. Wichtig ist jetzt die verschiedenen Chipkarten unterscheiden zu können, die Komponenten und Eigenschaften Chipkarten zu kennen um später bei der Wahl Chipkarten für die Anwendung an einer Hochschule sinnvolle Kriterien zu haben. 4.2 Hardware Arten von Chipkarten Chipkarten können in drei große Gruppen unterteilt werden, abhängig von den mit der Karte realisierbaren Anwendungen. Speicherkarten Speicherkarten sind die einfachste Form von Chipkarten. Sie enthalten nur einen nicht flüchtigen Speicher (in den meisten Fälle EEPROM max. 8 Kbytes) und keine Prozessoren, d.h. nicht rechenfähig: dafür sind Speicherkarten preisgünstig. Sie werden benutzt um bestimmte Daten zu speichern bzw. zu ändern. Bekannte Beispiele von Speicherkarten sind Telefonkarten und Krankenversicherungskarten. Das Bild 4.1 zeigt die Architektur einer Speicherkarte. Eine spezielle Art

31 4.2. Hardware 25 Norm ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC Beschreibung Physical characteristic Dimension and location of the contacts Electronic signals and transmission protocols Interindustry commands for interchange, secure messaging Registration system for applications in ICCs (AID), Registered appl. Provider identifiers (RID) Interindustry data elements Interindustry commands for Structured Card Query Language (SCQL) Security architecture and related interindustry commands Enhanced interindustrial commands Electronic signals and ATR for synch. cards Card structure and enhanced functions for multi applications use Tabelle 4.1: Übersicht der Normen von Chipkarten Abbildung 4.1: Architektur einer Speicherkarte.

32 26 4. Einführung in die Technologie von Chipkarten von Speicherkarten werden intelligente Speicherkarten genannt. Intelligente Speicherkarten besitzen zusätzlich eine Sicherheitslogik, die üblich für die PIN- Überprüfung benutzt wird. Damit ein Angreifer nicht beliebig oft versuchen kann den richtigen PIN zu erraten wird ein Zähler eingebaut, der die Anzahl der Fehlversuche speichert. So kann man nachdem die zulässige Anzahl, an Fehlversuchen überschritten ist, die Karte sperren. Mikroprozessorkarten und Speicherarten Mikroprozessorenkarten sind die Karten, die für einen Einsatz in einer PKI in Frage kommen. Dies lässt sich einfach dadurch erklären, dass sie die Prozessoren enthalten, die kryptographische Berechnungen ermöglichen. Zusätzlich zu den Prozessoren enthält diese Form der Chipkarten drei verschiedene Speicherbereiche: ROM: Read-only Memory ROM enthält das Betriebsystem der Karte, die Kryptoverfahren und das PIN-Überprüfungssystem. Das ROM ist über die Lebensdauer unveränderbar und nur lesbar wie es seinen Name ausdruckt. Dies ist durch Maskenprogrammierung erreicht. EEPROM: Electrically Erasable Programmable Read Only Memory EE- PROM ist der nichtflüchtige Speicherbereich der Karte. Hier werden zum Beispiel PIN, Schlüssel, Kontonummer sowie Programmcode unter Kontrolle des Betriebssystems gespeichert. RAM: Random Access Memory RAM ist der flüchtige Speicherbereich der Karte, der als Arbeitsspeicher benutzt wird. Die Daten, die in dem RAM gespeichert sind, werden nach einer Sitzung mit der Karte komplett gelöscht; nach der Abschaltung der Versorgungsspannung. Für die externe Verbindung dient die Eingabe/Ausgabe Schnittstelle (I/O System). Das Bild fig:mikroprozessorkarten zeigt die Architektur einer Chipkarte. Kontaktlose Chipkarten Bis jetzt wurde nur über kontaktbehaftete Chipkarten d.h. Chipkarten diskutiert, die in einem Kartenleser eingesteckt werden müssen. Die Kontaktierung mit dem Kartenleser, die in der ISO Norm 7816 festgelegt ist, ist aber die Quelle der meistens elektromechanischen Fehlern wegen der direkten Verbindung der Oberfläche der Chipkarten mit den Eingängen der integrierten Schaltung. Näheres dazu in [HaCH02]. Kontaktlose Chipkarten lösen die technischen Probleme und bringen neue Möglichkeiten mit sich. Es wird kein Kartenleser gebraucht um eine Verbindung zwischen dem Terminal und die Karten zu haben, sondern mit Hilfe einer in der Karte eingebauten Antenne. Deutliche Vorteile gibt es bei Anwendungen, die relativ schnell bei Menschengruppierungen ausgeführt werden müssen: Das sind zum Beispiel Gebäudezugänge, Bezahlungen in der Mensa, wo die Nutzer ohne die Karte in einem Gerät stecken zu müssen bezahlen oder sich identifizieren können. Wandalismusaktionen gegen die Kartenlesersysteme sind auch verringert, da nichts in dem Kartenleser gesteckt werden kann. Systemausfälle, weil eine Karte stecken geblieben ist, sind auch hier vermieden. Für den Kartenhersteller gibt es den Vorteil, dass er in der Gestaltung

33 4.2. Hardware 27 des Designs nicht eingeschränkt ist, da kein technisches Element an der Kartenoberfläche sichtbar ist. Dies ist aber nicht sehr relevant, da kontaktbehaftete Karten meistens mit kontaktlosem Chip ausgestattet werden (am meisten eingesetzt, der Mifare Chip). Ein großer Nachteil der kontaktlosen Karten sind die teuren Systemen, die sie benötigen um einwandfrei zu funktionieren.

34 28 4. Einführung in die Technologie von Chipkarten Abbildung 4.2: Architektur einer Mikroprossezorkarte Abbildung 4.3: Architektur einer kontaktlosen Karte

35 4.2. Hardware Eigenschaften von Chipkarten Kartenformate Kartenformate sind nach der Norm ISO 7810 festgelegt. Das bekannteste Format ist das ID-1 Format. ID steht für Identifikation: In dem Jahr 1985 als die erste Norm bekannt geworden ist, diente die Karte nur zur Identifikation und nicht zur Authentifikation. Der Einbau eines Chips wurde erst später normiert. Vorteile des ID-1 Formates sind die Handhabung und die Flexibilität. Die Karte lässt sich in Taschen oder Geldbeutel stecken und ist nicht so klein, dass sie leicht verloren werden kann. Sie ist nicht steif, so dass sie leicht gebrochen werden kann. Versicherungskarten, Bankkarten sind Beispiele von Karten mit ID-1 Format. Das Bild 4.4 ist eine Zeichnung des ID-1 Format. Das nächste Format wurde Abbildung 4.4: ID-1 Format normiert, weil das ID-1 Format die neuen Forderungen der Miniaturisierung in der heutigen Technik nicht erfüllen konnte. Mit der Entwicklung kleiner Geräten, wie das tragbare Telefon, mussten neue kleineren Karten gebaut werden und dies auch in neuen Normen festgestellt werden. Das Problem der Handhabung musste hier nicht beachtet werden, da die kleinen Karten nur einmal in das passende Gerät gesteckt werden müssen. Dies führte zur der Definition des ID- 000 Format, welches in Bild 4.5 präsentiert wird. Eine neue Generation von Abbildung 4.5: ID-000 Format

36 30 4. Einführung in die Technologie von Chipkarten Chipkarten zur Authentisierung besteht aus eine Mischung ID-000 Format und ID-1 Format(Bild 4.6, die sowohl mit einem seriellen Kartenleser als auch mit einem USB-Token benutzt werden: Dies ist zum Beispiel der Fall bei der Karte Cryptoflex von der Firma Schlumberger. Es gibt noch ein Format, das sich bis Abbildung 4.6: ID1- und ID-000 Format in einem jetzt nicht durchsetzen konnte: das ID-00 Format, dass praktisch die Hälfte einer Karte mit ID-1 Format darstellt. Abbildung 4.7: ID-00 Format Kontaktbehaftete Karte Eine kontaktbehaftete Karte muss in einen Kartenleser, um dort eine direkte Verbindung zum leitenden Mikromodul (typisch vergoldet) herzustellen. Mittels dieses physischen Kontaktpunktes findet die Übertragung von Kommandos und Daten statt. Kontaktlose Karte Durch den Verschleiß von kontaktbehafteten Karten bei häufiger Benutzung durch die Kontaktiereinheit von Kartenlesern sind kontaktlose Chipkarten immer mehr ins Gespräch gekommen. Sie sind unempfindlicher gegenüber Verschmutzungen, Vibration, Feuchtigkeit und elektrostatischer Aufladung. Eine kontaktlose Karte benötigt nur die Nähe eines Lesegerätes. Lesegerät und Karte

37 4.2. Hardware 31 besitzen beide eine Antenne und nur mit dieser kontaktlosen Verbindung kommunizieren sie. Die meisten kontaktlosen Karten beziehen ihre interne Energie durch dieses elektromagnetische Signal, die Energieversorgung erfolgt also induktiv. Die Entfernung zwischen Leser und Karte beträgt bei einer Karte ohne Batterie ca. 5-7 cm, und das ist ideal für Anwendungen wie der Massenbeförderung, die sehr schnelle Kartenschnittstellen benötigt. Kombi-Karte und Hybrid-Karte Zwei zusätzliche Kategorien (abgeleitet von den Beiden zuvor genannten) sind die Kombi-Karte und die Hybrid-Karte. Eine Hybrid-Karte besteht aus zwei Chips, jede mit einem Kontakt- bzw. kontaktlosen Interface. Die beiden Chips sind nicht verbunden, aber für viele Anwendungen genügt sie dem Bedarf des Verbrauchers und des Herstellers. Neu sind die Kombi-Karten, welche einen einzigen Chip mit beiden Interfaces verbindet. Somit kann ein und derselbe Chip über beide Systeme, mit einer sehr hohen Sicherheitsstufe angesprochen werden. Mifare, Legic und Hi-Tag sind hier die neuesten Techniken. Datenübertragung Für die Kommunikation zwischen Chipkarte und Terminal steht nur eine einzige Leitung zur Verfügung. Dadurch können Informationen nur wechselseitig ausgetauscht werden. Dieses abwechselnde Senden und Empfangen wird als Halbduplex Verfahren bezeichnet. Das Vollduplex Verfahren, bei dem beide Teilnehmer gleichzeitig senden und empfangen können, ist derzeit in der Chipkartenwelt noch nicht verwirklicht. Da jedoch die meisten Chipkarten-Mikrocontroller zwei I/O-Ports haben und zwei der acht Kontakte für zukünftige Anwendungen reserviert sind, wäre eine Vollduplex - Verbindung technisch möglich. Erste Vorschläge für eine Normierung liegen bereits vor. Grundsätzlich reagiert die Chipkarte immer auf Anfragen des Hosts, der entweder ein selbständiges Kartenterminal, mit eigener Applikation oder ein von einem Computersystem angesteuerter Chipkartenleser ist. Zwar gibt es Ansätze, dass die Chipkarte sich beim Eintreffen eines Ereignisses von alleine zurückmeldet, jedoch sendet sie in der Regel keine Anfragen an den Host. Es ergibt sich ein Master Slave Verhältnis, mit dem Host als Master und der Karte als Slave. Bei jeder Datenübertragung ist die Einhaltung von Regeln notwendig, die in den Protokollen definiert sind. Die Chipkartenprotokolle sollen folgende Funktionen beinhalten: Datenverluste auf der Übertragungsstrecke erkennen Datenverfälschungen auf der Übertragungsstrecke erkennen Synchronisation Es sind insgesamt 15 Übertragungsprotokolle in der ISO-Norm vorgesehen. Ihre Bezeichnung setzt sich aus dem Ausdruck T= und einer nachfolgenden natürlichen Zahl zusammen. Die Tabelle 4.2 zeigt einen Überblick: Betriebsysteme Das Betriebssystem wird als ROM in der Chipkarte (Mikrokontroller) beim Hersteller eingebaut. Das EEPROM ist für die spätere Verwendung leer. Tre-

38 32 4. Einführung in die Technologie von Chipkarten ten beim Test des Chips keine Fehler auf, so werden vom Hersteller Schmelzbrücken physikalisch aufgetrennt, die einen späteren Zugriff auf die Testfunktionen unterbinden. Vor dem ausliefern der Chipkarten werden diese noch mit einem Transportcode versehen, der vom Kunden eingegeben werden muss, um seine eigene Software einzubringen. Eigene Software einbringen bedeutet, dass der Kunde die Karte für seine speziellen Wünsche personalisieren kann, d.h. den leeren EEPROM beschreibt. Nach der Personalisierung geht die Karte zum Endverbraucher, der die Karte für einen festgelegten Zeitraum (max. für ca Steckzyklen) verwenden kann: Chipkarten haben eine begrenzte Lebenszeit, die lang genug ist, um ausreichend zu sein. Genauso wie ein großer Computer, braucht auch der Chipkartenmikrocontroller ein Betriebssystem, das die Steuerung und Kontrolle der Programme übernimmt. Bei einer Chipkarte steht nicht so sehr die Kontrolle von externer Hardware im Vordergrund, sondern viel mehr die folgenden Funktionen: Datenaustausch mit der Chipkarte Dateiverwaltung Kryptographische Funktionen Zugriffskontrolle und Sicherheit So wie z. B. das Betriebssystem DOS für Disk Operation System steht, gibt es die Bezeichnung COS für das Chipcard Operating System. Viele Hersteller setzen häufig noch ihre Produktbezeichnung vorne an (z. B. TCOS Telesec Chipcard Operating System, ODS-COS Oldenbourg Datensysteme, STARCOS, etc.). Die Systeme richten sich in der Regel nach der ISO-Norm und stellen alle dort festgelegten Kommandos zur Verfügung. Das COS ist mit max. 16 KByte ROM recht klein. Dies wird unter anderem dadurch erreicht, dass die Karte unter Assembler programmiert wird. Ein Update wie bei Computern ist nach der Herstellung nicht mehr möglich. Die Befehle erreichen den Mikrocontroller über die serielle IO-Schnittstelle. Fehler werden vom IO-Manager unabhängig von den anderen Modulen gehandelt. Sofern ein Kommando erfolgreich empfangen wurde, wird dieses vom Security Manager ggf. entschlüsselt und auf Korrektheit überprüft. Anschließend analysiert der Kommandointerpreter den Befehl und führt ihn aus bzw. generiert mit dem Rückmeldungsmanager einen Fehler der über den IO-Manager ein Statusfehlerwort für den Terminal zurückliefert. Wenn alles geklappt hat, dann geht der Befehl an den Kanalmanager, der bis zu vier logische Kanäle parallel verwalten kann (entsprechend der Chipkartenanwendungen). Danach wird die Zustandsmaschine aufgerufen. Hier wird die erste semantische Prüfung durchgeführt, nämlich ob der Befehl mit den gegebenen Parametern im aktuellen Zustand der Zustandsmaschine überhaupt erlaubt ist. Verläuft die Prüfung positiv, wird der Befehl in den eigentlichen Programmcode konvertiert und ausgeführt. Andernfalls wird wieder mit dem Rückmeldungsmanager ein Fehler über den IO-Manager an das Terminal gesendet. Sofern der Befehl einen Dateizugriff auslöst, wird dies mit Hilfe der Dateiverwaltung ausgeführt, die die logischen Adressen in einer internen physikalischen Adressdarstellung umwandelt und auch die Bereichsgrenzen sowie die Zugriffsbedingungen kontrolliert. Die Dateiverwaltung ist ähnlich der vom DOS (hierarchisch / Baumstruktur) und für Chipkarten in der Norm ISO definiert. Das Masterfile (MF) stellt das Wurzelverzeichnis, das immer beim Reset

39 4.3. Sicherheit 33 der Chipkarte selektiert ist. Sofern eine Chipkarte über mehr als eine Anwendung verfügt, können noch Dedicated files (DF) angelegt werden, unter denen die verschiedenen Anwendungen Platz finden. Die Schachtelungstiefe der DF s (Unterverzeichnisse) ist beliebig und nur durch den Speicherplatz begrenzt. Die eigentlichen Daten sind in den Elementaryfiles (EF) abgelegt, die sich unterhalb des Masterfiles (MF) oder der Dedicated Files (DF) befinden können. Bevor man auf eine Datei zugreifen kann, muss man die Applikation (Anwendung) selektieren in der sich die Datei befindet und schließlich die Datei selbst selektieren. Die Applikationsbezeichnungen sind mit einer Länge von 5-15 Bytes hexadezimal codiert und bestehen aus zwei Einheiten. Die Identifikationskennung (RID) mit einer festen Länge von 5 Bytes (Ländercode, Anwendungskategorie und Nummer für den Anwendungsanbieter) und einer optionalen Kennung PIX, die 0-11 Byte lang sein kann. Damit man die Datei selektieren kann, muss man diese über einen Namen (FID File Identifier) ansprechen können. Dieser Name besteht aus 2 Byte hexadezimal codierte Zahlen (z. B. 3F00 für das Masterfile). Die Datenstrukturen sind häufig im ASN.1 (Abstract Syntax Notation One) gehalten, die sich z. B. schon bei der Krankenversichertenkarte Einzug gehalten hat. 4.3 Sicherheit Die Sicherheit in einer Chipkarte umfasst den Schutz der in der Karte gespeicherten Daten so wie den Schutz von unautorisierter Benutzung der Karte (meistens durch Verwendung eines PIN s). Außerdem muss bei der Übertragung der sich auf der Karte befindenden Informationen einen Schutzmechanismus geboten sein, damit ein Angreifer keinen unautorisierten Zugriff auf diese bekommen kann: dies ist durch Secure Messaging gewährleistet. Die Sicherheit in der Karte hängt von den Sicherheitseigenschaften des Chips und des Betriebssystems ab Angriffe Die Verschiedenen Angriffe auf Chipkarten können in drei große Bereiche geteilt werden. Angriffe während der Entwicklung Die Entwicklung muss geheim vorangetrieben werden. Der ganze Chipdesign und die Implementierung des Betriebssystems darf nur von bestimmten Personen bekannt sein, so dass umfangreiches Insiderwissen gebraucht wird, um sicherheitsschwächende Veränderungen vornehmen zu können. Angriffe während der Produktion Die Produktion der Karten muss in einer hoch sichere Umgebung erfolgen. Angreifer dürfen nicht die Möglichkeit haben, die Karte durch Dummy-Karten zu wechseln, welche sie dann benutzen können um Angriffe zu starten.

40 34 4. Einführung in die Technologie von Chipkarten Angriffe während der Kartenbenutzung Angriffe während der Kartenbenutzung sind die am meisten realisierten Angriffe. Hier werden bestimmte Schwächen von Chipdesign und Datenübertragungsart ausgenutzt. Die bekanntesten Angriffe der letzten Jahre sind Simple Power Attacks (SPA) und Differential Power Attacks (DPA). Für eine Übersicht mit mehr Details wird auf [WRA] verwiesen. 4.4 Chipkarten und Digitale Identitäten Chipkarten bieten einen sicheren handhabbaren Datenträger mit Kryptoprozessoren für die Speicherung und Berechnung mit kryptographischen Schlüsseln. Je nach ihren Speicherplätzen können in Karten ein oder mehrere Schlüsselpaaren und Zertifikate gespeichert werden: Dies kann sich als nützlich durchsetzen, wenn man Anwendungen hat mit verschiedenen Sicherheitsniveaus. Digitale Zertifikate in Kombination zu Authentisierung müssen für eine spätere Benutzung als digitale Identität immer mit dem privaten Schlüssel gespeichert werden. Noch sicherer ist es, wenn die Karte prepersonalisiert ist, so dass der private Schlüssel nur in der Karte zu finden ist und vor allem die Karte nie verlässt: Nur mit Eingabe eines PIN s ist der private Schlüssel benutzbar. In Betriebssystemen werden Zeiger auf die digitalen Zertifikate in der Karte gespeichert. Diese Verbindung zu der Karte läuft über den Standard PKCS#11 und wird in Microsoft Produkten zusätzlich mit Hilfe eines CryptoServiceProvider CSP unterstützt. Der Versuch das Zertifikat zu Authentisierung, Signatur oder Verschlüsselung zu benutzen, verursacht einen Zugriffsversuch auf die Daten auf der Karte, was gleich ist wie der Versuch die Karte zu benutzen. Die Benutzung der Karte ist aber PIN geschützt: Das heißt, es löst die Anfrage einer PIN Eingabe. Der PIN zusätzlich zu dem Besitz der Karte, ist das wesentliche Sicherheitsmittel in diesem Szenario. Chipkarten erweisen sich also, als sehr gute Personal Security Environment für die Multi kryptographischen Anwendungen in einer PKI. Das ist der Grund, warum sie immer in Firmen sowie in Forschungsinfrastrukturen wie Hochschulen und speziell in diesem Fall an der TU-Darmstadt eingesetzt werden Standards Um mit der Karte arbeiten zu können, müssen erst die benötigten Daten auf die Karten geschrieben werden. Für die Anwendung von Chipkarten in einer PKI sind diese Daten PIN, private Schlüssel und Zertifikate. Diese Karten können aber auf verschiedene Weisen in der Karte gespeichert werden, so dass keine Interportabilität bis jetzt gewährleistet ist. Dies hat aber sowohl für die Anwender als auch für die Benutzer keine Vorteile, da man sich für jede Karte mit unterschiedlichen Strukturen neu einarbeiten müsste um zu wissen wie man mit der Karte arbeiten muss. Um diese Problemen zu lösen hat die RSA Laboratories 1 Standards vorgeschlagen. In [RSALaB] kann ein genauerer Überblick über kryptographische Standards gewonnen werden. 1 Das ist die Forschungsabteilung der Firma RSA Security Inc, die von den Erfindern des kryptographischen Verfahrens RSA gegründet worden ist.

41 4.4. Chipkarten und Digitale Identitäten 35 PKCS#15 PKCS#15 steht für Cryptographic Token Information Format Standard. Dieser Standard definiert, wie kryptographische Daten auf eine Karte gespeichert werden. [PK15] stellt den kompletten Standard dar. Im Gegenteil zu den von kommerziellen Firmen am meistens benutzten Formaten, die eine Konfigurationsdatei für die Beschreibung der Kartenstruktur benutzen, ist PKCS#15 ein Format was auf der Karte gespeichert wird. PKCS#15 kann auf jeder ISO/IEC kompatiblen Karte gespeichert werden. Das Informationsformat ist in ASN.1 definiert um die Kompatibilität mit den Standards ISO/IEC und ISO/IEC und ISO/IEC zu gewährleisten. Außerdem ist die Zusammenarbeit mit PKCS#11 Implementierung vereinfacht durch die objektorientierte Vorgehensweise, wo Schlüssel, Zertifikate und andere Daten als Objekte mit Attributen und Werten behandelt werden. Damit Applikationen problemlos herausfinden, welche Algorithmen, Schlüssel und Zertifikate auf der Karte gespeichert sind, wie die Objekte auf der Karte geschützt sind, welche Objekte aktualisiert werden können, sind verschiedene Verzeichnisse eingeführt worden. ODF: Der Object Directory File ist ein Verzeichnis, das Pointer auf alle Verzeichnisse mit elementaren Daten wie Informationen über private Schlüssel und mehr enthält. PrKDF, PuKDF, SKDF: Genannt die Cryptographic Key Directory Files, diese Verzeichnisse enthalten jeweils Informationen über private Schlüssel (Private Key Directory Files) Informationen über öffentliche Schlüssel (Public Key Directory Files) und Informationen über symmetrische Schlüssel (Secret Key Directory Files). Diese Verzeichnisse sind alle optional, aber mindestens eins muss in einer Karte zu kryptographische Zwecken vorgegeben sein. CDF: Die Certificate Directory Files Verzeichnisse enthalten Informationen über Zertifikate. Zertifikate und die dazugehörigen privaten Schlü-ssel haben den gleichen Identifier. Diese Verzeichnisse sind alle optional, aber mindestens eins muss in einer Karte zu kryptographische Zwecken vorgegeben sein. AODF: Die Authenticate Object Directory Files Verzeichnisse enthalten Informationen über Objekte zu Authentisierung wie PIN. Jedes Objekt hier hat eine eindeutige Referenznummer, die benutzt wird, um PIN mit Schlüssel zu referenzieren. DODF: Die Data Object Directory Files Verzeichnisse enthalten Informationen über alle andere Objekte als kryptographische Daten. Token Info File: Dieses Verzeichnis enthält allgemeine Informationen über die Karte als solche. Es ist trotz dieser Verzeichnisdefinition nicht notwendig alle Informationen über die sensitiven Daten in der Karte zu speichern. PKCS#15 unterstützt die Referenzierung externe Daten wie Zertifikate, die in anderen Orten gespeichert sind: wie in einem LDAP Verzeichnis. Das Bild 4.8 stellt die Struktur der Daten nach PKCS#15 dar. 2 siehe Anhang

42 36 4. Einführung in die Technologie von Chipkarten Übertragungsprotokoll Beschreibung Bemerkung T=0 asynchron, halbduplex byteorientiert - speziell in Frankreich sehr verbreitet T=1 asynchron, halbduplex blockorientiert fortschrittlichstes Übertragungsprotokoll T=2 reserviert für zukünftige vollduplex Anwendungen konkreter Standardisierungsvorschlag der DeTeMobil GmbH T=3 reserviert für zukünftige vollduplex Anwendungen T=4 asynchron, halbduplex byteorientiert - in Arbeit, Erweiterung von T=0 T=5 bis T=13 reserviert für zukünftige vollduplex Anwendungen T=14 für nationale Anwendungen, nicht von ISO genormt Protokoll der deutschentelekom AG T=15 reserviert für zukünftige Erweiterungen Codierungsmöglichkeit bei mehr als 15 Protokollen Tabelle 4.2: Übersicht der verschiedenen Übertragungsprotokollen Abbildung 4.8: Verzeichnisstruktur nach PKCS#15 Standard

43 4.4. Chipkarten und Digitale Identitäten 37 PKCS#11 Während PKCS#15 die Struktur auf die Tokens beschreibt, beschreibt PK- CS#11 eine Schnittstelle, genannt Cryptoki, die es einem Programm erlaubt auf eine standardisierte Schnittstelle zur Ansteuerung von Cryptotokens zuzugreifen. Alle Geräte, die eine Cryptoki-Schnittstelle bieten, können also gleich angesprochen werden, solange das Gerät die gleichen Funktionen bietet. Cryptoki abstrahiert die Hardware des Geräts als Slots und Tokens: Slots sind meistens Kartenleser oder andere Geräte, die Tokens halten können. Tokens sind Cryptogeräte: Zum Beispiel Smartcards, mit deren Hilfe entschlüsselt, verschlüsselt und signiert werden kann. Durch diese Abstraktion der Hardware wird dem Entwickler ermöglicht seine Software so zu gestalten, dass sie verschiedene Hardware und verschiedene Betriebsysteme nutzen kann. Angewendet wird PKCS#11 bei allen Betriebsystemen für die Kommunikation mit einem kryptographischen Token.

44 38 4. Einführung in die Technologie von Chipkarten

45 Kapitel 5 Anforderungsanalyse für die Integration von Chipkarten als digitale IDs Die Einführung einer PKI stellt die Basis fest, für die Einführung Chipkarten als digitale Identität. Die Einführung einer PKI geht aber über die Grenzen dieser Arbeit hinaus. Das Thema wurde schon in der Arbeit [JZ03] von Jens Zörkler bearbeitet. Die Einrichtung einer PKI macht nur dann Sinn, wenn sie nützlich ist. Die PKI wird erst nach der erfolgreichen Benutzung digitalen Identitäten für die verschiedenen vorgesehenen Anwendungen nützlich. Die Digitale IDs werden in der PKI als Ausweis angewendet und öffnen die Möglichkeiten kontrollierte und sichere Authentisierung sowie Signatur, Verschlüsselung und Entschlüsselung von Mails durchzuführen. Außerdem bietet die PKI eine sichere Verwaltung (Erstellung, Revozierung etc.) von Digitalen Identitäten. Was die PKI aber nicht anbietet, ist eine sichere Aufbewahrung der digitalen Identitäten. Wie sollte dies überhaupt funktionieren? Welcher Sinn hätte es die digitalen Identitäten, die sehr persönlich sind, in einer PKI aufzubewahren, wenn man diese frei benutzen möchte? Man könnte sich denken, dass man jedes Mal die Zertifikate mit Hilfe der Eingabe von PIN s herunterlädt, bevor man sie benutzt. Dies würde die Benutzung von Zertifikaten aber sinnlos machen, da eine online PIN Authentifizierung genau das ist, was die Anwendung von digitalen IDs eigentlich verbessern sollte. Die Frage der Aufbewahrung der Zertifikate und vor allem des Schlüssels ist auch deswegen wichtig, weil der Inhaber des Schlüssels der einzige sein muss, der sein Zertifikat benutzen kann. Wird ein Zertifikat in einem Browser installiert und der Schlüssel nicht mit einer PIN-Eingabe gekoppelt, kann jeder, der Zugriff auf den Browser hat, die Zertifikate benutzen: auch wenn eine PIN-Eingabe mit dem Schlüssel gekoppelt ist, ist der Schlüssel auffindbar. Es ist möglich für einen Angreifer, einen Brute Force Angriff erfolgreich einzusetzen. Diese Szenarien sind aber nicht gewollt. Benutzt man sein Zertifikat auf einem fremden Rechner, muss man dieses gleich deinstallieren und am besten löschen, da die gewählte Passphrase zu Schutz des privaten Schlüssels meist leicht zu erraten sind und es gibt keinen Mechanismus zu automatischen Sperre nach einer bestimmten Anzahl von Fehleingaben. Das ist aber nicht benutzerfreundlich. Zusammengefasst möchte der Benutzer einer Digitalen Identität folgendes 39

46 40 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs machen können: Einziger sein, der seine Digitale Identität benutzen kann: Dies ist gewährleistet, wenn die Benutzung des Schlüssels geschützt ist. Möchte man das installierte Zertifikat für eine andere Anwendung als Verifizierung von Signatur oder Verschlüsselung von Nachrichten benutzen, wird man aufgefordert eine PIN einzugeben. Digitale Identität überall benutzen, wo er diese braucht ohne großen Umstand: Dies ist gewährleistet, wenn der Benutzer die Möglichkeit hat, sein Zertifikat immer bei sich zu haben und die technischen Voraussetzungen dargeboten sind, dieses zu benutzen. Übliche Funktionen einer digitalen Identität benutzen: Sichere und eindeutige Authentifikation, hochwertige Signatur von Mails, sichere Verschlüsselung und Entschlüsselung. Dies ist gewährleistet durch die Interoperabilität der Karte mit den verschiedenen Clients. Chipkarten bieten diese Möglichkeiten und wurden gewählt als Datenträger für die Benutzung von Zertifikaten. Diese sind handhabbar, leicht zu stecken, und sicher (siehe Kapitel 4). Die Benutzung von Chipkarten ist mit verschiedenen Anforderungen gekoppelt, die erst erfüllt werden müssen, bevor man die Chipkarten einsetzen kann. 5.1 Rechtliche Anforderungen Es kann nur etwas an einer Universität wie auch wo anders eingeführt werden, wenn es rechtlich in Ordnung ist. An einer Universität werden diese Anforderungen von dem rechtlichen Beauftragtern geregelt. Die Einführung einer Chipkarte an sich, solange sie nicht zwingend für eine Einschreibung, ist rechtlich in Ordnung. Erst wenn die Chipkarte Bedingung für die Einschreibung eines Studenten wird, oder für bestimmte Anwendungen angesetzt wird, wird es rechtlich kritisch: Studentenrechte und gesetzlich gemäße Anwendungen Hochschulrecht Studenten können nicht einfach zur Benutzung von Chipkarten gedrängt werden. Die Benutzung der Karte kann nur gezwungen werden, wenn sie für etwas benutzt wird, was der Student schon vorher machen musste. Ein gutes Beispiel ist die Benutzung der Karte als Studentenausweis: an der Universität von Gießen und an der Fachhochschule Frankfurt wurde dies eingeführt. Die verschiedenen rechtlichen Rahmen abhängig von den unterschiedlichen gewählten Verfahren der zwei Hochschulen (siehe [DaH2]) zeigen, dass es keine einfache Vorgehensweise ist. Die allgemeinen rechtlichen Rahmen sind in der Verordnung des Hessischen Ministeriums für Wissenschaft und Kunst über die Verarbeitung personbezogener Daten und das Verfahren der Immatrikulation an den Hochschulen gegeben: 4 Abs. 2 des Hessischen Datenschutzgesetzes HDSG zur Verordnung über die Verarbeitung von personenbezogenen Daten und über das Verfahren der

47 5.1. Rechtliche Anforderungen 41 Immatrikulation an den Hochschulen des Landes Hessen. Die Hochschule kann den Studienausweis als Chipkarte ausstellen. Der Datenspeicher der Chipkarte enthält als einzige personenbezogene Daten Namen und Ident-/Matrikelnummer. Auf der Chipkartenoberfläche befinden sich die Angaben nach Absatz 1, die Bibliotheksbenutzernummern mit Barcode des/ der Studierenden und ein Foto der Karteninhaberin oder des Karteninhabers. Die Einzelheiten des Nutzungsumfangs der Chipkarte bezüglich allgemeiner Serviceangebote der Hochschule wie etwa Einschreibund Rückmeldeverfahren, Zugang zu Parkplätzen oder Nutzung von Hochschulrechenzentrum oder Bibliothek sowie der Einbeziehung von Angeboten des Studentenwerks und der Kosten regelt die Hochschule in einer Satzung. Aus der Quelle [DaH3]. Dieser Punkt ist nur eine zentrale Regelung. Die einzelnen Ausgestaltungsvarianten sind den Hochschulen überlassen. Vor den zwei Schritten sind auch durch Verordnung des Hessischen Datenschutzgesetze folgende Schritten durchzuführen. So genannte Vorabkontrollen müssen gemacht werden.die Kontrollen dienen der Einschätzung, Chancen und Risiken für die Studenten bei der Benutzung von Chipkarten. Die folgende Verordnung regelt es: 7 Abs. 6 HDSG Wer für den Einsatz oder die wesentliche Änderung eines Verfahrens zur automatisierten Datenverarbeitung zuständig ist, hat vor dem Beginn der Verarbeitung zu untersuchen, ob damit Gefahren für die in 1 Abs. 1 Nr. 1 geschützten Rechte verbunden sind; dies gilt in besonderem Maße für die in 1 Abs. 4 genannten Daten. Das Verfahren darf nur eingesetzt werden, wenn sichergestellt ist, dass diese Gefahren nicht bestehen oder durch technische und organisatorische Maßnahmen verhindert werden können. Das Ergebnis der Untersuchung und dessen Begründung sind aufzuzeichnen und dem behördlichen Datenschutzbeauftragten zur Prüfung zuzuleiten. Aus der Quelle [DaH2] Bevor man etwas neues für die Studenten einführt, ist unabdingbar, dass man sie darüber informiert. Die Studenten über ihre Organisation AStA (Allgemeine Studierendenausschuss) entscheiden, ob sie die neue Einführung zustimmen. 8 Abs. 2 HDSG Wenn eine in 3 Abs. 1 genannte Stelle für die Gewährung einer Leistung, das Erkennen einer Person oder für einen anderen Zweck einen Datenträger herausgibt, auf dem personenbezogene Daten des Inhabers automatisiert, etwa in Form einer Chipkarte, verarbeitet werden, dann hat sie sicherzustellen, dass er dies erkennen und seine ihm nach Abs. 1 Nr. 1 bis 5 zustehenden Rechte ohne unvertretbaren Aufwand geltend machen kann. Der Inhaber ist bei Ausgabe des Datenträgers über die ihm nach Abs. 1 zustehenden Rechte sowie über die von ihm bei Verlust des Datenträgers zu treffenden Maßnahmen und über die Folgen aufzuklären. Aus der Quelle [DaH3] Die Erfahrung gesammelt nach Beobachtung des Ansatzes an der Justus-Liebig Universität Gießen (siehe in [UnGi2]) zeigt, dass die Benutzung der Karte eine Reihe von Nachteilen mit sich bringt. Nicht nur die ganzen Kontrollen und

48 42 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs der Aufwand vor der Einführung ist ein Nachteil, sondern die Inbetriebnahme und den Betrieb mit beispielsweise tausenden Karten, die jedes Semester neu bedruckt werden müssen. Wegen dem Aufwand, der durch seine Einführung hervorgerufen wird, wird in dieser Arbeit die Benutzung von Chipkarte als Studentenausweis und für Rückmeldung nicht empfohlen: das sind die Anwendungen, die jedes Semester den größten Aufwand hervorrufen Anwendungsbezogene gesetzliche Rahmenbedingungen Die rechtliche Akzeptanz der Anwendungen, die mit der Karte ausgeführt werden, müssen überprüft werden. Kann ich mit der Karte eine rechtlich konforme Signatur nach dem deutschen Signaturgesetz(siehe in [SigV]) erstellen? Das Gesetz macht seine Anwendung sehr aufwändig. Der Lösungsweg hier ist das Angebot einer fortgeschrittenen Signatur, die eine sichere Signatur ist, die aber gesetzlich nicht anerkannt ist, trotzdem in Rahmen der Universität benutzt und anerkannt werden kann. Für alle anderen Anwendungen gibt es keine rechtliche Verordnung. Theoretisch ist viel möglich, aber nur wichtig, wenn die Realisierungsmöglichkeit dargeboten ist. Um dies herauszufinden, müssen die technischen Anforderungen der Karte möglichst genau spezifiziert werden. 5.2 Technische Anforderungen Die technischen Anforderungen sind abhängig von den Anwendungen, die mit der Karte vorgesehen sind. Es wird davon ausgegangen, dass die Karte sowohl für kryptographische Zwecke, als auch für Bezahlfunktionen sowie Zutrittskontrollen benutzt wird. Unter diesen Vorraussetzungen sind folgende technische Anforderungen nötig: Hybrid-Karte Die Karte muss hybrid sein, das heißt sie enthält 2 Chips. Ein kontaktbehafteter Chip mit Krypto-Coprozessor und ein kontaktloser Chip. Der kontaktbehaftete Chip ist für die kryptographischen Berechnungen zuständig und der kontaktlose Chip für die Bezahlfunktion und Gebäudezugang zuständig. Die Bezahlfunktion und der Gebäudezugang müssen von den kryptographischen Funktionen getrennt sein. Tatsächlich erfordert das Bezahlungssystem genau so wie die PKI die Speicherung einer Nummer, unter welcher die Karte registriert ist. Die zwei Nummern dürfen nicht gleich sein, sonst können Rückschlüsse auf die Person getroffen werden. Diese Nummern sind dann gleich, wenn sie den gleichen Chip repräsentieren: das ist der Fall bei Dual-Access Karten, die nur einen Chip für alle Funktionen enthalten: Bei Dual-Access Karten ist der kryptographische Bereich der Karte von dem kontaktlosen Interface erreichbar. Der kontaktbehaftete Chip soll mindestens 32 KByte Speicherplatz haben. Außer der private Schlüssel, der die Karte nie verlassen darf, werden auch Zertifikate in der Karte gespeichert. Mehrere Zertifikate können gebraucht werden, weil verschiedene Anwendungen unterschiedliche Anforderungen (Zum Beispiel: Sicherheitsniveau, Schlüssel-Backup) erfordern. Der Einsatz eines kontaktlosen Chips für

49 5.2. Technische Anforderungen 43 die Bezahlfunktion und Zugangsgebäude ist notwendig, weil der Chip vor allem in der Mensa schnell schmutzig wird und dadurch Fehler bei den Kartenlesern verursacht. Außerdem ist der praktische Einsatz dadurch in der Geschwindigkeit und Einfachheit des Vorgangs erheblich gebessert. Das Mifare-Chip ist ein Beispiel eines kontaktlosen Chip. Der Mifare-Chip wird an der TU-Darmstadt eingesetzt. Kartenleser für kontaktlose Chips sind technisch kompliziert gebaut und müssen in Verbindung mit Geräten wie Kassen-Terminal, Drucker oder Zugangstür eingebaut werden (siehe Seite der Universität Gießen [UnGi1]). Aus diesen Gründen sind diese Geräte teuer im Vergleich zu Leser für kontaktbehaftete Chips. Die hohen Preise machen persönliche Anwendungen an eigenen Rechner schwierig, wobei der notwendige Krypto-Coprozessor für nützliche Anwendungen am Rechner in der Hybrid-Karte nur in dem kontaktbehafteten Chip eingebaut ist. Der Standard Mifare-Chip kann wegen unabhängiger Speicherbereiche für verschiedene Anwendungen eingesetzt werden, die unabhängig und versteckt von den anderen läuft. Die anonyme Zahlung in der Mensa und die spätere Zutrittskontrolle können ohne Rückschlüsse auf die Karte erfolgen, obwohl die zwei Anwendungen mit dem gleichen Chip laufen. Der Mifare-Chip sollte ohne PIN eingesetzt werden, weil der Vorgang der Bezahlung und der des Zutrittskontrolls schnell und umstandfrei erfolgen soll. Anwendungen Mindestens alle vorgesehenen Anwendungen müssen mit der Karte realisierbar sein. (Die Anwendungen sind in Kapitel 6 beschrieben). Zukünftige Anwendungen sollten mit der Karte auch realisierbar sein. Die Einführung neuer Anwendungen sollte nicht mit der Einführung neuer Chipkarte gekoppelt sein, sondern die aktuellen Karten müssen eine Kompatibilität zu den zukünftigen Anwendungen haben. Es sollte also im schlimmsten Fall ein Betriebssystem-Update nötig sein um die Karte weiter zu benutzen. Kompatible Clients Anwendungen der Firma Microsoft aufgrund ihres Marktanteils müssen mit der Karte funktionieren. Außerdem abhängig von den Betriebssystemherstellern, die den größten Anbieter von Rechnerräumen (meisten das Hochschulrechenzentrum (HRZ)) benutzt, wird festgestellt, welche Kompatibilität erfüllt werden müssen. Vorbeschlüsselung Die Karte muss vorbeschlüsselt sein. Die Vorbeschlüsselung erspart eine aufwändige Arbeit für die Verantwortlichen der Universität. Wenn die Karte nicht vorbeschlüsselt ist, muss sie an der Universität personalisiert werden. Das heißt auf Karten müssen Schlüssel geschrieben werden. Dieser Vorgang ist aus verschiedenen Gründen problematisch: Die Druckmaschine für Karte ist teuer. Sie kann um die 100 Karten pro Tag drucken. Fehlerquote mitberechnet, würde diese Initiative drei bis vier Wochen in Anspruch nehmen.

50 44 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs 5.3 Sicherheitsanforderungen Es ist nicht ausreichend, dass alle geplanten Anwendungen funktionieren, da die einen Netzverkehr erfordern. Netzverkehr ist mit Unsicherheit gekoppelt, also muss hier Garantie über den sicheren Netzbetrieb gegeben werden. Sichere Erzeugung und Aufbewahrung von Daten auf der Karte Benutzung von sicherer Software für die Registrierung der in der Karte enthaltenen Zertifikate. Eine PIN-Anfrage bei jeder Benutzung der Karte muss erfolgen. Karte darf auf der physische Ebene nicht angreifbar sein: das heißt Angriffe wie Side Channel Attacke dürfen nicht möglich sein. Diese Eigenschaften sind schon Teile der Eigenschaften einer Chipkarte. Die Sicherheitsanforderungen, die aber anwendungsspezifisch sind, müssen hier noch erläutert werden. Schlüssel Generierung und Größe des RSA Schlüssels Die Größe des RSA Schlüssels auf der Karte darf nicht kleiner als 1024 Bit sein. Diese Angaben beruhen auf heutigen Sicherheitsstatus von RSA. Die Länge des Schlüssels muss in einer anderen Zeit mit anderen Sicherheitsstatis nach oben korrigiert werden. Die Schlüsselgenerierung auf der Karte muss in einer evaluierten Umgebung erfolgen. Die Evaluation wird nach dem Common Criteria (CC) und Information Technology Security Evaluation Criteria (ITSEC) gemacht. Erst-PIN Verfahren Erst-PIN Verfahren sind Verfahren, die Möglichkeit geben, die erste Benutzung der Karte zu erkennen. Nach der ersten Benutzung der Karte muss erkennbar sein, dass die Karte schon einmal benutzt worden ist. Die Firma TELESEC der Deutschen Telekom hat ein solches Verfahren in ihren Karten. Das Erst- PIN Verfahren der TELESEC wird das Null-PIN Verfahren genannt. Warum dieses Verfahren wichtig ist, wird in dem folgenden Szenario geschildert: Nach einer Einschreibung bekommt ein Student seine Karte. Vor der Ausgabe an den Student wurde die Karte von einem Angreifer unbemerkt benutzt. Der Angreifer hat mit der Karte Dokumente signiert: dies war möglich, weil die Karte vorbeschlüsselt ist. Es ist unwahrscheinlich, dass Nachrichten vor der Ausgabe mit der Karte entschlüsselt worden sind, da die öffentlichen Schlüssel noch nicht veröffentlicht sind. Der Angreifer sendet die signierten Dokumente nicht, sondern er wartet auf die Veröffentlichung des Zertifikates (also wenn das Zertifikat gültig ist). Der Empfänger einer so signierten Nachricht empfängt die Nachricht und verifiziert die Signatur mit dem öffentlichen Schlüssel. Die Konsequenz einer solcher Tat für eine an der Universität geltende Signatur kann für den Betroffenen katastrophal werden. Eine Alternative zu Erst-PIN Verfahren ist das Senden von PIN-Briefen wie bei Bankkarten. Diese Alternative bringt aber viele Nachteile mit sich: Verwaltung: Die PIN-Briefe müssen gesendet werden: das heißt es wird eine Zuordnung, Kartennummer zu PIN-Briefe und eine Zuordnung Kartennummer oder PIN-Briefe zu Studenten gebraucht. Diese Zuordnungen

51 5.3. Sicherheitsanforderungen 45 müssen für ungefähr Studenten verwaltet werden. Die PIN-Briefe bestehen aus Papier und müssen mit Briefmarken frankiert werden. Das sind zusätzliche Kosten. Außerdem dürfen die PINs nicht gespeichert werden. Wenn der PIN-Brief aus einem bestimmten Grund nicht empfangen worden ist oder verloren wurde, muss eine neue Karte ausgestellt werden: Dies kann bei Karten für die Hochschule (oder den Student) teuer werden. Auch Fehler bei der Verwaltung sind zu erwarten: Ein Student bekommt eine PIN, die nicht für seine Karte erzeugt wurde. Benutzerunfreundlichkeit: Die Benutzung von PIN-Briefen motiviert nicht den Einsatz von Chipkarten. Es ist gewöhnlich, dass Studenten mit Briefe von der Universität nichts anfangen, oder der Brief einfach zu Hause irgendwo ablegen. Sicherheitsproblem: Die Sicherheit ist hier problematisch, schon weil ein Angreifer die PIN ohne große Schwierigkeit haben kann. Briefkasten vor allem im Studentenwohnheim können unbemerkbar geleert werden: Das zusätzliche Senden per Post der Karte ist bei der Überlegung eines solchen Verfahrens einzuführen, zu vermeiden. Wurde eine Karte schon benutzt, kann das nicht erkannt werden, da der PIN vor der ersten Benutzung nicht geändert werden musste. Sichere Datenübertragung Die Datenübertragung von Rechner zur Karte und von der Karte zum Rechner muss gesichert sein. Die angewandten Authentisierungsverfahren müssen nicht nur in der Zeit der Einführung, sondern auch für eine lange Zeit für sicher gehalten werden können. Abwehrmaßnahmen Die in Kapitel 4 genannten Angriffe müssen möglichst abgewehrt sein, um die nötigen Schutzziele nicht zu gefährden. Besonders muss die Datenübertragung zwischen Client und Karte geschützt sein.

52 46 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs 5.4 Wahlkriterien von Kartentypen Um eine große Anzahl von Karten zu kaufen ist eine Ausschreibung notwendig. Diese Ausschreibung wird natürlich abhängig von den oben genannten Anforderungen sein. Die technischen Anforderungen müssen aber ergänzt werden durch technische Details, die dabei helfen sollen, das Beste für den günstigsten Preis zu bekommen (Dies ist aber nicht die Aufgabe dieser Arbeit). Gebraucht wird ein Hierarchiemodell, das bei der Entscheidung die größte Rolle spielen muss. Nachdem der Vorgang zu Erstellung technische Wahlkriterien an der TU-Darmstadt viel Zeit gekostet hat, sind am Ende drei wichtige Punkte aufgefallen: Technik muss den Anforderungen angepasst werden und nicht umgekehrt. Wenn der Fehler gemacht wird, sich an die Begrenzung der gebotenen Karten zu halten, wird man nicht das möglichst beste Produkt kaufen. Hierarchiemodell zu Entscheidung ist nötig, so dass es klar sein muss, welche Kriterien Vorrang haben oder nicht. Dies ist vor allem wichtig, weil die verschiedenen Anbieter unterschiedliche Nachteile und Vorteile haben. Die für die Erstellung technischer Wahlkriterien vorgesehenen Personen, sollen rein technisch denken und nicht technische Entscheidungskriterien weglassen. Die folgenden Kriterien sind unter der Vorrausetzungen der technischen Anforderungen erstellt und klassifiziert worden. PKCS#15 Kompatibilität Die PKCS#15 Struktur ist plattform-, hersteller- und anwendungsneutral. Dies eröffnet viele Möglichkeiten für die Benutzung Open Source Projekten. Die Open Source Gruppe OpenSC [OpenSC] beschäftigt sich viel mit diesem Thema und haben schon eine funktionierende Software veröffentlicht. Die auf dem Markt angebotenen Software, sind meistens für Studenten zu teuer. Es ist also von großem Interesse Karten zu haben, die mit Open Source Software benutzbar sind: Eine Einführung von Chipkarten ohne die Möglichkeit verschiedene Anbieter (vor allem Open Source Gruppe) benutzen zu können ist sehr beschränkt. Java Schnittstelle Die Möglichkeit, die Karte selbst weiter zu entwickeln sollte durch eine Java Schnittstelle geboten sein. Dies macht nicht nur weitere Forschungen an der Hochschule möglich, sondern ist auch für den neugierigen Student interessant. Schlüsselgenerierung und Größe des RSA-Schlüssels Heutzutage sind 1024 Bits Schlüssel noch sicher. Die Welt der Kryptographie entwickelt sich aber so schnell, dass schon in ein paar Jahren die 1024 Bits Schlüssel nicht mehr sicher sein können. Es ist also von Vorteil, wenn die Karte größere Schlüssellänge unterstützt. Die nächste Größe wäre 2048 Bits.

53 5.5. Getestete Kartenmodelle 47 Speicherplatz In der Karte muss genug Speicherplatz gegeben sein, um mindestens drei verschiedenen Zertifikate speichern zu können. Dies ist mit 32 KByte schon erreicht. Aber uneingeschränkter wäre ein größerer Speicherplatz. Gebotene Anwendungen Mit der Karte müssen mindestens alle an einer Universität vorgesehenen PKIbasierte Anwendungen realisierbar sein. Wenn die Karte aber mit sich ungeplante Anwendungen bringt, ist es ein Vorteil. Kompatible Clients Zusätzlich zu den vorgesehenen Clients ist die Unterstützung anderer Clients keine Kleinigkeit, da immer mehr Studenten und Fachbereiche unterschiedliche Betriebssysteme unterstützen. Smartcard Readers Es ist wichtig, dass zusätzlich zu den von Hersteller gebotenen Kartenlesern, Kartenleser anderer Hersteller die Karte auch lesen können. Es gibt Hersteller, deren Karteleser zu teuer für Studenten sind: müssten die Studenten keinen günstigeren Kartenleser kaufen können, würden die Anwendungen von Chipkarten auf Hochschulrechenzentrum Rechner oder andere Rechner der Universität beschränkt sein. Allgemein Extras von den beworbenen Firmen können ein Entscheidungsfaktor sein. Extras können in allen genannten Kriterien auftreten. 5.5 Getestete Kartenmodelle Die Karten, die hier genannt werden, sind überwiegend für diese Arbeit unter Windows Systemen getestet worden. Eine guten Überblick Tests unter Linux kann in der Arbeit von Dirk grosse Osterhues [DG] gelesen werden. Die Ergebnisse dieser Arbeit werden hier miterwähnt. Außer der Karte wurden folgende Mittel benutzt: Kartenleser: Kobil Kaan Professional Chipkartenleser der Firma Kobil und E-gate Connector Chipkartenleser der Firma Schlumberger. Software: Proprietäre Software der jeweiligen Firmen außer für die Gemplus Karten, für die nur Open Source Projekte eingesetzt worden sind. Zwei Open Source Projekte wurden benutzt: OpenSC, das eine Bibliothek für Chipkarten anbietet, die PKCS#15 unterstützen, und CSP11 ein Crypto Service Provider, das eine Schnittstelle zu Windows Applikationen für mit OpenSC initialisierte Chipkarten anbietet. Betriebssystem Windows XP

54 48 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs TCOS 2.0 Das Betriebsystem TCOS (TeleSec Chipcard Operating System) wurde von der deutschen Telekom entwickelt. TCOS garantiert ein Höchstmaß an Sicherheit. Die Verwaltung der Daten erfolgt mit einem File-System. Zugriffskontrollen unter anderem werden mit Hilfe verschiedener kryptographischen Sicherheitsmechanismen erreicht. Allgemeiner Zugriff auf die Daten der Karte oder während der Übertragung zu den Clients ist durch Überprüfung der Identität und Authentizität des Nutzers mit PIN-Eingabe und mit Authentisierungsverfahren (MAC 1 ) geschützt. Die Initialisierung der Karte erfolgt in einer gesicherte Umgebung innerhalb des Trust Centers der Deutschen Telekom: eine kundenspezifische Vorpersonalisierung (Vorbeschlüsselung) ist möglich. Das Dokument [TeKom] liefert mehr Details über TCOS Karten. Mifare-Chip: In der Karte kann ein Mifare-Chip integriert werden. PKCS#15 Kompatibilität: Es gibt keine PKCS#15 Struktur auf der Karte. Die von der Firma TELESEC angebotenen Karten TCOS haben eine eigene Struktur, sind nicht PKCS#15 kompatibel und könnten mit den benutzten Open Source Projekten nicht funktionieren, weil diese eine PK- CS#15 Struktur voraussetzen. Java Schnittstelle: Die Karte besitzt eine Java Schnittstelle. Die Projekte OCF (Open Card Framework) und JPCSC (Java über PCSC) können hier eingesetzt werden. Schlüsselgenerierung und Größe des Schlüssels: TCOS 2.0 arbeitet mit RSA Schlüssel 512 und 1024 Bits. Der Nachfolger von TCOS 2.0 genannt TCOS 3.0 wird angeblich RSA 2048 unterstützen und Elliptic Curve Cryptography ECC. Die Karte selbst und die Schlüsselerzeugung auf der Karte ist nach CC und ITSEC evaluiert. Erst-PIN Verfahren: Ein Erst-PIN ähnliches Verfahren ist vorhanden. Dieses Verfahren ist eine Proprietät der Firma TELESEC und heißt Null-PIN Verfahren. Bei dem Null-PIN Verfahren sind alle Karten vor ihrer Benutzung nur mit einer PIN aus Nullen ansprechbar. Diese PIN muss geändert werden, um mit der Karte weiter arbeiten zu können. Der Trick ist, dass die PIN nie mehr aus Nullen bestehen kann. Das heißt wenn bei der ersten Benutzung die PIN aus Nullen nicht angenommen wird, wurde die Karte schon benutzt. Speicherplatz: TCOS 2.0 hat 32 KByte Speicherplatz. Abwehrmaßnahmen: Abwehrmaßnahmen gegen bekannteste Angriffe: Bellcore-, SPA-, DPA- und Timing-Angriffe. Kompatible Clients: Alle vorgesehenen Anwendungen funktionieren unter Windows und Linux Systemen mit dem kommerziellen Software Kobil Smart Key. Die Software kann angeblich mehr; dies wurde aber nicht getestet. Die Anwendungen funktionieren nicht mit Open Source Projekten OpenSC und CSP11, weil die genannten Projekte auf PKCS#15 Struktur aufbauen. 1 siehe Kapitel 3

55 5.5. Getestete Kartenmodelle 49 Smartcard Readers: Zwei verschiedene Readers wurden eingesetzt. Ein Reader der Firma Kobil genannt Kobil Kaan Professional und ein Reader der Firma Schlumberger genannt E-gate Connector Reader. Nur der erste Reader hat erfolgreich die Karte lesen können. Allerdings liegt es daran, dass die E-gate Connector Reader nur Karten der Firma Schlumberger lesen können. Allgemein: Die externen und internen Schreibzugriffe sind abgesichert: ein begonnener Schreibvorgang wird nach einem Ausfall der Spannungsversorgung korrekt beendet. Übertragungsgeschwindigkeit TCOS 2.0 benutzt das Protokoll T = 1 nach ISO Starcos SPK 2.3 Das Betriebsystem Smart Card Chip Operating System (Starcos) Standard Version with Public Key Extension 2.3 ist eine Karte, die eine Multifunktionalität anbietet. Mifare-Chip: In der Karte kann von dem Hersteller ein Mifare-Chip integriert werden. PKCS#15 Kompatibilität: Die Karte ist PKCS#15 kompatibel. Java Schnittstelle: Der Hersteller ist Mitglied des Konsortiums OPEN CARD und somit besitzt die Karte eine Java Schnittstelle. Schlüsselgenerierung und Größe: Starcos 2.3 unterstützt RSA Schlüssel der Größe 1024 Bits. Die Schlüsselgenerierung erfolgt in einer hoch sicheren Umgebung, die nach CC und ITSEC Standards evaluiert ist. Erst-PIN Verfahren: Ein Erst-PIN ähnliches Verfahren ist vorhanden. Dieser heißt Transport-PIN. Bevor die Karte überhaupt benutzt werden kann, muss der Transport-PIN geändert werden, was das Wissen des Codes voraussetzt. Der Transport-PIN kann geschickt werden, aber aus Kostengründen, Aufwandsproblemen und Fehlervermeidung kann er durch triviale oder persönliche Angaben ersetzt werden. Speicherplatz: Der Speicherplatz auf der Karte beträgt 32 KByte. Abwehrmaßnahmen: Abwehrmaßnahmen gegen bekannteste Attacken: Bellcore-, SPA-, DPA- und Timing-Attacken. Kompatible Clients: Mit SafeSign, die Herstellersoftware, sind alle vorgesehenen Anwendungen unter Windows ausführbar. Außerdem konnten die Anwendungen aufgrund der PKCS#15 Struktur auch mit Open Source Projekten OpenSC und CSP11 ausgeführt werden. Das ist ein großer Vorteil, weil OpenSC Unix-basierte und MAC Betriebssysteme der Firma Apple unterstützt. Unix-basierte und MAC Betriebssysteme werden immer mehr eingesetzt. Ihre Unterstützung ist vor allem für die Zukunft von Vorteil. Smartcard Readers: Der Reader Kobil Kaan Professional konnte die Karte problemlos lesen, aber der E-gate Connector Reader wie schon erwähnt funktioniert nur mit Karten der Firma Schlumberger.

56 50 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs Allgemein: Es gibt eine ganze Reihe zusätzliches Einsatzgebiete der Karte, die zwar für eine Hochschule nicht sehr relevant sind, aber allgemein ein Vorteil für private Nutzung darstellt (siehe [Starcos]) Gemplus GPK 16k Mifare-Chip: In der Karte kann ein Mifare-Chip integriert werden. PKCS#15 Kompatibilität: Die Karte ist PKCS#15 kompatibel. Java Schnittstelle: Die Gemplus Karten haben eine Java Schnittstelle. Die Schnittstellen sind über den Open Card Framework (OCF) benutzbar. Schlüsselgenerierung und Größe: Die Karten arbeiten mit RSA Schlüssel der Länge 1024 Bits. Die Schlüsselgenerierung erfolgt in einer hoch sicheren Umgebung, die nach den Standards CC und ITSEC evaluiert ist. Erst-PIN Verfahren: Die Gemplus Karten haben ein Erst-PIN ähnliches Verfahren genannt Transport Secret Code. Bevor die Karte überhaupt benutzt werden kann, muss der Transport Secret Code (TSC) geändert werden, was das Wissen des Codes voraussetzt. Der TSC kann geschickt werden, aber aus Kostengründen, Aufwandsproblemen und Fehlervermeidung wird er wie an der Universität Freiburg [UnFre] durch das Geburtsdatum oder ähnliches ersetzt. Speicherplatz: Der Speicherplatz ist ein Nachteil der Gemplus Karten. Er beträgt nur 16 KByte. Der Betrag könnte zwar für die vorgesehenen Anwendungen ausreichend sein, ist aber für eine erweiterte Nutzung zu sehr beschränkt. Abwehrmaßnahmen: Abwehrmaßnahmen gegen bekannteste Attacken: Bellcore-, SPA-, DPA- und Timing-Attacken. Kompatible Clients: Alle vorgesehenen Anwendungen konnten mit den Open Source Projekten getestet werden. Smartcard Readers: Kobil Kaan Professional Reader konnte die Karte erfolgreich lesen. Allgemein: Mehr Informationen über die Gemplus Karten können in [Gplus] gewonnen werden Cyberflex Access E-gate 32k Mifare-Chip: In der Karte kann ein Mifare-Chip integriert werden. PKCS#15 Kompatibilität: Diese Karte ist nicht PKCS#15 kompatibel: Sie hat keine File System Struktur. Die PKCS#15 Struktur kann aber auf der Karte simuliert werden mit Hilfe eines Java Applets. Java Schnittstelle: Als Java Karte hat sie selbstverständlich eine Java Schnittstelle.

57 5.5. Getestete Kartenmodelle 51 Schlüsselgenerierung und Größe: Die Karten arbeiten mit RSA Schlüssel der Länge 1024 Bits. Die Schlüsselgenerierung erfolgt in einer hoch sicheren Umgebung, die nach den Standards CC und ITSEC evaluiert ist. Erst-PIN Verfahren: Die Cyberflex Karten haben kein Erst-PIN ähnliches Verfahren, sondern die maximale Anzahl von PIN-Versuchen kann begrenzt werden. Speicherplatz: Die Größe des Speichers beträgt 32 KByte. Kompatible Clients: Alle vorgesehenen Anwendungen konnten mit der Proprietären Software funktionieren. Die Open Source Software für Cyberflex Karten, die von der Seite der Muscle Projekt Seite [Muscle] heruntergeladen wurden, konnten nicht erfolgreich getestet werden. Smartcard Readers: Die zwei benutzten Kartenleser konnten die Karten erfolgreich lesen. Allgemein: Die Karte präsentiert interessante Extras wie die Benutzung von biometrischen Merkmalen für die Authentisierung. Eine genauere Übersicht der Spezifikationen der Karte ist in [Cyber] präsentiert Cryptoflex 32k Mifare-Chip: In der Karte kann ein Mifare-Chip integriert werden. PKCS#15 Kompatibilität: Diese Karte ist PKCS#15 kompatibel. Java Schnittstelle: Die Karte hat eine Java Schnittstelle. Schlüsselgenerierung und Größe: Der große Vorteil der Cryptoflex Karten ist die Unterstützung von RSA Schlüsseln der Länge 2048 Bits. Erst-PIN Verfahren: Die Karte enthält kein Erst-PIN ähnliches Verfahren. Dies ist ein großer Nachteil, weil das Senden von PIN-Briefen wie bei Bankkarten aufwändig, umständlich und fehleranfällig ist. Speicherplatz: Der Speicherplatz beträgt 32 KByte. Kompatible Clients: Alle vorgesehenen Anwendungen konnten mit der Proprietären Software und die Open Source Software OpenSC und CSP11 funktionieren. Smartcard Readers: Kobil Kaan Professional Reader und E-gate Connector Reader konnten die Karte erfolgreich lesen. Allgemein Die Seite [Crypto] bietet eine genauere Übersicht der Karte an Tabellenübersicht Die Tabelle 5.1 ist eine Zusammenfassung der getesteten Karten (Unter Benutzung der im Abschnitt 5.5 genannten Software) und ihre Eigenschaften.

58 52 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs Modell TCOS 2.0 Starcos 2.3 Gemplus 16k Cyberflex 32K Cryptoflex 32k Mifare-Chip Ja Ja Ja Ja Ja Erst-PIN Verfahren Ja Ja Nein Nein Nein PKCS#15 Nein Ja Ja Nein Ja Java Ja Ja Ja Ja Ja Schnittstelle Windows Ja Ja Ja Ja Ja Linux Ja Ja Ja Ja Ja Andere Betriebssystemen Open Source Schlüssel Größe (Bits) Nein Ja Ja Ja Ja Nein Ja Ja Ja Ja Tabelle 5.1: Tabelleübersicht

59 5.6. Ablauf zur Ausstellung von Digitalen IDs Ablauf zur Ausstellung von Digitalen IDs Dieser Abschnitt enthält einen Vorschlag über den Ablauf zur Ausstellung von Digitalen IDs an einer Hochschule. Der Ablauf ist deswegen wichtig, weil Sicherheit und minimaler Aufwand dadurch gebessert oder verschlechtert werden können. Es ist nicht nur wichtig, dass die Anwendungen mit den Digitalen IDs während der Benutzung erfolgreich und sicher funktionieren, sondern auch muss die Ausstellung und die Revokation der Digitalen IDs so wie die Initialisierung der Karten sicher erfolgen. Für den Fall, dass ein automatisierter, dezentralisierter Prozess mit wenig Personal Anforderung gebraucht wird, eignet sich der Ablauf an der TU-Darmstadt. Der Ablauf an der TU-Darmstadt ändert nicht die existierenden Registrierungsprozesse der Universität und ist deswegen einfach integrierbar. Er erfolgt in mehreren Schritten mit verschiedenen Statis, die den Zustand der Zertifizierung oder Revokation angeben. Als Anhang ist eine Tabelle, die die Übersicht über diese Statis angibt Registrierung und Erzeugung Kartenausgabe Jeder Student bekommt nach seiner Immatrikulation eine prepersonalisierte (vorbeschlüsselte) Chipkarte, ein Username und ein Passwort (für das LDAP Verzeichnis). Die Karte enthält bereits nach ihrer Erzeugung einen oder mehrere private Schlüssel. Die Benutzung der Karte ist durch ein Erst-PIN ähnliches Verfahren geschützt. Die zu den privaten Schlüsseln gehörigen öffentlichen Schlüssel werden zusammen mit der jeweiligen Kartenseriennummer schon vor der Ausgabe der Karte in einer Datenbank abgelegt. Diese Zuordnung wurde bei der Herstellung der Karte gemacht und wird von dem Hersteller an die Hochschule geschickt. Dazu kommt die Matrikelnummer des Studenten nach seiner Immatrikulation. Die Einschreibungsstelle schickt unter anderem das Tripel (Name, TUD Matrikelnummer, Chipkartennummer) von dem Student an das Hochschulrechenzentrum HRZ. Das HRZ bekommt das Tripel und erzeugt einen Userkonto in dem LDAP Verzeichnis der PKI. Der LDAP Eintrag des Studenten enthält folgendes: - Common Name (CN): Name des Studenten - Chipkartennummer - Matrikelnummer und Benutzer-Passwort Die RA verwaltet Statusinformationen über den Ablauf vom Antrag zu Erteilung von Zertifikaten bis zur Revokation. Im LDAP werden jedem Userkonto ein Statusfeld zugeordnet, das am Anfang auf 0 gesetzt ist. Online Registrierung Nach einer erfolgreichen Anmeldung an einem mit dem Hochschul-Netz verbundenen Rechner (Angabe eines Usernames und Passwort, welche meistens in den Immatrikulationsunterlagen zu finden sind), kann der Student sein Onlinekonto aktivieren. Der Student wird auf seiner Kontoseite aufgefordert, seine -Adresse zu setzen. Die Weboberfläche, die die Kontoseiten der Studenten verwaltet, ist ein Servlet. Der Servlet ist mit der PKI verbunden. Der Servlet

60 54 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs schreibt die aadresse in LDAP. Der Servlet setzt das Statusfeld in LD- AP auf 1. Die Registrierung durch die RA der PKI ist dann erfolgreich nur, wenn der Student kein Zertifikat besitzt: dies klappt, weil die RA einen Registrierungsdämon (Komponente, die ständig im Hintergrund läuft) enthält, der ständig in dem LDAP nach Einträge mit notwendigem Status, nämlich 1, sucht. Sobald der Registrierungsdämon einen solchen Eintrag findet, werden: LDAP Distinguished Name (DN): Adresse: Matrikelnummer: Kartennummer: des Studenten aus dem LDAP gelesen. Das Bild 5.1 ausgenommen aus [VLW] stellt ein LDAP Eintrag dar. Abbildung 5.1: Ein LDAP Eintrag Weil in dem LDAP die Verknüpfung, Kartennummer mit Public-Key schon besteht, kann die RA nach dem Empfang von Namen und Kartennummer die Verknüpfung, Name mit Schlüssel machen. Der Registrierungsdämon setzt den Status auf 2, damit er den gleichen Antrag nicht mehrmals bearbeitet. Bei der Weiterverarbeitung der Daten wird die RA steuern, welche Daten in ein Zertifikat einfließen, welche gespeichert und welche nur für die Zeit der Antragsverarbeitung im System bleiben. Es wird zum Beispiel auf die Matrikelnummer mit

61 5.6. Ablauf zur Ausstellung von Digitalen IDs 55 Hilfe von Access Control List (ACL) Lesezugriffsrecht verweigert, da die Anonymität gewährleistet werden muss. Außerdem lassen sich weitere Attribute, die für verschiedene Anwendungen erforderlich sind (zum Beispiel Firewall-Zugang und VPN, sichere Kommunikation mit IPSec und SSL), in das Zertifikat integrieren. Die Verknüpfung zu einem öffentlichen Schlüssel wird in den Zertifikaten bescheinigt. Die RA erzeugt ein to be signed(tbs) Zertifikat und signiert es. Dieses signierte TBS Zertifikat wird an die CA der PKI weitergeschickt. Die CA erzeugt das Zertifikat konform zum Standard X.509 [X509] und signiert das Zertifikat Publizierung Das Zertifikat wird nach seiner Erzeugung in LDAP veröffentlicht und archiviert. Publiziert werden dann folgende Einträge: - Das Zertifikat (usercertificate) - Gültigkeitsintervall: (ValidityNotBefore) und (ValidityNotAfter) Der Status der Registrierung wird auf 3 gesetzt Zertifikat auf Karte schreiben Bevor der Student sein Zertifikat auf seine Karte schreiben kann, muss er seine Karte freischalten (Erst-PIN Verfahren, siehe Abschnitt 5.3). In einem mit Chipkartenleser ausgestatteten Poolraum (nur in so einem Raum oder bei eigenem PC mit Chipkartenleser kann der Student seine Karte benutzen) steckt er seine Karte ein und kann mit Hilfe eines Zugriffsprogramms seine PIN-Nummer ändern. Nachdem der Student sichergestellt hat, dass er im Besitz eine vorher noch nicht benutzten Karte ist, kann er jetzt sein Zertifikat mit Hilfe der angebotenen Software auf seine Karte schreiben. Um den Prozess des Schreibens zu starten muss er sich auf seine Kontoseite mit Username und Passwort anmelden und das UpdateClient 2 ausführen. Das Update Client überprüft den Status des Studenteneintrags auf 3 im LDAP und schreibt das Zertifikat auf die Karte bei einer erfolgreichen Überprüfung Revokation Der Student oder der Administrator können das Zertifikat revozieren. Gründe für die Revokation sind: Exmatrikulation, Kartenverlust etc. Die Revokation erfolgt in drei Schritten: Antragsstellung: Die Revokation wird von dem Student auf seine Kontoseite oder von dem Administrator beantragt. Der Servlet ändert den Studenteneintrag in LDAP und setzt den Status auf 5. Bearbeitung : Die LDAP-Einträge werden im regelmäßigen Intervall von dem Revokationsdämon der CA auf Revokationsstatus (Status 5) geprüft. Wird ein Eintrag mit dem Status 5 gefunden, wird er von der RA an die 2 Programm womit Zertifikate auf die Karte geschrieben werden. Es ist ein von der TU- Darmstadt entwickeltes Programm

62 56 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs CA zur Bearbeitung geschickt. Die RA setzt den Status des Eintrags auf 6. Ausführen: Die CA revoziert das Zertifikat. Dieses wird in LDAP gelöscht. Das gesperrte Zertifikat wird in die CRL eingetragen und die Liste wird veröffentlicht. Diese Liste wird in regelmäßigen Abständen aktualisiert oder immer dann, wenn ein Antrag auf Revokation erfolgreich ausgeführt worden ist. Es kann passieren, dass Benutzern von der Revokation eines Studenten nichts mitbekommen. Sie könnten dann zum Beispiel signierte Mails bekommen und öffnen, die aber eine ungültige Signatur enthalten. Der Student muss soweit nicht in seinem Browser oder -Programm einstellbar, die CRL vor der Öffnung signierte und verschlüsselte Mails aktualisieren Verlängerung Die Zertifikate sind innerhalb 2 Jahren gültig, wenn sie vor der Gültigkeitsfrist nicht revoziert worden sind. Nach dem Fristablauf wird das Zertifikat vom System automatisch revoziert. Wenn der Benutzer sein Zertifikat verlängern möchte, so kann er dies beantragen. Ein Zertifikat kann nur dann verlängert werden wenn das Statusfeld des Studenteneintrags auf 5 gesetzt ist. Antragsstellung bei der RA mit Hilfe des Servlets: Der Status wird auf 7 gesetzt. Bearbeitung: Der Antrag von dem Registrierungsdämon gefunden. Die vorherigen Schritte ab wiederholen sich bis zur Erzeugung. Das Bild stellt eine Zusammenfassung des Ablaufs dar.

63 5.6. Ablauf zur Ausstellung von Digitalen IDs 57 Status Aktion 0-1 Der Student hat seine Mail gesetzt. Der Servlet setzt den Status auf Die RA bekommt den Antrag auf Zertifikatserteilung, erzeugt einen TBS Zertifikat und setzt den Status auf Die CA erzeugt das Zertifikat und setzt den Status auf 3. Das Zertifikat wird veröffentlicht. 3-5 Die RA bekommt den Antrag auf Revokation. 5-6 Die CA revoziert das Zertifikat. 5-7 Die RA bekommt den Antrag auf Zertifikatsverlängerung. Tabelle 5.2: Übersichtstabelle des Ablaufs zur Zertifikatserteilung

64 58 5. Anforderungsanalyse für die Integration von Chipkarten als digitale IDs

65 Kapitel 6 Anwendungen In diesem Kapitel wird ein Überblick über die möglichen kryptographischen Anwendungen an einer Hochschule dargestellt Signatur und Verschlüsselung Es werden per Mailsendung in einer Hochschule verschiedene Verwaltungsprozessen erledigt. Der Austausch erfolgt zwischen Studenten, zwischen Studenten und Institut Staff, zwischen Institut Staff und Hochschulverwaltung, so wie zwischen Studenten und Hochschulverwaltung. Bei diesem Austausch, so weit nicht gesetzlich zwingend, wird meistens ohne Überprüfungsmöglichkeit angenommen, dass die Mail Quelle echt ist, dass die Mail nicht geändert worden ist, oder dass die Mail von Unerlaubten nicht gelesen worden ist. Dies kann zu administrativen Fehlern führen. Die Benutzung von digitalen Signaturen und Verschlüsselungen wird zusammengefasst durch vier Sicherheitskriterien motiviert: Authentizität: Der Mail-Empfänger möchte sicher sein, dass die empfangene Mail tatsächlich von dem Besitzer der Mail-Adresse geschickt worden ist. Wird diese Mail digital signiert, kann man sich auf die Authentizität der Nachricht verlassen, solange das Zertifikat gültig ist. Dies ist vor allem bei Dokumenten nötig, die bestimmte Aktionen hervorrufen. Datenintegrität: Die Mail-Sender und Empfänger möchten sicher sein, dass die Mail unterwegs nicht geändert worden ist. Dieses Problem wird auch durch die Benutzung von digitalen Signaturen gelöst: Signiert werden Hashwerten (siehe 3.2.5), deren Vergleich die Gewissheit über die nicht Veränderung der Daten bringen soll. Vertraulichkeit: Die Mail-Sender und Empfänger möchten sicher sein, dass die Mail von Dritten nicht gelesen worden ist. Die Verschlüsselung der Daten mit dem RSA Verfahren (Benutzung von 1024 Bits großen Schlüsseln) löst das Problem. 59

66 60 6. Anwendungen Verbindlichkeit: Der Sender der Mail sollte nicht die Möglichkeit haben, die Sendung der Mail abzustreiten. Wenn der Benutzer seine Mail mit seinem privaten Schlüssel signiert, welcher er normalerweise als einziger Mensch benutzen kann, kann er später die Sendung der Mail nicht abstreiten. Außerdem sind die Signaturen fälschungssicher (kopierbar). In dieser Hinsicht sind sie sicherer als schriftliche Unterschriften, die gewöhnlich leicht nachmachbar sind. Um seine Mail zu signieren oder zu verschlüsseln, wählt der Benutzer das zu benutzende Zertifikat und wählt in seinem Mail Editor die Option Mail signieren. Die Zertifikate werden nur erkannt, wenn die PKCS#11 Schnittstelle für die Karte geladen ist. Im Fall von Anwendungen der Firma Microsoft, wird zusätzlich eine Registrierung der Zertifikate benötigt. Das Bild 6.1 stellt eine Registrierung mit der Software Smart Key der Firma Kobil dar. Die Registrierung unter Windows erfolgt unter der Implementierung eines Cryptographic Service Provider, der kryptographische Algorithmen implementiert. Wird ein Zertifikat mit einer bestimmten CSP registriert wird dieses CSP immer gebraucht, wenn versucht wird auf das Zertifikat zuzugreifen. In der CSP werden die Daten verschlüsselt, entschlüsselt, signiert und verifiziert, außer bei dem Fall von Karten, weil der CSP keinen Zugriff auf den privaten Schlüssel hat. Die Benutzung der Karte ist durch eine PIN-Eingabe geschützt, deren Eingabezeit begrenzt ist. Das Bild 6.3. Bei dem Versuch eine Mail zu signieren oder zu verschlüsseln, werden die zum verschlüsselnden oder zum signierenden Daten in die Karte gesendet, dort signiert oder verschlüsselt, und zurückgesendet. Das Bild 6.2 zeigt die Aufforderung zur PIN-Eingabe bei der Signatur oder Verschlüsselung einer Mail. 6.2 Authentisierung und Autorisation Der Zugang zu administrativen Bereichen an der Hochschule Darmstadt ist durch eine Benutzerkennung/Passwort Kombination geschützt. Die Menschen müssen sich so viele Passwörter merken, dass sie sich diese meistens irgendwo aufschreiben. Außerdem wird meistens das gleiche Passwort für verschiedene Anwendungen benutzt, so dass ein Angreifer im Besitz eines Passwortes hohen Schaden einrichten kann, weil er damit Zugang zu mehreren Applikationen bekommt. Will man sich auf einer sicheren Seite authentifizieren, muss die eindeutige Identifizierung der Kommunikationspartner dabei gewährleistet sein. Das heißt, die Möglichkeit die Authentizität des Servers zu prüfen muss auch gegeben sein. Die Möglichkeit, eine fremde Identität anzunehmen, muss ausgeschlossen werden. Um sich nicht verschiedene Passwörter zu merken, weil man sich auf verschiedenen Webseiten und andere authentifizieren muss, werden digitale Identitäten benutzt. Zusätzlich wird ein Datenträger benutzt, in dem der private Schlüssel gespeichert wird. Dieser Schlüssel wird die Karte nie verlassen und die Authentifizierung mit dem Schlüssel ist sicher, weil der Schlüssel 1024 Bit groß ist. Verschiedene Anwendungen erfordern verschiedene Sicherheitsniveaus. Aus diesem Grund können verschiedene Zertifikate mit verschiedenen Sicherheitsniveaus für verschiedene Anwendungen benutzt werden. Die Anwendungen, für Authentisierung und Autorisation gebraucht werden, werden in den nächsten Abschnitten beschrieben.

67 6.2. Authentisierung und Autorisation 61 Abbildung 6.1: Registrierung der Zertifikate mit Kobil Smart Key Windows Logon Gewöhnlich wählen Benutzer einfache Passwörter für ihre Anmeldungskonten. Dies vereinfacht die Arbeit von Angreifer, die mit Hilfe einer Brute Force Attacke die Passwörter knacken können. Der Zugang zu einem Konto ermöglicht meistens die Benutzung aller Programme und Daten, die diesem Konto zugeordnet sind. Außerdem kann der Angreifer ein DOS Angriff (Denial Of Service) starten und den Zugang zu dem Konto sperren, in dem er das Passwort ändert. Die Arbeitszeit wird durch den Nichtzugriff auf den PC verloren. Diese Probleme werden durch den Einsatz einer Chipkarte gelöst. Die Chipkarte enthält eine digitale Identität. Bei der Anmeldung wird der Benutzer aufgefordert, seine Karte einzustecken. Hat der Benutzer seine Karte eingesteckt, muss er eine PIN eingeben. Die digitale Identität wird automatisch mit Hilfe eines Challenge Response von dem Rechner überprüft. Das Passwort des Benutzers ist nicht auf dem Rechner gespeichert. Um eine Brute Force Attacke zu starten, müsste der Angreifer die Karte gestohlen haben. Ein anderes Hindernis ist die begrenzte Anzahl von PIN-Versuchen. Für die Anmeldung an Unix-basierten Systemen wird auf [DG] verwiesen.

68 62 6. Anwendungen Zugang zu geschützten Webseiten per Secure Socket Layer (SSL) An der TU-Darmstadt gibt es den Bedarf den Zugang zu den verschiedenen Webseiten oder das Herunterladen von Dokumenten von Instituten und andere Einrichtungen zu schützen. Dieser Schutz wird so weit bekannt, mit Hilfe Benutzerkennung/Passwort erreicht. Die Authentisierung durch Wissen ist wie inzwischen bekannt nicht ausreichend für eine hohe Sicherheit. Die Brute Force, trojanische Pferde und andere Angriffe können problemlos und erfolgreich ausgeführt werden. Um die Sicherheit zu erhöhen werden für den Zugang, digitale Identitäten eingesetzt. Die Ansicht von Klausurergebnissen oder der Zugang zu elektronischem Lehrmaterial (Vorlesungsfolien, Vorlesungsskript oder Übungen) wird durch den Besitz einer digitalen Identität möglich. Tatsächlich ist es mit Apache Webserver möglich, nur Besitzer bestimmter Zertifikate den Zugang zu Webseiten zu gewähren. Das heißt, dass zum Beispiel nur Studenten vom Fachbereich Informatik angemeldet für eine Vorlesung als einzige den Zugang zu der Webseite der Vorlesung bekommen können. Wer Zugriff bekommt, wird in der jeweiligen Einrichtung entschieden. In der Apache Webserver Konfigurationsdatei werden Angaben über die CA, die die Zertifikate erstellt hat, gemacht. Es ist wichtig für den Server zu wissen, wo sich die CA Schlüssel und Zertifikat befinden. Zusätzlich muss das Zertifikat der CA in dem Browser des Benutzers installiert werden, sonst wird der Browser keine Möglichkeit haben, die Authentizität des eigenen Zertifikats und die der CA zu prüfen. Die Browser verfügen über die Zertifikate mit Hilfe der PKCS#11 und bei Microsoft Anwendungen zusätzlich mit Registrierung der Zertifikate. Die Benutzung von digitalen Identitäten öffnen viele Möglichkeiten. Es ist möglich alle Anwendungen, die über den Server laufen mit Besitz von digitalen Identitäten zu schützen. Eine interessante Anwendung ist die Raumbuchung im Fachbereich Informatik an der TU-Darmstadt. Mit der Anwendung können Mitarbeiter bei Vorlegen ihrer Zertifikate freie Räume des Informatikgebäudes buchen. Mitarbeiter müssen sich kein Passwort merken. Außerdem ist sicher, dass ein Raum nur von einem Mitarbeiter gebucht worden ist. Eine Überprüfung ist nicht mehr erforderlich Sichere digitale Prüfungsverwaltung Die TU-Darmstadt benutzt das HIS-GX Modul POS Module von der Firma Hochschul-Informations-System GmbH um die Prüfungen zu verwalten. Das Modul basiert auf einem Applikationserver, einem Datenbankserver und einem Webserver. Der Einsatz des Webserver macht eine Online Verwaltung möglich. Der Online-Zugang kann sowohl mit Benutzerkennung/Passwort als auch mit PIN-Tan Kombination geschützt werden. Eine Authentisierung, die nur auf das Wissen eines oder mehrere Passworte basiert, ist für die Wichtigkeit der sensitiven Daten, die damit geschützt werden, unausreichend. Im Vergleich zu Online- Banking, bei der die Banken für die Sicherheit der Daten garantieren (Zum Beispiel werden nicht selbst getätigte Überweisungen rückgängig gemacht) ist dies in der Universität viel schwieriger. Daten können geändert werden, aber die Unleugbarkeit der Änderung ist fast nicht möglich. Nicht weil das Schutzsystem gut ist, aber weil ein Benutzer der Verwaltung schwer erklären kann warum Daten, die er verwaltet, geändert worden sind. Die Mitarbeiter, die in der Zukunft Karten bekommen sollen, sind durch die Benutzung von Chipkarten

69 6.2. Authentisierung und Autorisation 63 besser geschützt. Außerdem gibt es die Möglichkeit für Studenten auch einen geschützten Zugang zu den Selbstbedienungsfunktionen des HISPOS-GX Moduls. Studenten können ihre (Vor)Diplomprüfungsnoten einsehen, sich für eine Diplomprüfung anmelden, oder ihren Leistungsspiegel ausdrucken. Es sollte in der Zukunft die Möglichkeit geben, sich nach einer Authentisierung mit seiner digitalen Identität seine Studentenbescheinigung selbst aus dem Netz auszudrucken. Die Mitteilung von Adressenänderungen sollte auch möglich sein. Diese Anwendungen sind von einem anderen Modul der Firma HIS verwaltet. Das HISSOS-GX Modul. Die Integration der Authentisierung läuft auch über den Web-Server des Softwares Landesbibliothek Die Anwendung der Chipkarte als Bibliotheksausweis ist als zukünftige Anwendung an der TU-Darmstadt eingestuft. Die Ausleihe von Büchern in den Bibliotheken ist nur durch eine Kontrolle des Studentenausweises oder durch den Besitz eines Bibliothekausweises geschützt. Ein Angreifer im Besitz des Studentenausweises (oder des Bibliotheksausweises) seines Opfers könnte Bücher ausleihen und diese nie mehr zurückgeben. Dies kann schon dramatische Konsequenzen sowohl für die Opfer als auch für die Bibliothek haben, zumal die Studenten mehrere Bücher gleichzeitig ausleihen können. Die Einführung von digitalen Identitäten in der Bibliothekverwaltung ist vor allem für die Fachbereichsbibliotheken relevant. Die zentrale Bibliothek, die mehr als die Studenten der Universität verwaltet, käme nicht in Frage aufgrund der Verwaltung zu verschiedenen Benutzern, die bis jetzt keine Gebühr für den Bibliotheksausweis bezahlen müssen. Die digitale Identität kann jedoch eingeführt werden, wenn die zentrale Bibliothek die Kosten von Chipkarten für nicht an der TU-Darmstadt studierende Benutzer übernimmt. Es werden einfach neue Zertifikate erstellt, die für die Authentisierung gegenüber einem neuen Bibliothek-Server benutzt werden. Zu erwarten wäre auch noch, dass viele Benutzer, die in der zentralen Bibliothek Bücher ausleihen, über sehr wenig Computerkenntnisse verfügen. Einfache Software und ein guter Support wird also notwendig sein Login in dem Universitätsnetz An der TU-Darmstadt wird für den kabellosen externen Zugriff auf dem TU- Netzwerk die Cisco Virtual Private Network (VPN) Lösung angewendet. Sie bietet eine fortschrittliche PKI Technologie, die mobilen Anwendern einen Remote Zugriff zu deren TU-Netzwerk ermöglicht und sensitive Daten verschlüsselt überträgt. Eine Authentisierung mit Chipkarten und digitale Identitäten kann bequem auf jedem Computer implementiert werden, auf dem ein Cisco VPN Client 3.0 über Microsoft Crypto API zur Kommunikation mit der Cisco VPN 3000 Concentrator Serie läuft. Mit den CISCO VPN Client wird eine sichere Verbindung zwischen Benutzer Rechner und Netzwerk aufgebaut. Der Cisco VPN 3000 Concentrator. Der Benutzer kann in dem auf seinem Rechner installierten VPN Client (Windows Betriebssystemen) die Art der Authentisierung wählen. Für eine zertifikatsbasierte Authentifizierung muss der Benutzer Authentisierung mit Zertifikaten wählen. Weil der Cisco Client die Crypto API von Microsoft benutzt, muss das für die Anwendung benutzte Zertifikat im Windows Betriebssystem registriert sein. Somit wird bei dem Versuch sich im Netzwerk anzumelden,

70 64 6. Anwendungen die Aufforderung zur PIN-Eingabe ausgelöst. Die Zertifikate werden von dem Cisco IOS Certificate Server verwaltet. Das Bild 6.4 stellt ein Screenshot zur Authentifizierung mit dem Kobil Smart Key dar. 6.3 Anwendungen mit dem kontaktlosen Chip Die folgenden Anwendungen sind nicht PKI basiert, aber trotzdem relevant, zumal der kontaktlose Chip (Mifare-Chip) in der gleichen Karte wie der Krypto Chip integriert ist. Auf den kontaktlosen Chip der TU-Karte werden Geldbeträge gespeichert. Mit der Karte kann man anonym in der Mensa so wie in anderen Bereichen der Universität bezahlen. Im Gegenteil zu den anderen Anwendungen kümmert sich hier das Studentenwerk über die Abrechnung. Das Studentenwerk verfügt über ein Bezahlungssystem, das mit verschiedenen Clients in den Einrichtungen der Universität vernetzt ist. In dem System erfolgen alle Vorgänge anonym. Die Bezahlungen, die mit der Karte gemacht werden, beinhalten außer der Mensa, kopieren, drucken und waschen. Diese Anwendungen werden schon an der Universität angeboten. Die Vorteile, die mit der neuen Karte kommen, beziehen sich nicht direkt auf die Sicherheit. Die Benutzung eines kontaktlosen Chips erhöht die Benutzungsdauer der Karte und der Kartenleser. Die Karte muss nicht in einen Karteleser eingesteckt werden. Schmutz auf der Karte in der Mensa wird dadurch verringert. Die Kartenleser funktionieren immer unabhängig davon, ob eine Karte schmutzig ist. Tatsächlich erfolgt der Bezahlvorgang dadurch, dass die Karte in unmittelbarer Nähe des Kartenlesers gebracht wird. Es reicht sogar wenn die Karte in einem Geldbeutel steckt und dieser in der Nähe von dem Leser gebracht wird. Der Mifare-Chip ermöglicht einen Kontakt von bis zu 10 cm Entfernung. Der Betrag in der Karte kann zurück erstatten werden, so bald der Besitzer dies wünscht. Der große Nachteil ist, dass weder die Universität noch das Studentenwerk der TU-Darmstadt eine Haftung für die mit dem Mifare Chip geladenen Geldbeträge übernehmen. Dies ist ein Nachteil, weil jede Person, der die Karte nicht gehört, kann mit der Karte auch bezahlen, da kein Identifikationsmechanismus vorhanden ist. Die zukünftig geplanten Anwendungen mit dem Mifare-Chip sind: Gebäudezugang: Die Universität beabsichtigt seine Einrichtungen mittels Zugangskontrolle zu schützen. Dies erfolgt wie bei der Bezahlung, in dem die Chipkarte in unmittelbarer Nähe eines Kartenlesers gebracht wird. Die Kartennummern werden zu verschieden Zugangsrechten abgebildet, so dass das System automatisch erkennt, zu welchem Gebäude oder Raum Zutritt zu gewähren ist. Karten vom Bankkonto laden: Die Benutzer der Karten sollen die Möglichkeit bekommen ihre Karten, direkt von Ihrem Konto zu laden. Wie dies erfolgen soll, ist noch nicht klar. Karten zur Rückmeldung benutzen: Die Benutzer sollen die Möglichkeit bekommen sich mit ihrer Karte rückzumelden, anstelle das Verfahren mit den Überweisungsformular zu benutzen. Diese Einführung wird noch als nicht nötig eingeschätzt, da die Überweisungsformulare bis jetzt noch kein großes Problem stellen.

71 6.3. Anwendungen mit dem kontaktlosen Chip 65 Abbildung 6.2: Aufforderung zur PIN Eingabe beim Versuch eine Mail zu signieren oder verschlüsseln

72 66 6. Anwendungen Abbildung 6.3: Eingabezeit Begrenzung mit Kobil Smart Key

73 6.3. Anwendungen mit dem kontaktlosen Chip 67 Abbildung 6.4: VPN Authentifizierung mit Kobil Smart Key

74 68 6. Anwendungen

75 Kapitel 7 Realisierung von Prototypen 7.1 Authentifikation, Autorisation auf Webserver mittels SSL Webservern werden in großen Mengen an der TUD benutzt. An diesen Webservern hängen mehrere Webseiten und Dokumente, die vor unberechtigten Dritten geschützt werden müssen. Dieser Schutz wird in dieser Arbeit mit Hilfe der Authentifikation und Zugriffkontrolle mittels Secure Sockets Layer (SSL) erreicht. Gewöhnlich war bis jetzt die Benutzung von Benutzerpasswörtern ohne Authentisierungsanforderungen. SSL ist ein Übertragungsprotokoll, das von Netscape entwickelt worden ist, um private Dokumente mittels Tunneling zwischen einem Client und einem Server über Internet zu übermitteln. SSL benutzt einen privaten Schlüssel um die Dateien zu verschlüsseln, die über die SSL Verbindung übermittelt werden. Für den Aufbau einer SSL Verbindung muss sich der Server gegenüber dem Client immer authentisieren. Der Client wird sich gegenüber dem Server nur dann authentisieren müssen, wenn dies konfiguriert wurde. Eine zweiseitige Authentisierung erfolgt wie folgt: Der Client sendet eine Verbindungsanfrage an den Server. Der Server antwortet mit derselben Nachricht und sendet eventuell ein Zertifikat. Der Client versucht, das Zertifikat zu authentisieren (bei Misserfolg wird die Verbindung abgebrochen). Dieses Zertifikat enthält den öffentlichen Schlüssel des Servers. Nach erfolgter Authentisierung erstellt der Client das pre-master secret, verschlüsselt dieses mit dem öffentlichen Schlüssel des Servers und sendet es an den Server. Ebenfalls erzeugt der Client daraus den Master secret. Der Server entschlüsselt das pre-master-secret mit seinem privaten Schlüssel und erstellt das Master secret. 69

76 70 7. Realisierung von Prototypen Client und Server erstellen aus dem Master secret den session-key. Das ist ein einmalig benutzter symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten genutzt wird. SSL unterstützt für die symmetrische Verschlüsselung mit diesem session-key unter anderem DES und Triple DES. Client und Server tauschen mit diesem session-key verschlüsselte Nachrichten aus und signalisieren damit ihre Kommunikationsbereitschaft. Die SSL-Verbindung ist aufgebaut. Es wird in diesem Abschnitt eine einfache PKI aufgebaut und einige Anwendungen simuliert. Um dies zu erreichen braucht man einen Webserver, eine SSL implementierende Software, und ein Interface Modul zwischen dem Webserver und der SSL Software, die starke Kryptographie für den Webserver realisiert mit Hilfe von der SSL Software. Diese Software und die Module müssen erst installiert werden. Die Installation erfordert bestimmte Voraussetzungen je nachdem welches Betriebssystem benutzt wird. Die Tests wurden unter den Betriebssystemen Windows XP und Linux Suse 9.0 durchgeführt Vorraussetzungen Alle benutzten Software außer Visual C++ von der Firma Microsoft sind Open Source Projekte. Vorrautsetzungen unter Linux Die folgenden Programme müssen aus den genannten Quellen heruntergeladen werden Apache Webserver: Apache Webserver ist ein Webserver, der für fast alle Betriebssysteme verfügbar ist. Er implementiert alle für den Test gebrauchten features (Zum Beispiel: Verwaltung der Authentisierung von Einheiten auf verschiedenen Webdokumenten). Die verschiedenen Versionen von Apache Webserver können aus [APA] heruntergeladen werden. Die Version 1.3 wurde für den Test heruntergeladen. OpenSSL: OpenSSL implementiert den SSL und den Transport Layer Security (TLS). Dies ermöglicht eine sichere Verbindung von Client zu Server. Zudem stellt OpenSSL Kryptographische-Bibliotheken zur Verfügung und implementiert verschiedenene PKI Standards (Zum Beispiel: Erzeugung von X.509 Zertifikaten). Die Version OpenSSL wurde aus [OSSL] heruntergeladen. Mod SSL: Die Mod SSL Schnittstelle zwischen Apache und OpenSSL ermöglicht starke Kryptographie für den Apache Webserver auf der Basis von OpenS- SL. Die Software kann aus [MSSL] heruntergeladen werden. Die Version Mod SSL 2.8 wurde für den Test benutzt.

77 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 71 OSSP MM: Viele Features von Apache Webserver werden als verteilte dynamische Objekte (in eng. Dynamic Shared Object DSO) geladen und benutzt. Die Schnittstelle Mod SSL wird auch als DSO geladen. Das Betriebssystem Linux bietet aber keine dynamische Speicherverwaltung für die Module von Apache. Aus diesem Grund wurde die Bibliothek OSSP MM implementiert. Die Version MM wurde aus [ESC] heruntergeladen. Perl (optional): Die Version Perl wurde aus [PER] heruntergeladen. GZip: GZip ist ein Dekompressionsprogramm. Ein Dekompressionsprogramm wird gebraucht, weil alle heruntergeladenen Softwaren komprimiert sind. Die Version GZip wurde aus [GZI] heruntergeladen. Vorrautsetzungen unter Windows Apache Webserver: Die Binary Version 1 von Apache Webserver kann aus [APA] heruntergeladen werden. Mod SSL: Es gibt für Mod SSL keine Binary Version. Die Version, die aus [MSSL] heruntergeladen werden kann muss kompiliert werden. OpenSSL: Die Binary Version von OpenSSL wurde aus [OSSL] heruntergeladen. Visual C++: Es gibt nicht für jeden der oben genannten Softwaren, Binary Versionen die einfach installiert werden können. Für die Kompilierung der Daten wird unter Windows Visual C++ eingesetzt. Mehr über Visual C++ in [VC+]. Cygwin32: Eine andere Möglichkeit die Daten zu kompilieren ist die Unix simulierende Anwendung Cygwin32 für Windows Betriebssysteme. Die Anwendung wurde aus [CGW] heruntergeladen. Perl (optional): Die Binary Version von wurde aus [PER] heruntergeladen. Für die Installation wird auf den Anhang A verwiesen. 1 Binary Version steht für Windows typische Installationsdateien, die keine Kompilierung brauchen.

78 72 7. Realisierung von Prototypen Konfiguration Konfiguration von Apache Die Konfiguration von Apache besteht hauptsächlich aus der Datei http.conf. Aus dieser Datei erfährt Apache alles was er zum Starten des Servers (eine ohne SSL Unterstützung oder mit SSL Unterstützung) braucht. Die Quelltextdistribution des Servers enthält einen Satz an Beispieldateien für die Konfiguration des Servers. Sie werden in einer Standarddistribution ein Unterverzeichnis mit dem Namen conf vorfinden, welches seinerseits einige Beispieldateien enthält, die alle die Endung dist haben. Die Vorschläge, die am Ende jedes Abschnittes gemacht werden, beziehen sich immer auf eine Installation mit Installation-CDs auf Linux SUSE 9.0. Es wird empfohlen eine Kopie dieser Dateien zu machen, bevor man Änderungen vornimmt. Die Konfigurationsdateien bestehen aus zwei Typen von Informationen: Kommentare und Direktiven an den Server. Kommentare sind alle Zeilen, die mit dem Zeichen # beginnen. Die Kommentarzeilen haben für den Server keine Bedeutung. Sie werden als Dokumentation und für Hinweise benutzt. Es können beliebige viele Kommentare hinzugefügt werden. Alle Zeilen, die nicht leer sind oder eine Kommentar enthalten, werden entweder als ganze Direktiven oder Teilanweisungen für den Server interpretiert. Direktiven sind so etwas wie Arbeitsanweisungen für den Server, die ein bestimmtes Verhalten aktivieren, abstellen oder verändern. Durch die Veränderung der Datei http.conf wird das Verhalten des Servers direkt verändert. Im Anhang A ist eine Konfigurationsdatei dargestellt. Die Direktiven werden in folgenden Abschnitten beschrieben und gleichzeitig in die Konfigurationsdatei geschrieben. Für eine genauere Beschreibung wird [MJK03] empfohlen. Es gibt drei verschiedene Direktivengruppen: Die Direktiven für die globale Umgebung, die Direktiven für die Konfiguration des Default- Servers und die Direktiven für die Konfiguration der virtuellen Hosten. Direktiven für die globale Umgebung Die wichtigsten Direktiven werden hier besprochen. Eine ausführliche Beschreibung aller Direktiven für die globale Umgebung kann in [MJK03] gelesen werden. Die ersten Direktiven ServerType, ServerRoot: Die Direktive ServerRoot legt das Wurzelverzeichnis des Web-Servers fest. Es ist nicht das Verzeichnis, in dem alle Web-Dokumente angelegt werden, sondern jenes, in dem der Server installiert ist. Der Vorgabewert für ServerRoot entspricht dem Wert, der bei der mit Hilfe von heruntergeladenen Dateien Installation (nicht mit den Installation-CDs) durch die Option prefix festgelegt wurde. Bei der Installation mit Hilfe von Installation-CDs, wird das Verzeichnis /srv/www/ automatisch angelegt. ServerRoot: /srv/www/ Die Direktive ServerType legt fest, ob der Server vom System gestartet wird (inetd) oder manuell (standalone). ServerType: standalone

79 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 73 Timeout, KeepAlive, MaxKeepAliveRequests und KeepAliveTimeout: Die Direktive Timeout setzt die Grenzwerte für den Server-Timeout. Die Werten der Direktiven KeepAlive, MaxKeepAliveRequests und KeepAliveTimeout bestimmen, wie lange Verbindungen aufrechterhalten werden. Die restlichen Direktiven benötigen meistens nicht viele Veränderungen. Der angesproche Teil für die erste Direktivegruppe ist im Bild 7.1 enthalten. Die komplette Konfigurationsdatei ist im Anhang A zu sehen. ## ## httpd.conf -- Apache HTTP server configuration file ## ### Section 1: Global Environment ServerType standalone ServerRoot "/srv/www" LockFile /var/lock/subsys/httpd/httpd.accept.lock PidFile /var/run/httpd.pid ScoreBoardFile /var/run/httpd.scoreboard Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 1 MaxSpareServers 1 StartServers 1 MaxClients 150 MaxRequestsPerChild 0 Abbildung 7.1: Globale Umgebung der Konfigurationsdatei von Apache. Direktiven für die Konfiguration des Main-Servers Die zentrale Konfiguration des Servers bezieht sich auf den Main-Server. Dieser Server ist derjenige, der reagiert und Dokumente ausliefert, sobald nach dem

80 74 7. Realisierung von Prototypen Start des Servers die IP-Adresse oder der Namen des Rechners in die Adressleiste des Browsers eingegeben wurde. In diesem Abschnitt werden auch nur die wichtigsten Direktiven besprochen. Port: Der Wert dieser Direktive legt fest, auf welchem Port der Server Anfragen beantwortet. Der Standard Wert ist 80. Der Server wird dann wie folgt angesprochen: Wenn eine SSL Unterstützung gewünscht ist, muss dies Apache miterteilt werden. Der Port für Webseiten mit SSL Unterstützung (die mit https anfangen anstelle von http) ist 443. Es wird also folgendes eingetragen: < IfDefine SSL > < Listen 80 > < Listen 443 > < / IfDefine > Benutzer User und Gruppennamen Group : Die Direktiven User und Group legen fest, unter welcher Benutzerkennung UID und unter welchem Gruppennamen GID die Serverprozesse laufen sollen. Diese Direktiven sind extrem wichtig für die Sicherheit des Systems vor allem in Hinsicht auf die Unix-Systeme. Der Primäre Serverprozess, der auf Verbindungen wartet, läuft als Prozess des Root-Users. Die andere Prozesse (im Falle von mehreren Servern), laufen als Kindprozesse mit unterschiedlichen Benutzer- und Gruppen-IDs. Die Kindprozesse laufen nicht als Root-Prozesse, würde das der Fall sein, öffne sich ein potenzielles Sicherheitsloch für Hacker-Attacken, da Benutzer unerlaubte Rechte als Root-User ausnutzen könnten. Die Kindprozesse sollten möglichst wenig Privelegien haben. ServerAdmin: Diese Direktive bestimmt welche Adresse angezeigt wird, wenn der Server eine Fehlerseite generiert. Aus diesem Grund ist es sinnvoll die - Adresse des Web-Administrators einzutragen. ServerName: Diese Direktive legt den Namen fest, mit dem der Server angesprochen wird. Zusätzlich zu der Möglichkeit der Server wie oben in der Direktive Port mit dem Hostnamen gezeigt wurde, kann der Server wie folgt auch angesprochen werden: DocumentRoot: Hier und nicht unter ServerRoot wird das Verzeichnis eingetragen, das als Wurzelverzeichnis für alle Dokumente gilt. Im Falle mehrere Webseiten oder Webserver wird empfohlen für jeden ein Unterverzeichnis anzulegen, damit der primäre Server nur auf die Dateien der jeweiligen Webserver oder Webseite greifen kann. Module : Apache Module sind Komponenten, die der Apache API entsprechen und in den Webserver von Apache geladen werden können. Dies kann statisch

81 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 75 bei der Kompilation des Projektes oder dynamisch über die Konfigurationsdatei geschehen. Man kann sowohl vorhandene als auch selbst geschriebene (mit Perl geschrieben) Module einbinden. Mod SSL.so ist ein Beispiel eines Apache Moduls, das die Einbindung von Mod SSL ermöglicht. Module müssen über die Anweisung LoadModule geladen werden und über die Anweisung AddModule zur Benutzung gestellt werden. Die Default Module werden in dem ersten Teil der Konfurationsdatei (Global Section) definiert. Weil es viele gibt wurden sie nur in der kompletten Konfigurationsdatei in Anhang A gezeigt. Um Apache mit SSL Unterstützung starten zu können, muss folgendes angegeben werden: LoadModule ssl module /usr/lib/apache/libssl.so AddModule Mod SSL.c Es ist vorausgesetzt, dass die Datei libssl.so sich wirklich in Verzeichnis /usr/lib/apache/ befindet. Der Teil der Konfigurationsdateien mit benutzten Direktiven für die Konfiguration des Default-Servers ist im Bild 7.2 dargestellt: Direktiven für die Konfiguration der virtuellen Hosts Virtueller Hosts dienen dazu, verschiedene Webangebote auf einer einzigen Maschine zu betreiben. Es gibt zwei Arten von virtuellen Hosts: IP-basierte virtuelle Hosts und Namensbasierte virtuelle Hosts. IP-basierte virtuelle Hosts ermöglichen das Betreiben eines einzigen Webangebotes unter einer eindeutigen IP-Adresse. Namens-basierte virtuelle Hosts ermöglichen das Betreiben mehreren Webangeboten unter einer einzigen IP-Adresse. Namens-basierte virtuellen Hosten wurden für den Test vorgezogen, da der Zugriff auf mehreren Webangebote unter einer einzigen IP-Adresse mit verschiedenen Zertifikaten getestet werden sollte. Die Direktiven für die Konfiguration der virtuellen Hosts sind in zwei Kontexten verteilt: ein SSL Global Kontext und ein SSL virtueller Host Kontext. SSL Global Kontext Der SSL Global Kontext enthält die globalen SSL Anweisungen: Das heißt die SSL Anweisungen sowohl für den Server als auch für die virtuellen Hosts. MIME-Types Die Direktiven von dem Modul mod mime beschreiben den Inhalt von Webdokumente. Der Client muss wissen wie er Webdokumenten zu behandeln hat. Dabei ist wichtig zu wissen, um welche Arten von Dokumenten es sich handelt. Dafür gibt es die Direktive AddType. Diese Direktive wird hier benutzt um die Zertifikate- und CRL-Formate zu definieren. <IfDefine SSL> AddType application/x-x509-ca-cert.crt AddType application/x-pkcs7-crl.crl </IfDefine> Mod SSL Dieser Teil enthält die globalen Direktiven für die Konfiguration von - Mod SSL. Diese Direktiven können beliebig als global oder für einen spezifischen virtuellen Host definiert werden. Die Default Konfigurationsdatei bietet die Direktiven SSLPassPhraseDialog, SSLSessionCache,

82 76 7. Realisierung von Prototypen ### Section 2: Main server configuration Port 80 <IfDefine SSL> Listen 80 Listen 443 </IfDefine> User wwwrun Group www ServerAdmin ServerName localhost DocumentRoot "/srv/www/htdocs" <Directory /> AuthUserFile /etc/httpd/passwd AuthGroupFile /etc/httpd/group Options -FollowSymLinks +Multiviews AllowOverride None </Directory> <Directory "/srv/www/htdocs"> Options Indexes -FollowSymLinks +Includes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> <IfModule mod_dir.c> DirectoryIndex index.html </IfModule> AccessFileName.htaccess <Files ~ "^\.ht"> Order allow,deny Deny from all Satisfy All </Files> UseCanonicalName On <IfModule mod_mime.c> TypesConfig /etc/httpd/mime.types </IfModule> DefaultType text/plain <IfModule mod_mime_magic.c> MIMEMagicFile /etc/httpd/magic </IfModule> HostnameLookups Off ServerSignature Off <Directory "/srv/www/htdocs/manual"> Options Indexes FollowSymlinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory> Abbildung 7.2: Konfiguration des Apache Main-Servers.

83 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 77 SSLMutex, SSLRandomSeed, SSLLog. SSLPassPhraseDialog beschreibt den Vorgang zur Anfrage von der Passphrase für den privaten Schlüssel des Servers. Eine Passphrase schützt den privaten Schlüssel vor unerlaubter Benutzung. SSLSessionCache beschreibt die Art von Cache, die für die parallelen Anfragen an der Server benutzt wird. SSLMutex beschreibt die Art, mit welcher Prozesse synchronisiert werden. Diese Direktive ist die Einzige, die eine globale Definition erfordert, weil sie nur so einen Sinn macht. SSLRandomSeed beschreibt wie die Zufallszahlen erzeugt werden. SSLLog beschreibt die Direktive, die für die Protokollierung der Meldungen von SSL Modulen benutzt wird. Mehr Informationen über die Direktiven von Mod SSL können in [ERR02] gewonnen werden. SSL Virtuellen Host Kontext In diesem Abschnitt bezieht sich die Konfiguration auf einen spezifischen virtuellen Host. Als erstes werden für die im virtuellen Host enthaltenen Verzeichnisse die Zugriffskontrolle konfiguriert. Dies erfolgt mit Hilfe von den folgenden Direktiven (alle aus dem Modul Mod SSL): SSLRequire gibt an, welche Vorraussetzungen erfüllt werden müssen, um Zugriffsrechte auf bestimmte Daten zu bekommen. SSLVerifyDepth gibt an, wieviele Zertifikate zwischen dem Zertifikat des Clients und dem Zertifikat, dass der Server für die Überprüfung benutzt, vorhanden sind. Für selbstsignierte Zertifikate wird der Wert auf 0 gesetzt. SSLVerifyClient beschreibt was ein Client braucht, um sich zu authentisieren. Der Besitz eines gültigen Zertifikats kann als optional oder notwendig eingestellt werden, wobei die Gültigkeit nicht default vorgegeben sein muss. SSLEngine aktiviert oder deaktiviert das SSL Protokoll. Die nächsten Direktiven dienen der globalen Konfiguration von virtuellen Hosten. SSLCertificateFile gibt den Speicherort des Serverzertifikats an. SSLCertificateChainFile beschreibt eine Reihe Zertifikaten von CAs, die voneinander abhängen. Diese Zertifikate können als ein Baum strukturiert werden. Diese Direktive dient der Verifikation von Serverzertifikaten. SSLCipherSuite gibt an, welche Verschlüsselungsverfahren akzeptiert werden und welche Zertifikate nicht akzeptiert werden. SSLCertificateKeyFile gibt den Speicherort des Serverschlüssels an. SSLCACertificatePath gibt den Speicherort der Zertifikate von CAs an, die für die Authentisierung der Clients benötigt werden. Dies ist nützlich, wenn mehrere CAs benutzt werden.

84 78 7. Realisierung von Prototypen SSLCACertificateFile gibt den Speicherort des Zertifikats von der CA an. Unterschied zu der vorherigen Direktive, ist das hier nur ein Zertifikat ist. SSLCARevocationFile gibt den Speicherort der CRL an. SSLOptions beschreibt zusätzliche Funktionen von Mod SSL. Wie bei der Konfiguration des Main Servers müssen die Direktiven DocumentRoot, ServerName, ErrorLog und TransferLog die benötigten Werte haben. Das Bild 7.3 ist eine Dartellung der letzen Abschnitt der Konfigurationsdatei.

85 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 79 ### Section 3: Virtual Hosts <IfDefine SSL> AddType application/x-x509-ca-cert.crt AddType application/x-pkcs7-crl.crl </IfDefine> <IfModule mod_ssl.c> SSLPassPhraseDialog builtin SSLSessionCache dbm:/var/run/ssl_scache SSLSessionCache shmcb:/var/lib/httpd/ssl_scache SSLSessionCacheTimeout 600 SSLMutex file:/var/run/ssl_mutex SSLMutex sem SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLLog /var/log/httpd/ssl_engine_log SSLLogLevel info </IfModule> <IfDefine SSL> <Directory "/srv/www/server"> SSLRequireSSL SSLVerifyDepth 0 </Directory> <Directory "/srv/www/server/client"> SSLVerifyClient require SSLVerifyDepth 3 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_OU} in {"FB20","FB3"} </Directory> <Directory "/srv/www/server/client/informatik"> SSLVerifyClient require SSLVerifyDepth 3 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_OU} in {"FB20","CDC"} </Directory> <Directory "/srv/www/server/client/psychologie"> SSLVerifyClient require SSLVerifyDepth 3 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_OU} eq "FB3" </Directory> <VirtualHost _default_:443> DocumentRoot "/srv/www/server" ServerName localhost #ServerAdmin you@your.address ErrorLog /var/log/httpd/error_log TransferLog /var/log/httpd/access_log SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/ssl/certs/servercert.pem SSLCertificateKeyFile /etc/ssl/certs/serverkey.pem #SSLCertificateChainFile /etc/httpd/ssl.crt/ca.crt SSLCACertificatePath /etc/ssl/certs SSLCACertificateFile /etc/ssl/certs/cacert.pem SSLCARevocationPath /etc/httpd/ssl.crl SSLCARevocationFile /etc/httpd/ssl.crl/ca-bundle.crl </VirtualHost> </IfDefine> Abbildung 7.3: Konfiguration von virtuellen Hosten.

86 80 7. Realisierung von Prototypen Aufbau einer Zertifizierungsinstanz CA Eine Test CA wird mit Openssl erzeugt. Die Test CA wird von sich selbst signiert Seine Authentizität kann nicht von Dritten behauptet werden. Der Test-Server läuft unter Linux SuSe 9.0. Shell Script schreiben Es wird einen Shell Script geschrieben, dass eine spätere Erstellung automatisiert. openssl genrsa -des3 -passout pass:1234 -out cakey.pem 1024 openssl req -new -key cakey.pem -out careq.csr touch cacert.pem openssl req -new -x509 -days 365 -in careq.csr -key cakey.pem -passin pass:1234 -out cacert.pem -extensions v3_ca cp cacert.pem../certs/cacert.pem openssl pkcs12 -export -clcerts -inkey cakey.pem -out ca.p12 -passin pass:1234 -in cacert.pem Abbildung 7.4: Shell Script zur automatischen Erzeugung von CA-Zertifikaten CA Authentication Damit der Apache Webserver weiß, mit welcher CA er die Zertifikate überprüfen muss, muss der Speicherort des CA Zetifikats und des Schlüssels in der Konfigurationsdatei von Apache eingetragen werden Erzeugung von Serverzertifikaten Damit der Server sich gegenüber den Clients authentizieren kann, werden Server- Zertifikate erstellt. Shell Script schreiben Erzeugung von Server-Zertifikaten ohne jedes Mal alles neu schreiben zu müssen. #!/bin/bash openssl genrsa -des3 -out certs/serverkey.pem 1024 openssl req -new -key certs/serverkey.pem -out certs/serverreq.pem -days 300 -extensions v3_req touch certs/server.pem cat certs/serverkey.pem certs/serverreq.pem > certs/server.pem openssl ca -cert private/cacert.pem -extensions usr_cert -out certs/servercert.pem -infiles certs/server.pem c_rehash Abbildung 7.5: Shell Script zur automatischen Erzeugung von Server- Zertifikaten Server Authentication Der Apache Web-Server kann sich nur authentizieren, wenn er das für ihn erzeugte Zertifikat findet. Dies wird dadurch erreicht, dass der Speicherort des Zertifikats in der Konfigurationsdatei eingetragen wird.

87 7.1. Authentifikation, Autorisation auf Webserver mittels SSL Aufbau User Gruppen mit Zertifikaten Um die Authentisierung und Autorisation zu simulieren, werden User Gruppen mit verschiedenen Zugriffsrechten (also verschiedenen Zertifikatsextensions) gebraucht. Es werden für den Test zwei User-Gruppen erstellt. Die Gruppe mit Studenten der Informatik und die Gruppe mit Studenten der Psychologie. Die Studenten werden eine Autorisation brauchen um bestimmte Aktionen als Informatik-Student oder Psychologie-Student erfolgreich zu machen. Shell Script schreiben #!/bin/bash #echo $1 openssl genrsa -des3 -out private/$1.key 1024 openssl req -new -extensions v3_req -key private/$1.key -out private/$1.pem -days 30 openssl ca -cert certs/cacert.pem -extensions usr_cert -in private/$1.pem -out newcerts/$1.crt openssl pkcs12 -export -clcerts -in newcerts/$1.crt -inkey private/$1.key -out newcerts/$1.p12 Abbildung 7.6: Shell Script zur automatischen Erzeugung von Benutzer- Zertifikaten Client Authentication Es werden Zertifikate für die Benutzer erstellt mit den benötigten Eigenschaften, abhängig davon, ob man Student der Informatik oder Student der Psychologie ist. Auf einem anderen Rechner installieren die Test- Studenten in ihren Browser ihre Zertifikate Authentisierung und Rechtsvergabe Die verschiedenen Zugriffsrechte auf Test-Webseiten werden dadurch geregelt, dass sich der Server gegenüber dem Client mittels Zertifikaten authentisiert. Dafür wird die Anzahl von benötigten CAs für die Authentisierung angegeben. Der Wert 0 deutet, dass das Zertifikat von dem Server selbstsigniert ist. Der Zugriff auf das Verzeichnis der Test-Webseite ist wie im Bild 7.7 konfiguriert: <Directory "/srv/www/server"> SSLRequireSSL SSLVerifyDepth 0 </Directory> Abbildung 7.7: Konfiguration der Zugriffsvoraussetzungen auf das Verzeichnis der Test-Webseite

88 82 7. Realisierung von Prototypen Der Zugriff auf das Verzeichnis der Studenten-Webseite ist wie im Bild 7.8 konfiguriert: <Directory "/srv/www/server/client"> SSLVerifyClient require SSLVerifyDepth 3 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_OU} in {"FB20","FB3"} </Directory> Abbildung 7.8: Konfiguration der Zugriffsvoraussetzungen auf das Verzeichnis der Studenten Test-Webseite Der Zugriff auf das Verzeichnis der Informatiker-Webseite ist wie im Bild 7.9 konfiguriert: <Directory "/srv/www/server/client/informatik"> SSLVerifyClient require SSLVerifyDepth 3 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_OU} in {"FB20","CDC"} </Directory> Abbildung 7.9: Konfiguration der Zugriffsvoraussetzungen auf das Verzeichnis der Informatiker Test-Webseite Der Zugriff auf das Verzeichnis der Psyschologen-Webseite ist wie im Bild 7.10 konfiguriert: <Directory "/srv/www/server/client/psychologie"> SSLVerifyClient require SSLVerifyDepth 3 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_OU} eq "FB3" </Directory> Abbildung 7.10: Konfiguration der Zugriffsvoraussetzungen auf das Verzeichnis der Psychologen Test-Webseite

89 7.1. Authentifikation, Autorisation auf Webserver mittels SSL Test (Betrieb) In diesem Abschnitt wird der Betrieb bewertet und diskutiert, ob die Ziele erreicht worden sind. Studenten der Informatik sollen die Möglichkeit bekommen auf die Studenten-Webseite und die Informatik-Webseite zuzugreifen, aber nicht auf die Psychologen Webseite. Dies gilt auch für die Studenten der Psychologie. Diese sollen kein Zugriff auf die Informatik-Webseite bekommen. In der Konfigurationsdatei des Servers müssen die Speicherorte der Zertifikate angegeben werden. Die komplette Konfigurationsdatei kann in Anhang A angesehen werden. Für den Test der Signature und der Verschlüsselung, ist nur die Installation von den erzeugten Zertifikaten nötig. Aus diesem Grund wurde kein zusätzlicher Abschnitt hierfür gemacht. Server Starten linux:/ # apachectl startssl Apache/ mod_ssl/ (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server localhost:443 (RSA) Ok: Pass Phrase Dialog successful. Ok: Pass Phrase Dialog successful. /usr/sbin/apachectl startssl: httpd started Zugriffe Auf die Start-Seite: Bild 7.11 Auf die Studenten-Webseite: Bild 7.12 Auf die Informatiker-Webseite: Bild 7.13 Auf die Psychologen-Webseite: Bild 7.14

90 84 7. Realisierung von Prototypen Abbildung 7.11: Startseite

91 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 85 Abbildung 7.12: Webseite der Studenten

92 86 7. Realisierung von Prototypen Abbildung 7.13: Webseite der Informatiker

93 7.1. Authentifikation, Autorisation auf Webserver mittels SSL 87 Abbildung 7.14: Test Webseite der Psychologen