内部告発の証拠：公開せずにタイムスタンプを付与する

封印付きの存在証明（Proof of Existence）を使えば、ファイルを一切公開することなく内部告発の証拠を保全できます。送信者は証拠をハッシュ化し、選んだ一人の受信者向けに暗号化したうえで、Label 309 レコードを Cardano 上に公開します。オンチェーンのレコードが持つのはハッシュとラップされた鍵だけです。平文も受信者のアイデンティティも一切含みません。後日、受信者がファイルを復号し、タイムスタンプ付きのコミットメントと一致することを確認します。

これによって、証拠が公開された時刻までに存在し、特定の鍵保有者の手に渡ったことが証明されます。一方で、送信者を匿名にするわけでも、身の安全を守るわけでも、法的保護を与えるわけでも、何かが裁判で証拠として採用されることを保証するわけでもありません。封印付きレコードは、それ自体が情報開示の戦略なのではなく、証明と暗号化のレイヤーとして捉えてください。

これが実際に解決する問題とは何か

証拠は脆いものです。ファイルは削除できます。文書は編集できます。スクリーンショットには異議を唱えられます。データベースのエクスポートは再生成して日付を遡れます。内部告発者は多くの場合、特定のファイルが情報開示・報復の申し立て・監査・訴訟の前から存在していたことを示す必要があります。しかも、証拠が問題にしているまさにその組織の善意に頼ることなく、それを示さなければなりません。

同時に、ファイルをそのまま平文で公開することは、危険であったり、違法であったり、あるいは単純に間違っている場合があります。無関係な第三者や、企業秘密、診療記録をさらしてしまいかねません。

封印付き Label 309 レコードは、証明と平文を切り離します。タイムラインは公開で永続的にできます。内容は一人の受信者向けに暗号化されたままです。情報開示という代償を払わずに、タイムスタンプだけを手に入れられるのです。

封印付きの証明は段階を追ってどう機能するのか

その流れはハッシュ・署名・封印・共有で説明したものと同じで、機微な素材に適用したものです。

1. 送信者は証拠ファイル、あるいは多数のファイルを記述した証拠マニフェストを用意します。
2. ソフトウェアが平文のハッシュを計算します。
3. 内容が受信者の受信アドレス向けに暗号化されます。コンテンツ鍵は、age 方式の封印エンベロープのなかで受信者の公開鍵に対してラップされます。
4. 暗号文はコンテンツアドレス指定の保存先（ar:// または ipfs://）に保存されます。そこに保存されるのは暗号文だけで、平文は決して保存されません。
5. Label 309 レコードが Cardano 上に公開され、ハッシュとラップされた鍵を運びます。平文も受信者の公開鍵も含みません。
6. 受信者は後日、暗号文を取得してローカルで復号します。
7. 受信者は平文のハッシュを再計算し、レコードと照合します。

レコードはコミットメントがいつ存在したかを証明します。復号されたファイルは、そのコミットメントが何についてのものだったかを証明します。この両方が必要であり、後半は鍵保有者だけの秘密のまま保たれます。

なぜ証拠をブロックチェーンに直接載せないのか

公開チェーンは永続的であり、安全に公開できない証拠も存在するからです。機微な素材には、個人データ、企業の機密情報、医療上の詳細、企業秘密、認証情報、セキュリティ上の脆弱性、無関係な人々の氏名、法的に制限されたコンテンツなどが含まれていることがあります。それがいったん公開台帳に載れば、もう取り消すことはできません。

封印付きの証明があれば、送信者はバイト列そのものをさらすことなく、それに対してコミットできます。受信者は内容を非公開で受け取って検証する一方、それ以外の世界が目にするのは、何らかの封印付きレコードが特定のブロック時刻に公開された、という事実だけです。これは公開ファイルなしの機密開示で扱ったのと同じパターンです。

受信者は誰にすべきか、そして適切な相手にどう届けるか

受信者は慎重に選んでください。ジャーナリスト、弁護士、規制当局、社内の倫理オフィス、監査人、市民社会組織、信頼できる調査者などが考えられます。譲れない要件は、送信者が、意図された受信者に本当に帰属する受信アドレスを持っていることです。

受信アドレスは公開鍵の文字列にすぎません（age1… のような見た目をしています）。それ単体では、誰がそれを管理しているかについて何も証明しません。Label 309 は、鍵のディレクトリも信頼できるレジストリも意図的に規定していません。ですから機微な証拠については、送信者は双方がすでに信頼している経路でアドレスを確認すべきです。これはまさにファイルを封印する前に受信者を確認するで述べたとおりです。

ここを誤れば、その代償は現実のものになります。間違った鍵に送れば、証拠は意図した相手には読めず、あるいは意図しない誰かに読まれてしまうのです。

送信者はレコードに署名すべきか

帰属を避けることが目的であれば、通常は署名すべきではありません。

レコードレベルの署名は、レコードを公開鍵に結び付けます。これは、企業や名前のある個人が説明責任を望む場合には有用です。一方、送信者が情報開示をアイデンティティに結び付けないようにする必要がある場合には、危険を伴います。

Label 309 における著者署名は常に任意です。署名なしの封印付きレコードでも、証拠のコミットメントが公開された時刻までに存在したことは依然として証明されます。ただ、公開の著者主張を一切行わず、オンチェーンでは送信者のアイデンティティを何も結び付けないというだけです。トレードオフは単純です。

• 署名付きレコードは説明責任を加えます
• 署名なしレコードは、公開された鍵裏付けの帰属を避けられます

どちらが正しいかは、法的・安全面の状況に完全に依存します。そしてそれは、ブログ記事からではなく、弁護士とともに下すべき判断です。

封印付きレコードは送信者を匿名にするのか

いいえ。これは最も重要な限界なので、はっきりと述べる価値があります。

署名なしの封印付き Label 309 レコードは、平文、受信者のアイデンティティ、そして送信者の署名のいずれもチェーン外に保ちます。さらにグローバルなレコードフィードは受信者ブラインドであり、誰が復号できるかを指し示すものは何も含まれていません。しかし匿名性は、一つのレコードのバイト列だけにとどまらない、はるかに多くの要素に左右されます。レコードの外側にあるすべてが、依然として送信者を露呈させ得るのです。

• ネットワークメタデータや IP アドレス
• ブラウザやデバイスのフィンガープリント
• 侵害されたデバイス
• 支払いの痕跡
• ゲートウェイアカウントの活動
• 公開操作どうしのタイミング相関
• ファイル・文書・カメラのメタデータ
• 文体
• 運用上のミス
• 受信者との連絡に使った経路

暗号技術はこれらを解決できません。これらは、専用の情報源保護ツール、運用上のセキュリティ、そして法的助言が担う領域です。封印付き存在証明を匿名化システムとして扱わないでください。あくまでタイムスタンプを付与し暗号化する手段として捉え、それ以外のすべてについては適切なツールと組み合わせてください。

受信者はファイルを手にした後に何を検証できるのか

一致する秘密鍵を持つ受信者は、主張の連鎖全体を確認できます。

• Label 309 レコードが Cardano 上に存在すること
• そのレコードのブロック時刻と確認状況
• 自分の鍵がエンベロープのスロットの一つを開け、コンテンツ鍵を回復できること
• 再計算した平文のハッシュが、チェーン上にコミットされたハッシュと一致すること
• 証拠がより大きなバンドルの一つのリーフだった場合の、Merkle 包含証明
• 送信者が署名を選んだ場合の、レコード署名

一致する鍵を持たない者は、パブリック検証ツールを含め、レコードが存在すること、エンベロープが正しく構成されていること、暗号文の URI が到達可能であることまでは確認できます。できないのは、それを復号することと、何にコミットしているかを知ることです。この分離こそが要点です。チェーンはコミットメントを目撃し、鍵保有者だけが、それが何にコミットしているのかを確かめるのです。

封印付きの証明が証明しないことは何か

タイムスタンプは意図的に範囲が狭いものです。封印付きレコードは、次のことを証明しません。

• 証拠が真実であること
• 送信者が内部告発者保護法によって守られていること
• その情報開示が合法であること
• 受信者が信頼に値すること、あるいは平文の機密を保ち続けること
• ファイルが合法的に入手されたこと
• 送信者が匿名であること

そして、受信者がいったん内容を復号すれば、それを共有することを妨げるものは何もありません。暗号化が守るのは、転送中および保存時のファイルであって、その後の受信者の分別ではないのです。

封印付きレコードが実際に証明することは、限定的で有用です。すなわち、特定のバイト列に対するタイムスタンプ付きのコミットメントが、特定の鍵保有者に届けられた、という事実です。これは、法的助言、ジャーナリズムの情報源保護の実務、安全な通信ツール、安全計画の代わりにはなりません。この境界線についてさらに詳しくは、証明が証明しないことをご覧ください。

なぜ単一のアーカイブではなくマニフェストを封印するのか

証拠は通常、一つのきれいなファイルではなく、ひとまとまりの束として届きます。送信者は、不透明なアーカイブを一つ封印するのではなく、次のような内容を記録した証拠マニフェストを構築できます。

• ファイル名または中立的な識別子
• ファイルごとのハッシュ
• 収集時刻
• 出所と証拠保管の連鎖（chain of custody）に関する注記
• 編集（黒塗り）の状態
• 受信者情報
• Merkle リーフと包含証明

機微なエントリは、それ自体を暗号化することもできます。マニフェストは、受信者が何が開示されたのかを理解し、後から個々のファイルを検証する助けになります。大規模なセットでは、単一の Merkle ルートが束全体にコミットしつつ、各ファイルを単独で確認できるようにします。これは何千ものファイルを一つのレコードでで扱ったアプローチです。

組織は封印付きの開示を受け取る準備をどう整えるべきか

組織は、機微な証拠の送付を人々に呼びかける前に、下準備を済ませておくべきです。具体的には、受信アドレスを慎重に公開すること、必要に応じてそれをローテーションまたは廃止すること、アドレスの所有権を端から端まで検証すること、復号できる受信者シードを保護すること、誰が復号を許されるかを明確に定義すること、そして封印付き証拠の取り扱い方を文書化することです。

また、その限界について情報源に対して正直であるべきです。受信アドレスは、完全なセキュアドロップシステムではありません。それは受付プロセスの一構成要素にすぎません。本当にリスクの高い開示を支えたいと考える組織には、暗号技術の周囲に法務・セキュリティ・運用の手続きが必要であり、暗号技術だけでは足りないのです。

これは後日、紛争の場面でどう役立つのか

証拠のタイムラインを確立します。後から疑問が生じた場合、受信者は次のものを示せる可能性があります。

• Cardano のトランザクション参照
• Label 309 レコードとそのブロック時刻
• 暗号化されたペイロード
• 復号された証拠
• 一致する平文のハッシュ
• 束ねられたファイルについての、Merkle 包含証明
• そのコミットメントが特定の日付より前に存在していたという事実

これは、調査、報告、法的レビュー、あるいは社内の説明責任プロセスを支える場合があります。しかも、検証に必要なのはトランザクションメタデータとバイト列、そして公開された Cardano エクスプローラーだけなので、CardanoWall が存続しているかどうかには依存しません。これは存在と完全性についての証拠であって、誰が正しいかについての証拠ではありません。時間に敏感な企業の情報開示についての関連パターンはセキュリティインシデントのタイムラインで、より広い法廷の文脈は法的証拠と eディスカバリーで扱っています。

要点だけ

封印付き Label 309 レコードを使えば、内部告発者と選ばれた受信者が証拠を非公開で保全できます。コミットメントにタイムスタンプを付与し、一人の受信者向けにファイルを暗号化し、その受信者が後から、復号したバイト列が公開レコードと一致することを証明できるようにします。

ただし、匿名性も、合法性も、安全も、真実も保証しません。そして受信者は、復号したものを漏らすこともできます。これは、より広範で、十分な助言に基づいた情報開示プロセスのなかの、慎重に扱うべき一つのレイヤーとして使ってください。計画のすべてとして扱ってはいけません。

さらに読む

• 公開ファイルなしの機密開示
• ファイルを封印する前に受信者を確認する
• 証明が証明しないこと
• Label 309 標準：label309.org
• オープンソースのコード、CLI、SDK：github.com/cardanowall