Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Weitere Magazine

Empfehlungen

Info

52 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr 51 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr S zusammengehören. Die späteren Konzelationssysteme mit kurzen Schlüsseln werden alle in diesem Sinn nicht sicher sein; z.B. gibt es bei vielen asymmetrischen Konzelationssystemen zu jedem c nur genau ein mögliches d (vgl. Bild 3-4), und damit, weil der Angreifer c kennt, auch zu jedem Schlüsseltext S nur genau einen möglichen Klartext x. Dort muß man sich also voll und ganz darauf verlassen, daß x schwierig auszurechnen ist. Bezüglich der Berechnung ist die Vernam-Chiffre einfach und schnell, und sie verursacht auch keine Nachrichtenexpansion. Ihr einziger Nachteil ist die Länge des Schlüssels: Er ist genauso lang wie die Nachricht. Daher gilt die Vernam-Chiffre für viele Zwecke als unpraktikabel. (Mit Verbesserung der Speichermedien wird sie aber immer besser einsetzbar, jedenfalls in Fällen, wo die Teilnehmer vorweg z.B. Disketten austauschen können.) Anmerkung 3: Die übliche Definition informationstheoretisch sicherer Konzelation [Sha1_49] holt etwas weiter aus; unsere kann man dann als äquivalent beweisen. (Und in konkreten Beweisen verwenden auch andere Autoren meist die obige einfachere Formulierung (1).) Sie besagt: Egal, was der Angreifer a priori an Information über den Klartext hat, er gewinnt durch das Sehen des Schlüsseltextes keine Information hinzu. Die a-priori-Information wird durch eine Wahrscheinlichkeitsverteilung dargestellt, die die Klartexte aus seiner Sicht haben (z.B. bei Briefanfängen W(Liebe) = 0,4, W(Sehr ) = 0,4, W(xrq,q) = 0,0001). Auch die Schlüssel haben Wahrscheinlichkeiten und werden unabhängig vom Klartext gewählt. Damit haben auch die Schlüsseltexte Wahrscheinlichkeiten. Die aposteriori-Wahrscheinlichkeit eines Klartextes x, wenn der Angreifer den Schlüsseltext S gesehen hat, ist die bedingte Wahrscheinlichkeit von x, wenn man S kennt, W(x|S). Die Sicherheitsforderung ist also ∀S ∈ S ∀x ∈ X: W(x|S) = W(x). (2) Man kann leicht einsehen, daß für informationstheoretische Sicherheit die Schlüssel so lang sein müssen: Sei K die Schlüsselmenge, X die Klartextmenge und S die Menge der mindestens einmal auftretenden Schlüsseltexte. Zunächst muß |S | ≥ |X | gelten, denn bei festem Schlüssel müssen alle Klartexte verschieden verschlüsselt werden, damit man eindeutig entschlüsseln kann. Nun haben wir für die Sicherheit verlangt, daß für alle S und x ein k existiert mit k(x) = S. Bei festem x muß dies für jeden Schlüsseltext S ein anderer Schlüssel sein. Also gilt |K | ≥ |S |, und insgesamt |K | ≥ |X |. Es muß also mindestens so viele Schlüssel wie Klartexte geben. Sind die Klartexte geschickt codiert42 , so müssen also die Schlüssel genauso lang sein. Anmerkung 1: Mit den gerade eingeführten Bezeichnungen lautet die Definition für informationstheoretische Sicherheit für den Fall, daß alle Schlüssel mit gleicher Wahrscheinlichkeit gewählt werden, also kurz: ∀S ∈ S ∃ const ∈ IN ∀x ∈ X: |{k ∈ K | k(x) = S}| = const. (1) Dies bedeutet, daß für jemand, der den Schlüssel nicht kennt, Klartext x und Schlüsseltext S stochastisch unabhängig sind. Zur Äquivalenz der Definitionen (1) und (2): Nach der Bayesschen Formel ist W(x|S) = W(x)•W(S|x) . W(S) (2) ist also äquivalent zu 43 ∀S ∈ S ∀x ∈ X: W(S|x) = W(S). (3) Wir zeigen, daß dies äquivalent ist zu ∀S ∈ S ∃ const' ∈ IR ∀x ∈ X: W(S|x) = const'. (4) (3) ⇒ (4) ist klar mit const' := W(S). Umgekehrt zeigen wir const' = W(S): W(S) = ∑ W(x)•W(S|x) = ∑ W(x)•const' = const' • ∑ W(x) = const'. x x x (4) sieht (1) schon sehr ähnlich: Allgemein ist W(S|x) = W({k|k(x) = S}), und wenn alle Schlüssel gleichwahrscheinlich sind, W(S|x) = |{k|k(x) = S}| / |K |. Dann ist (4) äquivalent (1) mit const = const'•|K |. 3.3 Authentikationscodes Da es sich hier um eine zentrale Definition handelt, sei sie noch etwas problematisiert und dadurch erläutert: Da IN = {1, 2, 3, 4, ...}, gilt: const ≥ 1. Die Konstante const darf in obiger Definition vom konkreten Schlüsseltext S abhängen. Bei vielen informationstheoretisch sicheren Konzelationssystemen, etwa dem One-time pad, tut sie das nicht. Dort ist, wie bereits erwähnt, const = 1. Man mag deshalb versucht sein, die Reihenfolge der Quantoren in der Definition zu tauschen: ∃ const ∈ IN ∀S ∈ S ∀x ∈ X: |{k ∈ K | k(x) = S}| = const. Dadurch wird die Definition aber restriktiver, ohne daß ihr genügende Konzelationssysteme sicherer werden. Also bleibt man geschickterweise bei der schwächeren Definition. Aus den gleichen Gründen nimmt man auch nicht folgende noch stärker vereinfachte Definition: ∀S ∈ S ∀x ∈ X: |{k ∈ K | k(x) = S}| = 1. Nun seien auch noch – zugegeben eher exotische – Konzelationssysteme angegeben, die der allgemeinen Definition (1) genügen, den engeren aber nicht: Beispiel für const = 2: Wir erweitern den Schlüsselraum des One-time pads um ein Bit, das bei der Ver- und Entschlüsselung überhaupt nicht verwendet wird. Dann kann jedem Schlüsseltext jeder Klartext jeweils durch 2 Schlüssel zugeordnet werden, die sich genau im nicht verwendeten Bit unterscheiden. Beispiel für const abhängig von S: Wir verdoppeln die Schlüssellänge des One-time pads, verwenden aber jedes zweite Schlüsselbit bei der Ver- und Entschlüsselung überhaupt nicht. Dann kann jedem Schlüsseltext der Länge l Bit jeder Klartext jeweils durch 2l Schlüssel zugeordnet werden, die sich genau in den l nicht verwendeten Bits unterscheiden. Also ist const vom Schlüsseltext, genauer: seiner Länge, abhängig. Es gilt dann: const = 2l . Authentikationscodes sind informationstheoretisch sichere symmetrische Authentikationssysteme. Sie bestehen also aus den in Bild 3-6 gezeigten Komponenten. Bevor wir ein Beispiel geben (Bild 3-15), betrachten wir informell, was informationstheoretische, also absolute, Sicherheit in diesem Fall heißt. Sicherheit heißt, daß, wenn ein Angreifer eine Nachricht unterzuschieben versucht, der Empfänger anhand des (nicht passenden) MAC bemerkt, daß sie falsch ist. Dies kann nicht mit Wahrscheinlichkeit 1 gelten: Irgendeinen korrekten MAC muß es geben, und der Angreifer kann immer Glück haben und gerade diesen erraten. Genauer gilt, wenn der Wertebereich für die MACs W Elemente hat, daß man mit rein zufälligem Raten mit der Wahrscheinlichkeit Anmerkung 2: Das informationstheoretische, also absolute, an der Sicherheit ist, daß wir uns in keiner Weise darum gekümmert haben, ob etwas vielleicht schwierig auszurechnen ist: Wir haben den schlimmsten Fall angenommen, daß der Angreifer eine genaue Tabelle hätte, welche k, x und 43 Wir betrachten nur solche Schlüsseltexte S, die vorkommen können, so daß gilt: W(S) > 0. 42 Um einem Mißverständnis vorzubeugen: Hier hat „Codieren“ nichts mit Vertraulichkeit oder Authentikation zu tun, sondern es geht nur darum, daß mittels Bitketten der Länge l insgesamt 2l Werte unterschieden, das bedeutet 2l Klartexte geschickt codiert – oder anders ausgedrückt: repräsentiert –, werden können. Entsprechendes gilt auch für die Werte der Schlüssel, so daß die entsprechende Länge der Schlüssel(codierung) resultiert.
54 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr 53 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr 1. Fall: Der Angreifer fängt H,0 ab. Dann sind noch die Schlüssel k=00 und k=01 möglich. Bei k=00 muß der Angreifer 0 als MAC für T wählen, bei k=01 hingegen 1. Wieder rät also der Angreifer mit Wahrscheinlichkeit 1/2 falsch. 2. Fall: Der Angreifer fängt H,1 ab. Analog … (Weiter s. Aufgabe 3-8 b)). 1/W den richtigen MAC erwischt. (Insbesondere also bei σ-Bit-MACs mit Wahrscheinlichkeit mindestens 2 –σ .) Die beste erreichbare Sicherheit ist also die, daß es für einen Angreifer keine bessere Möglichkeit gibt, als rein zufällig zu raten. Genauere Sicherheitsdefinition: Eine präzisere Definition, wann ein Authentikationscode code sicher mit Fehlerwahrscheinlichkeit ε ist, beschreibt genau das, was wir im obigen Beispiel getan haben: „Selbst wenn ein Angreifer eine richtige Nachricht (x, MAC) sieht, und diese beseitigt und statt dessen versucht, den Klartext y zu schicken, gilt, egal wie geschickt er dazu MAC' wählt: Die Fälschung wird mit Wahrscheinlichkeit ≥ 1–ε erkannt, d.h. die Wahrscheinlichkeit für MAC' = code(k, y) ist höchstens ε (wobei k der korrekte geheime Schlüssel ist).“ Wir müssen nur noch präzis angeben, worüber eigentlich die Wahrscheinlichkeit gebildet wird. Dies ist genau die Menge der aus Angreifersicht noch möglichen Schlüssel. (Wie im Beispiel im 1. Fall die Menge aus 00 und 01.) Die Angreifersicht besagt, daß nur noch solche Schlüssel k in Frage kommen, für die MAC = code(k, x) ist. Anmerkung: Beachte aber, daß der Angreifer hier nicht lokal prüfen kann, ob er richtig geraten hat, d.h. es trifft nicht der Fall aus §3.1.3.4 1) zu. Hier werden wir beweisbar erreichen, daß ein Fälschungsversuch fast sicher erkannt wird. Im Gegensatz dazu könnte ein Angreifer mit beliebig viel Berechnungsfähigkeit bei einem digitalen Signatursystem im Sinne von Bild 3-7 lauter solche Signaturen erzeugen, die wirklich richtig aussehen, weil er ja den Test kennt, den sie bestehen müssen. (Vgl. aber §3.9.2 und §3.9.3.) Authentikationscodes haben also einen prinzipiellen Sicherheitsvorteil gegenüber digitalen Signaturen; dafür sind sie unpraktischer, s. §3.1.1.2. Ganz formal also: Ein Authentikationscode code mit Schlüsselmenge K (und Wahrscheinlichkeitsverteilung W auf K ) heißt sicher mit Fehlerwahrscheinlichkeit ε, wenn gilt: ∀ x ∀ MAC ∈ code(K , x) ∀ y ≠ x ∀ MAC': W(MAC' = code(k, y) | MAC = code(k, x)) ≤ ε. Beispiel 1: Bevor wir die Sicherheitsaussage formalisieren, betrachten wir Bild 3-15, das einen kleinen Authentikationscode darstellt (aus der Sicht des Angreifers). Hier soll 1 Nachrichtenbit ∈ {H, T} (von Head, Tail) authentisiert werden; der Schlüssel ist 2 Bit lang, und der MAC 1 Bit. Wie bei allen folgenden Systemen werden alle Schlüssel mit gleicher Wahrscheinlichkeit gewählt. Die möglichen Ergebnisse stehen oben; in der Tabelle sieht man, bei welchem Klartext sich dieses Ergebnis ergibt. (Man kann diesen Code übrigens sehr viel kürzer darstellen, s. Aufgabe 3-8 b).) Wie bei der Vernam-Chiffre wird jeder Schlüsselabschnitt (hier jeweils die beiden Bits) nur einmal verwendet. Beispiel 2 (Verbesserung des Codes aus Bild 3-15): Will man die Fehlerwahrscheinlichkeit des Codes aus Bild 3-15 von 1/2 auf 1/2σ senken, so kann man an ein Nachrichtenbit σ MACs im bisherigen Sinne hängen, etwa x, MAC1 , … , MACσ . Man muß also vorher 2σ Schlüsselbits ausgetauscht haben. Jeden Einzel-MAC rät der Angreifer nur mit Wahrscheinlichkeit 1/2 richtig, und sie sind alle unabhängig, folglich rät er nur mit Wahrscheinlichkeit (1/2) σ jedesmal richtig. Will man den Code auf Nachrichten der Länge l Bit anwenden, so braucht man l•2σ Schlüsselbits, und jedes Bit wird einzeln in obigem Sinne authentisiert. (Die Gesamtfehlerwahrscheinlichkeit ändert sich etwas!) Ein wesentlich effizienterer Code wird in Aufgabe 3-8 f) betrachtet. Text mit MAC H,0 H,1 T,0 T,1 – T – H 00 T – – H 01 – T H – 10 Schlüssel Ausblick: Grenzen von Authentikationscodes. Wie informationstheoretisch sichere Konzelationssysteme, so brauchen auch informationstheoretisch sichere Authentikationscodes Schlüssel einer gewissen Mindestlänge. Wir haben schon fast gezeigt, daß man für eine Fehlerwahrscheinlichkeit ε mindestens eine Schlüsselmenge mit ⎡1/ε⎤ Elementen braucht: Klar war, daß ⎡1/ε⎤ MACs für die zu fälschende Nachricht y möglich sein müssen. Zu jedem möglichen MAC muß aber auch ein möglicher Schlüssel gehören. Es ist auch einleuchtend, daß es noch mehr Schlüssel sein müssen, denn anhand der richtigen Nachricht (x, MAC) konnte der Angreifer ja i.allg. schon viele Schlüssel ausschließen. Man kann (nicht allzu schwierig) zeigen, daß es ⎡1/ε2⎤ Schlüssel sein müssen [GiMS_74]. T – H – 11 Bild 3-15: Ein kleiner Authentikationscode Wählt man ε = 2 –σ , so braucht man also mindestens Schlüssel der Länge 2σ. Dies ist lange nicht so schlimm wie die untere Schranke für Konzelationssysteme: Dort mußte der Schlüssel so lang wie die Nachricht sein. Für die Fehlerwahrscheinlichkeit wird hingegen in der Praxis ein Wert von etwa 2 –100 genügen. (Sonst wird allmählich die Wahrscheinlichkeit größer, daß der zur Prüfung des MAC benutzte Rechner unbemerkt ausfällt und gefälschte Nachrichten als gültig passieren läßt u.ä., oder überhaupt sämtliche Risiken des praktischen Lebens.) Anhand der MAC-Länge wissen wir, daß das Erkennen von Fälschungen in diesem Beispiel höchstens mit Wahrscheinlichkeit 1/2 möglich ist. Wir wollen nun zeigen, daß tatsächlich jede Fälschung mit Wahrscheinlichkeit 1/2 erkannt wird. Wir betrachten nur den Fall, daß der Angreifer gerne die Nachricht T unterschieben würde. Wenn der richtige Absender noch gar nichts gesendet hat, sind alle 4 Schlüssel gleichwahrscheinlich, und bei je zweien hat T als MAC 0 bzw. 1. Mit Wahrscheinlichkeit 1/2 wählt der Angreifer also den falschen Wert. Das interessante an einem Authentikationscode ist aber, daß die Sicherheit auch dann noch gilt, wenn der richtige Absender die Nachricht H mit ihrem richtigen MAC sendet, und der Angreifer diese abfängt und durch T zu ersetzen versucht.
Seite 1 und 2: A. Pfitzmann: Datensicherheit und K
Seite 3 und 4: VI A. Pfitzmann: Datensicherheit un
Seite 5 und 6: X A. Pfitzmann: Datensicherheit und
Seite 7 und 8: 2 A. Pfitzmann: Datensicherheit und
Seite 9 und 10: 6 A. Pfitzmann: Datensicherheit und
Seite 11 und 12: 10 A. Pfitzmann: Datensicherheit un
Seite 31: 50 A. Pfitzmann: Datensicherheit un
Seite 57 und 58: 102 A. Pfitzmann: Datensicherheit u
Seite 83 und 84:
154 A. Pfitzmann: Datensicherheit u
Seite 85 und 86:
Seite 87 und 88:
Seite 89 und 90:
Seite 91 und 92:
Seite 93 und 94:
Seite 95 und 96:
Seite 97 und 98:
Seite 99 und 100:
Seite 101 und 102:
Seite 103 und 104:
Seite 105 und 106:
Seite 107 und 108:
Seite 109 und 110:
Seite 111 und 112:
Seite 113 und 114:
Seite 115 und 116:
Seite 117 und 118:
Seite 119 und 120:
Seite 121 und 122:
Seite 123 und 124:
Seite 125 und 126:
Seite 127 und 128:
Seite 129 und 130:
Seite 131 und 132:
Seite 133 und 134:
Seite 135 und 136:
Seite 137 und 138:
Seite 139 und 140:
Seite 141 und 142:
Seite 143 und 144:
Seite 145 und 146:
Seite 147 und 148:
Seite 149 und 150:
Seite 151 und 152:
Seite 153 und 154:
Seite 155 und 156:
Seite 157 und 158:
Seite 159 und 160:
Seite 161 und 162:
Seite 163 und 164:
Seite 165 und 166:
Seite 167 und 168:
Seite 169 und 170:
Seite 171 und 172:
Seite 173 und 174:
Seite 175 und 176:
Seite 177 und 178:
Seite 179 und 180:
Seite 181 und 182:
Seite 183 und 184:
Seite 185 und 186:
Seite 187 und 188:
Seite 189 und 190:
Seite 191 und 192:
Seite 193 und 194:
Seite 195 und 196:
Seite 197 und 198:
Seite 199 und 200:
Seite 201 und 202:
Seite 203 und 204:
Seite 205 und 206:
Seite 207 und 208:
Seite 209 und 210:
Seite 211 und 212:
Seite 213 und 214:
Seite 215 und 216:
Seite 217 und 218:
Seite 219 und 220:
Seite 221 und 222:
Seite 223 und 224:
Seite 225 und 226:
Seite 227 und 228:
Seite 229 und 230:
Seite 231 und 232:
A. Pfitzmann: Datensicherheit und K
Seite 233 und 234:
Seite 235 und 236:
Seite 237 und 238:
Seite 239 und 240:
Seite 241 und 242:
Seite 243 und 244:
Seite 245 und 246:
Seite 247 und 248:
Alle anzeigen

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?