Hallo!

Ich habe den PhonerLite und bin damit sehr zufrieden, vor allem, dass der eben auch SRTP und TLS kann. Leider gibt es ja für TLS noch keine (?) Provider, so dass ich eben nur mit SRTP verschlüssele. Allerdings wird dann ja der Master Key im Klartext über SIP mitgeteilt. Ich hab mal meine eigene VoIP-Session mitgesnifft und finde da eben in den SDP-Attributen den Schlüssel:

Media Attribute Value: 1 AES_CM_128_HMAC_SHA1_80 inline:HKuPJQx+xxwdAhij/h9zKI+lQEkKLWr1lLFkHArS

Die Zeichenfolge nach dem "inline" ist doch der Master Key, oder?
Wenn jetzt jemand irgendwie an den SRTP-Datenverkehr kommt (was weiß ich, z.B. durch Mitsniffen an nem öffentlichen Hotspot), dann könnte der doch theoretisch mit dem Master Key den Session Key erzeugen und die SRTP-Daten entschlüsseln.
Aber so, wie ich das sehe, gibts dafür glaube ich noch keine frei verfügbaren "Hacker-Tools", so dass derjenige das dann wohl erstmal selbst programmieren müsste.

Ist doch so, oder? Oder sind inzwischen doch schon Tools verfügbar, die jeder benutzen könnte?

Also, wenn nicht, dann bietet SRTP auch ohne TLS eine relative Sicherheit, weil zumindest nicht jeder dahergelaufene Möchte-Gern-Hacker die Daten entschlüsseln könnte.

Viele Grüße,
Robinix

Hallo Kai ,
danke für deine Antwort!

Also, daraus ergibt sich, dass die Zeichenfolge da oben tatsächlich der Master Key ist. Aber es ist wohl wirklich noch nicht so weit, dass es schon frei verfügbare Tools zur Entschlüsselung von SRTP gibt, selbst wenn man den Master Key hat. Allerdings arbeiten die Jungs und Mädels von Wireshark schon kräftig an einem SRTP Decryptor, hab ich gelesen...

Was TLS betrifft: Also, im IP-Phone-Forum hab ich da echt NULL Anbieter gefunden. Angeblich soll Sipgate das bieten, aber ich hab da auf der HP mal geguckt und da ist keine Rede davon. Hab selbst nen Kostenlos-Account bei Sipgate und da ist auch nix mit TLS oder SRTP oder so. Aber auch bei den Accounts mit Aufpreis steht da nix von TLS oder SIPS. 

Seufz...

Naja, danke auf jeden Fall für die Antwort!

Viele Grüße,
Robinix

Hallo,

zum Thema SIP und SIPS (SIP-über-TLS) habe ich hier und hier einige leicht verständliche Dokumentationen (deutsch) gefunden.

Zum Thema "TLS-Verschlüsselung bei VoIP-Providern" habe ich jetzt ziemlich lange gegoogelt, jedoch leider bisher keinen Provider gefunden, der so etwas zu den - für deutsche Kunden - üblichen Konditionen anbietet. Ehrlich gesagt habe ich zur Providern, die SIPS (oder TLS) öffentlich anbieten, nichts weiter gefunden, als vage Andeutungen, dass so etwas "von nicht vielen" Providern angeboten wird.

Ich vermute, das daran sowohl Kosten als auch Probleme bei der technischen Umsetzung ursächlich sind. 

Der SIP-Provider benötigt zunächst ein TLS-Zertifkat, dass - so wie die für das HTTP-Protokoll üblichen SSL-Zertifikate - von einem Trust-Center, meist befristet, verliehen wird.

Die Kosten hierfür halten sich aufgrund der hohen Anzahl mittlerweile anerkannter Trust-Center in Grenzen. Doch nur einmal theoretisch angedacht: Was nützt dem SIP-Provider, der ja nur einen SIP-Proxy zu Verfügung stellt, durch den der jeweilige Gesprächspartner gefunden werden soll, solch ein Zertifikat?

Stellt man mit Phoner(Lite) per TCP/IP eine Verbindung zum Registrar her - dem SIP-Proxy - so könnte mit diesem Server ausgehandelt werden, dass zwischen dem "eigenen" Phoner(Lite) und dem Proxy jeder Datenverkehr verschlüsselt, und zwar mit TLS, abgewickelt wird. Diese Strecke wäre demnach "abhörsicher".

Die Telefonie benötigt jedoch zwei Gegenstellen, damit das Bell'sche Konzept aufgeht: Den Anrufer, und den Angerufenen.

Um TLS demnach für beide zugänglich zu machen, sollten sich Anrufer und Angerufener beide bei dem gleichen SIP-Proxy registrieren, und beide eine vorhandene Verschlüsselungsmöglichkeit einschalten. Nur auf diese Weise macht das Zertifikat des SIP-Providers für beide Sinn.

Theoretisch: Dadurch, dass sich der "eigene" Phoner mit eingeschalteter Verbindungs-Verschlüsselung registriert hat, muss dieses Verfahren nicht zwangsläufig auch beim Angerufenen etabliert worden sein - derjenige müsste ja auch das Zertifikat des zwischengeschalteten Proxys zunächst einmal "akzeptieren" oder etwas mit einer Verschlüsselung anfangen können.

Ist der Angerufene im Festnetz mit einem üblichen analogen Endgerät zu erreichen, macht die gesamte Verschlüssung zwischen Anrufer - SIP-Proxy - Festnetz-Gateway - und Angerufenem bereits keinen Sinn mehr. Der SIP-Proxy müsste sogar für diese Verbindungstypen die Verschlüsselung abschalten, damit beim angerufenen Festnetzteilnehmer mehr als nur ein "weisses Rauschen" ankommt. Meines Wissens nach wird im mittlerweile in Deutschland flächendeckend verfügbaren digitalen ISDN-Netz eine solche "Decryption (Entschlüsselung) im Amt" noch nicht angeboten.

Grundsätzlich gilt das gleiche für angerufene Teilnehmer in Mobilfunknetzen, hierzu müssten jedoch die Endgeräte - einfach Handys genannt - eine Decryption verschlüsselter Verbindungen anbieten. Ich vermute jedoch, da sich eine solche Einstellungsmöglichkeit in meinem neuen Handy noch nicht auffinden läßt, dass der heutige Stand der Technik dieses Verfahren noch nicht in marktreifen Handys ohne Zusatzsoftware etabliert hat.

Etwas anderes ist es nun zwischen zwei Teilnehmern, die ohne den Umweg über einen Proxy direkt mit Phoner(Lite) miteinander kommunizieren. Hier macht eine Verschlüsselung per TLS zur Zeit in Hinsicht auf die Abhörsicherheit noch Sinn. Innerhalb eines Netzwerkes kann sich Phoner mit jedem anderen Phoner über SIP verbinden, wenn man die IP des Rechners des angerufenen Teilnehmers in das Wählfeld einträgt. Theoretisch - und bisher von mir noch nicht getestet - sollte dieses auch über das Internet funktionieren, wenn die öffentliche IP des angerufenen Teilnehmers dem anrufenden Teilnehmer bekannt ist, und die vorhandenen Endgeräte (Router) die VoIP-Port direkt an den Rechner des Angerufenen weitermappen.

Meinem Verständnis nach benötigte jedoch der angerufene Teilnehmer ein TLS-Zertifikat - es sei denn, die in Phoner(lite) integrierte Verschlüsselung würde automatisch anhand des übermittelten Keys eine Decryption vornehmen. Das weiß ich jedoch leider nicht, und ich hoffe, Heiko stellt Fehlannahmen meinerseits richtig.

So, wie nicht jeder mit einer Homepage eine SSL-Verschlüsselung zertifiziert hat, so wird auch nicht jeder, der VoIP-über-SIP betreibt, ein eigenes TLS-Zertifikat haben. Das bedeutete - ich spinne das einfach einmal weiter - dass die Verschlüsselung zwar vereinbart werden kann, jedoch tatsächlich nicht stattfinden sollte, wenn der angerufene Gesprächspartner das Verfahren nicht beherrscht.

Vorstehend sollten genügend Annahmen aufgezählt sein, die "noch" gegen ein weites Angebot von TLS-Verschlüsselten Verbindungen sprechen - es ist halt noch nicht die Infrastruktur vorhanden, dass ein solches Angebot auch von Kunden genutzt werden kann.

Meiner Meinung nach erreicht man bereits einen hohen Grad an Abhörsicherheit, wenn man die die eigene, interne Verbindung entsprechend absichert. Da eine Gesprächsverbindung naturgemäß nur auf der Strecke zwischen Anrufer und Angerufenem abgehört werden kann, erreicht man gerade bei SIP - das dem HTTP-Protokoll sehr ähnlich ist - eine hohe Sicherheit, wenn die eigenen Geräte durch WEP oder WPA miteinander kommunizieren. Ein Sniffer kann entweder nur im Heimnetz des Anrufers oder im Heimnetz des Angerufenen tätig werden - die dazwischen liegenden Internet-Backbones sollten sicher sein, um das Vertrauen in die jeweiligen Zugangsprovider zu rechtfertigen .

Hängt die Netzwerkkarte mit einem Kabel am Router, so sollte es jedem leicht auffallen, wenn ein weiteres Kabel in den Router eingestöpselt ist, dass nicht zum eigenen Heimnetz gehört. Soviel zu diesem Thema...

Sendet nun ein W-LAN völlig ungeschützt seine Daten an das Modem (bzw. zunächst an den Router), so wird die gesamte Umgebung mit diesen Informationen verseucht - ein Sniffer kann jederzeit und mit Leichtigkeit den Datenverkehr - hier das VoIP-Telefonat - abhören. Doch bereits eine WEP oder WPA-Verschlüsselung macht's jedem Sniffer bereits etwas schwerer - er muss zunächst einmal an die entsprechenden Schlüssel kommen, um beispielsweise den übertragenen Master-Key einer VoIP-SRTP-Verschlüsselung zu erhalten.

Betreibt nun der angerufene Teilnehmer ein W-LAN, und ist dort das interne Netz nicht WEP- oder WPA-gesichert, ist ein VoIP-Telefonat zwar noch bei ihm abhörbar - doch mal ehrlich:

Wer nutzt heutzutage noch ein ungesichertes W-LAN?

Viele Grüße vom Kai

Hallo all,

@Heiko wg. Master Key und SRTP
Du schreibts, wenn man den Master Key hat, sei es problemlos möglich, SRTP zu entschlüsseln. Also, ich hätte da schon Probleme, weil ich nicht weiß, wie ich aus dem Master Key dann den Session Key berechnen soll und wie ich mit dem den verschlüsselten Gesprächsstrom wieder entschlüsseln soll. Dazu bräuchte ich erstmal ein Tool, wo ich den Master Key eingeben könnte und der dann den Algorithmus nachfährt, um die Entschlüsselung vorzunehmen. Wenn ich schlau genug wäre, könnte ich das selbst programmieren - bin ich aber nicht . Und son fertiges Tool, wo man einen Master Key eingeben kann, gibt es meines Wissens noch nicht. Insofern ist es zur Zeit zumindest, glaube ich, nicht ohne weitere Angstrengungen möglich, ein SRTP-Gespräch zu entschlüsseln.

@Kai und Heiko wg. TLS
Ja, die Provider haben nciht son dickes Interesse daran, den Aufwand zu betreiben, TLS zu implementieren. Und nachdem, was ich von Heiko jeztt gelesen habe, ist das wohl auch nachvollziehbar. Andererseits ist eben diese Nachlässigkeit in Sachen Sicherheit auch irgendwie generell typisch - sowohl für Provider als auch für Kunden. Sicherheit ist eben ein zusätzlicher Aufwand, weil eben die Basisprotokolle TCP/IP etc. eben von der Architektur her unsicher sind.
Aber gut, wenn ich lese was Heiko schreibt mit dem zusätzlichen Overhead, ist das auch schon schwierig, TLS für VoIP zu implementieren. Aber vllt kann man ja nochmal nen Schritt zurückgehen: Es geht ja darum, dass der Master Key von SRTP nicht im Klartext über das Netz wandert. Das tut er normalerweise, weil - soweit ich das weiß - das Schlüsselaustauschverfahren MIKEY standardmäßig dafür benutzt wird. Aber man könnte ja auch ein anderes Schlüsselaustauschverfahren implementieren, bzw. eben ein Verfahren, bei dem der Schlüssel selbst nicht ausgetauscht wird, sondern nur seine Erzeugungsparameter, wie z.B. das Diffie-Hellman-Verfahren.
Da gibt es z.B. die  Software Zfone von Phil Zimmermann. Das is ne Software, die zusätzlcih zum VoIP-Client installiert werden muss und die die Schlüsselerzeugung über Diffie-Hellman herstellt.
Allerdings muss jede Seite Zfone haben bzw. das sog. ZRTP unterstützen und außerdem muss man einen Provider haben, der eine Ende-zu-Ende-Verbindung herstellt, sonst klappt es nicht.

http://zfoneproject.com/getstarted.html

Viele Grüße,
Robinix

P.S. Ich finde es klasse, dass ich mal ein paar Gedanken zum Thema verschlüsseltes VoIP austauschen kann. In dem IP-Phone-Forum besteht da eher eine gleichgültige Haltung dazu.

Zfone finde ich ja auch ganz interessant, jedoch kann man das SDK dazu nur kostenlos in GPL-Programme einbauen - und Phoner(Lite) ist eben kein solches unter der GPL vertriebenes Programm. Ich sehe nun gar nicht ein, dass ich etwas lizensieren soll und natürlich noch bezahlen. Für ein (nicht GPL-) Freeware Programm ist das einfach nicht möglich.

MIKEY ist sicherlich interessant, aber eben auch nicht mal so nebenher zu implementieren. Kennst du denn Gegenstellen (möglichst Provider), die das beherrschen?

Eine Ende-zu-Ende Kommunikation bzgl. RTP gibt es zum Beispiel bei Sipgate - zumindest war das mal so. Das geht aber nur solange, wenn beide Clients über eine öffentliche IP-Adresse verfügen. Ansonsten muss es zwangsläufig über eine öffentliche Mittelstation (Proxy) gehen.

Wenn du deinem Provider nicht vertraust, so verwendest du den falschen Provider. Du solltest also Peer-to-Peer telefonieren 

phuck wrote on 18. Aug 2010 at 21:06:

Das stimmt so nur wenn Du keinen redirect-Server benutzt, denke ich. Wenn Du einen redirect-Server benutzt, bekommt PhonerLite die direkte Adresse Deines Gesprächspartners und es besteht zumindest die Möglichkeit, dass PhonerLite den SRTP-Schlüssel noch mal neu erstellt bevor es das INVITE an diesen Gesprächspartner direkt verschickt. Dann sollte niemand mehr mithören können da der SRTP-Schlüssel nur den beteiligten SoftPhones bekannt ist.

Heiko, macht das PhonerLite oder verwendet es den gleichen SRTP-Schlüssel wie bei dem INVITE an den registrar?

Die aktuelle Version von PhonerLite (1.80)  unterstützt nun ZRTP. In den nachfolgenden Beta-Versionen werde ich versuchen etwaige Probleme diesbezüglich noch zu eliminieren.
Mit ZFone ist es zumindest schon mal kompatibel