数字化契约如何守护？解析群/环签名的妙用

有效的数字签名机制是否一定会透露签名方的身份？在不知道签名方身份的前提下，如何验证数字签名的有效性？匿名的签名方案如何支持监管仲裁有效介入？其背后的群签名和环签名技术之间有何区别？

在现代商业活动中，签名机制的字面解释是：为表示同意、认可、承担责任或义务而写下名字，同时验证方可以查验字迹的真实性，以核实签名的有效性。这个过程中，验证方往往可以从“名字”获知签名方的身份。在传统签名机制中，能够获知签名方的身份，是验证签名有效性的必要条件。

这同时也带来了一个问题：如果参与商业活动的协作方，不愿意或者不方便透露自己的身份，那我们还能不能与之签订有效的契约呢？

举个具体的例子，在典型的暗标采购场景中，投标方需要对自己投出的标书进行签名承诺，确保标书的有效性，并体现自己符合一定的资质。与此同时，招标方、招标平台、其他投标方不能通过签名识别出该投标方身份，避免出现围标、串标等潜在不法行为。

解决以上问题的关键，在于将数字签名的可验证性和签名方的身份信息解耦，这里就会用到群签名和环签名技术。这两类技术为何能够实现这样反常理的效果？且随本文一探究竟。

群签名与环签名的匿名性

在实现签名方身份隐匿上，群签名和环签名是最常见的两类数字签名技术，其主要效果为签名的验证方只能验证签名来自于一个群体，但无法准确推断出签名具体来自哪一个个体签名方。

回到之前的暗标采购场景，投标方可以通过群签名或环签名对自己的标书进行签名承诺，招标方和招标平台可以验证该标书是来自一个具备资质的群体，但无法获知其身份信息。

一般而言，一个有效的群签名或环签名算法，除了上一论提到的密码学数字签名的基本特性之外，还具有以下特性：

群体匿名：验证方只能验证签名来自对应的群体，但无法精确定位到个体成员。

不可链接：对于任意两个签名，验证方无法获知它们是否来自同一的个体成员。

其基本使用过程如下：

签名：同一群体中的个体成员使用各自不同的私钥对契约内容进行签名。

验签：验证方使用该群体的公钥对签名进行验证。

以上过程与经典数字签名最大的不同在于，尽管签名时可以使用多个不同私钥中的任意一个，但验签使用的却是同一个公钥，以此实现了一定的匿名性。

进一步细分，群签名有一个群管理员的设定，该管理员可以通过自己的管理员私钥识别进行签名的个体成员的身份，而且对于任一个成员，在同一群体内的其他成员不能冒充其进行签名，从而也使得监管仲裁成为了可能。

相比之下，环签名不需要引入群管理员，每一个个体都可以自由选择其他个体，像建立聊天群一样，自由组建隐匿自身身份的群体。有趣的是，Ron Rivest、Adi Shamir和Yael Tauman Kalai最初提出这一概念的论文标题为《How to leak a secret》，可见环签名最初的设计用途是用于安全匿名地泄露敏感信息。

在实际业务中，对于有监管需求或者上下级从属结构比较稳定的场景，可以优先使用群签名，邀请主管部门担任管理员的角色，为所辖范围内的个体成员签发对应的签名私钥，在必要时可以介入进行监管调解。

对于组织结构比较灵活，且对匿名性要求比较高、不希望引入管理员的场景，环签名可能是更好的选择，个体成员可以自由选择群体中成员，并对外将自己展现成该群体的一员。

值得注意的是，群签名和环签名实现的匿名性并不是无条件的。使用时具体需要注意哪些事项，我们在以下两个小节中具体展开。

群签名的使用注意事项

一个典型的群签名算法会涉及三类角色，其核心使用流程如下：

群管理员

· 负责初始化群设置

· 生成群管理私钥并由自己保存

· 基于群管理私钥，生成群公钥并公开

· 与新的群成员协商，为其生成或分派成员的签名私钥

· 使用自己的群管理私钥对现有的签名进行身份解密

群成员

· 使用自己的签名私钥对契约内容进行群签名

验证方

· 使用当前的群公钥，对收到的群签名进行验证

可以注意到，群签名诸多操作过程中的核心输入——群公钥是所有群成员共用的，也就是说，当群成员关系发生变更时，当前的群公钥可能会因此作废。

正如上一论所提到的，可信地作废一个旧公钥并分发一个新公钥，是一个相当有挑战的过程，现有阶段的主流解决方案不得不依赖中心化的公钥基础设施，即便如此也不能保证撤销的公钥证书能够及时地反映到公钥黑名单列表中。

在现代商业环境中，动态的业务往来比比皆是，如果每一次群成员关系发生变更之后，都需要更新群公钥，那么群签名的实用性将大打折扣。

目前经典的群签名算法，对这一挑战提供了部分解决方案，以经典的BBS04群签名算法为例，增加新的群成员并不需要更新群公钥，群管理员可以使用群管理私钥增加任意多个群成员。

但BBS04核心算法并没有提供对删除群成员的直接支持，难以有效地支持被删除群成员签名私钥的撤销操作。为此，原论文和后续论文提出了一系列协议层面的扩展，来缓解这一问题，常见思路有：

定期公开一个私钥的撤销列表，其中可能包含所有被删除群成员的签名私钥或相关信息，并同时更新当前的群公钥，使得被撤销的群成员签名私钥无法生成与更新后群公钥匹配的有效签名。

当前的群公钥保持不变，但依旧定期或实时公开一个私钥的撤销列表，有效的群成员可以通过其他手段，如零知识证明，证明自己的签名私钥不在已公布的撤销列表中。

无论哪一类扩展，都引入了撤销列表的设计，在实际业务中，如果需要支持高频的群成员关系变更，如何保证其实时性和完整性都是不小的挑战。

对于现实业务系统，通常会倾向于保持当前群公钥的整体方案，减少密钥分发过程中带来的风险。以可信硬件执行环境TEE（参见第14论）背后的EPID协议为例，其本质上是一个群签名，用于核实当前硬件设备是否为已注册且未被加入黑名单的TEE模块。硬件厂商和平台服务商可以通过提供一个远程硬件认证服务，实时对TEE模块的有效性进行验证，控制群成员撤销（即TEE硬件被破解）的相关风险。

环签名的使用注意事项

一个典型的环签名算法会涉及两类角色，其核心使用流程如下：

环成员

· 初始化自己的签名公钥和私钥对，并公开广播自己的公钥

· 监听广播，收集其他潜在环成员的公钥

· 自主选择一组环成员，将自己的公钥混入其公钥列表中，生成本次环公钥

· 结合环公钥和自己的签名私钥对契约内容进行环签名

· 公布环签名结果和对应的环公钥

验证方

· 使用环签名对应的环公钥，对收到的环签名进行验证，验证结果为签名方属于环成员之一

很多情况下，环签名算法每一次使用都会公布新的环公钥（附加在签名数据中），所以不涉及群签名中群成员关系变更后需要更新群公钥的问题。

但这一特点作为设计上的取舍，也影响了环签名的匿名性。环签名提供匿名性的强度，取决于收集到的其他潜在环成员公钥的数量和质量。环签名的验证方可以通过环公钥中的公钥列表，相对容易地推断出签名方的身份必然为其中之一。

如果可以通过PKI等公钥服务获得当前环成员公钥对应的身份，那更容易排除可能性低的签名方，从而进一步削弱环签名的匿名性。相比之下，群签名提供的匿名性，除了群管理员之外，验证方无法准确地获知当前群中到底有多少个成员，以及这些成员是谁。

所以环签名在使用时，需要引入足够数量不记名的环成员公钥，保证其匿名性得到落实。以近年来比较知名的环签名应用CryptoNote为例，在其使用过程中，环成员会产生一定数量的假账户，并为此分别生成随机公钥，以此来满足环成员数量和质量的要求，达成难以追溯的匿名性。

对于涉计n个环成员的环签名，其完整签名数据的大小一般至少为O(n)，作为去除群管理员的设计取舍，环签名的数据大小和计算复杂度通常会比群签名高。所以，如果不介意群管理员的设定，群签名通常是更优选择。

尽管核心设计目标都是隐匿签名方的身份，群签名和环签名在设计上各有取舍，一般情况下，可以参照下图进行基本的技术选型。

正是：身份涉密契约难签订，群环签名可隐亦可现！

数字化经济中，隐匿协作方的身份，对于开展涉及敏感隐私数据的高价值业务，或者需要基于匿名性保证流程公正有效的公共服务等，是不可或缺的前提。基于是否需要监管介入，以及协作方关系是否稳定等具体需求，酌情选用群签名或者环签名算法，可以在协作方不透露自己身份的前提下，实现有效契约的签订。

目前，群签名和环签名主要应用在投票、竞标、竞拍等场景，以保障参与者身份隐私，在联盟链治理中也有广泛应用。以微众银行牵头联合金链盟开源工作组开源的FISCO BCOS联盟链底层平台为例，平台通过集成群、环签名方案，为用户提供能够保证身份匿名性的工具。应用详情可参考《FISCO BCOS隐私特性：群/环签名技术实现》。

根据业务需求，群签名或者环签名的基础算法可以做进一步扩展，例如，增加门限特性，使得只有在多数协作方同意的前提下才能完成签名等。