/usr/share/doc/gnupg-doc/mini-HOWTO/de/GPGMiniHowto-1.html is in gnupg-doc 2003.04.06+dak1-1ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.69">
<TITLE>GNU Privacy Guard (GnuPG) Mini Howto : Konzepte</TITLE>
<LINK HREF="GPGMiniHowto-2.html" REL=next>
<LINK HREF="GPGMiniHowto.html#toc1" REL=contents>
</HEAD>
<BODY>
<A HREF="GPGMiniHowto-2.html">Weiter</A>
Zurück
<A HREF="GPGMiniHowto.html#toc1">Inhalt</A>
<HR>
<H2><A NAME="GPG-Minihowto-Konzepte"></A> <A NAME="s1">1.</A> <A HREF="GPGMiniHowto.html#toc1">Konzepte</A></H2>
<H2><A NAME="ss1.1">1.1</A> <A HREF="GPGMiniHowto.html#toc1.1">Public Key Verschlüsselung</A>
</H2>
<P>Klassische Methoden zur Verschlüsselung benutzen nur einen
Schlüssel. Der Sender verschlüsselt seine Nachricht mit diesem
Schlüssel, und der Empfänger entschlüsselt ihn mit demselben
wieder. Damit das funktioniert, muß der Empfänger vorher den Schlüssel
bekommen haben, und zwar auf einem sicheren Kommunikationskanal, da
sonst Unbefugte in Kenntnis des Schlüssels gelangen könnten. Also
braucht man einen sicheren Kommunikationskanal, aber wenn man den hat,
braucht man auch nicht mehr zu verschlüsseln.</P>
<P>Public Key Verfahren (auch: asymmetrischen Verfahren) beseitigen
dieses Problem, indem zwei Schlüssel erzeugt werden: Der
öffentliche, der über beliebige Kommunikationskanäle
verschickt werden kann und der private, den nur der Besitzer
kennt. Idealerweise ist der private Schlüssel nicht mit dem
öffentlichen rekonstruierbar. Der Sender verschlüsselt die
Nachricht mit dem öffentlichen Schlüssel des
Empfängers. Entschlüsselt wird die Nachricht dann mit dem
privaten Schlüssel des Empfängers. Nach diesem Schema kann
man demnach effektiv verschlüsseln, ohne über einen sicheren
Kommunikationskanal zu verfügen. </P>
<P>Ein ganz wichtiger Punkt ist aber die Geheimhaltung des privaten
Schlüssels. Er darf auf keinen Fall in fremde Hände geraten,
auch nicht über das Netz verbreitet werden. GnuPG via
<CODE>telnet</CODE> zu benutzen, ist zum Beispiel eine ziemlich schlechte
Idee. (Eigentlich sollte man <CODE>telnet</CODE> sowieso durch
<CODE>ssh</CODE> ersetzen) </P>
<H2><A NAME="ss1.2">1.2</A> <A HREF="GPGMiniHowto.html#toc1.2">Digitale Unterschriften</A>
</H2>
<P>Digitale Unterschriften sollen die Authenzität einer Nachricht
beweisen. Würden Nachrichten von offizieller Seite signiert,
wäre es deutlich schwerer, mit gefälschten Nachrichten
Unruhe oder Schaden anzurichten (aktuelles Beispiel: Ein trojanische
Pferd, verschickt als Patch eines bekannten Webbrowsers).</P>
<P>Ein digitale Signatur wird mit Hilfe des privaten Schlüssels aus dem
Text erzeugt. Diese kann dann vom Empfänger mit dem öffentlichen
Schlüssel des Senders überprüft werden. Dabei wird nicht nur der
Absender (nur der kennt den privaten Schlüssel) überprüft, sondern
auch, ob der Text unverändert angekommen ist.</P>
<H2><A NAME="ss1.3">1.3</A> <A HREF="GPGMiniHowto.html#toc1.3">Web of trust</A>
</H2>
<P>Eine Schwachstelle der Public Key Algorithmen ist die Verbreitung der
öffentlichen Schlüssel. Ein Benutzer könnte einen
öffentlichen Schlüssel mit falscher User ID in Umlauf
bringen. Wenn dann mit diesem Schlüssel Nachrichten kodiert
werden, kann der Eindringling die Nachrichten dekodieren und
lesen. Wenn er sie dann noch mit einem echten öffentlichen
Schlüssel kodiert an den eigentlichen Empfänger
weiterleitet, fällt dieser Angriff nicht einmal auf.</P>
<P>Die von PGP (und damit auch von GnuPG) gewählte Lösung
besteht im Unterschreiben von Schlüsseln. Ein öffentlicher
Schlüssel kann von anderen Leuten unterschrieben werden. Diese
Unterschrift bestätigt, daß der Schlüssel zu der in
der UID angegebenen Person gehört. Der Benutzer kann festlegen,
welchen Unterschriften er wie weit traut. Vertrauen ist dabei zwar
reflexiv, aber nicht symmetrisch und transitiv. Ein Schlüssel
gilt als vertrauenswürdig, wenn er von Leuten unterzeichnet wurde,
denen man vertraut. Wenn man Schlüssel unterzeichnet, sollte man
sich sicher sein, daß man die Identität desjenigen, dessen
Schlüssel man unterschreibt, genau kennt. Eine Möglichkeit
ist es, den Schlüssel persönlich bekommen zu haben, eine
andere, den Fingerprint über zuverlässige Kanäle zu
vergleichen.</P>
<H2><A NAME="ss1.4">1.4</A> <A HREF="GPGMiniHowto.html#toc1.4">Grenzen der Sicherheit</A>
</H2>
<P>Wenn man Daten vertraulich halten will, sollte man sich nicht nur
Gedanken über die Sicherheit des Verschlüsselungsalgorithmus machen,
sondern über die Systemsicherheit allgemein. Die in GnuPG verwendeten
Algorithmen gelten gemeinhin als nicht zu knacken. Daraus zu
schließen, daß alle verschlüsselten Daten sicher seien, ist naiv. Es
gibt auch noch andere Formen von Angriffen. Anfang Februar 1999
tauchte zum Beispiel ein Word Trojaner auf, der private PGP
Schlüsselbunde auf der Festplatte suchte und via ftp verschickte
(Meldung im Heise Newsticker vom 03.02.99). Ein privates Schlüsselbund
läßt sich, insbesondere bei schlechtem Passwort, deutlich leichter
knacken als eine einzelne Datei.</P>
<P>Denkbar sind auch Trojaner, die Tastatureingaben weiterleiten. Falls
man die Nachrichten entschlüsselt auf dem Rechner lagert, können sie
natürlich auch gelesen werden. Aufwendiger, aber technisch möglich ist
es, die Abstrahlung des Monitors zu messen und sichtbar zu machen, so
daß der Bildschirminhalt mitgelesen werden kann. Dann nützt es auch
nichts, eine verschlüsselte Datei nur zum Lesen zu entschlüsseln. Zum
Thema "Überwachung" gibt es den interessanten Artikel
"Abhör-Dschungel" aus der c't 5/98, Seite 82 und "In
die Röhre geguckt" c't 24/98, Seite 90. </P>
<P>Die obigen Möglichkeiten sollen keine Paranoia hervorrufen, sondern
nur darauf hinweisen, daß Verschlüsselung von Daten nur ein Baustein
eines Sicherheitskonzeptes sein kann. Um so erstaunlicher, daß es
immer wieder Versuche gibt, Verschlüsselung von Daten zu be-
beziehungsweise zu verhindern. </P>
<HR>
<A HREF="GPGMiniHowto-2.html">Weiter</A>
Zurück
<A HREF="GPGMiniHowto.html#toc1">Inhalt</A>
</BODY>
</HTML>
|