Die Maßnahmen zur Eindämmung der Coronavirus-Pandemie haben zu einer erheblichen Zunahme der Nutzung von Videokonferenzen geführt, sei es für die Einbindung von Heimarbeitsplätzen oder um Präsenztreffen mit Geschäftspartnern zu ersetzen. Dabei spielt die Vertraulichkeit der Kommunikation eine große Rolle, um Datenschutz und Datensicherheit von Geschäftsgeheimnissen gerecht zu werden.
Begriffsverwirrung
Eine übliche Forderung ist dabei die Ende-zu-Ende-Verschlüsselung, die in den letzten Jahren im Rahmen von E-Mail-Verschlüsselung Bekanntheit erlangt hat. Gemeint ist damit üblicherweise, dass die Kommunikation zwischen dem Endgerät eines Nutzers bis hin zum Endgerät eines anderen Nutzers so geschützt ist, dass keine dritte Partei, insbesondere nicht die Dienstleister, die die Kommunikation transportieren, Einsicht in die Kommunikation nehmen können, also die Vertraulichkeit auch auf den weiterleitenden E-Mail-Servern selbst und nicht nur auf den Kommunikationsverbindungen zwischen den Email-Servern gewahrt bleibt. Im E-Mail-Bereich wird dafür beispielsweise PGP verwendet.
In einer technischen Diskussion wird Ende-zu-Ende-Verschlüsselung allerdings auch abstrakter als eine Eigenschaft zwischen den beteiligten Kommunikationsparteien auf Ebene des verwendeten Kommunikationsprotokolls verwendet. Die beteiligten Parteien des verwendeten Protokolls oder der dabei betrachteten Verbindung sind aber nicht notwendigerweise die mit Hilfe dieses Protokolls kommunizierenden Personen, die Informationen auf zwischenmenschlicher Ebene auszutauschen.
So kann man beispielsweise in einer Studie zur Sicherheit von WebRTC lesen: „[…] allowing WebRTC to offer end-to-end encryption between peers with almost any server arrangement.” [1] Das Wort “peers” meint dabei nicht, wie man interpretieren könnte, die menschlichen Kommunikationspartner, sondern auf einer technischen Ebene die miteinander kommunizierenden Systeme. Dies sind aber bei Videokonferenzen oft nicht die Geräte der Nutzer, sondern das Gerät jedes Nutzers mit dem Server des verwendeten Dienstleisters. Gemeint ist also eine Transportverschlüsselung.
Wird nun diese in technischen Dokumentationen gefundene Formulierung wortwörtlich und unreflektiert in Webseiten und Werbematerialien übernommen, ohne dabei eine inhaltliche Anpassung an die zu vermittelnde Botschaft vorzunehmen, ergeben sich daraus attraktive Formulierungen von Videokonferenzdiensten, die Ende-zu-Ende-Verschlüsselung anpreisen, damit aber nur die Verschlüsselung zwischen Endgerät und Dienstanbieter meinen. Diese Interpretation wurde kürzlich prominent bei Zoom kritisiert [2], findet sich aber auch in vergleichbarer Form bei anderen Konferenzanbietern. Auch das BSI formuliert: „Bei Einsatz einer MCU kann jedoch keine echte Ende-zu-Ende-Verschlüsselung der Medienströme erreicht werden. Eine Ende-zu-Ende-Verschlüsselung kann nur in dem Sinne erreicht werden, dass die Medienströme zwischen Teilnehmer und MCU verschlüsselt werden.“ [16] (Hervorhebung durch den Autor) [MCU steht für „Multipoint Control Unit“, die zentrale Stelle in Multi-Party Videokonferenzen, die alle Videoströme der Teilnehmer entgegennimmt, sie zu einem Strom zusammenmischt, z.B. auch Telefoneinwähler in das Audio einfügt, und den Strom wieder an alle Teilnehmer verteilt.]
Die Sicherheit einer Ende-zu-Ende-Verschlüsselung hängt insbesondere auch vom verwendeten Schlüssel ab. Neben bestimmten Qualitätseigenschaften, die hier nicht thematisiert werden sollen, ist es für die Effektivität der Verschlüsselung essentiell, dass nur die intendierten Parteien über den verwendeten Schlüssel verfügen. Bei verschiedenen Diensten wird jedoch der Schlüssel zentral auf der Plattform des Anbieters erzeugt und dann an die Endgeräte verteilt. Selbst bei einer korrekt implementierten Ende-zu-Ende-Verschlüsselung im engeren Sinne ist unter diesen Umständen die Vertraulichkeit der Kommunikation trotzdem nicht gewahrt, da der Dienstanbieter mit Hilfe des ihm bekannten Schlüssels den Datenverkehr, der üblicherweise weiterhin über dessen Systeme abgewickelt wird, entschlüsseln kann.
Zielstellung
In diesem Beitrag werden verschiedene Online-Konferenz-Dienstanbieter untersucht. Anhand der verfügbaren Dokumentation und Anpreisungen wird erarbeitet, welcher Dienst eine effektive Ende-zu-Ende-Verschlüsselung von Medienströmen zwischen den Geräten der kommunizierenden Menschen unterstützt. Dabei wird nur Bezug genommen auf Audio-/Videoströme von Videokonferenzen; andere damit oft verbundene (und entsprechend angepriesene) Teilfunktionen wie Chat, Dateiübertragung, Bildschirmübertragung oder Whiteboard werden nicht betrachtet. Außerdem wird insbesondere auf den Fall von Konferenzen mit mehr als zwei Teilnehmern eingegangen, deren Implementierung sich von einer reinen 1:1-Verbindung zwischen nur zwei Teilnehmern unterscheiden kann.
Nicht betrachtet werden Videokonferenzlösungen, deren beteiligte Serverkomponenten in eigener Regie betrieben werden, wie beispielsweise Matrix, Jitsi, BigBlueButton oder NextCloud Talk. In diesen Fällen bleibt die Hoheit der Daten im eigenen Unternehmen und unterliegt damit den etablierten Sicherheitsmaßnahmen und Datenschutzregelungen, die auch für das an der Kommunikation beteiligte Endgerät und seinen Nutzer gelten. Auch nicht betrachtet werden Hardwarelösungen der im weiteren betrachteten Software-Anbieter.
Ebenfalls nicht weiter betrachtet wird der Schutz der Metadaten. Es sollte angenommen werden, dass der Dienstanbieter zur Vermittlung von Gesprächen und dem Einleiten von Konferenzen Kenntnis von den äußeren Umständen der Kommunikation erhält, also mindestens Beginn und Ende der Konferenz, IP-Adressen der beteiligten Parteien und ggf. deren Namen und weitere Kontaktdaten sowie ggf. ergänzende, im Portal gepflegte Informationen wie die Agenda.
Indizien
Die Untersuchung der verschiedenen Plattformen gestaltet sich relativ schwierig, da es nicht immer gelingt, belastbare Dokumentation der Anbieter zu eruieren. Gefundene Dokumentation ist teilweise unvollständig, oberflächlich oder sogar in sich widersprüchlich. Oft muss daher mit Hilfe von Indizien gearbeitet werden, die Hinweise auf die Eigenschaften des Produkts geben.
Ein Indiz kann die Software selbst sein. Wenn in ihr Konfigurationsmöglichkeiten gegeben werden, die auf unterschiedliche Verschlüsselungsformen und Umgang mit den Datenströmen hinweisen, ist wahrscheinlich, dass die unterschiedlichen Einstellungen unterschiedliche Eigenschaften der Kommunikation bewirken. Idealerweise deckt sich diese Beobachtung mit der Dokumentation, Hilfeseiten oder sogar den in Werbematerialien angepriesenen Funktionen, die anhand der unterschiedlichen Einstellungen der Software möglicherweise nicht mehr zur Verfügung stehen.
Zu diesen Funktionen gehört insbesondere die Telefoneinwahl. Wird diese ermöglicht, ist Voraussetzung, dass der Dienstanbieter den Audiostrom der Telefonie in die Videokonferenz einfügen kann, um sie den verbundenen Teilnehmern zur Verfügung zu stellen. Dies kann nur gelingen, wenn der Anbieter Zugriff auf den Datenstrom hat, ist also ein starkes Indiz für nicht vorhandene Ende-zu-Ende-Verschlüsselung zwischen den Endgeräten der Teilnehmer. Dokumentiert der Dienstanbieter hingegen, dass bei einer bestimmten Konferenzeinstellung Telefoneinwahl nicht mehr möglich ist, deutet dies darauf hin, dass eine Ende-zu-Ende-Verschlüsselung zwischen den Endgeräten der Teilnehmer gegeben ist.
Auch die Anbindung von externen Geräten, die auf SIP oder H.323 oder ähnlichen Protokollen basieren, wie sie insbesondere in Raum-Konferenzsystemen verwendet werden, deutet auf das Fehlen von Ende-zu-Ende-Verschlüsselung von Endgeräten der Nutzer hin. Vereinfacht gesagt: sobald die Menge der verwendeten Kommunikationsgeräte technologisch inhomogen wird und es einer Umsetzung oder Weiterleitung von Protokollen oder Standards bedarf, kann Ende-zu-Ende-Verschlüsselung nicht mehr realisiert werden.
Gleiches gilt für die Aufzeichnung von Konferenzen auf dem Server des Anbieters. Dies kann nur sinnvoll gelingen, wenn der Anbieter Zugriff auf den Datenstrom hat oder wenigstens den zur Verschlüsselung verwendeten Schlüssel weiterhin vorhält. Die Übersetzung oder Untertitelung des Gesprächs wird vermutlich auf Seiten des Dienstanbieters realisiert und bedarf damit ebenfalls dessen Zugriffs auf den Audio- und Videodatenstrom.
Wird für die Konferenz WebRTC verwendet ist dies ein starkes Indiz dafür, dass der Dienstanbieter Zugriff auf den Datenstrom hat. WebRTC ist ein direkt im Browser verankertes Protokoll, welches nur zwischen zwei „peers“ Ende-zu-Ende verschlüsseln kann, bei mehr als zwei Konferenzteilnehmern sind dies jeweils das Endgerät des Nutzers mit dem Server des Anbieters.
Als Randnotiz sei bemerkt, dass selbst bei WebRTC-Konferenzen „direkt“ zwischen zwei Teilnehmern der Dienstanbieter nicht nur die Verbindung kennt, sondern auch der verschlüsselte Datenverkehr zwischen den Endgeräten zur Überwindung von Netzwerkgrenzen über Server des Dienstleisters verläuft. Durch eine Eigenschaft des WebRTC-Protokolls kann der Dienstanbieter dabei sogar zu jedem Zeitpunkt feststellen, welcher der beiden Nutzer aktiv kommuniziert. [2]
Untersuchung gängiger Plattformen
In diesem Abschnitt soll untersucht werden, welche der gängigen Videokonferenz-Plattformen Ende-zu-Ende-Verschlüsselung zwischen den Endgeräten der beteiligten menschlichen Kommunikationspartner bietet. Die Reihenfolge der Anbieter ist willkürlich und ohne Bedeutung.
Zoom
Nach der Veröffentlichung von [2] hat Zoom eine Klarstellung in [3] veröffentlicht. Daraus wird deutlich, dass unter bestimmten Umständen, die nicht vollständig kontrollierbar und überprüfbar sind, eine Ende-zu-Ende-Verschlüsselung zwischen Nutzerendgeräten vorliegt. Aus weiteren Erläuterungen in diesem Text lässt sich aber auch ableiten, dass die Generierung der Schlüssel, die für die Verschlüsselung nötig sind, in der Infrastruktur von Zoom abläuft und dann die generierten Schlüssel an die Clients verteilt werden. Selbst wenn also die Aussage, bestimmte Konferenzen sind von Nutzerclient bis Nutzerclient Ende-zu-Ende verschlüsselt technisch korrekt ist, solange die Schlüssel für die Verschlüsselung durch Zoom erzeugt werden, besteht für Zoom die Möglichkeit, den Datenstrom zu entschlüsseln.
Darüber hinaus stellte Bruce Schneier fest, dass der schwache, nicht zu empfehlende ECB-Betriebsmodus bei der Verschlüsselung verwendet wird. [4] Zur Wichtigkeit der Betriebsart bei Verschlüsselungen sei ergänzend auf meinen Beitrag „Die Tücken der Blockchiffren in TOMs“ verwiesen. Unter Berücksichtigung all dieser Faktoren kann davon ausgegangen werden, dass die von Zoom betriebene Lösung zur Zeit keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert.
GoToMeeting
Auf der Homepage von GoToMeeting wird durch den Dienstanbieter LogMeIn formuliert: “GoToMeeting uses robust encryption mechanisms and protocols […] for data that is transmitted between the LogMeIn infrastructure and users, and data stored within the LogMeIn systems on behalf of its users for cloud recordings, transcriptions, and meeting notes.” [5] Damit ist bereits deutlich, dass die Datenübertragung nur auf dem Weg vom Endgerät in die Infrastruktur der Unternehmensmutter verschlüsselt wird, aber auf den Infrastruktursystemen weiterhin unverschlüsselt zu Verfügung steht. Auch die Telefoneinwahl, serverseitige Aufzeichnungsmöglichkeit und automatische Übersetzung indizieren diesen Schluss.
Noch deutlicher wird es im Security Whitepaper [6]: “To protect the confidentiality and integrity of VoIP connections from the endpoints to the voice servers […]” und “To protect the confidentiality and integrity of video connections from the endpoints to the video servers […]”macht gleiches deutlich. Die Aussage “Key establishment is accomplished by using a randomly generated 128-bit seed value selected by the GoToMeeting service that is distributed to all endpoints […]” [6] klärt, dass auch hier die Schlüsselgenerierung von Daten der Infrastruktur abhängig ist und der Anbieter jederzeit während einer Konferenz Zugriff auf ihren Inhalt hat. Damit bietet die von GoToMeeting resp. LogMeIn betriebene Lösung zur Zeit keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer.
WebEx
Cisco dokumentiert für WebEx Meetings im Help Center, wie Ende-zu-Ende-Verschlüsselung implementiert ist, welche Funktionen bei Wahl dieser Option nicht mehr zur Verfügung stehen und wie der Schlüssel auf Seiten des Meeting Hosts, nicht der Infrastruktur, generiert und sicher an die Clients verteilt wird. Es wird ausdrücklich formuliert: “In this model, traffic cannot be decoded by the Cisco Webex server.” [7] Das Security Whitepaper unterstreicht diese Aussage und ist so deutlich wie kein anderer Anbieter:
“Media streams flowing from a client to Cisco Webex servers are decrypted after they cross the Cisco Webex firewalls. Cisco can then provide network-based recordings, and all media streams can be recorded for future reference. Cisco Webex then re-encrypts the media stream before sending it to other clients. However, for businesses requiring a higher level of security, Cisco Webex also provides end-to-end encryption. With this option, Cisco Webex Cloud does not decrypt the media streams.” [8]
Anschließend wird auf die Schlüsselgenerierung eingegangen, die deutlich macht, dass Cisco Webex keinen Zugriff auf die für den Schutz der Medienübertragung verwendeten Schlüssel hat. Im selben Dokument werden auch die verwendeten Verschlüsselungsalgorithmen gelistet, einschließlich der verwendeten Betriebsarten; die in [4] bei Zoom kritisierte Betriebsart ECB ist nicht dabei. Probeweiser Start des kostenlosen Clients erlaubt die Konfiguration des persönlichen Meetingraums für Ende-zu-Ende-Verschlüsselung.
Die detaillierte und schlüssige Dokumentation sowie die von der Software entsprechend ermöglichte Konfiguration lässt darauf schließen, dass WebEx eine effektive Ende-zu-Ende-Verschlüsselung zwischen den Endgeräten der Nutzer umsetzt und dabei selbst keinen Zugriff auf den unverschlüsselten Datenstrom hat, weder direkt während der Kommunikation noch indirekt durch Kenntnis des verwendeten Schlüssels.
Update 04.05.2020: Ende-zu-Ende Verschlüsselung findet sich nicht mehr in der Anpreisung, im Webinterface oder im Client. Die Hilfeseite von Cisco benennt diese Funktion für Sites seit 02.05.2020 als „auf Anfrage“ verfügbar: https://help.webex.com/nwh2wlx/Enable-End-to-End-Encryption-Using-End-to-End-Encryption-Session-Types
Blizz
Von der Firma Teamviewer wird das Produkt Blizz Collaboration Companion für Onlinekonferenzen angeboten. Die Webseite [9] wirbt mit “256Bit end-to-end encryption, protecting sessions from prying eyes”, listet aber gleichzeitig Produkteigenschaften wie Telefoneinwahl und Aufzeichnung. Eine Anfrage im Support Forum zur Ende-zu-Ende-Verschlüsselung [10] wurde durch Verweis auf ein Security-Statement Dokument [11] zum Produkt TeamViewer „beantwortet“. Dieses Dokument, zu dessen Abruf das Zertifikat der HTTPS-Verbindung ungültig ist, zeigt, wie die Infrastruktur von TeamViewer einen Schlüssel an die beteiligten Kommunikationspartner verteilt. Der Dienstanbieter kann also Zugriff nehmen auf die verschlüsselten Daten. Anhand der gebotenen Informationen sollte deshalb davon ausgegangen werden, dass die von TeamViewer betriebene Lösung Blizz zur Zeit keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert.
Update 05.05.2020: Das Security-Statement Dokument [11] beschreibt in der Tat eine echte Ende-zu-Ende-Verschlüsselung, verteilt werden öffentliche Schlüssel, nicht der Session Schlüssel, der Dienstanbieter kann bei dieser Implementierung deshalb keinen Zugriff nehmen. Weiterhin halte ich die Dokumentation für nicht belastbar: Es wird das falsche Produkt dokumentiert, es wird nur von einer 1:1-Verbindung ausgegangen, während der Artikel ausdrücklich Mehrpersonenkonferenzen betrachtet, und alle Indizien wie Telefoneinwahl und Gesprächsaufzeichnung auf dem Server des Anbieters sprechen dafür, dass keine Ende-zu-Ende-Verschlüsselung zwischen den Endgeräten der Benutzer realisiert wird.
Skype
Verlässliche und klare Informationen zur Endkundenversion von Skype waren auf den Webseiten von Microsoft nicht auffindbar. Formulierungen in [12] und die Möglichkeit der Telefonverbindung deuten darauf hin, dass keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert ist.
Skype for Business wird hier nicht betrachtet, da entweder der zugehörige Server im Unternehmen selbst beheimatet ist oder das Produkt durch Teams abgelöst wird.
Teams
Teams von Microsoft löst Skype for Business ab. Es ist nicht gelungen, verlässliche und klare Informationen zur Umsetzung der Verschlüsselung in Microsoft Teams zu finden. Das Dokument [13] listet zwar den Verlauf des Protokollverkehrs, zeigt aber nicht auf, welche Komponente die Schlüssel generiert und wie diese verteilt werden. Stattdessen wird explizit auf das Mischen von Datenströmen eingegangen. Weiterhin wird Telefonkonnektivität geboten und erweiterte Unternehmensfunktionen zur Compliance erlauben den Zugriff auf alle Unternehmensdaten. Unter diesen Gesichtspunkten sollte davon ausgegangen werden, dass Microsoft Teams keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert.
Meet
Google Meet verwendet nur Transportverschlüsselung zwischen den Endgeräten der Konferenzteilnehmer und der Google Infrastruktur. [14] Die Telefoneinwahlmöglichkeit deutet ebenfalls darauf hin, dass der Anbieter Zugriff auf die Kommunikation hat. Es kann davon ausgegangen werden, dass Google Meet keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert.
Lifesize
In der Beschreibung der Sicherheitsmechanismen von Lifesize [15] finden sich keine detaillierten Angaben zur Protokollimplementierung oder Schlüsselgenerierung, Ende-zu-Ende-Verschlüsselung wird nicht erwähnt. Jedoch wird WebRTC verwendet, Telefoneinwahl ist möglich, Server des Dienstanbieters werden für die Überwindung von Netzwerkgrenzen verwendet, traditionelle Raumsysteme können eingebunden werden. Es kann davon ausgegangen werden, dass Lifesize keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert.
Fazit
Von den betrachteten Mehr-Personen Online-Konferenz-Diensten bietet nur WebEx von Cisco bei entsprechender Konferenzkonfiguration unter Verzicht auf damit nicht kompatible Funktionen bereits ab der kostenlosen Variante nachvollziehbar eine effektive Verschlüsselung der Mediendaten zwischen den Endgeräten der Benutzer ohne Kenntnis vom verwendeten Schlüssel, also eine „echte“ Ende-zu-Ende-Verschlüsselung, wie unter Sicherheitsgesichtspunkten gewünscht und erwartet.
Alle anderen betrachteten Dienstanbieter haben grundsätzlich Zugriff auf die übertragenen Medieninhalte der Online-Konferenz. Dies ist entweder ausdrücklich dokumentiert, aus der Dokumentation oder Produktbeschreibung resp. den angebotenen Funktionen ableitbar, oder muss anhand der (nicht) publizierten Informationen angenommen werden.
Bei der Auswahl des geeigneten Tools muss eine individuelle Abwägung zwischen benötigten Funktionen, Skalierbarkeit der Teilnehmerzahl, Stabilität und Qualität der Verbindung, Sicherheitsanforderungen, Bedien- und Betreibbarkeit, ggf. Zügigkeit der Umsetzung sowie der Gesamtkosten getroffen werden.
Referenzen
[1] “A Study of WebRTC Security”, NTT Communications, online unter https://webrtc-security.github.io/ , abgerufen am 15.04.2020
[2] “Zoom meetings aren’t end-to-end encrypted, despite misleading marketing”, The Intercept_, online unter https://theintercept.com/2020/03/31/zoom-meeting-encryption/ , abgerufen am 15.04.2020
[3] “The Facts Around Zoom and Encryption for Meetings/Webinars”, zoom blog, online unter https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-encryption-for-meetings-webinars/ , abgerufen am 15.04.2020
[4] “Security and Privacy Implications of Zoom”, Bruce Schneier, online unter https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html , abgerufen am 15.04.2020
[5] “Security FAQs”, GoToMeeting, online unter https://support.goto.com/meeting , abgerufen am 15.04.2020
[6] “Web conference security”, White Paper: Security, LogMeIn, 22.05.2019, online unter https://logmeincdn.azureedge.net/gotomeetingmedia/-/media/pdfs/ucc_security_white_paper.pdf , abgerufen am 15.04.2020
[7] “What Does End-to-End Encryption Do? ”, Cisco, online unter https://help.webex.com/en-us/WBX44739/What-Does-End-to-End-Encryption-Do , abgerufen am 15.04.2020
[8] “Cisco Webex Meetings Security”, White paper, Cisco public, 02/2019, online unter https://www.cisco.com/c/dam/en/us/products/collateral/conferencing/webex-meeting-center/white-paper-c11-737588.pdf , abgerufen am 15.04.2020
[9] Blizz Homepage, online unter https://www.blizz.com/ , abgerufen am 15.04.2020
[10] “Blizz: End to End Encryption”, Blizz Support, online unter https://community.teamviewer.com/t5/Blizz-Support/Blizz-End-to-End-Encryption/m-p/36604 , abgerufen am 15.04.2020
[11] “TeamViewer Security Statement”, TeamViewer, 05/2017, online unter https://trust-static.teamviewer.com/wp-content/uploads/2017/07/TeamViewer-Security-Statement-en.pdf , abgerufen am 15.04.2020
[12] “Does Skype use encryption?”, Skype Support, online unter https://support.skype.com/en/faq/FA31/does-skype-use-encryption , abgerufen am 15.04.2020
[13] “Microsoft Teams call flows”, Microsoft Docs, online unter https://docs.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows , abgerufen am 15.04.2020
[14] “Google Meet security and privacy”, Google, online unter https://support.google.com/a/answer/7582940?hl=en , abgerufen am 16.04.2020
[15] “Lifesize Security Overview”, Lifesize, online unter https://www.lifesize.com/~/media/Documents/Related%20Resources/Product%20Papers/Lifesize%20Cloud%20Security.ashx?la=en , abgerufen am 16.04.2020
[16] „Kompendium Videokonferenzsysteme“, KoViKo – Version 1.0.1, Bundesamt für Sicherheit in der Informationstechnik, online unter https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Kompendium-Videokonferenzsysteme.pdf , abgerufen am 16.04.2020
7. Mai 2020 @ 13:35
Vielen Dank für den sehr hilfreichen Artikel! Da ich auf der Suche nach datenschutzkonformen Anwendungen bin, hier eine Frage „im Umkehrschluss“: die nicht betrachteten Anwendungen Matrix, Jitsi, BigBlueButton und NextCloud Talk sind datenschutzkonform einsetzbar? Und sind sie kostenfrei einsetzbar (gem. Verein)?
7. Mai 2020 @ 14:26
> [sind] die nicht betrachteten Anwendungen […] datenschutzkonform einsetzbar?
Danke für die Rückfrage! Ich muss hier noch einmal verdeutlichen, der Artikel betrachtet die technische Realisierung der Verschlüsselung bei den Dienstleistern; der Artikel macht keine Aussage über die Datenschutzkonformität des jeweiligen Dienstes. Letzteres wäre eine damit vielleicht verbundene, aber nicht eindeutig abhängige Fragestellung. Aus dem Artikel zu schließen, die gelisteten Anbieter wären per se nicht datenschutzkonform, wäre keine valide Schlußfolgerung. Im Gegenteil, im Artikel genannte Dienste können datenschutzkonform genutzt werden, auch wenn sie keine Ende-zu-Ende Verschlüsselung aufweisen. Für Datenschutzkonformität ist diese keine Voraussetzung. Aus dem Datenschutz heraus muss (unter anderem) der unbefugte Zugriff auf personenbezogene Daten verhindert werden. Wenn Sie einen angemessenen AV-Vertrag mit dem Dienstleister schließen, damit dieser für Sie die Daten verarbeitet, ist er nicht unbefugt, sondern Sie befugen ihn dadurch.
Datenschutzrechtlich ist es vielleicht einfacher, einen Videokonferenzdienst selbst zu betreiben, wie es mit den von Ihnen genannten Produkten möglich ist. Dabei sind die datenschutzrechtliche Vorgaben aber natürlich ebenfalls einzuhalten. Wenn Sie beispielsweise die nötige Serversoftware nicht in Ihren eigenen physischen Räumen betreiben, sondern statt dessen auf einen Dienstleister zugreifen, bei dem Sie in einem kommerziellen Rechenzentrum einen dedizierten Server hosten, dann müssen Sie auch mit jenem Anbieter einen angemessenen Vertrag schließen – unabhängig davon, welches Videokonferenzprodukt Sie einsetzen wollen. Dazu kommen die nötigen technischen und persönlichen Kapazitäten, die Sie selbst bereitstellen müssen, ein angemessenes Datenschutzniveau im Rahmen technisch-organisatorischer Maßnahmen zu gewährleisten – und überhaupt erst einen unter allen zu erwartenden Bedingungen zuverlässig funktionierenden Dienst zu realisieren. Was für Sie „der beste“ Weg ist, hängt von Ihren Möglichkeiten und Bedürfnissen ab und bedarf einer entsprechenden individuellen Abwägung.
Unter dem Strich müssen Sie den Datenschutz immer beachten, unabhängig davon, ob Sie die technische Umsetzung einer Funktion oder Teile davon auf Dienstleister auslagern oder selber betreiben. Lediglich die Maßnahmen, Aufwände und Konsequenzen sind andere.
Zu Details des Datenschutzes spezifischer Videokonferenz-Dienste kann ich auf andere Artikel dieses Blogs verweisen: https://www.datenschutz-notizen.de/tag/videokonferenz/
2. Mai 2020 @ 20:55
Vielen Dank für diese fundierte Zusammenstellung! Da ich Online-Konferenzen mit Regierungsvertretern moderiere, las ich Ihren Beitrag insbesondere unter dem Askpekt, welche Tools eine E2E-Verschlüsselung anbieten. Für WebEx schreiben Sie: „Probeweiser Start des kostenlosen Clients erlaubt die Konfiguration des persönlichen Meetingraums für Ende-zu-Ende-Verschlüsselung.“ Stand heute (2. Mai 2020) konnte ich trotz 7-stündiger Beschäftigung mit WebEx diese Option nicht finden. Ich wäre Ihnen äusserst dankbar, wenn Sie mir hierzu Hinweise geben könnten, wie das funktioniert.
4. Mai 2020 @ 10:06
Danke für die Rückfrage. Seit der Erstellung des Artikels ist plötzlich die Webseite viel hübscher und heller und auch der Client schöner geworden, so „schön wie Zoom“. Die Option zum Session-Typ des personal meeting room sucht man nun aber vergeblich. Die Webseite https://help.webex.com/nwh2wlx/Enable-End-to-End-Encryption-Using-End-to-End-Encryption-Session-Types wurde am 02.05.2020 geändert und dort liest man jetzt: „The following end-to-end encryption session types are available, by request, in Webex Site Administration and Webex Control Hub. Contact your Customer Success Manager (CSM) or Support to get them.“ Diese Funktionalität ist also scheinbar nun nicht mehr kostenlos erhältlich. Da war dieser Artikel wohl zu hilfreich ;-/
1. Mai 2020 @ 18:04
Ausgerechnet Cisco soll vertrauenswürdig sein? In Produkten der Firma werden ständig gefährliche Sicherheitslücken gefunden. Viele von denen sind auf den ersten Blick als absichtlich eingebaute Hintertür zu erkennen. Der Firma traue ich nicht von hier bis zur Tür. –
Dann die Technik der angeblichen E2E Verschlüsselung für KONFERENZEN.
1. Die Abbildung auf [7] zeigt nur zwei Teilnehmer. Das ist einfach Video-Telefonie; da kann jede Anwendung E2E, wenn sie möchte. Wenn mehrere Partner teilnehmen, wird die Zahl der notwendigen Schlüsselpaare und damit die notwendige Rechenleistung sehr schnell sehr groß. Außerdem muss es dann eine Stelle geben, an der für jeden einzelnen Client umcodiert wird. Dort ist prinzipiell Abhören möglich.
2. Was bedeuten die Einschränkungen durch Aktivieren der so genannten Konferenz-E2E? Was heißt „Web App ist nicht möglich“? Heißt das nicht, dass die Konferenz faktisch nicht benutzbar ist?
4. Mai 2020 @ 10:34
> vertrauenswürdig
Die Vertrauenswürdigkeit des Anbieters habe ich nicht beurteilt.
> Die Abbildung auf [7] zeigt nur zwei Teilnehmer.
Das halte ich für eine Vereinfachung. Der zugehörige Text spricht von „all“: „all Cisco Webex clients generate key pairs and send the public key to the host’s client.“ Mathematisch kann „all“ natürlich „alle 2“ meinen, aber die Beschreibung scheint mir schon auf eine unbestimmte Zahl Teilnehmer gemünzt.
> Wenn mehrere Partner teilnehmen, wird die Zahl der notwendigen Schlüsselpaare und damit die notwendige Rechenleistung sehr schnell sehr groß.
Ja, echte Ende-zu-Ende Verschlüsselung hat ein Skalierungsproblem, darauf weist der letzte Absatz des Artikels hin. Die Abwägung der Wünsche und Möglichkeiten muss man durchführen. Alles gleichzeitig geht nicht.
Wenn übrigens alle Parteien einen symmetrischen Schlüssel teilen, der zu Beginn der Konferenz ausgehandelt wurde, muss auf der sendenden Seite nur 1x verschlüsselt werden.
Ich vermute, das wird ein Grund sein, warum diese Option bei Anbietern selten zu finden ist: die Qualität ist von vielen Faktoren abhängig, die oft nicht erfüllt sind (hinreichende und ununterbrochene Rechenleistung, bidirektionale Bandbreite, geringe Latenz, …). Damit ist die Meeting-Qualität oft „schlecht“ was auf den Dienstanbieter zurückfällt („Zoom ist viel einfacher und da funktioniert das problemlos!“), weshalb diese Funktion wahrscheinlich dem Geschäft mehr schadet als nützt. Cisco hat die Funktion gerade aus der kostenlosen Version entfernt und bei der bezahlten Versionen ist sie nur noch „auf Anfrage“ erhältlich.
> Außerdem muss es dann eine Stelle geben, an der für jeden einzelnen Client umcodiert wird. Dort ist prinzipiell Abhören möglich.
Ja, bei Cisco ist das der Meeting Host. Der ist aber bei der Kommunikation sowieso als Teilnehmer beteiligt, daher keine dritte Partei.
> Was bedeuten die Einschränkungen
Sie bedeuten, dass all die Funktionen, die die Beteiligung des Dienstanbieters an der Kommunikation erfordern, dann nicht mehr funktionieren. Telefoneinwahl geht z.B. nicht mehr, weil es bedeuten würde, dass der Dienstanbieter Zugriff auf den Datenstrom hätte. Auch das Betreten der Konferenz vor dem Host geht nicht mehr, weil der Host derjenige ist, der die Schlüssel an die Teilnehmer verteilt. usw. Das sind Hinweise darauf, dass die Funktion im originären Sinne einer „Ende zu Ende“-Verschlüsselung implementiert wurde.
> Heißt das nicht, dass die Konferenz faktisch nicht benutzbar ist?
Es heißt, dass jeder Teilnehmer die Client-Software benutzen muss.
30. April 2020 @ 17:00
An und für sich ein guter Artikel. Wenn die Kommunikation bei Teamviewer mit dem Schlüsselaustausch wie beschriebenen stattfindet, wäre ein Zugriff durch den Anbieter aber nicht möglich, da er nicht im Besitz der dafür notwendigen Private Keys ist und damit nicht entschlüsseln kann.
4. Mai 2020 @ 9:46
Ich halte das Dokument von Teamviewer nicht für belastbar in Bezug auf Blizz, daher die Anführungszeichen. Zum einen werden nur 1:1 Teamviewer-Sessions beschrieben, keine Blizz-Konferenzen. Zum anderen wird mit Telefoneinwahl geworben. Wie soll Blizz das Telefon-Audio in die Konferenz mischen, ohne über einen Schlüssel für die verschlüsselten Datenströme zu verfügen?
4. Mai 2020 @ 22:23
Erst mal vielen Dank für den tollen Artikel.
Dennoch scheint mir die Argumentation in Bezug auf Blizz nicht sauber zu sein, denn das Argument von T. Kraus gilt nach wie vor: der TeamViewer Master-Server hat nach der Dokumentation [11] nur Kenntnis von den öffentlichen Schlüsseln der beteiligten Partner A und B und nicht von deren privaten Schlüsseln. Wenn dem tatsächlich so ist, kann auf dem TeamViewer Master-Server der Inhalt der Kommunikation zwischen A und B nicht entschlüsselt werden (das ist auch mehrfach die Aussage im Dokument), es läge also echte E2EE vor. Ihr Schluss im Haupttext „Der Dienstanbieter kann also Zugriff nehmen auf die verschlüsselten Daten. “ ist damit fachlich falsch. Umgekehrt wird ein Schuh draus: Weil der TeamViewer Master-Server nur Kenntnis von den öffentlichen Schlüsseln hat bzw. nur die öffentlichen Schlüssel verteilt, kann der Dienstanbieter also keinen Zugriff nehmen auf die verschlüsselten Daten.
Wie bei [10] klar und deutlich beschrieben, endet die E2EE im Falle einer Telefoneinwahl zumindest für den Audiostream. Andere Datenströme können zumindest theoretisch weiter voll E2EE übertragen werden.
Es ist richtig, dass im Dokument nur eine Verbindung von 2 TeamViewer Clients und keine Meetingsituation mit mehreren TN beschrieben wird. Es ist auch richtig, dass diese Dokumentation streng genommen nur für TeamViewer und nicht direkt auch für Blizz gilt.
Daraus kann man aber nicht schließen, dass „Blizz zur Zeit keine effektive Ende-zu-Ende-Verschlüsselung zwischen Endgeräten der Benutzer realisiert.“, sondern nur, dass aufgrund der mangelnden Dokumentation für Blizz selbst unklar ist, ob dort auch eine effektive E2EE wie bei TeamViewer selbst besteht und ob dies auch für mehr als 2 Clients gilt.
Mein Beitrag dient einzig und allein einer sachlichen Klärung und enthält keine persönlichen Angriffe. Nur zur Klarstellung. 🙂
5. Mai 2020 @ 11:49
Ich stimme Ihnen bzgl. der Verschlüsselung zu, dokumentiert ist eine „echte“ Ende-zu-Ende-Verschlüsselung. Ich habe den Teil „Transfer of the symmetrical keys“ in der Grafik falsch gelesen.
An der grundsätzlichen Einschätzung von Blizz halte ich allerdings weiter fest, die Dokumentation ist nicht zutreffend, es ist der falsche Use Case und die angepriesenen Funktionen deuten darauf hin, dass der Dienstanbieter Einsicht nehmen kann. Eine Dokumentation die anderes belegt konnte ich nicht finden und Blizz ist an dieser Stelle nicht sehr auskunftsfreudig.
Ich habe den Artikel entsprechend mit einem Update ergänzt. Danke für die sachliche Rückmeldung, Korrektheit muss sein! 🙂
30. April 2020 @ 10:51
Eine sehr gute Analyse, vielen Dank dafür. Können Sie auch eine Einschätzung für das Produkt FastViewer geben? Der Anbieter wirbt auch damit über eine End-to-End-Verschlüsselung zu verfügen.
30. April 2020 @ 12:47
Danke sehr! Ich habe kurz einen Blick auf FastViewer geworfen, es wird Telefoneinwahl angeboten, dass ist ein klares Indiz für keine Ende-zu-Ende Verschlüsselung im „echten“ Sinne. „cloud-based web conferencing solution“ sind zwei weitere Hinweise: „cloud-based“ heißt de facto „auf einem Server des Anbieters“, „web“ deutet auf die Verwendung von WebRTC hin, was nur 1:1 Verbindungen unterstützt, die bei „Webkonferenzen bis zu 100 Teilnehmern“ nur zu einem Server sein können. Das mag im Einzelfall von 1:1 Gesprächen unter Berücksichtigung bestimmter Randbedingungen anders sein, das müsste man jeweils im Detail untersuchen, war aber nicht Bestandteil des Artikels.
27. April 2020 @ 12:43
Fazit: Strenge Ende-zu-Ende-Verschlüsselung ist nur in wenigen Anwendungen tatsächlich praktikabel. Das zeigte sich bereits bei der eGK (jahrzehntelange Entwicklung mit überschaubaren Ergebnissen) und beim beA (unvermeidliches Umschlüsseln im Sicherheitsmodul wegen komplexer, dynamischer Zugriffsrechte). Es zeigt sich ebenso bei der clientseitigen E-Mail-Verschlüsselung, die sich mangels Praktikabilität (und wohl auch mangels eines realen Nutzens) nicht durchsetzen konnte. Nun zeigt es sich auch bei Videokonferenzdiensten: Die Ende-zu-Ende-Verschlüsselung kollidiert mit anderen Anforderungen. Stand der Technik ist sie nicht und wird sie auch nicht werden.
27. April 2020 @ 13:24
Ja, ich fürchte zur Zeit ist E2E Verschlüsselung für Videocalls auf bestimmte Szenarien beschränkt. Die praktikabelsten Wege sind die Wahl eines „vertrauenswürdigen“ Providers oder der Eigenbetrieb einer MCU mit seinen ganz eigenen Herausforderungen.
27. April 2020 @ 12:31
Bemerkenswert guter Artikel der auf den ersten Blick keine Frage offen lässt, danke. Kurze Ergänzung: mit „Insertable Streams“ gibt es zumindest einen Draft der zukünftig echte E2EE mit WebRTC und damit z. B. Jitsi ermöglichen soll (https://jitsi.org/blog/e2ee/).
27. April 2020 @ 13:21
Danke für die Blumen und den Link, den werde ich auswerten.
12. März 2022 @ 11:15
Dieser Artikel ist schon eine Weile her, und ich fand ihn äußerst informativ. Darf ich fragen, ob sich da bei den Bewertungen etwas geändert hat bzw. Sie zu neuen Erkenntnissen gekommen sind? Es würde mich vor allem interessieren, inwieweit sich einerseits „insertable streams“ bei WebRTC, das ich jetzt auch bereits bei einem Anbieter implementiert gefunden habe (der allerdings auch auf Beschränkungen etwa bei der Browserwahl hinweist, vgl https://simplemeeting.de/de/videokonferenz/encryption.php), andererseits) als Weg für tatsächliche E2E-Verschlüsselung erwiesen hat und andererseits, wie Sie das im Hinblick zu der Verschlüsselung bei TeamViewer Meeting aktuell sehen.
31. März 2022 @ 16:08
Danke! 🙂 Entschuldigung für die Verzögerung, „leider“ hatte ich Urlaub…
In der Zwischenzeit hat sich einiges getan, aber ich habe das Thema noch nicht wieder intensiv aufgegriffen. Meines beschränkten Wissens nach hat Zoom nun echte Ende-zu-Ende-Verschlüsselung für Konferenzen implementiert (muss ausdrücklich aktiviert und ausgewählt werden), Microsoft in Teams nur für 1:1 Meetings (die Aktivierung ist mir unbekannt). Von TeamViewer ist mir kein neuer Stand bekannt.
Simplemeeting führt WebRTC (die Webseite hat den Stand 11/2020!) als „experimentell“ und weist auf die eingeschränkte Browserauswahl hin. Wenn man dort weiter wäre, hätte man die Webseite aktualisieren können. Auch ansonsten habe ich in letzter Zeit nichts von WebRTC gehört; Mainstream scheint mir das nicht zu sein.