有效的數字簽名機制是否一定會透露簽名方的身份？在不知道簽名方身份的前提下，如何驗證數字簽名的有效性？匿名的簽名方案如何支持監管仲裁有效介入？其背後的群簽名和環簽名技術之間有何區別？

在現代商業活動中，簽名機制的字面解釋是：為表示同意、認可、承擔責任或義務而寫下名字，同時驗證方可以查驗字蹟的真實性，以核實簽名的有效性。這個過程中，驗證方往往可以從“名字”獲知簽名方的身份。在傳統簽名機制中，能夠獲知簽名方的身份，是驗證簽名有效性的必要條件。

這同時也帶來了一個問題：如果參與商業活動的協作方，不願意或者不方便透露自己的身份，那我們還能不能與之簽訂有效的契約呢？

舉個具體的例子，在典型的暗標採購場景中，投標方需要對自己投出的標書進行簽名承諾，確保標書的有效性，並體現自己符合一定的資質。與此同時，招標方、招標平台、其他投標方不能通過簽名識別出該投標方身份，避免出現圍標、串標等潛在不法行為。

解決以上問題的關鍵，在於將數字簽名的可驗證性和簽名方的身份信息解耦，這裡就會用到群簽名和環簽名技術。這兩類技術為何能夠實現這樣反常理的效果？且隨本文一探究竟。

群簽名與環簽名的匿名性

在實現簽名方身份隱匿上，群簽名和環簽名是最常見的兩類數字簽名技術，其主要效果為簽名的驗證方只能驗證簽名來自於一個群體，但無法準確推斷出簽名具體來自哪一個個體簽名方。

回到之前的暗標採購場景，投標方可以通過群簽名或環簽名對自己的標書進行簽名承諾，招標方和招標平台可以驗證該標書是來自一個具備資質的群體，但無法獲知其身份信息。

一般而言，一個有效的群簽名或環簽名算法，除了上一論提到的密碼學數字簽名的基本特性之外，還具有以下特性：

群體匿名：驗證方只能驗證簽名來自對應的群體，但無法精確定位到個體成員。不可鏈接：對於任意兩個簽名，驗證方無法獲知它們是否來自同一的個體成員。

其基本使用過程如下：

簽名：同一群體中的個體成員使用各自不同的私鑰對契約內容進行簽名。驗簽：驗證方使用該群體的公鑰對簽名進行驗證。

以上過程與經典數字簽名最大的不同在於，儘管簽名時可以使用多個不同私鑰中的任意一個，但驗簽使用的卻是同一個公鑰，以此實現了一定的匿名性。

進一步細分，群簽名有一個群管理員的設定，該管理員可以通過自己的管理員私鑰識別進行簽名的個體成員的身份，而且對於任一個成員，在同一群體內的其他成員不能冒充其進行簽名，從而也使得監管仲裁成為了可能。

相比之下，環簽名不需要引入群管理員，每一個個體都可以自由選擇其他個體，像建立聊天群一樣，自由組建隱匿自身身份的群體。有趣的是，Ron Rivest、Adi Shamir和Yael Tauman Kalai最初提出這一概念的論文標題為《How to leak a secret》，可見環簽名最初的設計用途是用於安全匿名地洩露敏感信息。

在實際業務中，對於有監管需求或者上下級從屬結構比較穩定的場景，可以優先使用群簽名，邀請主管部門擔任管理員的角色，為所轄範圍內的個體成員簽發對應的簽名私鑰，在必要時可以介入進行監管調解。

對於組織結構比較靈活，且對匿名性要求比較高、不希望引入管理員的場景，環簽名可能是更好的選擇，個體成員可以自由選擇群體中成員，並對外將自己展現成該群體的一員。

值得注意的是，群簽名和環簽名實現的匿名性並不是無條件的。使用時具體需要注意哪些事項，我們在以下兩個小節中具體展開。

群簽名的使用注意事項

一個典型的群簽名算法會涉及三類角色，其核心使用流程如下：

群管理員· 負責初始化群設置· 生成群管理私鑰並由自己保存· 基於群管理私鑰，生成群公鑰並公開· 與新的群成員協商，為其生成或分派成員的簽名私鑰·使用自己的群管理私鑰對現有的簽名進行身份解密群成員· 使用自己的簽名私鑰對契約內容進行群簽名驗證方· 使用當前的群公鑰，對收到的群簽名進行驗證

可以注意到，群簽名諸多操作過程中的核心輸入——群公鑰是所有群成員共用的，也就是說，當群成員關係發生變更時，當前的群公鑰可能會因此作廢。

正如上一論所提到的，可信地作廢一個舊公鑰並分發一個新公鑰，是一個相當有挑戰的過程，現有階段的主流解決方案不得不依賴中心化的公鑰基礎設施，即便如此也不能保證撤銷的公鑰證書能夠及時地反映到公鑰黑名單列表中。

在現代商業環境中，動態的業務往來比比皆是，如果每一次群成員關係發生變更之後，都需要更新群公鑰，那麼群簽名的實用性將大打折扣。

目前經典的群簽名算法，對這一挑戰提供了部分解決方案，以經典的BBS04群簽名算法為例，增加新的群成員並不需要更新群公鑰，群管理員可以使用群管理私鑰增加任意多個群成員。

但BBS04核心算法並沒有提供對刪除群成員的直接支持，難以有效地支持被刪除群成員簽名私鑰的撤銷操作。為此，原論文和後續論文提出了一系列協議層面的擴展，來緩解這一問題，常見思路有：

定期公開一個私鑰的撤銷列表，其中可能包含所有被刪除群成員的簽名私鑰或相關信息，並同時更新當前的群公鑰，使得被撤銷的群成員簽名私鑰無法生成與更新後群公鑰匹配的有效簽名。當前的群公鑰保持不變，但依舊定期或實時公開一個私鑰的撤銷列表，有效的群成員可以通過其他手段，如零知識證明，證明自己的簽名私鑰不在已公佈的撤銷列表中。

無論哪一類擴展，都引入了撤銷列表的設計，在實際業務中，如果需要支持高頻的群成員關係變更，如何保證其實時性和完整性都是不小的挑戰。

對於現實業務系統，通常會傾向於保持當前群公鑰的整體方案，減少密鑰分發過程中帶來的風險。以可信硬件執行環境TEE背後的EPID協議為例，其本質上是一個群簽名，用於核實當前硬件設備是否為已註冊且未被加入黑名單的TEE模塊。硬件廠商和平台服務商可以通過提供一個遠程硬件認證服務，實時對TEE模塊的有效性進行驗證，控制群成員撤銷（即TEE硬件被破解）的相關風險。

環簽名的使用注意事項

一個典型的環簽名算法會涉及兩類角色，其核心使用流程如下：

環成員· 初始化自己的簽名公鑰和私鑰對，並公開廣播自己的公鑰· 監聽廣播，收集其他潛在環成員的公鑰· 自主選擇一組環成員，將自己的公鑰混入其公鑰列表中，生成本次環公鑰· 結合環公鑰和自己的簽名私鑰對契約內容進行環簽名· 公佈環簽名結果和對應的環公鑰驗證方· 使用環簽名對應的環公鑰，對收到的環簽名進行驗證，驗證結果為簽名方屬於環成員之一

很多情況下，環簽名算法每一次使用都會公佈新的環公鑰（附加在簽名數據中），所以不涉及群簽名中群成員關係變更後需要更新群公鑰的問題。

但這一特點作為設計上的取捨，也影響了環簽名的匿名性。環簽名提供匿名性的強度，取決於收集到的其他潛在環成員公鑰的數量和質量。環簽名的驗證方可以通過環公鑰中的公鑰列表，相對容易地推斷出簽名方的身份必然為其中之一。

如果可以通過PKI等公鑰服務獲得當前環成員公鑰對應的身份，那更容易排除可能性低的簽名方，從而進一步削弱環簽名的匿名性。相比之下，群簽名提供的匿名性，除了群管理員之外，驗證方無法準確地獲知當前群中到底有多少個成員，以及這些成員是誰。

所以環簽名在使用時，需要引入足夠數量不記名的環成員公鑰，保證其匿名性得到落實。以近年來比較知名的環簽名應用CryptoNote為例，在其使用過程中，環成員會產生一定數量的假賬戶，並為此分別生成隨機公鑰，以此來滿足環成員數量和質量的要求，達成難以追溯的匿名性。

對於涉計n個環成員的環簽名，其完整簽名數據的大小一般至少為O(n)，作為去除群管理員的設計取捨，環簽名的數據大小和計算複雜度通常會比群簽名高。所以，如果不介意群管理員的設定，群簽名通常是更優選擇。

儘管核心設計目標都是隱匿簽名方的身份，群簽名和環簽名在設計上各有取捨，一般情況下，可以參照下圖進行基本的技術選型。

正是：身份涉密契約難簽訂，群環簽名可隱亦可現！

數字化經濟中，隱匿協作方的身份，對於開展涉及敏感隱私數據的高價值業務，或者需要基於匿名性保證流程公正有效的公共服務等，是不可或缺的前提。基於是否需要監管介入，以及協作方關係是否穩定等具體需求，酌情選用群簽名或者環簽名算法，可以在協作方不透露自己身份的前提下，實現有效契約的簽訂。

目前，群簽名和環簽名主要應用在投票、競標、競拍等場景，以保障參與者身份隱私，在聯盟鏈治理中也有廣泛應用。以微眾銀行牽頭聯合金鍊盟開源工作組開源的FISCO BCOS聯盟鏈底層平台為例，平台通過集成群、環簽名方案，為用戶提供能夠保證身份匿名性的工具。應用詳情可參考《FISCO BCOS隱私特性：群/環簽名技術實現》。

根據業務需求，群簽名或者環簽名的基礎算法可以做進一步擴展，例如，增加門限特性，使得只有在多數協作方同意的前提下才能完成簽名等。

門限特性也是密碼學數字簽名高頻使用的高級特性之一，對保障多方協作中公平、對等的合作關係至關重要，技術上究竟如何實現，欲知詳情，敬請關注下文分解。