/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ | GGGGGG CCCCCC FFFFFFF | | G G C F | | G GGG C FFFF | | G G C F | | GGGGGG CCCCCC F | | | | [G]erman [C]omputer [F]reaks | \ Since 1997 / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Titel: Angriffe auf kryptographische Protokolle ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eine Einführung By GENTLEMAN for GCF GENTLEMAN@GCF.DE Themen: 1 - Einleitung 2 - Replay-Attack 3 - Man-In-The-Middle-Attack 4 - Identitätsbetrug-Betrug 5 - Literatur 5 - Greetz to ... 1. Einleitung Um gleich einigen Widersprüchen vorzusorgen handelt es sich hier nicht um eine wissenschaftliche Abhandlung zur Krypto- analyse, es werden vielmehr mögliche Schwachstellen von Protokollen und Protokoll-Suiten behandelt. Ich werde die meisten Theorien verständlicher gestalten, in- dem ich einen Byte via XOR "verschlüssele", so dass es etwas anschaulicher wird. 2. Replay-Attack Eine relativ bekannte Methode ist diese Form der Attacke, da sie sich als sehr einfach darzustellen entpuppt, es geht hier- bei lediglich um die Wiederholung einer abgefangenen Nachricht. Diese nachricht kann erneut unverschlüsselt gesendet werden, wenn keine weiteren Sicherheiten zum Schutz dieser Nachricht eingegliedert wurden. Wir können hierbei von einer fiktiven Nachricht ausgehen, die keine unbekannten und einzigartigen merkmale aufweist, demnach genauso aussieht wie eine andere vorhergehende nachricht mit derselben Botschaft und demselben Schlüssel. Ein kleiner Fingerzeig: Schlüssel: 10101010 Nachricht: 01010101 Verschlüsselt: 11111111 Hierbei wird sichtbar das auch 2,3 oder mehr Botschaften mit demselben Schlüssel und derselben Nachricht wieder die gleiche verschlüsselte nachricht ergeben wie die vorige und folgende. Ein Angreifer der nun eine "Aktion" wiederholen will, kann sich nun darauf beschränken die abgefangene Nachricht erneut zu senden ohne sie entschlüsseln zu müssen. Um also sicherzugehen, dass eine nachricht nur einmal gesendet werden kann und spätere Nachrichten unterschiede aufweisen, so das um eine Aktion zu wiederholen erst die nachricht mit der Aktion entschlüsselt und später wieder verschlüsselt werden muss, bei bekanntsein des Algorithmus sowie ggf. geheimen Variablen. Gehen wir nun vom oberen Beispiel aus könnten wir eine variable hochzählen, so dass die Nachricht 1 in einem speziellen Part (ggf. Header) eine Idenfikationsnummer 1 kriegt, die 2 Nachricht eine 2, die 3 eine 3, müsste ein Angreifer erst wissen, das die ID hochgezählt wird, dies könnte er erraten oder er müsste mindestens 2 unserer Nachrichten empfangen und entschlüsseln um eine ID erkennen zu können. Setzen wir dieses Beispiel wieder um: Schlüssel: 10101010 1010 ---------------------------- STATUS BODY | ID ---------------------------- Nachricht1: 01010101|0001 Verschlüsselt: 11111111|1010 ---------------------------- Nachricht2: 01010101|0010 Verschlüsselt: 11111111|1000 Wie man nun sehen kann besitzen diese Nachrichten eine Möglichkeit zur Identifikation, um ggf. als gefälscht erkannt werden zu können. Hierbei werden häufig Zeiten, Variablen, Zähler, Einmalwerte etc. ls Identifikation genutzt. 3. Man-In-The-Middle-Attack Ein für viele aus der Netzwerksicherheit bekanntes Problem, das fast alle Sicherheitsschranken ausschalten kann ist bei einer beidseitigen Kommunikation mit Sicherheit die MITM-Attack, angenommen wir haben 3 fiktive Perseonen, nennen wir sie YOU, ME & YOU2. Wobei sich die Situation so verhält YOU <-> ME <-> YOU2, dementsprechend ist ME der Angreifer. Hierbei eignet sich ein Protokoll gut, bei dem keine Schlüssel bekannt werden sehr gut als Beispiel. YOU-Schlüssel: 11001100 YOU2-Schlüssel: 10101010 Nachricht: 01010101 (YOU will diese an YOU2 schicken) Bei dieser Methode verschlüsselt YOU die Nachricht mit seinem Schlüssel sendet die verschlüsselte nachricht an YOU2, der diese mit seinem Schlüssel verschlüsselt und schickt diese wieder zurück an YOU, dieser entschlüsselt das nun mit seinem Schlüssel und schickt die Nachricht zurück zu YOU2 der sie nun mit seinem Schlüssel entschlüsselt und somit die Originalnachricht von YOU erhält, ohne das einer von beiden den Schlüssel des anderen kennt. Hier ein Beispiel, mit den oben gegebenen Daten: YOU-Schlüssel: 11001100 Nachricht: 01010101 Verschlüsselt: 10011001 // mit YOU's Schlüssel verschlüsselt YOU -> YOU2 YOU2-Schlüssel: 10101010 Verschlüsselt: 10011001 Verschlüsselt2: 00110011 // mit YOU's und YOU2's Schlüssel verschlüsselt YOU2 -> YOU YOU-Schlüssel: 11001100 Verschlüsselt2: 00110011 // entschlüsselt mit seinem Schlüssel Verschlüsselt: 11111111 // mit YOU2's Schlüssel verschlüsselt YOU -> YOU2 YOU2-Schlüssel: 10101010 Verschlüsselt: 11111111 // entschlüsselt mit seinem Schlüssel Entschlüsselt: 01010101 // entschlüsselt Bei der Situation, das nun ME in der Mitte sitzt und lauscht kann man sich das so vorstellen, dass ich nun alle Pakete zwischen den beiden Personen empfange und mit meinem Schlüssel versehe, also kann ich alle lesen und kann ggf. die Pakete weiterleiten oder selbiges unterlassen. Im Fall das ich obiges beispiel wähle und das Paket von YOU empfange, benutze ich nun meinen Schlüssel, was wie folgt aussieht: YOU-Schlüssel: 11001100 Nachricht: 01010101 Verschlüsselt: 10011001 // mit YOU's Schlüssel verschlüsselt YOU -> ME ME-Schlüssel: 11111111 Verschlüsselt: 10011001 Verschlüsselt2: 01100110 // mit YOU's und ME's Schlüssel verschlüsselt ME -> YOU YOU-Schlüssel: 11001100 Verschlüsselt2: 01100110 // entschlüsselt mit seinem Schlüssel Verschlüsselt: 10101010 // mit ME's Schlüssel verschlüsselt YOU -> ME ME-Schlüssel: 11111111 Verschlüsselt: 10101010 // entschlüsselt mit seinem Schlüssel Entschlüsselt: 01010101 // entschlüsselt Falls ich mich nun entschließe YOU's Paket weiterzuleiten ist es das Gleiche nur das ich nun YOU2 wieder mit ME's Schlüssel eine Nachricht schicke und sich das ganze wieder so abspielt, so dass im Endeffekt beide das Gefühl haben miteinander zu kommunizieren und ME's alle Nachrichten empfangen und lesen kann. 4. Identitätsbetrug-Betrug Hierbei kann man gut und gerne auf die Realität verweisen, in der sich Personen als eine andere Person ausgeben und eine Identifikations- schwäche ausnutzen. Hierbei geben wir uns, wie auch in den anderen Beispielen, als jemand anderes aus als wir eigentlich sind. In diesem Fall gehen wir davon aus, das sich ME als YOU gegenüber YOU2 ausgibt und somit YOU2 denkt er würde von YOu eine Nachricht erhalten, dieses Problem existiert sowohl bei symmetrischen (DES) sowie asymmetrischen (PGP) Algorithmen, hierbei gehen wir davon aus das ME eine Nachricht für YOU generieren kann, durch YOU2's öffentlichen Schlüssel den auch YOU besitzt. Durch eine fehlende Identifikation kann ME sich also als YOU ausgeben, da er eine eigene Nachricht erstellen kann und YOU2 auf andere Merkmale einer Vertrauensperson finden muss. Wenn ME nun diese Merkmale, in oder um die Nachricht herum, fälschen kann muss YOU2 wieder denken er hätte eine mail von YOU erhalten, was sich z.B. an einer, mit einem öffentlichen Schlüssel, verschlüsselten Nachricht mit gefälschtem Absender zeigt. Folgende Situation: Schlüssel: 11100011 // der öffentliche Schlüssel von YOU2 ;) Nachricht: 01010101 Verschlüsselt1: 10110110 // von ME verschlüsselt Verschlüsselt2: 10110110 // von YOU verschlüsselt Da beide gleich aussehen, kann YOU2 den wahren Absender nur am Inhalt oder wie bereits erwähnt einer äußeren Variablen erkennen ob die Nachricht echt ist. Eine Maßnahme zum Schutz wäre es einen Identifi- kationscode für jeden einzuführen, so das jeder ein eindeutiges Merkmal, und hoffentlich fälschungsicheres Merkmal, besitzt um eine Identifikation zu gewährleisten. 5. Literatur Bruce Schneier - Angewandte Kryptographie Johannes Buchmann - Einführung in die Kryptographie Peter Lipp - Sicherheit und Kryptographie in Java : Einführung, Anwendung und Lösungen 5. Greetz to ... "GCF", some PPL from "UNF", "In Flames" & "Apcalyptica" for their great music...