Microsoft bietet in Office die Möglichkeit Dokumente zu verschlüsseln, um diese vor unberechtigten Augen zu schützen. Bei dieser Verschlüsselung wird der Stromchoiffre RC4 eingesetzt. Unverständlicherweise hat Microsoft aber ein grundlegendes Implementierungsprinzip jedes Stromchiffres (und auch anderer) verletzt, wodurch diese Verschlüsselung letztendlich in vielen Fällen ohne großen Rechenaufwand zu knacken ist. Hierzu erst einmal etwas Theorie:
Was ist RC4? RC4 ist eine symetrische Verschlüsselung mit variaber Schlüssellänge bis 2048Bit. Ein Stromchiffe, im Gegensatz zu einem Blockchiffre, erzeugt zum Verschlüsseln von Daten einen Schlüsselstrom mit dem der Datenstrom Bitweise per XOR verschlüsselt wird. Der Schlüsselstrom hat die gleiche Länge, wie der Datenstrom. Zum Entschlüsseln wird der chiffirierte Datenstrom wieder mit dem selben Chiffrestrom per XOR verknüoft und man erhält die Ausgangsdaten, hierzu eine kurze Illusration:
Ursprungsdaten: 11001101
Chiffrestrom: 01011000
------------------------
Chiffrat: 10010101
Chiffrat: 10010101
Chiffrestrom: 01011000
----------------------
Ursprungsdaten: 11001101
Um einen pseudozufällgen Chiffrestrom zu erzeugen braucht man zwei Komponenten: Einen Initialisierungsvektor (IV) und einen Seed zur Initialisierung des Pseudoufallszahlen-Generators. Psudozufallsgeneratoren haben eine bestimmte Eigenschaft, werden sie mit dem gleichen Initialisierunsvektor und dem gleichen Seed aufgerufen, so erzeugen sie identische Chiffreströme. Dies ist kein Fehler, dies ist gewollt, da man ja ein Chiffrat auch wieder entschlüsseln will, ohne daß man den kompletten Chiffrestrom mit der gleichen Länge wie das Chiffrat vorhalten muß (im Gegensatz zu einem One-Time-Pad). Man braucht also nur IV und Seed um ein verschlüsseltes Dokument wieder herzustellen. Dadurch wird klar, daß IV und Seed geheim gehalten werden müssen.
Neben diesen Randbedingungen gibt es noch eine Fundamentale Bedingung, welche erfüllt sien muß, damit ein Stromchiffre sicher sein kann: Man darf nicht zwei unterschiedliche Dokumente mit dem gleichen Chiffrestrom verschlüsseln, waum wird gleich gezeit.
Gegeben Plain-Text1 (PT1) und Plain-Text2 (PT2), sowie Chiffrestro RC4 aus IV und Seed (in beiden Fällen identisch.
Cyphertext CT1 = PT1 XOR RC4
Cyphertext CT2 = PT2 XOR RC4
Wenn RC4 identisch ist, dann gilt folgendes:
CT1 XOR CT2 =
(PT1 XOR RC4) XOR (PT2 XOR RC4) =
(PT1 XOR PT2) XOR (RC4 XOR RC4) =
(PT1 XOR PT2) XOR 0 =
PT1 XOR PT2
Hat man also zwei unterschiedliche Dokumente, die mit gleichem Chiffrestrom verschlüsselt wurde und verknüpft diese mit XOR, so fällt der Chiffre sozusagen einfach raus. Man erhält zwei XOR-Verknüpfte Dokumente im Klartext. Was bringt einem das?
Ein Klartet hat die kryptografische "Unart", daß die Buchstaben des Textes mit einer gewissen statistischen Häufigkeit auftreten, deswegen ist das Knacken eines Substitutionschiffres (wie .B. der Caesar-Chiffre oder sein Spezialfall ROT13) mit den Mitteln der Kryptoanalyse ein Klacks. Hat man nun zwei Plain-Text-Dokuente, welche mit XOR verknüpft wurden, so haben gewisse Buchstabenkombinationen immer noch eine bestimmte statistische Häufigkeit und lassen sich genau so leicht entschlüsseln. Schlimmer noch sieht es aus, wenn die beiden Texte eine unterschiedliche Länge hatten, denn dann sind Teile des Textes (diese, bei denen der zweite Texte leer war) sogar im Klartext vorhanden trotz XOR.
Ergo: Niemals der gleiche Chiffrestrom für unterschiedliche Daten. Dies ist auch eines der Hauptprobleme bei der WEP-Verschlüsselung in WLAN, da sich hier der Chiffrestrom sehr häufig wiederholt und zudem der IV im Klartext übertragen wird, somit kann der Angreifer genau erkennen, wann er zwei "interesting packets" gefunden hat, also Datenpakete, welche mit dem gleichen Chiffrestrom verschlüsselt wurden.
Was hat Microsoft nun getan? Ganz einfach. Verschlüsselt jemand ein Dokument, speichert es, öffnet es dann wieder und ändert etwas, so bleibt verständlicherweise der Seed (Sozusagen das Pawort) natürlich identisch. Dummerweise bleibt aber auch der Initialisierungsvektor (IV) für den Pseudozufallszahlengenerator identisch. Da sowohl IV, als auch Seed gleich sind mündet dies in einem identischen Chiffrestrom. Geht man nun davon aus, daß oftmals Dokumente häufiger in mehreren Versionen abgespeichert werden, oder von unterschiedlichen Personen bearbeitet werden, so ist die Wahrscheinlichkeit für einen Angreifer sehr hoch zwei Versionen des Dokuentes zu erhalten (allein schon über temporäre Dateien). Auch das Herausfischen aus Emails bei Bearbeitung durch mehrere Personen ist denkbar, es ist also keine rein hypohetische Möglichkeit an diese zwei unterschiedlichen Versionen zu gelangen.
Hat man nun diese zwei Versionen, so greift die Erklärung von oben: Beide per XOR verknüpfen, und den Plaintext analysieren (was automatisiert mit fertigen Programmen leicht möglich ist und auf einem modernen Rechner im Bereich von wenigen Minuten erledigt ist).
Da man davon ausgehen kann, dass nur Leute Dokumente verschlüsseln, die auf Sicherheit Wert legen und die eine geisse Brisanz besitzen, so muß man sagen, daß die interne Verschlüsselung in Office nicht anzuraten ist.
Noch eine Anmerkung für Alle, die sich fragen sollten warum RC4 überhaupt verwendet wurde, da man häufig liest RC4 sei schon längst geknackt: Diese Aussage stimmt so nicht ganz. Der Algorithms zu RC4 ist proprietärer Besitz einer US-Firma, welche ur als Closed Source vorliegt. Allerdings wurde vor einigen jahren von einer anonymen Person ein Quellcode im Usenet verbreitet, welcher identische Verschlüsselungen wie RC4 liefert, es ist also fast sicher, daß es sich dabei um RC4 handelt. Dieser Algorithmus wurde natürlich von allen Seiten begutachtet, da er sehr scnell und simpel ist, es wurden jedoch bis heute keine grundlegenden Schwachstellen des Algorithmus gefunden, sofern:
a) er korrekt implementiert wird
b) die Schlüssellänge oß genug ist
Doch genau hier krankt es. Durch Exportschranken durfte RC4 nur mit einer Schlüssellänge von 40Bit exportiert werden (jeder Admin kennt das Problem seit NT4.0) und 40Bit urden schon anfang der 90er mit ca. 40 PentiumRechnern in 8 Tagen per Brute Force (also stupides durchprobieren aller Möglichkeiten) "geknackt". Wobei man anmerken muß, nicht der Algorithmus wurde geknackt, sondern durch rohe Gwalt wurde durchprobiert.
Das zweite Prolem sind falsche Implementierungen, wie z.B. bei WEP und jetzt bei Office (es gibt auch noch andere Beispiele). Zuletzt ist natürlich auch noch die Qualität des Generators für Pseudozufallszahlen ein Aspekt der Sicherheit.
Letztendlich ist aber RC4 als solches immer noch quasi sicher, wenn Schlüssellänge stimmt und Implementierung.
Ikaros34
xafford
