[Security] 版メタデータの trust anchor: 観測者が偽 parents で読み単調性を bypass できる

[somasekimoto]

背景

PR #56 のディープレビュー指摘 (R2-blocker1)。read 経路の完全性検証 (docs/design.md §10) のうち、CID 検証(payload真正性) + 単調性チェックでは塞がらない残りの穴。

問題

CID 照合が保証するのは「バイト列が要求した版 CID に一致すること」であり、「その版が正規の書き込みとして作られたこと」ではない。

relay 上で暗号文を観測できる攻撃者は:

1. 観測済みの本物の暗号文を新しい crsl-lib Node に包み直す
2. parents に任意の CID (例: クライアントの last_seen) を詰める
3. その Node の CID を「最新版」として提示する

→ payload は本物なので CEK 復号も plain CID 照合も通る。単調性チェックは parents を信頼して祖先を辿るため、last_seen を parents に含めた偽版で bypass される。

本修正

版メタデータ(parents / version)の真正性を保証する trust anchor が必要:

• 案A: Node への owner 署名 (書き込み時に owner が Node 全体へ署名し、クライアントが検証)
• 案B: checkpoint (定期的に owner が署名した版チェーンのスナップショット)

いずれも crsl-lib の Node フォーマットに及ぶプロトコル変更のため、#56 のスコープ外として明文化した上でここで追跡する (design.md §10「既知の限界」1 に記載済み)。

🤖 Generated with Claude Code

[somasekimoto]

PR #56 での対応状況(2026-07-28)

PR #56 ではこの問題を解決していないことを明記した上でマージ候補としている。関連する変更:

1. 単調性チェック(last_seen + 祖先 walk)を取り下げた(commit e6433af)。本 issue のとおり偽 parents で bypass できるため本質的な防御にならない一方、結果整合性のもとで正当な sync 遅延と攻撃を応答単体で区別できず、正規 read を壊す誤検知(256 版超のギャップで復旧手段なく失敗、部分同期 member で walk 失敗)と GC できないクライアント永続状態という負債だけが残るため。実装は commit 2fe4162 以前に残っているので、必要なら参照可能。

2. docs/design.md §10 に保証範囲を明記した。read の保証は「返された payload が要求した版に対して真正であること」までで、版の真正性・ロールバック耐性は未対応であること、その解決が本 issue であることを記載。

3. [Task] read 経路の完全性: 署名付き応答の E2E 検証 + メンバーシップ証明 #55 は本 PR ではクローズしない方針にした(PR feat(read-integrity): verified read path — payload authenticity, sender-authenticated CEK envelopes, single-use mutation signatures #56 のタイトル・本文も実態に合わせて訂正済み)。本 issue の対応と合わせてクローズする。

本 issue のスコープに追加したいもの

レビューで指摘された 初回 KeyEnvelope の送信者鍵 TOFU も、同じ trust anchor に依存するのでここで扱うのが自然:

• 現状: 初回は caller 供給の sender_public_key をそのまま HPKE Auth の検証鍵にし、成功後にピンする。HPKE Auth が証明するのは「その入力鍵の持ち主が作った」ことであり「owner が作った」ことではない
• 平文を知る第三者は、自分の鍵で整合する envelope を作って先にピンを奪える(以後、正規の envelope がピン不一致で弾かれる)
• 修正方針: 初回送信者鍵を owner identity または検証済み delegated token の issuer へ束縛する。つまり「版の真正性」と同じく owner を信頼の根に置く話に帰着する

提案する解決の形(再掲)

owner 署名付き head ポインタ:

head_cert = sign_owner(content_id, latest_version_cid, seq)

• クライアントは owner 公開鍵(初回 share 時にピン、または帯域外)で検証し seq を比較するだけ
• 祖先 walk・逐次 fetch・版 TOFU が不要になり、クライアント状態は整数 1 個に縮む
• crsl-lib の Node 形式を変えずに済む(Node への署名埋め込みは CID 形式ごと変わる)
• state node は head_cert を版と一緒に保存・返却するだけ
• 委譲 write を許す場合は writer の head 署名 + 委譲 JWT のチェーンで拡張

残る限界は「owner がオフラインの間の最新性は保証できない」だが、これは否定的事実の証明不能性に由来し、どの方式でも同じ。head 方式のほうが保証の境界が明確になる。

[somasekimoto]

追記: 初回 sender key の TOFU も同じ trust anchor 問題

PR #56 のディープレビュー (B56-7) で、本 issue の「版メタデータの trust anchor」と同根の穴がもう 1 つ指摘された。併せてここで追跡する。

初回 KeyEnvelope の sender key は TOFU

monas-sdk/src/controller/share.rs。初回の KeyEnvelope は caller が提示した sender key をそのまま採用する(Trust On First Use)。HPKE Auth が owner identity を証明するのは 2 回目以降であり、初回は証明していない。

default read が証明していないもの

monas-sdk/src/controller/state.rs。default read は未認証の history から version を選び、その CID に対する self-consistency と AES-GCM 復号を確認する。これが証明するのは payload bytes と CEK の所持だけで、次は証明していない。

• 正規 writer であること
• 正規 series であること
• それが latest であること

read-only recipient も CEK を持つため、CEK 所持は write authority ではない。

位置づけ

本 issue の案 A(Node への owner 署名)/ 案 B(checkpoint)は、初回 sender key の問題にもそのまま効く — どちらも「owner / authorized writer の署名を trust anchor に置く」ことだからである。したがって別 issue に分けず、本 issue のスコープに含める。

PR #54 / #56 は本 issue を未解決のまま、保証範囲を design.md に明記した部分 hardening として扱う。

関連

• [Security] relay read: 未証明の DHT 候補を member として扱い、credential 転送と認可否定の受理を行っている #63 (member discovery の trust anchor)
• [Security] mutation の single-use が node-local・volatile で Content Network 全体に効かない #65 (mutation の single-use — 同じく「誰の署名を根に置くか」に依存)