staging.inyokaproject.org

Technischer Hintergrund

Dieser Artikel handelt vom technischen Hintergrund von GnuPG 🇬🇧. Wer bereits mit der Funktionsweise der asymmetrischen Verschlüsselung vertraut ist - bspw. durch die Benutzung eines vergleichbaren Systems wie PGP in der Vergangenheit - wird hier wahrscheinlich nicht viel Neues entdecken und kann gleich zum praktischen Teil unter GnuPG und GnuPG/Web of Trust weiterklicken.

Abgrenzung zu rein symmetrischen Verfahren

Viele Verschlüsselungsformen nutzen sowohl für die Verschlüsselung als auch für die Entschlüsselung den gleichen Schlüssel. Man spricht hier daher vom symmetrischen Verfahren. Der Schlüssel - man könnte auch Passwort sagen - muss dabei geheim zwischen den Kommunikationspartnern ausgetauscht werden. Dies ist eine schwer zu erfüllende Anforderung.

Außerdem benötigt man für jeden potentiellen Kommunikationsweg einen eigenen Schlüssel. Wächst die Gruppe derer, die untereinander verschlüsselt kommunizieren wollen, wächst also gleichzeitig die Anzahl der benötigten Schlüssel unverhältnismäßig stark an, da jeder zu jedem mit einem anderen Schlüssel verschlüsseln muss. Zehn Personen benötigen z.B. bereits 45 unterschiedliche Schlüssel, die alle verdeckt ausgetauscht werden müssen, damit jeder mit jedem privat kommunizieren kann. (Allgemein gesagt, benötigt man bei n Teilnehmern eine Schlüsselzahl von n(n-1)/2.)

Eine Beschreibung wie symmetrische Verschüsselung unter GnuPG verwendet wird, steht im Wiki-Artikel GnuPG/Symmetrische Verschlüsselung.

Das asymmetrische Verfahren

GnuPG geht aber auch den asymmetrischen Weg: Es werden zwei Schlüssel verwendet, die durch eine komplizierte mathematische Berechnung in Beziehung zueinander stehen, welche ein Schlüsselpaar bilden. Mit dem einen Schlüssel können Daten nur verschlüsselt werden. Man kann sich das wie eine Einbahnstraße vorstellen: Durch Anwendung dieses Schlüssel werden die Daten in kryptisches Kauderwelsch verwandelt, eine Entschlüsselung ist prinzipbedingt hiermit nicht mehr möglich. Dies ist die Aufgabe des zweiten Schlüssels. Nur mit ihm kann dieses Kauderwelsch wieder zurückverwandelt werden. Es gibt also einen Schlüssel zum Abschließen und einen zum Aufschließen.

Man gibt also den Absperrschlüssel an seine Kommunikationspartner weiter. Dabei braucht man nicht geheime Wege einzuschlagen, was übrigens gerade der Vorteil des asymmetrischen Verfahrens ist. Da mit ihm ja nur verschlüsselt werden kann, darf im Prinzip jeder diesen Schlüssel bekommen. Man spricht deswegen auch vom öffentlichen Schlüssel.

Den Aufsperrschlüssel dagegen muss man gut hüten. Nur mit ihm können die Daten wiederhergestellt werden. Man spricht daher auch vom privaten Schlüssel.

Für eine gegenseitige Kommunikation werden also zwei Schlüsselpaare benötigt. Jeder Partner hat jeweils einen öffentlichen und einen zugehörigen privaten Schlüssel. Die öffentlichen Schlüssel werden jeweils an die anderen Kommunikationspartner (oder wen auch immer) übergeben. Die Anzahl der benötigten Schlüssel wächst also nur noch linear. Beim o.a. Beispiel von zehn Personen werden insgesamt nur zehn Schlüsselpaare gebraucht, also zwanzig Schlüssel, von denen die eine Hälfte niemals übertragen zu werden braucht (und sollte) und die andere Hälfte ganz öffentlich über Email-Signaturen, persönliche Homepages oder sogar allgemein zugängliche und durchsuchbare Keyserver verbreitet werden kann (und sollte).

Partner A verschlüsselt Nachrichten an Partner B dann also, indem er den öffentlichen Schlüssel von B verwendet. Nun kann nur B diese Nachricht mit Hilfe des eigenen privaten Schlüssels wieder lesen. Umgekehrt verwendet B den öffentlichen Schlüssel von A, um diesem geheime Botschaften zu senden.

Hybride Verfahren

Genau ausgedrückt, verwendet GnuPG ein hybrides Verfahren zur Verschlüsselung. Da asymmetrische Verschlüsselung extrem rechenintensiv ist, wird die eigentliche Nachricht tatsächlich symmetrisch verschlüsselt. Hierfür wird intern ein "Einweg-Schlüssel" erzeugt. Mit diesem Schlüssel wird zunächst die Nachricht verschlüsselt, was nun wesentlich schneller geht. Es wird nur der relativ kurze, symmetrische Schlüssel mit dem asymmetrischen Schlüssel (öffentlicher Schlüssel) gesichert. Der jetzt gesicherte symmetrische Schlüssel wird sodann zusammen mit der gesicherten Nachricht versandt. Der Empfänger nutzt seinen privaten Schlüssel, um Zugang zum geheimen, symmetrischen Schlüssel zu erlangen, und kann damit schließlich die Nachricht wiederherstellen. Die Erstellung und Verwendung des symmetrischen Schlüssels erfolgt programmintern und für jeden einzelnen Verschlüsselungsvorgang neu und ist für den Anwender vollkommen transparent. Da bei diesem Verfahren sowohl symmetrische als auch asymmetrische Verschlüsselung Verwendung findet, spricht man von hybrider Verschlüsselung.

Von sicheren und geheimen Kanälen

Doch ist eigentlich sichergestellt, dass ein öffentlicher Schlüssel tatsächlich zu einer bestimmten Person gehört? Schließlich lassen sich die Angaben im Schlüssel selbst (Name, E-Mail-Addresse) leicht irreführend angeben. Dieses Problem trifft sicher nicht zu, wenn man den Kommunikationspartner persönlich kennt und die Übergabe direkt stattfindet. Doch was ist, wenn die Übermittlung zum Beispiel via Internet erfolgt? Absenderadressen in E-Mails lassen sich leicht fälschen. So könnte also ein "Dritter" einen Schlüssel "sieht-nach-B-aus" an A senden. Wenn dieser Dritte sich geschickt anstellt, so fängt er alle verschlüsselten Nachrichten von A an B ab, entschlüsselt diese - weil er ja den privaten Schlüssel zu "sieht-nach-B-aus" besitzt - und sendet die Nachricht an B weiter - diesmal aber mit dem echten öffentlichen Schlüssel von B. Weder A noch B merken, dass es einen Lauscher dazwischen gegeben hat (im Fachjargon wird das als Man-in-the-middle-Angriff bezeichnet). Inwieweit so ein Vorgang tatsächlich durchgeführt werden kann, ist eine andere Frage, schließlich ist so ein Angriff mit einem hohen technischen und logistischen Aufwand verbunden. Glücklicherweise ist aber die Umgehung dieses Problems recht einfach:

Nachdem A den öffentlichen Schlüssel von B - wie auch immer - bekommen hat, muss sich A die Authentizität des Schlüssels bestätigen lassen. Jeder Schlüssel hat eine Art Fingerabdruck, eine unverwechselbare Kennung. Diese Kennung ist nur einige Zeichen - meist 40 Zeichen - lang und lässt sich beispielsweise vorlesen. Nun ist es so, dass bei dieser Prüfung wieder genau der gleiche Man-in-the-middle-Angriff möglich ist. Daher muss bei dieser einen Kommunikation, die also zur Prüfung des Fingerabdrucks dient, ein sicherer Kanal genutzt werden. Was ist ein sicherer Kanal? Es ist eine Kommunikation, die nicht manipuliert werden kann. Außerdem muss die Identität des Gegenübers gesichert sein. Der Kanal braucht allerdings nicht geheim zu sein. Jeder darf zuhören. Einige Beispiele für sichere Kanäle:

  • direkter Kontakt

  • Telefonat, wenn die Stimme des Kommunikationspartners bekannt ist

Wenn also ein direkter Kontakt möglich ist, so kann der Schlüssel auf einem Datenträger übergeben werden. Bei anderen Übergabeformen sollte zusätzlich der Fingerabdruck sicher geprüft werden.

Neben der Unabhängigkeit von einem geheimen Kanal gibt es aber noch weitere Vorteile gegenüber der symmetrischen Verschlüsselung, selbst wenn sichergestellt wird, dass ein Passwort geheim vereinbart werden kann. Wie sieht es mit der Sorgfalt im Umgang mit den Passwörtern aus? Man selbst kann noch so gewissenhaft mit dem Passwort umgehen - wenn dies der Kommunikationspartner nicht auch so handhabt, ist die eigene Anstrengung umsonst.

Passwortsätze

Selbst wenn der geheime Schlüssel doch einmal gestohlen wird, sind die verschlüsselten Dokumente noch lange nicht geknackt, weil der geheime Schlüssel noch einmal mit einem Passwortsatz ("passphrase") verschlüsselt wird, den man bei jeder Benutzung eingeben muss. Die Qualität des Passwortsatzes beeinflusst dabei aber nicht die Qualität der Verschlüsselung der Dokumente. Diese hängt nur von der Länge des Schlüssel und dessen Typ ab. Der Passwortsatz dient nur als Schutz vor unberechtigtem Zugang zum privaten Schlüssel, sollte daher also dennoch ausreichend sicher sein.

Diese Revision wurde am 17. Juni 2018 15:53 von rolands11 erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Kommunikation, Sicherheit, Email, Verschlüsselung