Universal Anonymous Signatures: bridging past, present, and future of anonymous authentication - IOHK Blog
最近，我们的论文《匿名签名的基础：正式定义、简化要求和基于一般假设的构建》被 FC’24（2024 年版金融密码学会议）接受。 本文介绍了通用匿名签名（UAS）。
我们对此感到非常兴奋，因为除了桥接匿名身份验证领域的几个子领域之外，UAS 还为我们认为可能成为自我主权身份未来（一部分）的道路奠定了基础，并且我们肯定会推动在身份验证领域内进行整合。 阿塔拉供奉。
但介绍已经足够了。 无人机系统是什么？
一点历史
1985 年，David Chaum 首次想到了一种加密凭证，人们可以使用这种凭证而不会实际泄露自己的身份，但仍然可以向服务提供商保证他们正在与合法人交谈。 人们提出了许多变体，通常利用经过证明的属性的概念——凭证所有者可以有选择地选择是否透露这些属性。 这称为匿名凭证 (AC) 方案。
1991年，Chaum和van Heyst提出了群组签名（GS），它允许持有成员凭证的群组成员做类似于AC的事情。 这些成员凭证通常没有属性，但 GS 方案生成的签名可以由可信实体处理，该实体可以提取匿名签名者的标识符。
AC 和 GS 方案都依赖于颁发身份验证或签名所需凭据的机构。 这样的实体在 2001 年被删除，当时 Rivest、Shamir 和 Tauman 提出了环签名 (RS) 方案，该方案可以被视为一种无法去匿名化且不需要发行者的群签名。
因此，在不到 16 年的时间里，密码学界发现自己可以通过三种不同但相似的方式来允许用户匿名验证自己的身份。 自 2001 年以来，人们提出了更多的变体，有时会找到中间点。 其中包括允许链接签名的 RS 方案，或只有用户可以链接自己签名的组签名。
无人机解决什么问题？
实际上，AC、GS 和 RS 方案（及其许多变体）不仅有一些共同点。 它们存在的理由是密切相关的。 允许用户进行匿名身份验证，同时仍然让服务提供商对他们可以提取的信息进行某种控制。 从理论的角度来看，这反映在安全模型通常看起来非常相似的事实上。 例如，人们总是需要考虑匿名属性，它捕获可以从签名中了解到的信息。 关于不可伪造性属性，它具有可追溯性和不可框架性变体，准确地说明了验证者（服务提供商）和用户分别可以期望什么样的不可伪造性保证。 此外，还有一些方法可以从非常相似的构建块构建这些方案。
然而，由于某种原因，到目前为止，AC、GS、RS等都已独立研究。 此外，即使在某些具体分支（例如 GS）内，存在诸如“群签名基础”工作线之类的参考安全模型，但情况并非总是如此。 即使有参考模型，这些安全模型通常也与具体的隐私与实用性权衡相关。
一个实际的例子
假设您有一个 AC 方案，允许您在凭证呈现时有选择地披露任意属性。 但是，您希望在还需要链接来自同一用户的演示文稿的情况下重用它（也许您想用一些保真度奖励该用户，或者也许该用户正在向您发送垃圾邮件，而您想阻止他们！） 。 简而言之，您想要添加某种类型的可审核性。 这种先验的简单改变需要新的安全模型！ 当然，如果你知道怎么做，你可以扩展以前的结构，如果幸运的话，你之前的结构也可以轻松更新。 但如果您曾经实施过此类事情，您就会知道这通常是不可企及的。
匿名身份验证中隐私与实用权衡的动态模型
针对具体的隐私与实用权衡要求一种安全模型显然并不理想。 这正是我们想要解决的问题，因为这种相似但不同的要求在实践中很常见。 因此，我们所做的就是提出 UAS，这是一种可以随时进行调整的通用安全模型，以便您可以根据您的用例的需求进行调整 - 就所需的隐私与实用性权衡而言 。 更详细地说，仔细观察，人们可能希望在三点上采用这种类型的匿名身份验证方案：
颁发时：当用户请求凭证时，他们可能需要提供之前获得的满足属性 A 或 B 的背书凭证，或者甚至可能不需要提供根本没有凭据！
签名时：当用户想要生成匿名签名（或出示其凭证）时，验证者可能需要了解凭证属性是否满足特定标准。
审核时：审核员可能要求在创建签名后提取一些信息。 也可能根本没有审计员！
我们通过这三个点上的“功能占位符”（程序员可以将其视为抽象函数）来捕获这些不同的权衡，这些占位符嵌入在基本上遵循上述匿名性不可伪造性模板的安全框架中。 对于工程师来说最重要的是，鉴于我们的模型中已证明安全的结构，他们只需要指定每个步骤所需的具体功能 - 发行、签名和审核 - 就是这样！ 安全源于主体建筑的安全。
这与 GS、AC 或 RS 有什么关系？
公平的问题！ 我们想要确定我们声称的通用模型实际上是通用的。 那么，我们是如何做到的呢？ 好吧，我们证明了，通过在发行、签署和审核时提供具体功能，我们的通用结构可以表现为 GS、AC 或 RS 方案。 更具体地说，我们证明我们的构造的这种变体是安全的 GS、AC 或 RS 方案（在他们众所周知的安全模型下）。
当然，论文是有限的，所以我们只证明基本的 GS、AC 和 RS 可以从 UAS 的通用结构中构建出来。 我们还草拟了更高级变体的证明，例如具有消息相关打开的 GS、多模式私有签名和可撤销匿名凭证。 很容易想象许多其他变体。 例如，具有扩展审计功能的匿名凭证，甚至是具有隐私与实用性权衡的匿名签名方案，而学术领域尚未考虑到这一点。
接下来是什么（或可能是什么）？
您可能注意到的第一件事是，这是一项相当理论化的工作。 虽然纸面上一切看起来都很好，但编码时可能会出现问题。 一个合理的担忧是，如果拥有一个可以适应许多不同用例的结构，那么在效率方面会受到什么样的惩罚。 这是一个非常合理的担忧。 毕竟，为单一目的而设计的方案往往会更有效。 为了更好地评估这一点，我们正在开发一个原型。 最初，我们希望有一个可以抽象出内部细节的库，让开发人员专注于他们感兴趣的具体功能占位符的实现。然后，从我们（目前唯一的）通用构造中测试结果的效率如何 。 这对于某些应用程序来说可能已经足够了，但不是全部。
论文给出了基于 BBS+、加密和通用（非交互式）ZK 证明的通用构造。 如果我们想要实现的是选择性披露类型的声明，那么这肯定是可以的，但例如，如果我们想证明更具表现力的谓词，这可能不适合。 因此，下一步是考虑更适合更具表现力的要求的替代通用结构。
另外，从理论的角度来看，我们对未来有很多想法。 例如，允许发行人和审计师改变其职能。 目前，虽然许多发行人或审计师可以共存，但他们每个人都致力于履行一项职能。 或者使模型适应完全动态的设置等等。
我们计划如何将 UAS 集成到 Atala 中？
如前所述，我们正在致力于基于 BBS+、加密 (ElGamal) 和 ZK 证明（基本 Sigma 协议）的通用构造的实现。 这将是我们的起点，使我们能够在 Atala 提供的 SSI 堆栈中测试这项新技术。 通过将 UAS 集成到 Atala 的开放企业代理堆栈中，我们将能够利用 Atala 包含的所有工具，并开始测试 UAS 在生产就绪环境中的行为方式（使用特定于 SSI 的代理、节点、通信协议等），并且 使其适应市场和工程团队的需求。
请密切关注即将推出的更新！