- Ab April 2026 können nicht verifizierte Geräte in Element keine Ende-zu-Ende-verschlüsselten (E2EE) Nachrichten mehr senden oder empfangen
- Diese Änderung folgt einem Update der Matrix-Spezifikation und soll die Sicherheit der Unterhaltungen aller Nutzer stärken
- Die Geräteverifizierung ist ein Verfahren, mit dem kryptografisch nachgewiesen wird, dass jedes Gerät tatsächlich der betreffenden Person gehört; dadurch entfallen Hinweise auf nicht vertrauenswürdige Nachrichten
- Künftig können nur noch verifizierte Geräte an Unterhaltungen teilnehmen, und Warnsymbole oder Schildanzeigen verschwinden
- Diese Maßnahme ist ein zentraler Schritt zum Aufbau einer vertrauensbasierten sicheren Kommunikationsumgebung
Überblick über das Sicherheitsupdate
- Ab April 2026 blockiert Element das Senden und Empfangen Ende-zu-Ende-verschlüsselter Nachrichten auf nicht verifizierten Geräten
- Dies folgt einem Update der Matrix-Spezifikation, das auf der Matrix-Konferenz im Oktober 2025 angekündigt wurde
- Nutzer müssen die Geräteverifizierung abschließen, um auf ihren bestehenden Geräten weiterhin verschlüsselte Nachrichten senden und empfangen zu können
- Ziel dieses Updates ist es, sicherzustellen, dass Nachrichten tatsächlich vom beabsichtigten Absender stammen
- Element will damit die sicherste Kommunikationstechnologie bereitstellen
Risiken nicht verifizierter Geräte
- Nicht verifizierte Geräte können ein Angriffsvektor sein
- Wenn während einer Unterhaltung beispielsweise ein Warnsymbol erscheint, kann das sowohl auf ein einfach nicht verifiziertes Gerät als auch auf einen Versuch der Kontoübernahme hindeuten
- Werden solche Warnungen ignoriert, können sich Sicherheitsrisiken im gesamten Netzwerk ausbreiten
- Element bietet allen Nutzern standardmäßig Ende-zu-Ende-Verschlüsselung und will durch die verpflichtende Verifizierung Unsicherheit und die Möglichkeit böswilliger Aktivitäten beseitigen
Die Rolle der Geräteverifizierung
- Die Geräteverifizierung ist ein kryptografischer „Handshake“ zwischen einzelnen Geräten, der belegt, dass das jeweilige Gerät der betreffenden Person gehört
- Nachrichten von neuen, nicht verifizierten Geräten werden als nicht vertrauenswürdige Nachrichten markiert
- Durch die verpflichtende Verifizierung können Nutzer sicher sein, dass sich alle Nachrichten in einem vertrauenswürdigen Zustand befinden
Vertrauen als Grundprinzip des Designs
- Künftig werden Geräte nur noch in einen von zwei Zuständen eingeteilt: „verifiziert“ oder „kann nicht an Unterhaltungen teilnehmen“
- Warn- oder Schildsymbole werden nicht mehr angezeigt
- Damit soll verhindert werden, dass Nutzer gegenüber Warnungen abstumpfen
- Die Geräteverifizierung schützt nicht nur einzelne Personen, sondern trägt auch zur Stärkung des Vertrauens im gesamten Netzwerk bei
- Element treibt ein Systemdesign mit Sicherheit als oberster Priorität voran; der Verifizierungsprozess ist dabei ein Kernelement
Was Nutzer tun müssen
- Nutzer, die ihre Geräte bereits verifiziert und einen Wiederherstellungsschlüssel (recovery key) eingerichtet haben, müssen nichts weiter unternehmen
- Andernfalls sind folgende Schritte nötig
- Den Verifizierungsstatus aller Geräte prüfen, darunter Mobilgeräte, Web und Desktop
- Die Wiederherstellungsfunktion einrichten (optional, aber dringend empfohlen)
- Die Wiederherstellungsfunktion vereinfacht die Verifizierung neuer Geräte und ermöglicht die Wiederherstellung der Verifizierung selbst dann, wenn alle Geräte verloren gehen
- Konkrete plattformspezifische Schritte finden sich in der Benutzerdokumentation von Element
Einschränkungen ohne Verifizierung
- Ab April 2026 gelten für nicht verifizierte Geräte folgende Einschränkungen
- Kein Nachrichtenversand möglich
- Keine Anzeige des Inhalts empfangener Nachrichten (es ist nur sichtbar, dass eine Nachricht eingegangen ist)
- Dadurch sind nicht verifizierte Geräte für E2EE-Unterhaltungen nicht nutzbar
- An Unterhaltungen mit deaktivierter Verschlüsselung können sie jedoch weiterhin teilnehmen
Vertrauensaufbau und Unterstützung
- Element betont, dass durch Geräteverifizierung geschaffenes Vertrauen ein zentraler Bestandteil sicherer Kommunikation ist
- Diese Änderung gilt als kleine Maßnahme mit deutlich höherem Sicherheitsniveau
- Gemeinsam mit den Nutzern verfolgt Element das Ziel, dass alle Nachrichten so vertrauenswürdig wie ein persönliches Gespräch werden
- Während der Umstellung wird das Support-Team Nutzeranfragen beantworten und die reibungslose Einführung unterstützen
1 Kommentare
Hacker-News-Kommentare
Vor 3 Monaten habe ich den Server abgeschaltet und die Community wieder zu IRC zurückgebracht.
Ich hatte noch meinen IRC-Setup in einem Podman-Container übrig, daher war die Rückkehr einfach.
Jeden Monat musste ich mich mit Geräte-Verifizierungsfehlern, fehlgeschlagener Entschlüsselung von Nachrichten und UX-Problemen herumschlagen.
Anfangs entwickelte es sich schnell, aber in den letzten Jahren gab es bei der UX kaum Verbesserungen, was schade ist.
Auch die Beziehung zwischen Matrix und Element ist inzwischen verwirrend.
Das Entwicklerteam wirkt desinteressiert, und der vorgeschlagene „policy server“ ist ebenfalls noch unvollendet.
Man hat sich auf das Konzept einer „dezentralen JSON-Datenbank“ versteift
und dabei offenbar die Benutzbarkeit als Chat-System aus den Augen verloren.
Ich nutze es zwar noch, aber um normale Nutzer anzuziehen, ist noch ein weiter Weg zu gehen.
Wenn man eine IRC-basierte Community modernisieren will, halte ich Jabber (XMPP) für eine realistischere Alternative.
Ich habe es mit Freunden getestet, aber wegen der holprigen UX war es unbequemer als andere Messenger,
und nachdem die IRC-Bridge-Unterstützung eingestellt wurde, gab es keinen Grund mehr, es weiter zu nutzen.
Vor ein paar Monaten wurden meine Geräte zufällig abgemeldet/verifizierungslos gemacht, und obwohl ich mich mit dem Wiederherstellungsschlüssel eingeloggt habe, waren sie immer noch nicht verifiziert.
Die gegenseitige Verifizierung zwischen iOS, Linux, Windows und Android funktionierte überhaupt nicht richtig.
Solche erzwungenen Verifizierungsschritte sind praktisch ein unfreiwilliges Offboarding.
Wenn es ein problematisches Verifizierungsverfahren gibt, sollte das per Blog angekündigt werden.
Ich mag Element, aber so etwas braucht Vorbereitung im Vorfeld.
Manchmal klappt es kurz, nur um direkt wieder ausgeloggt zu werden, und Pop-ups zur Verifizierung alter Geräte tauchen ständig auf.
Ich habe am Ende Sorge, alle meine Profile zu verlieren.
Manchmal musste ich bei jedem Öffnen 30 Minuten lang Fehler beheben.
Die Idee ist gut, aber das Verhältnis von Aufwand zu Nutzen ist viel zu schlecht.
Es wirkt sich auch negativ auf die Kommunikation in OSS-Projekten aus.
Ich nutze es intensiv, hatte aber nie solche Probleme.
Vor ein paar Monaten wollte ich einen Matrix-Bot implementieren, aber die Open-Source-SDKs für Python
unterstützten E2EE und Geräteverifizierung überhaupt nicht, was zu einer schrecklichen Erfahrung führte.
Stattdessen fand ich das interne Rust-SDK (matrix-rust-sdk), und das war ziemlich gut.
Es gab auch FFI-Bindings für Python/Kotlin, aber die Dokumentation war dürftig.
Mithilfe von LLMs und dem Quellcode bekam ich es gerade so zum Laufen, und auch die Emoji-Verifizierung funktionierte erfolgreich.
Inzwischen wurde die Dokumentation deutlich verbessert, und es gibt auch einen Referenz-Client.
Ich habe auf Reddit einen kritischen Beitrag über Matrix gelesen.
Darin hieß es, dass die Struktur mit dauerhafter Speicherung und Duplizierung von Daten zu schlechter Leistung und schwacher Privatsphäre führe.
Bei Signal würden sogar Metadaten geschützt, während bei Matrix Raumnamen, Teilnehmer und Zeitangaben offengelegt würden.
Ich frage mich, ob das stimmt und ob das Protokoll eine Zukunft hat.
Das aktuelle Schutzniveau für Metadaten ist niedriger als bei Signal, wird aber verbessert.
Matrix hat ein anderes Threat Model, und man kann den Vertrauensbereich selbst wählen.
Wenn man es auf kleinen Servern betreibt, werden weniger Daten offengelegt als bei Signal.
Es ist nicht perfekt, aber ich sehe Entwicklungsgeschwindigkeit und Richtung positiv.
Das ist eine grundlegende Datenschutzanforderung, und trotzdem geht die Umsetzung nur langsam voran.
Probleme bei der Entschlüsselung von Nachrichten bestehen ebenfalls weiterhin.
Trotzdem halte ich es unter offenen Systemen nach wie vor für die beste verfügbare Option.
ist es anfällig für SIM-Spoofing-Angriffe.
Das modulare, dezentrale Design ist zugleich Stärke und Einstiegshürde.
Signal erreicht dank seiner einfacheren Struktur eine höhere Reife bei den Kernfunktionen.
Letztlich ist es eine Plattform, die einen vertrauenswürdigen Server voraussetzt.
Trotz der Beschwerden in diesem Thread
halte ich es für vernünftig, zu verhindern, dass man im unverifizierten Zustand eingeloggt ist und verschlüsselte Nachrichten austauscht.
Ich nutze Matrix seit 6 Jahren, und der Verifizierungsprozess ist inzwischen ziemlich reibungslos.
Sobald auch der Login per QR-Code fertig ist, wird es viel einfacher sein.
Einzelne Entscheidungen mögen sinnvoll sein, aber insgesamt sorgen mangelnde Kommunikation und
fehlende Dokumentation für Verwirrung.
Wer es oft benutzt, kommt klar, aber Gelegenheitsnutzer müssen jedes Mal ein Wiederherstellungs-Spiel durchmachen.
Dadurch kann man Nachrichten entschlüsseln, die vor dem Login eingegangen sind.
Problematisch war die UX, die es erlaubte, den Verifizierungsschritt zu überspringen.
Im Blog hätte klar definiert werden müssen, was mit Verifizierung gemeint ist.
Auf die Frage „Was ist Verifizierung?“
führt man beim Login auf einem neuen Gerät mit einem bestehenden Gerät einen kryptografischen Identitätsnachweis durch.
Das geschieht per Emoji-Vergleich, QR-Code-Scan oder Eingabe des Wiederherstellungsschlüssels.
Meistens ist das schnell und einfach, aber manche Clients haben Bugs.
Es ist einfach der Vorgang, ein neues Gerät mit einem bestehenden Gerät zu bestätigen.
Von allen verschlüsselten Messengern, die ich bisher benutzt habe, war dies die einfachste Verifizierungsmethode.
Wenn die auf beiden Geräten angezeigten Emojis übereinstimmen, wird bestätigt.
Beim Login auf einem neuen Gerät muss man es nur auf einem bestehenden Gerät bestätigen.
Ich nutze Thunderbird als Matrix-Client,
aber wenn ich Element oder Nheko öffne, warnen beide, dass sie nicht verifiziert seien.
Selbst wenn ich auf den Verifizierungsbutton drücke, passiert nichts, und auch kein QR-Code wird angezeigt.
Die UX von Matrix ist wirklich ein Albtraum.
Wegen der langsamen Updates habe ich aufgehört, es zu nutzen.
Es gibt keinerlei Anzeichen für Besserung.
Ich habe einen Alpha-Client ausprobiert, aber das Verifizierungs-Pop-up verschwindet nicht.
Manche Clients haben den Verifizierungsablauf nicht einmal implementiert,
wodurch die Einstiegshürde für neue Clients noch höher zu werden scheint.
Clients stürzen häufig ab, und auch die Synchronisierungsverzögerung ist stark.
Aus diesen Gründen halte ich XMPP für die bessere dezentrale Chat-Option als Matrix.
XMPP geht elegant mit Fehlern um und hat auch keine Echtzeit-Synchronisierungsprobleme.
Um Arbeitskollegen zu überzeugen, braucht es eine bessere UI.
Allerdings fehlen XMPP Cross Signing und Key Backup,
sodass es beim Komfort noch nicht ganz an Matrix heranreicht.
Element ist schwergewichtig, und andere Clients haben ein stark unausgewogenes Funktionsniveau.
Stattdessen habe ich mit einem Prosody-Server XMPP erneut ausprobiert,
und obwohl die Dokumentation etwas unfreundlich ist, war die Ressourceneffizienz beeindruckend.
Dass ein XMPP-Server selbst auf schwacher Hardware gut läuft, fand ich bemerkenswert.
Auf Client-Seite war ich allerdings etwas enttäuscht,
aber ich denke, bei der Dokumentation gibt es viel Raum für Verbesserungen.
Letztlich hoffe ich einfach, dass das freie Open-Source-Messenger-Ökosystem gedeiht.
Die neuesten Videos der Matrix Conference sind auf media.ccc.de verfügbar.
Es gibt viel Interessantes zu sehen,
und auch ohne einen eigenen Server zu betreiben kann man kostenpflichtiges Hosting wie etke.cc nutzen.
Ich mag Matrix/Element sehr.
Ich betreibe mehrere Räume für den FOSDEM-Devroom,
und sogar Videoanrufe haben einwandfrei funktioniert.
Ich hoffe nur, dass noch mehr Funktionen hinzukommen.