ブラインド署名バウチャーと匿名アクセス資格情報
AeroNyx の VPN バウチャーにより、ノードが支払ったアカウントを知ることなく支払いを検証できる仕組み、reject_invalid 展開モードでまだ許可されていること、ノードとバックエンドが依然として見られるもの、そして Blind Vault の入場が実装済みでありながらデプロイされていない理由を説明します。
AeroNyx はブラインド署名されたバウチャーを使い、VPN ノードが、どのアカウントが支払ったかを知ることなく、接続が支払い済みであることを確認できるようにしています。これは現在 VPN で稼働していますが、バウチャーのない接続も引き続き受け付ける互換モードで動作しています。もう一つの資格情報の経路である Blind Vault の入場は、ノードソフトウェアに存在しますが、デプロイされておらず、公式アプリでも使われていません。
2 つの資格情報の経路
| 資格情報の経路 | 状態 | 引き換えのモデル |
|---|---|---|
| VPN ハンドシェイクのバウチャー | 稼働中。reject_invalid 互換モードで動作 | ノードは署名を検証します。1 回限りの使用は追跡しません |
| Blind Vault V2 の入場 | ノードに実装済み。デプロイされておらず、公式アプリでも使われていません | 1 回限りの使用を、リースの作成と原子的に記録します |
| Blind Vault V1 の入場 | 互換性のためのみで、同じく無効化されたコンポーネント内にあります | 1 回限りの使用ですが、発行と引き換えを紐付けることができます |
VPN バウチャーの発行方法
- アプリはランダムな 32 バイトのトークンを生成し、RSA ブラインド署名(RSABSSA-SHA384-PSS-Randomized、RFC 9474)を使ってローカルでブラインド化します。
- アプリは、ブラインド化されたメッセージだけを AeroNyx バックエンドの
/api/voucher/issue/に送信します。バックエンドは、サインイン中のアカウントに権利があることを確認し、ブラインド化されたメッセージに署名して、その署名を返します。バックエンドがトークンを見ることは決してありません。 - アプリはローカルで署名を確定させます。完成したバウチャー(トークン、署名、メッセージランダマイザー、鍵のエポック)は、発行リクエストと紐付かない持参人型の資格情報です。
エポックごとにまとめられた発行者の公開鍵は、次の場所で公開されています。
GET https://api.aeronyx.network/api/voucher/issuer/keys/
ノードによるバウチャーの検証方法
アプリは VPN の ClientHello にバウチャー拡張を付加します。
ClientHello fixed frame
+ magic: AVCH
+ voucher_length: u16 little-endian
+ voucher JSON (maximum 2048 bytes)
{
"token": "base64-32-byte-token",
"signature": "base64-finalized-blind-signature",
"msg_randomizer": "base64-32-byte-randomizer",
"epoch": "issuer-key-epoch"
}
ノードはこれらのフィールドだけを解析します。上記のエンドポイントからそのエポックの発行者公開鍵を取得し、1 時間キャッシュして、ランダム化された SHA-384 の RSA-PSS 署名を検証します。ウォレットやアカウントの識別子は必要ありません。
展開モード:reject_invalid
- 形式が不正なバウチャーや暗号学的に無効なバウチャーは、ハンドシェイクが受け入れられる前に拒否されます。
- バウチャーがまったくない接続も引き続き受け付けられます。これは古いクライアントが動作し続けるようにするためです。バウチャーの使用はまだ必須ではありません。
- ノードは使用済みのバウチャーを 記録しません。ノードは、有効なバウチャーを、その発行者鍵のエポックが公開されている限り、提示されるたびに何度でも受け付けます。共有、リプレイ、クォータの制限は、ノードではなくバックエンドが適用します。
ノードが報告するのは集計結果だけです。
mode = reject_invalid
valid | invalid | missing | malformed | total
valid_ratio | invalid_ratio | missing_ratio | malformed_ratio
last_observation | last_error
ノードがあなたについて知ること
「ノードがあなたのウォレット ID を知ることは決してない」という保証が成り立つのは、バウチャーによる接続の場合だけ です。
- バウチャーによる接続(公式アプリ): アプリはバウチャーと、新しく生成した一時的なハンドシェイク鍵で接続します。ノードは支払いを検証できますが、セッションをあなたのウォレットや P2P ID と紐付けることはできません。
- レガシー接続: バウチャーの代わりに自身の ID 鍵で認証するクライアントは、ハンドシェイクでその鍵を送信します。
どちらの場合も、ノードはセッションのハンドシェイク公開鍵を、セッションの時刻とバイト数とともに、client_wallet という名前のフィールドで AeroNyx バックエンドに報告します。バウチャーによる接続では、その値は一時的な鍵です。レガシー接続では、クライアントの ID 鍵です。ノードオペレーターは、セッション単位のトラフィックとこれらの鍵を Nodeboard で確認できます。
バウチャーは、それ以外のすべてを隠すわけでもありません。一般的な VPN と同じく、ノードは引き続きあなたの IP アドレスを把握し、出口として宛先と DNS も把握します。アプリが 1 日分の接続を予約する際、バックエンドはそのアカウントがその時刻に接続したことも記録しますが、どのノードを使ったかは記録しません。VPN の比較とトラストセンターをご覧ください。
Blind Vault の入場(未デプロイ)
Blind Vault は、クライアント側で暗号化されたオブジェクトを匿名のリースのもとで保存するためのノードコンポーネントです。MemChain と Blind Vaultで説明しています。入場の設計は次のとおりです。
- V2: クライアントは RFC 9474 の入場メッセージをブラインド化します。権利確認サービスが発行を承認し、別個の署名プロセス(
aeronyx-blind-issuer)がブラインド化されたバイト列だけに署名します。このプロセスは、アカウントデータベース、ストレージ、引き換え状況のいずれにもアクセスできません。ノードは、確定済みの資格情報を固定された公開鍵のエポックに照らして検証し、1 つの SQLite トランザクションの中で、使用済みマーカーを記録し、ランダムで自己認証するリースを作成します。使用済みの資格情報で 2 つ目のリースを作成することはできません。まったく同じリクエストを再試行すると、同じリースが返されます。 - V1: 同じ 1 回限りの使用テーブルを使う持参人型のチケットです。ノードはチケットの識別情報を保存するため、引き換えを発行と紐付けることができます。互換性のためだけに残されています。
ノードがこれらのルートを公開するのは、Blind Vault とその公開 API の両方が有効な場合だけです。どちらもデフォルトでオフです。
GET /api/vault/v1/issuers
POST /api/vault/v1/lease
POST /api/vault/v1/put
POST /api/vault/v1/pull
POST /api/vault/v1/delete
現在の状況:Blind Vault は本番ノードにデプロイされておらず、公式アプリはこれらのルートを呼び出さず、AeroNyx バックエンドには Blind Vault の権利確認エンドポイントがありません。Blind Vault はバックアップ、アーカイブ、ストレージの製品ではなく、そのような製品は提供されていません。
可観測性
オペレーター向けの画面に表示されるのは、資格情報の集計的な健全性だけです。
- VPN の
valid、invalid、missing、malformedの合計と比率、および展開モード - 発行者鍵の可用性と、おおまかな失敗の区分
バウチャーのトークン、署名、ランダマイザー、ブラインド化されたメッセージ、使用 ID が表示されることは決してありません。セッション単位のトラフィックとハンドシェイク鍵は、上記で説明した別のオペレーター向けビューです。
脅威モデルと限界
ブラインド署名は、発行リクエストとバウチャーの間のつながりを断ち切ります。次のリスクを取り除くものではありません。
- バックエンドの発行記録や接続予約記録と、ノードのセッション記録との間のタイミング相関。一方の当事者が両方を見られる場合は、特に該当します
- ノードがあなたの IP アドレス、宛先、DNS を把握すること
- 鍵のエポックが公開されている間のバウチャーの盗難、共有、転売。ノードは 1 回限りの使用を強制しないためです
- バウチャーのない接続。
reject_invalidモードでは引き続き受け付けられます - 発行者鍵のローテーションの誤りや、侵害されたクライアント
ソースマップ
| レイヤー | ノードリポジトリ内のパス | 役割 |
|---|---|---|
| VPN 検証器 | crates/aeronyx-server/src/voucher_verifier.rs | AVCH を解析し、エポックの鍵を取得し、バウチャーを検証し、集計結果を記録します |
| ブラインド署名者 | crates/aeronyx-blind-issuer/src/signer.rs、api.rs | Blind Vault V2 向けの、ID 情報を持たない RSA ブラインド署名 |
| ワイヤ契約 | crates/aeronyx-core/src/protocol/blind_vault.rs | RFC 9474 の入場メッセージ、鍵のエポック、使用 ID |
| Blind Vault のサービスと API | crates/aeronyx-server/src/services/blind_vault.rs、api/blind_vault.rs | 入場、原子的な使用とリース、オブジェクトのルート |
| Blind Vault の設定 | crates/aeronyx-server/src/config_blind_vault.rs | デフォルトでオフ。発行者の固定とローテーションのルール |
ノードソフトウェアは AGPL-3.0 のもと、github.com/AeroNyxNetwork/AeroNyx でオープンソースとして公開されています。アプリはオープンソースではありません。
<!-- faq:start -->よくある質問
AeroNyx の VPN ノードは、私がどのウォレットで支払ったかを知っていますか?
公式アプリが使うバウチャーによる接続では知りません。ノードが検証するのはブラインド署名されたバウチャーと一時的なハンドシェイク鍵で、どちらもあなたのウォレットとは紐付いていません。自身の ID 鍵で接続するレガシークライアントは、その鍵をノードに明かします。
バウチャーは複数回使えますか?
はい。ノードはバウチャーのエポックについて公開された鍵に照らして署名を検証しますが、使用済みバウチャーのリストは保持しません。クォータはバックエンドが適用します。
接続にバウチャーは必須ですか?
まだ必須ではありません。ノードは形式が不正なバウチャーや無効なバウチャーを拒否しますが、古いクライアントが動作し続けるよう、バウチャーのない接続は引き続き受け付けます。
バウチャー発行者の鍵はどこで公開されていますか?
https://api.aeronyx.network/api/voucher/issuer/keys/ で、エポックごとにまとめて公開されています。ノードはこれらの鍵を 1 時間キャッシュします。
Blind Vault はアプリで利用できますか?
いいえ。Blind Vault の入場はノードソフトウェアに実装されていますが、デフォルトで無効で、デプロイされておらず、公式アプリでも使われていません。AeroNyx はバックアップ製品やストレージ製品を提供していません。
<!-- faq:end -->