![[HaBo]](/styles/default/logoklein.png){kind=small}
Sicherer Schlüsselaustausch...
- Themenstarter enkore
- Beginndatum
Wenn man vorher einmalig einen sicheren Kanal zum Austausch zur Verfügung hat, könnte man erst öffentliche Schlüssel für ein asymmetrisches Kryptosystem darüber austauschen und dann hinterher mittels dieser Schlüssel die Schlüssel für ein symmetrisches Verfahren austauschen. Das ist natürlich nicht bei jedem Anwendungsfall möglich.
Ansonsten gibt es natürlich noch die Möglichkeit Zertifikate etc. zu verwenden, wie bei SSL, aber das fällt wahrscheinlich unter "gewaltigen Aufwand".
Ansonsten gibt es natürlich noch die Möglichkeit Zertifikate etc. zu verwenden, wie bei SSL, aber das fällt wahrscheinlich unter "gewaltigen Aufwand".
Hm aber was ginge wäre doch, einen Pseudosicheren Kanal zu haben;
Beispiel:
Zufallsschlüssel wird per Diffie-Hellman erzeugt. Der User gibt dann einen Nummer/Wort whatever ein, dass dann gehasht wird und an den Key angehängt wird.
Sofern beide User sich irgendwie auf ein Wort über einen pseudosicheren Kanal (sprachliche Abmachung oder so, CODEBÜCHER XD) einigen, klappt das.
Ist natürlich nicht so sicher wie mit Certs...
Apropos:
Wie werden Digitale Signaturen in der Realität implementiert? Der Wikiartikel erklärt das nur sehr lückenhaft...
Beispiel:
Zufallsschlüssel wird per Diffie-Hellman erzeugt. Der User gibt dann einen Nummer/Wort whatever ein, dass dann gehasht wird und an den Key angehängt wird.
Sofern beide User sich irgendwie auf ein Wort über einen pseudosicheren Kanal (sprachliche Abmachung oder so, CODEBÜCHER XD) einigen, klappt das.
Ist natürlich nicht so sicher wie mit Certs...
Apropos:
Wie werden Digitale Signaturen in der Realität implementiert? Der Wikiartikel erklärt das nur sehr lückenhaft...
Elderan
0
Hallo,
Sonst das simpelste Verfahren:
Annahme: Alle Clients haben den Public Key einer vertrauenswürdigen Partei. Das Cert. enthält dann: Public Key vom Client, Name des Clients, Signatur (Hashwert von Name, Public Key usw. mit dem Private Key der 3. Partei verschlüsselt).
Dann bei der Authentifizierung überprüft der Client die Signatur (Hashwert der Daten vom Zertifikat mit dem public key der 3. Partei verschlüsseln und vergleichen).
Nur musst du dich dann auch um die Ausgabe von Zertifikaten kümmern, schauen dass die User sich dann auch untereinander authentifizieren können usw. Alles gar nicht so einfach.
Man muss eben gucken was für ein System man erstellt. Hat man einen zentralen Server und die Clients sollen sich mit dem verbinden (z.B. ein Online-Backup System), dann lässt sich MITM leicht verhindern. Man gibt einfach jedem Client den Public Key des Servers mit und die Clients nutzen dann diesen zur Authenfizierung.
Weiterhin recht einfach ist es bei einer Client <-> Server <-> Client Architektur (z.B. Skype, ICQ etc.). Jeder Client bekommt den Public Key des Servers integriert und der Schlüsselaustausch geht über Client -> Server -> Client. Gut der Server könnte dann mitlauschen, das wäre aber weiterhin nicht soo schlimm, denn jede vertrauenswürdige dritte Partei kann ihr vertrauen ausnutzen und z.B. gefakte Zertifkate ausstellen. Nur würde man es einem Einbrecher in dem Server es erleichtern, alle Daten des Systems mitzulauschen und er müsste dann nicht diverse MITM Attacken durchführen, was recht schwierig ist.
Problematisch wird es bei Client to Client Verbindungen, bei dem ein Server nicht involviert sein soll. Da muss man dann i.d.R. auf Zertifikate zurückgreifen.
Wie gesagt, am besten ne Lib schnappen die den X.509 Standard implementiert, so dass man dann z.B. Zertifikate mit OpenSSH o.ä. erstellen kann.
Am besten nutz man eine Lib, die das unterstützt. Den Spaß das zu implementieren macht das nicht.
Sonst das simpelste Verfahren:
Annahme: Alle Clients haben den Public Key einer vertrauenswürdigen Partei. Das Cert. enthält dann: Public Key vom Client, Name des Clients, Signatur (Hashwert von Name, Public Key usw. mit dem Private Key der 3. Partei verschlüsselt).
Dann bei der Authentifizierung überprüft der Client die Signatur (Hashwert der Daten vom Zertifikat mit dem public key der 3. Partei verschlüsseln und vergleichen).
Nur musst du dich dann auch um die Ausgabe von Zertifikaten kümmern, schauen dass die User sich dann auch untereinander authentifizieren können usw. Alles gar nicht so einfach.
Natürlich geht das auch. Man nutzt einen Shared Key, den man zuvor irgendwie ausgetauscht hat, und nutzt diesen + Diffie Hellman um daraus Sitzungsschlüssel abzuleiten.
Man muss eben gucken was für ein System man erstellt. Hat man einen zentralen Server und die Clients sollen sich mit dem verbinden (z.B. ein Online-Backup System), dann lässt sich MITM leicht verhindern. Man gibt einfach jedem Client den Public Key des Servers mit und die Clients nutzen dann diesen zur Authenfizierung.
Weiterhin recht einfach ist es bei einer Client <-> Server <-> Client Architektur (z.B. Skype, ICQ etc.). Jeder Client bekommt den Public Key des Servers integriert und der Schlüsselaustausch geht über Client -> Server -> Client. Gut der Server könnte dann mitlauschen, das wäre aber weiterhin nicht soo schlimm, denn jede vertrauenswürdige dritte Partei kann ihr vertrauen ausnutzen und z.B. gefakte Zertifkate ausstellen. Nur würde man es einem Einbrecher in dem Server es erleichtern, alle Daten des Systems mitzulauschen und er müsste dann nicht diverse MITM Attacken durchführen, was recht schwierig ist.
Problematisch wird es bei Client to Client Verbindungen, bei dem ein Server nicht involviert sein soll. Da muss man dann i.d.R. auf Zertifikate zurückgreifen.
Wie gesagt, am besten ne Lib schnappen die den X.509 Standard implementiert, so dass man dann z.B. Zertifikate mit OpenSSH o.ä. erstellen kann.
Ich denke mal, dass ich dann in mein System eher eine PSK Achitektur mit Diffie Hellman implementieren werde...
Danke für die Erklärung
/EDIT:
http://oldpiewiki.yoonkn.com/cgi-bin/moin.cgi/DiffieHellmanKeyExchange
Weiß jemand welcher DH Gruppe bei dieser Impl g angehört? Oder eher: Wo finde ich eine Auflistung der DH Gruppen?
Danke für die Erklärung
/EDIT:
http://oldpiewiki.yoonkn.com/cgi-bin/moin.cgi/DiffieHellmanKeyExchange
Weiß jemand welcher DH Gruppe bei dieser Impl g angehört? Oder eher: Wo finde ich eine Auflistung der DH Gruppen?
Elderan
0
Hallo,
leider ist mein Japanisch/Chinesisch nicht ganz so gut.
Aber es gibt ein RFC mit Gruppen die man benutzen kann / sollte:
http://tools.ietf.org/html/rfc2412#page-45
Ansonsten kannst du jede Gruppe nutzen, in der der diskrete Logarithmus (aktuell) schwer zu lösen ist. Meistens nutzt man dabei (Z/pZ)* (Einheitengruppe der Restklassen der ganzen Zahlen modulo p). Welches p man nutzt, ist egal. Man muss nur einen Erzeuger/Primitivwurzel dieser Gruppe finden, bzw. eine Erzeuger der eine ausreichend große Untergruppe erzeugt.
Da man aber keine Lust hat das alles zu implementieren, nutzt man lieber die empfohlenen Gruppen/Erzeuger aus dem RFC.
leider ist mein Japanisch/Chinesisch nicht ganz so gut.
Aber es gibt ein RFC mit Gruppen die man benutzen kann / sollte:
http://tools.ietf.org/html/rfc2412#page-45
Ansonsten kannst du jede Gruppe nutzen, in der der diskrete Logarithmus (aktuell) schwer zu lösen ist. Meistens nutzt man dabei (Z/pZ)* (Einheitengruppe der Restklassen der ganzen Zahlen modulo p). Welches p man nutzt, ist egal. Man muss nur einen Erzeuger/Primitivwurzel dieser Gruppe finden, bzw. eine Erzeuger der eine ausreichend große Untergruppe erzeugt.
Da man aber keine Lust hat das alles zu implementieren, nutzt man lieber die empfohlenen Gruppen/Erzeuger aus dem RFC.
Weil der "man in the middle" quasi als eine Art Proxy agieren kann.
Alice und Bob wollen sich via DH auf einen Schluessel einigen.
MITM haengt sich jetzt dazwischen und vereinbart mit Alice einen Schluessel indem er sich als Bob ausgibt, und vereinbart dann noch mit Bob einen Schluessel indem er sich als Alice ausgibt.
Schon kann er nach belieben mitlesen und/oder Nachrichten aendern.
DH soll nur vor dem Mitlesen der Nachricht schuetzen, gegen MITM Angriffe helfen aber nur Zertifikate und/oder Signaturen.
- Keks
Alice und Bob wollen sich via DH auf einen Schluessel einigen.
MITM haengt sich jetzt dazwischen und vereinbart mit Alice einen Schluessel indem er sich als Bob ausgibt, und vereinbart dann noch mit Bob einen Schluessel indem er sich als Alice ausgibt.
Schon kann er nach belieben mitlesen und/oder Nachrichten aendern.
DH soll nur vor dem Mitlesen der Nachricht schuetzen, gegen MITM Angriffe helfen aber nur Zertifikate und/oder Signaturen.
- Keks