OpenPGP definiert ein Verschlüsselungsformat gemäß Internet Engineering Task Force (IETF) Standard 2440 und RFC 3156. OpenPGP basiert auf der ursprünglich von Phil Zimmermann entwickelten Software Pretty Good Privacy (PGP) in der Version 5. Die beiden bekanntesten OpenPGP Softwarepakete sind das kommerzielle PGP und das unter der GNU General Public License (GPL) veröffentlichte GnuPG (Gnu Privacy Guard). Heute findet OpenPGP vorzugsweise bei der Verschlüsselung von Emails Verwendung.

Wir werden uns in diesem Artikel zuerst mit der Entstehungsgeschichte von OpenPGP beschäftigen. Anschließend wenden wir uns den grundlegenden technischen Konzepten zu. Beschließen wollen wir den Artikel mit Hinweisen zum praktischen Einsatz von OpenPGP. Hier der Überblick:

A. Geschichte

A.1 Phil Zimmermann und die Geburt von PGP

1991 veröffentlichte der Softwareentwickler Phil Zimmermann PGP 1.0 zur freien, nicht-kommerziellen Verwendung inklusive Quellcode. Nach Zimmermann sollte PGP ein Werkzeug für die große Masse der Bürger zur sicheren elektronischen Kommunikation werden. Dabei galt sein Interesse insbesondere Bürgerrechtsbewegungen, die seiner Meinung nach am schnellsten in das Visier staatlicher Überwachungsmaßnahmen geraten können.

Phil Zimmermann

Konkreter Hintergrund der Freigabe von PGP 1.0 Anfang 1991 war der im Raum stehende Gesetzesentwurf Nr. 266 des US-Senats, der die verpflichtende Einrichtung von Hintertüren in Verschlüsselungsoftware zum Zwecke der Strafverfolgung vorsah. Diesem wollte Zimmermann zuvorkommen.

Kurz nach der Veröffentlichung von PGP 1.0 strich jedoch der Senat Anfang Juni 1991 die Kryptographie-Klausel aus dem Entwurf. Ungeachtet dessen verbreitete sich PGP schnell über Bulletin Boards und das Internet weltweit. Und so erschien bereits ein Jahr später PGP 2.0.

PGP 2.0 enthielt einige technische Verbesserungen gegenüber dem Erstlingswerk. Während PGP 1.0 noch Zimmermanns eigenen symmetrischen Algorithmus Base-O-Matic benutzte, kam jetzt der deutlich sicherere IDEA-Algorithmus zu Einsatz. Ebenso wurde der in PGP 1.0 verwendetet Hash-Algorithmus MD4 durch die verbesserte Version MD5 ersetzt. ZIP löste in PGP 2.0 LZHuf (Lempel-Ziv Huffman) als Kompressionsverfahren ab und die 7-bit-Übermittlung geschah nun mit ASCII via radix-64 anstatt mit uuencode.

A.2 Exportbeschränkungen und Patentstreitigkeiten

In beiden Versionen 1 und 2 setzte Zimmermann RSA für die Public-Key-Verschlüsselung ein. Dies führte zu Patentstreitigkeiten mit den Rechteninhabern von RSA, den Public Key Partners (PKP), respektive deren Mitglied RSA Data Security. Mit dem IDEA-Patent gab es hingegen weniger Schwierigkeiten.

Im Februar 1993 trat zusätzlich die US-Regierung auf den Plan. Jim Bidzos, Chef von PKP und RSA Data Security beschuldigte Zimmermann, das (nur!) in der USA gültige RSA-Patent verletzt zu haben – Bizdos und Zimmermann waren zwar zuvor übereingekommen, daß Zimmermann PGP wegen des RSA-Patents nicht im Inland verbreiten werde. Über europäische FTP-Server hatte PGP aber den Weg zurück in die USA gefunden.

Die US-Regierung begann also ihre Untersuchung zu dieser vermeintlichen Patentverletzung. Wenig später geriet nun ein anderer Aspekt von PGP ins Visier der Ermittler: PGP verletze mit Verwendung insbesondere von RSAREF die Exportbeschränkungen für Waffen (ITAR). Hintergrund: Kryptographie galt gemäß ITAR als Waffe, stand also auf derselben Stufe wie Lenkraketen, Bomben und Panzer. Diesbezügliche Ermittlungen zogen sich drei Jahre hin, wurden aber schließlich ohne Ergebnis im Januar 1996 eingestellt (vgl. Phil Zimmermanns Erklärung).

Ergebnis der patentrechtlichen Auseinandersetzungen mit RSA Inc. und der Regierung waren zwei verschiedene Versionen von PGP. Die US-Ausgabe – jetzt durch das MIT vertrieben – verwendete in Übereinkunft mit PKP bzw RSA ab Version 2.5 die Shareware-Bibliothek RSAREF. Die internationale Version PGPi griff hingegen auf Zimmermanns MPILIB-Bibliothek zurück, um die ITAR-Exportbeschränkungen von RSAREF nicht zu verletzen.

Um den weiteren Quellcode von PGP auch im Ausland legal nutzen zu können, veröffentlichte Zimmermann diesen in Buchform, so daß er sich trotz ITAR exportieren ließ. In Europa wurden die über 6000 Seiten des zwölfbändigen Buches dann gescannt und wieder in elektronische Form übersetzt. An PGP 5.0i waren daher über 70 Freiwillige mit insgesamt mehr als 1000 Arbeitsstunden beteiligt.

Die letzte so entwickelte PGPi-Auflage war die in der Schweiz gescannte Version 6.5.1i. Als die USA ihre Exportbeschränkungen 1999 gelockert hatten, war dieser umständliche Verbreitungsweg von PGP nicht mehr notwendig.

A.3 PGP 5 und der neue Standard OpenPGP

Nachdem die US-Regierung die Ermittlungen gegen Zimmermann Anfang 1996 eingestellt hatte, gründete er und sein Team zusammen mit Viacrypt (bis dahin Inhaber der kommerziellen Verwertungsrechte von PGP und RSA-Lizenznehmer) die Firma PGP Incorporated zur Weiterentwicklung von PGP. Dabei kam man überein, daß die PGP-Versionen von Viacrypt gerade Nummern haben sollten und die Entwicklungen des Zimmermann-Teams ungerade.

So enstand auf der Basis von PGP 2.x die Viacrypt-Version PGP 4. Um Konfusionen mit den Versionsnummern zu vermeiden, erhielt der im Mai 1997 vom Zimmermann-Team fertiggestellte Nachfolger der Viacrypt-Ausgabe nicht die Nummer 3, sondern wurde PGP 5 getauft.

PGP hatte sich bis zu diesem Zeitpunkt weltweit zu einem der am meist verwendeten Kryptographiesysteme gemausert. Anderweitige Implementierungen waren daher gefragt, aber nur begrenzt machbar (z.B. Veridis), da kein allgemeiner Standard verfügbar war. So trug PGP Inc. im Juli 1997 der Internet Engineering Task Force (IETF) das Anliegen eines solchen Standards mit dem Namen OpenPGP vor. Daraufhin gründete die IETF eine OpenPGP-Arbeitsgruppe.

Nach einem Jahr Entwicklung veröffentlichte die OpenPGP-Arbeitsgruppe im Juli 1998 ihr Ergebnis: Der Internet-Standard RFC 2440 (OpenPGP Message Format), basierend auf PGP 5. Dieses Papier löste den PGP 2.x beschreibenden Quasi-Standard RFC 1991 (PGP Message Exchange Formats) ab.

RFC 2440 befindet sich weiter in der aktiven Entwicklung. Den aktuellen Status kann man bei der IETF einsehen. Der 2440er Entwurf wurde ergänzt um den Standard RFC 3156 (MIME Security with OpenPGP), der die Integration von OpenPGP und MIME beschreibt. Es ist der Nachfolger von RFC 2015 (MIME Security with Pretty Good Privacy).

A.4 OpenPGP heute

OpenPGP gilt heute neben S/MIME als der wichtigste Standard zum Verschlüsseln und Signieren von Emails. Allgemein lassen sich nach dem OpenPGP-Standard aber auch andere digitale Daten verschlüsseln und signieren.

Sinnvolle Anwendung findet OpenPGP zum Beispiel bei der signierten Verteilung von Software über das Internet, um die Quelle der Software überprüfen zu können. Auch beim Signieren persönlicher Dateien oder der Verschlüsselung sensibler Daten etwa auf der eigenen Festplatte ist der Standard nützlich.

Die beiden bekanntesten Implementierungen sind das kommerzielle PGP und das unter der GNU General Public License (GPL) angebotene GnuPG (Gnu Privacy Guard) der Free Software Foundation (FSF). Daneben existieren weitere Hersteller, die OpenPGP-Produkte anbieten.

Zu nennen ist hier vor allem das belgische Unternehmen Veridis, das zusammen mit Phil Zimmermann Werkzeuge zur Verschlüsselung vertreibt. Zimmermann arbeitet zudem für dem Email-Provider Hushmail, der OpenPGP für Webmail anbietet. Auch Forum und Arcticsoft bieten Programme gemäß OpenPGP an.

Noch ein Blick auf PGP: Pretty Good Privacy wurde ab 1997 zwischenzeitlich von Network Associates (NAI) vertrieben. Nachdem NAI (heute McAfee) im Jahre 2000 die Veröffentlichung des Quellcodes von PGP ohne Einverständnis der Programmierer gestoppt hatte, gab es Gerüchte, daß PGP mit Hintertüren ausgerüstet wurde.

Wichtige Entwickler, darunter Zimmermann selbst, verließen NAI. Das Unternehmen kündigte daraufhin an, von PGP Abstand nehmen zu wollen und bot die Rechte im Oktober 2001 zum Verkauf an. 2002 kaufte die von ehemaligen PGP-Entwicklern neu gegründete Firma PGP Corporation die Rechte an PGP zurück und zeigt sich seitdem für dessen Weiterentwicklung verantwortlich.

Da PGP 5 selbst noch nicht vollständig standardkonform war, gilt der GNU Privacy Guard (GnuPG) als die eigentlich erste Implementierung des OpenPGP-Standards. Die GNU General Public License (GPL), unter der GnuPG lizenziert wird, garantiert die weltweite und zeitlich unbegrenzte freie Verfügbarkeit des Quellcodes. Hintertüren sind so kaum denkbar, da sich prinzipiell jeder Benutzer von der Integrität des Codes selbst überzeugen kann.

B. Technik

OpenPGP soll zwei Haupt- und zwei Nebenfunktionen erfüllen. Hauptfunktionen: OpenPGP definiert erstens einen Standard zur Verschlüsselung und zweitens einen Standard zur Signierung von Daten. Nebenfunktionen: Im Rahmen dessen sind Angaben zur Komprimierung und Umwandlung der Daten für den Transport notwendig.

OpenPGP als hybrides Kryptosystem

OpenPGP beschreibt ein hybrides Kryptosystem dar, d.h. man verwendet eine Kombination aus symmetrischer und asymmetrischer Verschlüsselung (public key Verschlüsselung) und bündelt so die Vorteile beider Verfahren, ohne deren Nachteile in Kauf nehmen zu müssen.

Zwar sind symmetrische Mechanismen gerade bei größeren Datenmengen deutlich schneller als asymmetrische, dafür stehen wir bei ersteren vor dem Problem der sicheren Schlüsselübertragung. Denn symmetrisch bedeutet: Der Empfänger benötigt zum Entschlüsseln exakt denselben Schlüssel wie der Sender zum Verschlüsseln. Doch dazu muß der Sender dem Empfänger den Schlüssel auf einem von der Nachricht getrennten und abhörsicheren Wege übergeben, was in der Praxis kaum durchführbar ist.

Daher kommt an dieser Stelle die asymmetrische Verschlüsselung ins Spiel: Mit ihrer Hilfe können wir den symmetrischen Schlüssel zusammen mit der Nachricht sicher an den Empfänger senden. Denn asymmetrisch bedeutet: Sender und Empfänger verfügen über ein komplementäres Schlüsselpaar, bestehend aus einem geheimen und einem öffentlichen Schlüssel (Schlüssel-Schloß-Prinzip).

Seinen geheimen Schlüssel (private key) kennt nur der Empfänger selbst, seinen öffentlichen Schlüssel (public key) kann jener aber an jeden möglichen Sender verteilen. Dieser verschlüsselt dann damit den symmetrischen Schlüssel und schickt ihn zusammen mit der symmetrisch verschlüsselten Nachricht zum Empfänger. Da nur letzterer über den geheimen Schlüssel verfügt, kann auch nur er den symmetrischen Schlüssel dekodieren und damit die Nachricht lesen.

Ein weitere Vorteil hybrider Kryptosysteme ist der Schutz gegen chosen-plaintext Angriffe (Angriffe mit frei wählbarem Klartext), wofür Public Key Verfahren anfällig sind. Auch das symmetrische System wird verbessert, weil der symmetrische Schlüssel erst kurz vor Versand der Nachricht erzeugt und nur für genau diese verwendet wird. Gelangt ein Unbefugter in den Besitz dieses Sitzungsschlüssels, so kann er maximal eine einzige Nachricht lesen. Aber schauen wir uns die Prozedur ein wenig genauer an.

B.1 Verschlüsseln – Daten geschützt übermitteln

OpenPGP benutzt also zwei kryptographische Verfahren: Ein symmetrisches und ein asymmetrisches. Beim symmetrischen Algorithmus (symmetric encryption algorithm) verwenden wir einen Einwegschlüssel (session key) zum Verschlüsseln der Daten.

Weil er nur einmal genau für einen Datensatz verwendet wird, ist der Einwegschlüssel an diesen gebunden. Daher muß er mit der Nachricht übermittelt werden. Dafür benutzen wir dann den asymmetrischen Algorithmus (public key algorithm), mit dem wir den Einwegschlüssel sicher an den Empfänger übermitteln können. Der Ablauf einer verschlüsselten Kommunikation mit OpenPGP sieht folglich so aus:

Nachricht entschlüsseln

Die Komprimierung der Daten vor der Verschlüsselung hat zweierlei Vorteile: Erstens wird die Verschlüsselung aufgrund der verminderten Datenmenge beschleunigt. Zweitens verringert das Komprimierung die Redundanz der Nachricht und erschwert so einen möglichen Angriff durch Kryptoanalyse.

B.2 Signieren – Die Echtheit von Daten prüfen

Das Signieren, also Unterschreiben von Nachrichten, dient der Echtheitsprüfung um Manipulationen an den Daten zu verhindern. Dafür wird ein sogenannter Hashwert aus der zu übermittelnden Nachricht generiert und dann asymmetrisch verschlüsselt, so daß jeder Empfänger durch Abgleich des empfangenen Hashwertes mit einem selbst generierten Hash überprüfen kann, ob die Daten bei der Übermittlung manipuliert worden sind. Der Ablauf gestaltet sich wie folgt:

Nachricht signieren

Signatur überprüfen

Wichtig beim Signieren ist, daß der Hashwert eindeutig der Nachricht zuzuordnen ist, d.h. daß keine zwei verschiedenen Nachrichten denselben Hashwert ergeben dürfen (Kollisionsfreiheit). Ein Hashwert soll eine Art Fingerabdruck der Nachricht sein. Das Signieren des Hashwertes anstatt der gesamten Nachricht hat nicht nur Geschwindigkeitsvorteile, sondern macht auch die separate Nutzung von Dokument und Signatur etwa in Archivierungssystemen möglich.

Nun kann es vorkommen, daß wir eine Nachricht zugleich verschlüsseln und signieren wollen. Auch dies ist mit OpenPGP möglich. Dazu wird zuerst die Signatur nach obigem Schema erzeugt und an die Nachricht angehängt. Anschließend wird die Nachricht zusammen mit der Signatur mit dem symmetrischen Einwegschlüssel chiffriert. Der Einwegschlüssel wird dann wieder mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und der restlichen Nachricht vornangestellt.

B.3 Algorithmen – OpenPGPs Mathematik

Der OpenPGP Standard legt nicht fest, welche Algorithmen für die Verschlüsselung verwendet werden müssen. Für die symmetrische Verschlüsselung gilt: Jeder Anwender kann seine eigene Liste präferierter symmetrischer Algorithmen in seinem eigenen (Sub-)Schlüssel (vgl. 2.5) hinterlegen. Damit diese Liste niemals leer ist, sieht OpenPGP vor, daß TripleDES (TDES) quasi als Rückfallsicherung verwendet wird. TDES ist daher der einzige symmetrische Algorithmus, der standardmäßig implementiert sein muß.

Symmetrische Algorithmen: TripleDES, AES und andere

Der Name TDES geht auf DES (Data Encryption Standard) zurück. DES wurde 1977 vom US National Bureau of Standards (NBS, heute National Institute of Standards and Technology, kurz NIST) trotz vieler Bedenken insbesondere wegen der geringen Schlüssellänge als Kryptostandard eingeführt (FIPS 46). Nachdem im Laufe der 90iger Jahre zahlreiche Angriffe gegen DES erfolgreich waren, stieg das NIST 1999 auf das bereits erwähnte TDES um (FIPS 46-3).

TripleDES erhöht die Schlüssellänge durch dreimalige Verschlüsselung von 56 auf 112 Bits. Für Kundige: Die theoretisch möglichen 168 Bit verringern sich wegen möglicher meet-in-the-middle Angriffen. TripleDES kann heute als sicher eingestuft werden, verliert aber seit 2001 durch seinen deutlich effizienteren Nachfolger AES an Bedeutung.

AES (Advanced Encryption Standard) ist genauer gesagt der Nachfolger von DES. Dazu hatte das NIST ein mehrjähriges Auswahlverfahren durchgeführt. Als Sieger ging im Oktober 2000 der nach seinen belgischen Erfindern Vincent Rijmen und Joan Daemen benannte Rijndael-Algorithmus hervor. Dieser überzeugte vor allem durch seine Schnelligkeit und wird seitdem als AES bezeichnet.

Viele Anwendungen – nicht nur gemäß OpenPGP – verwenden daher standardmäßig nicht mehr TripleDES, sondern eine AES-Variante mit 128, 192 oder 256 Bit Schlüssellänge. Neben AES kennt OpenPGP die patentierten symmetrischen Algorithmen CAST5 und den schweizer IDEA, sowie Bruce Schneiers Blowfish und Twofish.

Asymmetrische Algorithmen

Kommen wir zu den asymmetrischen Algorithmen (public key algorithm). Zwar legt OpenPGP auch hier nicht fest, welche Algorithmen der Anwender benutzen muß – gewöhnlich wählt der Benutzer die Algorithmen bei der Schlüsselerzeugung aus – aber laut Spezifikation müssen bestimmte symmetrische Algorithmen unterstützt werden: DSA für das Signieren und ElGamal für das Verschlüsseln. Außerdem sollte der seit September 2001 patentfreie RSA-Algorithmus wie bereits in PGP eingebaut sein (vgl. 1.2).

Die Sicherheit von ElGamal basiert in Anlehnung an das Diffie-Hellman-Verfahren auf der mathematischen Schwierigkeit diskrete Logarithmen über endlichen Körpern zu berechnen. Der mit ElGamal verwandte DSA-Algorithmus ist die Realisierung des Digital Signature Standard (DSS) des NIST von 1994. Zu DSA sei zu sagen, daß Gus Simmons 1993 einen verdeckten Kanal darin entdeckte. Mit Hilfe dieses verdeckten Kanals kann jemand eine geheime Unterschrift einschleusen, die nur derjenige lesen kann, der den Schlüssel kennt.

Bruce Schneier warnt daher davor, DSS-Implementierungen von nicht vertrauenswürdigen Entwicklern zu vertrauen. Für Kundige: Die Verfügbarkeit des Quellcodes wie bei GnuPG kann hier weiterhelfen, um das Erzeugen der PK-Parameter zu überprüfen.

Ein möglicher Signaturalgorithmus für die Zukunft könnte der japanische Efficient Signature Algorithm (ESIGN) sein, entwickelt von der japanischen Nippon Telegraph and Telephone Corporation (NTT). Die Autoren halten ESIGN für mindestens genauso sicher wie RSA oder Rabin. Zugleich ist es aber wesentlich schneller.

Weitere asymmetrische Algorithmen sind der zu DSA ähnliche ECDSA (Elliptic Curve Digital Signature Algorithm) und Diffie-Hellman X9.42 (RFC2631). Anzumerken bleibt, daß ElGamal und RSA für das Verschlüsseln und Signieren gleichermaßen verwendet werden können.

Kompressionsverfahren

Bei den Kompressionsverfahren verweist OpenPGP auf drei Algorithmen, deren Implementierung aber wiederum nicht verpflichtend ist. Empfohlen wird als Standard ZIP (RFC1951), optional können weitere Verfahren wie etwa ZLIB (RFC1950) und das neuere BZIP2 verwendet werden.

Hash-Algorithmen

Nun fehlen uns noch die Hash-Algorithmen. Hier sieht OpenPGP die Unterstützung von SHA1 (Secure Hash Algorithm) gemäß Secure Hash Standard (SHS) des NIST zwingend vor. Desweiteren wird die Implementierung von MD5 empfohlen, der ebenso wie SHA1 aus MD4 hervorgegangen ist.

Gegen SHA1 und auch gegen MD5 sind Angriffe für reduzierte Varianten bekannt, so daß beide Verfahren als gefährdet betrachtet werden müssen. Für Kundige: SHA erweitert MD4 um eine Expansionstransformation, eine zusätzliche Runde und erzielt einen besseren Lawineneffekt. MD5 verwendet gegenüber MD4 ein besseres Bit-Hashing, einer zusätzlichen Runde und hat ebenfalls einen besseren Lawineneffekt.

Bis bessere Algorithmen gefunden sind, kann man gemäß OpenPGP auf SHA256, SHA384 und SHA512 mit entsprechend längeren Schlüsseln ausweichen. Weitere Hash-Algorithmen sind RIPEMD160 (RACE Integrity Primitives Evaluation Message Digest) und der recht langsame MD2. Andere Algorithmen wie TIGER/192 oder HAVAL finden weniger Verwendung.

B.4 Kodieren – ASCII und MIME

Wir kommen nun zum 7Bit-Problem. OpenPGP stellt verschlüsselte Nachrichten standardmäßig durch binäre Zeichenfolgen mit einer Länge von 8 Bit dar. Zum interoperablen, sicheren Transport der Daten wird deren binäre Darstellung mit Base64 in druckbare ASCII-Zeichen mit einer Länge 7 Bit umgewandelt (ASCII-Hülle). Für OpenPGP wird zusätzlich eine CRC-Prüfsumme von 24 Bit angehängt. Wir nennen dieses um die Prüfsumme erweiterte Verfahren Radix64.

Nicht nur die verschlüsselte Nachricht kann ASCII-kodiert werden, sondern auch Signaturen und die einzelnen Schlüssel. Um die verschiedenen Inhalte unterscheiden zu können, wird jeder ASCII-Hülle ein ensprechender Kopf vorangestellt (header), aus dem hervorgeht, ob es sich um eine Nachricht, eine Signatur oder einen öffentlichen bzw. privaten Schlüssel handelt.

 -----BEGIN PGP MESSAGE-----
  Version: OpenPrivacy 0.99
  .
  yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
  vBSFjNSiVHsuAA==
  =njUN
  -----END PGP MESSAGE-----
	

Mit der soeben geschilderten Methode lassen sich verschlüsselte Inhalte direkt im Nachrichtentext einer Email übermitteln (PGP/Inline). Mögliche Anhänge müssen jedoch separat verschlüsselt werden. Dieses Problem kann man lösen, indem man OpenPGP mit dem MIME-Standard (Multipurpose Internet Mail Extensions) verheiratet. Das Ergebnis ist PGP/MIME, spezifiziert im RFC3156 (MIME Security with OpenPGP).

Bereits 1995 wurde im RFC1847 (Security Multiparts for MIME) eine elegante Lösung zum Signieren und Verschlüsseln für MIME entwurfen. Dabei definierte man einfach entsprechend zwei neue Inhaltstypen: Multipart/Signed und Multipart/Encrypted. OpenPGP greift diese Inhaltstypen auf und konkretisiert sie wie folgt: application/pgp-encrypted zum Verschlüsseln, application/pgp-signature zum Signieren und application/pgp-keys zum Übertragen von öffentlichen Schlüsseln.

Verschlüsselte wie signierte Nachrichten gemäß PGP/MIME bestehen aus zwei Teilen. Bei verschlüsselten Nachrichten besteht der erste Teil (application/pgp-encrypted) lediglich aus der Versionsnummer und der zweite Teil aus der eigentlich verschlüsselten Nachricht (application/octet-stream). Bei signierten Nachrichten ist es gerade umgekehrt: Der erste Teil ist die signierte Nachricht (z.B. text/plain) und der zweite Teil die Signatur (application/pgp-signature). Zusätzlich ist bei signierten MIME-Nachrichten der verwendete Hashalgorithmus angegeben.

From: Peter Ulber 
      To: Max Mustermann 
      Mime-Version: 1.0
      .
      Content-Type: multipart/encrypted; boundary=foo;
         protocol="application/pgp-encrypted"
      .
      --foo
      Content-Type: application/pgp-encrypted
      .
      Version: 1
      .
      --foo
      Content-Type: application/octet-stream
      .
      -----BEGIN PGP MESSAGE-----
      Version: 2.6.2
      .
      hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87
      eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8
      g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46w
      AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8Nxbu
      1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
      =zzaA
      -----END PGP MESSAGE-----
      .
      --foo--
	

Soll eine Nachricht signiert und verschlüsselt werden, so wird sie nach RFC1847 zuerst signiert und dann verschlüsselt (eine weitere kombinierte Variante wird in RFC3156, Kapitel 6.2 beschrieben). Nachrichten zur Schlüsselverteilung bestehen lediglich aus dem ASCII-kodierten öffentlichen Schlüssel (application/pgp-keys).

B.5 Schlüssel – Formate und Eigenschaften

Zur asymmetrischen Verschlüsselung und Signierung werden entsprechende Schlüsselpaare gebraucht, bestehend aus einem privaten und einem öffentlichen Schlüssel. Merke: Der private Schlüssel umfaßt immer auch den zugehörigen öffentlichen Schlüssel, nicht aber umgekehrt. OpenPGP macht nun genauere Angaben über das Format dieser Schlüsselpaare.

Schlüsselversionen V3 und V4

Grundsätzlich unterscheiden wir das ältere von PGP 2.6.3 stammende V3-Format und das neuere V4-Format, welches bei OpenPGP den eigentlichen Standard darstellt. V3-Schlüsselpaare wurden für RSA entwickelt und dienen gleichermaßen der Signierung und der Verschlüsselung mit RSA. V3 legt auch die anderen zu verwendenden Algorithmen fest: IDEA für symmetrische Chiffrierung und MD5 für den Hash. Die maximale RSA-Schlüssellänge beträgt hier 2048 Bit.

Gemäß V4 unterscheiden wir zwischen Hauptsignierschlüssel und mehreren möglichen Unterschlüsseln zur Verschlüsselung oder Signierung. Damit haben wir es gewöhnlich mit mindestens zwei Schlüsselpaaren zu tun: Einem Hauptschlüsselpaar zur Signierung und einem Unterschlüsselpaar zur Verschlüsselung. Es können also zum Signieren und Verschlüsseln verschiedene Algorithmen verwendet werden. OpenPGP schreibt vor, daß DSA zum Signieren und ElGamal zum Verschlüsseln unterstützt werden müssen, und empfiehlt vor allem zur Abwärtskompatibilität die Unterstützung von RSA.

V4 macht keine verbindlichen Vorgaben über die zu verwendenden Algorithmen, sondern setzt stattdessen auf eine vom Benutzer konfigurierbare Liste von präferierten symmetrischen bzw. Hash- und Kompressionsverfahren. Mit V4 hat man außerdem das Schlüsselvertrauen (via Signatur) um das Benutzervertrauen (owner trust) ergänzt (vgl. 2.6). Schließlich wurden gegenüber V3 einige kleinere Sicherheitslücken geschlossen.

Schlüssel identifizieren: ID und Fingerabdruck

Zur Identifikation des Schlüssels benutzt man eine Schlüssel-ID (key id) und den Fingerabdruck (fingerprint). Die ID besteht bei V3 aus den letzten 64 Bit des öffentlichen RSA-Schlüssels und bei V4 aus den letzten 64 Bit des Fingerabdrucks. Der Fingerabdruck ist bei V3 ein MD5-Hash und bei V4 ein SHA1-Hash (160 Bit) des Schlüsselmaterials. Somit ist klar, daß zur sicheren Identifikation eines V4-Schlüssels letztlich der gesamte Fingerabdruck heranzuziehen ist und nicht bloß die Schlüssel-ID.

Key ID = F16ADF3C
Fingerprint = 87D4 D237 859F 890C C15A 1D3F 8DB5 E59B F16A DF3C

Um eine (Sub-)Schlüssel an einen bestimmten Benutzer zu binden, werden Benutzer-IDs (uid), bestehend aus Name und Email-Adresse, verwendet. Jeder Benutzer-ID – zum Beispiel für verschiedene Email-Adressen – können eigene Listen für bevorzugte Algorithmen zugeordnet werden. Der Hauptsignierschlüssel wird dann der primären Benutzer-ID zugeordnet. Ändern sich die Angaben der Benutzer-ID, kann diese durch eine entsprechende Signatur widerrufen werden.

pub   1024D/F16ADF3C 2006-10-15
      Key fingerprint = 87D4D237 859F890C C15A1D3F 8DB5E59B F16ADF3C
uid                  Peter Ulber 
uid                  Peter Ulber 
uid                  Peter Ulber 
uid                  [jpeg image of size 3517]
sub   4096g/E4697334 2006-10-15 [expires: 2007-11-18]
	

Schlüssel widerrufen

Schlüssel können bei Bedarf oder nach einer festgelegten Zeit widerrufen werden. Letzteres geschieht dadurch, daß man bei der Erstellung eines neuen Schlüssels seine Lebensdauer angibt. Mit deren Ablauf wird der Schlüssel als ‚widerrufen‘ signiert (revoked). Der Widerruf kann bei Bedarf manuell entweder unter Verwendung eines separaten Widerrufszertifikats geschehen – dieses wird dann zum Zeitpunkt X dem zu widerrufenden Schlüssel zugeordnet – oder direkt durch eine entsprechende Widerrufssignatur.

Beim Schlüsselwiderruf können entweder einzelne Unterschlüssel als ungültig markiert werden – dies beeinträchtigt nicht die Funktion der anderen Subschlüssel – oder der Hauptsignierschlüssel. Wenn man den Hauptsignierschlüssel widerruft, werden automatisch alle Unterschlüssel mit ungültig gemacht.

-----BEGIN PGP PRIVATE KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
.
mRWH4MbexVAXoOFnECmdTDVJgRkP0Tu0cAbsEmMAAwUH/j08pEwexaw/oMUiBR1x
TyF4zghFNeCZPaaCI1LdCwFun4ydAlEEQJZi2RAIAOIkRJzufidS5pWSUkazsnvv
fBhU8Y9oHGJBfi3x7O8E6JSxSH3LSGdtd7a4q3kvml2JikX6IdYPEX0lyVwakTua
9GAAB8BEwY1CuoYeV/gvO1SEmgDfHCPufWyPAr1o4vvQArQnUGV0ZXIgVWxiZXIg
PHBldGVyQGRlcmdyb3NzZWJydWRlci5vcmc+iFcEExECABcFAkCWYsYFCwcKAwQD
FQMCAxYCAQIXgAAKCRDCZqyeBZYp+dkKAKCewLgsq1tjiJ2ejTF9+B+hVHRSDQCf
TyF4zghFNeCZPaaCI1LdCwFun4ydAlEEQJZi2RAIAOIkRJzufidS5pWSUkazsnvv
eAzdplkfbS/YajiGvbb1KnNX7LczWbhOo4iiIpwcyii9q20W7cRTQ8sxqwOC4/D9
GFPongzqptV/sW8u/txieGdB2pzoHm0EEteCVmHH7W0DRwLc0QNUbOPMk3qxNTFj
RtbBDpmqG1CjuSRc88eFJyQ6VKt7rttxU/XsxPK4KqtRfSMQOZRTg/Ckr3oaDtBw
EohvOq93zV/dYIKopBIiM5JM16LXUCkVsS56PSCwq0O3wXu4tEV9dz2dVwCgxqH7
iyhk9cViYtJzUgQlP1wSrLji9gcA2YIVMyQiFaY6cgV5NVQ7e/WmHz7kZnDoTBmk
bQgAreu7WxhJxxNXygnBnLImGm2/71g0wFMQ85n2s5kwdz4k3k1lXjgg6fw5ID1A
rIn3l/5H7cf3e9jnvfoMA21jlQ70Pb4djj8ElirmA62s1Fpqg6y+zijbTB9/FsEV
kVlZOUApnb/bEiAUiHIwi8eyylCphSL3Fb2wUoZQAeFrJ4i8Wrc4gM1cs7a1iX5X
gnZvT1SSvUUFfXiauso7xxSQmRWH4MbexVAXoOFnECmdTDVJgRkP0Tu0cAbsEmMA
AwUH/j08pEwexaw/oMUiBR1xAmEfRdkc2duvhf8Bn+vmuj5/cg3mEu3iSLjGnkyx
/9Dq5U+jpqMDHGxRS4hIFBED/18zlgwhk+kcGG7jBq8EpfKdx8AX2F+AxmUkttyx
Zdjp9yhJFSuA7sgZZeV2pSsWQPGwva8Udsxedb0pDi5rHNIwh/j8yCTE6u3FjRTB
pLGVtMhf6meX9frag0ytsZuyRw98WMb2KQh5htgjGGCbn6qVBQ5d26PVVeKdPQuF
lqpEBACABrWnQptNbpBBsaocdiRz+LAezvGJJ/lKl+6tUvd1RHCGimhVjOqer6hN
4pdPiYEzrl1LflcS3bwSmtrJFsQk5Wr4aRID65fp9bIUduQDL3IIMfDIuceLxk8g
CwePz4xD2ZYlH/cY+o9dBpdpJD4iSpenJa+RPzvJVmlCSkztF/8DAwKmBjIQMmI7
f11yKF4PKlD4jRrsj9LYdSzz/NCTvQO05braBKaxTrrhlSjNjHZ+D4acEIhj/nbT
ldPuDiP/f9IM+xmbSQehWk9VNPr/AwMCpgYyEDJiO/BgRaD2cpqSY1Y2vo+SHu+7
lQHPBECWYsYRBACZohN2L/Or2x7lfsM3aLar11bol/LLm/ijws91u9BhKYRT5jMg
BQJAlmLZAAoJEMJmrJ4Flin5PGkAoLQTtfPLQSoX9pvC3idUTwoB2WYeAJ0UO0Ff
6vTfU4dVY1MxvPY46+LPXQ==
=4U9b
-----END PGP PRIVATE KEY BLOCK-----
	

Weitere Schlüsselattribute (Signaturen) sind folglich der Zeitpunkt der Erstellung, ein mögliches Ablaufdatum, die Gültigkeit des Schlüssels und Benutzervertrauen (owner trust), sowie eine mögliche Widerrufsignatur. Bevor wir uns der Gültigkeit und dem Vertrauen zuwenden, sei noch kurz etwas zur Aufbewahrung der Schlüssel gesagt.

Üblicherweise werden die privaten und öffentlichen Schlüssel in je einem Schlüsselbund (meist eine Datei) lokal aufbewahrt. Die privaten Schlüssel werden zudem durch ein Paßwort geschützt. Jeder Schlüssel kann prinzipiell aus einem Schlüsselbund exportiert oder umgekehrt in einen solchen importiert werden. Diese Verfahren dienen vor allem dem Austausch öffentlicher Schlüssel im Rahmen des Web of Trust (vgl. 2.6) Um den Export zu verhindern, kann der Schlüssel als nicht-exportierbar markiert werden.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
.
TyF4zghFNeCZPaaCI1LdCwFun4ydAlEEQJZi2RAIAOIkRJzufidS5pWSUkazsnvv
AmEfRdkc2duvhf8Bn+vmuj5/cg3mEu3iSLjGnkyxeAzdplkfbS/YajiGvbb1KnNX
/NCTvQO05braBKaxTrrhlSjNjHZ+D4acEIhj/nbTldPuDiP/f9IM+xmbSQehWk9V
NPqIRgQYEQIABgUCQJZi2QAKCRDCZqyeBZYp+TxpAKC0E7Xzy0EqF/abwt4nVE8K
mQGiBECWYsYRBACZohN2L/Or2x7lfsM3aLar11bol/LLm/ijws91u9BhKYRT5jMg
fBhU8Y9oHGJBfi3x7O8E6JSxSH3LSGdtd7a4q3kvml2JikX6IdYPEX0lyVwakTua
EohvOq93zV/dYIKopBIiM5JM16LXUCkVsS56PSCwq0O3wXu4tEV9dz2dVwCgxqH7
/9Dq5U+jpqMDHGxRS4hIFBED/18zlgwhk+kcGG7jBq8EpfKdx8AX2F+AxmUkttyx
Zdjp9yhJFSuA7sgZZeV2pSsWQPGwva8Udsxedb0pDi5rHNIwh/j8yCTE6u3FjRTB
pLGVtMhf6meX9frag0ytsZuyRw98WMb2KQh5htgjGGCbn6qVBQ5d26PVVeKdPQuF
lqpEBACABrWnQptNbpBBsaocdiRz+LAezvGJJ/lKl+6tUvd1RHCGimhVjOqer6hN
4pdPiYEzrl1LflcS3bwSmtrJFsQk5Wr4aRID65fp9bIUduQDL3IIMfDIuceLxk8g
9gcA2YIVMyQiFaY6cgV5NVQ7e/WmHz7kZnDoTBmkbQgAreu7WxhJxxNXygnBnLIm
rMHD2bzQC/nWv6JKCGIe0LQnUGV0ZXIgVWxiZXIgPHBldGVyQGRlcmdyb3NzZWJy
dWRlci5vcmc+iFcEExECABcFAkCWYsYFCwcKAwQDFQMCAxYCAQIXgAAKCRDCZqye
BZYp+dkKAKCewLgsq1tjiJ2ejTF9+B+hVHRSDQCfTyF4zghFNeCZPaaCI1LdCwFu
n4y5Ag0EQJZi2RAIAOIkRJzufidS5pWSUkazsnvviyhk9cViYtJzUgQlP1wSrLji
7LczWbhOo4iiIpwcyii9q20W7cRTQ8sxqwOC4/D9GFPongzqptV/sW8u/txieGdB
2pzoHm0EEteCVmHH7W0DRwLc0QNUbOPMk3qxNTFjRtbBDpmqG1CjuSRc88eFJyQ6
VKt7rttxU/XsxPK4KqtRfSMQOZRTg/Ckr3oaDtBwf11yKF4PKlD4jRrsj9LYdSzz
ylCphSL3Fb2wUoZQAeFrJ4i8Wrc4gM1cs7a1iX5XgnZvT1SSvUUFfXiauso7xxSQ
Gm2/71g0wFMQ85n2s5kwdz4k3k1lXjgg6fw5ID1ArIn3l/5H7cf3e9jnvfoMA21j
lQ70Pb4djj8ElirmA62s1Fpqg6y+zijbTB9/FsEVkVlZOUApnb/bEiAUiHIwi8ey
CwePz4xD2ZYlH/cY+o9dBpdpJD4iSpenJa+RPzvJVmlCSkztF4hJBCARAgAJBQJA
lmUTAh0CAAoJEMJmrJ4Flin52mIAnjzRHXHLmrxZqCi9TVgyvs7dZMEiAJ9tcBkW
AdlmHgCdFDtBX+r031OHVWNTMbz2OOviz10=
=3WiQ
-----END PGP PUBLIC KEY BLOCK-----
	

Achtung: Schlüsselattribute sind Signaturen und Signaturen werden etwa imRahmen von Schlüsselvalidierungen auch Zertifikate genannt. Wir unterscheiden wie bei den Schlüsseln zwei Versionen V3 und V4 von Signaturen. Die obigen Ausführungen zu den Schlüsselattributen beziehen sich nur auf V4-Signaturen. V3-Signaturen bieten diese Möglichkeiten gar nicht und wurden nur der geforderten Abwärtskompatibilität zu PGP 2.6 wegen aufgeführt.

B.6 Vertrauen – Das Web of Trust

Allein die Stärke der Algorithmen macht die verschlüsselte Kommunikation nicht sicher. Wir müssen auch einen Weg finden, die Echtheit der Schlüssel überprüfen und mögliche Manipulationen erkennen können. Dafür benutzt OpenPGP zwei interagierende Konzepte: Die Gültigkeit des Schlüssels und das Vertrauen in den Benutzer (owner trust). Durch Interaktion beider Konzepte kann sich zwischen den verschiedenen Kommunikationspartnern nach und nach ein Netzwerk des Vertrauens bilden (Web of Trust).

Schlüsselgültigkeit versus Benutzervertrauen

Wir bezeichnen dann einen Schlüssel als gültig, wenn wir von seiner Echtheit überzeugt sind. Wir vertrauen dann einem anderen Benutzer, wenn wir überzeugt sind, daß jener bei der Echtheitsprüfung von Schlüsseln mindestens genauso sorgfältig vorgeht wie man selbst. Der Ausspruch des Vertrauens bestimmt so den Wert der Echtheitsprüfung des anderen Benutzers. Und die Erklärung der Gültigkeit eines Schlüssels bezieht sich auf dessen Echtheit.

Schauen wir uns zuerst die Bestimmung der Echtheit eines Schlüssels an. Erhalten wir von unserem Kommunikationspartner etwa per Email seinen öffentlichen Schlüssel, können wir nie sicher sein, daß der Schlüssel wirklich unverfälscht bei uns angekommen ist. Daher müssen wir den Schlüssel vor der Verwendung prüfen. Am besten geht dies, indem wir uns von unserem Kommunikationspartner zumindest den Fingerabdruck plus eventuell andere Attribute seines Schlüssels auf einem sicheren Kanal geben lassen (etwa persönlich).

Dann generieren wir unsererseits aus dem empfangenen Schlüssel ebenfalls dessen Fingerabdruck und vergleichen beide. Stimmen sie überein, sind die Schlüssel echt, und wir können dies mit einer Signatur des fremden Schlüssels durch unseren geheimen (Haupt-)signierschlüssel bestätigen. Damit erkennen wir den neuen Schlüssel als gültig an. Diese Signatur kann lokal auf unseren Schlüsselbund beschränkt oder zusammen mit dem signierten Schlüssel exportierbar sein.

Vertrauensniveau und Vertrauensmenge

Erst nach der Gültigkeitsprüfung eines Schlüssels können wir zusätzlich das Benutzervertrauen des betreffenden Schlüsselinhabers einstellen. Hierbei unterscheiden wir verschiedene Vertrauensniveaus (trust level 0,…,n) und die Vertrauensmenge (trust amount 0-255) auf dem gewählten Level. Die Idee: Stufen wir eine Schlüssel auf Level i ein, so ist dessen Besitzer für uns vertrauenswürdig andere Schlüssel mit einem Level kleiner i auf Echtheit zu prüfen.

Level 0 ist demnach äquivalent mit der bloßen Echtheitsprüfung. Level 1 bedeutet, daß wir die Signaturen des Betreffenden unter Schlüssel vom Level 0 anerkennen. Damit haben wir es quasi mit einer Zertifikatsauthorität (CA) zu tun. Level 2 heißt demzufolge, daß Schlüssel mit Level 0 oder 1 signiert werden können und von uns anerkannt werden, und so weiter.

Auf dem gesetzten Vertrauensniveau können wir nun noch die Vertrauensmenge festlegen. Dabei unterscheidet OpenPGP grundsätzlich zwischen teilweise (Werte kleiner 120) und vollem Vertrauen (120-255). Anwendungen sollten 60 für marginales (teilweises) und 120 für volles Vertrauen verwenden. Dieses Unterscheidung wird eingesetzt, um die Anzahl der Signaturen zu bestimmen, die notwendig sind, damit ein Schlüssel als gültig erachtet wird. Wir könnten dann zum Beispiel mindestens eine voll vertrauenswürdige Unterschrift oder zwei teilweise vertrauenswürdige Unterschriften verlangen.

Schauen wir uns dazu die Idee des Web of Trust (WoT) kurz an einem Beispiel an: Unser fiktives WoT bestehe aus Jan, Ines und Udo. Ines könnte nun ihren öffentlichen Schlüssel Jan persönlich übergeben, so daß Jan ihren Schlüssel signiert und damit für gültig erklärt. Dann gibt er Ines den signierten Schlüssel zurück und behält seinerseits eine Kopie davon.

Wollte nun Ines mit Udo kommunizieren, sendet sie ihm eine Kopie des von Jan signierten Schlüssels. Udo verfüge nun bereits über Jans öffentlichen Schlüssel und Udo vertraue den Echtheitsprüfungen von Jan (Level 1). Dann braucht Udo nur noch die Unterschrift von Jan mit Hilfe des öffentlichen Schlüssels von Jan verifizieren und kann dann den Schlüssel von Ines als gültig bestätigen ohne selbst mit Ines reden zu müssen.

Größeres Beispiel eines fiktiven Web of Trust zum Nachdenken

Diese Methode hat den Vorteil, daß man nicht jeden einzelnen Schlüssel per Hand überprüfen muß, sondern je nach Vertrauen auf bereits vorhandene Signaturen eines zu prüfenden Schlüssel zurückgreifen kann. Zusammen erlauben Benutzervertrauen und Schlüsselgültigkeit ein flexibles Schlüsselmanagement auf Basis eines flachen Web of Trust und bzw. oder hierarchischer Zertifizierungsinstanzen.

Ein wesentlicher Unterschied zwischen Benutzervertrauen und Schlüsselgültigkeit ist, daß die Gültigkeitssignaturen mit dem Schlüssel exportiert werden können, nicht aber das Benutzervertrauen (trust packet). Das Benutzervertrauen ist nur für den lokalen Schlüsselbund gültig und wird zum Beispiel bei der Implentierung von OpenPGP in GnuPG in einer separaten Datei gespeichert.

B.7 Sicherheit – Möglichkeiten und Grenzen

Von Laien wird die Sicherheit eines Kryptosystems oft mit der Sicherheit der verwendendeten Algorithmen gleichgesetzt. Dem ist natürlich nicht so. Die Sicherheit des Kryptosytems hängt von einer Vielzahl von Faktoren ab. Schauen wir uns also jetzt die wichtigsten Sicherheitsaspekte von OpenPGP an. Einige wurden bereits in vorhergehenden Abschnitten angeschnitten.

Da OpenPGP keine abschließende Liste mit zu benutzenden Algorithmen angibt, kann man in dieser Hinsicht nur bedingt über die Sicherheitsrisiken sprechen. Zwar setzt OpenPGP auf Standardverfahren wie TDES, DSA und ElGamal, an deren Zuverlässigkeit die Sicherheit von OpenPGP aber nicht zwingend gebunden ist. Bessere Algorithmen lassen sich ja bei Bedarf hinzufügen, wie das Beispiel AES zeigt.

Klar ist: Die Sicherheit der Algorithmen beruht nicht auf deren Geheimhaltung, sondern auf ihrem mathematischen Verfahren. Asymmetrische Kryptosysteme mit einem Schlüsselpaar setzen dabei auf die Schwierigkeit, den privaten aus dem öffentlichen Schlüssel zu berechnen. Damit lassen sich die zur Chiffrierung notwendigen Schlüssel auch über unsichere Kanäle verteilen, ohne den Schlüssel zur Dechiffrierung zu gefährden. In Verbindung mit den symmetrischen Sitzungsschlüsseln kann zudem chosen-plaintext Angriffen vorgebeugt werden.

Bei der Verteilung öffentlicher Schlüssel dienen die Signaturen im Rahmen des Web of Trust potentiellen Man-In-The-Middle Angriffen. Schlüssel sollten daher nur dann signiert werden, wenn sie via Fingerabdruck (und weiteren Attributen) auf Echtheit überprüft worden sind. Auch eine persönliche Übergabe ist hilfreich. Zusammen mit dem Benutzervertrauen ist so auch der Aufbau von besonderen Zertifizierungsinstanzen möglich.

Eigensignaturen

An dieser Stelle sei auf den Sinn von Eigensignaturen eingegangen. Das sofortige Signieren der User-IDs neu erzeugter Schlüssel beugt Denial of Service Attacken (DOS) vor, d.h. jemand kann mir die Zustellung an mich gerichteter Nachrichten vorenthalten. Hintergrund: Die User-IDs in unsignierten öffentlichen Schlüsseln können beliebig verändert werden, z.B. kann ein Angreifer die Email-Adresse manipulieren, so daß die an mich gerichteten Emails jetzt an ihn gesendet werden.

Wurde die User-ID hingegen vorher von mir selbst signiert, würde eine mögliche Manipulation auffallen, da der Signaturhash Informationen der User-ID beinhaltet. Der Fingerabdruck würde nicht weiterhelfen, da Änderungen an der User-ID nicht in den Fingerabdruck eingehen. Merke weiter: Eigensignaturen sind keine Echtheitsprüfungen im Sinne des Web of Trust, da ein Angreifer, der den ganzen Schlüssel fälscht, diesen mit dem passenden geheimen Schlüssel unterschrieben haben könnte.

Neben der Eigensignatur der User-ID (certification signatures) gegen DOS-Angriffe kann man nach OpenPGP auch die einzelnen Unterschlüssel unterschreiben (subkey binding signature) und beugt in Ergänzung zum Fingerabdruck Verfälschungen der Schlüssel vor. Auch kann der der gesamte Schlüssel inklusive aller Unterschlüssel und User-IDs signiert werden (direct-key signature).

Schlüsselserver

Die Eigensignatur zumindest der User-ID ist von Bedeutung, da öffentliche Schlüssel meist über frei zugängliche Schlüsselserver verteilt werden, welche die Identität des Benutzers bis dato nicht prüfen. Zu den Schlüsselservern merke man sich außerdem, daß zwar immer neue Schlüssel auf den Server hochgeladen werden können, das Löschen einzelner – auch der eigenen – Schlüssel aber bis dato aus genanntem Grund unmöglich ist.

Schlüsselserver der zweiten Generation mit neuen Funktionen befinden sich noch in der Entwicklung. Hinweis: Die PGP Corporation bietet bereits einen Schlüsselserver mit Identifizierung des Benutzers per Email an. Bei diesem Schlüsselserver lassen sich eigene Schlüssel nicht nur hochladen, sondern auch wieder löschen. Achtung: Die Authentifizierung per Email ist nicht hundertprozentig zuverlässig. Vor Gebrauch lese man daher die entsprechenden Sicherheitshinweise!

Der private Schlüssel bedarf im Gegensatz zum öffentlichen eines ungleich stärkeren Schutzes. Gewöhnlich bedient man sich einer sicheren Passphrase als letzte Hürde, so daß selbst ein sich im Besitz des privaten Schlüssel(bundes) befindender Angreifer nicht ohne weiteres Zugriff auf den geheimen Schlüssel erhält. Grundsätzlich sollte aber darauf geachtet werden, daß kein Dritter überhaupt in den Besitz des privaten Schlüssel(bundes) gelangt. An dieser Stelle kommen sichere und ordentlich administrierte Systeme sowie sichere Hardware ins Spiel.

Schlüssel widerrufen

Sollte der geheime Schlüsssel doch einmal kompromittiert worden sein, so bietet OpenPGP die Möglichkeit des Widerrufs. Dazu wird mit Hilfe eines entsprechenden Widerrufsschlüssels (revocation key4) eine Widerrufssignatur an den Schlüssel angefügt, der ihn als ungültig markiert. Neben der Kompromittierung des Schlüssels oder der User-ID sind auch profanere Gründe für einen Widerruf denkbar: Vielleicht möchte der Besitzer auf einen stärkeren Schlüssel umsteigen oder erneuert prinzipiell alle Jahre seine Schlüssel. Der Grund des Rückrufs geht in den Widerruf mit ein.

Um auch bei Verlust des privaten Schlüssels einen Widerruf durchführen zu können, ist es zu empfehlen, den Widerrufsschlüssel (auch Widerrufszertifikat genannt) sofort nach Erzeugen des eigentlichen Schlüsselpaares zu generieren und separat von diesem aufzubewahren. Neben dem Schlüssel kann auch lediglich die Signatur eine User-ID widerrufen werden (cert revocation), etwa weil man die Email-Adresse in der User-ID ändern möchte.

Der Widerruf wird allgemein als das schwächste Glied des ganzen Systems angesehen, da es keine Garantie gibt, daß der widerrufene Schlüssel nicht doch von irgendjemand benutzt wird. Ein Grund kann etwa sein, daß der Widerruf nicht alle Betroffenen erreicht. Neue Funktionen zukünftiger Schlüsselserver wie bei dem der PGP Corporation könnten hier Verbesserungen bringen.

Der Vollständigkeit halber sei ein wichtiger Vorteil von OpenPGP gegenüber Privacy-Enhanced Mail (PEM) genannt: Während Nachrichten nach OpenPGP in ihrem Header nur die Key-ID stehen haben, finden wir bei PEM-Headern zusätzliche Infos etwa zu den verwendeten Algorithmen, was einem möglichen Angreifer die Arbeit erleichtern kann – ein kleiner Sicherheitsvorteil von OpenPGP gegenüber PEM.

C. Praxis

C.1 Implementierung: GnuPG und Co.

Die beiden bekanntesten Implementierungen von OpenPGP sind gewiß GnuPG und PGP. Der GNU Privacy Guard (GnuPG) wurde Mitte der 90iger Jahre vom deutschen Softwareentwickler Werner Koch geschrieben und 1997 erstmals veröffentlicht. Hinter der Entwicklung von GnuPG steht neben weiteren Entwicklern die Free Software Foundation (FSF); GnuPG ist – wie der Name schon vermuten läßt – Teil des GNU-Projektes.

Wesentliches Merkmal von GnuPG ist die freie Verfügbarkeit inklusive Quellcode gemäß der GNU General Public License (GPL). Dies läßt auf einen wichtigen Grund für die Entwicklung von GnuPG schließen: Die Patentprobleme von Zimmermanns PGP Anfang der 90iger Jahre. Einen weiterer Schub dürfte der Verschluß des Quellcodes von PGP durch NAI im Jahre 2000 gewesen sein (vgl. 1.2).

GnuPG gibt es für alle gängigen Betriebssysteme. Während GnuPG am Anfang für Laien nur schwer zu bedienen war, machen graphischen Oberflächen die Benutzung heute auch für Einsteiger machbar. Unter Unix bzw. GNU/Linux seien neben GPA vor allem Seahorse für Gnome und Kgpg für KDE genannt. Unter Windows finden wir ebenfalls GPA sowie WinPT und GPGShell. Für Mac OS X gibt es den Mac GNU Privacy Guard.

GnuPG kann jeder auf der Projektseite – dort finden sich auch weitere Informationen – kostenlos herunterladen Die aktuelle, stabile Version 1.4.5 wurde im August 2006 freigegeben. Zukünftig wird GnuPG neben OpenPGP auch S/MIME unterstützen (in der Entwicklerversion 1.9.20 bereits enthalten).

Das zweite bekannte Produkt ist PGP, ursprünglich von Phil Zimmermann entwickelt und quasi selbst der Vater von OpenPGP. Nach den weiter oben beschriebenen Verwirrungen um PGP (vgl. 1.4) zeigt sich heute die PGP Corporation für das Produkt verantwortlich, die auch den Quellcode von PGP veröffentlicht. Die Lizenz von PGP gibt aber keine Garantie für die freie Verfügbarkeit, so daß ein Fall wie bei NAI für die Zukunft nicht ausgeschlossen werden kann.

Diesem Nachteil von PGP gegenüber GnuPG stehen die Vorteile der leichteren Bedienbarkeit und besseren Dokumentation vor allem für Laien gegenüber. PGP wird in verschiedenen Ausführungen für Privatpersonen, Unternehmen, für den Desktop oder Server angeboten. Die aktuellen Desktop- und Kommandozeilenausgaben tragen die Versionsnummer 9.

Neben GnuPG und PGP gibt es zahlreiche weitere Implementierungen des OpenPGP Standards, zum Beispiel McAfees E-Business Server bzw. Client, Authoras Encrypted Data Gateway Engine, EasyBytes Cryptocx, ASPG Megacrypt, Patrick Townsends Alliance oder Veridis Open-PGP. Ebenso existiert eine eigenständige Implementierung namens BGP in NetBSD unter BSD-Lizenz.

Aufmerksam sei schließlich auf die Implementierung von OpenPGP in Webmail gemacht. Derzeit gibt es zumindest zwei Lösungen: Den Emailprovider Hushmail und Freenigma. Hushmail bietet kostenfreie Webmailaccounts mit OpenPGP-konformer Verschlüsselung und Signierung an. Darüber hinaus läßt sich Hushmail gegen Aufpreis auch mit den üblichen Mailreadern wie Mozilla Thunderbird und Microsoft Outlook nutzen. Positiv zu werten ist, daß Hushmail den Quellcode seines Systems offenlegt.

Hushmail unterstützt OpenPGP für Webmail

Neben Hushmail gibt es seit Mitte 2006 Freenigma. Im Gegensatz zu Hushmail bietet Freenigma nicht selbst sichere Webmailaccounts an, sondern stellt eine Lösung für jeden beliebigen Webmailprovider bereit. Derzeit befindet sich Freenigma noch in der Beta-Phase und ist nur für eine beschränkte Nutzeranzahl für Google Mail, Yahoo! Mail und Hotmail/MSN verfügbar. Die Schlüssel werden auf dem Freenigma-Server mittels GnuPG gelagert. Auf Benutzerseite arbeitet eine Browsererweiterung (derzeit nur für Mozilla Firefox verfügbar) mit Ajax/Javascript, welche die Interaktion mit dem Webmailinterface übernimmt.

C.2 Anwendung: Email und Co.

Kommen wir zum Schluß zur Frage, was man mit OpenPGP Software denn so alles anstellen kann. Die beiden grundlegenden Funktionen von OpenPGP sind das Signieren und das Verschlüsseln. Also frage man sich, welche Daten man signieren bzw. verschlüsseln möchte.

Ein, wenn nicht der Einsatzbereich ist Email. Gewöhnliche Emails ähneln Postkarten, die prinzipiell jeder lesen oder manipulieren kann. OpenPGP kann helfen, einerseits Manipulationen von Emails zu verhindern (Signieren) und andererseits vertrauliche Nachrichten gegenüber den neugieren Augen Dritter zu schützen (Verschlüsseln).

Gerade GnuPG und PGP bieten hier einfache Lösungen für die gängigen Mailprogramme an. Unter Unix und GNU/Linux unterstützen viele Mailreader GnuPG von Haus aus, wie etwa Mutt und Mutt-NG, Pine, Kmail, Evolution, oder Sylpheed Claws. Für Mozilla Thunderbird gibt es systemübergreifend die Erweiterung Enigmail. Unter Windows bietet PGP Desktop 9.0 eine sehr gute Unterstützung von Microsoft Outlook; das GnuPG-Pedant GPGol befindet sich hingegen noch in der Entwicklung. Apple Mail wird von GnuPG und PGP unterstützt.

Mozilla Thunderbird mit OpenPGP-Erweiterung Enigmail

Weiterhin hat OpenPGP eine wichtige Bedeutung für sicheres Instant Messaging, d.h. für elektronische Kurznachrichten. So bietet beispielsweise Jabber eine gute Unterstützung von GnuPG an. Folgende Clients eigenen sich für GnuPG mit Jabber: Psi und JBother unter Windows, Linux und MacOS gleichermaßen; unter Linux Kopete für KDE, Gajim für Gnome und Centericq für die Konsole.

Neben Nachrichten können auch andere Daten, wie Bilder, Textdokumente oder Filme verschlüsselt bzw. signiert werden. PGP bietet zudem mit Whole Disk Encryption die Möglichkeit, ganze Datenträger zu verschlüsseln. Auch der serverseitige Einsatz mit PGP, GnuPG oder mit dem McAfee E-Business Server ist möglich.

Eine wichtige Rolle spielt das Signieren gemäß OpenPGP außerdem bei der Echtheitsprüfung von Software. So bietet zum Beispiel apt-secure unter Debian GNU/Linux die Möglichkeit, die Echtheit eines Softwarepaketes lückenlos zu überprüfen. Diese Möglichkeit wird noch vergleichsweise wenig genutzt; Oft wird Software mit ein paar Klicks aus dem Internet geladen und installiert ohne auch nur eine Sekunde auf die Prüfung der Echtheit zu verwenden. Auch hier kann OpenPGP helfen.

• Aktueller Statusbericht der IETF zu OpenPGP
• OpenPGP Organisation
• Zeittafel zur Entwicklung von PGP
• S/MIME vs. OpenPGP – Eine Entscheidungshilfe
• Der Große Bruder: „Emailverschlüsselung mit GnuPG“
• Ausführliche Anleitungen zu OpenPGP von Kai Raven