Date: Mon, 22 Nov 1999 19:33:30 -0500 (EST)
From: support@redtenbacher.de
Subject: Automat. Ver-/Entschluesselung von E-Mail, Teil II
Sehr geehrte "signatur"-Abonnenten,
heute geht es um die Sicht des Mailserver-Administrators: "Was
muß er wissen, und welche Arbeitsschritte fallen für ihn an?"
Dabei werde ich mich wieder am Programm "KT-MAIL/Krypto" orientieren.
Die beschriebenen Vorgehensweisen lassen sich jedoch jederzeit auch
auf beliebige andere Programme/Umgebungen übertragen.
ABSCHNITT 2: Die Sicht des Mailserver-Administrators
Jede Verschlüsselung (egal, ob automatisiert oder nicht) erfordert ein
gewisses "Schlüsselmanagement", das zumindest aus Import, Validieren
und Signieren der verwendeten Schlüssel besteht. Im Fall von
"KT-MAIL/Krypto" werden diese Schritte zentral vom Mailserver-Administrator
abgewickelt. Dieser muß daher im Unterschied zum Endanwender die
Grundsätze der PGP-Bedienung beherrschen.
Er sollte also das Tutorial des Verschlüsselungsprojekts
durchgearbeitet haben.
Da "KT-MAIL/Krypto" für die eigentliche Ver-/Entschlüsselung der
Dateien das Programm PGP benutzt, können die Schritte "Import" und
"Validierung" unmittelbar gemäß dem Tutorial-Schritt 5B und der
Schritt "Signieren" gemäß dem Tutorial-Schritt 4A durchgeführt werden.
Zur Erleichterung der Arbeit des Administrators bietet
"KT-MAIL/Krypto" jedoch ein kleines Administrator-Menü an, in dem aus
der Vielzahl der PGP-Möglichkeiten genau die regelmäßig
durchzuführenden Arbeitsschritte herausgepickt sind. Es umfaßt derzeit
folgende Menüpunkte:
1. PGP-Schlüsseldatei importieren
2. Schlüsselliste mit Fingerprints laden
3. PGP-Schlüssel signieren
4. Datei PGP.CFG laden
5. Datei KRYPTO.TAB laden
(Der Aufruf des Administrator-Menüs erfolgt über den Befehl
"makro pgpsetup" in der Befehlszeile von Komforttext. Die Menüpunkte
könnten aber natürlich auch in jeder anderen Menüsprache realisiert
werden.)
Menüpunkt 1:
Ein fremder PGP-Schlüssel liegt normalerweise als ASCII-Datei vor.
Diese muß in den eigenen Schlüsselbund importiert werden, bevor der
PGP-Schlüssel genutzt werden kann.
Der Menüpunkt "PGP-Schlüsseldatei importieren" erfragt den Namen
und Pfad der zu importierenden Datei über eine Dialogbox, die in
etwa dem Windows-Dialog zum Öffnen einer Datei entspricht.
Anschließend wird automatisch das PGP-Verzeichnis gesucht und der
passende Importbefehl (unter DOS z.B. "pgpk -a <Importdatei>")
ausgelöst.
Menüpunkt 2:
Zum Validieren eines importierten öffentlichen PGP-Schlüssels werden
als nächstes die "Key-ID", die Schlüssellänge und der sog.
"Fingerprint" (= "Fingerabdruck") des Schlüssels benötigt (vgl.
Tutorial-Schritt 5B).
All diese Angaben liefert der Menüpunkt "Schlüsselliste mit
Fingerprints laden". (Er sucht automatisch das PGP-Verzeichnis,
liest die akt. Schlüsselliste über einen Befehl der Art
"pgpk -ll >krypto.lst" aus und lädt diese Liste anschließend zum
bequemen Suchen/Blättern in ein Editorfenster.)
Anschließend kann die Echtheit des Schlüssels z.B. telefonisch
überprüft werden.
Menüpunkt 3:
Wurde die Echtheit eines importierten Schlüssels überprüft, so
sollte er als nächstes auf dem eigenen Schlüsselbund signiert (und
damit als "gültig" markiert) werden. Dies kann direkt aus der
geladenen Schlüsselliste von Menüpunkt 2 erfolgen, indem dort der
Menüpunkt "PGP-Schlüssel signieren" ausgewählt und der zu
signierende Schlüssel in einer Dialogbox eingegeben wird.
Der PGP-Aufruf zum Signieren (unter DOS z.B. in der Form
"pgpk -s -u <eigene ID> <zu signierender Schlüssel>") erfolgt
wiederum automatisch, wobei die ID des eigenen Schlüssels, der zum
Signieren verwendet wird, selbsttätig gesucht wird. (Ist in der
PGP-Konfigurationsdatei PGP.CFG ein Eintrag "MyName=..."
enthalten, so wird der dort angegebene Schlüssel zum Signieren
verwendet. Fehlt ein solcher Eintrag, so wird unter allen eigenen
PGP-Schlüsseln der zuletzt erzeugte gesucht und zum Signieren
benutzt.)
In der Regel besteht die "Wartungsarbeit" des Administrators also
daraus, bei neu eingetroffenen PGP-Schlüsseln die Menüpunkte 1 bis 3
des Administrator-Menüs der Reihe nach auszulösen (und beim Menüpunkt
2 natürlich die Identität des Schlüsselpartners zu überprüfen!).
Menüpunkt 4:
Der Menüpunkt "Datei PGP.CFG laden" wird nur gelegentlich gebraucht.
Er dient dazu, dem Administrator die Suche nach dem PGP-Verzeichnis
und das manuelle Laden der PGP-Konfigurationsdatei zu ersparen.
In der Praxis gibt es in der Datei PGP.CFG nur 2 Einträge, die im
Anschluß an eine Erstinstallation ggf. später geändert werden
müssen:
(a) Der Eintrag "MyName=...": Dieser Eintrag ermöglicht das
Festlegen desjenigen (eigenen) PGP-Schlüssels, der für das
Signieren von importierten Fremdschlüsseln benutzt werden soll.
(Gibt es nur 1 eigenen PGP-Schlüssel, ist der Eintrag nicht
erforderlich.)
Der Eintrag "MyName=..." hat beim Einsatz von "KT-MAIL/Krypto"
sonst keine Bedeutung. Welcher Schlüssel zum Signieren von
E-Mails benutzt wird, wird dort nicht über die Datei PGP.CFG,
sondern über die zentrale KT-MAIL/Krypto-Konfigurationsdatei
KRYPTO.TAB (s. Menüpunkt 5) gesteuert. (Diese erlaubt
beispielsweise, für verschiedene Absender im Haus
unterschiedliche Signaturschlüssel festzulegen.)
(b) Der Eintrag "NoBatchInvalidKeys=...": Dieser Eintrag ("im
automatischen Modus keine unvalidierten Schlüssel zulassen") hat
nach der Installation von "KT-MAIL/Krypto" den Wert "0" und
erlaubt damit das Versenden von verschlüsselten Mails an alle
Empfänger, deren PGP-Schlüssel in den eigenen Schlüsselbund
importiert wurden - auch ohne Validierung dieser Schlüssel.
Diese Einstellung erlaubt ein schnelles Testen des Arbeitens mit
verschlüsselten/signierten E-Mails, ohne zu diesem Zeitpunkt
bereits Kenntnisse einer korrekten Schlüsselvalidierung zu
verlangen.
Die volle Sicherheit von PGP wird aber natürlich erst durch
korrektes Validieren/Signieren der importierten PGP-Schlüssel
gemäß dem Tutorial-Schritt 5B erreicht. Daher sollte der Eintrag
"NoBatchInvalidKeys=..." nach der Lernphase auf "1" gesetzt
werden. Dadurch läßt PGP nur noch solche Empfängerschlüssel zu,
die validiert und signiert wurden.
Menüpunkt 5:
Der Menüpunkt "Datei KRYPTO.TAB laden" lädt die zentrale
Konfigurationsdatei von "KT-MAIL/Krypto". Diese Datei ermöglicht
eine sehr flexible Konfiguration der Ver-/Entschlüsselung:
Hier kann für beliebige Empfänger (Bsp.: "wolfgang@redtenbacher.de")
oder ganze Domains (Bsp.: "redtenbacher.de") festgelegt werden,
welches Verschlüsselungsverfahren (derzeit "PGP" [RFC 2440] oder
"PGP-MIME" [RFC 2015]) und welcher PGP-Schlüssel für verschlüsselte
E-Mails an diesen Empfänger benutzt werden soll.
Für signierte E-Mails kann anhand des Empfängers oder des Absenders
(jeweils als E-Mail-Adresse oder Domain) spezifiziert werden,
welcher PGP-Schlüssel zur Signatur verwendet werden soll.
Außerdem kann für bestimmte Empfänger auch festgelegt werden, daß
E-Mails an diese Empfänger stets verschlüsselt, signiert oder
verschlüsselt+signiert werden sollen, auch wenn der Absender im
Haus dies nicht explizit verlangt hat (über die Zusätze "!V!"
und/oder "!S!" - vgl. Abschnitt 1 der zusammenfassenden
Dokumentation, "Die Sicht des Endanwenders").
Hinweis:
Stimmt bei einem Empfänger die User-ID im PGP-Schlüssel mit der
E-Mail-Adresse überein und soll die Verschlüsselung im "normalen"
PGP-Modus (= ohne PGP-MIME-Erweiterungen) erfolgen, so ist dafür
_kein_ Eintrag in der Datei KRYPTO.TAB erforderlich.
Für solche Empfänger reicht es aus, wenn der öffentliche
PGP-Schlüssel der betreffenden Person über die Menüpunkte 1 bis 3
des Administrator-Menüs importiert, validiert und signiert wird.
Einträge in der Datei KRYPTO.TAB sind nur erforderlich, wenn
entweder die E-Mail-Adresse des Empfängers von der E-Mail-Adresse in
der User-ID des PGP-Schlüssels abweicht oder wenn besondere Wünsche
hinsichtlich Verschlüsselung/Signatur hinterlegt werden sollen.
Aufbau der Datei KRYPTO.TAB:
Die Datei KRYPTO.TAB ist eine normale ASCII-Datei, die zwei
verschiedene Eintragstypen enthalten kann:
1. Empfängereinträge:
Diese Einträge bestehen aus einer Zeile mit 4 oder 5 Angaben.
Beispiel 1:
@staedtetag-bw PGP O post@staedtetag-bw
(a) Die erste Angabe in der Zeile (hier: "@staedtetag-bw") legt
fest, für welche Empfängeradresse(n) der Eintrag gilt. Der
obige Eintrag gilt z.B. für alle Empfänger, deren Adresse den
Text "@staedtetag-bw" enthält, also beispielsweise für
"norbert.brugger@staedtetag-bw.de" oder
"andrea.weber@staedtetag-bw.de". (Auf diese Weise braucht man
nur 1 statt 17 Einträge für die Mitarbeiter des Städtetags BW,
wenn für alle der gleiche PGP-Schlüssel verwendet werden soll.)
(b) Die zweite Angabe (hier: "PGP") legt das gewünschte
Verschlüsselungsverfahren fest. "KT-MAIL/Krypto" unterstützt
derzeit die beiden Varianten "PGP" und "PGP-MIME". (PGP-MIME
ist eine Erweiterung, die es ermöglicht, auch mehrteilige
E-Mails, deren Teile wiederum aus mehreren Alternativen [z.B.
ASCII und HTML] bestehen, unter Beibehaltung dieser
Eigenschaften verschlüsselt zu übertragen. Diese Erweiterung
wird allerdings nicht von jedem PGP-Plugin verstanden. Man
sollte sie daher nur wählen, wenn man weiß, daß der Empfänger
damit zurechtkommt, weil er z.B. Eudora oder KT-MAIL/Krypto
nutzt.)
Zukünftig werden als zweite Angabe auch weitere
Verschlüsselungsverfahren (z.B. "S/MIME 3.0") unterstützt
werden, wenn diese den Internet-Standardisierungsprozeß
erfolgreich abschließen.
(c) Die dritte Angabe (hier: "O") ermöglicht, für alle E-Mails an
diese(n) Empfänger eine Verschlüsselung und/oder Signatur zu
erzwingen. Die Einstellung "O" (= optional) verschlüsselt bzw.
signiert nur, wenn der Absender im Haus dies (über die Zusätze
"!V!" und/oder "!S!" im "Subject:"-Feld) angefordert hat.
Mit der Angabe "V" wird eine Verschlüsselung erzwungen, auch
wenn der Absender den Zusatz "!V!" nicht angibt. Auf analoge
Weise erzwingt die Angabe "S" eine Signierung der E-Mail, und
die Angabe "VS" erzwingt Verschlüsselung und Signatur.
(In der Praxis sollte man die Angabe "V" nur eintragen, wenn
der Empfänger - wie der Städtetag BW oder die Stadt
Kirchheim/Teck - über eine automatische Entschlüsselung
verfügt, weil man ihm sonst generell einen Zusatzaufwand zum
Entschlüsseln aufbürdet.)
(d) Die vierte Angabe (hier: "post@staedtetag-bw") gibt an, welcher
PGP-Schlüssel zum Verschlüsseln der E-Mails an diese(n)
Empfänger verwendet werden soll. Hier kann entweder ein
(eindeutiger) Teil der User-ID des PGP-Schlüssels oder (in der
Form "0x12345678") die Key-ID des PGP-Schlüssels stehen.
Die obige Zeile bewirkt also, daß für E-Mails an Mitarbeiter des
Städtetags BW im Fall einer Verschlüsselung das "normale"
PGP-Format und der Postschlüssel des Städtetags BW
("post@staedtetag-bw.de") benutzt werden.
Beispiel 2:
signatur@onelist PGP S - 0xAB11CDCB
Dieser Empfängereintrag ist analog zum Beispiel 1 aufgebaut. Weil
als 3. Angabe hier die Einstellung "S" steht, bewirkt diese Zeile,
daß alle E-Mails an die Mailingliste "signatur@onelist.com"
automatisch PGP-signiert werden.
Da als vierte Angabe (= Empfängerschlüssel) ein "-" steht, können
E-Mails an diese Adresse nicht verschlüsselt werden. (E-Mails, bei
denen der Absender den Zusatz "!V!" angibt, werden ihm also mit
einem Fehlerhinweis vom Mailserver zurückgesandt, ohne das Haus zu
verlassen.) In diesem Fall ist das hilfreich, weil bei Beiträgen an
eine Mailingliste eine Verschlüsselung normalerweise nicht sinnvoll
ist.
Enthält ein Empfängereintrag eine 5. Angabe (hier: 0xAB11CDCB), so
wird dadurch die Key-ID des Signaturschlüssels festgelegt. Im
obigen Fall erfolgt die Signatur an die Mailingliste daher
stets mit dem Schlüssel zur Key-ID "0xAB11CDCB". (Die fünfte Angabe
eines Empfängereintrags hat Vorrang vor einer Festlegung des
Signaturschlüssels durch die nachstehend beschriebenen
Absendereinträge.)
2. Absendereinträge:
Diese Einträge sind analog aufgebaut wie die Empfängereinträge,
enthalten aber die eigene(n) E-Mail-Adresse(n). Der darin
festgelegte PGP-Schlüssel (= die 4. Angabe in der Zeile) wird daher
nicht zum Verschlüsseln, sondern zur Absender-Kennung (= Signatur)
verwendet. Außerdem enthält die 4. Angabe den Signaturschlüssel
stets als "Key-ID" (= eine 8stellige Hexadezimalzahl nach dem
Vorspann "0x").
Beispiel 3:
@redtenbacher.de PGP O 0x8A4A53E8
Diese Zeile (aus meiner eigenen KRYPTO.TAB) legt fest, welcher von
meinen 3 PGP-Schlüsseln normalerweise als Signatur-Schlüssel für
E-Mails benutzt werden soll.
Soll der Signaturschlüssel davon abhängen, von welchem Absender im
Haus die E-Mail stammt, läßt sich das über mehrere solche Einträge
regeln (s.u.).
Beispiel 4:
wolfgang@redtenbacher PGP O 0x4F813FBA
@redtenbacher.de PGP O 0x8A4A53E8
Diese beiden Einträge, von denen der erste "Treffer" (d.h. der
erste Eintrag, der auf die "From:"-Angabe in der Ausgangsmail paßt)
gewinnt, bewirken, daß bei signierten E-Mails des Absenders
"wolfgang@redtenbacher.de" der PGP-Schlüssel mit der Key-ID
0x4F813FBA zum Signieren verwendet wird, beim Absender
"support@redtenbacher.de" (und allen anderen Absendern des Domains
"redtenbacher.de") jedoch der PGP-Schlüssel mit der Key-ID
0x8A4A53E8.
Auf diese Weise lassen sich bei Bedarf die Signaturschlüssel
maßgeschneidert festlegen.
Hinweis:
Der Aufbau der Datei KRYPTO.TAB ermöglicht eine sehr flexible und
für zukünftige Erweiterungen offene Konfiguration der
Mail-Verschlüsselung. Im Normalfall wird in der Datei KRYPTO.TAB
jedoch nur ein einziger Absendereintrag (zur Festlegung des
Signaturschlüssels) stehen und je ein Empfängereintrag pro
Empfänger/Domain, dessen E-Mail-Adresse von der User-ID des
PGP-Schlüssels abweicht.
Damit ist die Beschreibung der Sicht des Administrators (der sich um
das Importieren/Validieren/Signieren von PGP-Schlüsseln und um die
Pflege der Konfigurationsdatei KRYPTO.TAB kümmert) abgeschlossen.
Im nächsten Dokumentationsabschnitt geht es dann darum, wie man als
Programmierer eine automatische Ver-/Entschlüsselung von E-Mail in
Analogie zum Verhalten von "KT-MAIL/Krypto" implementieren kann.
(Dabei wird es natürlich etwas "technisch" werden. Für einige
knifflige Stellen [Kodierung/Dekodierung der Internet-Formate, Analyse
der PGP-Pakete] werde ich daher nicht nur den "roten Faden" des
jeweiligen Algorithmus, sondern auch den Kern von geeigneten
Programmen im Quellcode publizieren.)
- Wolfgang Redtenbacher
"signatur"-Moderator
[Zurück zur Hauptseite des
Verschlüsselungsprojekts]