Wir setzen KI ein, um schneller zu schreiben – nicht, um zu entscheiden, was stimmt. Jemand bei Digital Samba hat jede Zeile dieses Artikels gelesen, bevor Sie es getan haben.
Kurze Antwort: Eine korrekt implementierte Ende-zu-Ende-Verschlüsselung (E2EE) wird nicht dadurch gebrochen, dass man die Verschlüsselung selbst angreift. Genau hier liegt die entscheidende Unterscheidung, die auch die Suchergebnisse prägt: Eine starke E2EE lässt sich mit heutiger Technik nicht knacken – aber sie lässt sich unter Umständen umgehen. Die realistischen Risiken sitzen an den Endgeräten, beim Schlüsselaustausch und in der Implementierung, nicht in der Chiffre. Wenn ein E2EE-geschützter Videocall kompromittiert wird, hat der Angreifer mit an Sicherheit grenzender Wahrscheinlichkeit nicht den Verschlüsselungsalgorithmus geknackt. Er hat ihn vollständig umgangen und dabei etwas ins Visier genommen, das viel näher an der nutzenden Person liegt.
Das ist wichtig, weil die Frage „Kann eine Ende-zu-Ende-Verschlüsselung geknackt werden?" häufig entweder mit falscher Beruhigung oder mit übertriebener Panikmache beantwortet wird. Keines von beidem hilft den Menschen, die tatsächlich Sicherheitsentscheidungen treffen müssen. Dieser Artikel erklärt, was E2EE wirklich schützt, wo die reale Angriffsfläche liegt und was ein gut entworfenes System tut, um sich gegen jeden einzelnen Vektor zu verteidigen – am konkreten Beispiel der Implementierung von Digital Samba.
Inhaltsverzeichnis
E2EE bedeutet, dass Inhalte auf dem Gerät der sendenden Person verschlüsselt und erst auf dem Gerät der empfangenden Person wieder entschlüsselt werden. Jeder Server und jedes Relay dazwischen – einschließlich der eigenen Infrastruktur des Anbieters – verarbeitet Chiffretext, den es nicht lesen kann. Die Schlüssel existieren nur an den Endpunkten. Der Server sieht sie nie.
In einem Videocall kann E2EE Medienströme, Bildschirmfreigabe, Chatnachrichten, Teilnehmernamen und Whiteboard-Inhalte abdecken – all das liegt innerhalb der verschlüsselten Grenze. Außerhalb dieser Grenze liegen die Metadaten: die Tatsache, dass ein Call stattfand, wann er begann und endete und welche Konten beteiligt waren. Metadaten sind keine Nutzlast. Sie sind Routing- und Sitzungsinformationen, die die Infrastruktur zum Funktionieren braucht, und E2EE schützt sie nicht.
Serverseitige Funktionen, die Zugriff auf Inhalte benötigen – etwa Aufzeichnung, Live-Transkription und automatische Protokollierung –, können innerhalb einer echten E2EE-Sitzung nicht funktionieren, weil der Server nicht entschlüsseln kann, was er verarbeiten müsste. Dieser Kompromiss ist real, und wir behandeln ihn weiter unten ausführlicher.
Einen tieferen Blick darauf, wie E2EE speziell in WebRTC funktioniert, bietet der Digital-Samba-Artikel über die Stärke von E2EE in WebRTC, der die zugrunde liegende Mechanik vollständig behandelt.
Nicht auf realistische Weise. Moderne Ende-zu-Ende-Verschlüsselung baut auf AES auf, der symmetrischen Chiffre, der man alles anvertraut – vom Online-Banking bis zu Verschlusssachen. In WebRTC werden Medien Frame für Frame mit SFrame verschlüsselt, einem IETF-Standard, und AES-128 ist dafür die etablierte Schlüssellänge: Es ist das, was der Standard vorschreibt und was produktive WebRTC-Implementierungen seit dem ersten Einsatz des Verfahrens verwenden. Digital Samba folgt diesem Standard und nutzt AES-128 im Counter-Modus mit HMAC-SHA256-Authentifizierung für Medien sowie AES-256-GCM für länger lebende Daten wie Chat und den Schlüsselaustausch selbst. Einen AES-Schlüssel per Brute-Force zu knacken – ob 128 oder 256 Bit – ist mit heutigem klassischem Rechnen praktisch unmöglich. Das ist keine Frage der Langsamkeit. Auf jeder realistischen Zeitskala lässt es sich schlicht nicht bewerkstelligen, und es wurde kein praktikabler Angriff gegen AES demonstriert.
Der ehrliche Vorbehalt ist das Quantencomputing. Grovers Algorithmus würde, sollte er je auf einem ausreichend großen, fehlertoleranten Quantencomputer laufen, eine quadratische Beschleunigung bei der Schlüsselsuche bringen, was die Stärke eines symmetrischen Schlüssels in Bit faktisch halbiert. Das ist einer der Gründe, warum Medienschlüssel ephemer sind – pro Sitzung erzeugt und rotiert statt langlebig – und warum für dauerhaft gespeicherte Daten längere Schlüssel verwendet werden. Das NIST veröffentlichte 2024 seine ersten Post-Quanten-Kryptografie-Standards; was noch andauert, ist die Migration. Nichts davon macht heutige E2EE unmittelbar angreifbar. Die Quantenbedrohung ist ein Planungshorizont: etwas, worauf man sich über die kommenden Jahre vorbereitet, lange bevor es einen heute geführten Call betreffen könnte.
Die Frage ist nicht, ob E2EE geknackt werden kann. Sie lautet, wie jemand den Schutz umgeht, den sie bietet. In der Praxis zielen Angreifer durchweg auf die Ränder des verschlüsselten Kanals.
Die obigen Angriffsvektoren sind nicht unüberwindbar. Eine gut entworfene E2EE-Implementierung begegnet jedem von ihnen architektonisch. Worauf Sie bei jedem E2EE-Produkt achten sollten, zeigt das folgende Beispiel der Implementierung von Digital Samba.
Bevor wir in die Architektur einsteigen, ist eine Unterscheidung wichtig: E2EE ist ein Modus, den man für eine Sitzung einschaltet, nicht der Standardzustand jedes Calls. Jeder Digital-Samba-Call ist während der Übertragung verschlüsselt, weil WebRTC das voraussetzt. Diese Transportverschlüsselung (TLS und DTLS-SRTP) arbeitet allerdings Hop für Hop und endet am Media-Server, während jeder Stream geroutet wird – genau das ermöglicht in der Standardkonfiguration serverseitige Funktionen wie die Aufzeichnung. E2EE fügt darüber eine weitere Schicht hinzu und verschlüsselt die Medien selbst Ende-zu-Ende, sodass die Media-Server nach dem Einschalten nur noch Chiffretext weiterleiten, den sie nicht lesen können. Diese Ende-zu-Ende-Schicht ist der Teil, den Sie für eine bestimmte Sitzung aktivieren, und von ihr hängen die folgenden Garantien ab.
Schlüssel werden mit der Web Crypto API auf dem Gerät erzeugt. Sobald E2EE eingeschaltet ist, werden private Schlüssel niemals an die Server von Digital Samba übertragen oder dort gespeichert: Sie existieren nur auf dem Gerät des Teilnehmers, für die Dauer dieser Sitzung. Das ist eine architektonische Bedingung und nicht bloß ein Richtlinienversprechen, und sie gilt, solange die E2EE-Sitzung läuft.
Zur Verteidigung gegen MITM-Angriffe auf den Schlüsselaustausch erzeugt Digital Samba einen Sicherheits-Verifizierungscode, den Teilnehmende Out-of-Band vergleichen können – etwa über eine Chatnachricht, einen Telefonanruf oder einen anderen, von der Videositzung unabhängigen Kanal. Stimmen die Codes überein, wurde der Schlüsselaustausch nicht manipuliert. Stimmen sie nicht überein, ist das ein Signal, dass die Sitzung abgefangen worden sein könnte. Dieser Mechanismus ist einfach, erfordert kein Spezialwissen und begegnet direkt dem realistischsten aktiven Angriff auf den E2EE-Schlüsselaustausch.
Dieser Verifizierungscode beruht allerdings auf einer Annahme: dass der Code, der die Verschlüsselung ausführt, selbst vertrauenswürdig ist. Browserbasierte E2EE – auch die von Digital Samba – läuft als JavaScript, das der Browser bei jeder Sitzung frisch herunterlädt, statt als feste, code-signierte native App, die man einmal installiert, so wie Signal oder WhatsApp es tun. Das ist ein tatsächlich anderes Vertrauensmodell. Derselbe Code, der die Verschlüsselung durchführt, erzeugt auch den Verifizierungscode, sodass der Code sich nicht selbst überprüfen kann. Das ist eine inhärente Eigenschaft von Kryptografie im Browser, nichts, was spezifisch für einen einzelnen Anbieter wäre – und deshalb haben unabhängige Sicherheitsaudits, veröffentlichte kryptografische Reviews und transparenter Client-Code bei browserbasierter E2EE besonderes Gewicht. Auf sie verlassen Sie sich, statt dem Code blind zu vertrauen.
Forward Secrecy und Backward Secrecy entstehen durch Schlüsselrotation bei Beitritts- und Austrittsereignissen. Tritt ein Teilnehmer bei, werden neue Schlüssel erzeugt; verlässt ein Teilnehmer die Sitzung, rotieren die Schlüssel erneut. Ein Schlüssel, der später kompromittiert wird, gibt keine Inhalte preis, die vor seiner Erzeugung oder nach seiner Rotation lagen. Das begrenzt die Gefährdung auf das Fenster zwischen zwei Rotationsereignissen statt auf die gesamte Sitzung.
Sobald E2EE aktiviert ist, verarbeitet die SFU (Selective Forwarding Unit), die die Medien zwischen den Teilnehmenden routet, ausschließlich Chiffretext. Sie kann die Streams, die sie weiterleitet, nicht entschlüsseln. Das ist im Design verankert: Es gibt keine Einstellung, die das aufheben könnte, solange E2EE eingeschaltet bleibt.
Genau dieselbe Garantie – dass der Server bei eingeschalteter E2EE nie nutzbare Schlüssel hält – macht E2EE zugleich unvereinbar mit jeder Funktion, die den Server braucht, um Inhalte zu lesen. Das ist ein Kompromiss, der klar ausgesprochen und nicht in der Dokumentation vergraben werden sollte.
Aufzeichnung und Transkription brauchen, so wie sie typischerweise umgesetzt sind, serverseitigen Zugriff auf Klartext-Audio oder -Video. In einer E2EE-Sitzung, in der der Server keine Schlüssel hält, ist das nicht möglich. E2EE für eine Sitzung zu wählen bedeutet zu akzeptieren, dass der Call nicht serverseitig aufgezeichnet werden kann, dass automatische Transkription nicht verfügbar ist und dass eine Compliance-Archivierung, die auf serverseitiger Erfassung beruht, nicht funktioniert.
Für viele Anwendungsfälle – etwa Rechtsberatungen, Arzttermine und sensible Geschäftsgespräche – ist das ein akzeptabler und oft sogar erwünschter Kompromiss. Für andere – etwa Schulungsaufzeichnungen, Qualitätssicherung im Kundensupport und die Archivierung in regulierten Branchen – möglicherweise nicht. Entscheidend ist, diese Wahl bewusst zu treffen, mit einem zutreffenden Verständnis dessen, was E2EE auf der Serverseite verhindert – statt die Unvereinbarkeit erst nach dem Rollout zu entdecken.
So sieht echter Schutz in der Praxis aus – und hier liegen die verbleibenden Verantwortlichkeiten:
Noch einmal die kurze Antwort: Die Chiffre wird nicht die Schwachstelle sein. Ihr Gerät, Ihre Gewohnheiten bei der Schlüsselverifizierung und die Qualität der Implementierung werden es sein. Ein gut entworfenes E2EE-System hält Schlüssel auf dem Gerät, bietet Out-of-Band-Verifizierung, erzwingt Forward und Backward Secrecy durch Schlüsselrotation und stellt sicher, dass der Server nach dem Einschalten nur Chiffretext verarbeitet. Diese Kombination begegnet der realistischen Angriffsfläche direkt. Was sie nicht leisten kann: ein kompromittiertes Endgerät schützen, Metadaten-Privatsphäre garantieren, für den im Browser ausgelieferten Code bürgen oder serverseitige Funktionen ermöglichen, die Klartextzugriff brauchen.
Wählen Sie Plattformen, die bei diesen Grenzen ehrlich sind. Diejenigen, die die Kompromisse zutreffend benennen – auch, wo E2EE eingeschaltet werden muss und was Sie das dann kostet –, sind meist auch die, die den Rest richtig umgesetzt haben.
Für die technischen Details des Ansatzes von Digital Samba behandelt das Security-Whitepaper die Implementierung vollständig. Für die WebRTC-spezifische Mechanik von E2EE ist die Stärke von E2EE in WebRTC das Begleitstück zu diesem Artikel.
Eine Verschlüsselung zu „knacken" heißt, den Algorithmus selbst mathematisch zu brechen – etwa einen AES-Schlüssel per Brute-Force zu erraten. Das ist mit heutiger klassischer Rechentechnik praktisch unmöglich. Sie zu „umgehen" heißt, den Schutz gar nicht anzugreifen, sondern an den Rändern vorbeizugehen: über ein kompromittiertes Endgerät, einen Man-in-the-Middle-Angriff auf den Schlüsselaustausch, Implementierungsfehler oder Social Engineering. Reale Angriffe auf E2EE sind fast immer ein Umgehen, kein Knacken.
Ja, wenn sie korrekt implementiert und für die Sitzung eingeschaltet ist. E2EE schützt Inhalte während der Übertragung, indem nur die Endgeräte die Entschlüsselungsschlüssel halten. Sie schützt nicht vor einem kompromittierten Gerät, sie verbirgt keine Metadaten, und ihre Stärke hängt von der Qualität der Implementierung ab.
Die realistischsten Wege sind Schadsoftware auf dem Gerät eines Teilnehmers, die Inhalte nach der Entschlüsselung liest, ein Man-in-the-Middle-Angriff auf den Schlüsselaustausch, der die Schlüssel des Angreifers gegen die legitimen austauscht, Implementierungsfehler wie schwache Schlüsselerzeugung oder ein Fallback auf schwächere Verschlüsselungsmodi sowie Social Engineering, das einen legitimen Nutzer dazu bringt, einem Angreifer Zugang zur Sitzung zu gewähren. Der Verschlüsselungsalgorithmus selbst ist kein realistisches Ziel.
Nicht mit heutigem klassischem Rechnen. Einen AES-Schlüssel per Brute-Force zu knacken – ob die 128-Bit-Schlüssel für Echtzeitmedien oder die 256-Bit-Schlüssel für länger lebende Daten – ist auf jeder praktischen Zeitskala nicht durchführbar. Quantencomputing könnte irgendwann die effektive Stärke symmetrischer Chiffren verringern, weshalb das NIST 2024 seine ersten Post-Quanten-Kryptografie-Standards veröffentlicht hat und Organisationen jetzt die Migration durcharbeiten. Das bleibt ein Planungshorizont und keine gegenwärtige Bedrohung. AES ist bei beiden Schlüssellängen weiterhin der Standard für starke symmetrische Verschlüsselung.
Nein. E2EE schützt Inhalte zwischen Geräten. Sobald Inhalte auf einem Gerät entschlüsselt wurden, sind sie für alles zugänglich, was auf diesem Gerät läuft – einschließlich Schadsoftware. Endgerätesicherheit, etwa das Patchen von Geräten oder der Einsatz seriöser Sicherheitssoftware, ist eine Voraussetzung dafür, dass E2EE sinnvollen Schutz bietet.
Die zuverlässigste Methode ist die Out-of-Band-Verifizierung des Sicherheitscodes, den ein gut entworfenes E2EE-System aus den gemeinsamen Schlüsseln erzeugt. Sehen beide Teilnehmenden denselben Code, wurde der Schlüsselaustausch nicht manipuliert. Unterscheiden sich die Codes, könnte die Sitzung abgefangen worden sein. Dieser Schritt sollte bei sensiblen Calls zur Standardpraxis gehören. Darüber hinaus sollten Sie auf Plattformen mit veröffentlichten kryptografischen Audits und dokumentierten Schlüsselmanagement-Praktiken achten.
Nein. Metadaten – Informationen darüber, wer wen wann, wie lange und von welchen Konten aus angerufen hat – sind typischerweise für den Anbieter sichtbar und können in einer Verkehrsanalyse auf Netzwerkebene auftauchen, selbst wenn der Inhalt des Calls verschlüsselt ist. E2EE schützt die Nutzlast; sie schützt nicht die Routing- und Sitzungsinformationen, die die Infrastruktur zum Funktionieren braucht. Hochsensible Anwendungsfälle brauchen möglicherweise zusätzliche Kontrollen, um der Metadaten-Sichtbarkeit zu begegnen.