Spontanen gesicherten Datenaustausch übers Internet ermöglichen asymmetrische Verfahren. Sie verwenden statt eines einzigen Schlüssels deren zwei: einen öffentlichen und einen privaten. Jeder Kommunikationspartner besitzt ein solches Schlüsselpaar. Den privaten Schlüssel hält er geheim, der öffentliche ist für jedermann zugänglich. Mit diesen Schlüsseln hat es eine besondere Bewandnis: Was mit dem einen Schlüssel verschlossen (chiffriert) wurde, kann man nur mit dem jeweils anderen wieder öffnen (dechiffrieren).
|
Funktionsweise von Public-Key-Verfahren. |
In der Praxis sieht das so aus: wenn Alice eine Nachricht an Bob senden möchte (Kryptographen verwenden gern die Namen Alice und Bob für die Kommunikationspartner), chiffriert sie diese mit Bobs öffentlichem Schlüssel SBpub. Zum Dechiffrieren ist Bobs privater Schlüssel SBpriv erforderlich. Da nur Bob im Besitz dieses Schlüssels ist (und ihn hoffentlich immer gut verwahrt), kann nur er die Nachricht dechiffrieren und lesen.
Der umgekehrte Weg - Verschlüsseln mit dem privaten und Dechiffrieren mit dem öffentlichen Schlüssel - ist ebenfalls sinnvoll und ermöglicht digitale Unterschriften. Um ein Dokument zu unterschreiben, chiffriert Alice es mit ihrem privaten Schlüssel. Bob entziffert es mit Alices öffentlichem Schlüssel. Dabei kommt nur dann etwas Sinnvolles heraus, wenn die Nachricht tatsächlich von Alice stammt und sie nicht von einem Dritten verfälscht wurde. In der Praxis wird Alice aus Effizienzgründen für die digitale Unterschrift nicht das komplette Dokument verwenden, sondern aus dem Dokument mit Hilfe einer [#ehf Einweg-Hash-Funktion] eine Kurzkennung generieren, Message-Digest oder Signatur genannt. Diesen Message-Digest chiffriert Alice mit ihrem privaten Schlüssel und hängt ihn an die Nachricht an. Für eine vertrauliche Übermittlung chiffriert sie das Dokument (und gegebenenfalls den Digest) vor dem Absenden mit Bobs öffentlichem Schlüssel.
|
Digitale Unterschrift. |
Bob dechiffriert die Nachricht mit seinem privaten Schlüssel und erhält das Dokument im Klartext sowie den mit Alices privatem Schlüssel verschlüsselten Digest. Letzteren dechiffriert Bob mit Alices öffentlichem Schlüssel. Nun berechnet er aus der Nachricht die Signatur neu und vergleicht sie mit dem empfangenen Digest. Die beiden Werte müssen identisch sein, sonst ist Alice nicht der Absender oder das Dokument wurde auf dem Transportweg verfälscht.
Einweg-Hash-Funktionen zur Generierung von Message-Digests müssen bestimmte Eigenschaften für den kryptographischen Einsatz aufweisen. Insbesondere muß ein solcher Algorithmus Signaturen liefern, die keinerlei Rückschlüsse auf das Ausgangsdokument ermöglichen - daher auch 'Einweg'. Außerdem darf es nicht möglich sein, zu einem gegebenen Digest ein Dokument zu konstruieren, das diesen Digest als Ergebnis liefert. Ebenso muß es unmöglich sein, zwei Dokumente zu finden, die denselben Digest liefern. 'Unmöglich' bedeutet hier übrigens immer, daß der erforderliche Aufwand, ein bestimmtes Ergebnis zu berechnen, jedes realistische Maß übersteigt und auch mit tausenden vernetzter Superrechner auf Jahrhunderte oder Jahrtausende hinaus nicht machbar ist. Da ein Message-Digest nicht beliebig lang ist, sondern die Länge in der Regel nicht über einige hundert Bytes hinausgeht, existieren selbstverständlich durchaus Dokumente, die denselben Digest liefern. Der Punkt ist: es darf kein Verfahren geben, das das Finden solcher Dokumente ermöglicht und schneller ist als simples Ausprobieren.
Message-Digest-Verfahren wie MD4 und MD5 sind frei verfügbar; Details finden sich in den RFCs RFC 1319, RFC 1320 und RFC 1321. Es gibt noch weitere Verfahren dieser Art.
Das Public-Key-Verfahren schlechthin heißt RSA, wurde 1977 entwickelt und ist nach seinen Erfindern Ron Rivest, Adi Shamir und Leonard Adleman benannt. Die Vorteile von Public-Key-Verfahren - kein Austausch von Geheimnissen über ein sicheres Medium, Authentifizierung - gegenüber symmetrischen Verfahren haben ihren Preis: Public-Key-Verfahren arbeiten um Größenordnungen langsamer. Die Geschwindigkeit hängt in erster Linie von der Schlüssellänge ab. RSA und DES etwa unterscheiden sich um einen Faktor von mindestens 100, bei einer DES-Implementierung in Hardware kann dieser Faktor leicht auf 1000 bis 10000 ansteigen.
Für die Verschlüsselung kompletter Dokumente ist RSA daher einfach zu langsam. In der Praxis kombiniert man Public-Key- und Private-Key-Verfahren zu einem effizienten Ganzen: Zunächst etablieren die Kommunikationspartner mit Hilfe des Public-Key-Verfahrens eine gesicherte Übertragung und gehen dann zum schnellen symmetrischen Verfahren über. Einer der Beteiligten generiert dazu einen 'Session-Key', chiffriert ihn mit dem öffentlichen Schlüssel des Partners und übermittelt ihn sicher. Der Empfänger dechiffriert ihn mit seinem privaten Schlüssel, und die eigentliche Nachrichtenübertragung kann beginnen.
Die Sicherheit der RSA-Verschlüsselung hängt von der Länge des verwendeten Schlüssels ab. Je länger der Schlüssel, desto schwieriger ist es, ihn zu knacken. Rivest schätzte 1992 die Kosten zum Knacken eines 512-Bit-Schlüssels auf zirka 8,2 Millionen Dollar für die nötige Hardware. Drei Jahre später liegen sie deutlich niedriger, und man sollte daher längere Schlüssel verwenden. Bei besonders hohen Sicherheitsanforderungen sollte die Schlüssellänge mindestens 1000 Bit betragen. Bei 'Pretty Good Privacy' (PGP) kann der Anwender drei Sicherheitsstufen auswählen: Home (256 Bit), Standard (512 Bit) und Military (1024 Bit). Grundsätzlich sollte man in gewissen Abständen, etwa alle zwei Jahre, das Schlüsselpaar wechseln und die neuen Schlüssel einige Bits länger wählen, um mit der Entwicklung der Hardwaretechnik Schritt zu halten.
Von Bedeutung ist noch die Frage nach der Glaubwürdigkeit öffentlicher Schlüssel. Wenn Alice eine Nachricht an Bob senden will, muß sie sicher sein können, daß Bobs öffentlicher Schlüssel, den sie etwa aus einer öffentlich zugänglichen Datenbank abrufen kann, wirklich Bobs öffentlicher Schlüssel ist. Was, wenn ihr ein Übeltäter - in der einschlägigen Literatur hört er auf den Namen Mallet - seinen eigenen öffentlichen Schlüssel unterschiebt? Wenn Alice damit in gutem Glauben ein vertrauliches Dokument chiffriert und es Mallet gelingt, dies abzufangen, kann er es mit seinem eigenen privaten Schlüssel dechiffrieren und lesen. Selbst wenn es wirklich Bobs öffentlicher Schlüssel ist, wird Alice dies nicht einfach glauben, sondern einen Nachweis dafür verlangen.
Im 'wirklichen Leben' wäre das ungefähr so, als wenn Mallet einen Personalausweis mit Bobs Namen herstellen und Alice präsentieren könnte. Das darf natürlich nicht sein, denn nur die Bundesdruckerei ist dazu berechtigt. Sie hinterläßt auf jedem Personalausweis als Kennzeichen den Bundesadler, den Aufdruck 'Bundesdruckerei', die Guillochen (verschlungene Linienzeichnungen) und die Plastikeinschweißung. Diese und die übrigen charakteristischen Merkmale kann jeder überprüfen, der sich von der Authentizität eines Personalausweises überzeugen will.
In der digitalen Welt benötigt ein öffentlicher Schlüssel ein Zertifikat, das seine Gültigkeit bestätigt. Bob erhält es (gegen Zahlung einer Gebühr) von einer Zertifizierungsstelle (Key Certification Authority, KCA). Es besteht aus Bobs Namen sowie seinem öffentlichen Schlüssel und ist von der KCA digital unterzeichnet. Wenn Alice den Schlüssel erhält, kann sie ihn mit dem öffentlichen Schlüssel der KCA überprüfen.
Soweit die verwendeten Verfahren in ihren Grundzügen. Detailfragen behandelt die einschlägige Literatur, insbesondere das schon mehrfach erwähnte Standardwerk von Schneier (siehe [[default.shtml#literatur 1]]).
Dieser Text ist der Zeitschriften-Ausgabe 12/1995 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.