Matrix-Verschlüsselung und -Verifizierung in OpenClaw

Verschlüsselte Matrix-Räume funktionieren nur, wenn das Gerät des Gateways von dem Konto, dem es gehört, als vertrauenswürdig eingestuft wird, und Vertrauen ist bei Matrix eine Kette: Secret Storage, Cross-Signing-Schlüssel, ein verifiziertes Gerät und ein Raumschlüssel-Backup. OpenClaw verpackt diese Kette in eine kleine Zahl von Befehlen und sagt ausdrücklich, was jedes Vertrauenssignal beweist. Hier steht, wie die Verschlüsselung aktiviert wird, wie Status und Verifizierung funktionieren, wie Cross-Signing initialisiert oder repariert wird, wie Backups wiederhergestellt oder zurückgesetzt werden, dazu die SAS-Befehle und die Betriebshinweise.

Aktivierung und Status

• In verschlüsselten Räumen verwenden ausgehende Bildereignisse eine verschlüsselte Thumbnail-Datei, sodass Vorschauen zusammen mit dem Anhang verschlüsselt werden, ohne Konfiguration, da das Plugin den Verschlüsselungsstatus des Raums erkennt; jeder Matrix-Befehl akzeptiert Flags für ausführliche Ausgabe, JSON und Konto, und die Ausgabe ist standardmäßig knapp.
• Der Befehl zur Einrichtung der Verschlüsselung initialisiert Secret Storage und Cross-Signing und legt bei Bedarf ein Raumschlüssel-Backup an; der Wiederherstellungsschlüssel wird dabei von stdin gelesen, damit er nie in Prozessargumenten erscheint, und ein bewusst zu setzendes Flag verwirft die aktuelle Cross-Signing-Identität. Ein neues Konto kann die Verschlüsselung bei der Erstellung aktivieren, und beide Wege schließen ihre Client-Operationen ab, bevor sie die Konfiguration speichern, damit ein laufendes Gateway danach neu laden kann, während ein fehlgeschlagener Bootstrap die Einstellung trotzdem speichert und die nächsten Schritte meldet.
• Der Verifizierungsstatus meldet drei unabhängige Signale: lokal vertrauenswürdig, also nur von diesem Client als vertrauenswürdig eingestuft; per Cross-Signing verifiziert, vom SDK gemeldet; und vom Eigentümer signiert, eine Diagnose, dass das Gerät Ihren Self-Signing-Schlüssel trägt. Ein Flag zum Einschließen des Wiederherstellungsschlüssels bestätigt in der Textausgabe nur, dass ein Rohschlüssel verfügbar ist, und verweist Sie auf JSON, das dann privat gehalten werden muss.
• Die Verifizierung des Geräts mit einem Wiederherstellungsschlüssel über stdin meldet drei Zustände, Schlüssel akzeptiert, Backup nutzbar und Gerät vom Eigentümer verifiziert, und endet mit einem Exit-Code ungleich null, wenn das volle Identitätsvertrauen noch nicht hergestellt ist, selbst wenn der Schlüssel Backup-Material entsperrt hat; zum Abschluss ist dann eine Selbstverifizierung von einem anderen Client aus nötig, auf die der Befehl zur Selbstverifizierung wartet, bis Cross-Signing verifiziert meldet.

„Verified by owner“ ist nur dann „yes“, wenn „Cross-signing verified“ „yes“ ist; lokales Vertrauen oder eine Eigentümersignatur allein genügt nicht.

Reparatur und Backup

Der Bootstrap-Befehl ist der Reparatur- und Einrichtungsweg für verschlüsselte Konten: Er initialisiert Secret Storage und verwendet dabei nach Möglichkeit einen vorhandenen Wiederherstellungsschlüssel wieder, initialisiert Cross-Signing und lädt fehlende öffentliche Schlüssel hoch, markiert das aktuelle Gerät und signiert es per Cross-Signing, und er legt ein serverseitiges Raumschlüssel-Backup an, falls keines existiert; wenn der Homeserver für das Hochladen von Schlüsseln eine interaktive Authentifizierung verlangt, versucht OpenClaw es ohne Authentifizierung, dann mit der Dummy-Login-Stufe, dann mit Passwort-Login, wofür das Kontopasswort in der Konfiguration stehen muss. Der Backup-Status zeigt, ob ein serverseitiges Backup existiert und ob dieses Gerät es entschlüsseln kann, die Wiederherstellung importiert gesicherte Raumschlüssel in den lokalen Krypto-Speicher, und eine Bearbeitung, deren Verlauf nicht vollständig entschlüsselt ist, beheben Sie, indem Sie die fehlenden Schlüssel wiederherstellen und es erneut versuchen, oder indem Sie eine neue Nachricht senden, wenn die Schlüssel verloren sind. Ein Backup-Reset ersetzt ein defektes Backup durch eine frische Basis, nimmt den Verlust nicht wiederherstellbaren Verlaufs in Kauf und legt optional Secret Storage neu an, und ein Rotate-Flag wird nur hinzugefügt, wenn der bisherige Wiederherstellungsschlüssel die neue Basis nicht mehr entsperren soll.

SAS, Konten, Start

• Der Befehl verify list zeigt ausstehende Anfragen, und verify request sendet eine, entweder als Selbstverifizierung mit dem Own-User-Flag, die in einem anderen Client desselben Nutzers angenommen wird, oder an einen bestimmten Nutzer, ein Gerät oder einen Raum; die Lebenszyklus-Befehle auf niedrigerer Ebene nehmen eine Anfrage an, starten den SAS-Ablauf, zeigen die Emojis oder Dezimalzahlen an, bestätigen oder verwerfen die Übereinstimmung und brechen mit Grund und Code ab, und alle akzeptieren DM-Folgehinweise, wenn sie an einen Direktraum gebunden sind.
• Ohne Konto-Flag verwenden die Befehle das implizite Standardkonto; bei mehreren benannten Konten ohne Standard weigern sie sich zu raten, und ein benanntes Konto ohne Verschlüsselung meldet seinen eigenen Konfigurationsschlüssel. Bei aktivierter Verschlüsselung steht die Verifizierung beim Start standardmäßig auf if-unverified: Ein nicht verifiziertes Gerät fordert eine Selbstverifizierung in einem anderen Client an und überspringt Duplikate innerhalb einer Abklingzeit von vierundzwanzig Stunden, die sich anpassen oder abschalten lässt, und beim Start läuft außerdem ein vorsichtiger Bootstrap-Durchgang, der eine abgesicherte Reparatur ohne Passwort versucht und nicht fatal ist, wenn Passwort-Authentifizierung erforderlich ist.
• Hinweise zum Verifizierungs-Lebenszyklus (Anfrage, Bereitschaft mit Emoji-Anleitung, Start, Abschluss und SAS-Details) werden als Notices in den strikten DM-Verifizierungsraum gepostet und erreichen nie die Agent-Pipeline; eingehende Anfragen von einem anderen Client werden verfolgt und automatisch angenommen, und die Selbstverifizierung startet den SAS-Ablauf automatisch und bestätigt ihre eigene Seite, während Sie in Ihrem Client noch vergleichen. Ein Gerät, das auf dem Homeserver nicht mehr aufgeführt ist, ersetzen Sie, indem Sie das Konto erneut mit einem Passwort-Login oder einem frischen Access-Token hinzufügen, veraltete Geräte werden mit den devices-Befehlen aufgelistet und bereinigt, und der Krypto-Zustand liegt unter dem State-Verzeichnis in kontobezogenen Wurzelverzeichnissen, die nach Homeserver, Nutzer und Token-Hash geschlüsselt sind; ein einzelnes älteres Wurzelverzeichnis ist normale Rotationskontinuität, mehrere befüllte Wurzelverzeichnisse sollten dagegen geprüft und archiviert statt gelöscht werden.

OpenClaw auf Matrix ist der Kanal-Beitrag, den dieser Beitrag vertieft, und Matrix-Konten und Homeserver in OpenClaw die Begleitseite zu Layouts mit mehreren Konten, privaten Homeservern und Zielformen.

Bei Diali

Matrix steht auf der Liste der verbindbaren Kanäle von Diali, neben WhatsApp, Telegram, Discord, Slack, Mattermost, SMS und Sprache: Das Homeserver-Konto und die Raum-Zulassungsliste gehören Ihnen, das Gateway gehört uns. Wie diese verknüpft werden, erklärt die Anleitung Ersten Kanal in fünf Minuten verbinden; die Grenze, die jeweils gilt, beschreibt die Diali-Sicherheitsseite.

Was die Vertrauensregel bringt

Auf Cross-Signing-Verifizierung statt auf lokalem Vertrauen zu bestehen bedeutet, dass ein gestohlenes oder wiedereingespieltes Gerät nicht vom Gateway selbst durchgewunken werden kann; nur der Kontoinhaber kann die Kette von einem anderen Client aus vervollständigen. Gehostetes OpenClaw bei Diali ist der Assistent und OpenClaw doctor der Befehl, der Probleme mit dem Krypto-Zustand zusammen mit dem Rest der Konfiguration sichtbar macht.

• Einrichten, verifizieren, Bootstrap, Backup: vier Befehle.
• Wiederherstellungsschlüssel über stdin, nie auf der Kommandozeile.
• Nur Cross-Signing zählt; schließen Sie von einem anderen Client aus ab.