← すべての記事

約12分で読めます

鍵がデバイスから外に出ない理由

CardanoWall では、署名・封印・復号のすべてが手元のデバイスで完結します。ゲートウェイは証明を公開し暗号文を保存しますが、ご自分の秘密鍵を受け取らないように設計されています。

CardanoWall では、ご自分の秘密鍵はデバイスにとどまります。署名・封印・試行復号・検証を行うソフトウェアはすべて手元で動作し、ホスト型のゲートウェイは Identity Seed も、署名鍵も、受信用の鍵も、封印されたファイルを復号する材料も受け取らないように設計されています。

ゲートウェイには、こうした秘密がなくても担うべき仕事がたくさんあります。価格の見積もり、保存用に暗号化済みの暗号文を受け取ること、Cardano トランザクションの送信、レコードのインデックス化、残高の管理などです。これらのどれも、作者性を証明したり封印されたペイロードを開封したりする鍵を必要としません。この分離は意図的なものです。サービスは証明を運ぶ手助けをし、秘密はご自分が持ち続けるのです。

どの鍵の話なのか

Label 309 のアイデンティティは、単一の値から始まります。32 バイトの **Identity Seed（アイデンティティの種）**です。この Identity Seed から、規格に準拠したソフトウェアであれば、アイデンティティが実際に使う鍵を 3 つの役割で導出します。

  • レコードに署名する Ed25519 鍵
  • 古典方式で封印されたレコードを受信する X25519 鍵
  • ポスト量子方式で封印されたレコードを受信するハイブリッドのポスト量子鍵

この導出は決定論的です。同じ 32 バイトは、規格に準拠したクライアントであればつねに同じ 3 組のキーペアを生み出します。これこそが Identity Seed を可搬にし、守るに値する唯一のものにしています。Identity Seed を持つ者なら誰でも、そのアイデンティティを復元し、その名義で署名し、宛先となっている封印付きレコードを復号できます。だからこそ Identity Seed は秘密のままに保ち、以下のすべてはそこから導かれるのです。

クライアントは手元で何をするのか

クライアントは、秘密鍵に触れるすべての操作を担います。

  • Identity Seed の生成またはインポート
  • そこからの署名鍵と受信鍵の導出
  • レコードへの署名
  • アップロード前のファイルの暗号化
  • コンテンツ鍵をラップする封印された受信者スロットの構築
  • 受信したレコードを試行復号して、自分宛てのものを見つけること
  • 暗号文の復号と平文のハッシュの再計算
  • 署名とレコード構造の検証

Web アプリ、デスクトップアプリ、コマンドラインツール、そして SDK 上に構築されたソフトウェアは、鍵をどう保存しどう解錠するかが異なります。それでも、これらの間で原則は変わりません。秘密鍵の素材はゲートウェイへ送られないのです。

ではゲートウェイは何をするのか

ゲートウェイは公開のパイプラインを動かします。具体的には以下のとおりです。

  • 見積もりの算出
  • 暗号化済みの暗号文を受け取り、コンテンツアドレス指定の URI を返すこと
  • 準備済みの証明レコードの受け入れ
  • Cardano トランザクションの送信と、その確認の待機
  • チェーンの再編成への対処と、公開が恒久的に失敗した場合の自動返金
  • レコードを共有フィードへインデックス化すること
  • アカウント残高の管理
  • API の公開とライフサイクルイベントの発行

これらは現実の仕事であり、運用作業の大半を占めます。しかし、そのどれ一つとして、封印されたコンテンツを復号する鍵を必要としません。ゲートウェイは転送と運用の層です。ご自分のアイデンティティ保管庫ではありませんし、そのように振る舞うようにも設計されていません。

なぜこの分離が重要なのか

証明は、その作成を手助けしたサービスを信頼しなくても検証可能でなければならないからです。

もしホスト型のサービスがご自分の鍵の唯一の控えを保持していたら、そのサービスはご自分の信頼の起点になってしまいます。サービスが停止したり、規約を変えたり、侵害に遭ったり、アカウントを凍結したりすれば、署名・復号、さらには検証する能力までもがそれに左右されかねません。Label 309 は、まさにこの状況を避けるために作られています。

Label 309 レコードは公開データから検証可能です。検証者に必要なのは、トランザクションメタデータと、必要に応じてコンテンツのバイト列、そして公開された Cardano エクスプローラーだけです。どの段階でも発行者のサーバーは不要です。封印付きレコードは鍵の保有者が開封できます。署名付きレコードはその署名鍵に照らして確認できます。ゲートウェイは公開をはるかに容易にできますが、設計上、オンチェーンへの掲載を手伝ったというだけで、正しく封印されたペイロードを読み取ることはできません。

それが、「証明を持っていると告げてくるサービス」と「それ自体で成り立つ証明」との違いです。

ゲートウェイは私の封印されたファイルを読めるのか

クライアントがコンテンツを正しく封印していれば、読めません。ゲートウェイが目にするのは暗号文だけです。

封印付きレコードがどう構成されているかを説明します。公開されるオンチェーンのレコードは平文のハッシュにコミットします。そのハッシュとブロック時刻が、タイミングの証明になります。暗号化されたペイロードそのものはオンチェーンには載らず、ar:// のようなコンテンツアドレス指定の URI に置かれます。コンテンツ鍵は 1 つ以上の受信者の公開鍵に対してラップされ、受信者ごとに 1 スロットが割り当てられます。受信者（または送信者）は暗号文を取得し、手元で復号し、平文のハッシュを再計算して、オンチェーンのコミットメントと一致するかを確認します。

ゲートウェイは、封印付きレコードが存在することは把握でき、暗号文のサイズ、アップロードのタイミング、アカウントの活動、トランザクションの状態、そして公開メタデータを観測できます。平文を見るようには設計されておらず、正しい秘密鍵がなければ暗号文は読めないままです。これに付随して、正直にお伝えすべき注意が 2 つあります。封印が守るのは機密性であって匿名性ではないこと。観測可能なメタデータは依然としてメタデータです。そして、ファイルを復号した受信者は、その後に平文を漏らすことをいつでも選べること。暗号化は転送中と保存時のバイト列を守るのであって、権限のある読者がその後にとる行動までは守りません。

ゲートウェイは正当な証明を偽造できるのか

無効な証明が独立した検証を通過することはできないように設計されています。

検証ツールは、オンチェーンのレコード、レコードの構造、ハッシュ、署名、そして開封できる封印付きレコードについては再計算した平文のハッシュを確認します。仮にゲートウェイがトランザクションについて偽りを述べたり、レコードのバイト列を改ざんしたり、署名を取り除いたり、コミットされたハッシュと一致しないバイト列を指し示したりしても、独立した検証ツールがそれを捕捉できるはずです。

これは精密な約束であり、誇張しないことが大切です。ゲートウェイが通常の運用上のかたちで不適切に振る舞うことは、依然として起こり得ます。公開に失敗したり、トランザクションを遅らせたり、エラーを返したり、自身の状態を誤って報告したり、障害を起こしたり、体験を損なったりすることはあり得ます。できてはならないのは、無効な証明を、公開データに照らしてきれいに検証が通るものへと変えてしまうことです。利便性は損なわれ得ますが、暗号学的な主張はゲートウェイが正直であることに依存しません。

では Web アプリについてはどうか

Web アプリはブラウザ内で動くソフトウェアであり、その性質がトラスト・モデルを形づくります。

関わる境界には、ブラウザ、読み込まれるアプリケーションコード、インストール済みの拡張機能、デバイスそのもの、そして解錠の流れが含まれます。ブラウザは便利ですが、ご自分が管理するビルドから動くデスクトップ保管庫やコマンドラインツールと同じ環境ではありません。解錠済みのセッションでは、悪意あるスクリプトがメモリ上の秘密を読み取り得ます。厳格なコンテンツセキュリティポリシー、最小限のスクリプト、そして明示的な解錠ステップはその露出を減らしますが、それを完全になくせると主張できる Web アプリはありません。

専用のデスクトップクライアントが存在する理由の一つがこれです。鍵の保持方法をローカルに保ち、より厳格に管理したい方のためのものです。この不変条件はすべてのクライアントにわたって成り立ちます。クライアントごとに鍵の守り方は異なっても、ゲートウェイがご自分の秘密鍵を必要としないという点は変わりません。境界がどこに引かれているかをより詳しく知るには、CardanoWall に何が見えて何が見えないかをご覧ください。

ではデスクトップアプリについてはどうか

CardanoWall Desktop は、最初からローカルの暗号化された保管庫を中心に据えて作られた、オープンソースかつクロスプラットフォームのアプリケーションです。

Rust のコアが、アイデンティティ保管庫、暗号処理、同期エンジン、試行復号、検証を担い、ウェブビューはインターフェースの描画だけを行います。Identity Seed や、そこから導出された秘密鍵は、通常の JavaScript 文字列としてウェブビューへ渡されることはありません。コンテンツをプレビューする必要があるときは、復号されたバイト列が文字列としてページを通過するのではなく、専用のチャネルを通じてビューへストリーミングされます。秘密はゲートウェイへ送られず、レンダラーへ越えてくることもありません。

このアーキテクチャは攻撃対象領域を狭めますが、消し去るわけではありません。侵害されたオペレーティングシステム、悪意ある依存関係、キーロガー、あるいはユーザーが承認してしまったマルウェアは、依然としてローカルのセキュリティを破り得ます。これは、どのデスクトップウォレットも背負う正直な限界と同じものです。鍵をゲートウェイの外に、そしてレンダラーの外に保つことは意味のある改善であって、完全に侵害されたホストに対する保証ではありません。詳しい仕組みについては、CardanoWall Desktop の概要とオフラインの証明をご覧ください。

ではコマンドラインツールと SDK についてはどうか

これらが重要なのは、ウェブサイトを使わずに同じモデルを利用できるようにするからです。

開発者は、Identity Seed を手元に保ち、レコードに手元で署名し、ファイルを手元で封印し、どのゲートウェイ経由でも送信できます。継続的インテグレーションのシステムは、アイデンティティの素材をチーム独自の管理下に置いたまま、スコープを絞った API 認証情報で公開できます。企業は独自のクライアントを構築したり、Label 309 を既存のソフトウェアに組み込んだりできます。どのインターフェースを選んでも、役割分担は同じです。ゲートウェイが公開し、クライアントが秘密を持ちます。

コマンドラインツールと SDK はオープンソースでゲートウェイに依存しないため、この境界は信頼に委ねるものではなく、ご自分で精査できるものです。

ゲートウェイへ決して送ってはならないものは何か

次のものは、ゲートウェイへも、いかなるウェブサイトへも、決して送らないでください。

  • L309-SEED-1… 形式の Identity Seed
  • 16 進数で表した生の Identity Seed
  • 署名用の秘密鍵
  • X25519 の受信用秘密鍵
  • ハイブリッドのポスト量子受信シークレット
  • 封印されたコンテンツを復号するパスフレーズ
  • 非公開にしておくつもりの平文

ゲートウェイが正当に必要とし得るのは、公開鍵、公開署名、公開されるレコードのバイト列、暗号文、見積もりの識別子、API トークン、そしてアカウント識別子です。これらは秘密のアイデンティティ素材ではありません。ルールは単純です。もしワークフローのどこかで秘密を貼り付けるよう求められたら、いったん立ち止まり、なぜなのかを問いかけてください。

それでも注意が必要なものは何か

ローカルの鍵は、それを取り巻く環境と同じだけの安全性しか持ちません。暗号技術はゲートウェイをご自分の秘密から締め出しますが、ユーザーが Identity Seed を攻撃者の管理下にあるフォームへ書き写してしまう事態までは防げません。ですから、以下のことは依然として必要です。

  • Identity Seed を守り、実際に使えるバックアップを取っておく
  • 機微なものを封印する前に、受信者の受信アドレスを確認する
  • フィッシングサイトを避ける
  • ブラウザ拡張機能について慎重になる
  • デバイスを最新の状態に保つ
  • 適する場面ではディスク暗号化を使う
  • 復号されたファイルがどうキャッシュされるかを理解する
  • デスクトップツールとコマンドラインツールは信頼できるビルドを実行する
  • 共有やチームのワークフローには鍵管理ポリシーを定める

失敗のかたちについては率直にお伝えする価値があります。それらは対称ではないからです。Identity Seed と解錠要素の両方を失えば、そのアイデンティティの今後の利用は失われます。ただし、すでに公開した証明は、公開データから永遠に検証できます。一方、盗まれた Identity Seed はアイデンティティの完全な侵害です。その対応は、新しいアイデンティティを作成して古いものを無効化することであって、パスワードのリセットではありません。リセットは存在しません。それが、保管者を置かないことの代償です。

なぜこれがオープンな標準にとって重要なのか

オープンな証明の標準は、信頼できる一つの運用者に依存すべきではありません。

仮に CardanoWall が明日消えたとしても、Label 309 レコードは依然として意味を持つべきです。企業が独自のゲートウェイを運用しても、そのレコードは依然として標準に準拠しているべきです。Identity Seed を別の準拠クライアントへエクスポートすれば、まったく同じ鍵が導出されるべきです。これが成り立つのは、境界がきれいに保たれている場合だけです。レコードは標準であり、検証は独立しており、ゲートウェイは差し替え可能であり、クライアントが秘密を持ち、そしてアイデンティティの根をいつでもご自分でバックアップできることです。

ですから「鍵がデバイスから外に出ない」というのは、ただの標語ではありません。それは、存在証明（Proof of Existence）を可搬にするものの一部です。どの単一のサービスをも越えて持ち運べる証明であり、本サービスもその例外ではありません。

まとめ

ゲートウェイは証明の公開を手助けします。クライアントが秘密を持ちます。

秘密鍵はゲートウェイへ送られません。コンテンツはアップロード前に暗号化されます。復号は手元で行われます。検証は、サービスの言い分を信頼することに依存しません。これが CardanoWall が拠って立つセキュリティの形であり、そして Label 309 が開かれたまま保とうとしている形です。

さらに読む

securityidentitycardanowall