GnuPG Anleitung - Seite 8

GnuPG für E-Mails

Noch einmal zur Erinnerung: verschlüsselt wird bei E-Mails mit dem öffentlichen Schlüssel des Kommunikationspartners, bei lokalen Daten entweder mit dem eigenen öffentlichen Schlüssel oder konventionell mit einem symmetrischen Schlüssel und Passphrase. Bei der Signierung kommt immer nur der eigene private Schlüssel zum Einsatz.

Bei der Behandlung von E-Mails mit GnuPG ist die ausschlaggebende Frage, ob die E-Mail Anwendung GnuPG selbst unterstützt (durch Plugins bzw. eigene Routinen) oder nicht. Ist die Unterstützung gegeben, ist die Anwendung von GnuPG kein Problem. Besitzt die E-Mail Anwendung keine Unterstützung, bleibt dem Anwender nur, E-Mails in einem Texteditor zu bearbeiten, GnuPG per Konsole, Skript oder GnuPG GUIs auf Texte anzuwenden und zu versendende Nachrichten in den Nachrichteneditor der E-Mail Anwendung einzufügen, d. h. GnuPG mehr oder weniger manuell zu bedienen.

Auf MUA Frontends, sichere E-Mail-Clients mit PGP/MIME und Mail readers with PGP/MIME RFC 2015 / RFC 3156 support sind E-Mail Anwendungen und Plugins aufgeführt, mit denen GnuPG direkt angewendet werden kann.

Manuell per Zwischenablage

Für E-Mail Anwendungen ohne GnuPG Unterstützung kann eine Nachricht mit dem GPA über die Zwischenablage verschlüsselt oder signiert werden. Dazu kopiert man die verfasste Nachricht in die Zwischenablage, startet den GPA und wählt über das Zwischenablage Icon den Zwischenablage-Editor. Alternativ kann man auch sofort im Zwischenablage-Editor die Nachricht verfassen.

Über das Zwischenablage einfügen Icon kann ein vorgefertigter Text eingefügt oder direkt ein Text verfasst werden:

Anschließend wählt man das Text verschlüsseln oder Text signieren Icon, markiert das Ergebnis, klickt das Auswahl kopieren Icon an und fügt den PGP/INLINE Inhalt aus der Zwischenablage wieder in den Nachrichten-Editor der E-Mail Anwendung ein.

PGP/MIME und PGP/INLINE

PGP/INLINE E-Mail

Neben den bekannten „PGP/INLINE“ signierten oder verschlüsselten Nachrichten, wo der Geheimtext bzw. die Signatur immer den gesamten Nachrichtkörper darstellt, besteht die mit PGP/MIME signierte oder verschlüsselte Nachricht aus mehreren MIME Anteilen.

PGP/MIME basiert auf den IETF Standards RFC 4880 „OpenPGP Message Format“, der die Methoden und den Aufbau OpenPGP verschlüsselter bzw. signierter Daten beschreibt und RFC 3156 „MIME Security with Pretty Good Privacy (PGP)“. RFC 3156 „übersetzt“ die im RFC 1847 „Security Multiparts for MIME Multipart/Signed and Multipart/Encrypted“ definierten MIME Inhaltstypen in OpenPGP spezifische Inhaltstypen zur Verschlüsselung und Signierung und führt dadurch die drei Subtypen „application/pgp-encrypted“, „application/pgp-signature“ und „application/pgp-keys“ ein.

MIME steht für „Multipurpose Internet Mail Extensions“ und definiert grundlegend das Format, das E-Mail Nachrichten zur Übertragung von textuellen und nicht-textuellen Nachrichteninhalten aufweisen. Nach RFC 822 „Standard for the format of ARPA internet text messages“ besteht eine Nachricht nur aus Text, der aus 7-Bit Zeichen des US-ASCII Zeichensatzes besteht. Eine Nachricht enthält danach weder Umlaute bzw. sprachspezifische Zeichen noch andere 8-Bit Zeichen, wie sie in multimedialen, binären Inhalten wie Audio- oder Videodaten vorkommen.

Um diese Beschränkungen aufzuheben, wurden Kodierungsanweisungen für verschiedene Nachrichteninhalte festgelegt, die im Kopf einer E-Mail in mehreren Feldern festgehalten werden: Ein Feld gibt die MIME-Version an, das Content-Type Feld die Art des Inhalts und das Content-Transfer-Encoding Feld das verwendete Kodierungsverfahren. Über den Content-Type: Multipart kann der Nachrichtenkörper in mehrere Abschnitte verschiedenen Inhalts unterteilt werden. Es ist auch möglich, eigene Nachrichteninhaltstypen zu definieren. RFC 1847 definiert also, wie per MIME und E-Mail verschlüsselte und signierte Nachrichteninhalte formatiert werden, RFC 3156 wie das mittels OpenPGP geschieht.

Somit stellt PGP/MIME den eigentlichen Standard für die Übertragung von Nachrichten dar, die mit OpenPGP kompatiblen Programmen wie GnuPG signiert und verschlüsselt werden. Neben der Standardkonformität und problemloseren Handhabung von Kodierungen und Zeichensätzen bietet PGP/MIME den Vorteil der automatischen Mitverschlüsselung von Anhängen. Bei dem PGP/INLINE Verfahren müssen Anhänge gesondert verschlüsselt und angehängt werden, wenn die E-Mail Anwendung keinen eigenen Automatismus anbietet. Wegen der Mitverschlüsselung bei PGP/MIME können Anhänge auch nicht auf der Transportstrecke nachträglich entfernt oder hinzugefügt werden. Daneben erleichtert die „Auslagerung“ der Signatur aus dem Nachrichtenkörper in einen Anhang das Lesen und Beantworten von E-Mails.

PGP/MIME verschlüsselte Nachricht

Die Daten, die per PGP/MIME verschlüsselt werden und die mittels PGP/MIME erzeugten Signaturen liegen zuerst als 8-bit binärer Output vor. Um eine Beschädigung der Signatur durch Zwischenstellen des Versandwegs zu verhindern, werden die Daten mittels Quoted-Printable oder Base64 Kodierung nachträglich in 7-bit umkodiert.

Eine OpenPGP PGP/MIME verschlüsselte Nachricht besteht aus einer speziellen Kopfzeile und zwei Nachrichtenkörperteilen:

In der Kopfzeile

Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
boundary="string"

wird der MIME Inhaltstyp nach RFC 1847 bestimmt und über den Protokoll Parameter der Subtyp, der auf den ersten Teil des Nachrichtenkörpers verweist. Die boundary Angabe verweist auf bzw. begrenzt mit einer beliebigen Zeichenkette den Bereich des E-Mail Nachrichtenkörpers, der den verschlüsselten Anteil enthält.

Der erste Narichtenkörperteil [application/pgp-encrypted] enthält die Kontrollinformationen, die eigentlich nur aus der „Version: 1“ Angabe bestehen, da alle weiteren Informationen in den Paketen der OpenPGP Verschlüsselung gespeichert sind.

Der zweite Nachrichtenkörperteil [application/octet-stream] enthält die eigentlichen Daten, die verschlüsselt wurden.

Da der zweite Nachrichtenkörperteil als Dateianhang dargestellt und als Datei abgespeichert werden kann und die gleiche Form aufweist wie die bekannten „PGP/INLINE“ Geheimtexte, können Personen, deren E-Mail Anwendung nicht PGP/MIME fähig ist, einfach die gespeicherte Dateidirekt mit GnuPG oder einem GnuPG GUI entschlüsseln.

Geheimtext-Beispiel
Content-Type: multipart/encrypted;
 protocol="application/pgp-encrypted";
 boundary="------------enigC86184E635FBAE679EE74B0A"
 
This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156)
--------------enigC86184E635FBAE679EE74B0A
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification
 
Version: 1
 
--------------enigC86184E635FBAE679EE74B0A
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"
 
-----BEGIN PGP MESSAGE-----
 
hQEOAzV64Drh036/EAP/VLQnmC0MthNo+b89M6uPseG0QqyGOIfqKWx0qDVqgPOF
XzdbWg2hBNMmD1DahKyQPmIEL22WcFNYxkMv7hnSBxHpechMvMvmzZrxzpi1ezzu
yp2p7Xi3s4kzDtB1wK8xnBshq20kSHNaKvxxyNKibrsgWao6BhhRKxJ1UvxIo74D
/2kOJL1os1JLpfVMCqvrTNn2/WWLU424f3NT36SCxJZ2nEfEdLSDtSIXrcgjuuCw
dW5EJ4U9jvzMW4Zaq3+Z2ulccWDRu/Jhb5CgOOUq1nacAj/e6/ZaA0fJQ/QuEMq6
WvaaNJkaumx3oI7hYOh0KTE0uRhRJwHrXpF0qUTgxHSr0sAZActIETs9J0t3NTub
n01BNY5UBnwxNNRxBvJjICyI9Sd2+8JhlhpfU4D4Bgtu/XuEnWSnCbExXKVRYGmW
0XjOtEz3FpiduKbR2B5sgX0TiO30rIDCLsP3MO/XyTI5h9znYiS8to/5uZh4Xmvg
z3vWUW1I2kVC70JBI22W0d+tb4HPIqIhv9wGXxLfFw+E33LQ/GJeMRwQjxhhveZM
NR/OIeIHwzq1c5e9Jp0o9TWVZR5edrPvtbKFUyMLr6qvuTlemKpDFXCo5FX1HxeS
5FTQKeOUYaiz16sb/w==
=I2VX
-----END PGP MESSAGE-----
 
--------------enigC86184E635FBAE679EE74B0A--

PGP/MIME signierte Nachricht

Eine OpenPGP PGP/MIME signierte Nachricht besteht aus einer speziellen Kopfzeile und zwei Nachrichtenkörperteilen:

In der Kopfzeile

Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg="pgp-sha256"; boundary="string"

wird der MIME Inhaltstyp nach RFC 1847 bestimmt, über den Protokoll Parameter der Subtyp, der auf den zweiten Teil des Nachrichtenkörpers verweist und der micalg (Message Integrity Check Algorithm) Parameter gibt den verwendeten Hashalgorithmus an. Die boundary Angabe verweist auf bzw. begrenzt mit einer beliebigen Zeichenkette den Bereich des E-Mail Nachrichtenkörpers, der die Signatur enthält.

Der erste Narichtenkörperteil besteht aus der Nachricht in Klarform, die signiert wurde.

Der zweite Narichtenkörperteil [application/pgp-signature] enthält die eigentliche Signatur.

Signatur-Beispiel
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------enigC2A6345E3008DD37D35A31E7"
 
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC2A6345E3008DD37D35A31E7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
 
Dieser Text wurde mit PGP/MIME signiert.
 
 
--------------enigC2A6345E3008DD37D35A31E7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
 
-----BEGIN PGP SIGNATURE-----
 
iIAEAREIACgFAk9iABQhGGhrcDovL2V1LnBvb2wuc2tzLWtleXNlcnZlcnMubmV0
AAoJEGLYuQlqnqZhkD0A/i4qij4MR/yJXtrbh8C2CeVkw9QQgdjT6FqEULgBScxY
AQCkAAPmGrob5nSmH0iVn2NLxRmXU3ASrWpqrKE1GwgDOA==
=MK+T
-----END PGP SIGNATURE-----
 
--------------enigC2A6345E3008DD37D35A31E7--
Probleme mit PGP/MIME Signaturen

Einige E-Mail Anwendungen setzen RFC 3156 nicht korrekt um, was die Behandlung von Leerraum an Zeilenenden betrifft. RFC 3156 schreibt vor, dass der Leerraum von Anwendungen bei der Signierung mit PGP/MIME erhalten bzw. geschützt werden muss. Die fehlerhaften E-Mail Anwendungen entfernen im Gegensatz dazu während der Signierung den Leerraum, was wiederum bei der Signaturprüfung auf der Gegenseite, die RFC 3156 korrekt umsetzt, die Angabe einer falschen, d. h. nicht als echt zu prüfenden Signatur erzeugt.

Um mit fehlerhaften E-Mail Anwendungen korrekt zu überprüfende Signaturen zu erzeugen, bis die Entwickler ihre E-Mail Anwendung gefixt haben, kann man in der gpg.conf die rfc2440-text Option setzen.

Um die eigene E-Mail Anwendung auf die korrekte Anwendung von RFC 3156 zu überprüfen, geht man wie folgt vor:

  1. Setzen der no-rfc2440-text Option in der gpg.conf
  2. An sich selbst adressierte E-Mail verfassen, die Zeilen mit Lehrräumen an Zeilenenden enthält
  3. Ersetzen der obigen Option durch rfc2440-text in der gpg.conf
  4. Verifizierung der Signatur

Wenn die Signatur bei der Prüfung als falsch deklariert wird, muss die E-Mail Anwendung gefixt und bis dahin die rfc2440-text Option in der gpg.conf verwendet werden.

PGP/MIME verschlüsselte und signierte Nachricht

Bei einer Kombination aus Verschlüsselung und Signierung wird die Nachricht entweder zuerst signiert und danach die Nachricht mit der Signatur in eine Verschlüsselung eingekapselt, so dass nach der Entschlüsselung eine nachträgliche Verifizierung vorgenommen wird oder Signierung und Verschlüsselung werden in einer Nachricht parallel durch- und zusammengeführt.

Beispiel: Enigmail

Wegen Thunderbird integriert Email-Verschlüsselung mit OpenPGP wird Thunderbird und Enigmail nicht mehr behandelt. Thunderbird ist für mich tot.

GnuPG E-Mail Relays

Der Vorteil des Einsatzes eines zentralen GnuPG E-Mail Relays oder „Proxy“ im Gegensatz zum dezentralen Einsatz auf vielen Rechnern ist die transparente Verwendung von GnuPG für die Anwender. Der Anwender versendet und empfängt wie gewohnt seine E-Mails, die GnuPG Funktionen (Ver- und Entschlüsseln, Signieren, Verifizieren) werden ohne Aktionen des Anwenders durch die E-Mail Relays ausgeführt. Deshalb sind E-Mail Relays für Firmen und Behörden interessant, die ihre E-Mail Kommunikation im LAN und aus dem LAN heraus mit GnuPG absichern wollen, aber den Installations-, Schulungs- und Supportaufwand scheuen, der bei der dezentralen Verwendung von GnuPG durch den einzelnen Anwender anfällt. Da die Relays unabhängig von eingesetzten E-Mail Anwendungen arbeiten, bieten sich PGP/MIME-fähige Relays auch an, wenn man PGP/MIME verwenden will, aber die E-Mail Anwendungen PGP/MIME nicht unterstützen.

Der Nachteil der Relays besteht darin, dass sie für die Entschlüsselung den Zugriff auf private Schlüssel und Passphrases (oder passphraselose Schlüssel) benötigen. Wäre ein illegaler Zugriff von außen auf die vorgehaltenen Schlüssel möglich, könnten nicht nur die privaten Schlüssel komprimitiert werden, sondern auch die gesamten Kommunikationsbeziehungen einer Firma oder Behörde in Erfahrung gebracht werden. Die Relays müssen also gut abgesichert sein. Für die Absicherung des Transports sollten Relays auch TLS unterstützen. Hinzu kommt, dass je nach Gestaltung einer unternehmens- oder behördenweiten Datenschutz-Policy die E-Mail Relays aufgrund ihrer Entschlüsselungsfuntionen oder zusätzlichen Drittschlüsselverschlüsselung auch zur Überwachung der verschlüsselten E-Mail Kommunikation der Angestellten verwendet werden kann.

Das Gleiche gilt für Internet-Diensteanbieter, die OpenPGP-Verschlüsselung über E-Mail Relays anbieten, wie es das Unternehmen Silent Circle bis August 2013 tat, die eventuell über eine abgesicherte Infrastruktur verfügen, aber aufgrund von Sicherheitsgesetzen zur Herausgabe der Schlüssel oder der entschlüsselten Kommunikationsdaten gezwungen werden können. Deshalb sollte man OpenPGP E-Mail Relay Dienstleistungen generell meiden.

Lösungen

OpenPGP für Mailinglisten

Die folgenden Anwendungen stellen Lösungen bereit, um einen Mailinglisten Server mit OpenPGP zu betreiben. Die Mailinglisten Server hosten interne Mailinglisten für geschlossene Benutzerkreise. Alle Nachrichten der Mitglieder werden dabei mit OpenPGP (GnuPG) verschlüsselt und/oder signiert. Zusätzlich können bzw. sollten einzelne Anwendungen Anonymisierungsfunktionen (z. B. Transport über Mixmaster, integrierte Pseudonymserver) enthalten.

Lösungen

Verweise auf aktuelle Seite