Neue Verschlüsselungslösung

[southy]

Hallo,

schaut mal hier:
http://www.golem.de/0603/44036.html

Das fängt offenbar die von einem Softphone generierten Daten ab und verschlüsselt sie auf dem Weg. klingt wirklich interessant und sieht so aus, als ob es auch einfach und DAU-tauglich funktionieren könnte.

Wenn man jetzt sowas noch auf einer Fritz!Nox implementieren könnte, so daß nicht nur die Softphone-User in den Genuss kämen....

Der source liegt doch sicher frei, kann man da nicht was machen? Würde die Rechenleistung der Box ausreichen?

Southy

 

[gandalf94305]

Das klingt in der Tat interessant und macht die Sache einfacher, als ein eigenes VPN zur Tunnelung aufzubauen... Für eine Fritz!Pox sollte man allerdings vorsichtig sein, denn Verschlüsselung/Entschlüsselung kostet Performance und Rechenzeit... da braucht die FBF vielleicht noch eine schnellere CPU ;-)

Einziges Problem hierbei: wenn ich das recht sehe, muß die Gegenstelle das Protokoll ja auch unterstützen ;-) d.h. da noch kein Provider ZRTP bietet, bleibt die Technik (noch) auf PC-PC Anrufe beschränkt...

--gandalf.

PS: Diese transparente Netzwerkverschlüsselung zwischen bestimmten Systemen gibt es schon länger... z.B. SKIP und andere, auch für Windows.

 

[southy]

Einziges Problem hierbei: wenn ich das recht sehe, muß die Gegenstelle das Protokoll ja auch unterstützen d.h. da noch kein Provider ZRTP bietet, bleibt die Technik (noch) auf PC-PC Anrufe beschränkt...

Das finde ich jetzt wiederrum sinnvoll. Eine Verschlüsselung, die beim Provider endet, reisst doch in Zeiten zunehmender staazlicher Überwachung keinen mehr vom Hocker.

Wenn schon, dann end-to-end.

Wobei ich finde, er hätte nicht unbedingt vollständig auf eine PKI verzichten sollen, man stelle sich vor:
ein öffentlicher Keyserver wie bei PGP existiert,
ich rufe irgendwo an, die Box checkt: ist das ein VoIP-Gespräch? -> lookup beim Key-Server -> er hat einen öffentlichen Schlüssel für diese Zielnummer -> automatisch verschlüsselt, ohne dieses "manuelle Tauschen eines hashes", was dieses neue Programm hier jetzt hat.

Gerade für die Nutzung ohne PC wäre das wichtig.

eine ideale Lösung könnte beides.


P.S: Ob die Box genug Rechenpower hat, ist eine interessante Frage.

 

[gandalf94305]

Das finde ich jetzt wiederrum sinnvoll. Eine Verschlüsselung, die beim Provider endet, reisst doch in Zeiten zunehmender staazlicher Überwachung keinen mehr vom Hocker.

Wenn schon, dann end-to-end.

Prinzipiell gebe ich Dir recht... aaaaaber ;-)

Für VoIP-VoIP-Verbindungen ist das auch gut so. Wenn ein Endpunkt im Festnetz liegt, dann muß ein Provider zwischengeschaltet werden und End-to-End Security ist nicht mehr möglich. Damit dies funktioniert, müssen jedoch auch Provider ZRTP unterstützen, damit die Internet-Strecke zumindest gesichert ist.

--gandalf.

 

[southy]

Für VoIP-VoIP-Verbindungen ist das auch gut so. Wenn ein Endpunkt im Festnetz liegt, dann muß ein Provider zwischengeschaltet werden und End-to-End Security ist nicht mehr möglich. Damit dies funktioniert, müssen jedoch auch Provider ZRTP unterstützen, damit die Internet-Strecke zumindest gesichert ist.

Das ist richtig.
Aber das haben wir ja nicht wirklich in der Hand.
Ich denke, wenn erstmal aus der Community eine Lösung für ein paar der populärsten Endgeräte, also z.b. Fritz!Box kommt, das dann evtl. irgendwann in die offizielle Firmware genommen wird, dann werden sich die Provider am ehesten _irgendwann_ mal bewegen.

Jetzt schon im vornherein auf Gateways mit Verschlüsselung zu hoffen, halte ich für etwas verfrüht.

Von daher halte ich es für am realistischsten, wenn erstmal von der Basis der User aus da ein bisschen was kommt und der Stein ins Rollen kommt.

Daher würde ich zunächst hauptsächlich auf Verschlüsselung bei reinen IP-Gesprächen setzen (auch nur den RTP Stream); also end-to-end und alles andere mal vorerst aussen vor lassen.
Und ich denke, wenn Phil den Sourcecode offengelegt hat, sollte eine Adaption doch mal garnicht so schwer sein. Die ganze GUI muss natürlich neu geschrieben werden als webformular, aber die Funktionalität an sich...

Wobei ich nach wie vor eine PKI hier schon sinnvoll finde. Aber sowas lässt sich halt nicht aus dem Ärmel schütteln, also lieber mal klein anfangen und dann anbauen.

southy

 

[MaZderMind]

Diffie-Hellman

Hi
Ich weiß nicht genau -- vllt. Verstehe ich auch eure Probleme mit Diffie-Hellman nicht, aber bei diesem Verfahren tauschen die Gegenstellen
/selbst/ bestimmte Werte aus, über die zusammen mit einer
selbst gewählten, geheimen Zahl, ein gemeinsamer Schlüssel errechnet
wird. Die öffentlich übertragenen Daten sind auf der einen Seite ohne
die jeweils geheime Zahl, nicht verwertbar, andererseits werden diese
geheimen Zahlen niemals öffentlich ausgetauscht.
Dieser Schlüssel ist, wie im Artikel beschrieben, nur für eine
einzelne Sitzung gültig und wird danach vernichtet.
Les mal den kurzen abschnitt zu Diffie-Hellman hier:
http://www.activevb.de/rubriken/kolumne/kol_8/schluessel.html

Gruß, Peter

 

[southy]

Hallo Peter,

Ich sag einfach mal: Ich hatte die Sache nicht genau richtig verstanden ;-)

Aber: Das Austauschen des Hashes, wie in diesem neuen Programm vorgesheen, dient dann also ausschliesslich als MITM-Abwehr?
Naja, auch das Problem wäre mit einer PKI nicht mehr existent.

Aber egal, ich bin da nicht wirklich der Fachmann.

Ich würde mich nur über eine solche Lösung für auf die Box freuen.

 

[prochmi]

1) ZRTP ist eine extension zu RTP, die einen masterkey für SRTP (ebenfalls eine extension zu RTP) bereitstellen soll. => ist also auch auf hardware phones realisierbar

2) ZRTP ist ja gerade End to End!

3) mit DH ist man erstmal nicht gegen man in the middle attacken sicher! außer man verwendet signed DH, dann braucht man aber eine PKI (zertifikate)

4) hier wird DH verwendet und ein paar andere mechanismen um zusätzlich gegen man in the middle sicher zu sein.

der ansatz ist SSH sehr ähnlich. beim ersten call muß man dem gegenüber mal vertrauen, indem man sich gegenseitig eine passphrase vorließt die über RTP übertragen wird und am display angezeigt wird (bei SSH fingerprint).

in den folgenden sessions werden reste aus der vorigen session verwendet um wieder eine vertrauensbeziehung zu haben.


mfg,
michael

 

[Novize]

Hier noch ein weiterer Link auf die Info:
heise.de: PGP-Erfinder präsentiert verschlüsselte Internet-Telefonie
Da wird auch kurz und knapp erklärt, wie man sich gegen Man-in-the-Middle-Angriffe wehren kann.

 

[ingmar2]

Daher würde ich zunächst hauptsächlich auf Verschlüsselung bei reinen IP-Gesprächen setzen (auch nur den RTP Stream); also end-to-end und alles andere mal vorerst aussen vor lassen.

Genau das leistet ZRTP. Der SIP Session-Aufbau wird nicht verschlüsselt.

Wobei ich nach wie vor eine PKI hier schon sinnvoll finde.

Gut, dass Phil hier so denkt wie Du:

Q: Can ZRTP use a PKI (public key infrastructure)?

A: Yes. Despite all the good reasons not to depend on a PKI, the ZRTP protocol does have the optional capability to use a PKI if you already have a PKI up and running. The ZRTP Internet Draft describes how ZRTP can use a PKI-backed digital signature key to sign the short authentication string in the ZRTP CONFIRM packet, to reduce reliance on users verbally comparing them during the call. Organizations that feel comfortable with PKIs can still get what they want. Thus, ZRTP offers all of the advantages of a protocol that can use a PKI, without actually becoming dependent on a PKI for security.

 

[ingmar2]

Ich weiß nicht genau -- vllt. Verstehe ich auch eure Probleme mit Diffie-Hellman nicht, aber bei diesem Verfahren tauschen die Gegenstellen
/selbst/ bestimmte Werte aus, über die zusammen mit einer
selbst gewählten, geheimen Zahl, ein gemeinsamer Schlüssel errechnet
wird. Die öffentlich übertragenen Daten sind auf der einen Seite ohne
die jeweils geheime Zahl, nicht verwertbar, andererseits werden diese
geheimen Zahlen niemals öffentlich ausgetauscht.

Ja. Das einzige Problem besteht in der nicht nur theoretischen Möglichkeit einer Man-in-the-middle attack, wogegen D/H allein keinen Schutz bietet. Dagegen solle eben der SAS schützen.