Schlüssel austausch

[arbu man]

Hallo,

ich habe eine Idee, ich möchte einen Schlüsselaustausch über das Internet machen. Ich stelle mir das so vor:

Vorraussetzungen:
Es gibt 2 PCs (A und B). Die Kommunikation zwischen A und B ist immer sichtbar.

Dann soll der Schlüsselaustausch stattfinden.

Ergebnis:
PC A und B haben nun den selben Schlüssel. Über die Kommunikation zwischen beiden kann man den Schlüssel nicht berechnen.


Nun meine Frage ist so etwas möglich oder nicht und wenn ja wie ? Mir fehlt dafür das wissen und auch die Nötigen Schlagwörter für eine Suche...

mfg, Björn

[mkinzler]

ich würde ein asymetrische Verschlüsselung verwenden, dann ist der Austausch der (öffentlichen) Schlüsseln kein Problem.

[Chewie]

Als Suchbegriffe könnte ich Diffie-Hellman anbringen.

[Meflin]

Dieffie-Hellman ist schonmal eine geniale Sache.

Noch viel genialer - und für deine Zwecke vermutlich auch dienlich - finde ich aber Shamirs No-Key-Protokoll

Klick

[arbu man]

Danke für die Antworten ich habe mir den Diffie-Hellman Algorithmus mal angeschut und habe versucht in zu implementieren. Theoretisch müsste er auch laufen. Zumindes mit den kleinen Zahlen von Wikipedia. Aber mit anderen Zahlen läuft er nicht.
Ich vermute es liegt an der Primitivwurzel (die erklärung auf Wikipedia dazu hab ich nicht sorecht verstanden). Z. Z. Berechne ich die Primitivwurzel so (Bezeichner sind die von Wikipedia):

  g := RandomRange(2, p-2) mod p; Ist das richtig oder bin ich da schon auf dem Holzweg ?

mfg, Björn

[negaH]

Holzweg.

Beim DH sollte man mit speziellen Primzahlen arbeiten, den Safe Primes oder auch Sophie German Primzahlen genannt. Diese haben folgende Form

P := 2*Q+1

wobei P und Q Primzahlen sein müssen und 2 auch eine Primzahl ist.

Arbeitet man mit diesen Primzahlen dann kann man den Generator so berechnen

Delphi-Quellcode:

  G := 3;
  repeat
    repeat
      G := G +1;
      T := G^2 mod P;
    until T <> 1;
    T := G^Q mod P;
  until T <> 1;

G ist dann die kleinste Zahl, größer 3, die ein Generator in dieser Domain ist. Das ist sogar erwünscht da dadurch sich die Berechnungen in der DH Domain per Brickel's modularer Exponentation um den Faktor 3 im Vergleich zur k'ary Sliding Window Exponentation beschleunigen lassen.

Arbeitet man nicht mit Safe Primes so benötigst du die Faktorization von P -1 = Phi(P) und musst alle so ermittelten Primzahlen nach obiger Methode austesten. Das Problem könnte diese Faktorization sein, da P meisten >= 2^2048 ist. Es ist dann sinnvoll die Konstruktion von P zu kennen. Dazu gibt es von Lim&Lee die LimLee Primes

"A Key recovery Attack on Discrete Log-based Schemes using a Prime Order Subgroup", Lim & Lee, Crypto '97

deren konstruierte Form sieht so aus

P := 2 * Q * P1 * P2 * ... * Pi +1,

P,2,Q,P1..Pi sind industrielle Primzahlen
P ist zb. 2048 Bits groß
Q ist zb. 160 Bits groß
P1..Pi sind > 160 Bits

Damit ist Q die kleinste Primzahl und bestimmt die Sicherheitsschranke wie sicher P ist. Man wird also beim "Knacken" = Faktorisieren von P als erstes immer Q finden.
Nachdem eine solche Primzahl erzeugt wurde hat man auch dessen komplette Faktorisation und kann im Anschluß den Generator berechnen. Bis auf P und G werden die restlichen Zahlen dann vernichtet.

Im Grunde konstruiert man eine abgeschwächte Variante der Sophie Germain Primzahlen. Wenn man eine gute Crypto Lib hat dann dauert die Konstruktion einer Safe Prime nicht wesentlich länger als die einer LimLee Primzahl. Das Ratio düfte so bei 3 zu 1 liegen. Mit meinem DECMath erzeugt ich eine solche Safe Prime in durchschnittlich unter 1 Sekunde auf einem P4. Nun beim DH Verfahren ist es üblich das alle beteiligten Parteien sich eine verifizierte und hardcoded Primzahl P teilen. Das heist man berechnet den ganzen Kram nur ein einzigstes mal. Es besteht also nicht der geringste Grund Safe Primes nicht zu benutzen und stattdessen irgendeine andere Form der Primzahlen zu benutzen. Besonderst weil man so das hardcoded speichern vom Generator G verzichten kann und mit obiger Methode live diesen Generator berechnen kann. So ist auch zusätzlich noch sichergestellt das man wirklich eine Safe Prime für DH benutzt, da ansonsten obiger Code eben falsche Resultate liefern muß. Ein möglicher Angriff wäre nämlich der Austasuch dieser Domain Parameter.

Gruß Hagen

[negaH]

Ach und nochwas, kannst du mit einer fertigen DLL leben ?

Schau dir das mal an http://www.delphipraxis.net/internal...976&highlight=

SRP macht ebenfalls einen sicheren Schlüsselaustausch inklusive einer sicheren Authenfikation beider Parteien.

Denn bedenke, so wie du jetzt DH ausführst ist es nicht sicher. Es besteht die ernstehafte Gefahr einer "MITMA-Man in the Middle Attack". Dabei schaltet sich eine dritte Partei in die Komunikation dazwischen und macht ihrerseits 2 DH-Schlüsselexchanges mit den zwei Parteien. Davon bekommen diese Parteien nicht mit. Das betrifft auch Shamier's Verfahren das übrigens patentiert ist und deshalb kaum Verwendung findet. Dieser Angriff ist beim SRP ausgeschlossen.

Gruß Hagen

[arbu man]

Hallo Hagen,

danke für deine Ausführungen. Damit habe ich es geschafft das richtige g zu finden allerdings bin ich dabei auf ein weiteres Problem gestoßen: Im Algorithmus kommt mehrfach ein Ausdruck in folgender Form vor:
a hoch b mod c Zwar habe ich eine Funktion um int64 Zahlen zu potenzieren, aber dieser Funktion geht sehr schnell die Puste aus, so etwa wenn der Exponent größer 30 wird. Das macht die Möglichen Schlüssel Natürlich recht übersichtlich...


Ich könnte auch mit deiner DLL Leben, ich hab mir Teil mal angeschaut. Sieht so aus als könnte die ein Passwort abhörsicher übertragen. Ich hab dazu ein kleines Demoprogramm erstellt. Ich denke mal ich hab alles richtig umgesetzt (Der Screenshot sagt alles, in mir schwirren noch die Editbezeicher herrum).
Gradiose Arbeit, die du da gemacht hast Danke Dir

mfg, Björn

[negaH]

Zitat:

Zwar habe ich eine Funktion um int64 Zahlen zu potenzieren, aber dieser Funktion geht sehr schnell die Puste aus,

http://www.delphipraxis.net/internal...+exponentation
http://www.delphipraxis.net/internal...=exponentation
http://www.delphipraxis.net/internal...ation&start=10

einfach mal durchlesen

Zitat:

Sieht so aus als könnte die ein Passwort abhörsicher übertragen

Nicht nur das, sondern sie macht es auch. Dh. du versendest deine verschlüsselte Daten mit dem SRP und diese Daten sind ein Passwort. Nur macht das SRP ja schon von Hause aus intern aber viel besser. Man tauscht nämlich garkein Passwort aus sondern Client und Server berechnen in parallel ein gemeinsammes und zufälliges Passwort.
Du musst also garnicht ein Passswort austauschen sondern sendest mit dem SRP Interface einfach verschlüssselte Daten. Meine SRP Source machen den Rest

1.) Authentifikation vom Client->Server und Server->Client ohne das das Benutzerpasswort real übertragen wird
2.) Berechnung eines zufälligen Passwortes auf Server und Client Seite ohne das nutzbare Daten übertragen werden
3.) Verschlüsselung des nachfolgenden Datenverkehrs mit sicheren Verfahren

In Punkt 1.) und 2.) werden die Information nur so übertragen das ein Lauscher mit mathematischer Beweisbarkei nicht in der Lage ist irgendwas an Information zu erlangen.

Meine SRP-6 Änderungen zum Original macht aber noch mehr

1.) bei jedem Login wird nach erfolgreichem Ablauf des Protokolls ein neuer Passwort-Verify zum Benutzer in der Server-DB gespeichert.
2.) bei jedem Login kann also der Benutzer selbst sein Passwort verändern ohne das der Server das mitbekommt. Also der Server kann nicht mitbekomme ob der Benutzer das alte Passwort als Neues weiterbenutzt oder ob real ein Neues Passwort registriert wurde.
3.) SRP kann ein Account-Limit besitzen, bzw. es gibt einen nicht manipulierbaren Counter für jeden Login. Wird dieser Counter im LOgin Dialog angezeit so hat der Benutzer ein visuelles Feadback ob sein Passwort per Brute Force oder KeyLogger geknackt wurde. Das funktioniert dann so das der Benutzer bemerkt das der aktuelle Counter um > +1 inkrementiert wurde. Das bedeutet eine andere Person hat sich in der Zwischenzeit angemeldet. Daraufhin schlägt entweder der Login fehl, weil der Angreifer das Passwort gestohlen hat und auch ein neues definiert hat. Man muß den Serveradmin informieren. Oder der Angreifer hat das gleiche Passwort weiterbenutzt. In diesem Moment kann der reguläre Benutzer dies erkennen und sofort ein neues Passwort registrieren. Und der Angreifer muß erneut dieses Passwort ausspionieren.

Alles drei erhöht die Verfahrenssicherheit. Also nicht die Sicherheit der Mathematik dahinter sondern die Benutzungssicherheit durch den Benutzer und Server.

Es gibt nur drei Angriffsstellen

1.) Angriff auf den Benutzer, sprich Computer, sprich Trojaner um das Passwort zu ermitteln
2.) Brute Force auf das Passwort, das lässt sich aber sicher ausschließen wenn das Passwort gut gewählt wurde und wenn der Server nach x'maligem falschen Login den Account sperrt oder ähnliche Aktionen folgen lässt.
3.) den Registrationsprozess ! Also die allererste Vereinbarung eines Accounts. Nur die Authentifikation durch eine dritte Partei kann dieses Problem lösen. Normalerweise sendet der Server eine EMail mit dem 1. Registrationskey mit der Aufforderung sofort das richtige Passwort zu definieren. Man könnte diese Mail abfangen und dieser Angreifer könnte den Account aktivieren. Allerdings hätte dann der reguläre Benutzer keinen Zugriff mehr, er kan sich also nicht merh freischalten und wird diese Problem dem Serveradmin melden. Man detektiert also solche Angriffe.

Alle drei Angriffe funktionieren mit allen bekannten Softwareverfahren !! Sie sind also nicht SRP typisch.

Die einfache Benutzung meiner SRP-Implementation darf nicht darüber hinwegtäuschen das noch einiges an Arbeit getan werden muß auf Serverseite um es wirklich sicher zu bekommen. Aber dann ist es wirklich sicher. Mir würde dann kein Angriff mehr einfallen der noch praktikabel wäre.

Der Vorteil zu allen anderen Verfahren ist halt das ein PC, ein Passwort und der SRP Code als Software ausreicht. Bei anderen Verfahren benötigt man noch digitale Zertifikate die als Dateien oder in der Registry gespeichert sein müssen. Auch diese benötigen ein Passswort für ihren Schutz das man sich merken muß. Oder man benötigt einbruchsichere extra Hardware wie USB Dongles, SmartCards, RSA TokenID usw. usw.

Gruß Hagen

[edit]
Übrigens basiert SRP auf DH.
[/edit]

[arbu man]

Zum Problem mit den "kleinen" int64 Zahlen, einige meiner Ansätze konnte ich in den von dir verlinkten Themen wiederfinden Letztlich hab ich eine BigInt Klasse gefunden mit der ich nun die Berechnung a^b mod c mache, und ich komme sogar auf das richtige Ergebnis

Deine SRP-Implementation ist auch eine Geniale Sache, z.Z. Versende ich Zwar den Registrierungsschlüssel über den Normalen Transport Kanal, aber ich nehme an das Verfahren bietet schon eine große Sicherheit, zumindest sieht es mal Kompliziert aus

Danke nochmal für deine Hilfe

mfg, Björn