Entwurf eines Konzepts für eine Zertifizierungsstelle für die Freie Universität Berlin

Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Kapitel 1 Motivation

Aufgabe der „Allianz von Technik und Datenschutz“ (Simitis) ist vor allem die Entwicklung und Verbreitung von ‘privacy enhancing technologies’. Sie soll

datenschutzfördernde Sicherheitsarchitekturen anbieten

— STEFAN WALZ [Wal97, S. 28]

Ohne Verschlüsselung gibt es bei der Kommunikation per E-Mail keine Vertraulichkeit. Als Beleg müßten die beiden folgenden Zitate eigentlich ausreichen, um jeden Skeptiker davon zu überzeugen, daß abgehört wird:

12,6% der 1000 führenden Unternehmen in den USA haben Eingriffe in ihr E-Mail-System entdeckt; mindestens jede zehnte Nachricht werde unbefugt abgefangen oder mitgelesen – laut PGP-Entwicklern ist es sogar jede vierte [CT-98a]

Der US-Geheimdienst NSA hört europaweit E-Mails ab [Ebe98, Wri98a, S. 19] und betreibt ein weltweites Abhörnetz, das vor allem gegen nicht-militärische Ziele gerichtet ist [Hag97] Dabei kooperieren EU und USA bei diesem weltweiten Überwachungssystem [STA97]

Und während sich der Zwischenbericht des EU-Parlamentes noch über das NSA-Abhörnetz empört

“If even half of these allegations are true then the European Parliament must act to ensure that such powerful surveillance systems operate to a more democratic consensus now that the Cold War has ended. ... No proper Authority in the USA would allow a similar EU spy network to operate from American soil without strict limitations, if at all. . . . [The] European Parliament is advised to set up appropriate independent audit and oversight porocedures and that any effort to outlaw encryption by EU citizens should be denied until and unless such democratic and accountable systems are in place, if at all.” [Wri98b]

plant die EU ziemlich im Verborgenen und bislang kaum beachtet schon etwas Vergleichba- res [SH98b].

Ohne Verschlüsselung ist nicht nur die Vertraulichkeit der elektronischen Kommunika- tion gefährdet, es ist, wie z.B. Damker et al. demonstrieren [DFS96] – und wie es

vermutlich viele Internet-Nutzer bereits selber erlebt haben (Mail von Helmut Kohl

<kohl@kanzleramt.de> ...) – auch keine sichere Feststellung des Urhebers (Authen- tizität) oder der Unverfälschtheit einer Nachricht (Integrität) möglich.

Und dennoch fehlt es immer noch an der unterstützenden Infrastruktur für den breiten Einsatz von geeigneten Verschlüsselungsverfahren. Was Rüdiger Grimm 1997 beklagte, ist, wenn auch vielleicht in etwas abgeschwächter Form, immer noch aktuell:

„Es werden global kompatible Zertifizierungsinfrastrukturen gebraucht, in denen jeder Bürger jeden öffentlichen Signaturschlüssel glaubwürdig verifizieren kann, ohne vor- her mit seinem Besitzer einen bilateralen Prüfvorgang durchlaufen zu müssen. [...] Warum aber gibt es diese Zertifizierungsinfrastruktur nicht längst, wenn sie doch so dringend gebraucht wird? Die Verfahren sind seit fast zehn Jahren bekannt. Hier gibt es ein Henne-Ei-Problem, indem die Zertifizierungsinfrastruktur einerseits und die Sicher- heitsanwendungen andererseits aufeinander warten. . . . Unternehmer sind nicht bereit, in den Aufbau von Zertifizierungsinstanzen zu investieren, wenn man mit den neuen Signaturschlüsseln nichts anfangen kann: Sie warten darauf, daß es . . . interessante An- wendungen gibt, die eine Nachfrage nach einer Schlüsselverwaltung erzeugen. Umge- kehrt investiert aber kein Anwender in teure Zusatzfunktionen in die schon bestehenden Internetanwendungen für Email und Word Wide Web [sic], wenn dafür Schlüssel ge- braucht werden, die es nirgends gibt ... .“ [Gri97, S. 217]

Die Freie Universität Berlin will im Rahmen ihrer Möglichkeiten mithelfen, durch den Auf- bau einer eigenen Zertifizierungsstelle diesen circulus vitiosus zu durchbrechen. Das hier vorliegende Konzept soll ein erster Schritt dazu sein.

Auch als Forschungseinrichtung muß die Universität ein Interesse daran haben, Know-How im Umgang mit Public-Key-Verschlüsselung und elektronischen Signaturen zu sammeln. So hat die EU 1998 den Auftrag für die Einrichtung und den Betrieb einer Zertifizie- rungsstelle ausgeschrieben, die die elektronische Einreichung von Geboten und Anträgen zu Forschungs- und Entwicklungs-Programmen der EU ermöglichen soll. [EK98] Ände- rungswünsche an den Einträgen in der RIPE-Datenbank sollen in Zukunft ebenfalls mit PGP authentifiziert werden. Ein Internet-Standard dafür existiert bereits als Entwurf [Zsa98].

Sogar die neue Bundesregierung verschließt sich diesen Vorzügen nicht, nachdem der vorige Innenminister noch ein vehementer Verfechter staatlicher Abhörbefugnisse war: Mit der „In- itiative des Bundesministeriums für Wirtschaft und Technologie für mehr Sicherheit in der Informationsgesellschaft“1will sie „. . . Projekte durch[zu]führen, u.a. um die Transparenz technischer Vorgänge zu verbessern und dadurch die Nutzer zu mehr Eigenverantwortlich- keit anzuregen. [...] Gerade . . . bei den privaten Internet-Nutzern besteht . . . noch erheblicher Informationsbedarf [... ]“ [Bun99b]

Erfreulicherweise kann jede Sicherungsinfrastruktur für digitale Signatursysteme, die tech- nisch zuverlässige Signierschlüssel bereitstellt, auch dazu benutzt werden, Verschlüsselungs- schlüssel (Konzelationsschlüssel) sicher auszutauschen. [HP96] Insofern hilft eine Zertifizie- rungsinfrastruktur, den Nutzern im Sinne ihres informationellen Selbstbestimmungsrechtes Hilfsmittel und Verfahren an die Hand zu geben, mittels derer sie die Authentizität und Inte- grität, aber auch die Vertraulichkeit ihrer Kommunikation selber sicherstellen können.

Ein weiterer Grund, sich für den verstärkten Gebrauch von Verschlüsselung einzusetzen und die Voraussetzungen für einen solchen auf breiter Basis zu schaffen, liegt in der Langlebig- keit einmal verschickter E-Mails begründet. Festplattenplatz ist billig geworden, und so wer- den elektronische Mitteilungen (auch unwichtige) länger aufgehoben als früher vergleichba- re Notizen oder Briefe, die irgendwann aus Platzgründen aussortiert wurden. Heute können solche Mitteilungen nicht nur in großer Zahl archiviert, sondern bei Bedarf auch blitzschnell nach Suchkriterien durchsucht und die Ergebnisse dann ohne größere Umstände elektronisch weitergeleitet oder auf Knopfdruck einem großen Empfängerkreis zugänglich gemacht wer- den.

Hinzu kommt noch (zumindest bei der Kommunikation mit öffentlichen Einrichtungen) die Gefahr, daß Dritte über Akteneinsichtsregelungen Einblick in die persönlichen Schreiben bekommen könnten [Mee99] – ein Umstand, dessen sich sicher nur die wenigsten von uns bewußt sind, wenn sie mit einer Behörde Schrift- bzw. E-Mailverkehr führen. Dieser Punkt betrifft uns in der Bundesrepublik (noch?) nicht in gleichem Maße wie beispielsweise die US-Amerikaner, die schon lange ein Akteneinsichtsgesetz (“Freedom of Information Act”, FOIA) haben, doch 1998 hat mit Brandenburg das erste Land der Bundesrepublik ein ent- sprechendes Gesetz [AIG98] erlassen, und auf Bundesebene hat die neue Regierungskoali- tion die Einführung eines FOIA in Deutschland als Ziel in ihrem Koalitionsvertrag2 festge- schrieben.

Es gibt also auch in Deutschland vermutlich bald noch einen Grund mehr, immer öfter ver- schlüsselt zu mailen.

„Sicherheit für alle - Bürgerrechte stärken“, Punkt 13 „Beteiligungsrechte“

Kapitel 2 Theoretische Grundlagen

Die Schlüssel werden golden und silbern gemalt. Der goldene . . . bedeutet die Gewalt, zu lösen und zu öffnen.

Der silberne . . . versinnbildet die Gewalt, zu binden und zu schließen.

— Bruno B. Heim , Wappenbrauch und Wappenrecht in der Kirche, zitiert nach [Rab70, S. 214]

Nachfolgend werden die theoretischen Grundlagen der Public-Key-Verschlüsselung sehr kurz umrissen. Eine gewisse gewisse Vertrautheit mit Public-Key-Verfahren ist daher von Vorteil beim Lesen dieser Arbeit. Einen guten, verständlichen Überblick über die grundle- genden Mechanismen bietet die Arbeit von Gehring [Geh98].

2.1 Public-Key-Verschlüsselung

Diffie und Hellman stellten 1976 ein für die Kryptographie revolutionäres Verfahren vor [DH76], das sie zurecht mit “New Directions in Cryptography” überschrieben.1 Sie brachen darin mit den bis dahin gängigen Verschlüsselungsverfahren, bei denen Sender und Empfän- ger beide denselben geheimzuhaltenden Schlüssel sowohl zum Ver- als auch zum Entschlüs- seln benutzen (sogenannte single key oder auch ‘symmetrische’ Verschlüsselungsverfahren). Sie schlugen vielmehr vor, daß Sender und Empfänger jeweils ein Schlüsselpaar erzeugen, der aus zwei Komponenten besteht, die in einem bestimmten mathematischen Bezug zuein- ander stehen.

Soll nun eine Nachricht vertraulich übermittelt werden, so verschlüsselt der Absender sie mit der einen Komponente des Empfängerschlüssels, die dafür öffentlich bekannt sein muß

– dem öffentlichen Schlüssel oder auch public key. Entschlüsseln kann diese Nachricht nun nur derjenige, der über die andere Komponente des Schlüssels verfügt. Diese sollte al- so geheimgehalten werden, damit kein Dritter unbefugt die verschlüsselte Nachricht lesen kann. Diese geheime Komponente wird als secret key oder auch als private key bezeichnet. Zur Veranschaulichung wird oft das Bild eines Briefkastens herangezogen. Der Absender kann eine Nachricht hineinwerfen (= verschlüsseln), sie aber nicht mehr wieder herausholen

(= entschlüsseln). Das kann nur der Inhaber des passenden „privaten“ Schlüssels zu diesem Briefkasten – eben der Inhaber des Secret Keys. Aufgrund der unterschiedlichen Schlüssel, die zum Ver- und zum Entschlüsseln verwendet werden, spricht man statt von Public-Key- Verschlüsselung gelegentlich auch von „asymmetrischer“ Verschlüsselung.

Auf diese Weise muß nur jeder seinen öffentlichen Schlüssel bekannt geben, und schon kön- nen ihm alle Leute, auch wildfremde, die ihm nie zuvor persönlich begegnet sind, verschlüs- selt und damit vertraulich Nachrichten zukommen lassen. Das ist ein wesentlicher Fortschritt gegenüber allen Verfahren, die man bis dahin kannte, bei denen jedes Sender-Empfänger- Paar einen separaten Schlüssel ausmachen mußte – bei einer größeren Zahl von Kommuni- kationsteilnehmern ein fast unlösbares Unterfangen. Bei den Public-Key-Verfahren hingegen ist es egal, ob 10 oder 10.000 Menschen miteinander kommunizieren wollen, jeder muß nur (s)einen öffentlichen Schlüssel bekannt geben, quasi seinen „Briefkasten aufhängen“, um in diesem Bild zu bleiben.

Es gibt dabei nun nur ein kleines, anderes Problem: Woran erkennt man, ob ein Briefkasten wirklich zu demjenigen gehört, dessen Name darauf prangt? Oder, auf die Verschlüsselung bezogen: Wie kann ein Absender einer Nachricht sicher sein, daß er wirklich den authenti- schen öffentlichen Schlüssel des beabsichtigten Empfängers vorliegen hat und nicht irgend- einen anderen Schlüssel, den ihm jemand untergeschoben hat? Bei einer großen Zahl von (potentiellen) Kommunikationsteilnehmern kann man sich nicht mehr mit jeder oder jedem persönlich treffen, um den öffentlichen Schlüssel des jeweils anderen sozusagen „aus erster Hand“ zu erhalten. Man spricht in diesem Zusammenhang auch vom „Schlüsselverteilungs- problem“, das sich glücklicherweise durch organisatorische Vorkehrungen stark reduzieren läßt (s. 2.3).

Ungünstigerweise sind die Rechenoperationen, auf denen Public-Key-Verfahren üblicher- weise aufbauen, sehr aufwendig und dieses Verfahren entsprechend langsam, besonders, wenn längere Nachrichten damit verschlüsselt werden sollen. Auch lassen sich die Grund- operationen für Public-Key-Verfahren, das Rechnen mit sehr großen Zahlen (mehr als 100 Stellen), nicht so gut auf einem Microprozessor ausführen wie die Basisoperationen, aus de- nen einige der besten herkömmlichen, symmetrischen Verschlüsselungsverfahren aufgebaut sind. (Beispiele für bekannte Vertreter dieser Verfahren sind der Data Encryption Standard, DES, und der International Data Encryption Algorith, IDEA. [DES77, LM91]) Um nun den Vorteil der Public-Key-Verschlüsselung – einfachere Schlüsselverteilung – mit den Vorzü- gen der symmetrischen Verschlüsselung – sehr schnell und besonders effizient in Hardware realisierbar – zu kombinieren, bedient man sich einer Kombination aus beiden: Es wird ein zufälliger Sitzungsschlüssel (session key, quasi ein „Einmal-Schlüssel“) erzeugt, der nur für die symmetrische Verschlüsselung einer einzigen Nachricht verwendet wird. Die vertrau- lich zu übermittelnde Nachricht wird z.B. mit DES unter diesem Sitzungsschlüssel chiffriert. Der Sitzungsschlüssel selber ist typischerweise nur wenige Bytes groß und wird nun wie- derum selber mittels asymmetrischer Verschlüsselung unter Verwendung des Public-Keys der beabsichtigten Empfängerin der Nachricht verschlüsselt. (Das geht trotz Public-Key- Verschlüsselung schnell, weil der Session-Key so kurz ist.) Beide verschlüsselten Informatio- nen, der Chiffretext der ursprünglichen Nachricht und der des zu ihrer Verschlüsselung ver- wendeten Einmalschlüssels, werden nun zusammen an die Empfängerin übermittelt. Diese entschlüsselt zuerst den Public-Key-verschlüsselten Session-Key, wozu sie ihren geheimen Schlüssel benutzt. Keine andere Person, auch kein „Lauscher“, könnte auf diese Weise den Sitzungsschlüssel ermitteln, da ja – sorgfältigen Umgang mit dem Private-Key vorausgesetzt

– niemand sonst über den zum öffentlichen Schlüssel der Empfängerin korrespondierenden

geheimen Schlüssel verfügt. Die Empfängerin erhält auf diese Weise den Sitzungsschlüs- sel und kann dann mit dessen Hilfe die herkömmlich verschlüsselte Nachricht wieder lesbar machen. Eine solche Kombination aus herkömmlicher und Public-Key-Verschlüsselung be- zeichnet man auch als „Hybrid“-Verfahren.

Die bekannteste konkrete Umsetzung des Public-Key-Ansatzes dürfte das RSA-Verfahren, sein [ARS78], das nach seinen drei Erfindern Ronald Rivest, Fiat Shamir und Leonard Ad- leman benannt ist und das die Grundlage für die Arbeit der gleichnamigen Firma (RSA Data Security, heute eine Tochter von Security Dynamics) darstellt. Beispiele für Pro- gramme, in denen Public-Key-Verschlüsselung vorkommt, und zwar meist als Teil einer Hybrid-Verschlüsselung, also in Kombination mit symmetrischen Verschlüsselungsverfah- ren, sind das Verschlüsselungsprogramm Pretty Good Privacy (PGP) [Zim95] und alle WWW-Browser, die die verschlüsselte Übertragung via Secure Socket Layer (SSL) [FKK96] unterstützen.

2.2 Digitale Signaturen

Manche der Public-Key-Verschlüsselungsverfahren verfügen über eine zusätzliche Eigen- schaft, die sie noch für einen anderen Zweck einsetzbar macht: Ver- und Entschlüsselungs- operation sind kommutativ, d.h. das Resultat ist dasselbe, egal ob erst ver- und dann ent- schlüsselt wird oder umgekehrt. Man kann also auch eine Nachricht zuerst mit dem geheimen Schlüssel „entschlüsseln“ und sie danach mit dem öffentlichen Schlüssel „verschlüsseln“ und erhält am Ende auch bei dieser Ausführungsreihenfolge wieder den ursprünglichen Klartext. Dies kann man sich zu Nutze machen, um die Urheberschaft eines Dokumentes zu kenn- zeichnen, es quasi zu „unterschreiben“: Der Absender, der eine Nachricht digital unterzeich- nen möchte, verschlüsselt diese mit seinem Private-Key, auf den niemand außer ihm Zugriff hat. Das Ergebnis ist eine Nachricht, die aussieht, als wäre sie verschlüsselt. Sie erweckt aber nur den Anschein als ob, denn jeder kann mit dem Public-Key des Absenders diese

„Verschlüsselung“ wieder rückgängig machen und erhält dann den Klartext. Durch die Ent- schlüsselungsoperation mit dem öffentlichen Schlüssel erfolgt quasi eine Prüfung der Unter- schrift bzw. des vermuteten Absenders. Ergibt diese Operation sinnvollen Klartext, so kann die vorhergehende Verschlüsselungsoperation nur mit dem korrespondierenden Private-Key durchgeführt worden sein – und auf den sollte, normalen Umgang mit geheimen Schlüs- seln vorausgesetzt, nur der Inhaber zugreifen können. Also muß diese Nachricht von ihm stammen. Man könnte sagen, er hat sie mit seinem geheimen Schlüssel signiert.

Da, wie bereits in 2.1 erwähnt, Public-Key-Verfahren ziemlich rechenaufwendig sind, zu un- terschreibende Nachrichten aber mitunter auch sehr groß werden können, greift man auch hier wieder zu einem Trick, um nicht nur möglichst kurze Datenfolgen mit dem Public-Key- Verfahren bearbeiten zu müssen: Statt eine ganze, möglicherweise sehr große, Nachricht zu mit dem geheimen Schlüssel zu „verschlüsseln“, um sie zu signieren, wird eine Art Prüf- summe, eine mathematische „Kurzfassung“ der Nachricht verschlüsselt, die dann zusammen mit der eigentlichen Nachricht übermittelt wird. Dazu bedient man sich sogenannter Hash- Funktionen – man spricht auch von message digests –, die große Nachrichten mit beliebiger Länge auf eine sehr kurze Bitfolge abbilden können. Der Empfänger einer auf diese Wei- se signierten Nachricht muß nun mehrere Schritte ausführen, um die digitale Signatur zu der Nachricht prüfen zu können: Der Text der eigentlichen Nachricht wird von der ange- fügten Signatur getrennt. Dann wird über diesem Text nach demselben Verfahren wie beim

Absender die Prüfsumme berechnet. Das Ergebnis dieser Berechnung wird mit der Zahl ver- glichen, die man erhält, indem man die signierte Prüfsumme, die ebenfalls Bestandteil der übermittelten Nachricht war, mit dem Public-Key des Absenders „entschlüsselt“. Sind beide Zahlen identisch, heißt das, daß der Absender die Hash-Funktion auf genau den Text ange- wendet haben muß, der auch beim Empfänger (zusammen mit der Signatur) angekommen ist. Weicht hingegen die vom Empfänger ermittelte Prüfsumme von der ab, die der Absender als Signatur mit der Nachricht mitgeschickt hat, so ist entweder die Nachricht unterwegs ver- ändert worden oder zum Prüfen der Signatur wurde der falsche Public-Key verwendet, und die Nachricht hat einen anderen Urheber.

Um außerdem noch erkennen zu können, wann ein Dokument auf diese Weise digi- tal unterschrieben wurde, wird außer der Prüfsumme meistens noch ein Zeitstempel mit„verschlüsselt“. Dadurch läßt sich dann beim Empfänger auch erkennen, ob eventuell eine alte Nachricht von einem Angreifer erneut eingespielt wurde (eine sog. replay attack).

Auch für die Prüfung einer digitalen Signatur ist es unerläßlich, daß der Empfänger den authentischen Schlüssel des vermuteten Absenders vorliegen hat, denn nur dann kann er mit Gewißheit prüfen, ob eine Nachricht von dieser Person stammt. Damit sind wir wieder beim Problem der verläßlichen Verteilung der authentischen öffentlichen Schlüssel angelangt.

2.3 Zertifizierungsstellen

Die direkte Übergabe eines Public-Keys bei einem persönlichen Kontakt (z.B. auf einer Dis- kette) oder die Übermittlung durch einen vertrauenswürdigen Kurier oder über eine gesi- cherte Standleitungsverbindung ist die naheliegendste Art und Weise, den authentischen öf- fentlichen Schlüssel eines Kommunikationspartners zu erhalten. Sie entspricht dem in [ISO] beschriebenen Verfahren Public-Key Distribution without a Trusted Third Party – Public-Key Transport Mechanism 1: using an Authenticated Channel.

Die Übermittlung des Public-Keys auf unsicherem Wege, z.B. per E-Mail, oder der Abruf von einem Keyserver oder einer Homepage mit anschließender Überprüfung beispielsweise durch telefonischen Vergleich des Schlüssels oder seiner kryptographischen Prüfsumme (bei Schlüsseln sagt man auch “Fingerprint” dazu; das ist letztlich nichts anderes als der Hash- Wert oder der message digest des betreffenden Schlüssels) analog zu Public-Key Transport Mechanism 2: Authentication using a Second Channel [a.a.O.] ist eine weitere – einfache- re und daher häufigere – Art und Weise des authentischen Schlüsselaustausches. Darunter fällt auch der Austausch des Fingerprints auf Visitenkarten bei einem direkten persönlichen Kontakt (= der zweite, authentische Kommunikationskanal) o.ä. und das anschließende Ver- gleichen dieses Fingerprints mit der errechneten Prüfsumme des via unsicherem Kanal er- haltenen Schlüssels.

Aber auch diese Vorgehensweise ist nicht immer praktikabel; oft wird man mit neuen, frem- den Kommunikationspartnern Public-Key-gesichert kommunizieren wollen, mit denen ein direkter Kontakt (vorerst) u.U. nicht möglich ist und deren Stimme man nicht – oder nicht gut genug – für eine telefonische Überprüfung des Fingerprints kennt.

In diesem Fall kommen die Zertifizierungsstellen (engl. certification authorities – CAs) ins Spiel:

The introduction of a CA reduces the problem of authentic user public key dis- tribution to the problem of authentic distribution of the CA’s public key, at the expense of a trusted center (the CA). [ISO]

Eine Zertifizierungsstelle stellt digitale Bestätigungen (Zertifikate, siehe 2.4) aus. In ihnen bestätigt sie mit ihrer digitalen Signatur die Bindung eines bestimmten Public-Keys (und damit implizit auch des zugehörigen Private-Keys) an eine Person, Institution oder Instanz (die beispielsweise auch ein Rechner sein kann), die in dem Zertifikat namentlich benannt wird. Die Zertifizierungsstelle bietet damit also einen Dienst ganz ähnlich einer notariellen Beglaubigung dafür, daß ein bestimmter Public-Key und eine bestimmte Person zusammen- gehören.

Es wird dadurch eine Komplexitätsreduktion möglich: statt vieler individueller Public-Keys muß nur noch der öffentliche Schlüssel der Zertifizierungsstelle authentisch verteilt werden. Liegt er einer Person vor, kann diese mit seiner Hilfe die digitalen Unterschriften der Zertifi- zierungsstelle unter jedem der von ihr ausgestellten Zertifikate überprüfen und sich damit der Echtheit und Unverfälschtheit aller von ihr ausgestellten Zertifikate vergewissern. Stimmt die Unterschrift, dann kann aus dem betreffenden Zertifikat der öffentliche Schlüssel der darin genannten Person abgelesen werden. Allerdings muß man dafür dem Aussteller des Zerti- fikates, also der betreffenden CA, dahingehend vertrauen, daß sie immer korrekt zertifiziert und keine falschen Bestätigungen ausstellt. Hat man dieses Vertrauen in die Arbeit der CA nicht, so bringt die Verschiebung des Schlüsselverteilproblems auf den CA-Schlüssel keinen wirklichen Vorteil.

Sehr wichtig, ja geradezu essentiell für die Arbeit einer Zertifizierungsstelle ist also ihre Glaubwürdigkeit bei möglichst vielen Nutzern. Nur wenn die Anwender bereit sind, sich auf die Bestätigung eines fremden öffentlichen Schlüssels durch die betreffende CA zu verlassen, hat diese eine Arbeitsgrundlage. Also muß es im Interesse der Zertifizierungsstelle sein, alles zu tun, um sich ihre entsprechende Reputation zu erhalten – oder eine solche gegebenenfalls auch erst zu erarbeiten (siehe dazu auch 4.16.2).

Im einzelnen läßt sich der Vorgang der Public-Key-Zertifizierung durch eine Zertifizierungs- stelle in die folgenden Teilschritte gliedern:

Erzeugung eines Schlüsselpaares (beim Zertifikatnehmer selbst oder in der Zertifizie- rungsstelle)

Registrierung und Identifizierung des Zertifikatnehmers direkt bei der CA oder in einer Außenstelle von ihr (im letzteren Fall spricht man auch von einer Registrierungsstel- le, registration authority, RA), ggf. erfolgt dort auch die Übergabe einer Kopie des öffentlichen Schlüssels vom Zertifikatnehmer an die CA/RA

gegebenenfalls: Übermittlung der Daten aus dem Zertifizierungsantrag von der RA an die Zertifizierungsstelle

Zertifizierung des Schlüssels (sofern alle Voraussetzungen dafür wie Schlüssellänge, eindeutiger Name des Schlüsselinhabers usw., erfüllt sind)

Aushändigung oder Übermittlung des Zertifikates an den Schlüsselinhaber

Veröffentlichung des Zertifikates durch die Zertifizierungsstelle mittels geeigneter Verzeichnis- oder Verteildienste

Hinzu kommen können später noch Dienste wie die Re-Zertifizierung eines Schlüssels, wenn ein bereits erteiltes Zertifikat abzulaufen droht, oder auch die Sperrung des Zertifikates, wenn entsprechende Gründe dafür vorliegen.

Nicht jede Zertifizierungsstelle muß alle diese Tätigkeitsfelder abdecken; es ist gut mög- lich, daß sich manche Stellen auf einen Teil dieser Aufgaben beschränken und sie andere Teilaufgaben, beispielsweise den Betrieb eines Verzeichnisdienstes, an Partnerunternehmen oder andere Anbieter delegieren. Die Zertifizierung von Schlüsseln als zentraler Tätigkeits- bereich einer Zertifizerungsstelle wird allerdings immer dazugehören.

Einrichtungen, die nicht nur Zertifizierungsdienste anbieten, sondern die beispielsweise zu- sätzlich auch Schlüssel für Nutzer generieren, Sicherungskopien geheimer Kundenschlüssel verwahren oder Zeitstempeldienste offerieren, werden häufig auch als Trustcenter oder auch als Trusted Third Party (TTP), also als ein „vertrauenswürdiger Dritter“ bezeichnet (siehe dazu auch 4.16.1). Ihnen muß, im Unterschied zu einer reinen Zertifizierungsstelle, auch der Zertifikat nehmer – also derjenige, dessen Schlüssel zertifiziert wird – Vertrauen entge- genbringen, denn er muß sich darauf verlassen, daß das Trustcenter wie zugesichert nach der Schlüsselerzeugung und -aushändigung alle Spuren des geheimen Schlüssels vernich- tet bzw. daß das Trustcenter die hinterlegte Sicherheitskopie des Private-Key auch wirklich geheimhält.

2.4 Public-Key-Zertifikate

2.4.1 Funktion

Public-Key-Zertifikate stellen die Verbindung her zwischen einer Identität (einer Person oder einer Instanz) und einem öffentlichen Schlüssel. Indirekt wird damit aufgrund des Zusam- menhangs zwischen öffentlichem und geheimem Schlüssel auch ein Bezug zwischen Iden- tität und Secret-Key hergestellt. Zertifikate helfen dabei, auf unsicheren Transportwegen öf- fentliche Schlüssel authentisch auszutauschen. Derartige Zertifikate sind eine wichtige Vor- aussetzung/ein wichtiges Hilfsmittel beim Einsatz von Public-Key-Kryptographie.

2.4.2 Allgemeiner Aufbau

Public-Key-Zertifikate enthalten mindestens einen öffentlichen Schlüssel, den Namen (die Identität) der betreffenden Person oder Instanz und eine digitale Signatur, die den Urheber dieser Bestätigung nachprüfbar macht und zugleich unbemerkte Modifikationen des Zertifi- kates verhindert (Authentizitäts- und Integritätsschutz). Darüberhinaus können Public-Key- Zertifikate noch diverse andere zusätzliche Bestandteile umfassen wie etwa

Seriennummer des Zertifikates

Bezeichnung des Schlüssels, der zum Signieren benutzt wurde Algorithmus, der zum Signieren des Zertifikates benutzt wurde

Algorithmus und Parameter, mit denen der zertifizierte Schlüssel benutzt werden soll Angaben, zu welchen Zwecken der zertifizierte Schlüssel eingesetzt werden darf

Gültigkeitsdauer bzw. frühestes Gültigkeitsdatum sowie Verfallsdatum des Zertifikates

zusätzliche Angaben über den Zertifikatnehmer, z.B. zu dessen Beruf, Qualifikation, Zulassungen usw.

Haftungsbeschränkungen oder -obergrenzen

Alternative Namen oder Kommunikationsadressen des Zertifikatausstellers Alternative Namen oder Kommunikationsadressen des Zertifikatnehmers Verweise auf Zertifikate für den Unterschriftenschlüssel des Ausstellers

Verweise auf Sperrlisten (siehe 2.5), auf denen dieses Zertifikat gegebenenfalls geführt wird

Verweise auf Möglichkeiten zur Online-Abfrage des Zertifikatstatus’

Konkrete Beispiele verbreiteter Zertifikat-Formate werden im nächsten Kapitel in Abschnitt

2.5 Widerrufslisten

Es sind Situationen denkbar, in denen ein Zertifikataussteller noch während der Gültigkeits- dauer eines von ihm ausgestellten Zertifikates die darin gegebene Bestätigung für ungül- tig erklären möchte, beispielsweise weil im Nachhinein bekannt wurde, daß das Zertifikat vom Zertifikatnehmer unter Angabe falscher Daten (Name usw.) erschlichen wurde oder weil der zum zertifizierten öffentlichen Schlüssel gehörende geheime Schlüssel einem An- greifer in die Hände gefallen („kompromittiert“) ist. Zu diesem Zweck werden Zertifikat- Widerrufslisten verwendet (certificate revocation lists, CRLs), auch ‘Sperrlisten’ genannt. Auf ihnen werden üblicherweise die Seriennummern derjenigen Zertifikate einer Zertifizie- rungsinstanz aufgeführt, die für ungültig erklärt werden und deren regulärer, im Zertifikat angegebener Gültigkeitszeitraum noch nicht abgelaufen ist. (Nach Ablauf dieses Zeitraumes besitzt das Zertifikat in jedem Fall keine Gültigkeit mehr und muß daher auch nicht weiter auf der Sperrliste geführt werden.)

Diese Sperrlisten werden, genau wie die Zertifikate, von der ausgebenden Stelle digital si- gniert, um Verfälschungen erkennen zu können. In der Regel enthalten sie zusätzlich einen Zeitstempel und eine Angabe, wann die nächste Aktualisierung dieser Sperrliste stattfindet. (Anhand dieser Daten läßt sich gegebenenfalls erkennen, ob eine veraltete Version der Liste vorliegt.)

Vergleichen lassen sich solche Sperrlisten am ehesten mit den Listen mit Seriennummern ge- stohlener oder in Lösegeldzahlungen verwendeter Geldscheine oder mit Listen der Nummern gestohlener und deshalb gesperrter Sparbücher, Schecks oder Kreditkarten.

Die Zertifikat-Sperrlisten werden ganz analog zu den genannten Beispielen aus dem Ge- schäftsleben verwendet: Jemand, der sich auf ein Zertifikat zur Authentifizierung eines öf- fentlichen Schlüssels verläßt, sollte zuvor unbedingt auch die entsprechende Widerrufsliste des betreffenden Zertifikatausstellers konsultieren und sich vergewissern, daß das fragliche Zertifikat dort nicht aufgeführt, also gesperrt wurde.

Sperrlisten haben unter anderem den Nachteil, daß sie immer eine gewisse zeitliche „Un- schärfe“ aufweisen: Ein Dritter, der sich auf ein Zertifikat verlassen will, muß u.U. das Er- scheinen der nächsten Ausgabe der betreffenden Sperrliste abwarten, um ganz sicher gehen zu können, daß das Zertifikat nicht in der Zeit seit dem Erscheinen der vorigen Widerrufsliste gesperrt wurde. Als eine Ergänzung bzw. eine Alternative zu Sperrlisten, die diesen Nachteil vermeidet, wurde daher das Verfahren erdacht, den Widerrufstatus eines Zertifikates onli- ne genau in dem Moment abzufragen, in dem der Schlüssel aus dem Zertifikat verwendet werden soll. Für diese Anfrage wird die Seriennummer des fraglichen Zertifikates an die Anfrage-Schnittstelle der Zertifizierungsinstanz übermittelt, die daraufhin als Antwort „gül- tig“ oder „ungültig“ liefert.

2.6 Zertifizierungsrichtlinien („Policy“)

„Das Problem der Zertifizierung öffentlicher Schlüssel läßt sich in folgenden Fragen zusammenfassen: Wer zertifiziert? Wer zertifiziert den Zertifizierer? Nach welchen Regeln und Richtlinien wird zertifiziert? Was wird zertifiziert?

– Auf jeden Fall die Bindung zwischen Person, Name und Schlüssel. Aber auch die Qualität der Schlüssel, die zugehörige Zertifizierungskette, die Zertifizie- rungsregeln? Der soziale Bezug, Rollen und Zugriffsrechte? Welche Dienste gehören zu einer Zertifizierung? Auch die Schlüsselgeneration? [Die] Rekon- struktion verlorener Schlüssel (und wie das)? Widerruf mißbrauchter oder ver- lorener Schlüssel? Speicherung von Schlüsseln? Ausgabe von Chipkarten mit geheimen Schlüsseln? Welche Garantien gibt eine Zertifizierung? Welche Haf- tung?“ [Gri95, S. 121]

Antworten auf alle oder wenigstens die meisten dieser Fragen sollten für eine bestimmte Zertifizierungsstelle deren Zertifizierungsrichtlinien (die sogenannte Policy, international oft auch Certification Practice Statement, CPS) geben.

2.6.1 Zweck einer Policy

Eine nachvollziehbare und nach festgelegten Regeln erfolgende Zertifizierung ist es ja gera- de, die eine CA von einem beliebigen, unbekannten Zertifizierer unterscheidet. Das Arbeiten nach selbstgesetzten (oder von außen – z.B. durch Gesetze oder Selbstverpflichtungen einer Branche – vorgegebenen), offengelegten Regeln ermöglicht es einem Dritten, der ein Zertifi- kat nutzen will, erst, die Glaubwürdigkeit und Verläßlichkeit des Zertifizierers einzuschätzen und sich zu entscheiden, inwieweit er dessen Aussage vertrauen will bzw. kann.

„TTPs [Trusted Third Parties] benötigen zur Begründung ihrer Vertrauenswür- digkeit eine veröffentlichte Policy, die eine klare Darstellung der Aufgaben und Sicherheitsanforderungen umfaßt und möglichst benutzerüberprüfbar realisiert ist.“ [FHK95, S. 2]

Damit eine Zertifizierungs-Policy diesem Anspruch gerecht werden kann, muß sie auf der einen Seite ausführlich genug sein, damit sich Nutzer ihrer Zertifikate ein Bild von der Ar- beitsweise der CA machen können, auf der anderen Seite darf sie aber auch nicht zu umfang- reich und detailliert sein, weil sie dann unübersichtlich würde. Im übernächsten Abschnitt

werden einige Beispiele genannt, die jeweils unterschiedliche Aspekte dieser Anforderun- gen besonders betonen.

2.6.2 Beispiele

Eine Policy dient nicht nur der Information Dritter, die Zertifikate nutzen wollen, sondern auch zur Absicherung der Zertifizierungsinstanz, die nach ihren Vorgaben zu zertifizieren verspricht. Schließlich geht es bei der Formulierung einer Policy auch darum, Haftungsregeln festzulegen (soweit dies rechtlich zulässig ist) bzw. diese im Sinne der Zertifizierungsstelle zu gestalten und für den Fall von Regreßforderungen und Rechtsstreitigkeiten eine günstige Ausgangsposition zu schaffen. Andererseits darf natürlich vor allem bei einer kommerzi- ell arbeitenden Zertifizierungsstelle die Policy die Interessen und Bedürfnissen der Kunden und von deren Kommunikationspartnern nicht völlig ignorieren, sonst beraubt sich die CA selber ihrer Geschäftsgrundlage. Wenn der Policy-Text nun aber auch den Anforderungen von Juristen genügen muß, dürfte denen im Zweifelsfall Vorrang vor der Verständlichkeit für technische oder juristische Laien gegeben werden. Das kann dann zu solchen CPS’ wie dem von VeriSign Inc. [Ver97] führen, das zwar sehr genau alle Aspekte der Zertifizierung durch VeriSign und der daraus resultierenden Haftung durch das Unternehmen beschreibt, dadurch aber so umfangreich geworden ist, daß vermutlich kaum ein Nutzer je die Richtlini- en vollständig zur Kenntnis nehmen wird – Abb. 2.1 mag einen Eindruck vom Umfang und der Detailgenauigkeit, aber auch der resultierenden Unübersichtlichkeit des VeriSign-CPS’ geben.

Das Public-Key-Verfahren bzw. das Zertifikat-Format (siehe auch 3.2), auf das sich die Po- licy bezieht, kann die Verständlichkeit einer Policy ebenfalls beeinflussen: Ein komplexes Verfahren oder Format mit vielen Optionen wird in den Zertifizierungsrichtlinien sicher nur schwer präzise und verständlich zugleich zu beschreiben sein. Darüberhinaus macht es auch einen Unterschied, ob die Zertifizierung als Dienst für Dritte angeboten oder eher für eigene Zwecke intern betrieben wird. Beide Punkte werden an dem Vorschlag von Dirk Fox für eine

„PGP-Policy für Unternehmen“ [Fox98] deutlich, die auf nur zwei Seiten knapp und über- sichtlich Zertifizierungs- und Umgangsregeln für die gesicherte firmeninterne und -externe elektronische Kommunikation beschreibt. Ihr kommt zugute, daß sie auf eine überschauba- re, geschlossene Benutzergruppe (noch dazu mit Weisungsbefugnissen für die Vorgesetzten) abzielt und sich nicht an einen offenen Nutzerkreis richtet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Die Verisign-Zertifizierungshierarchie (http://www.verisign.com/repository/hierarchy/)

Kapitel 3 Public-Key-Zertifizierung in der Praxis

3.1 Rechtlicher Rahmen

Für den Betrieb einer Zertifizierungsstelle sind viele gesetzliche Vorschriften relevant. Die wichtigsten, weil am konkretesten auf Zertifizierungsstellen abzielenden, sind das deutsche Signaturgesetz mit der zugehörigen Signaturverordnung und die im zweiten Entwurf vorlie- gende EU-Richtlinie zur elektronischen Signatur. Darüber hinaus sind die Datenschutzgeset- ze der Länder (hier: Berlins) und des Bundes maßgeblich.

3.1.1 Gesetz zur digitalen Signatur

Das Gesetz zur digitalen Signatur [SIG97a], auch Signaturgesetz oder kurz SigG, ist seit

1. August 1997 in Kraft. Es zielt darauf ab, Rahmenbedingungen zu schaffen, „unter denen digitale Signaturen als sicher gelten und Fälschungen digitaler Signaturen oder Verfälschun- gen von signierten Daten zuverlässig festgestellt werden können.“ (§ 1 Abs. 1) – Insofern ist es also eher ein „Sicherungsinfrastruktur-Gesetz“ als ein „Signaturgesetz“ und seine Be- zeichnung leicht irreführend. – Die Bundesrepublik hat damit als eines der ersten Länder den Versuch unternommen, einen Rahmen für den Einsatz und die Anerkennung eines Äquiva- lents zur eigenhändigen Unterschrift in der Welt der digitalen Kommunikation zu etablieren.

Der Anwendungsbereich des SigG umfaßt Zertifizierungsstellen, für deren Betrieb es ei- ner Genehmigung der im Gesetz als „zuständige Behörde“ bezeichneten obersten Zertifizie- rungsinstanz bedarf (§ 4 Abs. 1). Die Aufgabe dieser „Wurzelinstanz“ wird im SigG der Regulierungsbehörde für Telekommunikation und Post zugewiesen. (§ 3) Leider mangelt es dem Signaturgesetz in einem wichtigen Punkt an Bestimmtheit bzw. Eindeutigkeit: Eine Zertifizierungsstelle wird in ihm definiert als „eine natürliche oder juristische Person, die die Zuordnung von öffentlichen Signaturschlüsseln zu natürlichen Personen bescheinigt und da- für eine Genehmigung gemäß § 4 besitzt“ (§ 2 Abs. 2). Damit liegt ein Zirkelschluß vor, der Unklarheit darüber bewirkt, ob die Lizensierung freiwillig oder obligatorisch sein soll. § 1 Abs. 2 stellt ausdrücklich die Anwendung anderer Verfahren frei, während § 4 Abs. 1 und die Begründung zum Gesetz eine Lizensierungspflicht für jegliches Ausstellen von Zertifikaten nahelegen. [Roß97]

Die Erteilung einer Lizenz zum Betrieb einer Zertifizierungsstelle ist nach dem SigG an drei Voraussetzungen geknüpft:

Zuverlässigkeit des Antragstellers Fachkunde des in der Stelle tätigen Personals

Erfüllung der technischen und organisatorischen Sicherheitsanforderungen des Geset- zes an die Zertifizierungsstelle (Nachweis durch Vorlage eines Sicherheitskonzeptes und die Bestätigung der Umsetzung des Konzeptes durch eine von der zuständigen Behörde anerkannte Prüfstelle)

Personen, die den Anschein erwecken, über eine Lizenz als Zertifizierungsstelle nach dem SigG zu verfügen, ohne daß dies der Fall ist, kann die Tätigkeit der Lizensierung untersagt werden. (§ 13 Abs. 1)

Das SigG sieht eine zweistufige Zertifizierungshierarchie vor: Auf oberster Ebene befindet sich die “zuständige Behörde” genannte Wurzelzertifizierungsinstanz, die die eigentlichen, privatwirtschaftlich betriebenen Zertifizierungsstellen (zweite Ebene) zertifiziert. Diese wie- derum stellen die Zertifikate für die Anwender aus.

So begrüßenswert das SigG als schnelle Reaktion auf technische Neuerungen und die durch das Gesetz geschaffene Rechtssicherheit auch sein mögen, es bleiben auch einige Kritik- punkte, von denen hier nur die wichtigsten kurz erwähnt werden sollen (ausführlichere Darstellungen finden sich z.B. in [Roß97] und [Rei97c]): Die vorgegebene Zertifizierungs- struktur ist sehr rigide und orientiert sich vor allem an bereits existierenden Trustcentern; es sind keine spezifischen Haftungsregelungen vorgesehen (vgl. 4.19.2); die Sicherheitsan- forderungen sind sehr hoch und lassen kaum Raum für von einem Trustcenter abweichen- de Geschäftsmodelle – kleinere Unternehmen oder Spartenanbieter, die nur eine Teil der Trustcenter-Dienste offerieren wollen, dürften kaum in der Lage sein, die hohen Anforde- rungen zu erfüllen. Darüber hinaus ist der Gesetzestext an manchen Stellen unpräzise, so bei der Verwendung des Begriffes ‘öffentlicher Signaturschlüssel’, wenn eigentlich ein (öffent- licher) Schlüssel zum Prüfen und nicht zum Erstellen von Signaturen gemeint ist (§ 2 Abs. 3 u.a.), oder in § 3, wo von „Zertifikaten [sic], die zum Signieren von Zertifikaten eingesetzt werden“, die Rede ist.

3.1.2 Verordnung zur digitalen Signatur

In § 16 SigG wird die Bundesregierung ermächtigt, durch Rechtsverordnung Details zur Di- gitalen Signatur und zu SigG-Zertifizierungsstellen zu regeln, die im Signaturgesetz selbst ausgespart wurden. Dies betrifft alle wesentlichen Einzelheiten der Zertifizierung, der Pflich- ten einer Zertifizierungsstelle und der Maßnahmen, mit denen ihre Einhaltung kontrolliert werden soll.

Die Bundesregierung hat in der Verordnung zur digitalen Signatur (Signaturverordnung – SigV) [SIG97b] die entsprechende Ausgestaltung der o.g. Bereiche geregelt.

[...]