[HaBo]

speedo

Ein Zero-Knowledge-Beweis ist ein Verfahren, einem Server nachzuweisen, das richtige Passwort zu besitzen, ohne es direkt zu übermitteln. Nun gibt es ja Protokolle und Hash-Verfahren, die das ermöglichen.

Nachdem ich mir nun einige edanken zu einer Möglichkeit gemacht habe, ein eigenes Verfahren zu schaffen, möchte ich zuerst mal fragen, ob in diesem System nicht eine Sicherheitslücke steckt.


Ich bezeichne im Folgenden einmal den Client als den Rechner, der sich zu identifizieren hat (also den Beweis liefern soll), und den Server als den Prüfer des beweises auf Richtigkeit. Als kryptographischen Algorithmus verwende ich Rijndael.


1.: Der User bekommt nach dem Aufbau seiner Verbindung eine 128 Bit Zufallszahl zugeschickt.

2.: Der User verschlüsselt diese Zufallszahl mit seinem Schlüssel.

3.: Der User schickt den verschlüsselten Block zurück an den Server

4.: Der Server Verschlüsselt Seine Zufallszahl ebenfalls und vergleicht sie mit dem Verschlüsselten Datenblock des Users. (Stimmen diese nicht überein, war der Schlüssel nicht richtig.)

Könnte es dadurch Probleme geben, dass jemand, der die Leitung abhört, beim einloggen sowohl Plaintext als auch Ciphertext kennt?

Können andere Probleme auftauchen??


lg, Speedo

Spyx

Wenn man deinen Algorithmus kennt, dann ist es überhaupt kein Problem. Man "hört die Leitung ab", hat somit Zufallszahl und den verschlüsselten Block. Daraus kann man dann einfach den Schlüssel zurückrechnen .

speedo

Das ist mir neu. Wie geht sowas?

Heinzelotto

Beispiel: Die verschlüsselung ist: Addiere deine geheimzahl zu der zu dir gesendeten Zahl.
Server sendet: 100
deine Geheimzahl: 28
Du sendest also zurück: 128

Ein Angreifer, der nun 100 und 128 erhält und weiß, wie die Verschlüsselung funktioniert, kommt relativ schnell darauf, dass dein Key 28 ist

Es gibt allerdings auch Methoden, die keine (oder nur sehr schwer) Rückrechnung seitens des Angreifers zulassen, siehe dazu http://de.wikipedia.org/wiki/Asymmet...s_Kryptosystem

speedo

Wie ist das denn möglich, dass bei einem komplexen Algorithmus über Ciphertext und Plaintext jemand an das Passwort kommt? Gibt es dazu irgendwelche google-tauglichen Stichworte?


speedo

Elderan

Hallo,
Wenn man einen sicheren Algorithmus verwendet, z.B. AES, dann kann man aus Klartext + Geheimtext nicht den Key gewinnen.

Nur:
Was du beschreibst, nennt sich Challenge And Response Protokoll. Der Server sendet eine Challenge, der Empfänger berechnet etwas und sendet das Response (Antwort) und der Server schaut dann, ob die Antwort richtig ist.

Dies hat gar nichts mit Zero Knowledge zu tun. Zero Knowledge ist nicht nur dass das Passwort nicht über die Leitung gesendet wird, sondern man überzeugt den Server das man das richtige Passwort kennt, ohne das der Server das Passwort kennt! (Natürlich kennt der Server nach dem Login das Passwort immer noch nicht)

Deswegen wird man mit einem kommunikationswechsel nicht hinkommen, sondern man müsste z.B. 100 mal Daten austauschen, um sicher zu stellen, dass der User auch zugansgberechtigt ist.

Das Zero Knowledge Protokoll lässt sich anfänglich nur schwer verstehen, das Beispiel mit der Tür die nur durch einen geheimen Code aufgeht ist aber recht anschaulich: Anschauliches Beispiel zu Zero Knowledge
Alice kann hier Bob überzeugen, dass sie den Trick für die Tür kennt, ohne dass Bob den Trick kennen muss und ohne das Alice diesen Trick verrät.
Und ähnlich wäre das bei Passwörter.


Nur:
Weil man soviele Handshakes (Daten austauschen) machen muss, wird es praktisch kaum eingesetzt. Eine große Schwache von IPSec war (bis vor kurzen eine neuere Version vorgestellt wurde), dass der Handshake für den Schlüsselaustausch ich meine über 6 Schritte ging, was einfach zuviel ist.
Und jetzt 100 oder 200 Schritte durchzuführen...

speedo

Danke für den Link. Dann ist das, was ich meine Challange and Response.

Also ist, solange der Algorithmus sicher ist (was ja bei Rijndael, Blowfish oder 3DES gegeben ist), ein Symetrischer Blockschiffre ausreichend? Denn das Handlen von Zahlen > 1024 Bit ist schließlich mit wesentlich mehr Aufwand verbunden und wenn ein Blockschiffre ebenso sicher ist, dann ist das ja auch nichtt nötig.

speedo

Elderan

Hallo,
naja das Challenge and Response Protokoll hat auch einige Probleme, auf die man reagieren muss. Wie z.B. reply attack, MITM bzw. der Server kann sich als dich ausgegeben.
Insbesondere MITM ist kritisch, weswegen SSL für den Login auf alle Fälle die bessere Variante ist.

speedo

Was könnte denn der MITM ausrichten? Immerhin bekommt der erstmal nur die Zufallszahl einmal kodiert und einmal plain. Die weitere Kommunikation kann man ja so gestalten, dass der Server dem Client den IV in verschlüsselter Form übermittelt und der rest der Kommunikation im CBC-Modus stattfindet. Oder übersehe ich da etwas?

Elderan

Hallo,
den IV bei CBC geheim zu halten bringt gar nichts, da er sich eh nur auf den 1. Block auswirkt. Alle weiteren Blöcke sind vom IV unabhänig.

Was der MITM machen könnte:
Sich in die Mitte stellen und alle Daten mitlauschen, selber böse Anfragen an den Server senden und und und.
Wenn du eine sichere Verbindung haben möchtest, dann wirst du nicht an asymmetrischer Verfahren drum herum kommen.
Am einfachsten man verwendet gleich SSL.

speedo

Sicher bietet SSL bei der Praktischen Anwendung viele Vorteile (ganz zu schweigen davon, dass man sich kaum Gedanken um Kryptographie machen muss), mir geht es aber eher um die Theoretischen Aspekte und ich hatte bisher nicht vor, soetwas zu implementieren. Ich wollte mich (Ich bin noch neu auf dem Gebiet der Kryptigraphie) über die möglichkeiten der verschiedenen Algorithmen erkundigen.

Bei einem Asymetrischen Algorithmus kann der MITM doch auch irreführende Traffic versenden. Den Punkt verstehe ich leider nicht so ganz.

Ich dachte immer, das mit dem IV läuft folgendermaßen ab:

-> IV hat Einfluss auf den ersten Block bevor er verschlüsselt wird
-> Erster verschlüsselter Block hat einfluss auf den zweiten Block bevor er verschlüsselt wird
-> Zweiter verschlüsselter Block hat einfluss auf den dritten Block bevor er verschlüsselt wird
...
usw


Wenn ich das also richtig verstanden habe, wirkt sich der IV rekursiv auf alle Blöcke aus, die verschlüsselt werden. Ist dem nicht so?

Elderan

Hallo,
ne da hast du einen Denkfehler.
Wenn man einen anderen IV wählt, dann sieht zwar der Geheimtext anders aus obwohl der Klartext evt. der selbe ist, dennoch erhöht ein geheimer IV nicht die Sicherheit.

Wenn der IV verloren geht, dann ist davon nur der erste Geheimtextblock betroffen, den man nicht mehr einwandfrei entschlüsseln kann.
Den zweiten Geheimtextblock kann man aber weiterhin entschlüsseln, denn dafür braucht man nur den Geheimtext des 1. Blocks.

Ergo: Bringt es nichts den IV geheim zu halten.

Für soetwas gibts ja Zertifikate


Naja du kannst dich als MITM einfach dazwischen hängen.
Der Server sendet dem Angreifer eine Challenge, diese sendet man an den Client weiter. Der Client sendet dem Angreifer die Response, und diese gibt der Angreifer an den Server weiter.
=> Angreifer ist beim Server authentifiziert.

Wie gesagt, für den sicheren Kommunikationsaufbau kommt man kaum um RSA oder Diffie Hellman o.ä. herum. Lösungen die ausschließlich symmetrische Verfahren nutzen haben fast immer einen Knackpunkt.

speedo

Ja, das ist ein eindeutiger Vorteil.

Aber um nochmal zum CBC zu kommen: http://de.wikipedia.org/wiki/Cipher_Block_Chaining verstehe ich so:

Der IV wird mit dem ersten Block XOR-verknüpft und dann verschlüsselt. Mit dem verschlüsselten Block 1 (Dessen Ciphertext ja vom IV beeinflusst wurde) wird nun der Block 2 XOR-verknüpft und verschlüsselt. Hat so nicht der IV einfluss auf Block 2?

Immerhin ist die verschlüsselte Ausgabe von Block1 durch den IV beeinflusst worden und damit auch der Block2 da er damit XOR-verknüpft wurde?


lg, speedo

Elderan

Hallo,
natürlich hat der IV indirekt Einfluss auf Block 2, nur, man braucht den IV nicht zu kennen, um Block 2 zu berechnen, wenn man bereits Block1 hat.

Wie gesagt, den IV geheim zu halten bringt rein gar nichts. Denn Block2 hängt nur vom Ciphertext von Block1 ab, und den Geheimtext kennt der Angreifer.

speedo

ups stimmt... das war jetzt mächtig schusselig von mir, sorry

damit wäre aber jetzt erstmal alles geklärt. danke für deine hilfe!