Jitsi Meet lässt sich zwar auf eigenen Servern betreiben, erlaubt aber keine Ende-zu-Ende-verschlüsselte Kommunikation von Gruppen. Das soll sich nun ändern.
In einem Blogpost stellt das quelloffene Videokonferenz-Projekt Jitsi Meet erste Pläne vor, eine Ende-zu-Ende-Verschlüsselung über WebRTC umzusetzen und bittet Krypto-Experten um ihre Meinung. Das Projekt will dazu so genannte Insertable Streams verwenden, an denen Google zurzeit arbeitet. Dabei wird für eine verschlüsselte WebRTC-Übertragung einfach eine zusätzliche Verschlüsselungsebene eingezogen.
Den Schlüssel will das Projekt dabei von einem URL-Hash ableiten. Das ist der Teil einer URL, der dem “#” folgt und der nicht an einen Server gesendet wird (und in dem Jitsi-Modell auch nicht gesendet werden darf). Die Jitsi-Macher werten ihn über “window.location.onhashchange” aus und spüren so Änderungen am E2EE-Schlüssel auf. Von diesem Schlüssel leitet das Projekt wiederum einen 128-Bit-Schlüssel über PBKDF2 ab, wobei die Raumnamen als Salt herhalten. Das sei ein wenig schwach, aber alle Teilnehmer am verschlüsselten Chat müssten dasselbe Salt erhalten. Erhalten anfangs alle Teilnehmer noch denselben Schlüssel zum chiffrieren und dechiffrieren der Kommunikation soll später jeder Teilnehmer über die MUC-Ressource einen eigenen Key erhalten. Kommt ein neuer Teilnehmer in den Chat, rotieren die Schlüssel. Das sei aktuell noch nicht möglich, weil dies ein funktionierendes E2E-Signaling erfordere.
SRTP als Vorbild
Der abgeleitete Schlüssel kommt dann beim Verschlüsseln des Streams zum Einsatz. Dieser Prozess setzt auf die Insertable Stream API, AES-GCM und das Webcrypto-API und generiert einen 96-Bit langen Initialisierungsvektor. Vorbild dafür ist die Verschlüsselung in SRTP (Secure Real-Time Transport Protocol). Der Vektor fügt einem Paket 12 Byte Overhead hinzu. Während das für Videopakete in Ordnung gehe, denke man bei Audio-Tags über kürzere Authentifizierungs-Tags nach. Weil man den Header nicht verschlüssele, könne der Encoder chiffrieret Pakete auch ohne Schlüssel verarbeiten, erzeuge dann aber eine Art visuelles Rauschen. Am Ende soll die Selective Forwarding Unit (SFU), also die Jitsi-Videobridge auf dem Server, nicht zwischen verschlüsselten und unverschlüsselten Inhalten unterscheiden können.
Die Verschlüsselung in Jitsi steht also auf der Agenda, auch wenn die Umsetzung in mehreren Schritten erfolgen wird und noch Fragen offen sind. Interessierte dürfen aber bereits vorhandenen Code begutachten. E2EE-Keys lassen sich zudem in der aktuellen Alpha-Version experimentell einsetzen. Im nächsten Schritt stellt sich daher die Frage, ob und wie das Feedback der Krypto-Experten die Verschlüsselungspläne beeinflusst.
