论文分享 | 基于区块链和签名的去中心化跨域认证方案
身份认证是信息系统安全的第一道防线，常见的身份认证依赖中心服务器，采用密码、多因素、或证书等方式。分享一篇发表于 2025 年 CSI 期刊的论文，它基于区块链和签名算法，设计了一种使用去中心化身份的跨域身份认证方案。
论文摘要
论文提出了一种基于区块链和签名技术的跨域身份认证方案，旨在解决现有跨域认证中存在的隐私保护不足和用户体验不佳的问题。传统方法依赖于公钥基础设施（Public Key Infrastructure, PKI），存在中心化、隐私漏洞和可扩展性限制。而论文提出的方案利用去中心化身份（Decentralized Identity, DID）技术和可验证凭证（Verifiable Credential, VC），结合区块链的不可篡改和分布式特性，实现了用户隐私保护和数据安全。
1 背景介绍
跨域认证是验证和授权跨不同领域身份的关键过程，广泛应用于云计算和物联网等领域。早期的跨域认证方案依赖于 Kerberos，但其依赖中心服务器，限制了其应用范围。随后，身份基密码学（Identity-Based Cryptography, IBC）被引入以简化证书管理，但存在密钥托管问题。目前，公钥基础设施（Public Key Infrastructure, PKI）是跨域认证的主流技术，这种方案依赖于证书颁发机构（Certificate Authority, CA）的信任，存在隐私保护不足、中心化管理等问题，难以满足用户隐私保护和数据安全的需求。随着区块链技术的兴起，研究人员提出了多种基于区块链和 PKI 的跨域认证方案，利用区块链的不可篡改、透明、安全和可靠特性，解决了传统 PKI 方案的中心化问题。
目前，用户在访问不同网络服务时，缺乏统一的身份认证机制，导致用户需要在多个域中维护多个账户，这不仅增加了用户负担，还给跨域认证带来了显著的不便，去中心化身份（Decentralized Identity, DID）技术应运而生。DID 利用区块链和分布式账本技术，赋予用户对其身份数据的自主权，减少了对中心化权威的依赖。可验证凭证（Verifiable Credential, VC）作为 DID 的扩展，允许用户灵活地控制和分享身份信息，增强了隐私保护并降低了数据暴露的风险。尽管 DID 和 VC 技术通过区块链和分布式账本赋予了用户对身份数据的自主权，增强了隐私保护并降低了数据暴露的风险，但现有基于这些技术的跨域认证方案在用户体验和隐私保护方面仍存在不足，亟需进一步优化。
2 基础知识
2.1 去中心化身份（Decentralized Identity）
DID 是一类新型的可验证标识符，旨在识别分布式账本中的特定实体。这些标识符由万维网联盟（W3C）通过 DID 规范进行标准化，为去中心化标识符生态系统奠定了基础。VC 是包含有关凭证持有者属性的声明的加密数字证书。持有者完全控制这些凭证，可以将它们存储在数字钱包中，使 VC 成为 DID 系统的实际应用层。截止 2025 年 5 月，W3C 发布的最新标准分别为DID v1.1 和 VC Data Model v2.0，示例如下：
- A simple DID document
{"@context": "https://www.w3.org/ns/did/v1.1","id": "did:example:123456789abcdefghi","authentication": [{// used to authenticate as did:...fghi"id": "did:example:123456789abcdefghi#keys-1","type": "Multikey","controller": "did:example:123456789abcdefghi","publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"}]
}
- A template for creating prototype verifiable credentials
{"@context": ["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type": ["VerifiableCredential", "MyPrototypeCredential"],"credentialSubject": {"mySubjectProperty": "mySubjectValue"}
}
W3C 可验证声明工作组定义了凭证交换过程中的三个主要角色：发行者、持有者和验证者。发行者是创建 VC 的实体；持有者通常是用户，是凭证的保管人；验证者是通过用户的 DID 和 VC 验证用户身份的服务提供者。这三个角色之间的关系通常被称为信任三角形，只有当验证者信任发行者时，VC 才能传递信任。
2.2 门限签名（Threshold Signature）
门限签名是一种集体形式的数字签名，创建有效的签名需要至少达到预定义阈值的最少数量的组成员参与。基于区块链的门限签名系统抽象如下：
-
K e y G e n ( 1 λ , n , t ) \mathsf{KeyGen}(1^\lambda,n,t) KeyGen(1λ,n,t)：给定安全参数 1 λ 1^\lambda 1λ，成员数量 n n n 和阈值 t t t，密钥生成算法输出用于验证门限签名的公钥 m p k mpk mpk 以及每个成员用于创建部分签名的私钥 p r i K = ( p r i K 1 , . . . , p r i K n ) priK=(priK_1,...,priK_n) priK=(priK1,...,priKn)。
-
S i g n ( p r i K i , m ) \mathsf{Sign}(priK_i,m) Sign(priKi,m)：签名算法生成部分门限签名，它接受消息 m m m 和成员的私钥 p r i K i priK_i priKi，产生部分签名 s i s_i si。
-
C o m b i n ( s 1 , . . . , s t ) \mathsf{Combin}(s_1,...,s_t) Combin(s1,...,st)：组合算法合成门限签名。成员将满足阈值 t t t 的有效部分签名 s i s_i si 组合起来，产生最终签名 s s s。
-
V e r i f y ( m p k , m , s ) \mathsf{Verify}(mpk,m,s) Verify(mpk,m,s)：验证算法输入消息 m m m，公钥 m p k mpk mpk，检查门限签名 s s s 的有效性。如果验证成功输出
success，否则输出failure。
2.3 代理签名（Proxy Signature）
代理签名也称为委托签名，原始签名者将其签名能力委托给代理签名者，代理签名者然后代表原始签名者生成有效的签名。典型的代理签名包括以下六个组成部分：
-
K e y G e n ( 1 λ ) \mathsf{KeyGen}(1^\lambda) KeyGen(1λ)：密钥生成算法生成用户的公私钥对。它包括原始签名者的公私钥对 ( p u b K o , p r i K o ) (pubK_o,priK_o) (pubKo,priKo) 和代理签名者的公私钥对 ( p u b K p , p r i K p ) (pubK_p,priK_p) (pubKp,priKp) 。
-
D e l e g a t e ( p u b K o , p r i K o , w ) \mathsf{Delegate}(pubK_o,priK_o,w) Delegate(pubKo,priKo,w)：代理授权算法接受原始签名者的公私钥对和授权文件 w w w，输出授权信息 δ \delta δ。授权文件包括原始签名者和代理签名者的身份信息、授权关系描述、允许的消息范围和授权期限。
-
D e l e G e n ( δ , p r i K p ) \mathsf{DeleGen}(\delta,priK_p) DeleGen(δ,priKp)：在代理密钥生成算法中，输入授权信息 δ \delta δ 和代理签名者的私钥 p r i K p priK_p priKp，产生代理签名私钥 p r i K o p priK_{op} priKop。
-
P r o x y S i g n ( p r i K o p , w , m ) \mathsf{ProxySign}(priK_{op},w,m) ProxySign(priKop,w,m)：代理签名算法需要消息 m m m、授权文件 w w w 和代理签名私钥 p r i K o p priK_{op} priKop ，生成签名 s s s 以及授权文件 w w w。
-
V e r i f y ( w , m , s ) \mathsf{Verify}(w,m,s) Verify(w,m,s)：该签名验证算法检查签名 s s s 对消息 m m m 和授权文件 w w w 的有效性。如果签名有效，输出
success；否则，输出failure。
3 系统模型
论文提出的跨域认证方案涉及四个关键实体：用户、已注册域、未注册域和区块链。用户在已注册域完成注册后，可申请可验证凭证（VC），并利用该凭证在未注册域进行身份验证。整个认证流程依赖于区块链作为分布式数据库，确保 DID 及相关数据的安全存储与检索。方案分为三个阶段：注册、申请与生成、验证，如图 1 所示。
-
注册过程：
- a. 用户发送注册请求。
- b. 已注册域在其内部数据库中记录用户信息。
- c. 发送注册成功的确认信息。
-
申请和生成过程：
- d. 用户生成一个新的 DID，并请求颁发可验证凭证（VC）。
- e. 注册域在区块链上记录用户的 DID。
- f. 注册域生成相应的 VC 并返回给用户。
- g. 用户本地存储 VC。
-
验证过程：
- h. 用户向未注册域出示 VC。
- i. 未注册域从区块链上检索必要的验证信息。
- j. 根据检索到的信息验证 VC 的完整性和真实性。
- k. 验证成功，用户获得访问权限。
4 方案设计
假设存在 n n n 个域 P = { P 1 , P 2 , … , P n } P=\{P_1,P_2,…,P_n\} P={P1,P2,…,Pn} ，这些域在同一条联盟链上相互联合。这些域在链上经过认证和授权加入该网络，并且彼此之间建立了初始的信任基础。每个域 P i P_i Pi（其中 i = 1 , 2 , … , n i=1,2,…,n i=1,2,…,n）的公钥 p u b K P i pubK_{P_i} pubKPi 存储在链上，每个成员节点拥有其唯一的标识符 D I D P i DID_{P_i} DIDPi，私钥 p r i K P i priK_{P_i} priKPi 由各自节点保密保存。
4.1 DID 的注册
在注册过程中，注册域 P i P_i Pi 为用户 U t U_t Ut 生成一个唯一的账户标识符 U I D t UID_t UIDt ，它也作为该用户在该域内的身份标识。用户将提供与该账户关联的个人信息，以便注册域能够追溯任何违规用户。账户密码由用户自行管理。完成注册后，注册域 P i P_i Pi 将用户账户记录在其本地数据库中，并将 DID 与用户 U t U_t Ut 的账户关联起来。
4.2 VC 的生成
- 定向 VC 的申请
假设用户 U t U_t Ut 来自域 P i P_i Pi，希望访问域 P j P_j Pj （其中 i ≠ j i \neq j i=j）， U t U_t Ut 需要提交某些属性信息以请求注册域 P i P_i Pi 为其签发 VC，具体流程如图 2 所示。
首先，用户生成一个新的 DID d i d d did_d didd 和对应的公私钥对 ( p r i K d , p u b K d ) (priK_d,pubK_d) (priKd,pubKd) 用于定向 VC，并将 d i d d did_d didd 和 p u b K d pubK_d pubKd 提交给域 P i P_i Pi 。然后，域服务器将其存储在本地数据库中，并将 DID 信息写入区块链。DID 信息包括 d i d d did_d didd， p u b K d pubK_d pubKd ， ( d i d d , p u b K d ) p r i K P i (did_d,pubK_d)_{priK_{P_i}} (didd,pubKd)priKPi， p u b K P i pubK_{P_i} pubKPi。存储 DID 及其公钥便于未来的验证需求；对这两部分信息进行签名确保其完整性；为了加快未来的完整性验证速度，还存储了 P i P_i Pi 的公钥。
随后， P i P_i Pi 请求用户提供与 VC 相关的属性列表。用户提供 d i d d did_d didd 和属性列表， P i P_i Pi 根据这些信息生成证书 c e r d cerd cerd，对其进行签名并返回 V C d VC_d VCd，由时间戳 T m T_m Tm 和签名数据 ( T m , V C d ) p r i K P i (T_m,VC_d)_{priK_{P_i}} (Tm,VCd)priKPi 发送给用户。最后，用户安全地将 V C i VC_i VCi 本地存储，可以选择加密。
- 通用 VC 的申请
联盟采用阈值签名机制来签发通用 VC，假设阈值为 t t t。最初，联盟执行 K e y G e n ( 1 λ , t , n ) \mathsf{KeyGen}(1^\lambda,t,n) KeyGen(1λ,t,n) 算法，生成阈值公钥 m p k mpk mpk 和各个成员的私钥 p r i K t = ( p r i K t 1 , . . . , p r i K t n ) priK_t=(priK_{t1},...,priK_{tn}) priKt=(priKt1,...,priKtn)。这里， P i P_i Pi 表示执行操作的域，而 P j P_j Pj 表示与 P i P_i Pi 交互的其他域，整个流程如图 3 所示。
首先，用户生成一个 DID，其过程与定向 VC 一样，不再赘述。在收到属性列表后， P i P_i Pi 生成 R i R_i Ri，包括为用户生成的证书 c r e d cred cred 和对证书的完整性签名。 P i P_i Pi 然后将 R i R_i Ri 和其自身的公钥广播到区块链上，其他域收到广播后，使用区块链上的 P i P_i Pi 公钥验证 c r e d cred cred 的完整性。如果他们同意签发 VC，则使用 p r i K t j priK_{tj} priKtj 对 c r e d cred cred 进行签名，生成部分签名 V C j : { c r e d , ( c r e d ) p r i K t j } VC_j:\{cred,(cred)_{priK_{tj}}\} VCj:{cred,(cred)priKtj}，并将其发送给 P i P_i Pi。一旦 P i P_i Pi 收集到至少 ≥ t \geq t ≥t 个签名，它使用 C o m b i n \mathsf{Combin} Combin 算法将它们组合成最终可验证的 V C g VC_g VCg，返回给用户 ( T n , V C g , ( T n , V C g ) p r i K P i ) (T_n,VC_g,(T_n,VC_g)_{priK_{P_i}}) (Tn,VCg,(Tn,VCg)priKPi)。最后，用户将 V C g VC_g VCg 存储在本地。
4.3 VC 的验证
两种 VC 的认证方法类似，仅使用的密钥不同。为了访问域 P j P_j Pj，用户 U t U_t Ut 选择合适的 VC，使用其私钥 p r i K d priK_d priKd 对其进行签名，并将签名后的消息 M d M_d Md 发送给 P j P_j Pj。需要注意的是，认证不仅需要 VC，用户还需要通过签名来证明其对 VC 的所有权，验证顺序如图 4 所示。
首先， P j P_j Pj 收到消息 M d M_d Md，在区块链上查询 p u b K d pubK_d pubKd 和 p u b K P i pubK_{P_i} pubKPi，并使用 p u b K P i pubK_{P_i} pubKPi 验证用户公钥的完整性，确保未被篡改。然后， P j P_j Pj 读取用户用于验证 V C d VC_d VCd 的公钥，以确保 V C d VC_d VCd 是由用户提交且未被篡改。最后，域 P j P_j Pj 检查 VC 中的发行者公钥，验证成功后用户获得访问权限。
4.4 凭证借用
如果用户 U t 0 U_{t_0} Ut0 需要短期或不频繁地访问域 P j P_j Pj 的服务，可以选择借用其他用户的 VC，利用代理签名技术来实现这一目的。
首先，用户 U t 0 U_{t_0} Ut0 向用户 U t U_{t} Ut 发送请求信息和 d i d t 0 did_{t_0} didt0。作为响应， U t U_{t} Ut 生成一个随机数 n o n c e nonce nonce，将 { d i d d , n o n c e } \{did_d,nonce\} {didd,nonce} 返回给 U t U_{t} Ut。收到后， U t 0 U_{t_0} Ut0 使用其私钥 p r i K t 0 priK_{t_0} priKt0 对随机数进行签名，将签名后的随机数 ( n o n c e ) p r i K t 0 (nonce)_{priK_{t_0}} (nonce)priKt0 返回给 U t U_{t} Ut。在验证随机数后， U t U_{t} Ut 生成授权信息 δ \delta δ 和授权证书 w w w，然后打包凭证 V C d VC_d VCd 发送给 U t 0 U_{t_0} Ut0，详细过程如图 5 所示。
最后， U t 0 U_{t_0} Ut0 可以生成一个新的代理签名密钥 p r i K d 0 priK_{d0} priKd0 和 δ \delta δ。当访问域 P j P_j Pj 时， U t 0 U_{t_0} Ut0 使用 p r i K d 0 priK_{d0} priKd0 对 V C d VC_d VCd 进行签名，生成消息 M d 0 M_{d0} Md0，然后发送给 P j P_j Pj 进行验证。借用凭证的验证方法与前面两种凭证的验证方法类似，只是域需要在区块链上查找 U t 0 U_{t_0} Ut0 和 U t U_{t} Ut 的信息，并检查授权证书中的有效期等信息。
5 场景示例
论文使用跨国公司的案例来举例应用场景。跨国公司利用联盟区块链技术实现了一个高效且安全的身份认证系统，为了提高工作效率并加强公司员工信息安全的保护，公司决定在身份管理层面使用去中心化身份技术。每个业务域作为联盟链的一个节点，拥有自己独立的网络服务集。每个域的员工（即在该域拥有账户的员工）可以使用其域颁发的 VC 来认证身份并访问其他域。
定向 VC 的应用场景是，当金融领域的员工需要访问零售领域的资源时，他们可以申请一个特定的 VC，该 VC 由金融领域的监管部门担保并颁发，仅限于通过零售领域的认证。这种 VC 的优势在于，员工无需在其他域注册账户，可以访问其工作所需的资源，并且可以自主决定 VC 的使用和管理。
对于需要更广泛访问权限的情况，例如跨域合作项目的员工，可以申请通用 VC。这种 VC 的申请流程更为严格，需要金融领域的监管部门与其他域进行协商，并且只有当联盟链上超过一定数量的域同意时才能颁发。这确保了通用 VC 的颁发基于多方的信任和共识，增强了整个身份认证系统的安全性。
最后，凭证借用方法允许员工在不同域之间借用 VC。例如，如果零售领域的员工 A 需要短暂查询物流领域中某物品的位置信息，而其同事 B 恰好拥有物流领域的 VC，他们可以按照一定的协议让 A 借用 B 的凭证来访问所需数据，通过直接在 A 和 B 之间的凭证交互简化了流程。
学习笔记
这篇论文提供的是一个大的框架和方案，其中的具体实施可以有不同的算法来做到。比较好的一点是，去中心化身份认证的思路，可以让用户掌握自己的属性，并在不同的域之间轻松切换，域对接好信息和功能来提供权限的访问控制，安全和隐私做到了巧妙的平衡。最后，附上文献引用信息及 DOI 链接：
Zhang Z, Ren W, Zhang X, et al. A blockchain and signature based scheme for cross-domain authentication with decentralized identity[J]. Computer Standards & Interfaces, 2025, 94: 103994.
https://doi.org/10.1016/j.csi.2025.103994