要点

  • draft-irtf-cfrg-bbs-signatures-12 は、複数メッセージに対する一つの署名を知っていることを、選んだメッセージだけ開示して証明できる。非リンク性が保証する対象はランダム化された proof value であり、署名時の header、提示ごとの presentation_header、開示値、総メッセージ数と位置、署名者公開鍵、通信・端末メタデータまで自動的に隠すものではない。
  • ProofVerify の成功は、指定された鍵と入力に対する暗号学的関係を確認する一枚の受領書である。本人確認、発行時の実在性調査、現時点の失効状態、提示の十分性、認可、提示全体の追跡不能性、実行結果は別の責任主体と証拠を要する。

プライバシー事故の報告書には、しばしば二つの正しい数字が並ぶ。暗号チームは「同じ署名から派生した proof を proof bytes だけで結び付けられない」と報告する。分析チームは「二つのセッションを確実に同じ利用者群へ分類できた」と報告する。矛盾ではない。観測対象が違う。

第12版のBBS草案は、この違いを曖昧にしない。多メッセージ署名、選択的開示、ゼロ知識の知識証明という強い機構を示す一方、プライバシー節では証明値の外側に残る結合点を列挙する。導入審査で重要なのは前半だけを機能表へ写すことではなく、後半を運用契約へ変えることである。

具体的なテストベクトルは、現場の匿名性を証明しない

第12版は2026年9月28日に提出されたCFRGのIRTF文書で、Informationalを意図する作業中のInternet-Draftである。RFCでもIETF Standards Track標準でもなく、特定製品の実装・相互運用・普及を示す記録でもない。

第11版との大きな差は、テンプレートのまま残っていた暗号スイート定数、メッセージスカラー、生成元、署名、proof fixture が具体値になったことだ。実装者は固定入力に対する出力を一バイトずつ比較できる。これはアルゴリズムとシリアライズの再現性にとって重要である。

しかしfixtureは、鍵、メッセージ、header、擬似乱数をあらかじめ与える。実運用が問うのは、鍵を誰が配り、全員が同じ鍵集合を見たか、headerが何人で共有されたか、乱数状態がforkやsnapshot後も再利用されなかったか、端末IDやIPアドレスが同じログに残ったか、という問題である。固定ベクトルは、入力の選択やログ設計を審査しない。

したがってリリース証拠は二層に分けるべきだ。第一層は「このビルドが第12版の所定ベクトルと一致した」。第二層は鍵配布、匿名集合、header分布、RNGの一意性、メタデータ最小化、クロスverifier相関試験である。前者を通過したことから後者を推定してはいけない。

VALID が意味する文を短く保つ

BBSでは、一つの固定長署名が順序付きメッセージ列を覆う。holderは署名を直接見せず、選択した位置のメッセージだけを開示して、署名を知っていることのランダム化証明を作る。検証側は署名者公開鍵、proof、署名に束縛された header、proofに束縛された presentation_header、開示メッセージと元のインデックスを入力する。

検証成功から言えるのは、proverがその公開鍵の下で有効なBBS署名を知り、開示値が指定位置に入り、二つのheaderがproofに束縛され、非開示値や隠された署名がproofから露出していない、ということまでである。

proverソフトウェアを操作した人の戸籍上の身元は出てこない。issuerが元の事実をどう調べたかも出てこない。失効・一時停止・更新はアプリケーションが別に確認しなければならない。必要な項目がすべて提示されたか、ローカル規則が入場や送金を許すか、その後に扉や台帳がどう変わったかも別問題である。

既存のRFC 9901記事は、SD-JWTにおける「正しい開示」と「完全な記録」を分けている。本稿はそこを取り直さない。BBS固有の焦点は、proof value の非リンク性が成立したまま、提示の外形が追跡可能になる点である。

署名者が選ぶ header は毎回姿を現す

草案には二種類のheaderがある。header はSignerが選び、署名と、その署名から派生するすべてのproofに束縛される。Proverは提示のたびにVerifierへ見せなければならない。共通のアプリケーションID、配備ドメイン、低カーディナリティの版番号を入れるには便利だが、利用者固有値を入れると恒久的なタグになる。

ランダムなcredential ID、メールアドレス、秒単位の失効時刻、個別端末番号をheaderに置けば、proofが毎回完全に異なっても同じ値が繰り返される。草案がSignerに、広い利用者群で共有する低エントロピー値を求める理由はここにある。

ただし低エントロピーは辞書上の属性ではない。国コードは大規模サービスでは広いが、小規模外交団では個人を絞り得る。ソフトウェア版は配布直後に一般的でも、更新が進めば旧版の数台を特定する。header、公開鍵、地域、メッセージ構造を組み合わせた最小集合を測らなければならない。

issuerの受領書にはheaderの原バイト列、生成規則、想定・実測の共有人数、利用鍵、例外の禁止を残す。Holderは署名に固定されたheaderを後から安全な値へ変更できない。権限を持つissuerが、そのリスクの所有者でもある。

presentation header はchallengeを束縛するが、文脈を発明しない

presentation_header はProverが一回のproofに選ぶ。Verifierのnonce、audience、domain、有効期間、あるいはProverが署名したいメッセージを含められる。検証成功は、その値がproofと一体であることを示す。

新鮮性には運用状態が必要だ。nonceを誰が生成し、どのsessionとaudienceに属し、いつ失効し、既に消費されたかをVerifierが管理する。非対話型なら別の一意性規則がいる。値がランダムに見えることは、正しい取引へ結び付いたことと同じではない。

プライバシーも同様である。毎回異なる高エントロピー値は有用だが、再利用すれば安定したjoin keyになる。正確な位置、account ID、build番号を埋めれば一回限りでも利用者を識別することがある。暗号で完全性を守られたフィールドが、プライバシーに安全とは限らない。

ログにはnonceの発行主体、session、audience、作成・失効・消費状態を残し、保存期間を別に決める。「nonce valid」の一ビットだけでは判断を再構成できず、全challengeの永久保存は新しい相関台帳を作る。

値を隠しても、資格情報の形は残る

proofの長さと開示リストから署名メッセージの総数が分かり、開示インデックスから元schemaの位置が分かる。五項目の一般社員、九項目の請負人、十三項目の保護プログラムという設計なら、非開示値を一つも解読せずに分類できる。珍しいインデックスの組合せはさらに強い指紋になる。

草案が共通長へのpaddingと一貫した順序を勧めるのは、符号化の美しさではなく匿名集合のためである。schema版、総項目数の分布、padding規則、位置表、optional claimが少人数パターンを作らないことを検査する。

paddingには帯域と実装コストがあり、珍しいpadding方式自体が識別子になり得る。先に「誰と誰を区別不能にしたいか」を決め、実際の提示組合せで最小集合を測る必要がある。

公開鍵の配り方が利用者を分割する

Verifierは署名者公開鍵を使う。一人または少数だけに別鍵を割り当てれば、その鍵で検証されるすべてのproofが小集団を示す。proof bytes の非リンク性は、この鍵レベルの分類を防がない。

悪意がなくても発生する。地域ごとの時差rotaton、canary、事故隔離、合併前の鍵階層は集団を細分化する。悪意あるissuerなら特定Holderにだけ異なるkey viewを見せ、目印にできる。

必要なのは「鍵が正しい」という一行ではなく、鍵バイト、配布経路、開始・終了、想定母集団、実測発行数、一貫性の証拠である。全世界一鍵は匿名集合を広げるが漏えい半径を広げる。階層鍵は障害を分離するが群を小さくする。どちらもトレードオフを記録して選ぶ。

開示された正しい値は、最も強い識別子にもなる

氏名、政府番号、メール、電話は署名済みで真正でも、二度出せば直接リンクする。職種、誕生日、小さな自治体の組合せも個人を狭める。BBSは開示値の真正性を守るが、Verifierがその値を必要とするかは決めない。

「18歳以上」だけ必要な場面で正確な生年月日を要求すれば、アルゴリズム違反なしにプライバシー利益を失う。range proofやset-membership proofは改善策になり得るが、別の構成と検証責任を伴う。基礎BBSだけで閾値や非失効性が出てくるわけではない。

乱数は実装詳細ではなく秘密保持の材料である

ProofGen は毎回独立で一様な複数のランダムスカラーを必要とする。再利用、予測、既知の関係があれば、非開示メッセージや隠れた署名が漏れる可能性がある。形式上validなproofを返しても、プライバシーは失われ得る。

草案は、乱数出力の数ビットを攻撃者が操作し、秘匿データを外へ運ぶ可能性も述べる。唯一で一様なseedから決定的RNGを動かす設計は操作可能量を狭める一策だが、seed生成と保管の信頼は残る。

監査にはRNG種別、ライブラリbuild、seed経路、health test、fork、VM snapshot、失敗時の挙動、retry時の状態を含める。加えて公開鍵のdeserialize、subgroup check、domain separation、constant-time処理、message-to-scalar前処理の一致を独立に確認する。fixtureの成功はこれらを代行しない。

隣接拡張の機能を基礎BBSへ混ぜない

Blind BBS Signatures は発行段階でHolderの一部メッセージをSignerから隠す別プロトコルである。通常BBSの選択的開示は提示段階でVerifierに見せない仕組みであり、Issuerが発行時に知らなかったことを意味しない。

BBS per Verifier Linkability はcontext依存pseudonymを追加し、一つのVerifier内では再訪を認識し、異なるcontext間では結び付けにくくする別拡張である。基礎BBSは同じHolderのproofへ安定pseudonymを自動生成しない。

W3Cの bbs-2023 はVerifiable Credential向けにmandatory/selective pointer、データ変換、任意のholder bindingやpseudonymを定めるapplication profileである。調達時はdraft revision、ciphersuite、interface、extension、profileを列ごとに確認する。「BBS対応」だけでは能力範囲が分からない。

量子計算後も残るものと失われるもの

BBSの真正性は離散対数の困難性に依存し、post-quantum secureではない。十分な量子計算機が署名秘密鍵を復元すれば、攻撃者は選んだメッセージの署名とproofを作れる。

一方、草案は既存proof内の非開示値と隠れた署名の秘匿を情報理論的と説明する。無限の計算力と署名秘密鍵を持っても、proof値からそれらを抽出できない。これはproofのeverlasting privacyであって、credential system全体の量子安全性ではない。

移行は真正性の期限とログ秘匿の期限を分ける。鍵を交換しても、開示値、header、IP、端末ID、保存済み相関結果は消えない。過去データの保管方針は暗号移行とは別の決定である。

一つの verified フラグを廃止する

最小受領書は、文書版とciphersuite、issuer keyの出所と一貫性、発行方式、headerと共有人数、schema・padding、開示値とインデックス、presentation headerとnonce、proofと検証結果、RNG、parser・subgroup・domain-separation、通信・端末メタデータ、失効状態、policy、authorization、action、effect、retention、量子移行を分ける。

中央管理でなくてもよい。Issuer、Wallet、Verifier、Application、Security、Privacyの各ownerが、自分の決定を記録し、限定されたtransaction IDと時間で結合する。Lu Hengの最小初期仕様は共通暗号層を小さく保ち、結果を引き受ける現場へ判断を返す。現実層の区別はzero-knowledgeを認可へ昇格させず、running-code primacyは実際に使われた鍵、header、RNG、binary、log pathを求める。

BBS proofは弱くない。むしろ約束が強く、対象が明確である。弱いのは、その対象を無言で「会話全体」へ拡張する統治である。

出典