03.08.2013 Aufrufe

Sicherheit in Rechnernetzen - Professur Datenschutz und ...

Sicherheit in Rechnernetzen - Professur Datenschutz und ...

Sicherheit in Rechnernetzen - Professur Datenschutz und ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

3 Kryptografische Gr<strong>und</strong>lagen<br />

Daneben gibt es z. B. Pseudozufallsbitfolgengeneratoren (§3.4) <strong>und</strong> kollisionsresistente<br />

Hashfunktionen (§3.6.4 <strong>und</strong> §3.8.3) [Damg_88] <strong>und</strong> vieles andere.<br />

2. Der nötigen Schlüsselverteilung.<br />

Diese Unterscheidung bezieht sich vor allem auf solche kryptographischen Systeme, bei<br />

denen es zwei Sorten von Parteien gibt, Sender <strong>und</strong> Empfänger (wie eben Konzelations<strong>und</strong><br />

Authentikationssysteme). Hier unterscheidet man symmetrische <strong>und</strong> asymmetrische<br />

Systeme, je nachdem, ob beide Parteien den gleichen oder verschiedene Schlüssel haben,<br />

siehe unten.<br />

3. Dem <strong>Sicherheit</strong>sgrad.<br />

Die Hauptunterscheidung hier ist <strong>in</strong> <strong>in</strong>formationstheoretische <strong>und</strong> kryptographische<br />

<strong>Sicherheit</strong>. Erstere ist absolut (soweit man nur das kryptographische System betrachtet,<br />

also z. B. nicht Schlüsseldiebstahl). Letztere ist schwächer, kann aber noch s<strong>in</strong>nvoll weiter<br />

unterteilt werden, siehe unten.<br />

Zwei E<strong>in</strong>schränkungen von Konzelationssystemen seien gleich zu Beg<strong>in</strong>n erwähnt:<br />

• Sie schützen nur die Vertraulichkeit der Nachrichten<strong>in</strong>halte, nicht aber Kommunikationsumstände,<br />

beispielsweise wer von wo wann mit wem kommuniziert. Sollen auch die Kommunikationsumstände<br />

geschützt werden, s<strong>in</strong>d zusätzliche Schutzmaßnahmen nötig, vgl.<br />

§5.<br />

• Oftmals werden auch die Nachrichten<strong>in</strong>halte nicht vollständig geschützt, sondern manche<br />

Attribute des Nachrichten<strong>in</strong>halts, beispielsweise se<strong>in</strong>e Länge, schlicht ignoriert 3 . Besonders<br />

deutlich wird dies beim Beweis der perfekten <strong>Sicherheit</strong> der Vernam-Chiffre, vgl.<br />

Aufgabe 3-10b).<br />

Was mag diese weit verbreiteten, von den meisten Fachleuten überhaupt nicht bemerkten Fehler<br />

(oder beschönigend: Ungenauigkeiten) verursacht haben? Vielleicht folgendes Vorgehen:<br />

54<br />

Auf der höchsten Entwurfsebene, der Anforderungsdef<strong>in</strong>ition, wurde festgelegt:<br />

Nachrichten (auf dieser Ebene atomare Objekte) sollen vertraulich bleiben. Später<br />

wird auf niedrigeren Ebenen der atomare Typ Nachricht verfe<strong>in</strong>ert, <strong>in</strong>dem über<br />

die Repräsentation von Nachrichten entschieden <strong>und</strong> dabei beispielsweise implizit<br />

die Länge von Nachrichten e<strong>in</strong>geführt wird. Schließlich wird die Anforderung<br />

„Vertraulichkeit von Nachrichten“ auf der tieferen Ebene nur auf das entsprechende<br />

Hauptattribut bezogen, implizit e<strong>in</strong>geführte Nebenattribute wie z. B. „Länge“ geraten<br />

entweder überhaupt nicht <strong>in</strong>s Blickfeld oder werden für nicht wichtig erachtet.<br />

3 Wenn manche Attribute des Nachrichten<strong>in</strong>halts ignoriert werden, muß darauf geachtet werden, daß sie über den<br />

gesamten Nachrichten<strong>in</strong>halt nicht „zu viel“ verraten. E<strong>in</strong> drastisches Beispiel wäre, wenn Nachrichten<strong>in</strong>halte unär<br />

codiert werden <strong>und</strong> das Attribut Nachrichtenlänge nicht geschützt wird. Dann verrät die Nachrichtenlänge alles<br />

über den Nachrichten<strong>in</strong>halt, so daß Verschlüsselung etwa mit der Vernam-Chiffre überhaupt nichts nützt. (Unäre<br />

Codierung bedeutet: Es gibt nur e<strong>in</strong> Codezeichen - beispielsweise würde 17 also durch 17-faches H<strong>in</strong>tere<strong>in</strong>anderschreiben<br />

dieses Codezeichens dargestellt.)

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!