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.

402<br />

A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; Lösungen, TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />

401<br />

A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; Lösungen, TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />

Aus der Prüfziffer <strong>und</strong> ihrer ebenfalls abgefangenen Verschlüsselung mit der Vernam-<br />

Chiffre kann jeder durch Differenzbildung den aktuellen Schlüsselabschnitt bestimmen.<br />

Zu jeder (vom Angreifer frei wählbaren) Nachricht kann mittels des öffentlich bekannten<br />

Verfahrens die Prüfziffer berechnet werden <strong>und</strong> diese dann mittels des aktuellen Schlüsselabschnitts<br />

zu e<strong>in</strong>em „authentischen“ MAC verschlüsselt werden.<br />

Erreicht wird durch diesen passiven Angriff e<strong>in</strong> selektives Brechen, was wie schon <strong>in</strong><br />

§3.1.3.1 angemerkt, nicht akzeptabel ist.<br />

b) Für die üblichen kollisionsresistenten Hashfunktionen ist dies nach heutigem Wissen e<strong>in</strong>e<br />

sichere Konstruktion. Allerd<strong>in</strong>gs s<strong>in</strong>d diese nicht nur kollisionsresistent, sondern sie haben<br />

noch e<strong>in</strong>e darüber h<strong>in</strong>ausgehende, für die <strong>Sicherheit</strong> der bei TLS verwendeten Konstruktion<br />

wesentliche Eigenschaft:<br />

Ihr Funktionswert verrät nichts über die E<strong>in</strong>gabe.<br />

Um zu verdeutlichen, warum dies wesentlich ist, nehmen wir das Gegenteil an: Die kollisionsresistente<br />

Hashfunktion gäbe 80 Bit ihrer E<strong>in</strong>gabe als Teil ihres Funktionswertes aus. S<strong>in</strong>d<br />

sowohl die Funktionswerte lang genug als auch die E<strong>in</strong>gaben, so kann solch e<strong>in</strong>e Hashfunktion<br />

prima kollisionsresistent se<strong>in</strong>. Bei der bei TLS verwendeten Konstruktion e<strong>in</strong>gesetzt<br />

verkürzt sie allerd<strong>in</strong>gs die Schlüssellänge um 80 Bit, wenn der Schlüssel „dummerweise“ an<br />

der passenden Stelle der E<strong>in</strong>gabe steht. Wird mit e<strong>in</strong>er Schlüssellänge von 128 Bit gearbeitet,<br />

was normalerweise mehr als ausreichend ist, dann muß e<strong>in</strong> Angreifer höchstens 248 mal<br />

probieren, um den Schlüssel zu bestimmen. Dazu ist heute nahezu jeder relevante Angreifer <strong>in</strong><br />

der Lage.<br />

c) Ja: Hashe (, , ) <strong>und</strong> übertrage die Funktionswerte<br />

(ggf. zusammen mit , falls der Empfänger nicht mitzählt oder das<br />

Kommunikationsmedium unzuverlässig ist). Der Empfänger muß nun nur noch die Werte des<br />

Byte durchprobieren, <strong>in</strong>dem er (, , ) hasht<br />

<strong>und</strong> mit dem übermittelten Funktionswert vergleicht, um den Funktionswert zum Klartextbyte<br />

zu entschlüsseln. Außer Sender <strong>und</strong> Empfänger kann dies niemand, da niemand sonst den<br />

Schlüssel kennt. Die Numerierung der Bytes verh<strong>in</strong>dert, daß gleiche Bytes gleiche Funktionswerte<br />

ergeben, es wird so e<strong>in</strong>e synchrone Stromchiffre erzeugt, vgl. §3.8.2. Im Beispiel wird<br />

angenommen, daß e<strong>in</strong> Byte e<strong>in</strong>en s<strong>in</strong>nvollen Kompromiß zwischen der Anzahl der Versuche<br />

bei der Entschlüsselung durch den Empfänger <strong>und</strong> der Nachrichtenexpansion durch die<br />

wesentlich längeren Funktionswerte der Hashfunktion (typischerweise 160 Bit) <strong>und</strong> Nummer<br />

des Bytes (typischerweise 64 Bit) ist. Es ist klar, daß statt Bytes vom Bit bis (bei heutiger<br />

Technologie etwa) zum Langwort von 4 Bytes alles genommen werden kann.<br />

i) Das e<strong>in</strong>e ausgetauschte Speichermedium werde für Zweiwegkommunikation genutzt, so daß<br />

für jede Richtung nur die Hälfte der Speicherkapazität genutzt werden kann. Dann ergibt sich<br />

Hochauflösende Bewegtbildkommunikation<br />

(140 Mbit/s)<br />

Sprachkommunikation<br />

(normale ISDN-<br />

Codierung: 64 kbit/s)<br />

Textkommunikation<br />

(Tippgeschw<strong>in</strong>digkeit<br />

40 bit/s)<br />

1,62 Tage 87,5 s 0,04 s<br />

694 Tage 10,4 h 17 s<br />

5787 Tage 3,6 Tage 143 s<br />

139 Tage 2,1 h 3,4 s<br />

3009 Tage 1,9 Tage 74 s<br />

19676 Tage 12,3 Tage 486 s<br />

3,5"-Diskette<br />

(1,4 MByte)<br />

optische 5,25"-Platte<br />

(600 MByte)<br />

Video-8-Streamertape<br />

(5 GByte)<br />

3,5"-Diskette (120<br />

MByte)<br />

DVD-RAM e<strong>in</strong>seitig<br />

(2,6 GByte)<br />

Dual-Layer-DVD<br />

beidseitig (17 GByte)<br />

Austausch e<strong>in</strong>er 1,4 MByte Diskette reicht also für Textkommunikation für die meisten Anwendungen<br />

bereits „auf Lebenszeit“ (denn nur wenige werden Ihnen so am Herzen liegen, daß<br />

Sie <strong>in</strong>sgesamt 1,62 Tage nonstop für sie tippen), entsprechend reicht Austausch e<strong>in</strong>er optischen<br />

600 MByte Platte für viele Sprachkommunikations-Anwendungen (auch wenn viele<br />

Menschen ausdauernder reden als tippen). Für unkomprimierte hochauflösende Bewegtbildkommunikation<br />

s<strong>in</strong>d die heutigen Massenspeicher noch zu kle<strong>in</strong>, aber für komprimierte<br />

Bewegtbildkommunikation niedriger Auflösung wie im ISDN vorgesehen (e<strong>in</strong> zusätzlicher<br />

Kanal von 64 kbit/s für das Bild) durchaus brauchbar: Mit Hilfe e<strong>in</strong>es Video-8-Streamertapes<br />

1,8 Tage <strong>in</strong>formationstheoretisch sicher se<strong>in</strong>e(n) TelefonpartnerIn zu sprechen <strong>und</strong> zu betrachten,<br />

dürfte auch hier „auf Lebenszeit“ reichen. Für flüchtige Bekanntschaften tut's neuerd<strong>in</strong>gs<br />

e<strong>in</strong>e 120 MByte Diskette – <strong>und</strong> für <strong>in</strong>tensive Telebeziehungen künftig e<strong>in</strong>e Dual-Layer-DVD.<br />

3-8 Authentikationscodes<br />

a) Ausgetauscht sei der Schlüssel 00 11 10 01. Zu sichern sei der Klartext H T T T.<br />

Beim Authentikationscode wird dann H,0 T,1 T,0 T,1 als „Schlüsseltext“ generiert <strong>und</strong><br />

übertragen.<br />

b) Fängt e<strong>in</strong> Angreifer e<strong>in</strong>e Komb<strong>in</strong>ation aus H oder T sowie MAC ab, so bleiben für ihn immer<br />

zwei (der vier) Schlüsselwerte ununterscheidbar, da H bzw. T <strong>in</strong> jeder Spalte der Tabelle, <strong>in</strong><br />

der sie vorkommen, genau zweimal vorkommen. Genau diese zwei Werte unterscheiden sich<br />

aber dar<strong>in</strong>, ob für den anderen Wert des „Münzwurfs“ der MAC den Wert 0 oder 1 haben<br />

muß. (Behauptung kann <strong>in</strong> dem e<strong>in</strong>fachen Authentikationscode leicht durch vollständige<br />

Betrachtung aller Möglichkeiten verifiziert werden.) Deshalb hat der Angreifer ke<strong>in</strong>e bessere<br />

Strategie als Raten, was mit der Wahrsche<strong>in</strong>lichkeit 0,5 dazu führt, daß der Empfänger die<br />

Verfälschung des Angreifers erkennt.<br />

E<strong>in</strong>fachere Darstellung: Wenn k = k1k2, so ist k(H) = k1 <strong>und</strong> k(T) = k2. (Dies ist im folgenden,<br />

der Aufgabenstellung entnommenen Bild veranschaulicht, <strong>in</strong> dem k1 fett gezeichnet<br />

E<strong>in</strong>e ganz andere Frage ist, ob der Lesezugriff auf die Medien schnell genug geht, um <strong>in</strong> Realzeit<br />

auf den Schlüssel zugreifen zu können. Für Text- <strong>und</strong> Sprachkommunikation ke<strong>in</strong> Problem.<br />

Für hochauflösende Bewegtbildkommunikation mit 140 Mbit/s für alle Medien bisher<br />

nicht möglich – e<strong>in</strong> weiterer Gr<strong>und</strong>, weshalb Bewegtbildsignale nicht nur verlustfrei, sondern<br />

sogar verlustbehaftet komprimiert werden. Ersteres br<strong>in</strong>gt etwa den Faktor 4, bei letzterem<br />

kommt es darauf an, welche Qualitätse<strong>in</strong>buße man gewillt ist, <strong>in</strong> Kauf zu nehmen. Wenn Sie<br />

Ihren Taschenrechner noch ausgepackt haben, dann können Sie die Zahlen für hochauflösende<br />

Bewegtbildkommunikation noch mal mit den typischen Werten von 34 Mbit/s für verlustfreie<br />

<strong>und</strong> 2 Mbit/s für verlustbehaftete Kompression durchrechnen. Was ergibt sich? Video-8-Streamertape<br />

<strong>und</strong> DVD s<strong>in</strong>d für hochauflösende Bewegtbildkommunikation bei verlustbehafteter<br />

Kompression durchaus geeignet – sowohl für die Speicherung des One-Time Pads wie auch<br />

für die Speicherung des Bewegtbildsignals. Ke<strong>in</strong> W<strong>und</strong>er: Schlüssel, Schlüsseltext <strong>und</strong> Klartext<br />

s<strong>in</strong>d gleich lang – <strong>und</strong> für letzteres wurden die Medien konzipiert.<br />

3-7a Symmetrisch konzelierter Message Digest = MAC ?<br />

a) Das Rezept ist vollkommen unsicher, wie das <strong>in</strong> der Aufgabenstellung genannte Beispiel zeigt:<br />

Aus der abgefangenen Nachricht kann jeder mittels des öffentlich bekannten Verfahrens die<br />

Prüfziffer berechnen.

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!