Ende zu Ende RTP Verschlüsselung

Ein großes Thema bei Teams, WhatsApp, Zoom und anderen Plattformen ist die Frage der Verschlüsselung. Viele Personen setzen Verschlüsselung und Sicherheit gleich, obwohl es unterschiedliche Schuhe sind. Verschlüsselung ist nur ein Teil der Sicherheit aber wenn dann noch von Ende-zu-Ende Verschlüsselung gesprochen wird, dann wird es schnell unübersichtlich.

[MC259495] Microsoft Teams: End-to-end encryption option for Teams 1:1 VoIP Calls
https://www.microsoft.com/en-ww/microsoft-365/roadmap?filters=&searchterms=70780

Was erhoffen wir uns?

Natürlich möchten wir, dass auch unsere elektronische Kommunikation so sicher bleibt, wie das Briefgeheimnis, welches übrigens auch nur ein Gesetz war aber allzu oft ignoriert oder locker betrachtet wurde. Per Software ist aber Verschlüsseln und Entschlüsseln denkbar einfach, wenn die beiden Endpunkte sich auf ein Verfahren und entsprechende Schlüssel einigen können. Schon der Schlüsselaustausch ist eine Herausforderung, wenn ein Prozess dazwischen die Kommunikation beeinflussen kann.

"Ende zu Ende" bedeutet aber, dass die Verschlüsselung wirklich die beiden Endpunkte betrachtet und alle Zwischenstationen und deren Übertragungswege irrelevant sind. Idealerweise verschlüsselt die Applikation die Daten für den Empfänger ganz am Anfang und der Empfänger ist der Einzige, der die Daten wieder lesbar machen kann. So funktioniert dies z.B. bei E-Mails, die per PGP oder SMIME verschlüsselt sind. Der Transportweg kann dabei selbst unsicher sein, da die übertragene Nachricht in sich verschlüsselt ist.

Siehe auch Ende zu Ende Mail Verschlüsselung

Mit SMIME/PGP ist dies technisch möglich. wenn jeder Teilnehmer einen passenden privaten und öffentlichen Schlüssel hat.

Verschlüsselung mit Echtzeitdiensten

Etwas anders sieht es mit "Echtzeitdiensten" aus. Wenn Sie an WhatsApp u.a. denken, dann ist eine 1:1 Verschlüsselung durchaus möglich. Sie müssen sich aber das Schaubild betrachten. Der Client bzw. die App verbindet sich mit dem "Vermittlungsserver", welche die Nachricht nur kurz speichert, bis sie vom Ziel abgeholt wurde. Die Verbindung der Clients zum Service erfolgt heute natürlich verschlüsselt:

Allerdings hat jede Verbindung ihren eigenen Schlüssel und der Server sieht die Nachricht natürlich auch im Klartext. So funktioniert z.B. SIP/TLS, welches von VoIP-Systemen genutzt wird. Diese Lücke kann ein Anbieter nun so füllen, dass er den Client zusätzlich befähigt einen eigenen Schlüssel zu erzeugen, dessen öffentlicher Teil über diese noch nicht Ende2Ende-verschlüsselte Wege übertragen werden.

Diese Verfahren kennen Sie vielleicht von WhatsApp, bei dem jeder Anwender einen eigenen Schlüssel erstellt und sobald jemand sein Smartphone wechselt, bekommen Sie auch die Meldung, dass sich dessen Schlüssel geändert hat.

Bei WhatsApp nutzen sie in der Regel auch nur genau ein Endgerät. Seitens des Herstellers wird gar keine andere App angeboten und "WhatsApp Web" ist ja nur ein Browser, der die Smartphone-App quasi fernsteuert. Im Consumerbereich ist es auch eher unkritisch, wenn ein Anwender seinen Key verliert oder nicht auf andere Geräte übertragen kann. Der neue Key wird dann veröffentlicht und alle Partner bekommen eben die Warnung. Im Firmenumfeld ist so etwas natürlich ungeeignet, da hier Anwender durchaus unterschiedliche Endgeräte auch parallel nutzen.

Aber selbst mit persönlichen Schlüsseln müssen Sie natürlich der App vertrauen, dass diese die Daten nicht unbemerkt ausleitet, den privaten Schlüssel in die Anbieter-Cloud hochlädt oder dies auf Anforderung macht. Genau genommen ist die Existenz von "WhatsApp Web" ja gerade das Beispiel, dass eine Kommunikation eines Browsers über die Infrastruktur bis zur App auf dem Smartphone möglich ist. Da der Browser per HTTPS bei Whatsapp terminiert, hat der Anbieter Zugriff auf alle auf dem Client gespeicherten Informationen.

Das relativiert dann schon die Aussage einer sicheren verschlüsselten Kommunikation. Da auch die App immer wieder aktualisiert wird und die App selbst lokal immer Zugriff auf die Informationen hat, könnte das Verhalten der App anhand gerichtlicher Vorgaben natürlich auch pro "Ziel" geändert werden. So etwas kann der Anwender nicht erkennen. Theoretisch könnte ein Staat ja auch eine "länderspezifische App" fordern. Die AppStores und PlayStores haben ja schon bewiesen, dass Sie je nach Land andere Apps vorhalten.

Verschlüsselung mit SRTP (Audio/Video)

Ende zu Ende Verschlüsselung ist aber keine Erfindung von WhatsApp (mittlerweile Facebook). Die "Realtime-Produkte" von Microsoft, beginnend beim Exchange Chat Server über Live Communication Server (LCS), Office Communication Server (OCS), Lync Server und Skype for Business bis zu Teams arbeiten generell verschlüsselt. Hier muss man aber etwas genauer hinschauen, denn es gibt zwei Kommunikationskanäle.

  • Signalisierung (SIP/TLS)
    Damit ist klassisch das SIP-Protokoll über den Port 5061 oder als Tunnel in 443 gemeint, welches verschlüsselt ist. Hier handelt es sich aber nicht um eine echte Ende-zu-Ende-Verschlüsselung, denn die Verbindung ist nur zum nächsten Hop verschlüsselt. Der Server muss den Inhalt ja zumindest soweit verstehen können, um das Routing zu bedienen. Auch die Nutzlast muss der Server verstehen und selbst befüllen, da hier ja auch der Server die "Gegenstelle" ist. Der Server sendet von sich aus ja Konfigurationsinformation, Präsenzinformationen der Kollegen und akzeptiert vom Client auch Statusupdates etc.
    Bei einer E-Mail-Übertragung per SMTP wird der Header der Mail aber auch nicht verschlüsselt
  • Message in der Signalisierung
    Über das gleichen Protokoll werden aber auch Text-Mitteilungen, also "Chats", übertragen. Diese sind bei Skype for Business und früher nicht Ende-zu-Ende-Verschlüsselt. Der Server kann also "mitlesen", was aber auch Funktionen wird Archivierung und "Ethical Wall", Malwarefilter, SPIM-Filter erlaubt. Hier gilt es dann abzuwägen, ob eine richtige Ende-zu-Ende-Verschlüsselung wichtiger ist oder andere Faktoren die "Mitarbeit" des Server  erforderlich machen.
  • Audio/Video
    RTP-Daten (Audio/Video/Desktop-Sharing) werden nicht über den Kanal der Signalisierung gesendet, sondern bauen einen eigenen Kommunikationskanal auf, da muss es ja "schnell" und ohne Umwege gehen. Daher übertragen die beiden Endpunkte entsprechende Kandidaten (Siehe ICE, Kandidaten, STUN und TURN und SDP - Session Description Protocol) und bauen eine Verbindung auf. Die "Payload" kann dabei auch verschlüsselt werden. Allerdings werden die "Crypto Keys" über die Signalisierung übertragen und sind damit durch den Server einsehbar aber auch modifizierbar. Zudem wird nur die Nutzlast verschlüsselt aber auf dem Weg kann man durchaus erkennen, welcher Codec verwendet wird und damit auf Audio bzw. Video schließen. Allerdings weisen Audio und Video-Verbindung auch charakteristische Paketdaten (Anzahl und Größe) auf, anhand derer sie sich selbst bei verschlüsselten Verbindungen verraten.

Insofern kann bei der Übertragung der Sprache und Bilder von einer Ende-zu-Ende-Verschlüsselung gesprochen werden, bei der aber der Vermittlungsserver eine kritische Komponente ist.

Der "rote" Schlüssel ist ein einmaliger "Session Key", der aber über die Signalisierung übertragen wird.

N:M Chat

Interessanter wird das Bild, wenn drei oder mehr Personen miteinander kommunizieren. Alle nutzen den Service im Hintergrund, um die Informationen auszutauschen. Jeder Client baut erst einmal seine eigene verschlüsselte Verbindung zum Service auf, über welche die Anmeldung am Service und ggfls. Konfiguration des Clients gesteuert wird.

Wie auch beim 1:1 Chat werden bei Skype for Business und Microsoft Teams über die gleiche Verbindung nicht nur der Status sondern auch einfache Nachrichten übertragen. Eine individuelle Schlüsselverwaltung je Benutzer ist hier nicht vorgesehen. Das gilt auch bei n:m-Konferenzen.

Wenn der Client, wie bei WhatsApp, einen individuellen Key nutzt, dann wird die Kommunikation mit mehreren Personen genauso aufwändiger, wie Sie das bei SMIME schon kennen. Jeder Teilnehmer muss alle Schlüssel aller Teilnehmer haben und die Information entweder zu jedem Teilnehmer individuell verschlüsselt senden oder einen "Gruppenkey" erstellen, der dann mit allen Teilnehmern geteilt wird.

Gegen einen Gruppenschlüssel spricht, dass dieser wieder übertragen werden muss und damit auch in falsche Hände fallen kann. Die Nutzung der individuellen Schlüssel hingegen bedeutet, dass die Nachricht mit einem symmetrischen Schlüssel verschlüsselt wird und dieser Key mit den individuellen Schlüsseln der Personen verschlüsselt mitgeschickt werden. So macht SMIME das auch

Allerdings decodieren meines Wissens nach alle Clients wie WhatsApp, Telegram etc. die verschlüsselt empfangenen Meldungen und speichern diese ab. Ansonsten können Sie z.B.: bei einem Gerätewechsel mit Neuerstellung eines eigenen Schlüssels ihre früheren Nachrichten nicht mehr lesen. Zumindest von WhatsApp weiß ich, dass z.B. verschlüsselt empfangene Bilder unverschlüsselt im Dateisystem des Smartphone landen.

N:M Meeting

Eine weitere Steigerung bedeutet die Übertragung von Echtzeitdaten (Audio/Video/Sharing) in einer Konferenz. Es macht einfach keinen Sinn, die Daten vom Sender zu jedem Empfänger individuell zu übertragen.

Schon mit vier Teilnehmern wird das sehr viel und steigt mit jedem weiteren Teilnehmer stärker an. Konferenzen werden daher immer über eine oder mehrere "MCUs" (Multicast Uniits) betrieben. Jeder Client sendet seine Daten dort hin und die MCU mixt für jeden Teilnehmer das resultierende Signal.

Das bedeutet aber auch hier, dass die MCU die vom Sender empfangenden Daten decodieren und entsprechend neu zusammensetzen muss. Der Entwickler einer MCU muss überlegen, wie er zwei Herausforderungen löst:

  • Downscaling
    Wenn Teilnehmer1 ein HD Video sendet und Teilnehmer 2 dieses anfordert, dann kann die MCU die Nutzdaten einfach routen. Wenn aber ein anderer Teilnehmer aufgrund der Bandbreite oder Technik nur SD Video der gar kein Video braucht, dann darf die MCU keinen HD-Stream senden, sondern sollte die passende Auflösung mit der reduzierten Datenrate senden.
    Früher haben MCUs dazu das HD-Video herunter gerechnet und das gibt es heute immer noch. Solche MCUs sind daher teure Spezialisten mit Video-Verarbeitung auf eigenen Chips-
  • Video-Kacheln
    Die zweite Anforderung ist die Übertragung mehrerer Bilder. Wenn mehrere Teilnehmer ihr Bild senden, dann muss die MCU daraus einen neuen Stream mit "Kacheln" machen. Das war früher auch sehr aufwändig, da nun mehrere HD-Streams erst decodiert, dann herunter gerechnet, neu zusammengesetzt und wieder codiert werden mussten.

Da diese zentrale Transcodierung sehr mühsam ist, nutzen fast alle modernen Systeme aktuelle Codecs wie "H.264 SVC", die gleich mehrere Streams senden. Skype for Business und Teams senden dann mein Video nicht als HD-Streams sondern als Bild mit niedriger Auflösung, einen zweiten Stream, um die Differenz zu SD abzubilden und einem dritten Streams, der dann die Informationen für ein HD-Bild enthalten. So muss de MCU die Streams nicht mehr umbauen sondern leitet nur den Teil weiter, der angefragt wird und kann bei schlechten Übertragungswegen auch Streams einfach abschalten.

Für die Verschlüsselung könnte das aber nun bedeuten dass jeder Stream individuell verschlüsselt ist aber alle Teilnehmer je Stream den gleichen Schlüssel nutzen. Wenn Sie aber z.B. auf einem Server eine Aufzeichnung starten wollen, dann muss auch der Server eine entschlüsselbare Version erhalten und die MCU muss natürlich auch über die einzelnen Streams bescheid wissen.

Ich sage nicht, dass unmöglich ist bei Audio/Video-Konferenzen eine durchgängige Ende-zu-Ende-Verschlüsselung zu erreichen. Allerdings gibt es auch Nachteile und letztlich ist zu prüfen, ob die Aussagen des Marketings der Realität entsprechen.

Das Problem der meisten Lösungen ist die fehlende Möglichkeit einer Verifizierung. Nur weil sie per Wireshark nur SSL-Verbindungen zum Server oder SRTP-Verbindungen zu einer Gegenstelle sehen, ist das noch keine Garantie, dass die Daten wirklich durchgängig verschlüsselt bleiben. Da heute sowohl der Client als auch der Service unter der Kontrolle des Anbieters stehen und kontinuierlich weiter entwickelt werden. Eine Lösung kann so besser aber auch schlechter werden, ohne dass sie es merken.

Teams

Am 3. März 2021 hat Microsoft einen neuen Punkt auf die Roadmap gesetzt:


Quelle: https://www.microsoft.com/en-ww/microsoft-365/roadmap?filters=&searchterms=70780

Das bedeutet aber nicht, dass Teams-Anrufe nicht schon vorher verschlüsselt waren. Die SRTP-Verschlüsselung gibt es schon immer aber wenn eine MCU oder eine andere aktive Komponente in der Mitte ist, endet die SRTP-Verbindung dort und die Software selbst kann die unverschlüsselten Daten sehen. Eine zweite Sache ist natürlich die Übermittlung der Encryption-Schlüssel innerhalb des Signalisierung (SIP bei Skype for Business und HTTPS bei Teams). Hier kann jemand den Key auslesen oder durch einen eigenen Key ersetzen.

Auch wenn die technischen Details noch nicht öffentlich sind, dürfte es wie bei Mitbewerbern darauf hinauslaufen, dass die VoIP-Endpunkte nach dem Verbindungsaufbau per RTP/SRTP eine eigene Verschlüsselung aushandeln, die nicht mehr über die Signalisierungsserver läuft.

Damit kann auch keine Zwischenstelle mehr mitlauschen. Damit sind natürlich auch Einschränkungen verbunden, wenn eine Erweiterung durch einen Service oder Bot bereitgestellt wird

  • Keine "Transcription"
    Dieses Feature erfordert ja gerade, dass der Service mithört und die Sprach zum Text übersetzt und einblendet.
  • Keine Aufzeichnung auf dem Server
    Sie können alternativ natürlich auf dem Client eine Aufzeichnung mit 3rd Party Tools anfertigen.
  • Meetings ohne Video
    Bei einem klassischen Meeting sendet jeder Teilnehmer seine Sprache/Bilder an die Konferenz-MCU, die im Mittelpunkt steht. Bei einer Durchverschlüsselung kann die MCU nur noch die verschiedenen Streams weitergeben. Das verursacht mehr Bandbreite und insbesondere ein "Mixing" von Videos ist nicht mehr möglich. Daher wird Video zumindest am Anfang nicht möglich sein.

Die Funktion kann durch den Administrator gesteuert und durch den Benutzer in den Einstellungen aktiviert werden:

Öffentliche Vergleiche

Ehe ich eine eigene Test-Serie dokumentiere, habe ich diverse Vergleichstests unterschiedlicher Quellen gesucht und es gibt durchaus einige Gegenüberstellungen anderer Medien und eine Liste der NSA gefunden:


Quelle: https://media.defense.gov/2020/Jun/03/2002310066/-1/-1/0/CSI-SELECTING-AND-USING-COLLABORATION-SERVICES-SECURELY-SHORT-20200602.PDF (19. Jun 2020)

Schon auf den ersten Blick ist diese Tabelle unstimmig. Ich kann mir erst einmal nur ein Urteil über Skype for Business und Teams erlauben. So wird bei "Skype for Business" eine "E2E Encryption" bestätigt, die aber definitiv nicht der Fall ist. Die SIP-Verbindung garantiert nur die Übertragungsverschlüsselung aber die Skype for Business Server haben die SIP-Message und damit auch die SRTP-Schlüssel und die Instant Message in unverschlüsselter Form. Sie können ja auf dem Server einfach mal das CLSLogging mit den Skype für Business DebugTools und Snooper (OCSLogger) anschauen. Solche Funktionen dürften dann nicht gehen.

Aus dem Skype for Business Client Trace kann ich auch auslesen, dass jeder Teilnehmer in einer Konferenz einen eigenen SRTP-Schlüssel bekommt und damit jemand auf dem Weg, die MCU in diesem Fall, die Pakete entschlüsseln und für das jeweilige Ziel neu verschlüsseln muss.

Bei Microsoft Teams steht ein "Nein" bei "E2E Encryption". Das ist korrekt, denn sonst könnte man ja keine Meeting-Aufzeichnung auf dem Server starten und auch keine früheren Nachrichten in einem Chat lesen, zu dem man nachträglich addiert wurde. Auch die Compliance-Funktion eDiscovery u.a. in den Teams und Kanälen kann ja nur funktionieren, wenn die Daten dem Service in Klartext vorliegen. Das widerspricht ja nicht der Verschlüsselung auf dem Übertragungsweg und der Ablage auf den Massenspeichern, z.B.: per Bitlocker. Aber es ist eben nicht E2E-Encryption und wird es wohl auch nicht werden.

Reine Konferenzanbietet wie Zoom, Vidyo, WebEx, GoToMeeting etc., die nur Audio/Video über ihre MCUs an die eigenen Clients verteilen aber keine Daten speichern, können eine E2E-Encryption einfacher umsetzen. Teams aber auch Slack, Facebook Gruppen etc. können dies nicht. Die Frage der E2E-Encryption sollte daher nicht pro Produkt sondern pro Funktion gestellt werden.

Eigene Tests

Ich bin weder ein TÜV, noch eine NSA oder ein Datenschutzbehörde. Aber auch bei verschlüsselten Protokollen und Produkten können Sie den Clients auf die Finger schauen. Das funktioniert nicht für die Control-Verbindung ihres Clients zu ihrem Server aber bei RTP-Daten, also Audio/Video kann ein Vergleich per Wireshark zwischen zwei Clients durchaus gelingen. Ich habe daher in Teams und Zoom ein Meeting gestartet und mich mit zwei Clients in das Meeting verbunden. Wenn es eine E2E-Encryption gibt, dann könnten die ausgehende Payload beim Teilnehmer 1 und die eingehende Payload beim anderen Teilnehmer 2 gleich sein. Sie müsse nicht gleich sein, da theoretisch der Anbieter sowohl die Daten durch den Codec als auch durch die SRTP-Verschlüsselung verändern können.

Ich habe mehrere Wireshark-Mitschnitte angefertigt, die UDP-Streams darin eingesammelt und die Payload verglichen. Ich habe weder bei Zoom noch bei Teams zwei Streams gefunden, die binäre identisch aber von der Datenmenge schon nahezu gleich waren. ich interpretiere das so, dass ein Client sein Audio mit Cryptokey1 verwendet und die MCU mit einem anderen Cryptokey diese Daten zum anderen Client zurück gesendet hat. Die MCU hat zumindest die Pakete selbst umcodiert.

Dies ist eine Momentaufnahme vom 24. Jun 2020 und kann von den Anbietern natürlich geändert werden. Eventuell verhält sich Zoom "Free-Version" auch anders als die kommerzielle Version.

Ich kann auch nicht ausschließen, dass innerhalb der verändert verschlüsselten Codec die Inhalte noch einmal zusätzlich symmetrisch verschlüsselt wurden. Alles kann aber ob ein Anbieter wirklich E2E-Encryption nutzt, konnte ich nicht bestätigen.

Weitere Links