Niemand verbietet einem Provider die Verschlüsselung vom Kunden bis zu seinem System und niemand verbietet (bisher) einem Kunden, sich direkt mit der Gegenstelle "ins Benehmen zu setzen" und dabei SRTP auszuhandeln.
Was der Provider bei einer Überwachungsmaßnahme zu übermitteln hat, ist klar geregelt und z.B. hier:
https://www.bundesnetzagentur.de/Sh....0 pdf deutsch.pdf?__blob=publicationFile&v=1 nachzulesen. Der Punkt 5.5 im Anlage H (S. 117) ist da ziemlich eindeutig - und der Kommentar in der rechten Spalte zeigt auch auf, daß ein Provider nur den Session-Key bereitstellen muß, wenn der über seine Infrastruktur ausgetauscht wurde (ansonsten hat er ihn ohnehin nicht).
Das heißt, es gibt derzeit faktisch keine einzige sichere Kommunikationsmethode per Telefon?
Das ist ja eine vollkommen neue Erkenntnis: https://www.youtube.com/watch?v=4zUZwih19R0&feature=youtu.be&t=7
Inwieweit hat sich die Situation denn jetzt für die Kunden eines Providers dadurch verschlechtert, daß dieser auf VoIP setzt anstelle der "klassischen" Telefonie? Genau ... gar nicht. Die Ausleitung des Verkehrs hat (im Rahmen einer TKÜ-Maßnahme) bei leitungs- oder paketvermittelten Verbindungen genauso zu erfolgen, wie bei SIP/RTP - nur ist da schon mal gar keine Verschlüsselung möglich. Außer ggf. ein "scrambler" auf beiden Seiten, der als Zusatzgerät die Audio-Daten verschlüsselt - was bei RTP immer noch (bei verlustloser Kompression) machbar wäre.
Eine Verschlüsselung kann trotzdem noch sinnvoll sein ... denn im Gegensatz zu einer vollkommen unverschlüsselten Verbindung (wo dann sogar an beiden Endpunkten und bei jedem am Transport beteiligten Router ein einfacher Paketmitschnitt ausreicht, um ein Gespräch zu extrahieren), kann dann das Risiko des "eavesdropping" auf die beiden Endpunkte beschränkt werden. Das ist ja auch der Grund, warum die Schlapphüte immer wieder von "Quellen-TKÜ" träumen (aka Bundestrojaner), weil sie dann die noch unverschlüsselte Kommunikation abfangen können und auch in Ende-zu-Ende-verschlüsselte Verbindungen "hineinhorchen" könnten.
Deshalb ist auch die "These" im anderen Thread:
zwischenzeitlich sollte dem geneigten Leser hinreichend bekannt sein, dass deutschen Providern eine echte Ende-zu-Ende-Verschlüsselung aufgrund der gesetzlich vorgeschriebenen Möglichkeit auf Bestandsdatenabfrage grundsätzlich verwehrt wird.
eigentlich Quatsch ... die "deutschen Provider" können auch nicht verhindern, wenn die Kunden Ende-zu-Ende-verschlüsselt telefonieren. Das Einzige, was tatsächlich stimmt, ist das fehlende (bzw. nicht wirklich erkennbare) Bemühen der Provider, auch über Interconnects hinweg eine Verschlüsselung zu realisieren.
Außerdem liegen die "Bestandsdaten" (§111 Abs. 1 TKG) ohnehin immer vor, was soll das also mit der "gesetzlich vorgeschriebenen Möglichkeit auf Bestandsdatenabfrage" zu tun haben, ob ein Provider Verschlüsselung anbietet oder nicht?
Das kann dann aber tatsächlich auch noch damit zusammenhängen, daß bei "lawful interception" kein anderes Routing erfolgen darf, wenn der Belauschte (aus Sicherheitsperspektive kann man auch schreiben: der Angegriffene) nicht mißtrauisch werden soll und das soll auch nach der TR TKÜV verhindert werden:
Soll die Überwachung der Nutzinformation durch ein spezielles Routing, z.B. zu einem zentralen Netzknoten erfolgen, muss besonders darauf geachtet werden, dass dies gemäß § 5 Abs. 4 TKÜV nicht durch die VoIP-Teilnehmer festgestellt werden kann.
Wenn zuvor bei Telefonaten per "direct media" eine Ende-zu-Ende-Verbindung mit Verschlüsselung ausgehandelt wurde und plötzlich endet die verschlüsselte Verbindung irgendwo beim Provider, ist das natürlich zumindest mal ein Fingerzeig.
Aber das ist bei RTP ohnehin alles nicht ganz so einfach, wie es manchmal den Eindruck macht ... man braucht nur mal an die unterschiedlichen Paketgrößen bei RTP denken, die von den Gateways unterschiedlicher Provider "aufgerufen" werden und es gibt auch so schon genug Gründe, warum eine SIP/RTP-Verbindung zwischen zwei Teilnehmern bei unterschiedlichen Providern in die Hose gehen kann.
Da braucht es die zusätzliche Verschlüsselung gar nicht mehr und insofern kann man die Provider auch irgendwo verstehen, wenn sie nur da tatsächlich auf Verschlüsselung setzen (so wie easybell im eigenen Netz), wo sie auch alle Stationen auf dem Weg "unter Kontrolle" haben. Solange der Provider gar nicht der Peer bei einer Verbindung ist, die im Rahmen einer Überwachungsmaßnahme komplett "ausgeleitet" (bzw. "kopiert") wird, kann er auch die Informationen gemäß Anlage H, Punkt 5.5 nicht bereitstellen.
Wer tatsächlich vertraulich kommunizieren will, greift dann eben zu anderen Methoden (z.B. einem Whatsapp-Call, wenn man daran glaubt, daß dabei die Ende-zu-Ende-Verschlüsselung greift und bis das Gegenteil bewiesen wurde -
https://www.whatsapp.com/security) oder direkter Kommunikation (ob per SRTP oder VPN, ist dabei egal). Telefonie ist (und war schon immer) abhörbar, SMS genauso (Stichwort SS7 und was man damit alles anstellen kann, um selbst mTANs abzufangen) und auch bei E-Mail ist der Vergleich mit der Postkarte ja offensichtlich.
Wer auf die Idee kommt, mit einem dieser Medien wirklich vertrauliche Informationen zu übermitteln, dem ist nicht mehr zu helfen ... nicht ganz umsonst machen diverse Firmen (z.B. secunet AG, die m.W. auch für die VPN-Boxen nach TR TKÜV zuständig sind) auf diesem Gebiet ihr Geschäft und von den "Krypto-Handys" hat sicherlich auch schon jeder mal etwas gelesen.
Wie weit diese Kenntnis jetzt tatsächlich die TKÜ "ausbremst", kann sich jeder selbst ausrechnen ... am Ende werden bei solchen Maßnahmen nur die "Ahnungslosen" oder die "Unvorsichtigen" tatsächlich in einer Weise kommunizieren, die sich "belastend" auswirken kann.
Die sogenannten "Meta-Daten" (also wer, wann, mit wem, wie lange kommuniziert hat - IRI im Jargon der TR und in
§7 TKÜV aufgeführt) sind auch bei SRTP weiterhin zugänglich (weil sie im SIP-Protokoll vorliegen) und können auch nur max. zwischen Provider und Kunde verschlüsselt werden, wenn man SIPS verwendet (wobei der Provider sie dann bei einer TKÜ-Maßnahme wieder ausleiten muß - und kann), weil irgendjemand das ja mal "entziffern" muß, wohin das VoIP-Telefonat nun eigentlich gehen soll.
-------------------------------------------------------------------------------------------------
Und um noch mal zu den "Bestandsdaten" zurückzukommen ... schaut man sich Dienste wie posteo.de an, wundert man sich aufgrund der ziemlich weitreichenden "Schnüffelbefugnisse" in D vielleicht, wie man dort ein Postfach anbieten kann, für das mit
Anmeldung ohne Angabe persönlicher Daten
geworben wird, aber auch das steht eigentlich im §111 TKG:
(2) Die Verpflichtung zur unverzüglichen Speicherung nach Absatz 1 Satz 1 gilt hinsichtlich der Daten nach Absatz 1 Satz 1 Nummer 1 und 2 entsprechend für denjenigen, der geschäftsmäßig einen öffentlich zugänglichen Dienst der elektronischen Post erbringt und dabei Daten nach Absatz 1 Satz 1 Nummer 1 und 2 erhebt, wobei an die Stelle der Daten nach Absatz 1 Satz 1 Nummer 1 die Kennungen der elektronischen Postfächer und an die Stelle des Anschlussinhabers nach Absatz 1 Satz 1 Nummer 2 der Inhaber des elektronischen Postfachs tritt.
Entscheidend sollte hier das "und dabei Daten [...] erhebt" sein ... was der Provider (bei E-Mail geht das, bei Telefonie seit einiger Zeit nicht mehr, seitdem die Authentifizierungspflicht auch bei Prepaid-SIMs eingeführt wurde) nicht an Daten erhebt bzw. erhoben hat, kann er auch nicht weitergeben, wenn er darüber Auskunft erteilen soll.
Und das ist eben bei posteo.de dann "Firmenphilosophie" (
https://posteo.de/site/datenschutz/) ... es werden einfach keine Bestandsdaten erhoben und gespeichert. Es geht also (zumindest bei E-Mail) auch anders ... wenn sich eine Firma das "traut".
Die immer wieder gerne genommene "Ausrede", die deutschen Gesetze ließen einem gar keine andere Wahl, ist auch immer "leicht gelogen" - die meisten dieser Anbieter nehmen halt nur den Schutz der Daten ihrer Kunden lange nicht so wichtig, wie die diversen "Schweinereien", die sie selbst gerne mit solchen Daten machen ... und dafür müssen sie diese Daten eben erst mal erheben und geraten damit automatisch in die Speicher- und Auskunftspflicht. Das (also die "bequeme Ausrede", man könne ja gar nicht anders) dürfte am Ende auch für die Frage der Verschlüsselung von RTP-Verbindungen gelten ...
