Abbildung 1: Zustand des Schlosses
von Uwe Dierolf
In zunehmendem Maße werden bei der Nutzung internetbasierter Dienste in Bibliotheken personenbezogene und somit sicherheitsrelevante Daten zwischen WWW-Browser und WWW-Server übertragen. Der Missbrauch dieser Informationen seitens Dritter kann bei kostenpflichtigen Diensten zu finanziellen Schäden Betroffener führen. Aus diesem Grund empfiehlt sich der Einsatz kryptographischer Verfahren zur sicheren Datenübertragung.
Dieser Beitrag beschreibt einerseits die zugrundeliegenden Konzepte als auch die Auswirkungen der Umstellung auf ein vorhandenes Umfeld.
1. Motivation
Seit der Einführung des internetbasierten Ausleihsystems (s. [Dier96]) im Januar 1996 wurden an der Universitätsbibliothek Karlsruhe zunehmend anmeldepflichtige Internetdienste entwickelt und einem mehr oder weniger breiten Kreis von Nutzern zur Verfügung gestellt. Zu diesen Diensten zählt der Profildienst "Persönliche Zeitschriftenliste" (PZL, Herbst 1996), das "Lokale Elektronische Aufsatzliefersystem" (LEA, Sommer 1997) und die "Online-Fernleihe" (März 1999). Weiterhin ist die UB Karlsruhe seit Herbst 1997 SUBITO-Bibliothek.
Diese Internetdienste lassen sich in kostenfreie und kostenpflichtige Dienste aufteilen. Gemeinsam ist ihnen, dass sich der Benutzer irgendwann im Verlauf einer "Sitzung" anmelden muss. Dazu werden von ihm (i.d.R. nur einmal pro Sitzung) die Eingabe seiner Benutzernummer und seines Passwortes verlangt. Diese Daten werden unverschlüsselt von seinem WWW-Browser zum WWW-Server übertragen.
Mißbrauch dieser Daten hätte bei den kostenfreien Diensten im schlimmsten Fall zu einer gelöschten Vormerkung oder einem unnötigen Dokumentlieferauftrag führen können. Echten Schaden konnte man dem Kontoinhaber jedoch nicht zufügen, da ein Ausleihvorgang die Vorlage des Benutzerausweises erfordert.
Spätestens seit Einführung der Online-Fernleihe und SUBITO kann Missbrauch jedoch zu einer monetären Belastung des Benutzerkontos führen. Bei SUBITO kommt noch eine zusätzlicher Aspekt hinzu. Hier gehen nicht "nur" Anmeldedaten unverschlüsselt übers Netz, sondern u.U. auch die Bankverbindung oder – sofern die Hochschulkassen Kredikartenzahlungen akzeptieren – auch Kreditkartennummern.
Noch kommen Anfragen nach sicheren Verbindungen nur sporadisch. Hier jedoch zu warten, bis der erste größere Schaden entsteht, wäre sicherlich der falsche Weg. Aus diesem Grund hat die UB Karlsruhe den WWW-Server so erweitert, dass von ihm neben unsicheren Verbindungen gemäß "http" nun auch sichere, verschlüsselte Verbindungen gemäß "https" unterstützt werden.
2. Was ändert sich für den Benutzer?
Hierauf gibt es eine erfreulich einfache Antwort - eigentlich nichts, aber ...
Mit "aber..." ist gemeint, dass mit etwas Glück tatsächlich gar nichts getan werden muss, um in den Genuss der sicheren Verbindungen zu kommen. Dies hängt von zwei Faktoren ab: Zum einen von der Aktualität des eigenen Browsers und den mitgelieferten Voreinstellungen sowie zum anderen vom angestrebten Maß an Perfektion des Betreibers des sicheren WWW-Servers.
Wenn überhaupt, dann muss man sich nur einmal mit einem Verfahren auseinandersetzen, das bei allen sicheren WWW-Angeboten im Internet anzutreffen ist. So gesehen fällt die Kenntnis des Verfahrens in den Bereich "Internet-Allgemeinbildung". Wichtigste Begriffe sind hierbei "Zertifikat" und "Zertifizierungsstelle", die im folgenden erläutert werden.
Grundsätzlich gibt es eine sichere Verbindung nicht ohne ein gewisses Mehr an Technik. WWW-Browser und WWW-Server müssen sich schließlich in irgendeiner Form so abstimmen, dass die vom WWW-Browser verschlüsselten Daten vom WWW-Server entschlüsselt werden können. Dazu muss der WWW-Browser dem WWW-Server das Passwort mitteilen, mit dem zu entschlüsseln ist. Dieses muss er dem WWW-Server natürlich verschlüsselt mitteilen, sonst würde das Verfahren keinen Sinn ergeben.
Hier kommen nun die öffentlichen Schlüssel (public keys) und sog. Zertifikate ins Spiel.
Der WWW-Browser verschlüsselt die Daten mit einem von ihm generierten sitzungsabhängigen Schlüssel. Diesen Schlüssel wiederum verschlüsselt er mit dem öffentlichen Schlüssel des WWW-Servers. Diesen öffentlichen Schlüssel entnimmt er dem Zertifikat des WWW-Servers. Nur der WWW-Server "weiß", wie man die mit seinem öffentlichen Schlüssel kodierten Daten dekodiert, das ist das Prinzip der öffentlichen Schlüssel.
Den Begriff Zertifikat beschreibt [Reif96] wie folgt: "Ein Zertifikat ist ein überprüfbares, öffentliches Dokument, das Informationen über seinen Besitzer enthält und von einer vertrauenswürdigen Institution (Zertifizierungsstelle = CA = certification authority) unterschrieben ist."
Das Zertifkat des WWW-Servers beinhaltet neben dem öffentlichen Schlüssel weitere Informationen, wie die Zertifizierungsstelle sowie technische Angaben, die für die Verschlüsselung benötigt werden. Die Zertifizierungsstelle unterschreibt das Zertifikat digital. Somit kann jeder, der im Besitz des öffentlichen Schlüssels der Zertifizierungsstelle ist, prüfen, ob das Zertifikat echt ist.
Das Beglaubigen eines Server-Zertifikats durch eine CA ist nicht obligatorisch. Für das Betreiben eines sicheren WWW-Servers reicht es, wenn überhaupt ein öffentlicher Schlüssel des WWW-Servers mit Hilfe eines Zertifikats dem WWW-Browser mitgeteilt wird. Damit kann eine Verbindung verschlüsselt werden und somit sicher ablaufen.
Die Wahrscheinlichkeit, dass sich ein Angreifer als Betreiber des WWW-Servers ausgibt, um an die sicherheitsrelevanten Daten heranzukommen, ist relativ gering. Böswillige Hacker suchen sich lohnendere Ziele als Zugangsinformationen zu Bibliothekskonten.
Die gängigen WWW-Browser führen intern eine Liste aller Zertifikate, denen sie vertrauen. Aktuelle Browser "kennen" die wichtigsten Zertifizierungsstellen. Neue Zertifikate und deren Gültigkeitsdauer ("gilt nur eine Sitzung lang" bzw. "gilt für immer") können manuell hinzugefügt werden, wenn man sie für vertrauenswürdig hält.
Baut ein Benutzer zum ersten Mal mit seinem WWW-Browser (z.B. im Rahmen einer Anmeldung) eine sichere Verbindung (gemäß https) auf, können folgende Fälle auftreten:
a) Der WWW-Server schickt ein Zertifikat, das von einer dem Browser bekannten Zertifizierungsstelle beglaubigt wurde.
b) Der WWW-Server schickt ein unbeglaubigtes Zertifikat oder ein beglaubigtes Zertifikat, das von einer dem Browser unbekannten Zertifizierungsstelle beglaubigt wurde.
Im ersten Fall merkt der Benutzer i.d.R. nicht, dass er eine sichere Verbindung aufgebaut hat, da das Server-Zertifikat anhand des im Browser abgelegten öffentlichen Schlüssels der Zertifizierungsstelle geprüft werden kann. Lediglich das Schloss-Icon in der Statusleiste gibt einen Hinweis darauf – das normalerweise offene Schloss ist nun geschlossen!
Abbildung 1: Zustand des Schlosses
Ein weiteres Indiz ist das in der URL aufgeführte Protokoll (http://... oder https://...).
Bei Fall (b) wird der Benutzer vom WWW-Browser im Rahmen eines mehrschrittigen Dialogs aufgefordert, das Zertifikat zu akzeptieren oder abzulehnen.
Da gemäß Signaturgesetz (SigG) (s. [BMBF99]) Zertifikate nach spätestens 5 Jahren ihre Gültigkeit verlieren, müssen diese Daten von Zeit zu Zeit aktualisiert werden.
Die Abfrage nach der Gültigkeitsdauer des Zertifikats stellt leider nicht jeder WWW-Browser. Manche Browser übernehmen die Gültigkeitsdauer der Zertifikate ohne Rückfrage.
3. Wissenswertes
Bekannter dürfte das Signaturgesetz (SigG) zur Regelung der Rahmenbedingungen für Informations- und Kommunikationsdienste unter dem Namen "Multimediagesetz" sein. Wissenswertes hierzu findet sich unter [BMBF99]. Dieses seit Herbst 1997 geltende Gesetz enthält als Artikel 3 das Gesetz zur digitalen Signatur (SigG).
Einen guten, allerdings sehr technischen Überblick über Krypto-Protokolle findet man in [Schm98].
3.1 Zertifikate und Zertifizierungsstellen (CAs)
Für das Internet sind folgende Zertifikattypen von Interesse:
SSL-Zertifikate dienen primär der Zertifizierung von WWW-Servern. PGP-Schlüssel und S/MIME der Zertifizierung von Benutzern oder Zertifizierungsstellen (CAs). Haupteinsatzgebiet von Benutzerzertifikaten ist die sichere Übertragung elektronischer Post (e-Mail). Jedoch lassen sich darüber auch FTP- oder Telnet-Verbindungen aufbauen, bei denen allein die Übermittlung des Benutzerzertifikats ausreicht. Das Anmelden ist dabei nicht mehr notwendig.
Eine erste Anlaufstelle für die Einrichtung einer eigenen Zertifizierungsstelle ist die Policy Certification Authority des Deutschen Forschungsnetzes, kurz DFN-PCA (s. [DFN99a]).
Die DFN-PCA zertifiziert derzeit nur untergeordnete CAs, jedoch keine Benutzer! Da sich viele CAs noch im Aufbau befinden, hat das DFN eine eigene, untergeordnete CA für Benutzer (die DFN-User-CA) eingerichtet, bei der man direkt seinen persönlichen Schlüssel zertifizieren lassen kann.
Auch die Rechenzentren in den Hochschulen bauen derzeit eigene CAs auf. Ein Blick auf deren Internetseiten kann sich als lohnend erweisen. Schließlich bringt die Ausstellung eines Zertifikats einen nicht unerheblichen bürokratischen Aufwand mit sich, was für das Ausnutzen kurzer Wege spricht.
Da voraussichtlich die meisten Hochschul-CAs als Zertifizierungsstelle das DFN-PCA nutzen, reicht es, wenn ein Benutzer einmal das DFN-PCA Wurzelzertifikat dem eigenen Browser bekanntmacht. Alle davon – sogar mehrstufig – abgeleiteten Zertifikate können damit verifiziert werden.
Im Falle der Bibliothek bedeutet dies, dass das Zertifikat ihres WWW-Servers auch dann anhand des DFN-PCA-Wurzelzertifikats geprüft werden kann, wenn die CA der Bibliothek das Rechenzentrum der Hochschule und wiederum das DFN_PCA die CA des Rechenzentrums ist.
3.2 Web-of-Trust
Der weltweite Verbund aller PGP-Key-Server bietet die derzeit effizienteste Möglichkeit der Veröffentlichung öffentlicher Schlüssel, da beim Versand einer Mail der öffentliche Schlüssel des Empfängers im Internet gesucht werden kann.
Eine digitale Unterschrift, z.B. einer Mail, ist ein Chiffrat des geheimen Schlüssels. Mit Hilfe des Public Key kann es somit jeder dekodieren und sich von der Echtheit des Dokuments bzw. des Absenders überzeugen.
Die Qualität des sog. "Web-of-Trust", d.h. also das Maß an Sicherheit und Vertrauenswürdigkeit im Internet, wächst mit der Anzahl der Personen und Einrichtungen, die sich solcher öffentlicher Schlüssel bedienen.
Da ein Schlüssel (aus welchen Gründen auch immer) ungültig geworden sein kann, findet man oft auch den Begriff der CRL = Certificate Revocation Lists. Diese Liste enthält die zur Zeit widerrufenen CA-Zertifikate. Ein Hauptgrund dürfte vermutlich sein, dass Benutzer ihren eigenen privaten Schlüssel vergessen haben oder dass dieser nicht mehr geheim ist. Das DFN empfiehlt jedem PGP-Benutzer, ein eigenes "Revocation Certificate" zu erzeugen und dieses an einem sicheren Ort aufzubewahren. Auf diese Weise kann man seinen öffentlichen Schlüssel auch dann widerrufen, wenn man einmal seinen privaten Schlüssel vergessen haben sollte. Benutzer können ihren Public Key grundsätzlich nur selbst widerrufen, es sei denn die zertifizierende CA verfügt über ein vorher erzeugtes "Revocation Certificate" des Benutzers (s.[DFN99c]).
Das DFN bietet eine Vielfalt an Informationen für Interessierte an, u.a. auch eine Mailingliste ([DFN99b]]. Für besonders Eilige sind auch Kurzanleitungen zur Erlangung eines PGP- und SSL-Server-Zertifikats aufgeführt (s. [DFN99d] bzw. [DFN99e]).
Aufgrund der strengen Auflagen an eine SigG-konforme Zertifizierungsstelle operiert die DFN-PCA momentan nicht im Sinne des Signaturgesetzes.
3.3 Verschlüsselungsverfahren
Die meisten WWW-Browser stammen aus den USA und unterliegen somit den dort geltenden Exportbestimmungen für Kryptoverfahren. Die maximale Schlüssellänge war daher bisher auf 56-Bit beschränkt. Erst seit Mitte Januar 2000 sind auch 128-Bit erlaubt.
Die SSL-Servererweiterung auf Basis von SSLeay (s. Kapitel 4) stammt jedoch aus Australien und fällt nicht unter diese Restriktionen. Es liegt also nicht an den SSL-Servern, wenn bezüglich der Effektivität der Verschlüsselung nicht bis an die derzeit möglichen Grenzen gegangen wird. Mit Browsern aus Ländern ohne Exportbeschränkung für Kryptoverfahren wäre auch eine noch bessere Verschlüsselung der Verbindung zwischen Browser und WWW-Server möglich.
Auch im Falle einer Lockerung der Exportbestimmungen sollte man sich nicht der Illusion hingeben, dass die beschriebenen Verfahren 100-prozentige Sicherheit bieten. Es gibt – wie fast bei jedem Sicherheitskonzept – immer noch Schlupflöcher und Angriffspunkte. Allerdings sind die aufgebauten Hürden so groß, dass nur in seltenen Fällen sicherheitsrelevante Informationen in die Hände Unbefugter gelangen können.
Der aufmerksame Leser hat sich bestimmt schon gefragt, wieso der Browser nicht direkt die Daten mit dem öffentlichen Schlüssel des WWW-Servers verschlüsselt, sondern dazu einen eigenen (zufälligen Sitzungsschlüssel) generiert. Die Begründung liefern die Verschlüsselungsverfahren. Es gibt zwei Sorten von ihnen – asymmetrische und symmetrische. Zu den asymmetrischen Verfahren zählen die Public-Key-Verfahren, d.h. bei der Verschlüsselung wird mit zwei Schlüsseln – einem öffentlichen zum Verschlüsseln und einem privaten zum Entschlüsseln – gearbeitet. Bei den symmetrischen Verfahren kommt nur ein Schlüssel zum Einsatz, den daher beide Seiten kennen müssen. Bei der EDV-Anwendung solcher Verfahren spielt die Rechenzeit eine große Rolle. Die symmetrischen Verfahren sind ca. um den Faktor 10 schneller als die asymmetrischen.
Mit diesem Hintergrundwissen ist das oben beschriebene, scheinbar umständliche Verfahren plötzlich sehr einsichtig.
Abbildung 2: Verschlüsselte Datenübertragung
Der WWW-Browser möchte die gesamte Datenmenge schnell verschlüsseln und bedient sich dazu des symmetrischen Verfahrens (1). Für den WWW-Server verschlüsselt er den dabei verwendeten Schlüssel (Sessionkey) mit Hilfe eines langsamen asymmetrischen Verschlüsselungsverfahren (2). Beim Dekodieren wird in umgekehrter Reihenfolge (3 und 4) vorgegangen.
Bei PGP-verschlüsselten Mails wird ebenfalls ein solches Hybridverfahren eingesetzt.
4. Was ändert sich für Betreiber eines WWW-Servers?
Die Umrüstung des eigenen WWW-Servers auf https unter Verwendung von SSL ist prinzipiell nicht sehr aufwendig. Man benötigt entweder das Basispaket SSLeay ([SSLe99]) oder OpenSSL ([OSSL99]).
SSLeay ist eine frei verfügbare Implementierung von Netscapes Secure Socket Layer (SSL) und bietet zahlreiche Funktionen zur Zertifikat-Verwaltung sowie verschiedene kryptographische Funktionen. Es wurde entwickelt von Eric A. Young und Tim Hudson.
Das OpenSSL-Projekt basiert auf SSLeay. Sein Ziel ist die Bereitstellung einer Programmierbasis zur Erstellung bzw. Erweiterung von Internetsoftware um sichere Verbindungen gemäß Secure Socket Layer (SSL v2/v3) und Transport Layer Security (TLS v1).
An der UB Karlsruhe wird der Apache-WWW-Server (s. [Apac99]) eingesetzt. Für ihn gibt es zwei Erweiterungen. Zum einen den auf SSLeay basierenden Patch oder das auf OpenSSL basierende Modul mod_ssl. An der UB Karlsruhe wurde der Server mit Hilfe des SSLeay-Patches im Mai 1999 umgestellt.
Die erforderlichen Schritte sind sehr gut in den aufgeführten iX-Artikeln ([Kelm97], [Reif96-98]) beschrieben. Der wichtigste Punkt ist die Deaktivierung der Server-Cachings.
Die Umstellung des WWW-Servers bildet jedoch nur die technische Basis. Anschließend ist abzuwägen, ob man den Zugriff mittels https (standardmäßig über Port 443) generell zuläßt oder – wie an der UB Karlsruhe praktiziert – diese aufwendigeren Verbindungen nur für die Anmeldung oder andere sicherheitsrelevante Transfers verwendet. Sichere Verbindungen sind für beide Seiten (Browser und Server) nicht so schnell wie unsichere.
Die vorhandenen (CGI-) Programme müssen dahingehend erweitert werden, dass alle kritischen Aufrufe von (CGI-) Programmen das sichere https-Protokoll nutzen. Falls auf den generierten HTML-Seiten nach einer Anmeldung (z.B. Kontoauszug nach erfolgter Anmeldung am Ausleihsystem) relative Links verwendet werden, muss mit <BASE HREF> dafür gesorgt werden, dass wieder das http-Protokoll verwendet wird. Alternativ sind anstelle relativer URLs absolute zu verwenden. Leider kann bei URLs der Protokollteil nicht unabhängig vom Rest geändert werden.
Für Benutzer mit WWW-Browsern, die nicht https-fähig sind, sollte sowohl eine unsichere als auch eine sichere Anmeldung angeboten werden.
4.1 https-Einsatz an der UB Karlsruhe
Abbildung 3: Beispiel "Anmeldung am Ausleihsystem"
Zur Anmeldung bei folgenden Diensten bietet die UB Karlsruhe ihren Kunden die herkömmliche unsichere Verbindung (http – in den HTML-Formularen rot hinterlegt) als auch die sichere Verbindung (https – grün hinterlegt) an:
Die sichere Anmeldung wird gerne genutzt, was man aus der positiven Benutzerresonanz seit Einführung dieser Funktionalität im Mai 1999 schließen kann.
Damals bestand an der Universität Karlsruhe noch nicht die Möglichkeit, das eigene unbeglaubigte Zertifikat vor Ort beglaubigen zu lassen. Da eine Beglaubigung einen nicht unerheblichen bürokratischen Aufwand bei der Zertifizierungsinstanz erfordert (bei Mail-Zertifikaten geht dies bis hin zur persönlichen Vorlage des Personalausweises), wurde bisher darauf verzichtet. Das Ziel der sicheren Übertragung von Daten über das Internet konnte schließlich auch mit dem unbeglaubigten Zertifikat erreicht werden.
Es gibt heute immer mehr Nutzer, die sich intensiv mit dieser Problematik auseinander setzen. So wurde das unbeglaubigtes Zertifikat bereits einige Male beanstandet. Außerdem trat in der Pilotphase mehrfach das Problem auf, dass das Zertifikat der UB Karlsruhe abgelaufen war. Auch diese Tatsache wurde direkt per Mail bemängelt. In beiden Fällen war die Verbindung wie oben erwähnt verschlüsselt und somit sicher. Die Benutzerhinweise machen jedoch deutlich, wie sensibel viele Internetnutzer beim Thema Sicherheit inzwischen sind. Daher wird die UB Karlsruhe in Zukunft beglaubigte Zertifikate einsetzen.
5. Fazit
Auch wenn auf Bibliotheken nicht die im Bankenbereich gültigen Sicherheitsstandards anzuwenden sind, so kann doch mit wenig Aufwand dem Bibliotheksbenutzer ein sehr hohes Maß an Datensicherheit geboten werden.
Das sogenannte "Web-of-Trust" und damit die Reichweite sicherer Kommunikation wächst mit der Zahl der Schlüssel und Zertifikate. Daher ist es an der Zeit, dass man sich auch im Bibliotheksumfeld mit dieser Thematik beschäftigt.
Literatur
[Apac99] Apache: "Apache-SSL" http://www.apache-ssl.com/
[BMBF99] Bundesministerium für Bildung und Forschung (BMBF): "Der Wegweiser zum Informations- und Kommunikationsdienste-Gesetz (IuKDG)" ; http://www.iid.de/iukdg/
[Dier96] Dierolf, Uwe: "Vom WWW-Katalog zur WWW-Ausleihe", Bibliotheksdienst Heft 3, 1996, S. 484-487
[DFN99a] DFN: "Policy Certification Authority (PCA) - Die Zertifizierungsinstanz für das Deutsche Forschungsnetz"
[DFN99b] DFN: "Mailingliste win-pca zur allgemeinen und offenen Diskussion zu allen Fragen der Zertifizierung" win-pca-request@pca.dfn.de
[DFN99c] DFN: "Erzeugen eines PGP-Revocation Certificate" http://www.pca.dfn.de/dfnpca/certify/pgp/revoke.html
[DFN99d] DFN: "Kurzleitfaden zur Benutzer-Zertifizierung - Persönliche PGP-Zertifikate von der DFN-User CA"http://www.pca.dfn.de/dfnpca/certify/pgp/instuse2.html
[DFN99e] DFN: "Leitfaden zur Server-Zertifizierung - Wie bekomme ich ein Zertifikat für meinen SSL-Server"http://www.pca.dfn.de/dfnpca/certify/ssl/server-howto/
[Kelm97] Kelm, Stefan: "Aufbau und Gültigkeit von Zertifizierungsinstanzen - Herrschende Richtlinien", iX, Heft 4, 1997, S.146-149
[OSSL99] OpenSSL-Projekt http://www.openssl.org/
[Reif96] Reif, Holger: "Schlüsselfertig - Secure Socket Layer: Chiffrieren und Zertifizieren mit SSLeay", iX, Heft 6, 1996, S.128-137
[Reif97] Reif, Holger: "Herr der Zertifikate - Zertifikatsmanagement und Online-Beglaubigungsstellen mit SSLeay", iX, Heft 4, 1997, S.176-183
[Reif98] Reif, Holger: "Winnetou und Old SSLeay", iX, Heft 7, 1998, S.128-132
[Schm98] Schmeh, Klaus: "Einer paßt - Krypto-Protokolle für das Internet", iX, Heft 12, 1998, S.113-117
[SSLe99] SSLeay and SSLapps FAQ http://www.psy.uq.oz.au/~ftp/Crypto/
Abkürzungsverzeichnis
CA Certification Authority (Zertifizierungsinstanz)
CRL Certificate Revocation List (Widerrufsliste)
DFN Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
PIN Personal Identification Number
RA Registration Authority (Registrierungsinstanz)
HTTP Hypertext Transfer Protocol
HTTPS Secure Hypertext Transfer Protocol
S/MIME Secure/Multipurpose Internet Mail Extensions
SSL Secure Socket Layer
Dipl.-Inform. Uwe Dierolf
Tel. 0721/608-6076
eMail: Uwe.Dierolf@ubka.uni-karlsruhe.de
http://www.ubka.uni-karlsruhe.de/~uwe