PMail32.de
Pegasus Mail | Mercury | pmail.com 
Home | Info | Sitemap | Hilfe | Download 
 PMail32.de - Pegasus Mail
Donnerstag, 28.03.2024 

PGP: Schlüsselgenerierung

PGP: Schlüsselgenerierung basiert auf dem EDV-Info-Artikel "PGP: Schluesselgenerierung" aus dem Jahr 2001.

Schluesselgenerierung

Version 1.0 (14.10.97)

(c) 1997, Yorck Schneider-Kuehnle

- -------------------------------------------------------

Nach der Testphase, in der ich mit einigen Schluesseln und Freunden
die verschiedenen Moeglichkeiten von PGP ausprobiert hatte, habe ich
mir meinen endgueltigen Schluessel erzeugt und auch entsprechend
verteilt.

Diese Anleitung ist dazu gedacht, dass insbesondere Anfaenger nicht
etwas Wesentliches bei der Generierung der Schluessel vergessen.

Erprobt und geschrieben wurde sie unter Verwendung von PGP 2.6.3i
unter DOS/Win95. Aber sinngemaess sollten viele Vorgaenge auch unter
PGP 5.0 gelten. Ich habe selbst noch keine Versuche mit PGP 5.0
gemacht, werde das aber wohl nachholen, sobald die internationale
Version verfuegbar ist und ich Zeit dafuer gefunden habe.

UEber Rueckmeldungen und Verbesserungsvorschlaege per Email freue ich
mich jederzeit. (Yorck.Schneider-Kuehnle@urz.uni-heidelberg.de)

- ------------------------------------------------------------------ Nun
aber zur eigentlichen Anleitung.

Das Wichtigste ist: Die hierbei erzeugten Schluessel sind - was den
geheimen Schluessel angeht - sicher aufzubewahren und gegen den
Zugriff von Dritten zu schuetzen.

Je nach Sicherheitsbeduerfnis und auch persoenlichen Gegebenheiten
koennen da sehr unterschiedliche Massnahmen notwendig werden.
Letztendlich muss jeder selbst ueberlegen, wie der Missbrauch seines
Schluessels zu verhindern ist.

Zunaechst einmal ist es sehr wichtig, dass man selbst den geheimen
Schluessel nie verliert. Selbst wenn eine dritte Person diesen
Schluessel einmal in die Haende bekommen sollte, so benoetigt man
selbst immer noch den geheimen Schluessel, um auf dem Keyserver die
Schluessel sperren zu lassen. Dazu aber spaeter mehr, wenn es um das
revokation-certificate geht. Jetzt ist es erst einmal wichtig, dass
Sicherungskopien von den erzeugten Schluesseln gemacht werden koennen.

Ich habe - bevor ich mit der Schluesselgenerierung angefangen habe -
mir drei (Marken-)Disketten gesucht und diese neu formatiert (nicht
quick-format). Das kann man z.B. im Explorer machen. Bei der
Gelegenheit habe ich auch gleich die Systemdateien mit auf die
Diskette kopieren lassen. Schaden kann’s nicht, Platz ist auch genug
da und wer weiss, wann ich diese Diskette spaeter mal nutzen will.

Danach habe ich diese Disketten auf Oberflaechenfehler untersucht.
Dazu eignen sich z.B. das Utility Scandisk von Windows 95 oder auch
andere Tools wie die Norton Utilities. Nachdem die Disketten so
vorbereitet sind, denke ich, alles nur moegliche getan zu haben, um
meinen Schluessel auch ueber Jahre hinweg sicher lagern zu koennen.
Der Aufwand den man hier treibt, ist jedem selbst ueberlassen, aber
man sollte doch sorgfaeltig darueber nachdenken.

- ----------------------------------------------------------------------
- ------------

Jetzt gehts um die Erzeugung der Schluessel:

Vorueberlegungen:

Zur Schluessellaenge ist meinen UEberlegungen nach folgendes Vorgehen
sinnvoll. Ich erzeuge mir zwei Schluessel. Einer hat eine Laenge von
1024 Bit und ist damit meines Wissens in allen mir bekannten Versionen
von PGP einsetzbar (insbesondere auch in aelteren).

Da ich aber gerne auch die Moeglichkeiten von PGP 2.6.3i ausnutzen
will, erzeuge ich zusaetzlich einen 2048bit langen Schluessel. Die
Zeit, die dies erfordert ist nur einmalig bei der Generierung
aufzuwenden und macht den Schluessel nur noch schwerer zu knacken. Wem
dies zu paranoid erscheint, der kann auch jede andere Laenge waehlen
(aeltere Versionen koennen max. 1024bit nutzen). Die von der
Zeitschrift c’t initierte Krypto-Kampagne fordert allerdings fuer neue
Schluessel mindestens 1024 Bit [2].

Da die meisten Versionen (alle?) immer den Schluessel mit dem neuesten
Datum verwenden (zumindest als default) erzeuge ich mir zuerst den
1024bit Schluessel. Da dieser eigentlich nur fuer
Abwaertskompatibilitaet sorgen soll, bekommt er das aeltere Datum.

An dieser Stelle vielleicht noch ein Hinweis: Das Erzeugungsdatum, das
ein Schluessel traegt, ist in keinster Weise gesichert.

Jeder kann - fahrlaessig oder mutwillig - Schluessel mit beliebigem
Datum generieren. Dazu muss nur das Systemdatum anders gesetzt werden.

Daher bitte vor der Generierung der Schluessel einmal kurz die
Systemzeit ueberpruefen und gegebenenfalls neu stellen. Dazu unter DOS
(entweder direkt oder in einer DOS-Box unter Windows) kurz mal das
Kommando "TIME" eintippen. Die Systemzeit erscheint. Diese kann man
nun mit einer genaugehenden Uhr (Funkuhr oder auch der Videotext der
ARD) vergleichen. Wenn sie uebereinstimmt, einfach ENTER druecken.
Ansonsten die korrekte Zeit eingeben und ENTER druecken.

Auf die gleiche Weise laesst sich das Systemdatum ueberpruefen. Dazu
einfach "DATE" eingeben.

Generierung der Schluessel:

Ich beschreibe hier die Befehle, die unter DOS direkt eingegeben
werden muessen. Einige Front-Ends ermoeglichen eine sehr viel
komfortablere Generierung, aber sinngemaess sollten sich alle Schritte
auch dann nachvollziehen lassen. Zu der Installation eines Front-Ends
ist bereits eine Anleitung in der EDV-INFO von Nils Lohse erschienen.

Im PGP Verzeichnis mache ich mir Sicherungskopien von meinen
bisherigen Schluesselringen (den Testkeys) und verschiebe diese in ein
anderes Verzeichnis. Bei frischer Installation ist das natuerlich
nicht notwendig.

Um nun einen eigenes Schluesselpaar (oeffentlicher/geheimer) zu
erzeugen, "pgp -kg" eingeben. PGP zeigt in der vierten Zeile die
aktuelle Zeit (Achtung das ist UTC oder auch GMT, was das gleiche ist.
Das sollte in Mitteleuropa (kompletter deutschsprachiger Raum) im
Winter eine Stunde und wenn die Sommerzeit gilt, zwei Stunden frueher
sein als die Uhr an der Wand anzeigt (z.B. 10.00 Uhr UTC entspricht
11.00 MEZ bzw. 12.00 Uhr MESZ). Das nur mal als letzte Kontrolle. Was
PGP jetzt braucht, ist die gewuenschte Schluessellaenge. Bei mir habe
ich jetzt erst einmal 3 (fuer 1024bit) und bei einem spaeteren
Durchlauf dann 2048 direkt angegeben fuer den grossen Schluessel.

Nun verlangt PGP nach der user ID. Die sollte wie folgt aufgebaut
werden: Name dabei keine Umlaute verwenden !! (z.B.
Willy Mueller ). Wer mehrere Emailadressen
verwendet, kann spaeter problemlos weitere Ins fuer den gleichen
Schluessel hinzufuegen.

Das nun verlangte Mantra (Pass Phrase) ist sehr wichtig. PGP bietet
die Moeglichkeit, nicht nur ein Passwort sondern einen ganzen Passsatz
zu verwenden. Davon sollte tunlichst Gebrauch gemacht werden. Sollte
irgendwer doch einmal in den Besitz des geheimen Schluessels kommen,
so schuetzt nur noch dieses Mantra vor dem Missbrauch.

Dieses Mantra muss man sich natuerlich auch gut merken koennen, da man
selbst ohne Mantra auch nicht mehr an den Schluessel rankommt. (Dann
nuetzen einem auch die noch so sorgfaeltig erstellten Sicherungskopien
nix mehr). Also bitte etwas nachdenken und einen Satz auswaehlen, der
moeglichst aus Buchstaben und Zahlen und Zeichen besteht (Achtung
Gross-/Kleinschreibung beachten!). Dieses Mantra natuerlich nicht auf
den Disketten vermerken!! Man schreibt ja auch seine Geheimzahl nicht
auf die EC-Karte.

Das Mantra kann spaeter jederzeit wieder geaendert werden, ohne neue
Schluessel erzeugen zu muessen. Dazu einfach "pgp -ke eigene_userID"
eintippen. Die Frage, ob man eine neue UserID erzeugen will, verneinen
und dann darf man auch schon sein Mantra aendern.

Nach dem Mantra braucht PGP Zufallszahlen, die es aus willkuerlichen
Tastendruecken des Users generiert. Je nach Schluessellaenge muss man
halt mehr oder weniger lange auf der Tastatur rumtippen. Dabei bringt
es aber nix, wenn man nur eine Taste gedrueckt haelt. Das waere dann
nur ein Ergebnis, was von der Tastatur abhaengt, was im UEbrigen bei
PGP 2.6.3i auch nicht mehr akzeptiert wird.

Also nur schoen tippen, es ist ja nur einmalig notwendig, wenn ein
Schluessel erzeugt werden soll.

Nun arbeitet PGP etwas und sollte dann melden, dass alles OK ist. Nur
mal zur Orientierung:
512bit = 5 sec
768bit = 10 sec
1024bit = 23 sec
2048bit = 120 sec
(alle Zeiten unter DOS 7.0 auf einem Pentium 166)
2048bit = 210 sec (auf Am486DX4/100)
Gerade bei einem laengeren Schluessel ist deshalb etwas Wartezeit
einzuplanen.

Das gleiche macht man nun nochmals fuer den zweiten Schluessel (2048),
wenn man dem 1024 Bit Schluessel nicht ganz vertrauen will.

Alle Benutzer von PGP 2.6.3i koennen den nun folgenden Abschnitt
ueberspringen, da diese Version automatisch jeden Schluessel signiert.
Fuer alle anderen ist es jedoch wichtig, dass die Schluessel selbst
signiert werden. Jeder Fremde kann mit Hilfe eines Hex-Editors weitere
UserIDs zu einem bestehenden Schluessel hinzufuegen, was sehr
unangenehm werden kann, aber keiner ausser dem Besitzer kann die
hinzugefuegten UserIDs auch signieren. Deshalb trauen viele Leute nur
Schluesseln, die auch vom Besitzer selbst signiert sind.

Das Signieren ist recht einfach:
Man tippt "pgp -ks your_userID" ein. Dabei muss man die eigene_userID
evtl. durch die eindeutige Key-ID in der Form "0x1234567890" (diesmal
MIT den Anfuehrungszeichen und das 0x vor den Zahlen nicht vergessen)
eingeben, wenn mehr als ein Schluessel mit der gleichen user-ID
existiert.

Nun kommt noch eine sehr wichtige Sache. Fuer den Fall, dass man das
Mantra vergessen sollte, wird in der FAQ dringend empfohlen, schon bei
der Generierung des Schluessels ein sogenanntes revocation-certificate
zu erzeugen. Dieses kann dann bei Bedarf auf die Keyserver geladen
werden. Ohne Mantra kann kein revocation-certificate generiert werden,
da der Secret Key dazu benoetigt wird und dieser ohne Mantra wertlos
ist. Also erzeugt man das revokation-certificate schon jetzt und
lagert es zusammen mit den Sicherheitskopien an einem sicheren Platz.
Weitere Details zu dem revokation-certificate findet man in der schon
mehrfach zitierten FAQ [1], die es auch in einer deutschen
UEbersetzung gibt.

Das wird wie folgt gemacht:
1. Sicherheitskopien vom oeffentlichen und geheimen Schluesselbund
machen (pubring.pgp und secring.pgp). 2. den eigenen Schluessel
widerrufen (revoken) mit "pgp -kd eigene_userID" 3. den widerrufenen
Schluessel extrahieren mit "pgp -kxa eigene_userID" 4. diese dabei
erzeugte Datei auf einer Diskette an einem sicheren Ort lagern. 5. die
Sicherungskopien der Schluesselringe zurueckkopieren


Nun koennen die folgenden Files auf die Disketten kopiert werden: -
pubring.pgp - secring.pgp - die beiden revokation-certificates, die in
zwei Dateien gespeichert sind. Diese Sicherungskopien sollte man an
sicheren Orten aufbewahren (z.B. in der Schreibtischschublade, zu
Hause, im Bankschliessfach), die nach Moeglichkeit auch raeumlich
getrennt sind (das Bankschliessfach wahrscheinlich unberuehrt von
einem Wohnungsbrand bleiben, die Kopie in der Schreibtischschublade
hingegen wird wohl zusammen mit der Arbeitskopie auf der Festplatte
zerstoert werden). Weitere und viel detailliertere UEberlegungen zur
Sicherheit und den moeglichen Angriffspunkten, die ein solches System
bietet finden sich in der Dokumentation von PGP, die auf diese Punkte
sehr detailliert eingeht. Sie sollte sich im Verzeichnis "doc" bei PGP
finden.

Um den Schluessel weiterzugeben, muss er extrahiert werden aus dem
Schluesselbund. Dazu dient der Befehl: "pgp -kxa eigene_userID
Dateiname" die damit erzeugte Datei kann problemlos in eine Email
eingefuegt oder auf Diskette kopiert weitergegeben werden. Wenn man
(wie hier beschrieben) mehrere oeffentliche Schluessel hat (den 1024
und den 2048 Bit) so kann man beide in ein File extrahieren, indem man
folgendes eingibt: pgp -kx eigene_userID1 extract pgp -kx
eigene_userID2 extract Nun sind beide oeffentlichen Schluessel in der
Datei EXTRACT.PGP mit pgp -a extract.pgp erzeugt man eine ASCII-Armor
Datei daraus, die problemlos zu verteilen ist. Wenn PGP bei der
zweiten Zeile warnt, dass bereits ein File "extract.asc" existiert, so
ist in der config.txt von Pegasus die Option "Armor = ON" aktiviert
(nicht default). Das kann man einfach dadurch beheben, dass mit einem
Texteditor diese Zeile auskommentiert wird (mit "#"). Danach
funktioniert dieser Trick. Wenn man das File extract.asc dann hat,
kann man die Option ja wieder einschalten.


Das war’s jetzt eigentlich schon. Die oeffentlichen Schluessel koennen
und muessen nun so weit wie moeglich verteilt werden. Seinen direkten
Freuden kann man die Schluessel bedenkenlos per Email zuschicken und
ausserdem sollte man diese zu einem Keyserver senden, damit jedermann
bei Bedarf diesen Schluessel nutzen kann. Die Keyserver gleichen sich
weltweit selbstaendig untereinander ab, so dass es ausreicht, die
Schluessel an einen zu senden. Um den deutschsprachigen Keyserver zu
erreichen, schickt man eine Mail an: pgp-public-keys@keys.de.pgp.net
mit dem Subject HELP DE. Als Antwort kommt die Bedienungsanleitung des
Servers auf Deutsch zurueck.

Als Abschlussbemerkung moechte ich darauf hinweisen, dass ein
Verschluesselungssystem nur dann wirklich sicher funktionieren kann,
wenn die Teilnehmer auch die Hintergruende etwas verstanden haben. Es
wuerde den Rahmen dieser Anleitung mehr als sprengen, wenn ich jedes
Detail erklaeren wuerde. Gedacht ist diese Anleitung vielmehr dazu,
moeglichst schnell ein funktionierendes Verschluesselungssystem
aufzubauen. Wenn man diese Anleitung stur Schritt fuer Schritt
durchfuehrt, auch und gerade wenn man den Sinn nicht direkt versteht,
so sollte am Ende ein Schluesselsystem vorhanden sein, welches allen
Anforderungen an persoenlicher Sicherheit genuegen sollte. Punkte, die
zu Anfang noch nicht ganz verstaendlich sind, werden sicherlich nach
dem Lesen der FAQ und auch der Dokumentation (zumindest den Teil
"essential topics") etwas klarer. Sinnlose oder gefaehrliche Aktionen
sollten in dieser Anleitung nicht auftauchen. Meiner Erfahrung nach
ist PGP bestens dafuer geeignet, einen sehr hohen Standart an
Sicherheit zu bieten. Die groesste Gefahr geht wohl vom Benutzer aus,
der die Systematik der Public Key Verschluesselung und von PGP nicht
verstanden hat und durch Unvorsichtigkeit oder Unkenntnis die
einfachsten Angriffspunkte bietet.


Literaturverweise:

[1] "The comp.security.pgp FAQ" zu finden monatlich in allen Newgroups
der Gruppe: comp.security.pgp, oder als Textversion im Stueck unter
http://www.pgp.net/pgpnet/pgp-faq/pgpfaq.txt (117 kB) oder als
Hypertext Version (fuer Off-Line Reading) unter
http://www.pgp.net/pgpnet/pgp-faq/faq.html (auch 117 kB) oder in der
deutschen UEbersetzung unter:
http://ourworld.compuserve.com/homepages/zerberus/pgp/index.htm
(weitere Quellen finden sich in der FAQ).

[2] c’t Krpyto-Kampagne, http://www.heise.de/ct/pgpCA

[3] Die Homepage von der internationalen Version von PGP
http://www.pgpi.com Dort finden sich auch Literatur und Dokumente in
verschiedenen Sprachen (auch Deutsch)

[4] Die Homepage von Phil Zimmermanns Firma PGP Inc.,
http://www.pgp.com Dort sind zumeist Informationen fuer den
amerikanischen Kundenkreis zu finden.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBNEcwhtsAHljJlQYhAQHx2gf/dVAbJvw2NfAo+EPUoapZWPnoRU1yfsXL
HQsGk4QOrKAiNzinzrZ7sI//ksDzk1wfeMJUFmgfOSSMm2lFCMwtB4jdw4QnaSVI
enP+NXOJn6jxnePqjKhPjhYxeoabKzcovnZp+nfeW2CSHPMp7SCOoYlaxFNHmEXX
EGlO7uzUusIBEMBW3X4pwym0Xv1hHaSJ9pZ9kbnhViP4kCJGsiSuHmUC8hY7iTXS
bZj+ehVGTLObGPNnbH6PM7MSGqpe49Kw0OPCEk3qlzswNAMalr0yI3LxRnunZK43
a4uaJktNPw2LxobGMoiO3YqS9ZbcYQqj7o9hw92RZtqUNYQ1ABOV7w==
=qjxO
-----END PGP SIGNATURE-----

Yorck Schneider-Kuehnle, 1997, Fr. 17.10.1997 18:35, aktualisiert Di. 08.08.2017 11:16

Kontakt | Impressum | Datenschutz | © 2002-2023 NFL / Opetus Software GmbH
PMail32.de/Mercury32.de © 2002-2022 NFL/NLD/OSG | Pegasus Mail und Mercury © David Harris

Stichwörter für diese Seite: Pegasus Mail, E-Mail-Programm für DOS und Windows, kostenloser E-Mail-Client, Mercury MTS, Mail-Transport-System für Windows und Netware, Autor David Harris, deutschsprachige Informationen, E-Mail, Alternative zu Outlook Express, sicheres E-Mailen, kostenfreie und leistungsstarke Lösung für E-Mail, Informationen zur Software mit Download-Hinweis.

Die Benutzung von Informationen und Hinweisen aus Artikeln, Meldungen u.a. dieser Website erfolgt auf eigene Gefahr! Die Autoren haften nicht für irgendwelche Schäden, die durch die Nutzung dieser Informationen, ob direkt oder indirekt, resultieren.

pmail32.de · mercury32.de · key2it.de · edv-nachrichten.de