摘要

  • draft-irtf-cfrg-bbs-signatures-12 允许持有人证明自己知道一份覆盖多条消息的有效签名，同时只公开所选择的消息。草案对“不可关联”的定义非常克制：随机化的证明值不会泄露同一签名或同一 prover，但 header、presentation_header、披露值、消息总数与索引、签发公钥、网络地址和应用元数据仍可形成关联。
  • 因而一次 ProofVerify=VALID 只是证据链中的一个回执。它不自动证明持有人的现实身份、签发核验、凭证当前状态、展示完整性、授权依据、端到端匿名性或业务结果。

许多隐私事故不是因为算法被攻破，而是因为控制面选择了错误的证据对象。安全报告检查 proof bytes，发现两份证明不可区分；分析平台检查整个请求，立即找到同一稀有组合。双方都可能陈述事实，但只有后者回答了部署是否可追踪。

第 12 版 BBS 草案值得领导层阅读，正因为它没有把数学性质写成万能口号。文档先给出多消息签名、知识证明与选择性披露的接口，又在隐私章节逐项说明：承诺只覆盖 proof value，外围值必须另行治理。

第 12 版补齐测试向量，没有替部署补齐隐私

这是一份 CFRG/IRTF 的活跃 Internet-Draft，目标状态为 Informational。它不是 RFC，不是 Standards Track 结论，也不是某个钱包、签发机构或验证服务已经正确部署的证明。

从第 11 版到第 12 版，最明显变化是把原先的模板占位符替换为具体的曲线常量、消息标量、生成元、签名和证明样例。实现者因此可以把固定输入送入程序，逐字节核对输出。对序列化、曲线运算和接口一致性而言，这是高价值的运行代码证据。

但固定样例主动消除了生产环境最重要的不确定性。样例替你提供密钥、header、消息与 mock randomness；现场却必须回答公钥从何而来、不同持有人是否看到同一 key view、header 是否落入足够大的群体、随机数是否复用、设备和网络是否同时暴露标识。通过向量只能证明一个封闭路径算对了，不能证明开放系统选择了安全输入。

发布审批最容易犯的错误，是把可复制的单元测试升格为系统隐私结论。正确写法应是：“此构建对第 12 版指定向量产生预期字节。”随后另列密钥发布、人口分桶、随机数健康、元数据最小化和跨验证方关联测试。没有后一组回执，就不能写“部署不可关联”。

先把 VALID 翻译成一条边界清楚的句子

BBS 用一个固定大小签名覆盖有序消息列表。持有人随后生成随机化零知识知识证明，选择公开其中任意子集。验证输入包括签发者公钥、proof、签名时绑定的 header、本次证明绑定的 presentation_header、公开消息和它们原来的索引。

验证成功可以严谨地表达为：prover 知道一份在该公钥下有效的 BBS 签名；公开值处在这些索引；header 与 presentation header 已被这份证明绑定；验证方没有从 proof 中得到隐藏签名或未公开消息值。

句子到此结束。它没有识别键盘后的人，没有证明签发者当初怎样核实现实事实，没有查询撤销或状态源，没有判断遗漏字段是否重要，也没有替业务规则完成授权。门禁、支付、账户恢复或跨境检查的后果必须由后续系统单独记录。

RFC 9901 的既有文章已经占有 SD-JWT 的“有效披露不等于完整记录”论点。本篇不重复它。BBS 的独特风险在于：即使 proof 本身实现了更强的随机化不可关联，展示形状和会话外围仍可能像指纹一样稳定。

签发者的 header 可能变成永久姓名

草案定义两个不同所有者、不同生命周期的 header。header 由签发者选择，绑定原始签名，也绑定从该签名派生的每一次证明；prover 每次都必须向 verifier 公开。它适合承载共同的应用域、部署域或低基数版本，也因此最容易成为稳定 join key。

若签发者放入随机凭证号、精确到秒的到期时刻、邮箱或任何高熵值，proof 再随机也无济于事。所有展示重复同一 header，验证方根本无需分析密码学结构。草案据此要求 header 采用低熵值，并由足够大的人群共享。

“低熵”不是字段名字的固有属性。国家代码在全球计划中可能覆盖数百万人，在小型外交项目里可能只剩两人；软件版本在上线第一周很常见，一年后却可能只属于未升级设备；部署代号单独很宽，和地区、消息数量、公钥组合后却能指向一个人。

签发者必须保留原始 header 字节、生成规则、预期与实际群体大小、适用公钥和禁止个别例外的政策。持有人不能改写签名绑定的 header，因此风险权力也不能推给持有人。只审查 proof value 等于专门避开了签发者最能制造关联的字段。

presentation header 可以证明新鲜，却不能自动证明正确上下文

presentation_header 由 prover 为单次证明选择，可以装入 verifier 提供的 nonce、audience、domain、有效期或待签消息。验证成功说明该值与证明绑定，适合防止把旧 proof 原样重放。

然而，一个看起来随机的字符串不天然拥有“新鲜”语义。验证方还要证明谁生成 nonce、它属于哪个会话与受众、有效多久、是否已使用、跨域出现时如何处理。非交互模式则需要另一套唯一性判断。把 A 渠道的 nonce 搬到 B 渠道，可能仍然唯一，却绑定了错误交易。

隐私边界同样明确：高熵 presentation header 若每次新建且不含身份数据，可以是合理设计；复用就会成为稳定句柄；装入账户号、精确位置或设备 build，即便永不复用，也可能直接识别人。

运行回执应记录 nonce 来源、创建时间、受众、会话、过期和 consumed 状态。系统不能只保存一个“nonce 合格”布尔值而丢掉审计事实，也不能以审计为名永久保留所有 challenge。防重放与数据最小化是两个控制面。

隐藏值之外，消息形状仍在说话

BBS 隐藏未披露的消息值，却不会隐藏所有结构。proof 长度加公开列表可以推断签名消息总数，公开索引直接暴露字段在 schema 中的位置。稀有数量、顺序或组合足以标出凭证系列甚至小群体。

假设普通员工凭证含五项，承包商含九项，受保护证人项目含十三项。无需恢复任何隐藏文本，verifier 已经完成分类。若只有一个群体同时公开索引 2 和 11，多个 verifier 对日志做交集后，匿名集会更小。

草案建议在可行时统一 padding 与排序。它们不是格式美化，而是人口设计。证据包应包含 schema 版本、总槽位分布、padding 规则、索引图，以及对可选字段是否制造“一人形状”的测试。

padding 也并非免费：proof 变大，实现更复杂，罕见 padding 策略本身还会成为指纹。因此领导层需要先写清“哪些人必须彼此不可区分”，再根据真实输出测量最小群体，而不是机械要求所有项目填满同一长度。

公钥可以在证明生成前就把人群切碎

每份 proof 都在签发公钥下验证。若一个 key 只服务一个人或一个很小群体，所有 proof 都会暴露该群体，尽管任意两份 proof value 无法证明来自同一签名。

分片可能源于正常运营：地区按不同时间轮换、canary 只覆盖二十人、事故响应临时隔离一组账户。也可能源于恶意差异视图：签发者对特定持有人发布一把特殊 key，形成看不见的标签。

所以回执不能只写“公钥有效”。它需要 key bytes 与标识、发布通道、启停时间、设计群体、实际签发人数与一致性证据。草案提到的 key-consistency 机制是一条路径，核心义务则是证明 holder 与 verifier 没有被选择性地放进不同 key view。

一把全球 key 可以扩大匿名集，也会扩大泄露半径并增加轮换难度；分层 key 改善故障隔离，却缩小隐私群体。不存在通用答案，只有明确的取舍与可测的实际分布。

选择性披露不等于匿名披露

姓名、政府号码、邮箱和手机号都可能是合法签名字段，也可能被 holder 主动公开。相同高熵值出现两次，展示就直接关联；职业、精确生日与小城镇等普通字段的稀有组合也能完成同样工作。

BBS 证明公开值的真实性与完整性，不决定 verifier 是否真的需要它。请求目的、比例、保留期和替代证明属于应用政策。一个只需确认“年满十八岁”的服务若索取准确生日，不会违反 BBS 算法，却会消耗掉选择性披露的隐私收益。

区间证明或集合成员证明可以进一步减少披露，但它们是额外构造，带来自己的参数、实现与证据。基础 BBS 不会自动把年龄变成阈值，也不会因为撤销标识被隐藏就自动证明未撤销。

随机数是保密边界的一部分

ProofGen 需要多组相互独立、每次唯一且近似均匀的随机标量。复用、可预测或存在已知关系时，攻击者可能恢复未公开消息或隐藏签名。API 仍可能吐出语法正确的 proof，而隐私性质早已失效。

草案还描述更隐蔽的出站通道：攻击者操纵随机输出中的少量位，把敏感信息编码进看似正常的证明。对高敏系统，一种缓解是使用以唯一均匀 seed 初始化的确定性生成器，限制可操纵比特；它并不消除高质量 entropy 与 seed custody 的需要。

生产证据必须说明 RNG 和库构建、seed 路径、健康检查、进程 fork、虚拟机快照恢复、失败处理与重试状态。uses system RNG 是设计说明，不是某次 proof 的运行回执。

实现还必须分别证明公钥反序列化、子群检查、domain separation、常数时间曲线操作与消息到标量的共同预处理。固定向量通过，完全可能与跳过子群检查或因语言区域设置导致不同字符串规范化同时发生。

不要从相邻草案借来不存在的能力

Blind BBS 是单独扩展：它允许签发者在不知道 holder 某些消息的情况下，对 commitment 中的消息签名。基础 BBS 的选择性披露只在展示时对 verifier 隐藏消息，不能证明签发阶段对 issuer 也隐藏。

BBS per Verifier Linkability 也是单独扩展：它引入与 context 绑定的 pseudonym，使同一 verifier 可以识别重复展示，同时不同 context 保持不可关联。基础 BBS 不会因为 holder 多次生成 proof 就给 verifier 一个稳定假名。

W3C bbs-2023 则是 Verifiable Credentials 的应用 profile，规定 mandatory/selective pointers、数据转换，以及可选 holder binding 与 pseudonym。采购清单必须分别写出草案版本、ciphersuite、接口、扩展和 profile。“支持 BBS”不足以证明上述任何一项已经启用。

量子风险把真实性和隐藏性分成两条时间线

BBS 的签名真实性依赖离散对数困难，草案明确说它不是 post-quantum secure。密码学相关量子计算机可以从公钥恢复签名 secret，伪造任意消息的签名并生成可验证 proof。

草案对已生成 proof 的保密性作出不同判断：未披露消息与隐藏签名的零知识隐藏属于信息论性质，即使攻击者拥有无限计算能力和签名 secret，也不能从 proof 值恢复它们。这是 proof 的 everlasting privacy，不是整个凭证系统的“量子安全”标签。

迁移因此要分两只钟。真实性必须在决策与档案寿命进入量子风险窗口前更换；既有 proof transcript 的隐藏性可能保留，但公开值、header、IP、设备标识和 verifier 日志不会随换 key 自动消失。

用完整互动建立回执

最低回执集应分别保存：文档版本与 ciphersuite；issuer key 来源；key view 一致性；签发是否 blind；原始 header 与群体；schema 数量、顺序和 padding；公开值与索引；presentation header、nonce 来源、受众和 freshness；proof 与验证结果；RNG 证据；解析、子群和 domain-separation 检查；设备与网络元数据；撤销或状态；政策输入；授权；动作与效果；保留期；量子迁移状态。

这些记录不必由一个中央机构控制。issuer 负责 key 与 header，wallet 负责披露和 ProofGen，verifier 负责 challenge 与验证，业务 owner 负责充分性和授权，安全工程负责实现保证，隐私治理负责目的和保留。它们通过受限交易标识与时间关联，而不是塞进一个 verified=true。

这正是 Lu Heng 的最小初始规范原则：公共密码层只约定独立实现必须共同理解的部分，本地权威仍要为自己控制的 key、元数据和后果负责。现实层纪律阻止零知识证明借走授权决定的权力；运行代码优先要求检查真正加载的 key view、schema、header、RNG、二进制和日志路径。

BBS 的承诺并不弱。相反，它强大且边界清楚。真正危险的是组织把 proof 的性质扩写成整个系统的性质，却没有为扩写部分补上任何证据。

来源