Ein sicherer Anruf hat mehr als einen Datenpfad. Die Signalisierung koordiniert, wer anruft und wie sich Endpunkte verbinden; der Medienpfad transportiert Audio und Video. Einen Pfad zu schützen schützt nicht automatisch den anderen, und keiner allein verbirgt sämtliche Kommunikationsmuster.
WebRTC bietet wichtige Sicherheitsmechanismen, doch die Identitätsprüfungen einer Anwendung, die Rollen ihrer Server und ihr Aufzeichnungsmodus bestimmen weiterhin die vollständige Datenschutzgrenze.
Signalisierung und Medien haben unterschiedliche Aufgaben
| Ebene | Typischer Zweck | Sicherheitsfrage |
|---|---|---|
| Signalisierung | Einladungen, Sitzungsbeschreibungen und Verbindungskandidaten | Wer kann Informationen zum Verbindungsaufbau lesen oder ändern, und wie wird der vorgesehene Gesprächspartner authentifiziert? |
| Medien | Audio, Video und zugehörige Echtzeitströme | Wo endet die Verschlüsselung, und welche Endpunkte können auf die Medien zugreifen? |
| Betriebsdatensätze | Routing, Verbindungszeitpunkte und Zustellstatus | Welche Metadaten können Dienst oder Netzwerk beobachten? |
| Aufzeichnung | Eine dauerhaft aufbewahrte Kopie erstellen | Wer erhält Klartext oder nutzbare Aufzeichnungsschlüssel, und wo wird die Kopie gespeichert? |
Ein Nachrichtenprotokoll kann verschlüsselte Signalisierung transportieren, doch WebRTC verlangt nicht allgemein das Nachrichtenhüllenformat eines bestimmten Messengers. Andere authentifizierte Entwürfe sind möglich.
Was DTLS-SRTP leistet
Die WebRTC-Sicherheitsarchitektur, RFC 8827, verlangt Schutz für Medienkanäle und beschreibt den Schlüsselaufbau mit DTLS-SRTP. Vereinfacht gesagt hilft DTLS beim Aufbau des kryptografischen Kontexts, während SRTP die Echtzeit-Medienpakete schützt.
Die Endpunkte dieses Schutzes sind entscheidend. Eine direkte verschlüsselte Verbindung zwischen Teilnehmern unterscheidet sich von einer Verbindung, die an einem medienverarbeitenden Server endet. Manche Mehrparteiensysteme ergänzen die Transportverschlüsselung zum Server um eine separate Ende-zu-Ende-Schicht. Das Wort „WebRTC“ allein verrät nicht, welche Architektur ein Produkt verwendet.
Warum die Authentifizierung der Signalisierung wichtig ist
Der Verbindungsaufbau kann Informationen enthalten, die die Medienverbindung an die vorgesehene Partei binden. Kann ein Angreifer diese Informationen unbemerkt ersetzen, kann die Verschlüsselung eine geschützte Verbindung zum falschen Endpunkt herstellen.
RFC 8827 behandelt diesen Zusammenhang zwischen Signalisierung, Identitäten und DTLS-Fingerabdrücken. HTTPS schützt eine Verbindung zum Signalisierungsdienst; es beseitigt allein nicht die Notwendigkeit, einen bösartigen oder kompromittierten Dienst zu berücksichtigen. Ende-zu-Ende-authentifizierte Signalisierung oder ein geeigneter unabhängiger Mechanismus zur Überprüfung des Gesprächspartners können diese Grenze stärken.
Die Vertraulichkeit der Signalisierung ist ein verwandtes, aber anderes Ziel: Sie begrenzt, wer Details des Verbindungsaufbaus lesen kann. Ein Entwurf sollte sowohl Vertraulichkeit als auch Authentifizierung erklären, statt einen verschlüsselten Datenblock als ausreichenden Nachweis für beides zu behandeln.
Verschlüsselte Signalisierung macht einen Anruf nicht unsichtbar
Das Relay kann weiterhin wissen, zwischen welchen Konten oder Geräten es vermittelt. Netzwerkbeobachter können Verbindungszeitpunkte, Datenvolumen und Serveradressen sehen. Je nach Verbindungsentwurf können auch Gesprächspartner oder Relay-Infrastruktur Netzwerkinformationen erfahren.
Eine verschlüsselte Anrufeinladung beweist folglich nicht, dass der Dienst einen Anruf nicht erschließen, Beziehungen erfassen oder anrufbezogene Datensätze aufbewahren kann. Inhalte zu verbergen und Verkehrsmuster zu verbergen sind unterschiedliche Probleme.
Die von Livara veröffentlichte Grenze
Livaras Sicherheitsseite beschreibt direkte und Gruppenanrufe als Ende-zu-Ende-verschlüsselt, macht jedoch eine ausdrückliche Ausnahme für die optionale Serveraufzeichnung: Solange der sichtbare REC-Status aktiv ist, verwendet der Anruf Transportverschlüsselung statt E2EE.
Das Bedrohungsmodell lehnt außerdem Aussagen über Metadaten-Anonymität und Schutz vor einem kompromittierten Gerät ab. Dies sind Produktaussagen, keine unabhängige Verifizierung jedes Anrufpfads. Dieser Leitfaden behauptet weder eine ungeprüfte Teilnehmergrenze noch ein bestimmtes Signalisierungsformat oder eine Post-Quanten-Implementierung für Medien.
Insbesondere rüstet ein Post-Quanten-Schlüsselaustausch des Messengers einen separaten WebRTC-Medienhandshake nicht automatisch auf. Algorithmen und Schlüsselbindung des Medienpfads müssen unabhängig bewertet werden.
Vor einem sensiblen Anruf
- Bestätigen Sie die Teilnehmer und prüfen Sie unerwartete Identitätsänderungen.
- Prüfen Sie, ob die Aufzeichnung aktiviert ist und was sich laut Anwendung dadurch ändert.
- Klären Sie, ob der Dienst Medien verarbeitet oder lediglich geschützte Pakete weiterleitet.
- Berücksichtigen Sie die Geräte und Räume der Teilnehmer: Schadsoftware, Bildschirmaufnahmen oder ein Zuhörer in der Nähe können Inhalte nach der Entschlüsselung offenlegen.
- Fragen Sie nach Architektur- und Testnachweisen für genau den verwendeten Modus, statt sich auf ein allgemeines Kennzeichen „verschlüsselte Anrufe“ zu verlassen.
Eine nützliche Sicherheitsaussage benennt getrennt, wer auf Signalisierung, Medien, Metadaten und Aufzeichnungen zugreifen kann.
