ファイルを公開せずに行う機密開示

ファイルを公開しないまま、そのファイルが特定の時点に存在していたことを証明できます。

それを実現するのが、封印付きの Label 309 レコードです。送信者は平文をハッシュ化し、ファイルを暗号化したうえで、証明レコードを Cardano 上に公開します。暗号文はコンテンツアドレス指定の保存先に置かれ、復号できる鍵保有者だけが利用できるようになります。公開ブロックチェーンは、特定のコミットメントが公開されたブロック時刻までに存在していたことを証明します。平文は、選ばれた相手だけが読める状態のままです。

これは、法務・コンプライアンス・セキュリティ・ジャーナリズム・パートナー対応・内部調査といった業務に適しています。タイムラインが重要でありながら、文書を公開インターネットへ投稿すべきではない場面のすべてに当てはまります。

ここでいう機密開示とは何か

それは、世界全体ではなく特定の相手に証拠を共有することを意味します。

その相手とは、弁護士・監査人・規制当局・ジャーナリスト・内部調査チーム・顧客側のセキュリティ担当・取締役委員会・パートナーなどが考えられます。あるいは、将来の自分自身という場合もあります。

目的は、平文を公開ブロックチェーンや公開ウェブサイトに置くことなく、証拠が特定の時点に存在していたことを証明することです。封印付き存在証明（Proof of Existence）は、まさにこの形のために作られています。つまり、非公開のファイルに対する公開された時刻の主張です。

公開チェーンには実際に何が載るのか

公開されるのは証明レコードです。平文は載りません。

オンチェーンのレコードには、次の情報を含められます。

平文のハッシュ。これがタイミングの証明になります。
Cardano トランザクションのブロック時刻
ラップされた鍵素材を保持する暗号化エンベロープ
1 つ以上のコンテンツアドレス指定の暗号文 URI（ar:// または ipfs://）
送信者が署名を選んだ場合の、任意の署名
一度に多数のファイルを対象とする開示の場合の、Merkle ルート

一方で、このレコードには意図的に次のものを含めません。

平文のファイル
読み取り可能な受信者リスト
いずれかの受信者の秘密鍵
ご自分の Identity Seed
復号済みの証拠

はっきり述べておきたい点が 1 つあります。受信者の公開鍵もまた、チェーン上には決して現れません。受信者はレコード内で名指しされることはなく、試行復号（trial-decrypt）に成功して初めて、そのレコードが自分宛てであることに気づきます。観察者は、あるレコードが封印されていることを知り、その平文のハッシュとブロック時刻を見て、ラップされた鍵スロットの数を数えられます。しかしスロットは公開前に安全な乱数順へとシャッフルされるため、「主たる受信者が先頭」といった情報も一切漏れません。数からわかるのはいくつかであって、決して誰かではありません。

暗号文そのものは、URI を持つ人なら誰でもダウンロードできます。一致する鍵がなければ、読み取れないままです。

受信者はどうやって封印付きレコードを開くのか

受信者は送信者に受信アドレスを共有し、送信者はそのアドレス宛てにレコードを封印します。

受信アドレスとは、単なる公開鍵です。送信者は、ファイルの暗号化鍵をそのアドレス宛てにラップします。その後、受信者のクライアントは公開された Label 309 レコードをスキャンし、各レコードの暗号化された鍵スロットを自分の秘密受信鍵で開こうと試みます。これらはすべて、受信者の端末上でローカルに行われます。どのレコードが自分宛てかという情報が、端末の外へ出ることはありません。

スロットが開くと、クライアントは暗号文を取得して復号し、平文のハッシュを再計算して、そのハッシュをオンチェーンのコミットメントと照合します。一致すれば、2 つのことが同時に確認できます。受信者が本物のファイルを手にしていること、そしてそのファイルこそが、記録されたブロック時刻にコミットされたファイルだということです。

受信者は秘密鍵を保有しているため、ここで検証は「コミットメントが存在した」から「この特定のコンテンツが存在した」へと踏み込みます。受信アドレスを共有して封印付きレコードを受け取る送信者側の仕組みについては、封印付きレコードの受け取り方をご覧ください。

暗号化したファイルをメールで送るだけではだめなのか

メールはファイルを動かせますが、耐久性があり独立に検証可能なタイムスタンプにはなりません。

メッセージは削除・改変・紛失されることがあります。添付ファイルは除去されます。メールサーバーは廃止されます。エクスポート形式は雑然としていて、何年も後に真正性を確かめるのは困難です。そのいずれも、ファイルがいつ存在したのかを証明する手段を検証ツールに与えてはくれません。

封印付き Label 309 レコードは、ご自分のメールボックスや誰かのサーバーに依存しない公開された証明アンカーを、ファイルに与えます。暗号化されたペイロードは別途保存でき、受信者は後から、復号したコンテンツが公開チェーン上にコミットされたハッシュと一致することを証明できます。受信者にはメールで通知してもかまいません。ただし、証明そのものをメールに依存させないことです。

暗号化したファイルを非公開ストレージにアップロードするだけではだめなのか

それでもかまいませんし、多くの場合そうすべきです。しかし非公開ストレージだけでは、公開された時刻のアンカーは得られません。

社内のストレージバケット、案件管理ツール、セキュアポータルは、暗号化ファイルを問題なく保管できます。けれども、それら単独では答えられないことがあります。その暗号化パッケージがいつ存在したのか、そして復号した平文が公開されたコミットメントと一致するのかを、後の検証ツールが証明できるか、という点です。それがなければ、「3 月にこのファイルがあった」というのは主張であって、証拠ではありません。

Label 309 は、タイムスタンプ付きのコミットメントを付け加えます。セキュアストレージを置き換えるものではありません。そのストレージの上に、検証可能な証明レイヤーを与えるものです。

開示レコードはいつ署名すべきか

匿名性よりも説明責任が重要なときに署名します。

レコードへの署名は任意です。署名によって、特定のアイデンティティ鍵が開示の裏付けとなります。企業が監査人に正式な証拠パッケージを送る場合や、法務チームが説明責任のある帰属可能なレコードを必要とする場合に役立ちます。署名は公開鍵に裏付けられた作成者の主張であり、検証ツールはどのサーバーも信頼せずにそれを確認できます。

送信者の匿名性のほうが重要なときは、レコードを署名なしのままにします。署名なしの封印付きレコードは、送信者のアイデンティティをチェーン上にまったく結び付けません。これはまさに、内部告発の投函や封印入札のシナリオが必要とするものです。このトレードオフは、意図的な選択であるべきです。署名は開示の背後に誰がいたのかを示せますが、機微な状況では、その同じ帰属が送信者の望む以上のことを明らかにしかねません。

1 つのレコードで複数の受信者に届けられるか

はい。1 つの封印付きレコードは、ファイルの暗号化鍵を複数の受信者ごとに別々のスロットへラップできます。

各受信者は自分の鍵でレコードを開き、ある受信者が自分のスロットを使って別の受信者の鍵を導出することはできません。これは、法律事務所とその依頼者、内部調査チーム、監査人と企業側の担当、複数の規制当局への同時開示、取締役委員会といったケースに対応します。あるいは、他者と共有しつつ自分用に復元可能な控えを残しておく送信者にも対応します。

公開レコードはスロットの数を明かすことはあっても、それが誰のものかという読み取り可能なリストを明かすことは決してありません。

多数のファイルを含む大きな証拠パッケージはどうするか

ファイルごとに 1 トランザクションを使うのではなく、マニフェストと Merkle バッチ処理を使います。

各ファイルをハッシュ化してリーフにし、それらのリーフを単一の Merkle ルートへ畳み込んで、その 1 つのルートを Label 309 レコードに公開します。マニフェストと裏付けとなるファイルは、必要に応じて封印します。後から受信者や監査人は、パッケージ全体を不透明なアーカイブとして扱うのではなく、短い包含証明によって個々のファイルを完全にオフラインで検証できます。包含証明はバッチサイズの対数でしか増えないため、1,000 ファイルの開示であっても 1 件ずつ検証できます。

これは、数千ファイルを 1 レコードにで説明した「多数のファイルに 1 つのルート」と同じパターンです。ここではそれが、大規模な開示を、全か無かではなく検査可能なものにします。

封印付きレコードは実際に何を証明するのか

主張は強力ですが、対象は限定的です。封印付き Label 309 レコードは、次のことを示せます。

そのデータが公開されたブロック時刻までに存在していたこと
復号した暗号文が、コミットされた平文のハッシュと一致すること
レコードが署名されている場合に、特定の鍵がそのレコードに署名したこと
特定のファイルが、Merkle バッチ化された証拠セットに含まれていたこと
鍵と暗号文を保有する受信者が、復号可能な証拠にアクセスできたこと

これらはそれぞれ、タイミングと完全性に関する、独立に確認できる正確な言明です。

何を証明しないのか

同じくらい重要なこととして、これが確立しないことを挙げます。

証拠が真実であることは証明しません。証明が裏付けるのはバイト列とタイミングであって、事実ではありません。
送信者がそのファイルを開示する法的権利を有していたことは証明しません。
受信アドレスが信頼できるプロセスを通じて検証されていない限り、受信者の現実世界でのアイデンティティは証明しません。アドレスの真の所有者を確認するのは別の手順です。ファイルを封印する前に受信者を検証するをご覧ください。
匿名性は提供しません。タイミングのパターン、ネットワークメタデータ、ゲートウェイや決済の痕跡、デバイスのフィンガープリント、運用上のミスは、いずれもレコードの外側に存在する情報を明らかにし得ます。また受信者は、ひとたび復号すれば平文を漏らすこともできます。
法律顧問や安全な開示手順を置き換えるものではなく、ある証明が紛争で役立つかどうかは法域に依存します。

この境界の一般的な説明については、証明が証明しないことをご覧ください。

チームは必要になる前に、どう準備しておくべきか

開示のワークフローは、危機のさなかではなく、その前に定めておきます。あらかじめ次のことを決めておいてください。

誰が封印付きの開示を作成できるか
正式なレコードに署名するアイデンティティがあるとすれば、どれか
どの受信アドレスが信頼でき、それらはどのように検証されたか
暗号文をどこに保存するか
誰に復号を許可するか
複数ファイルのパッケージで、マニフェストをどう構成するか
トランザクション参照をどう記録し、どう引き継ぐか
証拠を法的レビュー向けにどうエクスポートするか

暗号技術は 1 つのレイヤーにすぎません。その周りを取り囲むプロセスこそが、いざ圧力がかかったときに証明が本当に役立つかどうかを決めます。証拠の取り扱いという観点については法的証拠と eディスカバリー（電子証拠開示）を、よりリスクの高い情報源については内部告発の証拠をご覧ください。

要点

機密開示には、2 つのものが同時に必要です。プライバシーと証明です。

封印付き Label 309 レコードは、選ばれた鍵保有者のためにファイルを暗号化したまま保ちつつ、そのハッシュに対する公開されたタイムスタンプ付きのコミットメントを公開します。受信者はローカルで復号し、平文がオンチェーンのハッシュと一致することを確認します。署名、Merkle ルート、複数受信者のスロットは、必要なときにより強力なワークフローの選択肢を加えます。

ファイルを一度も公開することなく、タイムラインを証明するために、これを使ってください。

さらに読む

Label 309 — 封印付きレコードの背後にある、オープンでベンダー中立な存在証明の標準です。Label 309 はオンチェーンのメタデータラベルであり、この提案は Cardano の CIP プロセスにおいて、メタデータカテゴリーの CIP として審査中です（公開中のプルリクエスト）。
CardanoWall オープンソース — 標準のコーパス、各種 SDK、そしてレコードの構築・封印・検証ができる cardanowall コマンドラインツールです。
証明が証明しないこと — あらゆる存在証明に共通する限界です。
ファイルを封印する前に受信者を検証する — 暗号化ワークフローで最もよくある人為的ミスです。