OpenPGP: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(28 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''OpenPGP''' - [[Standard|standardisiertes]] Datenformat für verschlüsselte und digital signierte Daten
 
== Beschreibung ==
== Beschreibung ==
== Installation ==
Format von [[Digitales Zertifikat|Zertifikaten]] festlegen
== Syntax ==
* werden landläufig auch als „[[Schlüssel (Kryptologie)|Schlüssel]]“ bezeichnet
=== Optionen ===
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
== Anwendung ==
=== Fehlerbehebung ===
== Konfiguration ==
=== Dateien ===
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Sicherheit ====
==== Dokumentation ====
===== RFC =====
{| class="wikitable sortable options"
|-
! RFC !! Titel
|-
| [https://www.rfc-editor.org/rfc/0000 0000] ||
|}
 
===== Man-Pages =====
===== Info-Pages =====
==== Links ====
===== Projekt =====
===== Weblinks =====
 
= TMP =
'''OpenPGP''' ist ein [[Standard|standardisiertes]] Datenformat für verschlüsselte und digital signierte Daten. Auch wird das Format von [[Digitales Zertifikat|Zertifikaten]] festgelegt, die landläufig auch als „[[Schlüssel (Kryptologie)|Schlüssel]]“ bezeichnet werden.


Es basiert auf dem Format, das von [[Pretty Good Privacy|PGP]]&nbsp;5 eingeführt wurde, und ist im <nowiki>RFC&nbsp;4880</nowiki><ref name="RFC4880" /> standardisiert. Mit <nowiki>RFC&nbsp;5581</nowiki><ref name="RFC5581" /> wurde [[Camellia (Algorithmus)|Camellia]] (ein weiterer symmetrischer Chiffrieralgorithmus) hinzugefügt. <nowiki>RFC&nbsp;6637</nowiki><ref name="RFC6637" /> ergänzte OpenPGP um [[Elliptic Curve Cryptography]]. Diese Erweiterungen sind aber ausdrücklich als „optional“ spezifiziert. Eine OpenPGP-konforme Anwendung ist also nicht gezwungen, diese beiden Erweiterungen zu implementieren.
Es basiert auf dem Format, das von [[Pretty Good Privacy|PGP]]&nbsp;5 eingeführt wurde
, und ist im <nowiki>RFC&nbsp;4880</nowiki> standardisiert
* Mit RFC&nbsp;5581 wurde [[Camellia (Algorithmus)|Camellia]] (ein weiterer symmetrischer Chiffrieralgorithmus) hinzugefügt
* RFC&nbsp;6637 ergänzte OpenPGP um [[Elliptic Curve Cryptography]]
* Diese Erweiterungen ist optional


== Allgemeines ==
== Allgemeines ==
OpenPGP ist ein [[Binärformat]]
* Eine OpenPGP-Nachricht besteht aus einem oder mehreren Datensätzen ({{enS|records}}), die aber aus historischen Gründen in der Originaldokumentation als ''{{lang|en|packets}}'', zu deutsch „Pakete“ bezeichnet werden


OpenPGP ist ein [[Binärformat]]. Eine OpenPGP-Nachricht besteht aus einem oder mehreren Datensätzen ({{enS|records}}), die aber aus historischen Gründen in der Originaldokumentation als ''{{lang|en|packets}}'', zu deutsch „Pakete“ bezeichnet werden.
Das PGP-Datenformat ist im Laufe der Zeit beständig erweitert worden und existiert in verschiedenen abwärtskompatiblen Versionen
 
* Im Wesentlichen wird zwischen einem „alten“ Format (verwendet von PGP bis Version 2.6) und einem „neuen“ Format (ab PGP Version&nbsp;3) unterschieden
Das PGP-Datenformat ist im Laufe der Zeit beständig erweitert worden und existiert in verschiedenen abwärtskompatiblen Versionen. Im Wesentlichen wird zwischen einem „alten“ Format (verwendet von PGP bis Version 2.6) und einem „neuen“ Format (ab PGP Version&nbsp;3) unterschieden. Neuere PGP-Versionen können aber Nachrichten im alten Format lesen und –&nbsp;sofern der Inhalt auch im alten Format ausgedrückt werden kann&nbsp;– optional auch Nachrichten im alten Format erzeugen.
* Neuere PGP-Versionen können aber Nachrichten im alten Format lesen und –&nbsp;sofern der Inhalt auch im alten Format ausgedrückt werden kann&nbsp;– optional auch Nachrichten im alten Format erzeugen


Jedes Paket beginnt mit einem ''{{lang|en|packet tag}}'' genannten Byte, das den Typ und die Länge des nachfolgenden Pakets festlegt. Folgende Pakettypen sind bisher spezifiziert:
Jedes Paket beginnt mit einem ''{{lang|en|packet tag}}'' genannten Byte, das den Typ und die Länge des nachfolgenden Pakets festlegt
* Folgende Pakettypen sind bisher spezifiziert:


{| class="wikitable"
{| class="wikitable options col1center"
|+ OpenPGP-Pakettypen nach <nowiki>RFC&nbsp;4880</nowiki><ref name="RFC4880" />
|+ OpenPGP-Pakettypen nach <nowiki>RFC&nbsp;4880</nowiki>
|-
|-
! Nummer !! Typ !! Bemerkungen
! Nummer !! Typ !! Bemerkungen
|-
|-
| 0     || ''Reserviert'' || Ein Paket mit diesem Typ ist nicht erlaubt.
| 0 || ''Reserviert'' || Ein Paket mit diesem Typ ist nicht erlaubt
|-
|-
| 1     || Public-Key Encrypted Session Key Packet || Enthält den (mit dem Public Key des Empfängers verschlüsselten) {{lang|en|''Session Key''}} genannten Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden.
| 1 || Public-Key Encrypted Session Key Packet || Enthält den (mit dem Public Key des Empfängers verschlüsselten) {{lang|en|''Session Key''}} genannten Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden
|-
|-
| 2     || Signature Packet ||
| 2 || Signature Packet ||
|-
|-
| 3     || Symmetric-Key Encrypted Session Key Packet || Enthält den (mit einem symmetrischen Kryptoalgorithmus verschlüsselten) Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden.
| 3 || Symmetric-Key Encrypted Session Key Packet || Enthält den (mit einem symmetrischen Kryptoalgorithmus verschlüsselten) Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden
|-
|-
| 4     || One-Pass Signature Packet ||
| 4 || One-Pass Signature Packet ||
|-
|-
| 5     || Secret-Key Packet || Enthält einen privaten Schlüssel
| 5 || Secret-Key Packet || Enthält einen privaten Schlüssel
|-
|-
| 6     || Public-Key Packet || Enthält einen öffentlichen Schlüssel
| 6 || Public-Key Packet || Enthält einen öffentlichen Schlüssel
|-
|-
| 7     || Secret-Subkey Packet ||
| 7 || Secret-Subkey Packet ||
|-
|-
| 8     || Compressed Data Packet || Enthält Daten, die mit [[zlib]] (<nowiki>RFC&nbsp;1950</nowiki><ref>{{RFC-Internet |RFC=1950 |Titel=ZLIB Compressed Data Format Specification version 3.3 |Datum=1996-05}}</ref>), Deflate (<nowiki>RFC&nbsp;1951</nowiki><ref>{{RFC-Internet |RFC=1951 |Titel=DEFLATE Compressed Data Format Specification version 1.3 |Datum=1996-05}}</ref>) oder [[Bzip2]] komprimiert sind.
| 8 || Compressed Data Packet || Enthält Daten, die mit [[zlib]] (<nowiki>RFC&nbsp;1950</nowiki>) oder [[Bzip2]] komprimiert sind
|-
|-
| 9     || Symmetrically Encrypted Data Packet || [[Cipher Feedback Mode|CFB]]-verschlüsselte Daten
| 9 || Symmetrically Encrypted Data Packet || [[Cipher Feedback Mode|CFB]]-verschlüsselte Daten
|-
|-
| 10     || Marker Packet ||
| 10 || Marker Packet ||
|-
|-
| 11     || Literal Data Packet || Enthält unverschlüsselte Binär- oder Textdaten und einen Dateinamen, unter dem die Daten abgespeichert werden können.
| 11 || Literal Data Packet || Enthält unverschlüsselte Binär- oder Textdaten und einen Dateinamen, unter dem die Daten abgespeichert werden können
|-
|-
| 12     || Trust Packet ||
| 12 || Trust Packet ||
|-
|-
| 13     || User ID Packet || Enthält üblicherweise Namen und E-Mail-Adresse eines Schlüsselinhabers.
| 13 || User ID Packet || Enthält üblicherweise Namen und E-Mail-Adresse eines Schlüsselinhabers
|-
|-
| 14     || Public-Subkey Packet ||
| 14 || Public-Subkey Packet ||
|-
|-
| 17     || User Attribute Packet || Enthält weitere Metadaten zum Schlüsselinhaber, z.&nbsp;B. ein JPEG-Bild. Weitere Metadatentypen sind bisher nicht spezifiziert worden.
| 17 || User Attribute Packet || Enthält weitere Metadaten zum Schlüsselinhaber, z.&nbsp;B.&nbsp;ein JPEG-Bild
* Weitere Metadatentypen sind bisher nicht spezifiziert worden
|-
|-
| 18     || Sym. Encrypted and Integrity Protected Data Packet || Kann statt Pakettyp 9 verwendet werden, um verschlüsselte Daten mit einem Schutz vor versehentlicher oder absichtlicher Veränderung zu erzeugen. Dieser Schutz ({{lang|en|''modification detection code''}}, MDC genannt) ist kryptographisch schwächer als eine digitale Signatur oder ein [[Message Authentication Code|MAC]], aber einfacher zu erzeugen und besser als gar kein Schutz.
| 18 || Sym.&nbsp;Encrypted and Integrity Protected Data Packet || Kann statt Pakettyp 9 verwendet werden, um verschlüsselte Daten mit einem Schutz vor versehentlicher oder absichtlicher Veränderung zu erzeugen
* Dieser Schutz ({{lang|en|''modification detection code''}}, MDC genannt) ist kryptographisch schwächer als eine digitale Signatur oder ein [[Message Authentication Code|MAC]], aber einfacher zu erzeugen und besser als gar kein Schutz
|-
|-
| 19     || Modification Detection Code Packet || Enthält die SHA1-Prüfsumme des mit Pakettyp 18 verschlüsselten Datenstroms.
| 19 || Modification Detection Code Packet || Enthält die SHA1-Prüfsumme des mit Pakettyp 18 verschlüsselten Datenstroms
|-
|-
| 60 bis 63 || Private or Experimental Values ||
| 60 bis 63 || Private or Experimental Values ||
|}
|}


Da im „alten“ OpenPGP-Format nur 4 Bit zur Kodierung des Pakettyps zur Verfügung stehen, kann es nur die Pakettypen bis 15 beinhalten. Im „neuen“ Format stehen 6 Bit zur Kodierung des Pakettyps zur Verfügung, was zur Kodierung der möglichen Werte 0 bis 63 ausreicht.
Da im „alten“ OpenPGP-Format nur 4 Bit zur Kodierung des Pakettyps zur Verfügung stehen, kann es nur die Pakettypen bis 15 beinhalten
* Im „neuen“ Format stehen 6 Bit zur Kodierung des Pakettyps zur Verfügung, was zur Kodierung der möglichen Werte 0 bis 63 ausreicht


Einige Pakettypen enthalten ihrerseits wiederum eine Versionskennung, wobei die Art und Anzahl der Dateninhalte i.&nbsp;d.&nbsp;R. mit steigender Versionsnummer zunehmen.
Einige Pakettypen enthalten ihrerseits wiederum eine Versionskennung, wobei die Art und Anzahl der Dateninhalte i.&nbsp;d.&nbsp;R.&nbsp;mit steigender Versionsnummer zunehmen


=== Verschlüsselung ===
=== Verschlüsselung ===


Die Nutzdaten werden stets mit einem symmetrischen Verschlüsselungsalgorithmus und einem zufälligen „Session Key“ verschlüsselt und in einem Paket vom Typ 9 abgelegt. Dieser „Session Key“ wird nun wiederum asymmetrisch (Paket Typ 1) oder symmetrisch (Paket Typ 3) verschlüsselt und den verschlüsselten Nutzdaten vorangestellt. Damit zählt OpenPGP zu den [[Hybride Verschlüsselung|hybriden Verfahren]].
Die Nutzdaten werden stets mit einem symmetrischen Verschlüsselungsalgorithmus und einem zufälligen „Session Key“ verschlüsselt und in einem Paket vom Typ 9 abgelegt
* Dieser „Session Key“ wird nun wiederum asymmetrisch (Paket Typ 1) oder symmetrisch (Paket Typ 3) verschlüsselt und den verschlüsselten Nutzdaten vorangestellt
* Damit zählt OpenPGP zu den [[Hybride Verschlüsselung|hybriden Verfahren]]


==== Paket Typ 1: „Public-Key Encrypted Session Key“ ====
==== Paket Typ 1: „Public-Key Encrypted Session Key“ ====
 
Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom ''Typ 1'' enthalten. Üblicherweise wird für jeden Empfänger einer OpenPGP-Nachricht je ein Paket vom ''Typ 1'' erzeugt
Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom ''Typ 1'' enthalten. Üblicherweise wird für jeden Empfänger einer OpenPGP-Nachricht je ein Paket vom ''Typ 1'' erzeugt.


Ein Typ-1-Paket enthält folgende Daten:
Ein Typ-1-Paket enthält folgende Daten:


* Eine Versionskennung, derzeit ist nur Version 3 definiert
* Eine Versionskennung, derzeit ist nur Version 3 definiert
* Eine 8 Byte lange ''Key-ID'' des Schlüssels, so dass ein Empfänger einfacher das für ihn bestimmte Paket finden kann. Es ist aber auch möglich, eine ''Null-ID'' anzugeben, so dass der Empfänger alle verfügbaren privaten Schlüssel durchprobieren muss.
* Eine 8 Byte lange ''Key-ID'' des Schlüssels, so dass ein Empfänger einfacher das für ihn bestimmte Paket finden kann
* Es ist aber auch möglich, eine ''Null-ID'' anzugeben, so dass der Empfänger alle verfügbaren privaten Schlüssel durchprobieren muss
* 1 Byte, das den verwendeten Public-Key-Algorithmus codiert (siehe Tabelle)
* 1 Byte, das den verwendeten Public-Key-Algorithmus codiert (siehe Tabelle)
* Den verschlüsselten ''Session-Key''
* Den verschlüsselten ''Session-Key''
Zeile 114: Zeile 97:
! ID !! Algorithmus !! Bemerkungen
! ID !! Algorithmus !! Bemerkungen
|-
|-
| 1 || RSA || zum Verschlüsseln und Signieren
| 1 || RSA || zum Verschlüsseln und Signieren
|-
|-
| 2 || RSA || nur zum Verschlüsseln
| 2 || RSA || nur zum Verschlüsseln
|-
|-
| 3 || RSA || nur zum Signieren
| 3 || RSA || nur zum Signieren
|-
|-
| 16 || Elgamal || nur zum Verschlüsseln
| 16 || Elgamal || nur zum Verschlüsseln
Zeile 124: Zeile 107:
| 17 || DSA || nur zum Signieren
| 17 || DSA || nur zum Signieren
|-
|-
| 18 || ECDH || definiert in <nowiki>RFC&nbsp;6637</nowiki><ref name="RFC6637" />
| 18 || ECDH || definiert in <nowiki>RFC&nbsp;6637</nowiki>
|-
|-
| 19 || ECDSA || definiert in <nowiki>RFC&nbsp;6637</nowiki><ref name="RFC6637" />
| 19 || ECDSA || definiert in <nowiki>RFC&nbsp;6637</nowiki>
|-
|-
| 20 || ''reserviert''
| 20 || ''reserviert''
|-
|-
| 21 || ''reserviert für [[Diffie-Hellman-Schlüsselaustausch|Diffie-Hellman]]'' || nach ANSI X9.42, wie für IETF-[[S/MIME]] definiert
| 21 || ''reserviert für [[Diffie-Hellman|Diffie-Hellman]]'' || nach ANSI X9.42, wie für IETF-[[S/MIME]] definiert
|-
|-
| 100 … 110 ||colspan="2"| ''reserviert für private / experimentelle Algorithmen''
| 100 … 110 ||colspan="2"| ''reserviert für private / experimentelle Algorithmen''
|}
|}


Für ECC-Schlüssel existieren verschiedene elliptische Kurven. Diese werden anhand ihrer [[Object Identifier|OID]] identifiziert, so dass das Hinzufügen neuer Kurven keine Änderung am OpenPGP-Standard erfordert.
Für ECC-Schlüssel existieren verschiedene elliptische Kurven
* Diese werden anhand ihrer [[Object Identifier|OID]] identifiziert, so dass das Hinzufügen neuer Kurven keine Änderung am OpenPGP-Standard erfordert


{| class="wikitable"
{| class="wikitable"
Zeile 142: Zeile 126:
! Name !! Bitlänge || OID !! Bemerkungen
! Name !! Bitlänge || OID !! Bemerkungen
|-
|-
| NIST curve P-256 || 256 || 1.2.840.10045.3.1.7 ||rowspan="3"| definiert in <nowiki>RFC&nbsp;6637</nowiki><ref name="RFC6637" />
| NIST curve P-256 || 256 || 1.2.840.10045.3.1.7 ||rowspan="3"| definiert in <nowiki>RFC&nbsp;6637</nowiki>
|-
|-
| NIST curve P-384 || 384 || 1.3.132.0.34
| NIST curve P-384 || 384 || 1.3.132.0.34
Zeile 156: Zeile 140:
| Brainpool 512r1 || 512 || 1.3.36.3.3.2.8.1.1.13
| Brainpool 512r1 || 512 || 1.3.36.3.3.2.8.1.1.13
|-
|-
| secp256k1 || 256 || 1.3.132.0.10 || seit GnuPG 2.1.0<ref>[https://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028141.html lists.gnupg.org]</ref>
| secp256k1 || 256 || 1.3.132.0.10 || seit GnuPG 2.1.0
|}
|}


==== Paket Typ 3: „Symmetric-Key Encrypted Session Key“ ====
==== Paket Typ 3: „Symmetric-Key Encrypted Session Key“ ====
 
Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom Typ 3 enthalten
Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom Typ 3 enthalten. Diese werden genutzt, um den Session Key nicht mit dem Public Key des Empfängers zu verschlüsseln, sondern mit einem symmetrischen Key, der aus einer [[Passwort|Passphrase]] erzeugt wird. Pro Passphrase wird dabei je ein Paket vom Typ 3 erzeugt.
* Diese werden genutzt, um den Session Key nicht mit dem Public Key des Empfängers zu verschlüsseln, sondern mit einem symmetrischen Key, der aus einer [[Passwort|Passphrase]] erzeugt wird
* Pro Passphrase wird dabei je ein Paket vom Typ 3 erzeugt


Ein Typ-3-Paket enthält folgende Daten:
Ein Typ-3-Paket enthält folgende Daten:


* Eine Versionskennung. Derzeit ist nur Version 4 definiert.
* Eine Versionskennung
* Derzeit ist nur Version 4 definiert
* Ein Byte, das den symmetrischen Chiffrier-Algorithmus codiert
* Ein Byte, das den symmetrischen Chiffrier-Algorithmus codiert
* Eine Kennung variabler Länge, die angibt, wie der Schlüssel aus der Passphrase abgeleitet wird („string-to-key specifier“)
* Eine Kennung variabler Länge, die angibt, wie der Schlüssel aus der Passphrase abgeleitet wird („string-to-key specifier“)
* gegebenenfalls der mit dem o.&nbsp;g. Verfahren verschlüsselte Session-Key
* gegebenenfalls der mit dem o.&nbsp;g.&nbsp;Verfahren verschlüsselte Session-Key


{| class="wikitable"
{| class="wikitable"
Zeile 195: Zeile 181:
| 10 || [[Twofish]] || 256 Bit ||
| 10 || [[Twofish]] || 256 Bit ||
|-
|-
| 11 ||rowspan="3"| [[Camellia (Algorithmus)|Camellia]] || 128 Bit ||rowspan="3"| definiert seit <nowiki>RFC&nbsp;5581</nowiki><ref name="RFC5581" />
| 11 ||rowspan="3"| [[Camellia (Algorithmus)|Camellia]] || 128 Bit ||rowspan="3"| definiert seit <nowiki>RFC&nbsp;5581</nowiki>
|-
|-
| 12 || 192 Bit
| 12 || 192 Bit
Zeile 204: Zeile 190:
|}
|}


Alle Algorithmen außer TripleDES sind allerdings optional, eine standardkonforme Implementierung muss nur TripleDES beherrschen. <nowiki>RFC&nbsp;4880</nowiki><ref name="RFC4880" /> ''empfiehlt'', dass jede Implementierung CAST5 und AES-128 beherrscht.
Alle Algorithmen außer TripleDES sind allerdings optional, eine standardkonforme Implementierung muss nur TripleDES beherrschen. <nowiki>RFC&nbsp;4880</nowiki> ''empfiehlt'', dass jede Implementierung CAST5 und AES-128 beherrscht


== Anwendungen ==
== Anwendungen ==
 
Zwei der Hauptanwendungen sind die Signierung und die Verschlüsselung von [[E-Mail]]s
Zwei der Hauptanwendungen sind die Signierung und die Verschlüsselung von [[E-Mail]]s. Dafür müssen OpenPGP-Nachrichten geeignet kodiert werden, da eine E-Mail nach <nowiki>RFC&nbsp;5322</nowiki><ref>{{RFC-Internet |RFC=5322 |Titel=Internet Message Format |Datum=2008-10}}</ref> nur aus druckbaren Zeichen aus dem [[American Standard Code for Information Interchange|ASCII]]-Zeichensatz und einigen wenigen Steuerzeichen bestehen darf.
* Dafür müssen OpenPGP-Nachrichten geeignet kodiert werden, da eine E-Mail nach <nowiki>RFC&nbsp;5322</nowiki> nur aus druckbaren Zeichen aus dem [[American Standard Code for Information Interchange|ASCII]]-Zeichensatz und einigen wenigen Steuerzeichen bestehen darf


Hierfür gibt es im Wesentlichen zwei Formate:
Hierfür gibt es im Wesentlichen zwei Formate:


* das ältere [[PGP/INLINE]] als Kompatibilitätsformat
* das ältere [[PGP/INLINE]] als Kompatibilitätsformat
** [[Datei:Pro.svg|15px]] Auch nutzbar (wenn auch nicht unproblematisch) mit Mailprogrammen, die OpenPGP nicht kennen (auch [[Webmail]]). Die E-Mail wird dabei von ihrer Struktur her als gewöhnliche Textmail erzeugt (<code>Content-Type: text/plain</code>), die verschlüsselten Text als [[Base64|Radix-64]]-kodierten Text enthält ([[Base64]] plus Prüfsumme; ursprüngliches Textformat von PGP); signierter Text wird als Klartextsignatur eingefügt (Einleitungszeile, normaler Text, Signaturdaten als Radix-64). Dies ermöglicht nur das Signieren und Verschlüsseln einfachen Mailtextes (Mailbody).
** [[Datei:Pro.svg|15px]] Auch nutzbar (wenn auch nicht unproblematisch) mit Mailprogrammen, die OpenPGP nicht kennen (auch [[Webmail]])
** [[Datei:Contra.png|15px]] Für HTML-Mails gibt es keine entsprechende Möglichkeit.
* Die E-Mail wird dabei von ihrer Struktur her als gewöhnliche Textmail erzeugt (<code>Content-Type: text/plain</code>), die verschlüsselten Text als [[Base64|Radix-64]]-kodierten Text enthält ([[Base64]] plus Prüfsumme; ursprüngliches Textformat von PGP); signierter Text wird als Klartextsignatur eingefügt (Einleitungszeile, normaler Text, Signaturdaten als Radix-64)
** [[Datei:Contra.png|15px]] Dateianhänge können aber vorab verschlüsselt und/oder signiert werden (das übernehmen die Mailprogramme; im Fall von Webmail muss man das ohne entsprechendes Browser-Addon selber machen). Allerdings garantieren die Signaturen dann nicht die Integrität der Mail insgesamt. Signierte Teile können unbemerkt entfernt werden, in anderem Zusammenhang signierte Daten können hinzugefügt werden (was nur auffiele, wenn man sich die Mühe machte, die Zeitstempel der einzelnen Signaturen zu vergleichen).
* Dies ermöglicht nur das Signieren und Verschlüsseln einfachen Mailtextes (Mailbody)
** [[Datei:Contra.png|15px]] Einer der Nachteile von PGP/Inline ist, dass Mailprogramme, die OpenPGP nicht verstehen, die Signatur im Text anzeigen, was viele Empfänger verwirrt.
** [[Datei:Contra.png|15px]] Für HTML-Mails gibt es keine entsprechende Möglichkeit
* [[PGP/MIME]] als saubere technische Lösung ([[Multipurpose Internet Mail Extensions|MIME]]-Erweiterung nach <code>RFC&nbsp;3156</code><ref>{{RFC-Internet |RFC=3156 |Titel=MIME Security with OpenPGP |Datum=2001}}</ref>)
** [[Datei:Contra.png|15px]] Dateianhänge können aber vorab verschlüsselt und/oder signiert werden (das übernehmen die Mailprogramme; im Fall von Webmail muss man das ohne entsprechendes Browser-Addon selber machen)
** [[Datei:Pro.svg|15px]] Dieses Verfahren deckt auch Dateianhänge und HTML-Mails ab. Für den Mailbody und alle Anhänge kann jeweils einzeln festgelegt werden, ob sie verschlüsselt und/oder signiert werden sollen; es wird technisch nur eine Signierung und/oder Verschlüsselung vorgenommen (bei PGP/Inline für den Textteil und jeden Dateianhang gesondert).
* Allerdings garantieren die Signaturen dann nicht die Integrität der Mail insgesamt
** [[Datei:Neutral.svg|15px]] Auch dieses Verfahren schützt aber nur den Inhalt der Mail, nicht ihre Kopfdaten (vor allem Absender, Empfänger, Betreff, Datum).
* Signierte Teile können unbemerkt entfernt werden, in anderem Zusammenhang signierte Daten können hinzugefügt werden (was nur auffiele, wenn man sich die Mühe machte, die Zeitstempel der einzelnen Signaturen zu vergleichen)
** [[Datei:Contra.png|15px]] Der Nachteil von PGP/MIME ist, dass Mailprogramme (oder Webmail-Implementierungen), die nicht einmal den grundlegenden Standard von 1995 (<nowiki>RFC&nbsp;1847</nowiki><ref>{{RFC-Internet |RFC=1847 |Titel=Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted |Datum=1995-10}}</ref>) unterstützen, der das grundsätzliche E-Mail-Format für verschlüsselte oder signierte Inhalte festlegt, im Zweifelsfall eine leere Mail mit Dateianhängen anzeigen, was noch irritierender und noch weniger benutzerfreundlich ist als eine Radix-64-Signatur im Text.
** [[Datei:Contra.png|15px]] Einer der Nachteile von PGP/Inline ist, dass Mailprogramme, die OpenPGP nicht verstehen, die Signatur im Text anzeigen, was viele Empfänger verwirrt
* [[PGP/MIME]] als saubere technische Lösung ([[Multipurpose Internet Mail Extensions|MIME]]-Erweiterung nach <code>RFC&nbsp;3156</code>)
** [[Datei:Pro.svg|15px]] Dieses Verfahren deckt auch Dateianhänge und HTML-Mails ab
* Für den Mailbody und alle Anhänge kann jeweils einzeln festgelegt werden, ob sie verschlüsselt und/oder signiert werden sollen; es wird technisch nur eine Signierung und/oder Verschlüsselung vorgenommen (bei PGP/Inline für den Textteil und jeden Dateianhang gesondert)
** [[Datei:Neutral.svg|15px]] Auch dieses Verfahren schützt aber nur den Inhalt der Mail, nicht ihre Kopfdaten (vor allem Absender, Empfänger, Betreff, Datum)
** [[Datei:Contra.png|15px]] Der Nachteil von PGP/MIME ist, dass Mailprogramme (oder Webmail-Implementierungen), die nicht einmal den grundlegenden Standard von 1995 (<nowiki>RFC&nbsp;1847</nowiki>) unterstützen, der das grundsätzliche E-Mail-Format für verschlüsselte oder signierte Inhalte festlegt, im Zweifelsfall eine leere Mail mit Dateianhängen anzeigen, was noch irritierender und noch weniger benutzerfreundlich ist als eine Radix-64-Signatur im Text


Manche Mailprogramme bieten die Möglichkeit, für die Adressbucheinträge festzulegen, in welchem Format OpenPGP-Nachrichten an die jeweilige Adresse geschickt werden sollen. Auf diese Weise kann man die Nachteile beider Verfahren minimieren.
Manche Mailprogramme bieten die Möglichkeit, für die Adressbucheinträge festzulegen, in welchem Format OpenPGP-Nachrichten an die jeweilige Adresse geschickt werden sollen
* Auf diese Weise kann man die Nachteile beider Verfahren minimieren


OpenPGP und [[S/MIME]] (welches [[X.509]]-Zertifikate verwendet) sind die beiden wichtigsten Standards für E-Mail-Verschlüsselung. Eine weitere Hauptverwendung von OpenPGP ist die Absicherung der Softwareverteilung (Paketverwaltung) von z.&nbsp;B. [[Linux]] durch digitale Signaturen.
OpenPGP und [[S/MIME]] (welches [[X.509]]-Zertifikate verwendet) sind die beiden wichtigsten Standards für E-Mail-Verschlüsselung
* Eine weitere Hauptverwendung von OpenPGP ist die Absicherung der Softwareverteilung (Paketverwaltung) von z.&nbsp;B. [[Linux]] durch digitale Signaturen


== Geschichte ==
== Geschichte ==
Entstanden ist OpenPGP im Jahr 1998 als Reaktion auf diverse Entwicklungen:
Entstanden ist OpenPGP im Jahr 1998 als Reaktion auf diverse Entwicklungen:


* Die in PGP verwendeten Algorithmen ([[International Data Encryption Algorithm|IDEA]] und [[RSA-Kryptosystem|RSA]]) waren patentiert und konnten nicht beliebig verwendet werden. Insbesondere gab es in den USA Gesetze, die den Export von starker Verschlüsselung (ab 40&nbsp;Bit) verboten.
* Die in PGP verwendeten Algorithmen ([[International Data Encryption Algorithm|IDEA]] und [[RSA-Kryptosystem|RSA]]) waren patentiert und konnten nicht beliebig verwendet werden
* Das Programm [[Pretty Good Privacy|PGP]] wurde kommerziell durch die Firma PGP Inc. vertrieben, und es gab unbelegte Gerüchte, dass eine Hintertür in das Programm eingebaut sei, da es über eine sogenannte ADK-Funktion (Additional Decryption Key) verfügte.
* Insbesondere gab es in den USA Gesetze, die den Export von starker Verschlüsselung (ab 40&nbsp;Bit) verboten
* Ende 1997 wurde PGP Inc. von Network Associates Inc. (NAI) bzw. [[McAfee#Problematik|McAfee]] übernommen, die zeitweilig den PGP-Quelltext verschlossen hielten, ADK-Funktionen einbauten und Mitglied der ''Key Recovery Alliance'' waren.
* Das Programm [[Pretty Good Privacy|PGP]] wurde kommerziell durch die Firma PGP Inc
* vertrieben, und es gab unbelegte Gerüchte, dass eine Hintertür in das Programm eingebaut sei, da es über eine sogenannte ADK-Funktion (Additional Decryption Key) verfügte
* Ende 1997 wurde PGP Inc
* von Network Associates Inc. (NAI) bzw. [[McAfee#Problematik|McAfee]] übernommen, die zeitweilig den PGP-Quelltext verschlossen hielten, ADK-Funktionen einbauten und Mitglied der ''Key Recovery Alliance'' waren


Das OpenPGP-Format wird mittlerweile von vielen Produkten implementiert. Prominente Vertreter sind das kommerzielle [[Pretty Good Privacy|PGP]] und das freie Open-Source-Programm [[GNU Privacy Guard|GnuPG]] (unter der [[GNU General Public License|GNU-GPL]] stehend).
Das OpenPGP-Format wird mittlerweile von vielen Produkten implementiert
* Prominente Vertreter sind das kommerzielle [[Pretty Good Privacy|PGP]] und das freie Open-Source-Programm [[GNU Privacy Guard|GnuPG]] (unter der [[GNU General Public License|GNU-GPL]] stehend)


Das ebenfalls weit verbreitete [[S/MIME]]-Format verwendet dagegen [[X.509]]-Zertifikate und ist deshalb grundsätzlich nicht kompatibel zu OpenPGP, auch wenn es auf unterster Ebene dieselben kryptografischen Verfahren verwendet. Es existieren Programme, welche OpenPGP-Schlüssel im RSA-Format in X.509-Schlüssel umwandeln können (und umgekehrt: pem2openpgp aus dem [[monkeysphere]]-Paket); diese Konvertierung betrifft aber nur das rohe Schlüsselmaterial, die Zertifizierungen durch Dritte gehen verloren. Auch eine Verwendung derselben Schlüssel für [[Secure Shell|SSH]] ist (etwa mittels GnuPG) möglich.
Das ebenfalls weit verbreitete [[S/MIME]]-Format verwendet dagegen [[X.509]]-Zertifikate und ist deshalb grundsätzlich nicht kompatibel zu OpenPGP, auch wenn es auf unterster Ebene dieselben kryptografischen Verfahren verwendet
* Es existieren Programme, welche OpenPGP-Schlüssel im RSA-Format in X.509-Schlüssel umwandeln können (und umgekehrt: pem2openpgp aus dem [[monkeysphere]]-Paket); diese Konvertierung betrifft aber nur das rohe Schlüsselmaterial, die Zertifizierungen durch Dritte gehen verloren
* Auch eine Verwendung derselben Schlüssel für [[Secure Shell|SSH]] ist (etwa mittels GnuPG) möglich


{{Überarbeiten|[[Diskussion:OpenPGP#OpenPGP Alliance = Seite?|Diskussionsseite]]|2=Der folgende Absatz}}
{{Überarbeiten|[[Diskussion:OpenPGP#OpenPGP Alliance = Seite?|Diskussionsseite]]|2=Der folgende Absatz}}
Es gibt ferner die ''OpenPGP Alliance'' als Zusammenschluss mehrerer Hersteller, die sich dem OpenPGP-Format verpflichtet fühlen. Seit August 2016 wird diese Seite von Dominik Schürmann betreut.
Es gibt ferner die ''OpenPGP Alliance'' als Zusammenschluss mehrerer Hersteller, die sich dem OpenPGP-Format verpflichtet fühlen
* Seit August 2016 wird diese Seite von Dominik Schürmann betreut


== Kryptographische Verfahren ==
== Kryptographische Verfahren ==


=== Verschlüsselung ===
=== Verschlüsselung ===
OpenPGP benutzt eine [[hybride Verschlüsselung]], die die Vorteile [[Asymmetrisches Kryptosystem|asymmetrischer Kryptosysteme]] (sichere Schlüsselübertragung) mit denen [[Symmetrisches Kryptosystem|symmetrischer Kryptosysteme]] (hohe Geschwindigkeit) kombiniert.
OpenPGP benutzt eine [[hybride Verschlüsselung]], die die Vorteile [[Asymmetrisches Kryptosystem|asymmetrischer Kryptosysteme]] (sichere Schlüsselübertragung) mit denen [[Symmetrisches Kryptosystem|symmetrischer Kryptosysteme]] (hohe Geschwindigkeit) kombiniert


Statt wie bei einem symmetrischen System nur einen Schlüssel sowohl für Ver- als auch Entschlüsselung zu verwenden, besteht bei einem asymmetrischen System ein Schlüsselpaar aus zwei zusammengehörigen Schlüsseln, einem öffentlichen und einem geheimen. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem geheimen Schlüssel wieder entschlüsselt werden; es ist nicht möglich, die Verschlüsselung mit dem öffentlichen Schlüssel aufzuheben. Mit dem asymmetrischen Verfahren wird ein symmetrischer Sitzungsschlüssel verschlüsselt, mit dem wiederum die eigentlichen Daten verschlüsselt werden.
Statt wie bei einem symmetrischen System nur einen Schlüssel sowohl für Ver- als auch Entschlüsselung zu verwenden, besteht bei einem asymmetrischen System ein Schlüsselpaar aus zwei zusammengehörigen Schlüsseln, einem öffentlichen und einem geheimen
* Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem geheimen Schlüssel wieder entschlüsselt werden; es ist nicht möglich, die Verschlüsselung mit dem öffentlichen Schlüssel aufzuheben
* Mit dem asymmetrischen Verfahren wird ein symmetrischer Sitzungsschlüssel verschlüsselt, mit dem wiederum die eigentlichen Daten verschlüsselt werden


Die symmetrische Verschlüsselung erfolgt stets mit einem modifizierten [[Cipher Feedback Mode|CFB-Modus]]. Dabei besteht der eigentliche Initialisierungsvektor nur aus Nullbytes, dafür werden dem Klartext 10 (bei Blockchiffren mit 64&nbsp;Bit Blockgröße) bzw. 18 (bei 128&nbsp;Bit Blockgröße) Bytes vorangestellt. Diese bestehen aus einem Block Zufallsdaten und der Wiederholung der ersten beiden Zufallsbytes. Durch diese Redundanz kann beim Entschlüsseln (mit einer Fehlerwahrscheinlichkeit von 1:65536 = 0,0015 %) erkannt werden, ob mit dem richtigen Schlüssel entschlüsselt wurde.
Die symmetrische Verschlüsselung erfolgt stets mit einem modifizierten [[Cipher Feedback Mode|CFB-Modus]]
* Dabei besteht der eigentliche Initialisierungsvektor nur aus Nullbytes, dafür werden dem Klartext 10 (bei Blockchiffren mit 64&nbsp;Bit Blockgröße) bzw. 18 (bei 128&nbsp;Bit Blockgröße) Bytes vorangestellt
* Diese bestehen aus einem Block Zufallsdaten und der Wiederholung der ersten beiden Zufallsbytes
* Durch diese Redundanz kann beim Entschlüsseln (mit einer Fehlerwahrscheinlichkeit von 1:65536 = 0,0015 %) erkannt werden, ob mit dem richtigen Schlüssel entschlüsselt wurde


=== Signatur ===
=== Signatur ===
Neben der Verschlüsselung unterstützt OpenPGP auch [[digitale Signatur]]en, mit denen Empfänger die [[Integrität (Informationssicherheit)|Integrität]] von Nachrichten feststellen können. Dazu wird vom Absender eine [[Prüfsumme]] (auch [[Hashfunktion|Hash-Wert]] genannt) der Daten gebildet, aus der dann mit dem privaten Schlüssel die Signatur gebildet wird (die signierten Daten bleiben unangetastet). Der Empfänger kann die Signatur mit dem öffentlichen Schlüssel des Absenders prüfen.
Neben der Verschlüsselung unterstützt OpenPGP auch [[digitale Signatur]]en, mit denen Empfänger die [[Integrität (Informationssicherheit)|Integrität]] von Nachrichten feststellen können
* Dazu wird vom Absender eine [[Prüfsumme]] (auch [[Hashfunktion|Hash-Wert]] genannt) der Daten gebildet, aus der dann mit dem privaten Schlüssel die Signatur gebildet wird (die signierten Daten bleiben unangetastet)
* Der Empfänger kann die Signatur mit dem öffentlichen Schlüssel des Absenders prüfen


=== Algorithmen ===
=== Algorithmen ===
OpenPGP ist gegenwärtig in <nowiki>RFC&nbsp;4880</nowiki><ref name="RFC4880" /> standardisiert, dem Nachfolger von <nowiki>RFC&nbsp;2440</nowiki>.<ref>{{RFC-Internet |RFC=2440 |Titel=OpenPGP Message Format |Datum=1998-11}}</ref> <nowiki>RFC&nbsp;4880</nowiki> legt fest, dass eine Implementierung das [[Elgamal-Verschlüsselungsverfahren]], [[Digital Signature Algorithm|DSA]], [[Triple DES]] und [[SHA-1]] unterstützen muss. Weiterhin wird dort empfohlen, dass Implementierungen die in [[Public-Key Cryptography Standards|PKCS #1]] v1.5 beschriebenen, auf dem [[RSA-Kryptosystem]] basierenden, Verschlüsselungs- und Signaturverfahren, sowie [[Advanced Encryption Standard|AES-128]], [[CAST-128]] und [[International Data Encryption Algorithm|IDEA]] unterstützen. Darüber hinaus gibt es eine Vielzahl weiterer Verfahren, die mit OpenPGP verwendet werden dürfen. Der Standard wurde 2009 durch <nowiki>RFC&nbsp;5581</nowiki><ref name="RFC5581" /> um [[Camellia (Algorithmus)|Camellia]] erweitert. 2012 fügte <nowiki>RFC&nbsp;6637</nowiki><ref name="RFC6637" /> Unterstützung von [[Elliptic Curve Cryptography]] ([[Elliptic Curve DSA|ECDSA]], [[Elliptic Curve Diffie-Hellman|ECDH]]) hinzu.
OpenPGP ist gegenwärtig in <nowiki>RFC&nbsp;4880</nowiki> standardisiert, dem Nachfolger von <nowiki>RFC&nbsp;2440</nowiki>. <nowiki>RFC&nbsp;4880</nowiki> legt fest, dass eine Implementierung das [[Elgamal-Verschlüsselungsverfahren]], [[Digital Signature Algorithm|DSA]], [[Triple DES]] und [[SHA-1]] unterstützen muss
* Weiterhin wird dort empfohlen, dass Implementierungen die in [[Public-Key Cryptography Standards|PKCS #1]] v1.5 beschriebenen, auf dem [[RSA-Kryptosystem]] basierenden, Verschlüsselungs- und Signaturverfahren, sowie [[Advanced Encryption Standard|AES-128]], [[CAST-128]] und [[International Data Encryption Algorithm|IDEA]] unterstützen
* Darüber hinaus gibt es eine Vielzahl weiterer Verfahren, die mit OpenPGP verwendet werden dürfen
* Der Standard wurde 2009 durch <nowiki>RFC&nbsp;5581</nowiki> um [[Camellia (Algorithmus)|Camellia]] erweitert. 2012 fügte <nowiki>RFC&nbsp;6637</nowiki> Unterstützung von [[Elliptic Curve Cryptography]] ([[Elliptic Curve DSA|ECDSA]], [[Elliptic Curve Diffie-Hellman|ECDH]]) hinzu


== Schlüsselbeglaubigung ==
=== Schlüsselbeglaubigung ===
Öffentliche Schlüssel können von anderen Schlüsselinhabern signiert („zertifiziert“) werden
* Der Signierende/Zertifizierer belegt damit, dass er sowohl den Schlüssel (also den Fingerprint) als auch die im Schlüssel enthaltene User-ID überprüft hat (wofür es jedoch keine festen Regeln gibt)
* Hat ein öffentlicher Schlüssel mehrere User-IDs, dann müssen diese einzeln zertifiziert werden
* Im Gegensatz zu S/MIME basiert diese Signierung jedoch nicht auf einem hierarchischen System, bei der nur eine übergeordnete Stelle Schlüssel untergeordneter Stellen signieren darf, sondern aus einem ''Netz des Vertrauens'' ([[Web of Trust]]), in dem jeder Teilnehmer die Schlüssel anderer signieren kann
* Die mit der Signatur (implizit) gemachte Aussage über die Echtheit des Schlüssels und der jeweiligen Identität (Name, E-Mail, Kommentar) ermöglicht es Dritten, die Authentizität des Zertifikats einzuschätzen
* Vertraut zum Beispiel B den Zertifizierungen von A (entweder vollständig oder teilweise), könnte B auch dem öffentlichen Schlüssel des ihm unbekannten Teilnehmers C vertrauen, wenn dieser Schlüssel durch A zertifiziert wurde
* Die Zertifizierung bezieht sich nur auf die Echtheit des Schlüssels; ob A auch den Zertifizierungen von C vertraut, ist aus der Signatur von A nicht ersichtlich und für die Zertifizierung von C durch A unerheblich
* Die Gültigkeit von Zertifikaten ist eine öffentliche Information, das Vertrauen der Nutzer in andere ist eine private Information
* Leider werden sehr oft Schlüsselgültigkeit und Zertifizierungsvertrauen miteinander verwechselt


Öffentliche Schlüssel können von anderen Schlüsselinhabern signiert („zertifiziert“) werden. Der Signierende/Zertifizierer belegt damit, dass er sowohl den Schlüssel (also den Fingerprint) als auch die im Schlüssel enthaltene User-ID überprüft hat (wofür es jedoch keine festen Regeln gibt). Hat ein öffentlicher Schlüssel mehrere User-IDs, dann müssen diese einzeln zertifiziert werden. Im Gegensatz zu S/MIME basiert diese Signierung jedoch nicht auf einem hierarchischen System, bei der nur eine übergeordnete Stelle Schlüssel untergeordneter Stellen signieren darf, sondern aus einem ''Netz des Vertrauens'' ([[Web of Trust]]), in dem jeder Teilnehmer die Schlüssel anderer signieren kann. Die mit der Signatur (implizit) gemachte Aussage über die Echtheit des Schlüssels und der jeweiligen Identität (Name, E-Mail, Kommentar) ermöglicht es Dritten, die Authentizität des Zertifikats einzuschätzen. Vertraut zum Beispiel B den Zertifizierungen von A (entweder vollständig oder teilweise), könnte B auch dem öffentlichen Schlüssel des ihm unbekannten Teilnehmers C vertrauen, wenn dieser Schlüssel durch A zertifiziert wurde. Die Zertifizierung bezieht sich nur auf die Echtheit des Schlüssels; ob A auch den Zertifizierungen von C vertraut, ist aus der Signatur von A nicht ersichtlich und für die Zertifizierung von C durch A unerheblich. Die Gültigkeit von Zertifikaten ist eine öffentliche Information, das Vertrauen der Nutzer in andere ist eine private Information. Leider werden sehr oft Schlüsselgültigkeit und Zertifizierungsvertrauen miteinander verwechselt.<ref>[http://www.openpgp-schulungen.de/kurzinfo/irrtuemer/#validity-vs-trust Gültigkeit vs. Vertrauen.] openpgp-schulungen.de</ref>
Eine weitere, einfachere Methode, die Echtheit eines Schlüssels zu prüfen, ist der Vergleich des ''Fingerabdrucks''
* Dabei handelt es sich um eine [[Prüfsumme]] der Schlüsseldaten (öffentlicher Hauptschlüssel plus dessen Generierungs-Zeitstempel) in hexadezimaler Form (zum Beispiel „72F0 5CA5 0D2B BA4D 8F86 E14C 38AA E0EB“), die sich leicht im direkten Gespräch, per Telefon oder per Brief vergleichen lässt


Eine weitere, einfachere Methode, die Echtheit eines Schlüssels zu prüfen, ist der Vergleich des ''Fingerabdrucks''. Dabei handelt es sich um eine [[Prüfsumme]] der Schlüsseldaten (öffentlicher Hauptschlüssel plus dessen Generierungs-Zeitstempel) in hexadezimaler Form (zum Beispiel „72F0 5CA5 0D2B BA4D 8F86 E14C 38AA E0EB“), die sich leicht im direkten Gespräch, per Telefon oder per Brief vergleichen lässt.
Der öffentliche Schlüssel kann auch mit Hilfe der [[Personalausweis_(Deutschland)#eID-Funktion|eID-Funktion]] des [[Personalausweis (Deutschland)|Personalausweises]] von der Firma [[Governikus]] im Auftrag des [[Bundesamt für Sicherheit in der Informationstechnik|Bundesamtes für Sicherheit in der Informationstechnik (BSI)]] beglaubigt werden


Der öffentliche Schlüssel kann auch mit Hilfe der [[Personalausweis_(Deutschland)#eID-Funktion|eID-Funktion]] des [[Personalausweis (Deutschland)|Personalausweises]] von der Firma [[Governikus]] im Auftrag des [[Bundesamt für Sicherheit in der Informationstechnik|Bundesamtes für Sicherheit in der Informationstechnik (BSI)]] beglaubigt werden.<ref>[https://pgp.governikus.de OpenPGP-Schlüssel beglaubigen.] pgp.governikus.de</ref>
Wird der öffentliche OpenPGP-Schlüssel auf einen [[Schlüsselserver]] wie <nowiki>keys.openpgp.org</nowiki> oder <nowiki>keys.mailvelope.com</nowiki> hochgeladen, wird die mit dem Schlüssel verbundene E-Mail-Adresse per Bestätigungslink verifiziert


Wird der öffentliche OpenPGP-Schlüssel auf einen [[Schlüsselserver]] wie <nowiki>keys.openpgp.org</nowiki> oder <nowiki>keys.mailvelope.com</nowiki> hochgeladen, wird die mit dem Schlüssel verbundene E-Mail-Adresse per Bestätigungslink verifiziert.<ref>[https://keys.openpgp.org/about Funktionsweise.] keys.openpgp.org</ref><ref>[https://keys.mailvelope.com/manage.html OpenPGP key upload.] keys.mailvelope.com</ref>
== Aufbau der Zertifikate ==


== Aufbau der Zertifikate ==
OpenPGP-Zertifikate (der aktuellen Version 4) bestehen aus einer Reihe von Komponenten
* Ihre Daten werden nicht in ihrer Gesamtheit zertifiziert, sondern in einzelnen Komponenten, teils vom Schlüsselbesitzer und von Dritten, teils nur vom Schlüsselbesitzer
* Damit geht einher, dass sich ein Zertifikat im Lauf der Zeit ändern kann
* Komponenten können hinzugefügt, geändert und gelöscht werden


OpenPGP-Zertifikate (der aktuellen Version 4) bestehen aus einer Reihe von Komponenten. Ihre Daten werden nicht in ihrer Gesamtheit zertifiziert, sondern in einzelnen Komponenten, teils vom Schlüsselbesitzer und von Dritten, teils nur vom Schlüsselbesitzer. Damit geht einher, dass sich ein Zertifikat im Lauf der Zeit ändern kann. Komponenten können hinzugefügt, geändert und gelöscht werden. Die wichtigsten Komponenten eines OpenPGP-Zertifikats sind:
Die wichtigsten Komponenten eines OpenPGP-Zertifikats sind:
# genau ein öffentlicher Hauptschlüssel (auf den sich der [[Hashfunktion|Fingerabdruck]] bezieht, der den Schlüssel insgesamt identifiziert), mit Erzeugungs- und ggf. auch Ablaufdatum
# genau ein öffentlicher Hauptschlüssel (auf den sich der [[Hashfunktion|Fingerabdruck]] bezieht, der den Schlüssel insgesamt identifiziert), mit Erzeugungs- und ggf
# eine oder mehrere User-IDs (Text zur Beschreibung des Benutzers, typischerweise im Format '''Vorname Nachname (Kommentar) <E-Mail-Adresse>''', ggf. mit Ablaufdatum)
* auch Ablaufdatum
# eventuell vorhandene Unterschlüssel (ggf. mit Ablaufdatum)
# eine oder mehrere User-IDs (Text zur Beschreibung des Benutzers, typischerweise im Format '''Vorname Nachname (Kommentar) <E-Mail-Adresse>''', ggf
* mit Ablaufdatum)
# eventuell vorhandene Unterschlüssel (ggf
* mit Ablaufdatum)
# eventuell Zusatzinformationen zur Verwendung des Schlüssels (Präferenz von Hash- und Verschlüsselungsalgorithmen, bevorzugter Keyserver, URL einer Schlüsselrichtlinie)
# eventuell Zusatzinformationen zur Verwendung des Schlüssels (Präferenz von Hash- und Verschlüsselungsalgorithmen, bevorzugter Keyserver, URL einer Schlüsselrichtlinie)
# Signaturen des Schlüsselbesitzers oder von Dritten, die die Echtheit der genannten Komponenten bestätigen oder ihre Gültigkeit widerrufen; Signaturen haben ein Erzeugungs- und eventuell ein Ablaufdatum
# Signaturen des Schlüsselbesitzers oder von Dritten, die die Echtheit der genannten Komponenten bestätigen oder ihre Gültigkeit widerrufen; Signaturen haben ein Erzeugungs- und eventuell ein Ablaufdatum
Dritte signieren nur die Kombination aus Hauptschlüssel und einer User-ID; es muss daher jede User-ID einzeln signiert werden. Ob er alle User-IDs signiert, steht einem Dritten frei. Der Schlüsselbesitzer signiert alles. Unsignierte Komponenten sind wertlos und werden ignoriert. Dadurch kann der Besitzer eigenmächtig seine Präferenzen, Zusatzinformationen und Gültigkeitsdauern ändern. Er kann Unterschlüssel und User-IDs hinzufügen und widerrufen. Unterschlüssel werden von OpenPGP-Software automatisch akzeptiert (wenn sie eine Eigenzertifizierung haben), User-IDs dagegen nicht. Wenn man seinen Schlüssel von Dritten zertifizieren lässt und anschließend eine E-Mail-Adresse hinzufügt (die nicht von Dritten zertifiziert wird), dann erhalten die Verwender des Zertifikats eine Warnung, wenn sie für die hinzugefügte E-Mail-Adresse verschlüsseln wollen. Die Anzeige der wichtigsten Elemente in GnuPG (--list-sigs):
Dritte signieren nur die Kombination aus Hauptschlüssel und einer User-ID; es muss daher jede User-ID einzeln signiert werden
* Ob er alle User-IDs signiert, steht einem Dritten frei
* Der Schlüsselbesitzer signiert alles
* Unsignierte Komponenten sind wertlos und werden ignoriert
* Dadurch kann der Besitzer eigenmächtig seine Präferenzen, Zusatzinformationen und Gültigkeitsdauern ändern
* Er kann Unterschlüssel und User-IDs hinzufügen und widerrufen
* Unterschlüssel werden von OpenPGP-Software automatisch akzeptiert (wenn sie eine Eigenzertifizierung haben), User-IDs dagegen nicht
* Wenn man seinen Schlüssel von Dritten zertifizieren lässt und anschließend eine E-Mail-Adresse hinzufügt (die nicht von Dritten zertifiziert wird), dann erhalten die Verwender des Zertifikats eine Warnung, wenn sie für die hinzugefügte E-Mail-Adresse verschlüsseln wollen
* Die Anzeige der wichtigsten Elemente in GnuPG (--list-sigs):


<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
pub   1024D/0x12345678 2005-09-05
pub 1024D/0x12345678 2005-09-05
      D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 1234 5678
D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 1234 5678


uid   Vorname Nachname <vorname.nachname@example.org>
uid Vorname Nachname <vorname.nachname@example.org>
sig   0x12345678     Vorname Nachname <vorname.nachname@example.org>
sig 0x12345678 Vorname Nachname <vorname.nachname@example.org>
sig   0x87654321     Zertifizierer <zertifizierer@example.org>
sig 0x87654321 Zertifizierer <zertifizierer@example.org>


uid   Vorname Nachname (Geschäftsführer der Beispiel GmbH) <vorname.nachname@example.net>
uid Vorname Nachname (Geschäftsführer der Beispiel GmbH) <vorname.nachname@example.net>
sig   0x12345678     Vorname Nachname <vorname.nachname@example.org>
sig 0x12345678 Vorname Nachname <vorname.nachname@example.org>
sig   0x87654321     Zertifizierer <zertifizierer@example.org>
sig 0x87654321 Zertifizierer <zertifizierer@example.org>


sub   2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
sub 2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
sig   0x12345678     Vorname Nachname <vorname.nachname@example.org>
sig 0x12345678 Vorname Nachname <vorname.nachname@example.org>
</syntaxhighlight>
</syntaxhighlight>


Zu sehen ist, dass nur ein Hauptschlüssel ('''pub''') vorhanden ist, dass es sich dabei um einen 1024&nbsp;Bit langen DSA-Schlüssel handelt und wann dieser Hauptschlüssel erzeugt wurde. Darunter steht sein Fingerabdruck. Die ID, mit der Schlüssel zumeist bezeichnet werden, ist der letzte Teil des Fingerabdrucks. Dann sind zwei User-IDs ('''uid''') zu sehen, die beide einen Namen und eine E-Mail-Adresse beinhalten und beide sowohl von dem zugehörigen Schlüssel selber als auch von einem anderen Schlüssel signiert wurden. Nur eine der User-IDs enthält einen Kommentar, in diesem Fall eine berufliche Position. Auf diese Weise kann ein organisatorisch entsprechend qualifizierter Schlüssel eines Unternehmens (etwa der des Geschäftsführers) die Position von Mitarbeitern des Unternehmens gegenüber Dritten, die dem ersten Schlüssel vertrauen, beglaubigen. Außerdem ist zu sehen, dass Unterschlüssel ('''sub''') nur von ihrem Hauptschlüssel signiert werden, nicht aber von Dritten.
Zu sehen ist, dass nur ein Hauptschlüssel ('''pub''') vorhanden ist, dass es sich dabei um einen 1024&nbsp;Bit langen DSA-Schlüssel handelt und wann dieser Hauptschlüssel erzeugt wurde
* Darunter steht sein Fingerabdruck
* Die ID, mit der Schlüssel zumeist bezeichnet werden, ist der letzte Teil des Fingerabdrucks
* Dann sind zwei User-IDs ('''uid''') zu sehen, die beide einen Namen und eine E-Mail-Adresse beinhalten und beide sowohl von dem zugehörigen Schlüssel selber als auch von einem anderen Schlüssel signiert wurden
* Nur eine der User-IDs enthält einen Kommentar, in diesem Fall eine berufliche Position
* Auf diese Weise kann ein organisatorisch entsprechend qualifizierter Schlüssel eines Unternehmens (etwa der des Geschäftsführers) die Position von Mitarbeitern des Unternehmens gegenüber Dritten, die dem ersten Schlüssel vertrauen, beglaubigen
* Außerdem ist zu sehen, dass Unterschlüssel ('''sub''') nur von ihrem Hauptschlüssel signiert werden, nicht aber von Dritten


Die einzelnen Komponenten des Zertifikats werden anders als bei X.509 ohne Kryptografie zusammengefügt. Die kryptografische Sicherung befindet sich nur jeweils innerhalb der Komponente. Man kann deshalb unbemerkt Teile eines Zertifikats löschen. Das heißt, dass der Nutzer im Allgemeinen nicht sicher sein kann, dass ein Zertifikat, das er sich (wie üblich) aus einer unsicheren Quelle beschafft hat, vollständig ist. Um diese Sicherheit zu bieten, kann man ein Zertifikat in eine Datei exportieren und diese dann signieren.
Die einzelnen Komponenten des Zertifikats werden anders als bei X.509 ohne Kryptografie zusammengefügt
* Die kryptografische Sicherung befindet sich nur jeweils innerhalb der Komponente
* Man kann deshalb unbemerkt Teile eines Zertifikats löschen
* Das heißt, dass der Nutzer im Allgemeinen nicht sicher sein kann, dass ein Zertifikat, das er sich (wie üblich) aus einer unsicheren Quelle beschafft hat, vollständig ist
* Um diese Sicherheit zu bieten, kann man ein Zertifikat in eine Datei exportieren und diese dann signieren


== Qualifizierte Signaturen nach dem Signaturgesetz ==
== Qualifizierte Signaturen nach dem Signaturgesetz ==


Das deutsche [[Signaturgesetz (Deutschland)|Signaturgesetz]] (SigG) unterscheidet '''elektronische Signaturen''', '''fortgeschrittene elektronische Signaturen''' und '''qualifizierte elektronische Signaturen'''. Letztere sind der eigentliche Inhalt des Gesetzes, die ersten beiden Gruppen dienen nur der Abgrenzung. Das SigG stellt sowohl technische als auch organisatorische Anforderungen an die Anerkennung qualifizierter Signaturen. Derzeit (2012) bieten die Zertifizierungsdiensteanbieter keine qualifizierten Zertifikate auf Basis von OpenPGP an, es ist also nicht möglich, mit OpenPGP qualifizierte Signaturen zu erzeugen. Das hat auch technische Gründe. Zum derzeitigen Konzept von OpenPGP gehört,
Das deutsche [[Signaturgesetz (Deutschland)|Signaturgesetz]] (SigG) unterscheidet '''elektronische Signaturen''', '''fortgeschrittene elektronische Signaturen''' und '''qualifizierte elektronische Signaturen'''
* Letztere sind der eigentliche Inhalt des Gesetzes, die ersten beiden Gruppen dienen nur der Abgrenzung
* Das SigG stellt sowohl technische als auch organisatorische Anforderungen an die Anerkennung qualifizierter Signaturen
* Derzeit (2012) bieten die Zertifizierungsdiensteanbieter keine qualifizierten Zertifikate auf Basis von OpenPGP an, es ist also nicht möglich, mit OpenPGP qualifizierte Signaturen zu erzeugen
* Das hat auch technische Gründe
* Zum derzeitigen Konzept von OpenPGP gehört,
# dass nur der Hauptschlüssel (zusammen mit einer User-ID) zertifiziert wird, nicht aber die Unterschlüssel
# dass nur der Hauptschlüssel (zusammen mit einer User-ID) zertifiziert wird, nicht aber die Unterschlüssel
# dass man mit einem Hauptschlüssel neue Unterschlüssel erzeugen kann.
# dass man mit einem Hauptschlüssel neue Unterschlüssel erzeugen kann
Das Signaturgesetz verlangt, dass die privaten Schlüssel qualifizierter Zertifikate in Hardware gespeichert werden, aus der sie nicht ausgelesen werden können. Das sind typischerweise [[Chipkarte|Smartcards]]. Da die aktuelle Version von OpenPGP die Signaturen von Unterschlüsseln genauso behandelt wie die von Hauptschlüsseln, eignen sich normale OpenPGP-Schlüssel prinzipiell nicht für qualifizierte Signaturen. Aber selbst wenn man einen atypischen, dieser Forderung entsprechenden OpenPGP-Schlüssel erzeugte, müsste die für seine Erzeugung und Speicherung verwendete Hard- und Software durch eine vom [[Bundesamt für Sicherheit in der Informationstechnik|BSI]] anerkannte Stelle daraufhin überprüft werden, ob sie den Sicherheitsanforderungen des Gesetzes genügt. Die Kosten einer solchen Prüfung sind ein weiterer Hinderungsgrund für die Verfügbarkeit von OpenPGP für qualifizierte Signaturen.
Das Signaturgesetz verlangt, dass die privaten Schlüssel qualifizierter Zertifikate in Hardware gespeichert werden, aus der sie nicht ausgelesen werden können
* Das sind typischerweise [[Chipkarte|Smartcards]]
* Da die aktuelle Version von OpenPGP die Signaturen von Unterschlüsseln genauso behandelt wie die von Hauptschlüsseln, eignen sich normale OpenPGP-Schlüssel prinzipiell nicht für qualifizierte Signaturen
* Aber selbst wenn man einen atypischen, dieser Forderung entsprechenden OpenPGP-Schlüssel erzeugte, müsste die für seine Erzeugung und Speicherung verwendete Hard- und Software durch eine vom [[Bundesamt für Sicherheit in der Informationstechnik|BSI]] anerkannte Stelle daraufhin überprüft werden, ob sie den Sicherheitsanforderungen des Gesetzes genügt
* Die Kosten einer solchen Prüfung sind ein weiterer Hinderungsgrund für die Verfügbarkeit von OpenPGP für qualifizierte Signaturen


Das deutsche Signaturgesetz wurde am 29. Juli 2017 vom [[Vertrauensdienstegesetz]] abgelöst.
Das deutsche Signaturgesetz wurde am 29
* Juli 2017 vom [[Vertrauensdienstegesetz]] abgelöst


== Normen und Standards ==
== Anwendung ==
OpenPGP ist als [[Request for Comments]] (RFC) standardisiert und wird fortwährend weiterentwickelt. Seit dem 31. August 2020 liegt ein finaler Entwurf im weltweiten Review, der <nowiki>RFC&nbsp;4880</nowiki>,<ref name="RFC4880" /> 5581<ref name="RFC5581" /> und 6637<nowiki>RFC&nbsp;6637</nowiki><ref name="RFC6637" /> ersetzen soll.<ref>[https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10 tools.ietf.org]</ref>
=== Problembehebung ===
== Konfiguration ==
=== Dateien ===
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Sicherheit ====
==== Dokumentation ====
; Normen und Standards
OpenPGP ist als [[Request for Comments]] (RFC) standardisiert und wird fortwährend weiterentwickelt
* Seit dem 31.&nbsp;August 2020 liegt ein finaler Entwurf im weltweiten Review, der <nowiki>RFC&nbsp;4880</nowiki>, ersetzen soll


* {{RFC-Internet |RFC=1991 |Titel=PGP Message Exchange Formats |Datum=1996 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=1991 |Titel=PGP Message Exchange Formats |Datum=1996 |Kommentar=veraltet}}
Zeile 316: Zeile 381:
* {{RFC-Internet |RFC=3156 |Titel=MIME Security with OpenPGP |Datum=2001}}
* {{RFC-Internet |RFC=3156 |Titel=MIME Security with OpenPGP |Datum=2001}}


== Weblinks ==
===== RFC =====
* [https://datatracker.ietf.org/wg/openpgp/charter/ IETF-OpenPGP-Arbeitsgruppe.]
{| class="wikitable sortable big options"
* [https://www.gnupg.org/ GnuPG] – GNU Privacy Guard, ein Programm entsprechend dem OpenPGP-Standard (multilingual).
|-
* [http://www.openpgp-schulungen.de/info/verify-mime/ PGP/MIME-Signaturen manuell verifizieren.] openpgp-schulungen.de
! RFC !! Titel
* [https://www.symantec.com/de/de/products-solutions/families/?fid=encryption Symantec PGP Produktfamilie] – ehemalige PGP Corporation (Hersteller des ursprünglichen PGP-Systems).
|-
* [https://www.openpgp.org/ OpenPGP Alliance] (englisch).
| [https://www.rfc-editor.org/rfc/0000 0000] ||
* [http://www.pgpi.org/ The International PGP Home Page] (veraltet, englisch).
|}
 
===== Man-Page =====
===== Info-Pages =====
 
==== Links ====
===== Projekt =====
===== Weblinks =====
# https://de.wikipedia.org/wiki/OpenPGP


[[Kategorie:Kryptologischer Standard]]
[[Kategorie:Kryptografie/Standard]]
[[Kategorie:GnuPG]]
</noinclude>
</noinclude>

Aktuelle Version vom 6. November 2024, 12:46 Uhr

OpenPGP - standardisiertes Datenformat für verschlüsselte und digital signierte Daten

Beschreibung

Format von Zertifikaten festlegen

  • werden landläufig auch als „Schlüssel“ bezeichnet

Es basiert auf dem Format, das von PGP 5 eingeführt wurde , und ist im RFC 4880 standardisiert

  • Mit RFC 5581 wurde Camellia (ein weiterer symmetrischer Chiffrieralgorithmus) hinzugefügt
  • RFC 6637 ergänzte OpenPGP um Elliptic Curve Cryptography
  • Diese Erweiterungen ist optional

Allgemeines

OpenPGP ist ein Binärformat

  • Eine OpenPGP-Nachricht besteht aus einem oder mehreren Datensätzen (), die aber aus historischen Gründen in der Originaldokumentation als Vorlage:Lang, zu deutsch „Pakete“ bezeichnet werden

Das PGP-Datenformat ist im Laufe der Zeit beständig erweitert worden und existiert in verschiedenen abwärtskompatiblen Versionen

  • Im Wesentlichen wird zwischen einem „alten“ Format (verwendet von PGP bis Version 2.6) und einem „neuen“ Format (ab PGP Version 3) unterschieden
  • Neuere PGP-Versionen können aber Nachrichten im alten Format lesen und – sofern der Inhalt auch im alten Format ausgedrückt werden kann – optional auch Nachrichten im alten Format erzeugen

Jedes Paket beginnt mit einem Vorlage:Lang genannten Byte, das den Typ und die Länge des nachfolgenden Pakets festlegt

  • Folgende Pakettypen sind bisher spezifiziert:
OpenPGP-Pakettypen nach RFC 4880
Nummer Typ Bemerkungen
0 Reserviert Ein Paket mit diesem Typ ist nicht erlaubt
1 Public-Key Encrypted Session Key Packet Enthält den (mit dem Public Key des Empfängers verschlüsselten) Vorlage:Lang genannten Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden
2 Signature Packet
3 Symmetric-Key Encrypted Session Key Packet Enthält den (mit einem symmetrischen Kryptoalgorithmus verschlüsselten) Schlüssel, mit dem die eigentlichen Nutzdaten (in Paket-Typ 9) verschlüsselt werden
4 One-Pass Signature Packet
5 Secret-Key Packet Enthält einen privaten Schlüssel
6 Public-Key Packet Enthält einen öffentlichen Schlüssel
7 Secret-Subkey Packet
8 Compressed Data Packet Enthält Daten, die mit zlib (RFC 1950) oder Bzip2 komprimiert sind
9 Symmetrically Encrypted Data Packet CFB-verschlüsselte Daten
10 Marker Packet
11 Literal Data Packet Enthält unverschlüsselte Binär- oder Textdaten und einen Dateinamen, unter dem die Daten abgespeichert werden können
12 Trust Packet
13 User ID Packet Enthält üblicherweise Namen und E-Mail-Adresse eines Schlüsselinhabers
14 Public-Subkey Packet
17 User Attribute Packet Enthält weitere Metadaten zum Schlüsselinhaber, z. B. ein JPEG-Bild
  • Weitere Metadatentypen sind bisher nicht spezifiziert worden
18 Sym. Encrypted and Integrity Protected Data Packet Kann statt Pakettyp 9 verwendet werden, um verschlüsselte Daten mit einem Schutz vor versehentlicher oder absichtlicher Veränderung zu erzeugen
  • Dieser Schutz (Vorlage:Lang, MDC genannt) ist kryptographisch schwächer als eine digitale Signatur oder ein MAC, aber einfacher zu erzeugen und besser als gar kein Schutz
19 Modification Detection Code Packet Enthält die SHA1-Prüfsumme des mit Pakettyp 18 verschlüsselten Datenstroms
60 bis 63 Private or Experimental Values

Da im „alten“ OpenPGP-Format nur 4 Bit zur Kodierung des Pakettyps zur Verfügung stehen, kann es nur die Pakettypen bis 15 beinhalten

  • Im „neuen“ Format stehen 6 Bit zur Kodierung des Pakettyps zur Verfügung, was zur Kodierung der möglichen Werte 0 bis 63 ausreicht

Einige Pakettypen enthalten ihrerseits wiederum eine Versionskennung, wobei die Art und Anzahl der Dateninhalte i. d. R. mit steigender Versionsnummer zunehmen

Verschlüsselung

Die Nutzdaten werden stets mit einem symmetrischen Verschlüsselungsalgorithmus und einem zufälligen „Session Key“ verschlüsselt und in einem Paket vom Typ 9 abgelegt

  • Dieser „Session Key“ wird nun wiederum asymmetrisch (Paket Typ 1) oder symmetrisch (Paket Typ 3) verschlüsselt und den verschlüsselten Nutzdaten vorangestellt
  • Damit zählt OpenPGP zu den hybriden Verfahren

Paket Typ 1: „Public-Key Encrypted Session Key“

Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom Typ 1 enthalten. Üblicherweise wird für jeden Empfänger einer OpenPGP-Nachricht je ein Paket vom Typ 1 erzeugt

Ein Typ-1-Paket enthält folgende Daten:

  • Eine Versionskennung, derzeit ist nur Version 3 definiert
  • Eine 8 Byte lange Key-ID des Schlüssels, so dass ein Empfänger einfacher das für ihn bestimmte Paket finden kann
  • Es ist aber auch möglich, eine Null-ID anzugeben, so dass der Empfänger alle verfügbaren privaten Schlüssel durchprobieren muss
  • 1 Byte, das den verwendeten Public-Key-Algorithmus codiert (siehe Tabelle)
  • Den verschlüsselten Session-Key

Folgende Public-Key-Algorithmen sind möglich:

Public-Key-Algorithmen
ID Algorithmus Bemerkungen
1 RSA zum Verschlüsseln und Signieren
2 RSA nur zum Verschlüsseln
3 RSA nur zum Signieren
16 Elgamal nur zum Verschlüsseln
17 DSA nur zum Signieren
18 ECDH definiert in RFC 6637
19 ECDSA definiert in RFC 6637
20 reserviert
21 reserviert für Diffie-Hellman nach ANSI X9.42, wie für IETF-S/MIME definiert
100 … 110 reserviert für private / experimentelle Algorithmen

Für ECC-Schlüssel existieren verschiedene elliptische Kurven

  • Diese werden anhand ihrer OID identifiziert, so dass das Hinzufügen neuer Kurven keine Änderung am OpenPGP-Standard erfordert
ECC-Kurven für OpenPGP
Name Bitlänge OID Bemerkungen
NIST curve P-256 256 1.2.840.10045.3.1.7 definiert in RFC 6637
NIST curve P-384 384 1.3.132.0.34
NIST curve P-521 521 1.3.132.0.35
Ed25519 255 1.3.6.1.4.1.11591.15.1 seit GnuPG 2.1.0, noch kein RFC
Brainpool P256r1 256 1.3.36.3.3.2.8.1.1.7
Brainpool P384r1 384 1.3.36.3.3.2.8.1.1.11
Brainpool 512r1 512 1.3.36.3.3.2.8.1.1.13
secp256k1 256 1.3.132.0.10 seit GnuPG 2.1.0

Paket Typ 3: „Symmetric-Key Encrypted Session Key“

Eine verschlüsselte OpenPGP-Nachricht kann kein, ein oder mehrere Pakete vom Typ 3 enthalten

  • Diese werden genutzt, um den Session Key nicht mit dem Public Key des Empfängers zu verschlüsseln, sondern mit einem symmetrischen Key, der aus einer Passphrase erzeugt wird
  • Pro Passphrase wird dabei je ein Paket vom Typ 3 erzeugt

Ein Typ-3-Paket enthält folgende Daten:

  • Eine Versionskennung
  • Derzeit ist nur Version 4 definiert
  • Ein Byte, das den symmetrischen Chiffrier-Algorithmus codiert
  • Eine Kennung variabler Länge, die angibt, wie der Schlüssel aus der Passphrase abgeleitet wird („string-to-key specifier“)
  • gegebenenfalls der mit dem o. g. Verfahren verschlüsselte Session-Key
Symmetrische Chiffrier-Algorithmen
ID Algorithmus Schlüssellänge Bemerkungen
0 unverschlüsselt – für Paket Typ 3 nicht erlaubt
1 IDEA 128 Bit einziger Algorithmus in PGP 2.6
2 TripleDES (DES-EDE) 168 Bit muss laut RFC implementiert werden
3 CAST5 128 Bit Default-Algorithmus in GnuPG 2.0
4 Blowfish 128 Bit 16 Runden
5 … 6 reserviert
7 AES 128 Bit Default-Algorithmus seit GnuPG 2.1
8 192 Bit
9 256 Bit
10 Twofish 256 Bit
11 Camellia 128 Bit definiert seit RFC 5581
12 192 Bit
13 256 Bit
100 … 110 reserviert für private / experimentelle Algorithmen

Alle Algorithmen außer TripleDES sind allerdings optional, eine standardkonforme Implementierung muss nur TripleDES beherrschen. RFC 4880 empfiehlt, dass jede Implementierung CAST5 und AES-128 beherrscht

Anwendungen

Zwei der Hauptanwendungen sind die Signierung und die Verschlüsselung von E-Mails

  • Dafür müssen OpenPGP-Nachrichten geeignet kodiert werden, da eine E-Mail nach RFC 5322 nur aus druckbaren Zeichen aus dem ASCII-Zeichensatz und einigen wenigen Steuerzeichen bestehen darf

Hierfür gibt es im Wesentlichen zwei Formate:

  • das ältere PGP/INLINE als Kompatibilitätsformat
    • Auch nutzbar (wenn auch nicht unproblematisch) mit Mailprogrammen, die OpenPGP nicht kennen (auch Webmail)
  • Die E-Mail wird dabei von ihrer Struktur her als gewöhnliche Textmail erzeugt (Content-Type: text/plain), die verschlüsselten Text als Radix-64-kodierten Text enthält (Base64 plus Prüfsumme; ursprüngliches Textformat von PGP); signierter Text wird als Klartextsignatur eingefügt (Einleitungszeile, normaler Text, Signaturdaten als Radix-64)
  • Dies ermöglicht nur das Signieren und Verschlüsseln einfachen Mailtextes (Mailbody)
    • Für HTML-Mails gibt es keine entsprechende Möglichkeit
    • Dateianhänge können aber vorab verschlüsselt und/oder signiert werden (das übernehmen die Mailprogramme; im Fall von Webmail muss man das ohne entsprechendes Browser-Addon selber machen)
  • Allerdings garantieren die Signaturen dann nicht die Integrität der Mail insgesamt
  • Signierte Teile können unbemerkt entfernt werden, in anderem Zusammenhang signierte Daten können hinzugefügt werden (was nur auffiele, wenn man sich die Mühe machte, die Zeitstempel der einzelnen Signaturen zu vergleichen)
    • Einer der Nachteile von PGP/Inline ist, dass Mailprogramme, die OpenPGP nicht verstehen, die Signatur im Text anzeigen, was viele Empfänger verwirrt
  • PGP/MIME als saubere technische Lösung (MIME-Erweiterung nach RFC 3156)
    • Dieses Verfahren deckt auch Dateianhänge und HTML-Mails ab
  • Für den Mailbody und alle Anhänge kann jeweils einzeln festgelegt werden, ob sie verschlüsselt und/oder signiert werden sollen; es wird technisch nur eine Signierung und/oder Verschlüsselung vorgenommen (bei PGP/Inline für den Textteil und jeden Dateianhang gesondert)
    • Auch dieses Verfahren schützt aber nur den Inhalt der Mail, nicht ihre Kopfdaten (vor allem Absender, Empfänger, Betreff, Datum)
    • Der Nachteil von PGP/MIME ist, dass Mailprogramme (oder Webmail-Implementierungen), die nicht einmal den grundlegenden Standard von 1995 (RFC 1847) unterstützen, der das grundsätzliche E-Mail-Format für verschlüsselte oder signierte Inhalte festlegt, im Zweifelsfall eine leere Mail mit Dateianhängen anzeigen, was noch irritierender und noch weniger benutzerfreundlich ist als eine Radix-64-Signatur im Text

Manche Mailprogramme bieten die Möglichkeit, für die Adressbucheinträge festzulegen, in welchem Format OpenPGP-Nachrichten an die jeweilige Adresse geschickt werden sollen

  • Auf diese Weise kann man die Nachteile beider Verfahren minimieren

OpenPGP und S/MIME (welches X.509-Zertifikate verwendet) sind die beiden wichtigsten Standards für E-Mail-Verschlüsselung

  • Eine weitere Hauptverwendung von OpenPGP ist die Absicherung der Softwareverteilung (Paketverwaltung) von z. B. Linux durch digitale Signaturen

Geschichte

Entstanden ist OpenPGP im Jahr 1998 als Reaktion auf diverse Entwicklungen:

  • Die in PGP verwendeten Algorithmen (IDEA und RSA) waren patentiert und konnten nicht beliebig verwendet werden
  • Insbesondere gab es in den USA Gesetze, die den Export von starker Verschlüsselung (ab 40 Bit) verboten
  • Das Programm PGP wurde kommerziell durch die Firma PGP Inc
  • vertrieben, und es gab unbelegte Gerüchte, dass eine Hintertür in das Programm eingebaut sei, da es über eine sogenannte ADK-Funktion (Additional Decryption Key) verfügte
  • Ende 1997 wurde PGP Inc
  • von Network Associates Inc. (NAI) bzw. McAfee übernommen, die zeitweilig den PGP-Quelltext verschlossen hielten, ADK-Funktionen einbauten und Mitglied der Key Recovery Alliance waren

Das OpenPGP-Format wird mittlerweile von vielen Produkten implementiert

  • Prominente Vertreter sind das kommerzielle PGP und das freie Open-Source-Programm GnuPG (unter der GNU-GPL stehend)

Das ebenfalls weit verbreitete S/MIME-Format verwendet dagegen X.509-Zertifikate und ist deshalb grundsätzlich nicht kompatibel zu OpenPGP, auch wenn es auf unterster Ebene dieselben kryptografischen Verfahren verwendet

  • Es existieren Programme, welche OpenPGP-Schlüssel im RSA-Format in X.509-Schlüssel umwandeln können (und umgekehrt: pem2openpgp aus dem monkeysphere-Paket); diese Konvertierung betrifft aber nur das rohe Schlüsselmaterial, die Zertifizierungen durch Dritte gehen verloren
  • Auch eine Verwendung derselben Schlüssel für SSH ist (etwa mittels GnuPG) möglich

Vorlage:Überarbeiten Es gibt ferner die OpenPGP Alliance als Zusammenschluss mehrerer Hersteller, die sich dem OpenPGP-Format verpflichtet fühlen

  • Seit August 2016 wird diese Seite von Dominik Schürmann betreut

Kryptographische Verfahren

Verschlüsselung

OpenPGP benutzt eine hybride Verschlüsselung, die die Vorteile asymmetrischer Kryptosysteme (sichere Schlüsselübertragung) mit denen symmetrischer Kryptosysteme (hohe Geschwindigkeit) kombiniert

Statt wie bei einem symmetrischen System nur einen Schlüssel sowohl für Ver- als auch Entschlüsselung zu verwenden, besteht bei einem asymmetrischen System ein Schlüsselpaar aus zwei zusammengehörigen Schlüsseln, einem öffentlichen und einem geheimen

  • Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem geheimen Schlüssel wieder entschlüsselt werden; es ist nicht möglich, die Verschlüsselung mit dem öffentlichen Schlüssel aufzuheben
  • Mit dem asymmetrischen Verfahren wird ein symmetrischer Sitzungsschlüssel verschlüsselt, mit dem wiederum die eigentlichen Daten verschlüsselt werden

Die symmetrische Verschlüsselung erfolgt stets mit einem modifizierten CFB-Modus

  • Dabei besteht der eigentliche Initialisierungsvektor nur aus Nullbytes, dafür werden dem Klartext 10 (bei Blockchiffren mit 64 Bit Blockgröße) bzw. 18 (bei 128 Bit Blockgröße) Bytes vorangestellt
  • Diese bestehen aus einem Block Zufallsdaten und der Wiederholung der ersten beiden Zufallsbytes
  • Durch diese Redundanz kann beim Entschlüsseln (mit einer Fehlerwahrscheinlichkeit von 1:65536 = 0,0015 %) erkannt werden, ob mit dem richtigen Schlüssel entschlüsselt wurde

Signatur

Neben der Verschlüsselung unterstützt OpenPGP auch digitale Signaturen, mit denen Empfänger die Integrität von Nachrichten feststellen können

  • Dazu wird vom Absender eine Prüfsumme (auch Hash-Wert genannt) der Daten gebildet, aus der dann mit dem privaten Schlüssel die Signatur gebildet wird (die signierten Daten bleiben unangetastet)
  • Der Empfänger kann die Signatur mit dem öffentlichen Schlüssel des Absenders prüfen

Algorithmen

OpenPGP ist gegenwärtig in RFC 4880 standardisiert, dem Nachfolger von RFC 2440. RFC 4880 legt fest, dass eine Implementierung das Elgamal-Verschlüsselungsverfahren, DSA, Triple DES und SHA-1 unterstützen muss

  • Weiterhin wird dort empfohlen, dass Implementierungen die in PKCS #1 v1.5 beschriebenen, auf dem RSA-Kryptosystem basierenden, Verschlüsselungs- und Signaturverfahren, sowie AES-128, CAST-128 und IDEA unterstützen
  • Darüber hinaus gibt es eine Vielzahl weiterer Verfahren, die mit OpenPGP verwendet werden dürfen
  • Der Standard wurde 2009 durch RFC 5581 um Camellia erweitert. 2012 fügte RFC 6637 Unterstützung von Elliptic Curve Cryptography (ECDSA, ECDH) hinzu

Schlüsselbeglaubigung

Öffentliche Schlüssel können von anderen Schlüsselinhabern signiert („zertifiziert“) werden

  • Der Signierende/Zertifizierer belegt damit, dass er sowohl den Schlüssel (also den Fingerprint) als auch die im Schlüssel enthaltene User-ID überprüft hat (wofür es jedoch keine festen Regeln gibt)
  • Hat ein öffentlicher Schlüssel mehrere User-IDs, dann müssen diese einzeln zertifiziert werden
  • Im Gegensatz zu S/MIME basiert diese Signierung jedoch nicht auf einem hierarchischen System, bei der nur eine übergeordnete Stelle Schlüssel untergeordneter Stellen signieren darf, sondern aus einem Netz des Vertrauens (Web of Trust), in dem jeder Teilnehmer die Schlüssel anderer signieren kann
  • Die mit der Signatur (implizit) gemachte Aussage über die Echtheit des Schlüssels und der jeweiligen Identität (Name, E-Mail, Kommentar) ermöglicht es Dritten, die Authentizität des Zertifikats einzuschätzen
  • Vertraut zum Beispiel B den Zertifizierungen von A (entweder vollständig oder teilweise), könnte B auch dem öffentlichen Schlüssel des ihm unbekannten Teilnehmers C vertrauen, wenn dieser Schlüssel durch A zertifiziert wurde
  • Die Zertifizierung bezieht sich nur auf die Echtheit des Schlüssels; ob A auch den Zertifizierungen von C vertraut, ist aus der Signatur von A nicht ersichtlich und für die Zertifizierung von C durch A unerheblich
  • Die Gültigkeit von Zertifikaten ist eine öffentliche Information, das Vertrauen der Nutzer in andere ist eine private Information
  • Leider werden sehr oft Schlüsselgültigkeit und Zertifizierungsvertrauen miteinander verwechselt

Eine weitere, einfachere Methode, die Echtheit eines Schlüssels zu prüfen, ist der Vergleich des Fingerabdrucks

  • Dabei handelt es sich um eine Prüfsumme der Schlüsseldaten (öffentlicher Hauptschlüssel plus dessen Generierungs-Zeitstempel) in hexadezimaler Form (zum Beispiel „72F0 5CA5 0D2B BA4D 8F86 E14C 38AA E0EB“), die sich leicht im direkten Gespräch, per Telefon oder per Brief vergleichen lässt

Der öffentliche Schlüssel kann auch mit Hilfe der eID-Funktion des Personalausweises von der Firma Governikus im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) beglaubigt werden

Wird der öffentliche OpenPGP-Schlüssel auf einen Schlüsselserver wie keys.openpgp.org oder keys.mailvelope.com hochgeladen, wird die mit dem Schlüssel verbundene E-Mail-Adresse per Bestätigungslink verifiziert

Aufbau der Zertifikate

OpenPGP-Zertifikate (der aktuellen Version 4) bestehen aus einer Reihe von Komponenten

  • Ihre Daten werden nicht in ihrer Gesamtheit zertifiziert, sondern in einzelnen Komponenten, teils vom Schlüsselbesitzer und von Dritten, teils nur vom Schlüsselbesitzer
  • Damit geht einher, dass sich ein Zertifikat im Lauf der Zeit ändern kann
  • Komponenten können hinzugefügt, geändert und gelöscht werden

Die wichtigsten Komponenten eines OpenPGP-Zertifikats sind:

  1. genau ein öffentlicher Hauptschlüssel (auf den sich der Fingerabdruck bezieht, der den Schlüssel insgesamt identifiziert), mit Erzeugungs- und ggf
  • auch Ablaufdatum
  1. eine oder mehrere User-IDs (Text zur Beschreibung des Benutzers, typischerweise im Format Vorname Nachname (Kommentar) <E-Mail-Adresse>, ggf
  • mit Ablaufdatum)
  1. eventuell vorhandene Unterschlüssel (ggf
  • mit Ablaufdatum)
  1. eventuell Zusatzinformationen zur Verwendung des Schlüssels (Präferenz von Hash- und Verschlüsselungsalgorithmen, bevorzugter Keyserver, URL einer Schlüsselrichtlinie)
  2. Signaturen des Schlüsselbesitzers oder von Dritten, die die Echtheit der genannten Komponenten bestätigen oder ihre Gültigkeit widerrufen; Signaturen haben ein Erzeugungs- und eventuell ein Ablaufdatum

Dritte signieren nur die Kombination aus Hauptschlüssel und einer User-ID; es muss daher jede User-ID einzeln signiert werden

  • Ob er alle User-IDs signiert, steht einem Dritten frei
  • Der Schlüsselbesitzer signiert alles
  • Unsignierte Komponenten sind wertlos und werden ignoriert
  • Dadurch kann der Besitzer eigenmächtig seine Präferenzen, Zusatzinformationen und Gültigkeitsdauern ändern
  • Er kann Unterschlüssel und User-IDs hinzufügen und widerrufen
  • Unterschlüssel werden von OpenPGP-Software automatisch akzeptiert (wenn sie eine Eigenzertifizierung haben), User-IDs dagegen nicht
  • Wenn man seinen Schlüssel von Dritten zertifizieren lässt und anschließend eine E-Mail-Adresse hinzufügt (die nicht von Dritten zertifiziert wird), dann erhalten die Verwender des Zertifikats eine Warnung, wenn sie für die hinzugefügte E-Mail-Adresse verschlüsseln wollen
  • Die Anzeige der wichtigsten Elemente in GnuPG (--list-sigs):
pub 1024D/0x12345678 2005-09-05
 D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 1234 5678

uid Vorname Nachname <vorname.nachname@example.org>
sig 0x12345678 Vorname Nachname <vorname.nachname@example.org>
sig 0x87654321 Zertifizierer <zertifizierer@example.org>

uid Vorname Nachname (Geschäftsführer der Beispiel GmbH) <vorname.nachname@example.net>
sig 0x12345678 Vorname Nachname <vorname.nachname@example.org>
sig 0x87654321 Zertifizierer <zertifizierer@example.org>

sub 2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
sig 0x12345678 Vorname Nachname <vorname.nachname@example.org>

Zu sehen ist, dass nur ein Hauptschlüssel (pub) vorhanden ist, dass es sich dabei um einen 1024 Bit langen DSA-Schlüssel handelt und wann dieser Hauptschlüssel erzeugt wurde

  • Darunter steht sein Fingerabdruck
  • Die ID, mit der Schlüssel zumeist bezeichnet werden, ist der letzte Teil des Fingerabdrucks
  • Dann sind zwei User-IDs (uid) zu sehen, die beide einen Namen und eine E-Mail-Adresse beinhalten und beide sowohl von dem zugehörigen Schlüssel selber als auch von einem anderen Schlüssel signiert wurden
  • Nur eine der User-IDs enthält einen Kommentar, in diesem Fall eine berufliche Position
  • Auf diese Weise kann ein organisatorisch entsprechend qualifizierter Schlüssel eines Unternehmens (etwa der des Geschäftsführers) die Position von Mitarbeitern des Unternehmens gegenüber Dritten, die dem ersten Schlüssel vertrauen, beglaubigen
  • Außerdem ist zu sehen, dass Unterschlüssel (sub) nur von ihrem Hauptschlüssel signiert werden, nicht aber von Dritten

Die einzelnen Komponenten des Zertifikats werden anders als bei X.509 ohne Kryptografie zusammengefügt

  • Die kryptografische Sicherung befindet sich nur jeweils innerhalb der Komponente
  • Man kann deshalb unbemerkt Teile eines Zertifikats löschen
  • Das heißt, dass der Nutzer im Allgemeinen nicht sicher sein kann, dass ein Zertifikat, das er sich (wie üblich) aus einer unsicheren Quelle beschafft hat, vollständig ist
  • Um diese Sicherheit zu bieten, kann man ein Zertifikat in eine Datei exportieren und diese dann signieren

Qualifizierte Signaturen nach dem Signaturgesetz

Das deutsche Signaturgesetz (SigG) unterscheidet elektronische Signaturen, fortgeschrittene elektronische Signaturen und qualifizierte elektronische Signaturen

  • Letztere sind der eigentliche Inhalt des Gesetzes, die ersten beiden Gruppen dienen nur der Abgrenzung
  • Das SigG stellt sowohl technische als auch organisatorische Anforderungen an die Anerkennung qualifizierter Signaturen
  • Derzeit (2012) bieten die Zertifizierungsdiensteanbieter keine qualifizierten Zertifikate auf Basis von OpenPGP an, es ist also nicht möglich, mit OpenPGP qualifizierte Signaturen zu erzeugen
  • Das hat auch technische Gründe
  • Zum derzeitigen Konzept von OpenPGP gehört,
  1. dass nur der Hauptschlüssel (zusammen mit einer User-ID) zertifiziert wird, nicht aber die Unterschlüssel
  2. dass man mit einem Hauptschlüssel neue Unterschlüssel erzeugen kann

Das Signaturgesetz verlangt, dass die privaten Schlüssel qualifizierter Zertifikate in Hardware gespeichert werden, aus der sie nicht ausgelesen werden können

  • Das sind typischerweise Smartcards
  • Da die aktuelle Version von OpenPGP die Signaturen von Unterschlüsseln genauso behandelt wie die von Hauptschlüsseln, eignen sich normale OpenPGP-Schlüssel prinzipiell nicht für qualifizierte Signaturen
  • Aber selbst wenn man einen atypischen, dieser Forderung entsprechenden OpenPGP-Schlüssel erzeugte, müsste die für seine Erzeugung und Speicherung verwendete Hard- und Software durch eine vom BSI anerkannte Stelle daraufhin überprüft werden, ob sie den Sicherheitsanforderungen des Gesetzes genügt
  • Die Kosten einer solchen Prüfung sind ein weiterer Hinderungsgrund für die Verfügbarkeit von OpenPGP für qualifizierte Signaturen

Das deutsche Signaturgesetz wurde am 29

Anwendung

Problembehebung

Konfiguration

Dateien

Anhang

Siehe auch

Sicherheit

Dokumentation

Normen und Standards

OpenPGP ist als Request for Comments (RFC) standardisiert und wird fortwährend weiterentwickelt

  • Seit dem 31. August 2020 liegt ein finaler Entwurf im weltweiten Review, der RFC 4880, ersetzen soll

Zusätzlich gibt es einen RFC, der sich speziell um PGP/MIME beschäftigt:

RFC
RFC Titel
0000
Man-Page
Info-Pages

Links

Projekt
Weblinks
  1. https://de.wikipedia.org/wiki/OpenPGP
Abgerufen von „https://wiki.foxtom.de/index.php?title=OpenPGP&oldid=114469“