Archiv der Kategorie: Kryptographie

Primfaktorzerlegung und NP

Hallo,

zunächst eine Warnung: dieser Beitrag ist relativ schwierig und ohne Vorkenntnisse in theoretischer Informatik nicht zu verstehen.

Im Laufe einer Lehrveranstaltung hat sich die Frage gestellt, ob die Primfaktorzerlegung (genauer: RSA – also 2 Primfaktoren) in NP liegt bzw. sogar NP-vollständig ist – ums populärer auszudrücken: wie viel Ärger bekommen wir, falls P=NP gilt.

Wir haben allerdings an dieser Stelle jedoch das Problem, dass die Komplexitätsklasse NP bzw. die Laufzeitfunktion NTIME auf Sprachprobleme – also Entscheidungen definiert ist. Innerhalb der Literatur finden sich wenig und vor allem sehr oberflächliche Aussagen darüber („es ist leicht einzusehen dass dieses Problem in NP liegt…“). Die letzten Wochen habe ich intensiver darüber nachgedacht und ich denke, eine brauchbare Lösung anbieten zu können.

Zunächst wichtige Vorarbeit:  die Frage, ob eine natürliche Zahl eine Primzahl ist oder nicht, liegt in P (also deterministischer Polynomialzeit). Erreicht wird dies durch den AKS-Primzahltest. Damit ist auch die Frage, ob eine Zahl n (ungleich 1) Primteiler besitzt in P feststellbar, da dies immer der Fall ist, sofern es sich um keine Primzahl handelt (Hauptsatz der Zahlentheorie).

Im nächsten Schritt prüfen wir, ob die Zerlegung des RSA-Moduls in NP liegt.

Nichtdeterministische ZerlegungNehmen wir hierzu beispielhaft die Primzahlen p=7 und q=11 also M=p*q = 7*11=77, binär dargestellt 1001101. Mittels eines naiven Nichtdeterministischen Algorithmus, können wir von 1 bis sqrt(M) alle möglichen Teiler durchprobieren. Dass dies in NP liegt, soll mittels der Abbildung gezeigt werden. Die Baumtiefe entspricht n/2, also die halbe Eingabelänge n(=7). Der Übersicht halber hier nur die Tiefe 3 anstelle 4.

Durch diese Verzweigung erhalten wir also alle Lösungskandidaten h.

Im blauen Kasten prüfen wir nun, ob h ein Primteiler von M ist. Sowohl der Primzahltest „ist h eine Primzahl?“ liegt in P (wie oben erwähnt), als auch die Division „ist h ein Teiler von M“. Auch würde der Primzahltest des zweiten Divisors in P liegen. Dementsprechend liefert der skizzierte Nichtdeterministische Algorithmus am Ende ein „ja“, da 111 (=7) sowohl Primzahl, als auch Teiler von M (77) ist.

Wir haben also nun festgestellt, dass die Frage nach der Primfaktorzerlegung in NP liegt. Das hilft uns allerdings nur bedingt, da diese Antwort schon vorher bekannt war. Per Definition besitzt ein RSA-Modul zwei Primteiler, daher würde der Algorithmus natürlich stets ein ja liefern. Wir müssen also dieses Entscheidungsproblem (1)  nutzen, um effizient das Optimierungsproblem (2) zu lösen.

Aus diesem Grund definieren also das Problem in folgender Weise neu:

Eingabe: (M,k) wobei m das RSA-Modul (bestehen aus dem Produkt zweier Primzahlen), und k eine beliebige Zahl k<=M.

Zulässige Lösung: ja/nein

Frage: liegt ein Primfaktor des RSA-Moduls M unterhalb von k.

Wir übergeben also das Modul M=(p*q) und fragen, ob sich der kleinere Primfaktor unterhalb von k befindet. Dieses Entscheidungsproblem ändert am oben skizzierten Algorithmus die Laufzeit nur um einen konstanten Faktor, welche in der polynomiellen Unschärfe sowieso verschwindet. Wir sind inder Lage, wie in der nächsten Abbildung zu sehen, mittels einer binären Suche den Primfaktor exakt zu bestimmen:


Binäre Suche nach dem Primfaktor

Können wir also das Entscheidungsproblem (1) als Orakel verwenden, so lässt sich auch dieses Optimierungsproblem (2) sehr effizient (logarithmisch) lösen. Die binäre Suche geht in der polynomiellen Unschärfe verloren, womit wir informell bewiesen haben: bei P=NP liegt die Faktorisierung auch in P.

Welche Auswirkungen hätte P=NP auf den Alltag? Diese Frage lässt sich leider nicht beantworten, da nicht jeder Algorithmus in P auch effizient ist. Wäre der Exponent jedoch niedrig, wären die Folgen schwerwiegend: die PKI würde zusammenbrechen, wodurch sicheres Online Banking unmöglich wäre. Jedes asymmetrische und damit auch jedes hybride Verschlüsselungssystem wäre hinfällig. Die Quantenkryptographie, die hiervon nicht betroffen wäre, liefert keinen adäquaten Ersatz.

Hoffen wir also, dass P != NP gilt.

Peer to Peer – Sicherheit

Hallo zusammen,

vor Kurzem ist in einem Spieleforum die Frage aufgekommen, wie es mit der Sicherheit von Peer-to-Peer Systemen aussieht. Vermutlich werden jetzt viele Leser an die juristischen Folgen durch, populär ausgedrückt, „illegale Downloads“ denken. Damit soll sich dieser Beitrag allerdings nicht befassen. Außerdem muss auch die Frage geklärt werden, wieso sich ein „Spieler“, eine möglicherweise leicht Klieschee behaftete Gruppe, dafür interessiert.

Insbesondere MMORPGs zeichnen sich durch einen sehr dynamischen Inhalt aus, was für viele einen Reiz darstellt, eine beachtliche Menge an Zeit zu investieren. Dies erfordert jedoch einen permanenten Aktualisierungsvorgang aller Clients. Viele „Kleinigkeiten“, wie Art/Position/Verhalten von s.g. NPCs können durchaus „on the fly“ dem Spieler mitgeteilt werden. Umfangreichere Änderungen, insbesondere neue Grafiken, erfordern jedoch eine Änderung des Programms bzw. der verwendeten Bibliotheken. Hiervon soll allerdings der Spieler möglichst wenig betroffen sein – insbesondere soll er nicht gezwungen sein auf dubiosen Webseiten die Patches zu laden und dann auf dem jeweiligen Rechner zu installieren. Jedoch ein Client-Server Modell, bei dem ein Server die Daten für alle Clients bereitstellt, ist nur für geringe Benutzerzahlen praktikabel. So bedeutet ein 100 MB Update, was durchaus nicht selten ist, bei 100.000 Spielern nunmal 10.000.000 MB Traffic, also 10 TB. An dieser Stelle sei noch anzumerken, dass es durchaus Spiele mit 5-10 Millionen aktiven Spieler gibt. Außerdem besteht ein betriebswirtschaftliches Interesse, die Kosten solcher Prozesse möglichst gering zu halten.

Was also tun? Das Thema liefert die Antwort: Peer to Peer Netzwerke, kurz P2P. Wie funktioniert das?
Nunja, viele leichtverständliche Informationen findet man auf einschlägigen Webseiten. Ich möchte an dieser Stelle insbesondere auf das P2P Netz eingehen, welches überwiegend beim Filesharing eingesetzt wird. Auch wenn „Filesharing“, „Peer to Peer“, etc. vielen Lesern die roten Alarmglocken schlagen lässt: es ist eine Technik, die von vielen Unternehmen eingesetzt wird und daran ist überhaupt nichts Illegal. Sie eignet sich allerdings auch zum Tausch von geschütztem Material wodurch sie häufig in einen falschen Zusammenhang gesetzt wird. Um dieses System in kurzen Worten zu erklären, möchte ich mich der Schneeball-Metapher bedienen:

Durch umfangreiche Aufklärungsarbeit der öffentlich rechtlichen Funk und Fernsehanstalten sollte vielen Lesern bekannt sein, wie ein Schneeballsystem (oder ein Kettenbrief) funktioniert. Wir definieren eine Person, die ein Produkt an eine Reihe von Personen anbietet und nennen diesen Tracker. Diese Reihe von Personen bemühen sich, aus eigenem Interesse, möglichst viele weitere Personen für dieses Produkt zu gewinnen. Wir bezeichnen alle Personen, die daran interessiert sind, als Schwarm. Angenommen jeder Teilnehmer gibt das Produkt (oder die Information) nur an zwei Andere weiter, haben wir nach 30 Schritten schon eine Schwarmgröße von 1.073.741.823 (2^30-1). Der Aufwand für den Einzelnen, 2 weitere zu „finden“ bzw. zu bedienen, war relativ gering – in der Gesamtheit war das Produkt jedoch ein riesen Erfolg.

Als Informatiker möchte ich jedoch an dieser Stelle anmerken, dass es sich hierbei um einen Baum der Ordnung 2 handelt – hingegen ein P2P System als ein Multigraph anzusehen ist. Übertragen auf das „Updateproblem“: der Tracker wirft den Patch also in die Menge (den Schwarm) und die Spieler organisieren sich untereinander diesen zu verteilen. Also läd man, bei diesem Vorgang, nicht vom offiziellen Server, sondern von Personen „wie dich und mich“ – jedoch natürlich nur von den Beteiligten.

Nun zurück zu dem besorgten Spieler. Grundsätzlich handelt es sich hierbei auch um Programmaktualisierungen. D.h. der Programmcode wird entweder ersetzt oder Neuer wird eingefügt – je nach Updatestrategie. Ein Beweis hierfür ist auch leicht erbracht: Updater sind immer „extra“ Programme, also kein Unterprozess. So findet sich in dem entsprechenden Spielordner stets das Spiel selbst, als auch ein Updater als ausführbare (exe) Datei.

Und daher nun endlich die Frage: Können mir andere Spieler „Schadcode“ übergeben, der sich dann, durch den Updatevorgang, auf meinem Rechner befindet?

Damit habe ich mich etwas Näher befasst. Zunächst muss natürlich klar sein, dass diese Frage nicht für alle Spiele geklärt werden kann. Grundsätzlich werden Daten von unbekannten Quellen geladen und diese können durchaus Fehlerhaft sein – gewollt oder ungewollt. Das ist die schlechte Nachricht. Die Gute ist, dass sich viele Spielebetreiber Techniken bedienen, die sich mittlerweile als Standard etabliert haben. Das relativ bekannte „BitTorrent“ Protokoll ist eines dieser – wofür es auch sehr viele und gute Clients gibt. Bei dieser Technik erhält der Client ein File genannt „Torrentfile“. Dieses enthält eine Auflistung der Dateien, die geladen und verteilt werden müssen – zusätzlich weitere triviale Informationen.
Am Ende, das lässt uns wieder aufatmen, ein SHA-1 Hash für jeden Part. Wer mag, kann an dieser Stelle einen Exkurs zum aktuellen Stand der Technik bzgl. der Sicherheit des SHA-1 unternehmen.

~

Wieder zurück? Gut. Denn selbst wenn wir ein Programm hätten, das uns „günstig“ Kollisionen des SHA1 aufzeigt, wäre es sehr unwahrscheinlich, dass dabei ein Teil eines ausfühbaren Programmes herauskommt und gleichzeitig auch den gewollten Schadcode enthält. Diese Thematik lässt sicherlich Platz für Diskussionen – allerdings kann an dieser Stelle und an diesem Tag festgehalten werden, dass der SHA-1 Hashalgorithmus für diesen Einsatzzweck noch völlig genügt. Was ein Hashcode „genau“ ist, habe ich in diesem Beitrag beschrieben: http://cryptblog.de/2008/06/18/hacken-fur-anfanger/

Es besteht also keinen Anlass zur Beunruhigung. Sofern der Tracker das Torrentfile korrekt an den Benutzer überträgt, ist ein P2P System (basierend auf BitTorrent), für diesen Einsatzzweck ausreichend sicher.

Zufällige Entscheidungen

Hallo zusammen,

vor kurzem hatten ein Kommilitone und ich ein Problem. Wir wollten (über das Internet) ausknobeln, wer von uns mit dem Auto fahren muss und wer dafür Alkohol trinken kann. Ein Schnick-Schnack-Schnuck über das Internet sozusagen. Beide hatten wir nach einer Lösung für dieses Problem gesucht jedoch keine wirklich gute gefunden. Zuletzt entschieden wir uns dazu, es über die Anzahl der Heise.de-News des nächsten Tages zu bestimmen. Je nachdem ob es eine gerade oder ungerade Anzahl ist, muss der eine oder der andere.

Die Frage ist also, ob es dafür bessere Lösungen gibt. Mit Hilfe einer dritten, unabhängigen Instanz sollte dies nicht so schwierig sein, einige Lösungsbeispiele habe ich dafür mal ausgearbeitet:

Beide Parteien könnten mit einem Client auf einen Server verbinden. Sobald alle verbunden sind, gibt dieser eine zufällige Zahl aus. So hat man, synchronisiert, allen Teilnehmern dieses Ereignis zugänglich gemacht.

Oder man könnte eine Webseite bereitstellen, die alle 5 Minuten eine zufällige Zahl ausgibt. So könnten beide Parteien Vermutungen über die nächste Ausgabe treffen und diesbezüglich eine Entscheidung finden. Um dieses Beispiel zu verdeutlichen habe ich diese Webseite angefertigt: http://www.cryptblog.de/random.php.

Eine weitere Möglichkeit wären Kryptogramme eines Servers: Partei A bezieht ein aktuelles Kryptogramm von einem Server, welches eine verschlüsselte Zahl enthält. Er übergibt das Kryptogramm der Partei B und beide einigen sich darauf, welche Entscheidung bei einer geraden/ungeraden getroffen wird. Die Entschlüsselung ist allerdings erst später (~5 Minuten) möglich. Ich denke allerdings, dass diese Lösung unnötig kompliziert ist und kaum einen Vorteil gegenüber den anderen besitzt.

Aber nun die Frage: ist es möglich eine solche Entscheidung zu treffen, ohne dass ein Dritter (Server) beteiligt ist? Meine Antwort darauf ist JA. Folgendes Verfahren habe ich mir überlegt:

Sowohl A, als auch B, denken sich eine möglichst große zufällige Zahl (a und b) aus. Mit Hilfe einer Webseite, die hier lediglich als „Taschenrechner“ dient, berechnen A und B jeweils einen Hash (Fingerabdruck, beispielsweise MD5) ihrer Zahl, also z.B. H(a) und H(b). Über ein beliebiges Kommunikationsmedium kann nun dieser Hashwert ausgetauscht werden. Außerdem müssen sich A und B jeweils für eine gerade oder ungerade Zahl entscheiden. Durch diesen Austausch, haben sich beide auch damit einverstanden erklärt, dieses Verfahren zu nutzen. Nachdem also Hashwerte ausgetauscht sind, ist jeder im Besitz seiner eigenen Zahl und einem Fingerabdruck der Zahl des anderen.

Jetzt kann jeder seine Zahl dem anderen nennen, ob nun A oder B zuerst ist egal. Beide Zahlen werden miteinander addiert, also m = a + b berechnet, und je nachdem ob diese Zahl gerade oder ungerade ist, fällt die Entscheidung für A oder B aus. Aufgrund des vorherigen Austausch der Hashwerte, ist ein nachträgliches ändern der Zahl nicht möglich bzw. A und B können die Aussagen des anderen verifizieren.

Um dieses Beispiel zu verdeutlichen, existiert eine neue Sektion und ein Script um die Durchführung zu vereinfachen: http://cryptblog.de/muenzwurf/.

Nochmal grob zusammengefasst:

zufallprotokoll
A prüft H(b)=H(b‘), B prüft H(a)=H(a‘). Sofern beides wahr, kann von a’=a und b’=b ausgegangen werden.
Beide berechnen m = a+b.

Mittels diesem Protokoll hat jeder Teilnehmer eine 50% Chance zu gewinnen:

geradeungerade

In der Anwendung ist folgendes zu beachten:

Die Hashfunktion sollte einigermaßen sicher sein und um Rainbowtables entgegenzuwirken, sollten die Zahlen möglichst groß sein. Sofern dies erfüllt ist, können auch JavaScript Lösungen zum berechnen verwendet werden, wie z.B. http://aktuell.de.selfhtml.org/artikel/javascript/md5/ .

Nachtrag:
Grundsätzlich kann man dieses System auch, leicht modifiziert, für das bekannte Stein-Schere-Papier einsetzen, indem ein Hash von Stein|Zufallszahl, Schere|Zufallszahl oder Papier|Zufallszahl gebildet und später ausgetauscht wird. Das macht die vorherige Absprache ob gerade oder ungerade unnötig.

ITS-Quiz für Zwischendurch

Hallo,

es handelt es sich um Protokollsicherheit in Verbindung mit asymmetrischer Verschlüsselung. In diesem Szenario möchte die Partei A eine geheime Information an Partei B senden. A besitzt den geheimen Schlüssel zum öffentlichen Schlüssel PK_A, und B äquivalent PK_B. Hierbei wird folgendes Protokoll verwendet:

(1) A –> B:     (A, E(PK_B, A|M), B)
(2) B –> A:     (B, E(PK_A, A|M), A)

also: (Absender, Nachricht, Empfänger) wobei Nachricht = Absender|Information.

Schritt für Schritt: A sendet an B eine Nachricht, diese besteht aus

  • dem Absender (A),
  • dem asymmetrisch verschlüsselten Text M wobei dieser noch mit  und dem Absender verbunden wurde (A|M),
  • dem Empfänger (B).

daraufhin bestätigt B den Erhalt der Nachricht durch:

  • den Empfänger (B),
  • die exakt identische Nachricht, diesmal allerdings mit dem öffentlichen Schlüssel des ursprünglichen Absenders – also des neuen Empfängers (PK_A) verschlüsselt,
  • den Absender der usprünglichen Nachricht (A).

E(PK_X, M) ist die asymmetrische Verschlüsselung, z.B. RSA, mit Hilfe des öffentlichen Schlüssels X, im obrigen Beispiel also jeweils des Empfängers. Das Ganze etwas anders ausgedrückt: Die Partei A sendet eine Nachricht an B, wobei diese mit dem öffentlichen Schlüssel des Empfängers verschlüsselt wurde und außerdem auch den Absender enthält.

Im Zuge einer Umstellung wurde das Protokoll abgeändert auf:

A –> B:     (A, E(PK_B, M), B)
B –> A:     (B, E(PK_A, M), A)  (Bestätigung)

Der Unterschied: der Absender ist hier nun nicht mehr innerhalb der verschlüsselten Nachricht enthalten.

Frage: ergibt sich daraus ein Problem? Wo ist der Unterschied bzw. gibt es überhaupt einen?

Auflösung Februar

Hallo liebe Gemeinde,

eine Vermutung wurde ja geäußert (siehe Kommentare). Dieser geht in die Richtung, den Klartext mit einem zufälligen Schlüssel zu chiffrieren und diesen wiederrum mit dem geheimen (ausgetauschten) zu verschlüsseln und an die Nachricht anzuhängen. Also: [E_tempkey(Text) | E_key(tempkey)]. Also ein ähnliches System wie bei den DLC-Containern.

Die Idee ist natürlich nicht schlecht, allerdings handelt es sich hierbei um etwas anderes. Und zwar gibt es in der Praxis verschiedene Betriebsmodi; um einige zu nennen: ECB, OFB, CFB. Und an dieser Stelle wurde der CBC „Cipher Block Chaining“ Modus verwendet. Was dies nun genau bedeutet ist etwas schwierig zu eklären, daher beschränke ich mich an dieser Stelle darauf den Unterschied zwischen dem simpelsten (ECB) darzustellen.

Beim ECB-Modus wird der Klartext in gleiche Stücke getrennt. Im Beitrag zur Bildverschlüsselung (http://cryptblog.de/2008/10/06/bildverschlusselung/) hatte ich dieses Verfahren bereits erläutert. Dort wurde

“Hallo, wie geht es dir  ”

in:

“Hallo, w”, “ie geht “, “es dir  ”

aufgeteilt. Jeder dieser Blöcke wird mit dem gleichen Key verschlüsselt und so erhalten wir am Ende wieder 3 Blöcke. Beispielhaft dargestellt:

“mdjwbcxg”, “ötüeoejd”, “ndkrdkdp”.

Angenommen ich ändere das „Hallo“ im Klartext in ein „Hello“, so würde sich nur der erste Block ändern, die anderen zwei blieben unberührt. Und um diesen Einfluss zu vergrößern gibt es die oben genannten Betriebsmodi. Ein Bild dazu aus Wikipedia zum CBC-Modus:

 cbc_encryption

Zunächst schwierig zu verstehen. Auf der linken Seite haben wir den sehr bekannten Initialisierungsvektor. Bei der Blowfish-Implementierung wird dieser einfach zufällig gewählt. Er wird mit dem Klartext verrechnet (XOR). Das Ergebnis daraus, wird verschlüsselt und ergibt den Chiffretext welches wiederrum auf den nächsten Klartextblock Einfluss nimmt. Durch diese Pfeile ist also zu sehen, dass der Vorgänger immer auf den unmittelbaren Nachfolger einwirkt.

Dadurch ergibt sich eine Kette: wird am Anfang eine Veränderung vorgenommen, ändert dies den kompletten restlichen Chiffretext. Und da, wie schon erwähnt, der IV gewürfelt wird, ergibt sich bei jeder Verschlüsselung einen anderen Chiffretext. Zur Entschlüsselung wird allerdings dieser Vektor benötigt, daher wird er einfach mitgeschickt. Aus dem Plaintext P wird also nicht nur ein Chiffretext C, sondern beinhaltet auch einen IV.

Verstanden sollte sein, dass diese „Block für Block“-Verschlüsselung Probleme bereiten kann und ein Betriebsmodus, wie der CBC, für noch mehr Einflussnahme des Klartextes sorgt.

Frage des Monats (Februar)

Nicht grade traditionsgemäß, aber um mal Abwechslung in den Cryptblog Alltag zu bringen.

Wir betrachten folgende Internetseite:
http://www.php-einfach.de/sonstiges_generator_blowfish_js.php

Der angezeigte Key wird zufällig ausgewürfelt und kann ähnlich wie der Klartext geändert werden, muss aber nicht. Danach besteht die Möglichkeit, die Eingabe zu verschlüsseln, worauf eine Ausgabe des verschlüsselten Textes im Base64 erfolgt. Mal als Eingabebeispiel:

Key: tsu15bdi
Klartext: test

Und nun? Jetzt kann mit dem „Verschlüsseln“-Button chiffriert werden. Um dies hier alles nachvollziehen zu können, sollte dies nun jeder einmal durchführen. Nun kommt das große „Problem“. Mit den oben genannten Daten ergibt sich:

AAtRZQALh6Bkp67o8pNUbg==

Wenn ich aber mehrmals den Button betätige, entsteht immer wieder etwas anderes:

AAUYzgALLpTtP2+zdG0O4A==
AAD+sgAJaAF/3D3mdFxHWw==
AA874gALmyCaU23yyjVKcQ==
AAHn2gAKE4mfFu4zg/muTQ==

Und es handelt sich dort jeweils um „test“. Jeder dieser Ergebnisse kann mit dem oben genannten Passwort auch wieder nach „test“ dechiffriert werden. Genaugenommen zu

„test    „

was 8 Zeichen mit jeweils 16 Bit = 128 Bit (Blockgröße) entspricht, dies allerdings nur am Rande.

Normalerweise geht man davon aus, das ein fester Klartext P mit dem festen Schlüssel K nur EIN eindeutiges Ergebnis zurückliefert, um das Entschlüsseln bzw. die Umkehrbarkeit eben möglich ist. Bei der einfachen (additiven) Cäsar Verschiebechiffre ist das ja ähnlich (Schlüssel 2):

A -> C
B -> D
C -> E

etc.

Das oben gezeigte verhält sich also so, als würde A (nach Verschlüsselung) sowohl zu C als auch zu D und E verschlüsselt werden. Und dies jeweils zufällig.

Frage: Wieso ist hier eine eindeutige Entschlüsselung möglich?

DLC-Container

Zur Abwechslung mal wieder etwas aus der Praxis. Heute geht es um die mittlerweile verbreiteten DLC-Container. Für die Leute, die damit nichts anfangen können, zunächst eine Zusammenfassung.

Dieses System wurde entwickelt, um Links zu verschlüsseln bzw zu verdecken. Die Benutzer sollen fähig sein, Daten von Servern herunter zu laden, ohne sehen zu können wo diese nun genau liegen. Also eine Containerdatei die Text (Linklisten) enthält, aber nicht von dem Benutzer – zumindest nicht auf einfache Art und Weise – eingesehen werden soll. Der Sinn bzw. Zeck kann von jedem selbst nachgeforscht werden.

Etwas nicht sehen dürfen? Also eine Verschlüsselung. Die Frage ist allerdings, wie hält man etwas vor dem Benutzer geheim, welcher den Inhalt allerdings selbst benötigt. Kurz gesagt: das geht natürlich in der elektronischen Welt nicht. Es ist z.B. durch einen modifizierten Proxy oder das Mitschneiden des Netzwerkverkehrs trotzdem möglich die Links zu erhalten. Die Frage, die allerdings nun hier beantwortet werden soll: „ergibt das Ganze dann noch Sinn?“. Und die Antwort darauf ist erstaunlicherweise: Ja.

Zunächst wollen wir uns Schritt für Schritt dem System nähern. An dieser Stelle muss ich sagen, das obwohl dieses eigentlich Open Source und „Dokumentiert“ ist, es keine wirklich brauchbaren Informationen darüber gibt wie es umgesetzt wurde. Wahrscheinlich um zu verhindern das jemand Schwachstellen findet, wie es bei ähnlichen Systemen geschehen ist. So musste ich ziemlich alles selbst erarbeiten, allerdings denke ich, das meine Argumentation schlüssig ist.

Zuerst war das Wort.. oder die Datei. In diesem Fall der DLC-Container, welchen ich über ein Webinterface der Herstellerseite erstellt habe. Im Cryptool betrachte ich den Inhalt:

dlcbase641

Nun, dies ist offensichtlich kodiert. Ja – kodiert und nein, das ist (bisher) keine Verschlüsselung. Es handelt sich um die Base64 Kodierung, welche häufig in Protokollen oder beim Übertragen chiffrierter Daten verwendet wird. Informationen darüber finden sich an jeder Ecke; an dieser Stelle genügt es zu sagen, das wir diese verlustfrei dekodieren können:

dlcclear1

Auf den ersten Blick sieht es tatsächlich so aus, als ob es uns nichts Neues gebracht hätte.  Dann betrachten wir das Ende dieser Datei etwas genauer:

dlcclearend

Was ist hier zu sehen? Zunächst unlesbarer Text bei welchem es sich offensichtlich um verschlüsselten Inhalt handelt, dann ein Nullbyte (0000 0000), und dann, sehr unerwartet, erneut ein Base64. Dieser kann nun erneut dekodiert werden, wobei sich daraus (ähnlich wie oben) lediglich unlesbarer Inhalt ergibt.

Was ist das alles nun? Naja, im oberen Teil befinden sich offensichtlich die Hauptinformationen. Wie eine Signatur liegt dort nun eingebettet eine Zeichenkette, die Besonders zu sein scheint. Nun ist die Frage was man damit machen kann. Zuerst war die Vermutung das es sich dabei um ein asymmetrisch verschlüsseltes Passwort handelt. Allerdings müssten dann die Informationen zum dechiffrieren hartkodiert im Quelltext vorliegen womit das System (insbesondere bei einer Java Anwendung) sehr schnell geknackt wäre.

Nach längerem überlegen kam ich zu dem Entschluss, das es also nur 2 Möglichkeiten gibt: die Sache ist einfach nur sehr oberflächlich und daher „simpel“, oder wirklich clever. Vorweg, ich musste erfahren das letzteres zutrifft.

Um diesem Problem nun gegenüber zu treten, habe ich den verursachten Traffic der Anwendung mitgeschnitten: also mir angeschaut was das Programm von meinem Computer aus ins Internet sendet. Und siehe da, dort war die Lösung. Und zwar gibt es beim Verarbeiten der DLC-Datei einen Datenaustausch zwischen einem Server und der Anwendung. Zuerst schickt das Programm eine Anfrage an den Server, welcher wiederrum antwortet. Und was dort uA gesendet wird ist hier zu sehen:

etherreal

Erneut wird im Base64 eine Zeichenkette über den Äther geschickt. An dieser Stelle war ich der Verzweiflung nahe, da es sich hierbei erneut um einen String handelt, den ich vorher noch nicht gesehen hatte. Wieder stand ich vor einem Problem, dessen Lösung allerdings recht einfach war:

mitschnittbase641

Und zwar ist das die Base64 Zeichenkette aus der DLC-Datei, erneut in einen Base64 eingepackt. Dies ergibt eigentlich keinen Sinn und scheint eher ein „Fehler“ zu sein bzw. Faulheit der Programmierer. Egal, es ist nun nachgewiesen das diese „besondere“ Signatur zum Server gesendet wird. Nach dieser Anfrage, antwortet der Server mit einer Base64 Zeichenkette (FVZ+8D1u+4Tey+5pSkwNP+SgUTaGXGlRt8kMywjdEkM=), die ich schonmal für uns im Cryptool ausgepackt habe:

passwort

Damit ist der Beweis erbracht. In der Datei ist eine Zeichkette enthalten, die nur vom Server entschlüsselt werden kann und das Passwort enthält, mit welchem die Datei vom Programm nutzbar gemacht werden kann. Wieso? Nunja, wir betrachten das letzte Bild, also die Antwort vom Server nach unserer Anfrage. Es handelt sich dabei um ganz exakt 256 Bit. Die typische Länge für z.B. einen AES256. Es kann an dieser Stelle kein asymmetrischen Verfahren verwendet worden sein, da dieses niemals unter 1024 Bit lang wäre. Es ist also sehr wahrscheinlich das hier der Schlüssel dirkt oder zumindest teilweise enthalten ist.

Nach dem was hier zu sehen war, funktioniert das System meiner Meinung nach so: möchte der Benutzer eine DLC-Datei auswerten, läd er diese in das entsprechende Programm. Da der Inhalt verschlüsselt ist, kann die Anwendung damit zunächst nichts anfangen. Innerhalb der Datei befindet sich allerdings das (verschlüsselte) Passwort zum entschlüsseln der Daten, welches jedoch nur vom Betreiber entschlüsselt werden kann. Die Applikation sendet also dieses verschlüsselte Passwort zum DLC-Server, welches die entschlüsselte Version zurückliefert. Damit kann der Inhalt dechiffriert werden kann. Nochmal zusammengefasst:

  1. das Öffnen der DLC-Datei mit dem Programm,
  2. die Anwendung sendet das verschlüsselte Passwort zum Server des Betreibers,
  3. der Betreiber dechiffriert dieses und sendet das entschlüsselte Passwort zurück,
  4. mit diesem Passwort kann der Inhalt dechiffriert werden und die Links „liegen offen“.

Wofür das Ganze? Der Betreiber kann auf diese Art und Weise kontrollieren, wer (von welcher IP-Adresse) wie häufig eine Datei entschlüsseln möchte. Der Sinn ist zu verhindern, das jemand große Mengen dieser Container entschlüsselt und damit die Links alle freilegt. Ohne Zusammenarbeit mit dem Server ist das entschlüsseln dieser Dateien bzw.der dort enthaltenen Links nicht möglich.

Insgesamt halte ich dieses System für ganz gelungen. Unter Umständen werde ich in einem separaten Eintrag noch einige Anmerkungen dazu machen.

Kaskadierung

Als Kaskadierung wird das Hintereinanderschalten mehrerer Systeme, in diesem Fall Kryptoalgorithmen, bezeichnet. Ein Beispiel:

AES(3DES(Blowfish(„Hallo“,key1),key2),key3)

Wobei key1 != key2 != key3 ist. Der erste Parameter ist der zu verschlüsselnde Text, der zweite der Schlüssel.

Das bemerkenswerte an diesem Beispiel ist, das der 3Des (Tripple-DES) schon in sich aus einer Kaskadierung von drei DES Algorithmen besteht:

3DES = DES(DES(DES(text,key1),key2),key3)

Allerdings ist hier zu bemerken, das der mittlere Baustein eine Entschlüsselung ist. Der 3DES arbeitet nämlich üblicherweise im EDE-Modus: encryption – decryption – encryption.

Wieso? Nunja, der DES hat eine effektive Schlüssellänge von 56 Bit und diese wurde durch das Verwenden von drei unabhängiger Schlüssel auf 168 Bit vergrößert.

Die große Frage ist nun: ist das Brechen einer kaskadierten Verschlüsselung schwieriger, als das einer einzelnen. Die Antwort ist simpel: JAIN.

Ein Beispiel: Wir definieren eine Verschlüsselung E und E‘ wobei E‘ = E^-1 also: E‘ ist die inverse von E. Wir verschlüsseln im ECB Modus, B entspricht dem ersten Block:

E'(E(B,key1),key1) = B

Wir erhalten also nun nach dieser doppelten Verschlüsselung, den Ausgangsblock. Nun würde jeder dagegen halten, das bei einer Kaskadierung unabhänige Schlüssel verwendet werden. Das ist richtig. aber es gibt noch andere Probleme. Z.B. nehmen wir eine additive Chiffre, dann verschlüsselt wir mit:

c = (p+k) mod m

Das p entspricht dem Plaintextzeichen, das k dem Schlüssel und das m der Länge des Alphabets. Nun kaskadieren wir diese Chiffre:

c = (((p+k1) mod m) + k2) mod m

an dieser Stelle darf das innere „mod m“ entfernt werden, ohne das sich dabei die Gleichung ändert:

c = (p+k1+k2) mod m

Und nun definieren wir ein k=(k1+k2):

c= (p+k) mod m

Wer hat’s gemerkt? Es handelt sich dabei um die ursprüngliche additive Chiffre. Wir haben also an dieser Stelle nichts gewonnen. Das liegt daran, das hier „Strukturgleichheit“ herrscht. Die Kaskadierung der gleichen Chiffre führt unter Umständen also nur dazu, das der Schlüssel sich ändert.

So ganz genau weiß man nicht, ob es sinnvoll ist, zwei konkrete Chiffren zu kaskadieren. Es könnte sich herausstellen, das es einfacher ist ein AES+Blowfish zu entschlüsseln, als lediglich ein AES, wenn sich der Blowfish invers verhält. Zugegeben, ist dies sehr unwahrscheinlich, aber nicht unmöglich.

Im Allgemeinen sagt man, das die Kaskadierung mindestens so sicher ist, wie die erste Chiffre der Kette. Es ist sehr wahrscheinlich das eine Kaskadierung mit verschiedenen Schlüsseln eine größere Sicherheit bietet, es ist allerdings nicht bewiesen.

Cryptool

Jajaja ich weiß, es wäre mal wieder Zeit für etwas Neues. Und ich verspreche auch innerhalb der nächsten Zeit noch etwas Interessantes zu berichten. Zwischendurch jedoch, wie bei Privatanbietern üblich, etwas Werbung.

Und zwar bin ich auf folgende Webseite gestoßen: http://www.cryptool.de/

Was ist das? Das wusste ich zunächst auch nicht; der Name verspricht jedoch viel. Also habe ich es mir genauer angeschaut und wurde nicht enttäucht. Hierbei beziehe ich mich auf die aktuelle stable Version 1.4.21. Selbiges wird zunächst installiert und nach dem Start fühlt man sich leicht in das Jahr 1999 zurück versetzt. Aber hier geht es ja nicht um Design, sondern um die Technik bzw. die Möglichkeiten dahinter und die sind sehr erstaunlich. Es erscheint ein Textfenster mit einem Willkommenstext. Seinen angeborenen Instinkt diesen möglichst schnell zu schließen sollte man an dieser Stelle unterdrücken, denn mit wenigen Handgriffen im Menü können wir daraus beachtliches zaubern. Ein Beispiel: wir wählen eine klassische symmetrische Chiffre, den Caesar (sollte mittlerweile bekannt sein), woraufhin sich ein Dialog mit weiteren Eingabemöglichkeiten öffnet. Hier lässt sich nun das Delta, also der Schlüssel, wählen. Wahlweise auch ROT13 was nunmal nichts anderes als ein Caesar mit Schlüssel 13 auf einem 26 stelligen Alphabet ist. Sobald die Konfiguration abgeschlossen ist, öffnet sich neben dem Willkommenstext ein zweites Fenster mit dem gewünschten verschlüsselten Inhalt.

Aber dem ist nicht genug. Wir können mit sehr wenig Aufwand auch moderne Chiffren wie z.B. den AES oder eine Hashfunktion z.B. MD5 wählen. Es ist auch möglich den Text mit einem Eigenen oder neu erstellten Zertifikat zu signieren. Es enthält auch viele kleine Demos, um die Funktionsweise einiger Verfahren zu verdeutlichen. Allerdings gibt es bei der modernen Kryptographie eben die Grundsätze der guten Diffusion und Konfusion. Letzteres zeigt sich nunmal auch bei der besten Demo.

Alles in allem sehr viele Möglichkeiten, also schaut es euch mal an.

Zur 2.0 Beta des Tools: wer hier nur hübchere Bedienoberflächen erwartet, irrt sich gewaltig. Natürlich wurde auch daran gearbeitet, allerdings handelt es sich hierbei (im Gegensatz zum Vorgänger) um einen Kryptobaukasten. Um die oben geschilderte Caesar-Verschlüsselung auch hier zu wiederholen, muss objektorientiert vorgegangen werden. Man nehme:

  • 1 Textbaustein zur Dateneingabe
  • 1 Baustein „Caesar“
  • 1 Textbaustein zur Datenausgabe bzw. Anzeige

Diese werden in geeigneter Weise verbunden und erhält das gleiche Ergebnis wie oben geschildert. Nun wird wohl sicherlich der Einwand kommen, das dies ziemlich kompliziert ist… und dieser ist auch berechtigt. Allerdings lasses sich hierdurch sehr komplexe Mechanismen erstellen und analysieren. Es ist ein mächtiges Tool und wie alle Werkzeuge dieser Art nunmal etwas unhandlich für die kleinen Dinge.

Zum professionellen Arbeiten, ist die 2.0 der alten Version weit überlegen, auch wenn einige Funktionen noch nicht fertiggestellt sind. Auch sehr empfehlenswert.