OpenClawのMatrix暗号化と検証

暗号化されたMatrixルームが機能するのは、Gatewayのデバイスがそれを所有するアカウントから信頼されている場合だけです。Matrixにおける信頼はチェーンになっており、シークレットストレージ、クロス署名鍵、検証済みデバイス、ルームキーのバックアップで構成されます。OpenClawはこのチェーンを少数のコマンドにまとめ、それぞれの信頼シグナルが何を証明するのかを明示しています。以下では、暗号化の有効化方法、状態確認と検証の仕組み、クロス署名のブートストラップと修復、バックアップの復元とリセット、SASのコマンド、そして運用上の注意点を説明します。

有効化と状態確認

• 暗号化されたルームでは、送信する画像イベントに暗号化されたサムネイルファイルが使われるため、プレビューも添付ファイルと一緒に暗号化されます。プラグインがルームの暗号化状態を検出するので、設定は不要です。すべてのMatrixコマンドはverbose、JSON、アカウントの各フラグを受け付け、出力はデフォルトで簡潔です。
• 暗号化のセットアップコマンドは、シークレットストレージとクロス署名をブートストラップし、必要に応じてルームキーのバックアップを作成します。リカバリーキーはstdinから読み込まれるためプロセスの引数に現れることはなく、現在のクロス署名IDを破棄するための意図的なフラグも用意されています。新しいアカウントは作成時に暗号化を有効にでき、どちらの経路でも設定を保存する前にクライアント操作を完了させるため、実行中のGatewayは後からリロードできます。ブートストラップに失敗した場合でも、設定は保存され、次の手順が表示されます。
• verify statusは3つの独立したシグナルを報告します。このクライアントだけが信頼していることを示すlocally trusted、SDKが報告するcross-signing verified、そしてデバイスがあなたの自己署名鍵を持っていることを示す診断であるsigned by ownerです。include-recovery-keyフラグは、テキスト出力では生のキーが利用可能であることを確認するだけでJSONを案内し、そのJSONは非公開に保つ必要があります。
• stdin経由のリカバリーキーでデバイスを検証すると、key accepted、backup usable、device verified by ownerの3つの状態が報告されます。キーでバックアップの素材を解錠できた場合でも、IDの完全な信頼が成立していなければ、ゼロ以外の終了コードで終了します。その場合の仕上げには別のクライアントからの自己検証が必要で、self-verifyコマンドは、クロス署名がverifiedを報告するまでそれを待ちます。

Verified by ownerがyesになるのは、Cross-signing verifiedがyesの場合だけです。ローカルの信頼やオーナーの署名だけでは不十分です。

修復とバックアップ

bootstrapコマンドは、暗号化されたアカウントの修復とセットアップのための経路です。可能であれば既存のリカバリーキーを再利用してシークレットストレージをブートストラップし、クロス署名をブートストラップして不足している公開鍵をアップロードし、現在のデバイスをマークしてクロス署名し、サーバー側のルームキーのバックアップがなければ作成します。ホームサーバーが鍵のアップロードに対話型認証を要求する場合、OpenClawは認証なし、ダミーログインステージ、パスワードログインの順に試します。パスワードログインには、設定にアカウントのパスワードが必要です。backup statusは、サーバー側のバックアップが存在するかどうかと、このデバイスがそれを復号できるかどうかを表示し、restoreはバックアップされたルームキーをローカルの暗号ストアにインポートします。履歴が完全に復号されていない編集は、欠けている鍵を復元して再試行することで直せます。鍵が失われている場合は、新しいメッセージを送信します。backup resetは、復元できない履歴の喪失を受け入れたうえで、壊れたバックアップを新しいベースラインに置き換え、必要に応じてシークレットストレージも作り直します。rotateフラグは、以前のリカバリーキーで新しいベースラインを解錠できないようにすべき場合にのみ追加します。

SAS、アカウント、起動時

• verify listコマンドは保留中のリクエストを表示し、verify requestはリクエストを送信します。送信先は、同じユーザーの別のクライアントで承認してもらうown-userフラグ付きの自己検証か、特定のユーザー、デバイス、ルームのいずれかです。より低レベルのライフサイクルコマンドでは、リクエストの承認、SASフローの開始、絵文字または数字の表示、一致の確認または拒否、理由とコードを付けたキャンセルを行えます。いずれも、ダイレクトルームに紐付いている場合はDMでのフォローアップのヒントを受け付けます。
• アカウントフラグがない場合、コマンドは暗黙のデフォルトアカウントを使います。名前付きアカウントが複数あってデフォルトがない場合は推測を拒否し、暗号化が有効でない名前付きアカウントは自身の設定キーを報告します。暗号化が有効な場合、起動時の検証はデフォルトでif-unverifiedです。未検証のデバイスは別のクライアントで自己検証をリクエストし、重複するリクエストは24時間のクールダウンでスキップされます（このクールダウンは調整することも、オフにすることもできます）。また、起動時には控えめなブートストラップ処理も実行され、パスワードなしで安全策付きの修復を試みます。パスワード認証が必要な場合でも、これは致命的なエラーにはなりません。
• 検証ライフサイクルの通知（リクエスト、絵文字の案内付きの準備完了、開始、完了、SASの詳細）は、厳格なDM検証ルームに通知として投稿され、エージェントのパイプラインには決して届きません。別のクライアントからの受信リクエストは追跡されて自動的に承認され、自己検証はSASフローを自動的に開始して自分の側を確認します。その間も、照合はあなたが自分のクライアントで行います。ホームサーバーに表示されなくなったデバイスは、パスワードログインまたは新しいアクセストークンでアカウントを再度追加することで置き換えます。古いデバイスはdevicesコマンドで一覧表示して削除します。暗号状態はstateディレクトリ配下にある、ホームサーバー、ユーザー、トークンハッシュをキーとするアカウントごとのルートに保存されます。古いルートが1つだけ残っているのはローテーションの継続として正常ですが、データのあるルートが複数ある場合は、削除せずに中身を確認してアーカイブしてください。

この記事はMatrix上のOpenClawの記事をさらに掘り下げたもので、マルチアカウント構成、プライベートホームサーバー、ターゲットの形式については、姉妹ページのOpenClawのMatrixアカウントとホームサーバーで扱っています。

Dialiでは

Matrixは、WhatsApp、Telegram、Discord、Slack、Mattermost、SMS、音声と並んで、Dialiで接続できるチャネルの一覧に含まれています。ホームサーバーのアカウントとルームの許可リストはお客様のもの、Gatewayは当社のものです。それらの結び付け方は5分で最初のチャネルを接続するガイドで、それぞれに適用される境界はDialiのセキュリティのページで説明しています。

信頼ルールがもたらすもの

ローカルの信頼ではなくクロス署名による検証を必須とすることで、盗まれたデバイスやリプレイされたデバイスを、Gateway自身が素通りさせることはできなくなります。チェーンを完成させられるのは、別のクライアントから操作するアカウント所有者だけです。アシスタント本体についてはDialiのマネージドOpenClawホスティングを、暗号状態の問題を他の設定と合わせて表示するコマンドについてはOpenClaw doctorをご覧ください。

• setup、verify、bootstrap、backupの4つのコマンドです。
• リカバリーキーはstdin経由で渡し、コマンドラインには決して書きません。
• 有効なのはクロス署名だけです。仕上げは別のクライアントから行います。