112 / 736BLIND

Blind Signature

中身を見ずにメッセージを承認するブラインド署名

発行者の承認が必要なのに、固有の番号を控えられては困る引換券を想像してください。後で発行者は本物の券だと確認できますが、署名から誰が受け取った券かを特定できません。Blind Signature はこの一見矛盾した条件を実現する仕組みです。お金の有効性を確かめる行為そのものが、持ち主の買い物履歴にならないようにする。電子現金の基本となる考え方です。

Blind Signature は、依頼者がメッセージを署名者から隠し、隠した形への署名を受け取り、最後に隠蔽を取り除く暗号技術です。元のメッセージに対する利用可能な署名が残ります。David Chaum はこれを電子現金に応用しました。正しいプロトコルなら、署名時の通信と後のトークンから、そのトークンの発行回を結び付けることはできません。ただし時刻、金額、ネットワークアドレスなどの手掛かりまで消えるわけではありません。

通常の承認では、発行者は券の番号と受取人を一緒に記録できます。店から券が戻れば両者を結び付けられます。Chaum はカーボン紙入りの封筒で説明しました。外から押した印が中の紙に写り、発行者には紙の番号が見えない。取り出した紙には有効な承認が残ります。これは理解のための比喩で、紙と印による安全な手順ではありません。実際には数と数学を使い、コンピューター間でこの分離を実現します。 [7] [1]

アンナが 100 sats のデジタル券を欲しいとします。Sats は Bitcoin の小さな単位です。ウォレットは、こうした券を管理し、支払いに使うためのアプリです。券を区別する予測不能な秘密の値を生成し、別の乱数で数学的に覆います。この変換がブラインディングです。発行者へ送るのは覆ったメッセージで、元の秘密ではありません。ウォレットは後で覆いを外すための情報を保持します。ファイル名を変えたり名前を削ったりするだけでは足りず、厳密な暗号学的性質が必要です。説明を簡単にするため券を一枚としていますが、実際のウォレットでは額面の異なる複数の券で必要な金額を組み立てることがあります。 [8] [2]

ブラインド署名は、誰にでも何でも無料で署名するという意味ではありません。発行者は先にアンナの入金を確かめたり、相当する残高を引いたりできます。希望額の 100 sats は知っていますが、券の秘密の番号を知る必要はありません。署名鍵は秘密の数値データで、発行者のソフトウェアが署名を作るために使います。額面ごとに別の署名鍵を使って価値を結び付ければ、ファイル内の数字を書き換えても高額な券にはなりません。発行者は覆われた入力に署名し、結果を返します。受取資格と、後に個々の券を識別する情報とを分離しているのです。 [7] [8]

ここでアンナが元の秘密を発行者に見せる必要はありません。ウォレット自身が返された結果から乱数による覆いを取り除きます。これが unblinding、アンブラインディングです。適切な設計なら、最初のメッセージへの有効な承認が残り、発行者の秘密署名鍵を手に入れることにはなりません。利用者には残高の増加が見え、数学的な包装と開封は裏側で行われます。このデジタル証票を通常トークンと呼びます。ブロックチェーンは、ビットコインの取引を共同で記録する台帳です。このトークンはその台帳上の独立したビットコインではなく、発行者に対する請求権です。 [2] [8]

検証は、承認がメッセージと正しい発行者の鍵に対応するかを調べます。RSA 暗号方式によるブラインド署名なら公開鍵で足りますが、別の構成では追加の証明や発行者の協力が必要な場合があります。それでも未使用か、誰かがコピーしていないか、発行者に十分な支払準備があるかは分かりません。この三点は別の問題です。本物でも使用済みの入場券では再入場できないように、暗号学的に正しい証票でも次の支払いには使えないことがあります。 [2] [10]

アンナは券をピーターに送ります。ただのデータなので同じコピーを残せます。ブラインド署名は端末のファイルを消してくれません。一般的なオンライン方式では、受取側のウォレットが発行者へトークンを出し、有効性と秘密が既に使われていないかを確認してもらいます。受理すると古いトークンを使用済みにし、ピーターに同じブラインド署名の手順で新しいトークンを発行できます。アンナは新しい秘密を知りません。古いコピーを再度使う試みは記録により拒否されます。同じ資金をもう一度使う double spend、二重支払いを防ぐのは、支払システムの別の役割です。 [9] [8]

逆方向の保護も必要です。許可された署名から、別の秘密を持つ追加の有効な証票を作れてはいけません。これが偽造不可能性です。ブラインド署名では特に one-more unforgeability を調べます。一定回数の署名のやり取りから、さらに一組多い、新しく有効なメッセージと署名を作れるかという問題です。同じ組をコピーするのは前節の問題です。正しい暗号技術でも、資格、金額、許可されたトークン形式をサーバーが確認する必要は残ります。これらの確認を組み合わせて、不正な価値の発行を防ぎます。 [2] [3]

発行者はアンナがいつ、いくら分を受け取ったかを知り得ます。使用時には時刻、金額、受取人のネットワークアドレスが分かることもあります。これらは支払証票に付随するメタデータです。利用者が少なければ、珍しい金額や直後の支払いから関連を推測しやすくなります。共通の検証済み鍵も重要で、一人専用の鍵は目印になりかねません。プロトコルの盲性が守るのは署名と発行との特定の結び付きであり、周辺情報のすべてではありません。侵害されたウォレットを直したり、発行者に支払いを強制したりもしません。 [7] [2]

Chaum の発想は、歴史的に DigiCash と結び付いた電子現金の基礎です。現在の Bitcoin では Cashu や Fedimint が利用し、Lightning Network (ビットコインで素早く支払うためのネットワーク) との接続で入出金をしやすくしています。ただし構成は RSA と異なります。基本の Cashu は発行者であるミントの秘密鍵でトークンを検証します。NUT-12 は公開情報で署名を確かめる証明を追加しますが、未使用である証明ではありません。Fedimint は複数の運営者に管理を分散します。いずれも利用者は発行者への請求権を持ち、資金保管と稼働に依存します。GNU Taler のように、買い手のプライバシーと商店収入の追跡可能性を両立させる設計もあります。 [5] [6] [10] [4]

簡略化すると数式で説明できます。メッセージを安全に数 m に符号化し、公開鍵を n と e、秘密部分を d とします。依頼者は n を法とする乗法逆元 r⁻¹ を持つ乱数 r を選び、m′ = m·r^e mod n を送ります。Mod n は n で割った余りで計算する意味です。署名者が s′ = (m′)^d mod n を返し、依頼者は s = s′·r⁻¹ mod n を得ます。検証では s^e mod n = m となります。r⁻¹ が覆いを外す役目です。これは原理の説明で、完成した安全なプログラムではありません。RFC 9474 ではメッセージ準備、安全な符号化を含む RSA-PSS 署名方式、入力検査、署名鍵の分離も定めます。乱数と適切なプロトコル変種の選択が重要です。 [2] [3]

理解を深めるには、この項目とあわせて次もお読みください David Chaum, Chaumian eCash, DigiCash, Cashu, Fedimint, Bitcoin のプライバシー. 次の項目からも参照されています DigiCash, Chaumian eCash, Reusable Proofs of Work, Fedimint.

DOC · 001David Chaum — Blind Signatures for Untraceable Payments一次資料 DOC · 002RFC 9474 — RSA Blind Signatures仕様 DOC · 003IRTF/CFRG — RFC 9474 publication record仕様 DOC · 004GNU Taler — Principles一次資料 DOC · 005Cashu protocol specifications仕様 DOC · 006Fedimint — How Federations Work一次資料 DOC · 007David Chaum — Security without Identification一次資料 DOC · 008Cashu NUT-00 — Notation and models仕様 DOC · 009Cashu NUT-03 — Swapping tokens仕様 DOC · 010Cashu NUT-12 — DLEQ proofs仕様
改訂日: 一次資料を優先 · 投資助言ではありません