In der öffentlichen Diskussion manifestieren sich diese Ansprüche in der Forderung nach Rechtsverbindlichkeit elektronischer Dokumente zum Beispiel durch digitale Unterschriften und dem Wunsch nach informationeller Selbstbestimmung, also dem Schutz persönlicher Daten.
Die zunehmende Nachfrage nach gesicherter Kommunikation und den zugehörigen Diensten spürt man auch an dem wachsenden Interesse an Verschlüsselungssoftware. Wachsendes Interesse bedeutet auch wachsende Märkte, und die Hoffnung auf einträgliche Geschäfte kommt den Programmen und Verfahren nicht unbedingt zugute. Aufgrund der hohen Anforderungen an Verschlüsselungs- und Signier-Programme scheint eine Einflußnahme auf sich abzeichnende Entwicklungen dringend geboten.
Während der private Schlüssel streng vertraulich behandelt werden muß, verdient der öffentliche Schlüssel eine weite Verbreitung. Jeder kann ihn nutzen, um dem Eigentümer eine vertrauliche Nachricht zu schicken. Niemand anderes als der Schlüsseleigner kann eine solche Nachricht wieder dechiffrieren, weil niemand anderes den nötigen Schlüssel - den private Key - kennt.
Mit pgp steht auch Software zur Verfügung, die den Einsatz dieser Verfahren weltweit enorm beschleunigt hat. Leider unterliegen die Algorithmen in Amerika Exportbeschränkungen, und auch die patentrechtliche Situation ist nicht ganz einfach, wie folgende Tabelle zeigt:
| Name und Patentnummer | Bereich | Entwickler | Beantragende Stelle | Beantragt, Erteilt, Läuft aus |
|---|---|---|---|---|
| Kryptographischer Apparat und Verfahren (4,200,770) | Diffie-Hellman Schlüsseltausch | M.E. Hellmann, B.W. Diffie, R.C. Merkle | Universität Stanford | 6.9.77, 29.4.80, 29.4.97 |
| Verfahren zur Kryptografie mit öffentlichen Schlüsseln (4,218,582) | Rucksackproblem und wahrscheinlich die gesamte Kryptographie mit öffentlichen Schlüsseln | M.E. Hellman, R.C. Merkle | Universität Stanford | 6.10.77, 19.8.80, 19.8.97 |
| Exponentialkryptographie (Verfahren) (4,424,414) | - | M.E. Hellman, S.C. Pohlig | Universität Stanford | 1.5.78, 3.1.84, 3.1.2001 |
| Kryptographische Kommunikation (Verfahren) (4,405,829) | RSA Kodierungen | R.L. Rivest, A. Shamir | MIT | 14.12.77, 20.9.83, 20.9.2000 |
| Verfahren zur Identifizierung von Unterzeichnenden und zur Erzeugung und Überprüfung von elektronischen Unterschriften (4,995,082) | Standard für digitale Unterschriften | C.P. Schnorr | - | 23.2.90, 19.2.91, 19.2.2008 |
Neben der Verschlüsselung bieten die Public-Key-Verfahren auch die Möglichkeit, digitale Unterschriften zu leisten. Das geschieht, indem über den zu signierenden Text eine kryptographische Prüfsumme gebildet und mit dem geheimen Schlüssel des Unterschreibenden verschlüsselt wird. Kein Fremder kann nun unbemerkt Modifikationen an der Nachricht vornehmen, denn jeder Empfänger kann seinerseits die Prüfsumme bilden und mit der vom Autor gebildeten vergleichen - vorausgesetzt, er hat dessen öffentlichen Schlüssel. Und damit sind wir auch beim Hauptproblem der Public-Key-Verfahren: Woher weiß der Empfänger, daß er den "richtigen" öffentlichen Schlüssel hat? Es kann ja ein Scherzbold, um nicht an noch schlimmere Zeitgenossen zu denken, ein Schlüsselpaar kreieren, welches der gleichen Person zugeordnet ist. Bevor ein öffentlicher Schlüssel verwendet wird, muß absolute Sicherheit herrschen, daß er wirklich von der Person stammt, deren Namen und e-Mail-Adresse er trägt.
Am einfachsten läßt sich das Problem lösen, indem man den Schlüsseleigner einfach anruft oder sich mit ihm trifft. Dabei muß man nicht unbedingt den Schlüssel selbst vorlesen oder austauschen, es reicht, wenn man (bei pgp) den Fingerprint, eine 128 Bit große Prüfsumme über den öffentlichen Schlüssel, kontrolliert. Aber schon, wenn man den Besitzer des Schlüssels nicht persönlich kennt oder ihn nicht erreichen kann, funktioniert das nicht mehr.
Zwei grundlegende Ansätze sollen die Authentizität der öffentlichen Schlüssel in größerem Rahmen sichern. Beide setzen voraus, daß sich auch Schlüssel unterschreiben lassen. Die Unterschrift unter einem Schlüssel besagt, daß sich der Unterzeichner der Authentizität des Schlüssels versichert hat. Er unterschreibt, daß der Schlüssel wirklich zu der Person gehört, deren Identifikation er trägt.
Diese Freunde kennen nun ihrerseits auch wieder Personen, denen sie vertrauen. So nach und nach bildet sich ein Netz des Vertrauens heraus, das "Web of Trust", in dem jeder selbst entscheidet, wem er vertraut, und wessen Unterschriften er welche Bedeutung beimißt. Es bleibt nur eine Frage: Was passiert bei der Begegnung bislang völlig fremder Partner?
Ein schlechtes Beispiel lieferte die Firma Verisign, die vor der Erteilung eines "Class 1" Zertifikats lediglich prüft, ob die angegebene e-Mail-Adresse nicht bereits in früheren Zertifikaten enthalten ist. Amerikanischen Hackern von "DigiCrime" gelang es, ein Zertifikat für root@localhost zu erhalten. Solche Zertifikate haben natürlich einen sehr zweifelhaften Wert ...
Wodurch sichert man aber die Authentizität des Schlüssels der CA? Ganz einfach - durch ein Zertifikat einer anderen CA. Die CAs werden hierarchisch aufgebaut. Die oberste oder Root-CA zertifiziert die CAs der niederen Ebenen. Die Schlüssel der Zertifizierungsinstanzen müssen natürlich jedem Interessenten bekannt sein, insbesondere der Schlüssel der Root-CA, mit dessen Hilfe sich alle anderen Schlüssel überprüfen lassen.
Die Arbeit der Certification Authority wird in einer "Policy" geregelt. In diesem Dokument können und sollen alle Interessenten nachlesen, wie die Zertifizierung vorgenommen wird, welche Prüfungen stattfinden, wie die Sicherheit gewahrt wird. Leider haben diese Dokumente oftmals den Makel zu großer Länge, so daß sich nur wenige Nutzer die Mühe machen, den Text wirklich durchzuarbeiten.
Eine wesentliche, leicht unterschätzte Aufgabe der CAs ist das Sperren von Schlüsseln. Es kann durchaus passieren, daß ein Schlüssel unsicher wird, z.B. weil man versehentlich im Beisein seiner Kollegen das Password laut mitgesprochen hat. Dann sollte der Schlüssel gesperrt werden. Dazu gibt die CA regelmäßig Listen mit gesperrten Schlüsseln heraus, sogenannte revoke Zertifikate.
Mit den CAs wird das "Web of Trust" nicht ersetzt, aber sinnvoll ergänzt.
Über die Policy, die Vereinbarungen der Nutzer mit der CA und auch der regionalen CAs mit der Root-CA kann man auf den WWW-Seiten des IN e.V. Näheres erfahren. Dort werden auch Listen ausgestellter Zertifikate der Root-CA sowie Rückruflisten veröffentlicht.
Übrigens werden prinzipiell zwei verschiedene Schlüsselpaare verwendet: Ein Schlüsselpaar zum Signieren (Sign Key), und eines zum Verschlüsseln (Encryption Key). Der (geheime) Signier-Schlüssel wird ausschließlich zum Zertifizieren verwendet. Wer Nachrichten an eine CA verschlüsseln möchte, muß unbedingt den (öffentlichen) Encryption Key verwenden. Der dahinterstehende Gedanke ist einfach: Im Rahmen einer Strafverfolgung könnte es zum Beispiel passieren, daß die Herausgabe des geheimen Schlüssels gefordert wird. Gäbe es nur ein Schlüsselpaar, dann wären mit einem Schlag alle Zertifikate wertlos. Durch die Trennung der Aufgaben gibt es aber keinen akzeptablen Grund für Herausgabe des (geheimen) Signierschlüssels - er kann praktisch nur zum Fälschen von Unterschriften verwendet werden, und das hat ja eine offizielle Instanz nicht vor. Sie wird sich also mit dem (geheimen) Encryption Key begnügen müssen, mit dem sie die an die CA gerichteten verschlüsselten Mails dechiffrieren kann.
Sollte der Encryption Key tatsächlich einmal kompromitiert werden, so kann jederzeit ein mit dem Sign Key signierter neuer Encryption Key veröffentlicht werden. Der Aufwand bleibt also überschaubar - vorausgesetzt, der Sign Key blieb unangetastet.
Um die Sicherheit noch weiter zu erhöhen, tragen alle Schlüssel ein Verfallsdatum. Danach ist die Zertifizierung zu erneuern, ähnlich, wie nach einer gewissen Frist der Ausweis erneuert werden muß. Während der experimentellen Phase des Aufbaus der Hierarchie ist die Frist sehr kurz, später werden dann Gültigkeitszeiträume von bis zu fünf Jahren anvisiert.
Zunächst baut die CA des IN e.V. auf pgp auf, später soll auch andere Software unterstützt werden. Der IN Chemnitz e.V. unterstützt die Aktivitäten des Dachverbandes und arbeitet am Aufbau einer eigenen, regionalen CA.