[Task] read 経路の完全性: 署名付き応答の E2E 検証 + メンバーシップ証明

[somasekimoto]

背景

PR #54 のレビュー指摘(コメント)と、その後の設計議論で明らかになった read 経路の完全性ギャップをまとめる。

PR #54 で対処済みなのは以下の2点:

• credential 漏洩の悪用: 読み取り署名を read:{content_id}:{timestamp} に content_id バインド済み。漏れても単一コンテンツ・5分間に限定。
• 偽データ注入 (本文): SDK の暗号化を AES-256-GCM (AEAD) に移行済み。改ざん・偽造された暗号文本文はクライアントの復号で必ず失敗する。

本 issue が扱うのは、GCM でも content_id バインドでも塞がらない残りの完全性問題。

問題の構造 — 2つのレイヤー

read 経路には独立した2つの信頼問題がある。両方を埋めないと防御にならない。

レイヤー1: 「誰に聞くか」(メンバーシップ)

resolve_members (state_node_service.rs) は、ローカルに ContentNetwork レコードがない場合、Kademlia DHT の近接ピア (find_closest_peers) をそのまま relay 先の「メンバー」として扱う。メンバーであることの暗号学的検証はない。攻撃者は自分の PeerID を対象コンテンツの DHT キー近傍に置くだけで relay 先候補に潜り込める。content network の正規メンバーである必要はない。

さらに、ローカルの ContentNetwork レコード自体も gossip イベント (ContentNetworkManagerAdded / ContentNetworkManagerRemoved) のペイロードを無検証で保存・上書きしている。発行者の正当性検証がない。

libp2p では埋まらない: libp2p (Noise) が保証するのは各ホップの相手 PeerID が本物であること (トランスポート認証) だけ。「その PeerID が対象コンテンツの正規メンバーか」はアプリ層の概念であり、libp2p は何も語らない。多段 relay の場合、libp2p が認証するのは隣接ホップ間のみで、中間ノードは中身を差し替え放題。

レイヤー2: 「返ってきた答えが正しいか」(応答の完全性)

relay 先が返す (data, version) および履歴 (relay_read_history の版 CID リスト) には署名も系列検証もない。GCM が守るのは暗号文本文の完全性のみで、以下は素通りする:

• 偽履歴の注入: get_history / get_latest_version は relay 先が返す版 CID の文字列リストをそのまま信頼する。攻撃者は本物のチェーンに存在しない偽の版 ID を混ぜられる。正規メンバーの sync 遅延 (正常な stale) では決して発生しない状態。
• ロールバック攻撃: 攻撃者が過去の本物の暗号文 (v3) を「最新」として返す。中身は正規の CEK で暗号化された本物なので GCM 認証は成功し、クライアントは正常に復号して「最新」と信じる。訂正・取り消し系の更新 (アクセス権削除、宛先修正等) を「なかったこと」にできる。

正常な stale read との区別: 正規メンバーが sync 遅延で一時的に古い版を返すのは結果整合性として正常な仕様であり、守るべき挙動。攻撃との違いは「時間が経てば sync で自己修復するラグ」か「攻撃者が特定の相手に対して古い版/偽履歴を意図的に固定・注入し、収束しない」か。検出の軸はメンバー/非メンバーでも新旧でもなく、自己修復するラグか、収束しない改ざんか。

提案する方向性 — 署名付き応答 (E2E 検証)

レイヤー1・2を同時に埋める本命は、member が返すデータ/版の系列に署名し、その署名を最終読み手 (SDK/クライアント) まで運んで E2E で検証すること。これにより:

1. 署名者の鍵で「本当に member か」を判定できる (レイヤー1)
2. 署名検証で改ざんの有無が分かる (レイヤー2)
3. 多段 relay でも中間 relay がデータに触れなくなる (member 本人の署名なので中間では作れない)

加えて、系列の完全性・単調性:

• 系列チェーン検証: version は crsl-lib の Node CID (SHA-256)。各版が genesis からの親子チェーンに繋がっているかをクライアントが辿れれば、偽履歴 (存在しない版) を弾ける。
• 単調性チェック (ロールバック検出): クライアントが「前回見た版」をローカルに記録し、返ってきた版がその祖先に巻き戻っていないか (monotonic / TOFU 的) を検証する。member/非 member 問わず効く。

やること (設計段階で詰める)

• member が read 応答 (データ本文および版/履歴) に署名する仕組みの設計 (署名対象・鍵・配布)
• SDK/クライアント側で応答署名を E2E 検証する経路の設計 (relay が何段挟まっても検証が効くこと)
• 版の系列チェーン検証 (genesis → 各版の親子関係) をクライアントで辿れるようにする
• 単調性チェック (前回版の記録と巻き戻し検出) の設計
• ContentNetwork レコードへの owner/genesis authority 署名と、gossip・DHT フォールバック両経路での検証 (レイヤー1 のルーティング側)
• 鍵配布・ローテーションの扱い

優先度メモ

すべて「攻撃者が read relay の経路に入れること」が前提。クローズドな 4 ノード構成の現状では成立しない。オープン参加型ネットワークにする前までに対応が必要 (Kademlia への Sybil/eclipse 攻撃が現実的になるため)。

[somasekimoto]

設計まとまりました(方式確定)

設計メモを docs/design/read-response-integrity.md に置きました(ブランチ feature/read-response-signing)。以下は結論の要約です。

脅威モデルの整理

read 経路の信頼問題は2レイヤーに分かれます。

• レイヤー1(誰に聞くか): resolve_members の DHT フォールバックも gossip の member レコードも無検証。非 member が relay 先になりうる。
• レイヤー2(何が返ったか): relay 応答の (data, version)・履歴に検証がない。GCM(fix(state-node): relay reads to members with member-side authorization; fix read auth + phantom history #54)は暗号文本文しか守らないので、偽履歴の注入とロールバック(過去の本物の版を「最新」と偽る)が残る。

大前提: メタデータ機密性を壊さない

「誰がどの content を管理しているか」を relay ノードに晒さないことをハード制約にしました。member リスト全体を晒すのは、単体の member が見える現状より質的に危険(冗長化の無効化・名寄せ・非否認性の劣化)。リストは出さず、応答した単体ノードだけが自分の正当性を証明する形にします。

確定した方式(3点セット・1 PR)

1. 版真正性: member が生 payload でなく Node 全体(CBOR) を返し、クライアントが CID を再計算して改ざん検知。CID = 内容ハッシュなので署名不要、追加のメタデータ漏洩ゼロ。
2. owner 発行の単体 member 証明: 既存の owner ES256 委任トークンを転用し、aud = そのノード の member 証明を応答に添付。読み手は自分が既に持つ委任トークンの iss(= owner 公開鍵、user:{hex(pubkey)} の自己完結型) で検証。リストを晒さず「正規 member が答えた」ことを確認できる。owner は発行時のみ介在し read 経路には入らない。
3. 単調性チェック: クライアントが「最後に見た版」を記録し、後退した応答を拒否(ロールバックのベストエフォート検出)。

正直な限界

この方式が防ぐのは非 member のなりすまし(= 本 issue の主シナリオ)。正規 member 自身が古い版を最新と返すことは原理的に防げない(「より新しい版が無い」という否定的事実はネットワーク越しに証明不能)。これは既知の限界として脅威モデルに明記し、単調性でベストエフォート検出します。

実装方針

• production 利用ゼロ(テストのみ)なので後方互換なし・破壊的変更 OK・1 PR。段階導入や Option 共存はせず最初から検証必須。
• 検証ロジックは monas-content に置く(SDK は薄い呼び出し層)。
• 実装前ブロッカーは調査で解消済み: owner 公開鍵は委任トークンから取れる(追加 API 不要)/ Node CID 再計算は monas-content に crsl-lib 準拠で新設(既存 content_id.rs の todo: crslのcid生成 を回収)。

却下した案(再検討防止・詳細はメモ §6.2)

署名付き member リスト配布 / member node 鍵の生署名 / envelope への CID 埋め込み(共有時1回しか配られないと判明)/ 可変な「最新ポインタ」(同じ問題が再帰)/ CEK による証明(member を区別できない)。

実装計画は設計メモ §8 に file:line 付きで記載しています。

[somasekimoto]

設計訂正: member 証明を廃止(owner は membership を知り得ない)

実装を進める中で、先の設計の「owner 発行の member 証明」(コンポーネント C)が Monas の分散設計に反する誤りだと分かったので訂正します。

何が誤りだったか

「owner が member 追加時に証明トークンを発行し、node が read 応答に添付、client が owner 鍵で検証」という案でしたが、これは前提が成立しません:

• owner は誰が member かを知らないし、知り得ない。member は DHT の複製配置・add_member_to_content によって owner の関与なく自律的に増減・入れ替わる。「owner が member 追加時に発行する」経路が存在しない。
• 「署名の信頼の根が owner(read 認可)」と「member を認定するのが owner」は別問題。これを混同していた。

訂正後の結論: member 証明は不要

#54 レビューの主シナリオ(非 member が偽データ・偽履歴を返す)は、コンポーネント A(Node 全体を CBOR で返し、client が CID を再計算)だけで防げます。攻撃者は正しい CID を持つ偽 Node を作れないため、誰が返そうと弾ける。「正規 member か」を確認する必要自体がない — データが暗号学的に正しければ、返した相手は誰でもよい。

ロールバック(過去の本物の版を最新と偽る)はコンポーネント B(単調性チェック、client がローカルで前回版より後退を検出)でベストエフォート対応。正規 member 自身による stale/ロールバックは原理的に防げない既知の限界として脅威モデルに明記します。

スコープ縮小

• A(版真正性): Node CBOR + CID 再計算。実装済み・crsl-lib パリティ検証済み。
• B(単調性): 実装中。
• C(member 証明): 廃止。

これにより owner を member 管理に巻き込む非現実的な仕組みが消え、設計がむしろ単純かつ正しくなります。設計メモ(docs/design/read-response-integrity.md)の冒頭に訂正を追記済み。