約9分で読めます
CardanoWall に見えるもの(そして見えないもの)
CardanoWall に見えるのは、アカウント・課金・公開された証明のデータです。設計上、平文の Identity Seed も、秘密鍵も、封印したファイルの平文も見えません。

CardanoWall に見えるのは、通常のサービスデータと、お客様が公開する公開証明レコードです。設計上、平文の Identity Seed(アイデンティティの種)も、秘密鍵も、封印したファイルの平文も見えません。もっとも機微な情報は、当社のサーバーではなく、ご自分のデバイス上で保持・利用されます。
これが、このプライバシーモデルの正直な姿です。CardanoWall はゲートウェイ上に構築されたホスト型の製品であり、動作のためにアカウント・課金・公開・インデックスのデータを実際に必要とします。興味深い問いは「CardanoWall は何かを見ているのか」ではありません。当然、見ています。本当に興味深いのは、それがどんな種類のデータを見ているのか、そして何が当社からは暗号化されたままなのか、という点です。
この記事では、その境界線をカテゴリーごとにたどっていきます。
CardanoWall はどんなアカウントデータを保存するのか
ホスト型サービスとして当たり前のデータです。製品の使い方によっては、次のようなものが含まれます。
- アカウント識別子
- メールアドレスや、連携した OAuth アカウントの参照などのログイン識別子
- 課金記録と前払いの残高
- API キーのメタデータと、ハッシュ化された API キー(平文の鍵は決して保存しません)
- チャージ時に使う決済プロセッサーの参照
- アカウントレベルの設定
- アカウント操作のタイムスタンプ
- サポートおよび運用上のメタデータ
- レート制限とセキュリティのログ
これは、アカウント制のサービスならどこでも保持しているのと同じ種類のデータです。その中に Identity Seed は含まれません。
どんなアイデンティティデータが見えるのか
公開アイデンティティ鍵です。秘密の情報は一切見えません。
CardanoWall では、アイデンティティは単一の 32 バイトの Identity Seed から決定論的に導出されます。サービスがその役割を果たすために必要とするのは、そのアイデンティティの公開鍵です。アイデンティティを一覧表示し、署名済みの証明を数え、所有証明の確認を経てアイデンティティをアカウントに紐付け、お客様が選んで公開する場合に公開プロフィールを表示する、といった用途です。
そのため、サービスから見えるのは次のような公開アイデンティティデータです。
- Ed25519 署名公開鍵
- X25519 受信公開鍵
- 任意のハイブリッド・ポスト量子受信公開鍵
- サービスデータベース上でのアイデンティティの作成時刻
- アカウントとアイデンティティの紐付け状態
- お客様が有効にした公開プロフィールの項目
これらは公開、またはサービスレベルの事実です。秘密署名鍵でも秘密受信鍵でもなく、ここから Identity Seed を復元することはできません。
サーバーが決して見る必要のないものとは
お客様になりすますことを可能にするものすべてです。サーバーは次のものを必要とせず、利用できる形では保持しないように作られています。
- 平文の Identity Seed
- Ed25519 秘密署名鍵
- X25519 秘密受信鍵
- ハイブリッド(ポスト量子)受信シークレット
- パスキーが生成する解錠用の情報
- 復号されたアイデンティティ保管庫の中身
- 封印したファイルの復号された平文
これらはすべて、解錠後のご自分のデバイス上か、お客様自身が管理するバックアップの中に存在します。アイデンティティの持ち運び可能な正式コピーはその Identity Seed です。ホスト型の利便レイヤーではなく、その一つのアーティファクトこそが本当のバックアップなのです。
暗号化された保管庫はサーバーに何を明かすのか
それが存在するという事実です。それ以外はほとんど何も明かしません。
新しいデバイスでパスキーによる解錠を可能にするため、CardanoWall はアカウントごとに現行の暗号化された保管庫の行を 1 つ保存します。サーバーが読み取れるのはその行のメタデータです。最終更新日時、バージョン番号、そしてそれに関連付けられた登録済みパスキー認証情報がどれか、といった情報です。解錠時の UX とライフサイクル管理にこれらが必要だからです。
サーバーにできないのは、保管庫を復号することです。保管庫は、お客様の WebAuthn パスキーの解錠要素(PRF スタンザ)だけに宛てられた単一の age 形式の暗号文です。パスワードから導出される解錠経路も、公開鍵の受信者も意図的に一切追加していません。そのため、保存された暗号文は、サーバーがオフラインで総当たりできるものを何も露出しません。これは身元の預かり(カストディ)ではなく、サービスレイヤーの利便機能です。当社が保持するのは施錠された箱、唯一の鍵はお客様のパスキーが握っています。
保管庫の平文には、お客様の Identity Seed と、秘密の表示ラベルが含まれます。まさにサーバーから読めてはならない情報です。同じ設計は失効の扱いにも及びます。パスキーを 1 つ削除すると、保管庫は残りの要素に対して再暗号化され、以前の暗号文はハード削除されます。これにより、削除された認証器は現行の保管庫をもはや開けなくなります。これは現在の状態に対する本当の失効です。ただし遡及的ではありません。攻撃者がすでに外部へ持ち出していて、なお開けてしまうコピーは、別個の問題です。これについてはパスキーがアイデンティティ保管庫を守る仕組みで詳しく掘り下げています。
どんな証明データが公開されるのか
証明そのものです。Label 309 レコードは、トランザクション参照を持つ誰もが検証できるよう、まさにそのために Cardano 上に公開されます。レコードによっては、公開データに次のものが含まれます。
- コンテンツのハッシュ
- トランザクション参照
- チェーンが割り当てるブロック時刻
- レコードの構造
- 署名と署名者の公開鍵(作成者が署名を選んだ場合)
- Merkle ルート(バッチ処理されたレコードの場合)
- 暗号化エンベロープのメタデータ
- コンテンツアドレス指定ストレージの URI(
ar://、ipfs://) - 暗号化された受信者スロットの数
- 封印付きレコードで使われた鍵交換ファミリー
このデータが公開されるのは意図的です。それこそが、CardanoWall を信頼せずに証明を検証可能にするものだからです。封印付きレコードの場合は、そこにないものに注目してください。ファイルの平文がチェーン上に載ることは決してありません。観察者には、レコードが封印されていること、受信者スロットがいくつあるか、どの鍵交換ファミリーを使っているかは見えますが、受信者が誰なのかも、中身も見えません。
ストレージゲートウェイには何が見えるのか
保存されたバイト列と、リクエストのメタデータです。
レコードが Arweave や IPFS 上のコンテンツを指している場合、そのバイト列を配信する公開ゲートウェイには、それらへのリクエストが見えます。公開ファイルであれば、そのバイト列は平文です。封印したファイルであれば、そのバイト列は暗号文であり、受信者の秘密鍵なしには読めないままであるべきものです。
ゲートウェイは、タイミング、オブジェクトのサイズ、リクエストのパターンも観測できます。機密性を委ねる相手ではありません。だからこそ、機微なファイルはストレージに送る前に封印すべきであって、機密性をストレージレイヤーに頼るべきではないのです。
解錠中のブラウザには何が見えるのか
お客様のアイデンティティとして振る舞うために必要なものすべてです。ただし、それはセッションが解錠されている間に限られます。
解錠後、お客様の Identity Seed と、そこから導出された秘密鍵は、アプリが署名と復号を行えるよう、ブラウザのセッションメモリ上に存在します。封印したファイルを復号すると、その平文もブラウザ内にあります。施錠時やサインアウト時には、そのメモリ上の情報がベストエフォートで消去(ゼロ化)されます。
これはクライアントサイドのプライバシーであり、その限界について正直であろうとしています。シークレットをご自分のデバイスに保つことでサーバーのカストディから守られますが、その代わりにデバイスとブラウザ環境が重要になります。悪意のあるブラウザ拡張機能、敵対的なローカルソフトウェア、あるいは解錠中のクロスサイトスクリプティングの欠陥が活発であれば、メモリ上の内容を読み取れてしまいます。厳格なコンテンツセキュリティヘッダー、スクリプトを最小限に抑えた解錠フロー、明示的な操作時のみの解錠は、いずれもその露出を減らします。しかし、それを完全になくすことはできません。機微なアイデンティティには、信頼できるデバイスを使ってください。何がキャッシュされ、何がされないのかはブラウザストレージとセッション鍵で正確に説明しています。
アドレス帳は何を明かしうるのか
連絡先リストはサービスデータであり、それ自体が機微になりうるものです。
信頼済み連絡先は、誰かにファイルを封印するたびに長い公開鍵を貼り付けずに済むようにする、アカウントローカルのエントリーです。1 つのエントリーには、表示名、署名公開鍵、任意の受信アドレス(従来型とポスト量子)、その連絡先をいつどのように検証したか、そして自由記述のメモを保持できます。
これらは Identity Seed ではありませんが、誰とやり取りしているかのリストは、人間関係やワークフローを明かしうるものです。CardanoWall のログは、それを静かに保つよう書かれています。連絡先を作成・編集するサーバー側の操作が記録するのはリクエスト識別子とお客様のアカウント識別子だけで、連絡先の名前・鍵・メモ・検証方法は決して記録しません。
CardanoWall が約束しないこととは
不可視性は約束しません。
CardanoWall は匿名化ネットワークではありません。ブロックチェーン、ストレージゲートウェイ、決済システム、アカウントのログイン、ブラウザ、そしてネットワーク経路は、いずれもメタデータを露出しうるものです。署名なしの封印付きレコードを公開すれば、送信者・受信者・平文は Label 309 レコード自体の外に保たれます。しかしそれはレコードレベルのプライバシーであって、完全な匿名性ではありません。手数料を支払う Cardano アドレス、ゲートウェイから見えるお客様の IP、そして類似のシグナルは、レコードの外、そしてこの保証の外に存在します。
また、危殆化したデバイスを安全にするものでもありません。解錠中のセッションで悪意のあるコードが動いていれば、そのコードはお客様に見えるものを見ることができます。
そして、公開された証明は設計上、公開のものです。それは、特定のバイト列が特定の公開された時刻までに存在したことを示します。それ自体で、誰がそれを作成したか、誰が所有しているか、あるいはその内容が真実であることを証明するものではありません。その境界については証明が証明しないことをご覧ください。
ひとことで言えば
CardanoWall に見えるのは、サービスデータと公開された証明データです。設計上、平文の Identity Seed も、秘密鍵も、保管庫の平文も、封印したファイルの平文も見えません。
ですから実務としては、機微なファイルはデバイスを離れる前に封印し、Identity Seed の安全なコピーを保管し、信頼できるデバイスで解錠し、チェーン上に公開したものはすべて恒久的に公開だと扱ってください。
良いプライバシーは、それぞれの種類のデータがどこに存在するのかを正確に知ることから始まります。CardanoWall は、もっとも重要なデータがお客様の手元に存在するよう作られています。
関連資料
CardanoWall は、オープンでベンダー中立な存在証明(Proof of Existence)の標準である Label 309 のリファレンス実装です。この標準は Cardano の CIP プロセスに提出されており、メタデータカテゴリーの提案として CIP エディターによる審査中です(公開中のプルリクエスト)。暗号コア、SDK、コマンドラインツールは github.com/cardanowall でオープンソースとして公開されており、当社の言葉を鵜呑みにするのではなく、ご自分のデバイス上で何が計算されているかを正確に監査できます。