PKI-Kooperationen zwischen Hochschulen und externen Einrichtungen. Fallstudie HypoVereinsbank FernUniversität

Transkript

1 PKI-Kooperationen zwischen Hochschulen und externen Einrichtungen Fallstudie HypoVereinsbank FernUniversität Henning Mohren FernUniversität in Hagen Universitätsrechenzentrum Universitätsstr Hagen 1

2 PKI-Kooperation Inhalt 1. PKI der FernUniversität 2. Chipkarten der HypoVereinsbank 3. Kooperation: Chipkarten der HypoVereinsbank in der PKI der FernUniversität 4. Kooperation: Verifikation von Zertifikaten 5. Ausblick 6. Partner 2

3 PKI der FernUniversität 1996: Beginn des DFN-Projekts Public-Key Service gefördert durch DFN, BMBF Technik: PGP 1997: Erweiterung des Projekts um SSL (X.509) 2002: Inbetriebnahme des Zertifizierungsautomaten für SSL-Zertifikate 2003: Zusammenarbeit mit NRW-Hochschulen, etoken-erweiterung 2004: Kooperation mit der HypoVereinsbank 2005: Kooperation mit Magellan Netzwerke GmbH 3

4 PKI der FernUniversität Komponenten einer PKI R Public Key Infrastructure (PKI) Registration Authority (RA) Certification Authority (CA) Validation Authority (VA) 4

5 PKI der FernUniversität Die FernUniversität ist anders R Keine Studierenden auf dem Campus (Persönlicher) Kontakt zwischen Studierenden und FernUniversität meist nur über Außenstellen ( Studienzentren ) Direkter Kontakt zwischen Studierenden und FernUniversität fernmündlich über Internet schriftlich 5

6 PKI der FernUniversität Wie erhält der Benutzer sein Zertifikat? R Zentrale Frage: Wie stelle ich sicher, dass Teilnehmer der PKI ein Zertifikat erhalten, ohne dass sie persönlich bei der Registration Authority (RA) / Certification Authority (CA) erscheinen müssen? Lösung: Clientzertifikate: Authentisierung mit Hilfe von Daten, die der FernUniversität ohnehin vorliegen: Einschreibevorgang Einstellungsvorgang Behördenadressen 6

7 PKI der FernUniversität Wie erhält der Benutzer sein Zertifikat? R Zentrale Frage: Wie stelle ich sicher, dass Teilnehmer der PKI ein Zertifikat erhalten, ohne dass sie persönlich bei der Registration Authority (RA) / Certification Authority (CA) erscheinen müssen? Lösung: Serverzertifikate: Außenwirkung! Persönliches Erscheinen bei Mitarbeitern der CA Serverzertifikate nur für Beschäftigte der FernUniversität 7

8 PKI der FernUniversität Authentisierung der Teilnehmer: Postverfahren R Einschreibevorgang Verifizierter Datenaustausch General- Password Adresse BMC Control SA HIS/SOS 8

9 PKI der FernUniversität Authentisierung der Teilnehmer: Postverfahren Z Ausnutzen des Einschreibevorgangs für den Zertifikatsserver: Client Zertifikatsserver 1. Client fordert Zertifikat an 2. Zertifikatsserver verifiziert Passwort gegen Zertifikatsdatenbank 3. Zertifikatsserver stellt Zertifikat aus; schreibt es in Zertifikatsdatenbank 4. Zertifikatsserver bietet Zertifikat zum Download an; Client holt es ab BMC Control SA HIS 9

10 PKI der FernUniversität Zulässige Speichermedien für Zertifikate Z Default: Windows-Zertifikatsspeicher / Browserumgebung Alternativ: Aladdin etoken Möglich: alles 10

11 PKI der FernUniversität V FernUni Root-CA Personen Server Objekte 11

12 PKI der FernUniversität Single-Root/Single-Level-PKIs V einfache Validierung von Zertifikaten flexible Attributierung Außenverhältnisse schwierig (Trust?) 12

13 PKI der FernUniversität DFN-PCA V FernUni Root-CA Personen Server Objekte 13

14 PKI der FernUniversität DFN-PCA V FernUni Root-CA Personen Server Objekte 14

15 PKI der FernUniversität Single-Root/Multiple-Level-PKIs V einfache Validierung von Zertifikaten Root-CA Attributierung in Abstimmung mit Root-CA Außenverhältnisse einfach Kooperation durch Verfolgung der Zertifikatskette bedingt möglich CA 1 CA 2 CA 3 15

16 PKI der FernUniversität Single-Root/Multiple-Level-PKIs V einfache Validierung von Zertifikaten Root-CA Attributierung in Abstimmung mit Root-CA Außenverhältnisse einfach Kooperation durch Verfolgung der Zertifikatskette bedingt möglich CA 1 CA 2 CA 3 16

17 Chipkarten der HypoVereinsbank Merkmale: R Persönliche Identifizierung zwingend erforderlich Zunächst fortgeschrittener Level (qualifiziert möglich) Zertifikate für Kunden auf eckarte (Bankensignaturkarte) Auch als kontoungebundene Karte Externe Anwendungen möglich 17

18 PKI Kooperation Aus zwei mach eins: Z + =? 18

19 PKI Kooperation Ziele der Kooperation: Einfache Möglichkeit für Studierende, Zertifikate zu erhalten Hohe Qualität der Zertifikate Mobilität von Zertifikaten Entlastung der FernUni-Mitarbeiter (keine etoken-verteilung) 19

20 PKI Kooperation Ziele der Kooperation: Werbung für die HypoVereinsbank Akzeptanzsteigerung für Signaturkarten (Auch externe Anwendungen angebunden) Persönliche Interessen 20

21 PKI Kooperation Optionen zur Kooperation: 1. Bridging/Meshing Z V FernUni Root-CA HypoVereinsbank Root-CA Personen Server Objekte Personen Server Objekte 21

22 PKI Kooperation Optionen zur Kooperation: 2. FernUniversität bringt auf den Chipkarten der HypoVereinsbank ein eigenes (weiteres) Zertifikat auf Z V 22

23 PKI Kooperation Optionen zur Kooperation: 3. FernUniversität akzeptiert HypoVereinsbank-Chipkarten Z V 23

24 PKI Kooperation Multiple-Root/Multiple-Level-PKIs komplizierte Validierung von Zertifikaten verschiedene Attributierungsmodelle Außenverhältnisse schwierig Aber: Modell entspricht dem wirklichen Leben (SigG) nur ein Zertifikat auf Nutzerseite Root-CA 1 CA 1 CA 2 V Root-CA 2 CA 3 24

25 PKI Kooperation Multiple-Root/Multiple-Level-PKIs komplizierte Validierung von Zertifikaten verschiedene Attributierungsmodelle Außenverhältnisse schwierig Aber: Modell entspricht dem wirklichen Leben (SigG) Lösung: Root-CA andere Validierung Qualität 1 zweistufig: Root-CA des 2 Ausweisens Prüfung im Sinne Außenverhältnis der PKI (Wurzel/CRL) im Sinne Dienstausweis Auflösen des Mitarbeiter Zertifikats erhalten gegen weiterhin Matrikelnummer Zertifikate der CA FernUniversität 1 CA 2 CA 3 Funktion Studentenausweis nicht erforderlich V nur ein Zertifikat auf Nutzerseite 25

26 PKI Kooperation Multiple-Root/Multiple-Level-PKIs komplizierte Validierung von Zertifikaten verschiedene Attributierungsmodelle Außenverhältnisse schwierig Aber: Modell entspricht dem wirklichen Leben (SigG) V Lösung: Primary Key an Universitäten ist die Matrikelnummer, daher Auflösen der Zertifikate gegen Matrikelnummer Zertifikate müssen an der FernUniversität (einmalig) registriert werden nur ein Zertifikat auf Nutzerseite 26

27 PKI Kooperation Multiple-Root/Multiple-Level-PKIs komplizierte Validierung von Zertifikaten verschiedene Attributierungsmodelle Außenverhältnisse schwierig Lösung: Validierung zweistufig: Prüfung im Sinne der PKI (Wurzel/CRL) Auflösen des Zertifikats gegen Matrikelnummer V Aber: Modell entspricht dem wirklichen Leben (SigG) nur ein Zertifikat auf Nutzerseite 27

28 PKI Kooperation Registrierung von Zertifikaten: R Nutzer erhält (nach wie vor) automatisch User-ID/General- Password per Post Nutzer ruft Webseite auf, meldet sich mit User-ID/General- Password und Zertifikat der HypoVereinsbank an Datensatz aus User-ID, Zertifikatsaussteller, Seriennummer wird erzeugt und in Datenbank hinterlegt rowid userid aussteller seriennummer AAAA35AAGAAAAAbAAV q o=dienstleister der HypoVereinsbank 00:00:01:00:01:00 AAAA35AAGAAAAAbAAW q o=dienstleister der HypoVereinsbank 00:00:04:00:02:00 AAAA35AAGAAAAAbAAX q o=dienstleister der HypoVereinsbank 00:07:AC:00:00:BF 28

29 PKI Kooperation Konsequenz für den Nutzer: R Altes Verfahren 1. Nutzer erhält Passwortbrief 2. Nutzer beantragt Zertifikat 3. Nutzer verwendet Zertifikat Neues Verfahren 1. Nutzer erhält Passwortbrief 2. Nutzer registriert Zertifikat 3. Nutzer verwendet Zertifikat 29

30 PKI Kooperation Verifikation von Zertifikaten: V 1. Zuerst Verifikation im Sinne der PKI 30

31 PKI Kooperation Verifikation von Zertifikaten: V 1. Zuerst Verifikation im Sinne der PKI 2. Auflösen gegen Matrikelnummer rowid userid aussteller seriennummer AAAA35AAGAAAAAbAAV q o=dienstleister der HypoVereinsbank 00:00:01:00:01:00 AAAA35AAGAAAAAbAAW q o=dienstleister der HypoVereinsbank 00:00:04:00:02:00 AAAA35AAGAAAAAbAAX q o=dienstleister der HypoVereinsbank 00:07:AC:00:00:BF 31

32 PKI Kooperation Ablauf einer zertifikatsbasierten Anmeldung V Client Webserver 1. Client fordert geschützte Webseite an 2. Webserver validiert Zertifikat (im Sinne der PKI) 3. Webserver ermittelt User-ID (aus Zertifikat oder aus Datenbank) 4. Webserver bereitet Daten auf und bietet diese an SOAP registrierte Zertifikate Daten 32

33 PKI Kooperation Konsequenz: V Modifikation des Verifikationsprozesses auf Seiten der Anwendungen Zusätzlich zur Validitätsprüfung auf PKI-Ebene ist ein Auflösen gegen User-ID erforderlich Webserver ist nicht in der Lage, ein Zertifikat selbstständig zu überprüfen Datenbankzugriff erforderlich Grundsätzlicher Unterschied: Eigenentwicklungen Fremdprodukte 33

34 PKI Kooperation Anwendungen: Webanwendungen: M U Lernraum Virtuelle Universität Online-Übungssystem Klausurkomponenten (Anmeldung, Auskünfte, Kommunikation mit Prüfungsamt) Anmeldung zu Praktika Softwaredownload Pflege von Studierendendaten - Abruf von Studierendendaten ( Kurslisten ) / Beraterportal - Andere Anwendungen: SSH - VPN? M = Umstellung möglich U = Anwendung bereits umgestellt 34 V

35 PKI Kooperation Ausblick: Skalierbarkeit Hinzunahme weiterer Zertifikate von anderen Ausstellern (Banken, Trustcentern, ) ist ohne weiteren Aufwand möglich Funktionserweiterung Implementierung weiterer Funktionen (echtes epayment) wird untersucht 35

36 Partner Unsere Partner: 36

37 Q&A 37