Der GNU Privacy Guard
Grundlagen
Dieses Kapitel soll ein wenig oberflächliches Hintergrundwissen vermitteln.
PGP, OpenPGP, GnuPG?
Philip Zimmermann programmierte 1991 Pretty Good Privacy und postete es im Usenet, wodurch es zum meistbenutzten E-Mail-Verschlüsselungsprogramm der Welt wurde und er sich strafbar machte, da die USA das Exportieren von Verschlüsselungssoftware strengstens untersagt - mittlerweile sind die Bestimmungen etwas aufgelockert. Er nutzte übrigens den patentierten RSA-Algorithmus, ohne eine Lizenz davon zu besitzen (ein Problem, das sich mit legalen Softwarepatenten in Europa zu einem Problem für alle ausweiten wird). PGP löste riesigen Wirbel weltweit aus, aber ich gehe darauf jetzt nicht weiter ein. Später gründete er PGP Inc., welche 1997 von Network Associates Inc. (NAI) übernommen wurde. 2002 verkaufte NAI die PGP-Software an die PGP Corp., welche es heute noch kommerziell vertreibt. Die Lizenzpolitik ist meines Erachtens etwas wirr: Der Quellcode für Teile der PGP-Produktserie ist einsehbar (wahrscheinlich, um zu zeigen, dass PGP nicht ausspioniert), allerdings ist PGP selbst keine freie Software, bis auf den unter der GNU GPL stehenden »PGP Universal«-Quellcode. Wer sich dafür interessiert, soll die PGP-Website konsultieren.
OpenPGP ist seit November 1998 ein Internetstandard, der die Formate (Schlüssel, Signaturen, etc.) und Methoden von PGP 5.x beschreibt.
Ein anderer derartiger Standard von 1999 ist im übrigen S/MIME (Secure/Multipurpose Internet Mail Extension), welcher hierarchisch und zertifikatbasiert ist. Daher eignet es sich eigentlich nur innerhalb großer Unternehmen und nicht im privaten Bereich. S/MIME und OpenPGP basieren auf MIME, sind aber nicht zueinander kompatibel.
Werner Koch ist der Autor von GnuPG, dem freien PGP-Ersatz, der ja in diesem Artikel besprochen wird. Die Erstveröffentlichung war am 20.12.1997, bis zur Version 1.0 vergingen nahezu zwei Jahre. GnuPG ist OpenPGP-kompatibel und somit ist der Austausch von Informationen mit Nutzern der PGP-Software fast kein Problem. Es unterliegt vollständig der GNU GPL und benutzt (ohne den herunterladbaren Zusatzquellcode) keine patentierten Algorithmen (RSA-Patent ist am 20.9.2000 in den USA abgelaufen; das Diffie-Hellmann-Patent, das angeblich ElGamal mit abdeckte, lief am 29.4.1997 ab; IDEA ist allerdings in den USA noch bis 25.5.2010 und in Europa sogar bis 16.5.2011 patentiert), wodurch es - wo es nationales Recht nicht verbietet - ohne Einschränkungen genutzt werden kann. GnuPG beherrscht in der jetzt stabilen 1.4-Serie kein S/MIME; GnuPG 2.0 (bis jetzt 1.9.x) soll damit umgehen können.
Verschlüsselungsverfahren
Oft ist von »symmetrischer« oder »asymmetrischer« Verschlüsselung die Rede. Doch was ist das?
Ein Verschlüsselungsverfahren ist symmetrisch, wenn es zur Ver- und Entschlüsselung ein und denselben Schlüssel verwendet. Das Problem dabei ist, dass der Empfänger diesen Schlüssel selbst erst einmal erhalten muss, um die verschlüsselte Nachricht entschlüsseln zu können. Ich muss wohl nicht erwähnen, dass dieser Schlüssel auch abgefangen werden kann und somit die ganze Verschlüsselung zwecklos wäre. Natürlich ist es möglich, den Schlüssel in verschiedene Summanden zu zerteilen und diese über unterschiedliche Kanäle (Post, E-Mail, Telefon) dem Empfänger zu übermitteln, aber das wäre auch viel zu aufwändig.
Bei asymmetrischen Verschlüsselungsverfahren, auch Public-Key-Verfahren genannt, gibt es dieses Problem nicht. Jeder Kommunikationspartner hat ein Schlüsselpaar, bestehend aus einem geheimen Schlüssel (private key oder secret key) und einem öffentlichen Schlüssel (public key). Den geheimen Schlüssel kann man selbstverständlich nicht ohne weiteres aus dem öffentlichen Schlüssel ableiten, sonst wäre das System sinnlos. Zur Verschlüsselung wird der öffentliche Schlüssel des Empfängers genutzt. Zur Entschlüsselung braucht man den geheimen Schlüssel des Empfängers - da den nur der Empfänger hat, ist es auch nur ihm möglich, die Nachricht entschlüsseln.
Wie der Name schon sagt, sollte der geheime Schlüssel unbedingt geheim gehalten werden. Aus eigener Erfahrung empfehle ich dennoch eine Sicherung. Der öffentliche Schlüssel sollte hingegen an Kommunikationspartner geschickt werden, auf der eigenen Homepage stehen, und von einem PGP-Keyserver (siehe unten) abrufbar sein. Eine möglichst weite Verbreitung des öffentlichen Schlüssels ist wünschenswert.
GnuPG (sowie PGP) benutzen eine »Kreuzung« aus beiden Verfahren, die hybride Verschlüsselung: die zu verschlüsselnde Nachricht wird mit einem (bei jeder Nachricht zufällig erstellten) symmetrischen Sitzungsschlüssel verschlüsselt, und dieser Schlüssel selbst mit dem öffentlichen Schlüssel des Empfängers. Ebenso wird bei der Entschlüsselung erst der Sitzungsschlüssel mit dem geheimen Schlüssel entschlüsselt und damit dann die eigentliche Nachricht.
Digitale Signatur
Mit der Möglichkeit, eine Nachricht zu unterschreiben, garantiert man ihre Echtheit bzw. Gültigkeit - man spricht von der Integrität bzw. Authentizität einer Nachricht (und des korrekten Absenders), die durch die digitale Unterschrift gewährleistet wird. Um es anders auszudrücken: die digitale Unterschrift erfüllt den gleichen Zweck, wie eine normale Unterschrift. Sie sollte daher fälschungssicher und verbindlich sein, d.h. sie ist nicht auf andere Dokumente übertragbar und das Dokument ist im Nachhinein auch nicht mehr änderbar (außer es wird neu unterschrieben).
GnuPG benutzt standardmäßig DSA (Digital Signature Algorithm), um digitale Unterschriften zu realisieren. Diese wird dabei mit dem geheimen Schlüssel des Absenders aus der Nachricht erzeugt. Der Empfänger kann die Authentizität dann mit dem öffentlichen Schlüssel des Absenders überprüfen.
Andere Personen (Freunde, Kommunikationspartner, usw.) können dann den eigenen öffentlichen Schlüssel unterschreiben, und versichern somit nach ihrem besten Gewissen, dass der öffentliche Schlüssel zu dem angegebenen Absender gehört. Man sollte nur Schlüssel von Personen unterschreiben, deren Identität man genau kennt. Hierbei spricht man auch vom Web-of-Trust. Als Beispiel sei das Debian-Projekt genannt, bei der jeder, der offizieller Entwickler werden will, als Grundvoraussetzung eine über Signaturen anderer Debian-Entwickler bestätigte Identität haben muss.
