Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Weitere Magazine

Empfehlungen

Info

120 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr 119 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr Parallelisierbarkeit: Kann die Ent- und/oder Verschlüsselung parallelisiert werden? Oder muß sie streng sequentiell durchgeführt werden? Vorausberechnung der Blockchiffre: Kann die Blockchiffre vorausberechnet werden oder kann auch dieser, bei weitem rechenaufwendigste Teil erst ausgeführt werden, wenn der Klartext bzw. Schlüsseltext vorliegt? 3.8.2.7 Anmerkungen zu expandierenden Blockchiffren und zur Initialisierung der Speicherglieder ECB CBC PCBC CFB OFB OCFB + möglich – nicht möglich Verwendung indeterministischer In den Bildern 3-42, 3-46, 3-48, 3-49 und 3-50 sowie den zugehörigen Verfahrensbeschreibungen ist jeweils nur der übliche Fall dargestellt, daß die Blockchiffre Klartextblöcke in Schlüsseltextblöcke gleicher Länge abbildet. Ist dies nicht der Fall, d.h. sind die Schlüsseltextblöcke länger, so muß in Bild 3-42 jeweils – geschickterweise vor dem „Speicher für Schlüsseltextblock n-1“ – eine Auswahl getroffen werden. Entsprechendes gilt für Bild 3-49. In den Bildern 3-46, 3-48 und 3-50 ist jeweils nur die vorhandene Auswahl zu modifizieren. Blockchiffren + asymmetrische Stromchiffre – symmetrische Stromchiffre Bei asymmetrischer Blockchiffre entsteht – durch Blocklänge der Blockchiffre bestimmt + beliebig Länge der verschlüsselbaren Einheiten potentiell unbegrenzt keine bei Verfälschung 1 + ⎡b / r⎤ Blöcke, wenn Fehler ganz rechts, sonst evtl. einer 2 Blöcke potentiell unbegrenzt nur innerhalb eines Blocks Fehlererweiterung Ebenfalls nicht eingegangen wird auf die Notwendigkeit geeigneter, d.h. insbesondere gleicher, Initialisierung der Speicherglieder. Die „Speicher für Schlüsseltextblock n-1“ in Bild 3-42 sollten geeignet initialisiert werden, die „Speicher für Schlüsseltextblock n-1“ und die „Speicher für Klartextblock n-1“ in Bild 3-49 müssen geeignet initialisiert werden. Die Schieberegister in Bild 3-46 sollten, die in den Bildern 3-48 und 3-50 müssen geeignet initialisiert werden [MeMa_82, DaPr_89]. Diese Aussagen beziehen sich jeweils auf die Verwendung zum Zweck der Konzelation. Bei Verwendung zum Zweck der Authentikation müssen beim Generieren und Prüfen des Authentikators jeweils dieselben Initialisierungen verwendet werden, die aber für alle Teilnehmer und alle Nachrichten gleich sein können. Genaueres zum Thema Initialisierung der Speicherglieder wird in Aufgabe 3-18 d) erarbeitet. weniger ja, sogar Konzelation im selben Durchgang ja bei geeigneterRedundanz: ja ja, sogar Konzelation im selben Durchgang bei deterministischer Blockchiffre: ja selbstsynchronisierend, solange Blockgrenzen erkannt bei Redundanzinnerhalb jedes auch zur Authentikation geeignet? 3.8.2.8 Zusammenfassung der Eigenschaften der Betriebsarten Blocks: ja synchron potentiell synchron selbstsynchronisierend potentiell synchron selbstsynchronisierend, solange Blockgrenzen erkannt synchron oder selbstsynchronisierend? nein potentiell nein nein potentiell nein ja potentiell ja, zumindest jeweils für einen Block nur bei Entschlüsselung nur bei Entschlüsselung potentiell nein potentiell nein wahlfreier Zugriff ja nur bei Entschlüsselung Parallelisierbarkeit ja nur bei Entschlüsselung jeweils für einen Block nein Vorausberechnung der Blockchiffre Bild 3-51: Eigenschaften der Betriebsarten Bild 3-51 gibt eine Zusammenfassung der Eigenschaften der beschriebenen Betriebsarten für Blockchiffren. Während die Beschreibung im Text sich vom Einfachen (und Standardisierten, nämlich ECB, CBC, CFB und OFB) zum Komplizierten, oder mit anderen Worten vom Speziellen zum Allgemeinen vorarbeitete, sind in Bild 3-51 die Betriebsarten nach ihrer Verwandtschaft in zwei Gruppen geordnet. In der linken Gruppe werden Ver- und Entschlüsselungsfunktion der Blockchiffre benutzt, und die Blockchiffre liegt direkt im Transformationsweg vom Klartext über den Schlüsseltext zum Klartext. In der rechten Gruppe wird die Verschlüsselungsfunktion der Blockchiffre zur Generierung einer Pseudozufallsfolge benutzt. Die Entschlüsselungsfunktion der Blockchiffre wird nicht verwendet. Im direkten Transformationsweg vom Klartext über den Schlüsseltext zum Klartext liegen dann nur die von der Vernam-Chiffre wohlbekannten Additions- und Subtraktionsoperatoren. Diese Gruppenspezifika bedingen die ersten drei Eigenschaften. Die in den Gruppen jeweils rechts stehende Betriebsart umfaßt jeweils die beiden links von ihr stehenden. Deshalb ist die Fehlerausbreitung der jeweils rechts stehenden Betriebsart jeweils nur potentiell unbegrenzt und sie sind jeweils zur Authentikation im selben Durchgang geeignet, d.h. es muß jeweils eine passende Funktion h verwendet werden. Entsprechendes gilt für die Frage, ob PCBC bzw. OCFB synchrone Stromchiffren sind. Bei geeigneter Wahl von h sind sie es. Zwischen den bisher diskutierten Eigenschaften der Betriebsarten und diesen 3 weiteren bestehen folgende Zusammenhänge: Aus selbstsynchronisierend folgt wahlfreier Zugriff bei der Entschlüsselung, denn zumindest nach dem für die Selbstsynchronisation nötigen Stück Schlüsseltext kann der folgende Teil entschlüsselt werden. Aus wahlfreiem Zugriff folgt Parallelisierbarkeit, denn wenn Teile unabhängig vom Rest bearbeitet werden können, dann kann dies auch parallel geschehen. Zusätzlich zu diesen Eigenschaften sind für den praktischen Betrieb, d.h. Nutzung oder Implementierung, folgende 3 Eigenschaften der Betriebsarten interessant und nützlich: Wahlfreier Zugriff: Kann wahlfrei auf einzelne Teile des Schlüsseltextes und/oder Klartextes zugegriffen werden, d.h. kann aus wahlfrei herausgegriffenen Teilen des Klartextes der entsprechende Teil des Schlüsseltextes errechnet werden und/oder aus wahlfrei herausgegriffenen Teilen des Schlüsseltextes der entsprechende Teil des Klartextes? Oder muß Schlüsseltext bzw. Klartext jeweils von Beginn der Nachricht an berechnet werden?
122 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr 121 A. Pfitzmann: Datensicherheit und Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr Alle Linien führen der Blocklänge entsprechend viele Alphabetzeichen Klartextblöcke haben die Länge des Schlüssels der Blockchiffre Addition mod 2 Liegt die Blockchiffre direkt im Transformationsweg vom Klartext über den Schlüsseltext zum Klartext, ist keine Vorausberechnung der Blockchiffre möglich. Andernfalls kann zumindest jeweils ein Block vorausberechnet werden. Insgesamt ergeben sich die Einträge der unteren 3 Zeilen von Bild 3-51. Speicher für Zwischenergebnisblock n-1 3.8.3 Kollisionsresistente Hashfunktion aus Blockchiffre Klartextblock n Letzter Block Verschlüsselung Aus Sicherheitsgründen sollte gelten: Schlüssellänge der Blockchiffre nicht wesentlich länger als ihre Blocklänge. Bild 3-52: Konstruktion einer kollisionsresistenten Hashfunktion aus einer deterministischen Blockchiffre Bild 3-52 ist in der gleichen Anordnung wie Bild 3-42 gezeichnet. Deshalb fällt auf, daß die Klartextblöcke an einer unüblichen Stelle in die Blockchiffre eingespeist werden – nämlich als Schlüssel. In diesem Abschnitt wird beschrieben, wie aus deterministischen Blockchiffren, deren Schlüssel nicht (wesentlich) länger als die Blocklänge ist, kollisionsresistente Hashfunktionen konstruiert werden können. Wie in §3.5.1 für kollisionsresistente Permutationenpaare bereits erklärt wurde, kann das Finden von Kollisionen allenfalls komplexitätstheoretisch schwer sein – informationstheoretisch ist es leicht, denn ein Angreifer könnte immer alle Möglichkeiten durchprobieren. Entsprechendes gilt für kollisionsresistente Hashfunktionen: Da sie beliebig lange Argumente auf Werte fester Länge abbilden, gibt es beliebig viele Kollisionen, d.h. verschiedene Argumente, die auf denselben Wert abgebildet werden. Ein Angreifer muß also nur genügend ausdauernd suchen (können), um Kollisionen zu finden. Das Beste, was man sich wünschen kann, wäre eine effiziente Konstruktion, die aus beliebigen Blockchiffren kollisionsresistente Hashfunktionen gewinnt, die bewiesenermaßen so sicher wie die verwendete Blockchiffre sind. Leider ist eine solche Konstruktion nicht bekannt – unter den zahlreichen Vorschlägen gibt es nicht einmal solche, die zwei der drei kursiv hervorgehobenen Eigenschaften haben. Da in §3.6.4 bereits (unter der Faktorisierungsannahme) bewiesenermaßen sichere kollisionsresistente Hashfunktionen angegeben wurden, geht es hier vor allem um größere Effizienz. Deshalb wird eine gemäß Bild 3-12 „wohluntersuchte“ Konstruktion angegeben, wie aus deterministischen Blockchiffren, deren Schlüssel aus Sicherheitsgründen hier nicht (wesentlich) länger als die Blocklänge sein dürfen [LuRa_89], sehr effizient kollisionsresistente Hashfunktionen konstruiert werden können. Wichtig ist – ganz egal wie die Hashfunktion konstruiert wird –, daß der Initialisierungswert festgelegt oder die Nachricht postfixfrei90 codiert ist. Sonst gibt es folgende trivialen Kollisionen: Bei der rundenweisen Berechnung des Hashwertes einer Nachricht entstehen mit den Zwischenergebnisblöcken jeweils passende Initialisierungswerte für die um die bisher abgearbeiteten Klartextblöcke verkürzte Nachricht. Um diese mögliche Schwäche zu vermeiden und auch um beim Auffüllen der Nachricht auf ein Vielfaches der Schlüssellänge der Blockchiffre zu wissen, wie viele Bits aufgefüllt wurden, sollte der letzte Klartextblock die Länge der Nachricht in Bit enthalten [LaMa_92 Seite 57]. Außerdem wird für jede Hashfunktion, die Ergebnisse der Länge b liefert (also z.B. auch die angegebene Konstruktion bei Verwendung einer Blockchiffre der Blocklänge b), durch Durchprobieren des Nachrichtenraumes im Mittel nach etwa 2b/2 Versuchen eine Kollision gefunden. Dies liegt am sogenannten Geburtstagsparadox: Damit mit Wahrscheinlichkeit 1/2 mindestens zwei Menschen am gleichen Tag Geburtstag haben, werden nicht etwa 365/2, sondern nur etwa √⎺⎺⎺ 365 Menschen benötigt [DaPr_89 Seite 279-281]. Für viele Anwendungen wird bei der angegebenen Konstruktion der Einsatz von DES als Blockchiffre also nicht ausreichen, da 232 Versuche von vielen möglichen Angreifern durchaus durchführbar sind. Selbst eine Blocklänge von 128 Bit dürfte für die überschaubare Zukunft nicht genügen, da demnächst auch 264 Versuche fähigen Angreifern möglich sein werden. Deshalb sollten kollisionsresistente Hashfunktionen Ergebnisse von wenigstens 160 Bit Länge liefern. In [DaPr_84, DaPr_89 Seite 265] wird folgende Konstruktion einer kollisionsresistenten Hashfunktion aus einer deterministischen Blockchiffre (z.B. DES) vorgeschlagen: Der zu hashende Klartext wird in Blöcke der Schlüssellänge der Blockchiffre unterteilt. In jeder Runde wird einer der Klartextblöcke als Schlüssel der Blockchiffre verwendet. Die Eingabe der Blockchiffre ist für die erste Runde ein Initialisierungswert, für die zweite und alle folgenden Runden das Ergebnis der vorherigen Runde. (In Bild 3-52 wird der Initialisierungswert sinnvollerweise als Zwischenergebnisblock Nummer 0 aufgefaßt.) In jeder Runde wird nicht nur verschlüsselt, sondern auch die Eingabe der Blockchiffre modulo 2 zur Ausgabe addiert. Dies verhindert, daß ein Angreifer rückwärts rechnen kann, indem er einen Schlüssel (sprich: Klartextblock) wählt, dann bezüglich des gewählten Schlüssels die Blockchiffre invertiert (sprich: entschlüsselt) und so die Eingabe dieser Runde erhält. Auf diese Art könnte er, wenn der Initialisierungswert frei wählbar ist, Kollisionen berechnen, indem er das Beschriebene mit zwei unterschiedlichen Schlüsseln ausführt. Das Ergebnis der letzten Runde ist die Ausgabe der Hashfunktion. (Damit dieser Hashwert von anderen überprüft werden kann, muß ihnen auch der Initialisierungswert bekannt sein. Ist der Initialisierungwert nicht global festgelegt, so muß er ihnen ggf. mitgeteilt werden.) 90 Kein Postfix, d.h. Endstück, einer postfixfrei abgebildeten Nachricht darf gleichzeitig postfixfreie Abbildung einer anderen Nachricht sein.
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 13 und 14:
14 A. Pfitzmann: Datensicherheit un
Seite 15 und 16: 18 A. Pfitzmann: Datensicherheit un
Seite 57 und 58: 102 A. Pfitzmann: Datensicherheit u
Seite 65: 118 A. Pfitzmann: Datensicherheit u
Seite 117 und 118:
222 A. Pfitzmann: Datensicherheit u
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 ...

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

Template löschen?

Als Template speichern?