OTP - Schlüsselübermittlung und Frage zur Sicherheit

[Ratte]

Dafür dürfte ein OTP nicht sonderlich gut sein (Du kannst natürlich jedem deiner Partner 1GB OTPs auf DVD geben und dann damit arbeiten, ist aber glaube ich nicht sonderlich clever. Du solltest lieber ein asymetrisches Verfahren nehmen (RSA). Allerdings kannst du natürlich in etwa wie bei PGP (überträgt keine OTPs, sondern "normale Schlüssel") den OTP per RSA verschlüsseln und dann so übertragen. Ist dann aber auch nur so sicher wie RSA (quasi unknackbar).
mfg,
Ratte

[negaH]

Schau mal hier in die CodeLib meinen SRP an.

SRP = Secure Remote Password Protocol ist ein Authentifikations und Schlüsselaustausch Protokoll. Dabei geht es also darum das sich ein Client bei einem Server anmelden kann, beide sich gegenseitige authentifizieren, sprich überprüfen ob am anderen Ende auch wirklich der berechtigte User sitzt, auf sicherer Art einen gemeinsam mmen Schlüssel erzeugen und damit dann ihre spätere Kommunikation verschlüsseln können. Wichtig bei all diesen Aspekten ist es das kryptographisch sicher verhindert wird

1.) das Password des Clients zu knacken
2.) das Password in keinster Weise jemals über den unsicheren Kanal übertragen wird
3.) eine Man in the Middle Attacke ausgeschlossen ist, unmöglich wird
4.) beide Parteien genau wissen das am anderen Ende derjenige ist für den er sich ausgibt
5.) ein sicheres Session-Password -> Shared Secret gemeinsam berechnet wird das zufällig ist, nicht über den unsicheren Kanal übertragen wird so das man es eventuell knacken könnte, dieser Sessionkey ausreichend groß ist >= 256 Bit.

Eventuell würde der SRP also nicht nur deine Anforderungen auf kryptogaphisch sichere Weise erfüllen sondern sogar dein Chat Program noch zusätzlich durch weitere bessere Feature aufwerten.

Gruß Hagen

[DGL-luke]

Zitat von negaH:

3.) eine Man in the Middle Attacke ausgeschlossen ist, unmöglich wird

Wie soll das gehen?

Sobald am Router oder sogar an einem der PCs oder am Server jemand alles mitloggt bzw. als man in the middle arbeitet (sprich alles abfängt und nach gutdünken weiterleitet), hat er doch alle Informationen die er braucht, um den kompletten Verschlüsselungsvorgang nachzuvollziehen.

Rein theoretisch ist doch eine man in the middle attack IMMER möglich, solange man eine solche Zwischenstation nicht auschließen kann (und im Internet kann man das nie)

(Ich hoffe, das ist nicht zu sehr OT)

[negaH]

Die MITMA ist ausgeschlossen, ansonsten würde SRP keinen Sinn machen, und viele andere Protokolle ebenfalls nicht.
Und es geht indem man Kryptographie benutzt. Genauer gesagt benutzt man die Technik des "Zero Knownledge" Protokolls. Dabei geht es darum wie man beweisen kann das man ein Geheimnis kennt OHNE dieses Geheimnis verraten zu müssen.

Also wenn es ein Verfahren gibt mit bei dem ich sage "Ich weis ein Geheimnis und kann dies dir beweisen OHNE das DU mein Geheimnis kennen musst" dann nennt sich das "Zero Knownledge", da DU keinerlei Informationen von mir über das Geheimnis selber erhältst. Wenn du aber keine Informationen über mein Geheimnis von mir erhälst so impliziert die auch das kein Anderer Informationen über mein Geheimnis erhält, also auch nicht der böse MITMA.

Es hört sich im ersten Moment als eine Unmöglichkeit an ist aber dank schlauer Mathematiker tatsächlich machbar.
SRP baut darauf auf oder Diffie Hellman Schlüssel Austausch baut indirekt darauf auf.

Allerdings gibt es tatsächlich einen, und einzisgten Zeitpunkt in dem eine MITMA möglich ist, immer, und bei jedem Protokoll. Nämlich der allererste Schritt in dem ein Client beim Server als berechtigter Client registriert wird. Bei jedem Protokoll ist dies eine Schwachstelle und lässt sich im Grunde nur durch eine Dritte Partei -> Trust Center oder direkte Authenfikation (persönlich) lösen.

Wurde dieser erste Schritt sicher abgearbeitet dann sind alle nachfolgenden Schritte garantiert MITMA sicher.
In diesem ersten Schritt ist es über das Zero Knownledge nun möglich das der Server und Client einen sogenannten Verifier vereinbaren/austauschen der denoch nichts über das Geheimnis=Password aussagt. Ganz stimmt diese Aussage aber nicht Denn korrekt betrachtet ist der Verifier eine Zahlenmäßige Umformung diese Passwortes die mit heutigem Wissen und technologischen Möglichkeiten nicht in das Passwort zurückgerechnet werden kann. Dieser Verifier wird nun zb. im laufenden Protokoll des SRPs niemals übertragen. Der Client/Server können sich aber denoch mit Hilfe des Zero Knownledge gegenseitig davon überzeugen das der jeweils andere diesen Verifier kennt.

Der Client wird einfach mit Hilfe vom SRP aus seinem Password diesen Verifier reproduzieren, der Server hat den Verifier gespeichert. Beide tauschen beim Login nun verschiede Werte untereinander aus die dann indirekt einen Beweis ergeben das der jeweils andere den Verifier kennen muß.

Man geht dabei immer davon aus das sowohl der Client wie auch der Server sicher sind. Wurde also ein Server kompromittiert und hijacked dann ist natürlich eine MITMA möglich. Politisch betrachtet ist das auch ein Grund warum in Deutschland per Verordnung ein Provider gesetzlich verpflichtet ist eine Standleitung zum BND einzurichten, quasi jeder Provider hijacked werden kann. Allerdings trifft dies eben nicht auf Endstellen zu, also Clients und Clients die als Server arbeiten. Und gerade deswegen ist es gut das es solche Protokolle gibt, sie verhindern nämlich eine MITMA effizient.

Bei SRP geht man noch einen Schritt weiter. Im Verlauf des Protokolls authentifizieren sich der Client und Server gegenseitig und erzeugen nebenbei sogar noch ein sogenanntes "shared Secret", einen gemeinsammen Schlüssel. Mit diesem kann dann später ohne Probleme die Kommunikation verschlüsselt werden. Bei diesem Schlüsselaustausch, bei dem keine Schlüssel "ausgetauscht" werden, sondern beide zur gleichen Zeit einen gemeinsammen Schlüssel berechnen, werden wiederum keine nützlichen Informationen übertragen die Rückschlüsse auf diesen Schlüssel ergeben. Ein MITMA kann also nicht diesen Schlüssel durch Lauschen nachberechnen.
Dieser Schlüssel ist dann auch noch zufällig gewählt, und verhindert durch seine binäre Größe jede Brute Force Attacke.

Mein Counter-SRP geht noch par Schritte weiter als Standard SRP. Counter-SRP ermöglicht es zu jedem Login ein neues Password zu vereinbaren ohne das dies übertragen wird und ohne das der Server wissen kann wie das Password lautet oder sogar mit der noch restriktiveren Einschränkung das der Server noch nichtmal in der Lage ist zu erkennen OB das Passwort geändert wurde oder nicht !

Einzigst der Server, als böser Server, wäre in der Lage eine Brute Force Attack auf das Client-Passwort durchzuführen. Allerdings bei gutem Passwort und öfterer Änderungen des Passwortes ist das praktisch nicht machbar.
Desweiteren benutzt Counter-SRP noch nichtmal einen lesbaren Client Namen. D.h. Counter-SRP könnte völlig anonyme Clients verwalten. Selbst wenn also der Server gestohlen würde so wüssten die Angreifer nicht welcher Datenbank-Record zu welchem Clienten gehört. Das ginge wiederum nur durch eine Brute Force Attacke oder besser per Dictionary Attack -> Wörterbuch Angriff. Selbst wenn dies erfolgreich machbar wäre dann muß man immer noch das Clientpasswort per Brute Force Attacke brechen. Allerdings geht dies diesesmal nicht mehr per Dictionary Attack, der Angreifer muß also für jedes Paswort real eine komplette Brute Force Attack durchführen. Das wären bei meinem Counter-SRP also 2^256 * Password_Länge_In_Bits Kombinationen die man durchprobieren muß !


Gruß Hagen

[DGL-luke]

Danke. Sehr aufschlussreich.

[WIN-MANww]

Hi zusammen

Danke für die Antworten, das mit dem SRP werd ich mir noch überlegen. Ich interessiere mich jetzt vor allem für das Public Key Verfahren, nur will ich es nicht so richtig begreifen, wie es funktioniert. Habt ihr vieleicht zufällig ein Stück Code, an welchem ich sehen kann, wie ein Public Key Verfahren zwischen einem Server und einem Client funktioniert? Würde mich sehr darüber freuen.

[WIN-MANww]

*push* Keine Ahnung ob es jetzt schon erlaubt ist, aber ich hoffe mal schon.

[generic]

warum willst du das rad neu erfinden.
tunnel deine komunikation du ssh/tls oder ein vpn.

[WIN-MANww]

Danke für die Antwort

Sagen wir es so, ich sollte es besser neu erfinden, denn dieser Chat soll ne Projektarbeit werden und ich muss das Ganze dann auch noch dokumentieren, daher wäre es besser, ich würde soviel wie möglich selber schreiben. Meine Vorstellung ist einfach, einen Chat zu schreiben, der die nötige Sicherheit beinhaltet, d.h. er soll so sicher wie möglich, aber trotzdem noch benutzerfreundlich werden, daher denke ich ist ein Public Key Verfahren ziemlich sinnvoll.

Habt ihr also ein bischen Code für mich über Public Key Verfahren? Würde mich sehr freuen.

[WIN-MANww]

Nochma, n *push*