付録: クレーム ID インデックス (信頼できる唯一の情報源)
この付録は、ホワイトペーパー内のすべてのクレーム ID について、信頼できる唯一の情報源となるものです。各クレームには一意で安定した ID とアンカーが付いており、記述と根拠を 1 行にまとめて掲載しています。根拠のリンク先は、繰り返し検証できる権威ある参照先 (各章のアンカー、またはステータスや第三者レポートの入口) に限られ、スクリーンショットや再ホストしたコンテンツにはリンクしません。
運用ルール
- MUST: クレーム ID は一意かつ安定したものとし、一度公開した ID は再利用しません。
- MUST: 各クレームの根拠は、繰り返し検証できるもの (各章のアンカー、または権威ある第三者の入口) でなければなりません。
- MUST: 記述は、根拠が裏付ける内容だけを主張します。「絶対的な安全」といった表現は避けます。
- SHOULD: 実装やポリシーの変更がクレームに影響する場合は、変更履歴に記録し、影響を受けるクレーム ID にリンクします。
第 1～4 章 (範囲、脅威モデル、アーキテクチャ、認可)
SCOPE-01
記述: 本書では、対象範囲内のリスクと範囲外のリスク、およびシステムのセキュリティ境界を明確に定義しています。 根拠:1.3， 1.4
THREAT-01
記述: 脅威モデルは、ネットワーク攻撃、不正なダウンロード、ストレージやサーバー側からの読み取りの試み、ブラウザー側の攻撃者を対象としています。 根拠:2.2
BOUNDARY-01
記述: 信頼境界によって、クライアント、サーバー、オブジェクトストレージ、外部環境それぞれの責任を明確に分離します。サーバーは CEK を取得してはなりません (MUST NOT)。 根拠:2.4
FAILCLOSE-01
記述: 認証に失敗した場合やコンテキストが一致しない場合、システムはフェールクローズ (安全側に停止) し、平文を一部でも出力しません。 根拠:2.5
ARCH-01
記述: 中核となるデータオブジェクトは明確に分離されています。暗号化されたチャンク、マニフェスト、監査データは互いに独立しています。 根拠:3.2
FLOW-UP-01
記述: アップロードの流れには、transferId の作成と、有効期間の短いアクセストークン (サーバー側で照合するセッショントークン) の発行が含まれ、スコープと有効期限を厳格に管理します。 根拠:3.3
FLOW-DL-01
記述: ダウンロードでは URL フラグメントを解析して CEK を取得します。マニフェストとチャンクの読み取りには、それぞれスコープの異なるトークンを使用します。認証に失敗した場合はフェールクローズします。 根拠:3.4， 2.5
AUTH-TOKEN-01
記述: 有効期間の短いアクセストークンは、サーバー側で照合する有効期限付きのセッショントークンであり、暗号文とマニフェストへのアクセス制御に使われます。 根拠:4.2
AUTH-SCOPE-01
記述: トークンは read_manifest / read_chunk / upload_chunk などのスコープで分離され、厳格に検証されます。 根拠:4.3， 4.4， 3.4
AUTH-PAID-01
記述: 有料ユーザーはワンタイムのマジックリンクでログインし、送信者側の管理操作に使う長期間有効なトークンをクライアント側で保持します。 根拠:4.1， 3.5
REVOKE-01
記述: 送信者はアクセスを取り消せます。転送の削除やファイルの削除により、ダウンロードを早期に無効化し、以後のアクセスを拒否します。 根拠:4.5
AUDIT-01
記述: ダウンロード回数や進捗などの監査データは送信者にだけ表示され、受信者には表示されません。 根拠:4.6， 3.5
LOG-01
記述: クライアントとサーバーのログおよびテレメトリには、CEK、URL フラグメント、鍵を導き出せる情報は含まれません。 根拠:4.7， 10.2
第 5 章 (暗号と鍵管理)
CRYPTO-ZK-01
記述: CEK はブラウザー内でのみ生成され、URL フラグメントで受け渡されます。サーバーが CEK を含む完全なダウンロードリンクを生成することはありません。 根拠:5.3.1， 5.3.2
CRYPTO-ZK-02
記述: サーバーは CEK を受信、保存、ログ記録しません。オブジェクトストレージに保存されるのは暗号化されたチャンクだけです。 根拠:5.0， 5.5.1
CRYPTO-E2EE-01
記述: チャンクには AES-128-GCM を使用します。認証に失敗した場合はフェールクローズし、平文を一部でも出力しません。 根拠:5.4.2， 5.8.4
CRYPTO-CHUNK-01
CRYPTO-NONCE-01
記述: IV は noncePrefix(8B)||uint32_be(chunkIndex) として導出され、同一の CEK のもとで重複してはなりません。 根拠:5.4.3， 5.8.1
CRYPTO-AAD-01
記述: AAD は transferId + fileId + chunkIndex に紐づけられ、EncodeAAD_v1 でエンコードされます。 根拠:5.4.4
CRYPTO-CLIENT-01
記述: ダウンロードおよび復号のページでは、サードパーティのスクリプトを読み込みません。クライアントのログやテレメトリには、フラグメントや鍵に関する情報は含まれません。 根拠:5.6， 10.2
CRYPTO-TLS-01
記述: サイト全体で HTTPS を強制しています。TLS の設定は、公開されている第三者レポートで検証できます。 根拠:5.1.2， /status#tls-configuration
第 6～7 章 (データのライフサイクル / 不正利用対策)
LIFECYCLE-01
記述: 有効期限の到来やユーザーによる削除をきっかけにクリーンアップが実行されます。ダウンロードを早期に無効化する取り消しにも対応しています。 根拠:6.2， 6.3， 4.5
ABUSE-01
第 8～9 章 (プライバシー / Web セキュリティと分離)
PRIVACY-01
記述: ゼロ知識の定義と約束事を明示しています。CEK はクライアント上でのみ生成・使用され、サーバーは鍵を復元できません。 根拠:8.1
PRIVACY-02
記述: URL フラグメントがプライバシーに及ぼす影響 (コピー&ペースト、リファラー経由の漏えい、ログ記録) と、その対策を文書化しています。 根拠:8.2， 10.2
WEB-01
記述: 主要なページでは、厳格な CSP とリソース境界を適用し、インジェクションやクリックジャッキングのリスクを低減しています。 根拠:9.1， 9.3
WEB-HEADERS-01
記述: セキュリティヘッダーの基準は、公開されている第三者レポートで検証できます。 根拠:/status#security-headers
WEB-OBS-01
記述: 本サイトは、公開されている第三者のベストプラクティススキャンで確認できます。 根拠:/status#http-observatory
第 10～12 章 (ログとインシデント対応 / 脆弱性の開示 / 証拠)
OBS-01
記述: 可観測性は最小限の原則に従い、運用とセキュリティに必要な範囲だけを対象とし、集計やサンプリングの手法を用います。 根拠:10.1
IR-01
記述: セキュリティインシデントへの対応プロセス (重大度の判定、封じ込め、事後検証、是正、公表) を定めています。 根拠:10.4
VDP-01
記述: 脆弱性の開示プロセスを設けており、ゼロ知識の境界に影響しうる問題を優先して扱います。 根拠:11.2
EV-01
記述: ステータスページには第三者による証拠の入口をまとめています。証拠は権威ある情報源にリンクし、適用範囲の境界を明示します。 根拠:12.2， 12.6