Archiv des Autors: Tim

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?

Neueröffnung nach Umzug

Hallo,

in verändertem Design, auf einem eigenen Server und mit eigener Domain präsentiert sich der cryptblog von Neuem. Innerhalb der nächsten Tage werde ich hier noch einige kleine Änderungen vornehmen, die wichtigsten Arbeiten sind allerdings erledigt.

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.

Bildverschlüsselung

Dies ist der (bisher) aufwändigste Eintrag.

Nachdem ich einen Interessanten Artikel [1] gelesen hatte, wusste ich direkt das es ein gutes Thema für den cryptblog ist. Und zwar geht es um Probleme beim Verschlüsseln von Bildern.

Zuerst jedoch noch eine wichtige Grundlage: bei Kryptosystemen gibt es verschiedene Betriebsmodi, die bekannteste ist der ECB-Mode (Electronic Code Book). Es ist ja in der Regel so, das nicht nur lediglich 128 Bit verschlüsselt werden sollen, sondern Gigabyte an Daten. Dafür wird dieser große Haufen bei Blockchiffren entsprechend aufgeteilt in kleinere. Ein Beispiel:

„Hallo, wie geht es dir  “ wird (sofern 1 Zeichen = 16 Bit) in:

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

aufgeteilt. Wie man sieht wurde hier der letzte String aufgefüllt damit er ein Vielfaches von 8 entspricht. Dies ist auch in der Praxis üblich.  Wir besitzen also am Ende eine große Liste von 128-Bit blöcken welche nacheinander ins Kryptosystem eingespeist und damit verschlüsselt werden. Heraus kommt z.B:

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

Das Problem bei diesem Modus ist, das gleicher Klartext auch in den gleichen Chiffretext verschlüsselt wird. D.h. wenn ich „12345678“ an 2 unterschiedlichen Stellen im Text verschlüssele, würde auch jeweils die gleiche Verschlüsselung entstehen.

aus: „Hallo, wie geht es dir Hallo, wie geht es dir “ wird also:
mdjwbcxgötüeoejdndkrdkdpmdjwbcxgötüeoejdndkrdkdp„.

Und das ist ein Problem bei Bildern, denn dort finden sich an vielen Stellen gleiche/ähnliche Werte. An dieser Stelle ein Beispiel mit zwei 2×2 Pixel Bildern:

rechteck1 rechteck2

Sei also links unser Klartext (das normale Bild) und rechts der Chiffretext (die Verschlüsselung). Aus dem schwarz und dem dunkelgrau werden jeweils gelb und grün. Jedoch diese zwei silbergrauen Flächen werden identisch verschlüsselt (blau). Dies wäre natürlich nur der Fall wenn die Chiffre nur eine 32 Bit Blockgröße hätte (Rot, Grün, Blau, Alpha), jedoch bleibt das Problem bei 128 Bit ebenso: gleiche Flächen werden gleich verschlüsselt und dies ist vorallem bei kontrastreichen und großen Bildern durch wiederholende Muster zu sehen.

Da mir das jedoch noch nicht genügte, habe ich ein Programm gebaut, welches die Bilder mit Blowfish (24 lässt grüßen) im ECB Modus verschlüsselt.

cryptbild221

Oben zu sehen das Originalbild, unten jeweils die Verschlüsselungen mit zwei unterschiedlichen Passwörtern. Hier ist das Problem deutlich zu erkennen: im vertikalen Bereich sind die Farbcodes jeweils identisch. Die kleinen Ungenauigkeiten stammen wahrscheinlich aus der JPG Komprimierung.

Zuletzt das ganze auch mal mit einem richtigen Bild. An dieser Stelle danke ich Tobias Gräber für die Bereitstellung:

cryptbild11

Besonders gut zu erkennen ist das Geländer an der rechten Seite. Auch einige Konturen finden sich in der verschlüsselten Version wieder.

Abschließend lässt sich also sagen, das eine Verschlüsselung alleine nicht immer genügt. Die Verschlüsselung und dessen Modus muss auch zum Einsatzzweck passen.

Quellen:
[1] http://www.turbocrypt.com/eng/content/TurboCrypt/Backup-Attack.html

24 (twenty four)

Nachdem ich nun in den letzten Wochen Staffelweise 24 geschaut habe, will ich einige Aussagen (die ich so gehört habe) kommentieren.

„das ist Blowfish verschlüsselt, das erkennt man am Header.“

Klingt gut, ist aber Unsinn. Eine verschlüsselte Datei bzw. ein verschlüsselter Container besitzt keinen besonderen Header. Natürlich könnte man dem zurecht entgegenhalten das dies Anwendungsspezifisch ist. Jedoch wo liegt der Sinn einem Angreifer schon vor Eingabe des Passworts den Algorithmus zu verraten (lassen wir Kerkhoff außen vor).  Sofern kein besonderer Verschlüsselungsalgorithmus ausgewählt ist, führen Programme „Probeentschlüsselungen“ durch und prüfen auf Plausibilität. 

Decryption is considered successful if the first 4 bytes of the decrypted data contain the ASCII string “TRUE“, and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the decrypted data (this value is unknown to an adversary because it is encrypted – see the section Header Key Derivation, Salt, and Iteration Count). If these conditions are not met, the process continues from (3) again, but this time, instead of the data read in (1), the data read in (2) are used (i.e., possible hidden volume header). If the conditions are not met again, mounting is terminated (wrong password, corrupted volume, or not a TrueCrypt volume).

Quelle: http://www.truecrypt.org/docs/encryption-scheme.php

Außerdem ist Blowfish (128 Bit) schwer veraltet.

Definieren wir das Ganze einfach mal als zweifelhaft.

 

Als nächstes:

„das ist eine affine Chiffre, die kann man nicht knacken“

Okay, Blowfish geht, aber eine (linear) affine Chiffre nicht. Die Affine Chiffre ist (das findet auch jeder in Google) eine einfache Blockchiffre, welche allerdings im Gegensatz zur einfachen Verschiebechiffre noch einen 2. Schlüssel hat. Der Schlüssel ist also ein zwei-Tupel: k=(a,b). Wenn wir eine Alphabetsgröße von 26 festlegen, verschlüsselt sich Text mit Hilfe folgender Formel:

c = a*p + b mod 26

Wobei c das neue Chiffre- und p ein Klartextzeichen ist. Ein Beispiel:

Klartext: „ABC“, Key: (2,3)

2 * 0 (A) + 3 mod 26 = 3 (C)
2 * 1 (B) + 3 mod 26 = 5 (E)
2 * 2 (C) + 3 mod 26 = 7 (G)

Chiffretext = „CEG“

Zum entschlüsseln muss ein mulitplikatives Inverses berechnet werden.

Das versteht man also unter einer affinen Chiffre. Natürlich ist etwas kniffeliger als eine reine Verschiebe oder Vignerechiffre, jedoch nicht wirklich ein Problem. Mit ein wenig Verstand bekommt man es auch noch gut auf dem Papier hin.
Diese Aussage können wir zweifelsfrei als Unsinn bezeichnen.

One Time Password

Was haben Banken, World of Warcraft und einige große Unternehmen gemeinsam? In allen kann ein Gerät, welches ein „One Time Password“ erstellt, zum authentifizieren verwendet werden.

Wie sieht sowas aus und wie wird es verwendet?

Das Gerät besitzt ein oder zwei Knöpfe und ein kleines Display. Nachdem ein Knopf betätigt wurde zeigt dieser einen meist 6-stelligen Code an. Dieser muss dann im System (z.B. für die Banküberweisung) eingegeben werden. Bei erneutem betätigen wird wiederrum eine andere Ziffernfolge (pseudozufällig) erstellt.

Wie funktioniert das?

Sofern das Gerät keine innere Uhr besitzt (meist der Fall), müssen 2 Modi unterstützt werden:
TAN-Generierung und Synchronisation. Sobald also, wie oben geschildert, der Benutzer aufgefordert wird eine Tan einzugeben, berechnet das Gerät aus dem aktuellen Index einen Code. Der Index ist die Anzahl der bisher erstellten TANs.

Also ein Beispiel: G(I,K) ist die zweistellige Generatorfunktion, I ist der Index und K ein Passwort, welches fest im Gerät „eingebrannt“ und nicht auslesbar ist:

beim ersten Mal: G(0001,“abc123″) -> 495096
beim zweiten Mal: G(0002,“abc123″) -> 938237
beim dritten Mal: G(0003,“abc123″) -> 294921

Der Index wird also immer weiter inkrementiert.

Der Server, auf der anderen Seite, kennt auch das Passwort K. Dies hat der Hersteller so eingerichtet. Nach jedem benutzen inkrementiert der Server, genau wie das Gerät, den Index wodurch synchronisation zwischen Gerät und Server hergestellt wird.

Beispiel: Der Benutzer betätigt die Taste des Geräts und lässt sich ein Key berechnen: G(0325, „abcdefg“). Der Benutzer gibt die ausgegebene Ziffernfolge (439323) in das Formular ein. Der Server kennt die Anzahl der bisherigen Logins (324) und berechnet nun den aktuellen Index: 0325. Dadurch ist es möglich die Eingabe zu validieren.

Angenommen ein Benutzer betätigt versehentlich die Taste ist das System asynchron. Daher muss, wie schon angedeutet, die Möglichkeit bestehen, den aktuellen Index auszugeben.

Sicherheit?

Das System eliminiert das recht große Sicherheitsloch des unsicheren Benutzerpassworts. Es stetig wechselndes Passwort bietet durchaus Vorteile. Allerdings ist das System nicht resistent gegen Man-in-the-Middle. Beispiel: Der Server sendet an den Benutzer die Aufforderung zur Eingabe. Dieser kommt dem natürlich sofort nach und sendet die entsprechende Tan. Der Angreifer fängt diese Antwort ab, ändert den Inhalt (Überweisung auf ein anderes Konto) und schickt diese zum Server. Grund zur Angst besteht allerdings nicht, da Online-Banking mittels SSL resistent dem gegenüber ist.

SSL Check

Die Stiftung Warentest bietet einen Onlinedienst zum prüfen der SSL Sicherheit einer Webseite an.

http://www.test.de/themen/computer-telefon/ssl_check

In einem guten Browser wird dies allerdings auch übersichtlich angezeigt, wofür das Ganze also?

Das wird vielleicht klar, wenn wir mal ein Beispiel betrachten. Die Webseite https://www.sofortueberweisung.de/ ist auch SSL geschützt. Schauen wir uns an, was der Test dort ausspuckt:

Vom Server unterstützte SSL-Version: 3
Bevorzugte Verschlüsselung: Triple-DES (168/112 Bit)

Wenn ich allerdings mit meinem Browser die Webseite betrete erhalte ich eine andere Information

sofuebscreenshot

Woher kommt das?

Dafür muss man sich das SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) Protokoll etwas genauer anschauen. Bei der Kontaktaufnahme teilt der Client dem Server mit, welche sym. / asm. Verschlüsselungskombinationen er „versteht“. Diese werden auch Ciphersuites genannt. Mein Browser teilt also dem Server der Webseite mit, das er AES 256 bevorzugt was auch durchaus in meinem Interesse ist.

Aber angenommen ich wäre einem Man-in-the-middle Angriff ausgesetzt, d.h. jemand kann meinen Traffic komplett auslesen und verändern, dann hätte er bei SSL nur dann eine Chance, wenn die Verschüsselung unsicher ist. Wenn also der Bösewicht in der Mitte dafür sorgt das eine schwache Verschlüsselung (CipherSuite) ausgesucht wird, wäre er in einer eindeutig besseren Lage als vorher.

Aus diesem Grund wählt der SSL Check eine möglichst schlechte Verschlüsselung aus um herauszufinden wo der Server noch mitspielt und wann nicht mehr. Würde er also DES (effektiv 56 Bit) und gleichzeitig AES (128 – 256) unterstützen, wäre der SSL Schutz vielleicht nicht mehr so sicher, wie er auf den ersten Blick erscheint.

Daher ist dieser Check, obwohl er vielleicht auf den ersten Blick nicht so wichtig erscheint, eine gute Sache.

Digitale Signaturen (Teil 2)

Im letzten Artikel hatten wir uns damit beschäftigt wie diese Signaturen technisch umgesetzt werden. Sehen wir selbige nun auch einfach als korrekt an.

Mit Hilfe des öffentlichen Schlüssels des Absenders (im Idealfall -allen- bekannt) lässt sich also eine Signatur auf Gültigkeit prüfen. Wir sehen also, das der Text bei der Übersendung nicht geändert wurde. Sofern wir also den öffentlichen Schlüssel einer natürlichen Person zweifelsfrei zuordnen können, wissen wir, das diese Nachricht authentisch ist.

Um dies zu erreichen gibt es eine Public – Key – Infrastruktur, kurz PKI. Wie sieht das aus: eine vertrauenswürdige Stelle (Bank, Bundesdruckerei, etc.) bestätigt, das dieser öffentliche Schlüssel der Person XYZ gehört. Dies wurde mittels Ausweis (Post-Ident Verfahren) geprüft. Diese Einrichtungen nennt man CA (certification authority).

In der Regel läuft es so ab:

Ein recht Anspruchsvolles Wurzelzertifikat sichert das Zertifikat der CA ab, welches wiederum das Zeritifkat der „Person“ bestätigt.

So sichert Verisign das CA Zertifikat der Deutschen Bank ab welches wiederrum ihren Mitarbeiter Zertifikate ausstellt.

Und wo ist da nun die große Sicherheit?

Das online banking ist SSL geschützt und beruht auf einem Zertifikat. Dieses Zertifikat besagt, das diese Webseite (auf der man sich befindet) „Eigentum“ der (z.B.) Deutschen Bank und entsprechend stark gesichert ist. Im Browser wird dies meist durch ein grünes Zeichen (aufleuchten) oder ein Schloss signalisiert. Wenn dies also gegeben ist, kann ich sicher sein, mich auf der korrekten Seite zu befinden, sofern ich die korrekte Internetadresse eingegeben habe. Analog bei E-Mails.

Ich hoffe den Sinn und Zweck von Digitalen Signaturen / Zertifikaten vermittelt zu haben.