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

Installation

Um GnuPG mit der E-Mail Anwendung Thunderbird einzusetzen, muss nur die Thunderbird Erweiterung für Enigmail installiert und konfiguriert werden. Wer Thunderbird Beta-Versionen einsetzt, sollte stets die aktuellste Enigmail Nightly Version installieren. Im Enigmail Wiki findet sich die eigene Dokumentation zu Enigmail.

Wenn die Erweiterung zuerst als XPI-Datei heruntergeladen wurde, öffnet man in Thunderbird über ExtrasAdd-ons den Add-ons-Manager und wählt den Erweiterungen Reiter aus. Anschließend wird die Enigmail Datei über den Tools Button geöffnet und installiert.

Nach einem Thunderbird Neustart steht Enigmail zur Verfügung.

Konfiguration

Über EnigmailEinstellungen im Thunderbird Menü werden die OpenPGP-Einstellungen aufgerufen.

Zunächst sollte man den Experten-Optionen und Menüpunkte anzeigen Button aktivieren, um alle Einstellungen vornehmen und später alle möglichen Menüpunkte auswählen zu können.

Hier wird der Pfad zur GnuPG Programmdatei eingetragen, wenn GnuPG nicht automatisch gefunden wird. Verschlüsselt man Nachrichten oder prüft ihre Signaturen öfters in kurzen Zeitabständen, kann man die Passphrase für ein anzugebendes Intervall zwischenspeichern lassen, um die Passphrase nicht ständig angeben zu müssen. Wenn der GPG-Agent läuft, ist die GPG-Agent default-cache-ttl Option in der gpg-agent.conf für die Dauer der Zwischenspeicherung ausschlaggebend.

Wählt man die Bequemen Verschlüsselungs-Einstellungen werden automatisch alle Optionen der Manuellen Verschlüsselungs-Einstellungen ausgegraut. Das bedeutet vor allem, dass alle Empfängerschlüssel „automatisch“ als echt und vertrauenswürdig eingestuft, also immer für den Versand akzeptiert und verwendet werden, sofern sie nicht abgelaufen, zurückgezogen oder deaktiviert sind, was den Sinn von Schlüssel-Zertifikaten und des Web of Trust komplett untergräbt. Stattdessen kann und sollte man – falls nötig – die Temporär den Schlüsseln aller Empfänger vertrauen Option nutzen, die über das Enigmail Icon im E-Mail Editor von Thunderbird zugänglich ist.

Die Bequemen Verschlüsselungs-Einstellungen sind wohl nach dem Modell der Opportunistic Security für Anwender gedacht, die sich nicht näher mit Kryptografie, GnuPG, Enigmail und IT-Sicherheit auseinandersetzen, sondern „einfach“ verschlüsseln wollen.

Desweiteren gibt es keinerlei Bestätigungsdialoge vor dem Versand für die Fälle, die unter Senden bestätigen aufgeführt sind. Davon abgesehen werden wie bei den Manuellen Verschlüsselungs-Einstellungen E-Mails automatisch verschlüsselt, sobald Empfängerschlüssel vorhanden sind.

Mit den empfohlenen Einstellungen der Manuellen Verschlüsselungs-Einstellungen wie oben abgebildet, wird immer

  • auf verschlüsselte und/oder signierte E-Mails auch immer mit verschlüsselten und/oder signierten E-Mails geantwortet.
  • ein Empfängerschlüssel nur verwendet, wenn seine Echtheit/Gültigkeit mittels Schlüssel-Zertifikaten bzw. nach dem Web of Trust ausgewiesen wurde.
  • (ggf., sonst Nie) einen Bestätigungsdialog einblenden lassen, wenn E-Mails das System unverschlüsselt verlassen sollen, Anwender aber sichergehen wollen, dass E-Mails nicht versehentlich unverschlüsselt versendet werden.

Alle Nachrichten werden standardmäßig neben dem Schlüssel des Empfängers immer zusätzlich mit dem eigenen Schlüssel verschlüsselt, was die nachträgliche Entschlüsselung abgesendeter Nachrichten ermöglicht. Die Einstellung wird von Enigmail unabhängig davon angewendet, ob in der gpg.conf die encrypt-to Option gesetzt ist. Die standardmäßige Eigenverschlüsselung kann durch Ändern der extensions.enigmail.encryptToSelf Einstellung geändert werden.

Hier kann bestimmt werden, wie die Auswahl von Empfängerschlüsseln erfolgt. Mit den obigen Standardeinstellungen versucht Enigmail zuerst, automatisch eine Empfängerregel (sofern vorhanden) anzuwenden, die auf die E-Mail Adresse des Empfängers zutrifft, sucht andernfalls die E-Mail Adresse im öffentlichen Schlüsselring und zeigt die Schlüssel des öffentlichen Schlüsselrings zur Auswahl an, wenn kein Schlüssel auf die aktuelle E-Mail Adresse des Empfängers zutrifft oder aktuell kein gültiger Schlüssel für den Empfänger vorhanden ist, sodass ein fehlender Schlüssel über die Schlüsselverwaltung von einem Schlüsselserver nachgeladen werden kann.

Über den Empfängerregeln bearbeiten Button oder EnigmailEmpfängerregeln im Thunderbird Menü öffnet sich das Fenster mit der Übersicht der Empfängerregeln und den Buttons zu ihrer Bearbeitung.

Die „-- “ Zeile, mit der man gleichbleibende E-Mail Signaturen vom Nachrichtenkörper abtrennt, was von den meisten E-Mail Programmen bei der Darstellug einer Nachricht berücksichtigt wird, bleibt mit aktivierter Option in der Form erhalten. Die virte Option besagt, dass bei der Schlüsselbestimmung in der Benutzerkennung des Schlüssels der Teil innerhalb < > die E-Mail Adresse enthält und E-Mail Adressen von < > eingefasst werden.

Im ersten Feld wird mindestens die Adresse eines Schlüsselservers eingetragen, wenn man Enigmail für Aufgaben der Schlüsselverwaltung benutzen will, die Transfers mit Schlüsselservern betreffen. Enigmail verwendet für den Datenverkehr mit Schlüsselservern automatisch den HTTP-Proxy, der ggf. in den Thunderbird Einstellungen eingetragen wurde, aber nicht das HKPS-Protokoll für den verschlüsselten Transport des Datenverkehrs.

Wird im zweiten Feld ebenfalls eine Schlüsselserver Adresse eingetragen, sucht und lädt Enigmail beim Anklicken einer signierten Nachricht mit unbekanntem Schlüssel automatisch jedesmal den Schlüssel über den Schlüsselserver, der dann im öffentlichen Schlüsselring gespeichert wird.

Bei Problemen kann man im anzugebenden Verzeichnis Logdateien anlegen lassen, in der Enigmail alle Aktionen protokolliert und über Eingabe einer E-Mail Adresse, für die sich im öffentlichen GnuPG Schlüsselring ein Schlüssel befindet, eine einmalige Testnachricht erzeugen.

Manuelle Einstellungen

Neben der Konfiguration, die man grafisch vornehmen kann, lassen sich weitere Einstellungen manuell in der erweiterten Konfiguration von Thunderbird (über Einstellungen → Erweitert → Konfiguration bearbeiten) oder über das Editieren der prefs.js Datei im Thunderbird Profilverzeichnis vornehmen.

Einstellungsname Wert Erklärung
extensions.enigmail.alwaysTrustSend false Für die Schlüsselverwendung vor dem Nachrichtenversand wird nicht dem Web of Trust Schema gefolgt, nach dem automatisch alle Empfängerschlüssel immer als voll vertrauenswürdig eingestuft bzw. gültig eingestuft sind und deshalb ihre Gültigkeit nicht überprüft wird (trust-model always GnuPG Option).
extensions.enigmail.protectHeaders
extensions.enigmail.protectedSubjectText
true
Textstring
Ab Enigmail 1.9 wird gemäß des Cryptographic Protection of E-mail Headers Entwurfs mit true bei verschlüsselten E-Mails der reale Inhalt der Subject Kopfzeile Teil des verschlüsselten Nachrichtenkörpers und durch einen statischen Standard-Inhalt ersetzt, den man mit der zweiten Einstellung abändern kann. Wird er nicht geändert, wird z. B. für ein deutschsprachiges Betriebssystem „Verschlüsselte Nachricht“ als Subject übertragen. Nach der Entschlüsselung wird in Thunderbird der reale Inhalt der Subject Kopfzeile wiederhergestellt und angezeigt. Somit kann z. B. von Geheimdiensten das Subject nicht mehr als „Selector“ (z. B. GCHQ, NSA) oder „Telekommunikationsmerkmal“ (BND) herangezogen und inhaltlich ausgewertet werden.
extensions.enigmail.encryptToSelf true Mit dem Standardwert true werden E-Mails unabhängig von Einstellungen in der GnuPG Konfigurationsdatei immer zusätzlich zum Emfpfänger-Schlüssel mit dem eigenen Schlüssel verschlüsselt, was die nachträgliche Entschlüsselung gesendeter E-Mails ermöglicht. Mit dem Wert false werden E-Mails nur mit dem Empfänger-Schlüssel verschlüsselt oder ebenfalls zusätzlich mit dem eigenen Schlüssel, wenn die encrypt-to oder hidden-encrypto-to Option in der GnuPG Konfigurationsdatei gesetzt wurde.
extensions.enigmail.inlineAttachAsciiArmor true Bei der Verschlüsselung von Dateianhängen mit PGP/INLINE werden die Dateianhänge nicht binär, sondern per --armor GnuPG Option in ASCII kodiert
extensions.enigmail.saveEncrypted n Festlegung, wie Nachrichtenentwürfe mit aktivierter Verschlüsselungsoption gespeichert werden sollen. Bei der erstmaligen Anwendung erfolgt eine Abfrage, wie damit zu verfahren ist. Die Optionen können mit folgenden Werten nachträglich oder vorab geändert werden:
Für n =
0 - Enigmail fragt nach
1 - Entwürfe werden verschlüsselt im Entwürfe Odner gespeichert und müssen zur Neubearbeitung erst entschlüsselt werden
2 - Entwürfe werden unverschlüsselt im Entwürfe Ordner gespeichert

Konten-Einstellungen

Über Thunderbirds Konten-Einstellungen wird für die Haupt-Identität eines E-Mail Kontos unter OpenPGP-Sicherheit die Verwendung von Enigmail und GnuPG aktiviert. Sind mit einem Konto mehrere E-Mail Aliasadressen („Identitäten“) verknüpft, finden sich die gleichen Einstellungen für jeden Alias über den Weitere Identitäen Button nach Anklicken der Konten-Bezeichnung.

Über den Schlüssel auswählen Button sollte ein bestimmter Schlüssel zugeordnet werden. Darunter werden wie bei den Empfängerregeln die Einstellungen festgelegt, die bestimmen, wie GnuPG standardmäßig angewendet wird.

Wird unter Standard-Einstellungen die Option Nachrichten standardmäßig verschlüsseln aktiviert und es ist kein öffentlicher Schlüssel des Empfängers vorhanden, wird Enigmail immer das Schlüsselauswahl-Fenster anzeigen, über das man dann versucht, den fehlenden Schlüssel von einem Schlüsselserver zu laden. Ist kein Schlüssel auf dem Schlüsselserver vorhanden, muss man danach die Verschlüsselung manuell deaktivieren.

Da PGP/MIME zur Verschlüsselung und Signierung die sinnvollere Methode statt PGP/INLINE ist, sollte PGP/MIME standardmäßig verwenden aktiviert sein.

Im Zusammenspiel mit Empfängerregeln bietet es sich an, unter Nach Anwendung von Standards und Regeln die beiden Einstellungen stets zu aktivieren, denn verschlüsselte E-Mails sollten auch signiert werden und unverschlüsselte E-Mails kann man immer signieren. Bei der Anlage einer Empfängerregel reicht es dann, die standardmäßige Verschlüsselung zu aktivieren und ggf. PGP/INLINE auszuwählen.

Wer E-Mails im Entwurfsstadium, die im Entwürfe Ordner gespeichert werden, ebenfalls verschlüsselt ablegen will, aktiviert die Nachrichten-Entwürfe verschlüsselt speichern Option.

Über den Erweitert Button kann man den Versand einer zusätzlichen OpenPGP Kopfzeile veranlassen, die dem Empfänger die Schlüssel-ID übermittelt, die er verwenden kann, um den Schlüssel selbst zu suchen und herunterzuladen. Zusätzlich kann man dem Empfänger eine komplette URL senden, über die er den Schlüssel direkt von einem Schlüssel-, Web- oder FTP-Server laden kann. Ohne TLS-Verschlüsselung des Servers erfolgt der Download jedoch ungesichert.

Als URL kann man mit der eigenen Schlüssel-ID am Ende eintragen:

http://eu.pool.sks-keyservers.net:11371/pks/lookup?op=index&fingerprint=on&search=0xSchlüssel-ID; preference=signencrypt

Beim Empfänger erscheint dann die Kopfzeile:

OpenPGP: id=Schlüssel-ID; url=http://eu.pool.sks-keyservers.net:11371/pks/lookup?
op=index&fingerprint=on&search=0xSchlüssel-ID; preference=signencrypt

Im ersten Teil wird mit id= die OpenPGP Schlüssel-ID angegeben und danach die eingetragene URL, die der Empfänger nur in das Adresseingabefeld seines Webbrowsers eingeben muss. Am Ende gibt der Absender mit preference an, dass er gerne vom Absender signierte und mit seinem Schlüssel verschlüsselte E-Mails erhält.

Die Angabe der URL eines Schlüsselservers macht nur Sinn, wenn man den öffentlichen Schlüssel des eigenen Schlüsselpaars auch auf einen Schlüsselserver hochlädt. Die Aktivierung der letzten Option zum Anhängen des Schlüssels macht überhaupt keinen Sinn, weil dann mit jeder E-Mail permanent der Schlüssel versendet wird. Stattdessen exportiert man den öffentlichen Schlüssel in eine Datei und versendet die Datei fallweise als Anhang in einer (zumindest) signierten E-Mail.

Empfängerregeln

Im OpenPGP-Empfängerregeln Fenster erhält man eine Übersicht zu allen Benutzer-IDs bzw. E-Mail Adressen, für die eine Regel angelegt wurde, ob immer verschlüsselt, signiert und ob dabei PGP/MIME oder PGP/INLINE verwendet wird. Über den Bearbeiten Button wird der Editor zu einer bestehenden Regel und über den Hinzufügen Button der Editor für eine neue Regel geöffnet.

Die einfachste Form einer Regel besagt: Wenn die Empfängeradresse (der Inhalt der To: / An: Kopfzeile im Nachrichteneditor) der eingetragenen E-Mail Adresse entspricht, dann soll der passende Schlüssel mit der unter Aktion angezeigten Schlüssel-ID verwendet werden.

Statt einer vollständigen E-Mail Adresse können auch Teile von E-Mail Adressen (z. B. nur @ oder @domain.tld) eingetragen und mit einer Mustererkennung wie enthält oder endet mit statt exakt verknüpft werden, um allgemeine Regeln anzulegen. Zur Auswahl des passenden Schlüssels klickt man den Auswählen Button an und aktiviert im Auswahlfenster den entsprechenden Schlüssel. Nur ein Schlüssel, der zuvor gemäß der Web of Trust Prinzipien zertifiziert wurde, kann auch ausgwählt werden, außer man hat die Enigmail Option Schlüsseln immer vertrauen (s. o.) aktiviert.

Da in den Konten-Einstellungen bereits das standarmäßige Signieren und die Anwendung von PGP/MIME aktiviert wurde, braucht hier nur das Verschlüsseln mit Immer aktiviert zu werden. Wenn es sich um einen Empfänger handeln, von dem bekannt ist, das er eine E-Mail Anwendung verwendet, die PGP/MIME nicht unterstützt oder um die Adresse einer Mailingliste, die PGP/INLINE Signaturen bevorzugt, kann zusätzlich mit Nie für PGP/MIME auf PGP/INLINE umgeschaltet werden. Für Empfänger, die OpenPGP nicht anwenden oder verwenden wollen, bietet es sich u. U. an, das Unterschreiben mit Nie abzuschalten.

Bei überlegter Konten-Einstellung und umfassender Nutzung von Empfängerregeln braucht man sich keine Gedanken mehr zu machen, was für Aktionen über OpenPGP Menüs und Icons auszuwählen sind, sondern die E-Mail wird automatisch mit PGP/MIME oder PGP/INLINE verschlüsselt und signiert oder nicht.

Verschlüsseln und Signieren

Wenn Empfängerregeln oder die Standard-Einstellungen in der OpenPGP-Konfiguration zum Konto genutzt werden, genügt das Auslösen des Mail-Versands oder Speichern der E-Mail im Postausgang zum späteren Versand, um die E-Mail automatisch über Enigmail mit GnuPG zu verschlüsseln und zu signieren, weil die Regel-Logik der Empfängerregeln oder die Standard-Einstellungen des Kontos die Enigmail und GnuPG Aktionen auslösen.

Zur manuellen Verschlüsselung und Signierung oder um von Empfängerregeln abzuweichen, klickt man einfach das Enigmail Icon in der Toolbar des Nachrichten-Editors an und erhält dann ein Fenster, in dem man die entsprechenden Optionen aktiviert:

Dabei entspricht der jeweilige Statustext, wie z. B. „Nachricht wird verschlüsselt“, bereits vorliegenden Empfängerregeln, Standard-Einstellungen und dem Stadium der E-Mail. So steht z. B. der Status auf „Nachricht wird nicht verschlüsselt“, wenn der Editor geöffnet wird und bleibt auch dabei, verändert sich aber auf „Nachricht wird verschlüsselt“, wenn eine Empfängeradresse ausgewählt wird, für die eine Empfängerregel besagt, dass immer verschlüsselt wird.

Eine schnelle Übersicht zum Status mit Verzweigung zu den gleichen Optionen wie in der vorhergehenden Abbildung erhält man über das Ausklappen der Dropdown-Liste durch Anklicken des nach unten zeigenden Pfeils neben dem Enigmail Icon. Hier kann man auch die Temporär den Schlüsseln aller Empfänger vertrauen Option als Alternative zum permanenten "Vertrauen" in alle Empfängerschlüssel fallweise aktivieren.

Enigmail zeigt auch in der Statusleiste an, ob die E-Mail signiert und verschlüsselt wird. Gleichzeitig kann man über das Anklicken der Icons die Signierung und Verschlüsselung an- oder abschalten:

Noch einmal zur Erinnerung: Sofern die Schlüsseln immer vertrauen Enigmail Einstellung nicht genutzt wird, muss der Schlüssel des Empfängers zuvor zertifiziert worden sein, um von Enigmail akzeptiert oder zur Auswahl angeboten zu werden. Ist das nicht der Fall, ist der Schlüssel für Enigmail nicht existent, obwohl im Schlüsselring vorhanden und Enigmail zeigt das Fenster zur Schlüsselauswahl an, um einen anderen Schlüssel zu wählen:

Wird eine E-Mail nur signiert oder signiert und verschlüsselt, folgt für die Signatur die Eingabe der Passphrase, sofern der GPG-Agent oder Enigmail die Passphrase nicht mehr im Zwischenspeicher vorhält.

Will man dem Empfänger beim erstmaligen Kontakt den eigenen öffentlichen Schlüssel als Dateianhang mitsenden, aktiviert man den Meinen öffentlichen Schlüssel anhängen Eintrag im OpenPGP Menü. Enigmail fügt dann der E-Mail mit PGP/MIME die 0xSchlüssel-ID.asc Datei und mit PGP/INLINE die 0xSchlüssel-ID.asc.gpg Datei der E-Mail bei.

Entschlüsseln und Überprüfen

Entweder erhält man eine E-Mail, die PGP/MIME oder PGP/INLINE signiert und verschlüsselt wurde:

PGP/MIME E-Mail

Da bei PGP/MIME der verschlüsselte Nachrichteninhalt als encrypted.asc Dateianhang gesendet wird, könnte man die Datei auch speichern und dann mit gpg -o decrypted.txt --decrypt encrypted.asc in die decrypted.txt Datei mit dem Klartext entschlüsseln.

PGP/INLINE E-Mail

Sofern man die Automatisch entschlüsseln/überprüfen Option nicht im Thunderbird OpenPGP Menü aktiviert hat, wird eine E-Mail erst nach Anklicken des Nachrichten mit OpenPGP entschlüsseln/überprüfen Icons (i. d. Abb. mit Briefumschlag und Vorhängeschloß) entschlüsselt bzw. die Signatur überprüft.

Bei einer verschlüsselten E-Mail entschlüsselt Enigmail mit GnuPG und dem privaten Schlüssel nach Eingabe der Passphrase die E-Mail und zeigt sie im Klartext an. Bei nur signierten E-Mails wird die Signatur mit dem öffentlichen Schlüssel des Absenders überprüft und das Ergebnis angezeigt.

Entschlüsselte PGP/MIME E-Mail

An dem Schlüssel und Stift Icon in der Statusleiste kann man an der Gelbfärbung erkennen, dass die E-Mail und ihre Signatur korrekt entschlüsselt und überprüft wurde. Das bringen auch die grün gefärbte OpenPGP „Kopfleiste“, das Icon mit dem gesiegelten Briefumschlag und das Icon mit dem Schloß im Kopf zum Ausdruck. Klickt man eines der beiden Icons an, erhält man eine detailiertere Information:

Trifft Enigmail auf eine signierte E-Mail, für deren Signatur kein öffentlicher Schlüssel des Absenders im Schlüsselring vorhanden ist, erkennt man das an der gelbgefärbten OpenPGP „Kopfleiste“ und den enstprechenden Icons im Kopf der E-Mail und in der Statusleiste:

Signierte E-Mail mit fehlendem Schlüssel

Enigmail versucht nach Anklicken des OpenPGP Icons in der Thunderbird Toolleiste, den Schlüssel auf dem eingetragenen Schlüsselserver zu finden, zur Überprüfung der Signatur in den öffentlichen Schlüsselring zu importieren und wiederholt bei Erfolg den Überprüfungsvorgang. Man kann den Schlüssel auch manuell suchen lassen, indem über DetailsSchlüssel importieren ausgewählt wird.

Nach Anklicken des Importieren Button wird bei mehreren Schlüsselservern ein Schlüsselserver aus der Liste ausgewählt und mit dem OK Button der Such- und Importvorgang gestartet.

Ist kein Schlüssel auf dem Schlüsselserver zu finden, muss der Schlüssel vom Absender angefordert werden.

Dateianhänge

Verschlüsseln

Bei PGP/MIME und PGP/INLINE verschlüsselten E-Mails unterscheidet sich der Vorgang zum Anhängen und Versand von Dateianhängen nicht von unverschlüsselten E-Mails.

Bei PGP/MIME werden nach Anklicken des Versand Buttons alle Dateianhänge problemlos in den gesamten encrypted.asc Dateianhang mitverschlüsselt. Wird die E-Mail zusätzlich signiert, umfasst die Signatur (und ihre Überprüfung) damit auch die Dateianhänge.

Da bei PGP/INLINE der Nachrichteninhalt und die Dateianhänge gesondert behandelt werden, zeigt Enigmail einen Auswahldialog an, in dem für PGP/INLINE E-Mais nur die zweite Methode sinnvoll ist. Soll die zweite Methode immer für PGP/INLINE (aber nicht PGP/MIME) E-Mails mit Dateianhängen gelten, aktiviert man bei der erstmaligen Anzeige die letzte Checkbox.

Die PGP/INLINE E-Mail wird also aus dem verschlüsselten Nachrichtentext und zwei einzeln verschlüsselten Dateianhängen bestehen. Bei anderen E-Mail Anwendungen ohne ähnliche Funktionen muss dagegen jeder Dateianhang vorher mit GnuPG manuell verschlüsselt werden und wird dann im Nachrichteneditor angehängt, bevor die E-Mail verschlüsselt versendet wird. Wird die E-Mail zusätzlich signiert, umfasst die Signatur (und ihre Überprüfung) nur den Nachrichtentext und nicht die Dateianhänge.

Entschlüsseln und Öffnen
Anhänge im Klartext bei entschlüsselter PGP/MIME E-Mail

Bei PGP/MIME liegen nach dem Entschlüsseln der E-Mail sowohl die Nachricht, als auch die Dateianhänge sofort im entschlüsselten Klartext vor.

Zum Öffnen der Dateien mit der entsprechenden Anwendung lässt man sich die Anhänge unten anzeigen und klickt die Dateinamen doppelt an oder wählt Öffnen im Kontextmenü zum markierten Anhang. Über den Alle öffnen Button werden alle Dateien zugleich mit den Anwendungen geöffnet.

Zum Speichern der entschlüsselten Dateien wählt man Speichern im Kontextmenü zum markierten Anhang und wählt das Speicherverzeichnis aus. Über den Alle Speichern Button und Auswahl des Speicherverzeichnisses werden ale Dateien zugleich entschlüsselt gespeichert.

Verschlüsselte Anhänge bei entschlüsselter PGP/INLINE E-Mail

Bei PGP/INLINE liegt nach dem Entschlüsseln der E-Mail nur die Nachricht im Klartext vor.

Zum Öffnen der Dateien mit der entsprechenden Anwendung lässt man sich die Anhänge unten anzeigen und wählt Entschlüsseln und Öffnen im Kontextmenü zum markierten Anhang.

Zum Speichern der entschlüsselten Dateien wählt man Entschlüsseln und Speichern unter im Kontextmenü zum markierten Anhang und wählt das Speicherverzeichnis aus. Über den Alle Speichern Button und Auswahl des Speicherverzeichnisses werden ale Dateien zugleich im verschlüsselten Zustand gespeichert und müssen nachträglich mit GnuPG entschlüsselt werden.

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