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

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

B.5 Lösungen zu <strong>Sicherheit</strong> <strong>in</strong> Kommunikationsnetzen<br />

Fehlern wird normalerweise nicht vergeblich entschlüsselt. Zusätzlich wird selbst dann Aufwand<br />

gespart, wenn gar ke<strong>in</strong>e Fehler auftreten: Jede fehlertolerante Codierung muß Red<strong>und</strong>anz<br />

h<strong>in</strong>zufügen <strong>und</strong> damit die Nachricht verlängern. Bei erst fehlertolerant Codieren <strong>und</strong> dann Verschlüsseln<br />

müßte das aufwendige Ver- <strong>und</strong> Entschlüsseln mit der verlängerten Nachricht erfolgen.<br />

Last but not least kann das Verschlüsseln red<strong>und</strong>anter Nachrichten die <strong>Sicherheit</strong> e<strong>in</strong>es nur<br />

komplexitätstheoretisch sicheren Konzelationssystems entscheidend schwächen. Denn genau<br />

die Red<strong>und</strong>anz hilft e<strong>in</strong>em Angreifer ja zu erkennen, wenn e<strong>in</strong> Entschlüsselungsversuch erfolgreich<br />

war.<br />

Aufgabe auf Seite 454.<br />

5-4 Behandlung von Adreß- <strong>und</strong> Fehlererkennungsfeldern bei Verschlüsselung<br />

a) Die Adresse bleibt bei Ende-zu-Ende-Verschlüsselung im Klartext erhalten. Als verschlüsselte<br />

Nutznachricht ergibt sich<br />

Klartext-Nutznachricht 00110110<br />

⊕ verwendetes One-time-pad 01100111<br />

verschlüsselte Nutznachricht 01010001<br />

Als Prüfzeichen ergibt sich 01 + 11 + 01 + 01 + 00 + 01 = 11. Also lautet die Ende-zu-<br />

Ende-verschlüsselte Nachricht 0111 01010001 11.<br />

Anmerkungen:<br />

Das Prüfzeichen darf man natürlich nicht von der Adresse <strong>und</strong> Klartext-Nutznachricht bilden:<br />

Erstens würde dies e<strong>in</strong>em Angreifer manche Information über die Klartext-Nutznachricht<br />

verraten, da das Prüfzeichen im Klartext übertragen wird <strong>und</strong> der Algorithmus zu se<strong>in</strong>er<br />

Bildung öffentlich bekannt ist. Zweitens würde die Bildung des Prüfzeichens von der<br />

Adresse <strong>und</strong> Klartext-Nutznachricht die Fehlererkennung im Kommunikationsnetz genauso<br />

unmöglich machen wie dies das Mitverschlüsseln des Prüfzeichens täte.<br />

Braucht man ke<strong>in</strong>e Fehlererkennung im Kommunikationsnetz, sondern nur Ende-zu-Ende,<br />

dann kann das Prüfzeichen mitverschlüsselt werden, so dass die obigen Probleme wegfallen.<br />

Ist man dazu bereit, was One-time-pad-Verschlüsselung natürlich etwas von der<br />

knappen Ressource Schlüssel kostet, dann sollte man eigentlich noch e<strong>in</strong>en Schritt weiter<br />

gehen <strong>und</strong> e<strong>in</strong>en Authentikationscode verwenden, so dass nicht nur dumme Fehler,<br />

sondern auch <strong>in</strong>telligente Angreifer Nachrichten nur mit sehr ger<strong>in</strong>ger Wahrsche<strong>in</strong>lichkeit<br />

unentdeckt verfälschen oder unterschlagen können.<br />

Hätte man gerne Fehlererkennung im Kommunikationsnetz <strong>und</strong> Ende-zu-Ende-Authentikation,<br />

muss im gegebenen Nachrichtenformat die Authentikation als Teil der Nutznachricht<br />

erfolgen. Das Prüfzeichen wird dann wie zu Beg<strong>in</strong>n beschrieben von der Adresse <strong>und</strong><br />

der sowohl verschlüsselten als auch authentifizierten Nutznachricht gebildet. Natürlich<br />

kann man jetzt auch zwei Felder für Prüfzeichen e<strong>in</strong>führen, diskutieren, ob die Authentikation<br />

die Adresse mit e<strong>in</strong>schließen soll, ob es gar zwei, möglicherweise unterschiedliche<br />

Adressen gibt, etc. Wir sehen also, dass beim E<strong>in</strong>satz von Verschlüsselung <strong>in</strong> Kommunikationsnetzen<br />

mit mehreren Protokollschichten viele Möglichkeiten bestehen, von denen<br />

längst nicht alle s<strong>in</strong>nvoll s<strong>in</strong>d.<br />

559

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!