基于区块链和可信执行环境的属性签名身份认证方案

冉津豪 蔡栋梁

（复旦大学计算机科学技术学院 上海 200433）

（上海区块链工程技术研究中心（复旦大学）上海 200433）

（复旦大学义乌研究院 浙江义乌 322000）

（22110240060@m.fudan.edu.cn）

2022 年，中央网络安全和信息化委员会办公室等十六部门联合通知，公布了15 个综合性和164 个特色领域国家区块链创新应用试点名单[1]，区块链应用正在逐步进入常人的生活.

区块链是新一代信息技术的重要组成部分，在过去十余年里，部分学者称区块链技术为分布式系统领域革命性的技术[2].中本聪[3]的一种点对点的现金系统首次展现了区块链的应用形式，他通过将Haber 和Stornetta 提出的无信任时间戳的概念[4]应用到去中心化的环境中，并结合工作量证明[5-6]，建立了比特币共识协议.工作量证明协议将计算资源总和超过50%的节点共识得到的结果作为正确的结果记录下来，实现最终的一致性[7].同时，区块链中的区块将通过哈希成链，保证了链上内容不可篡改的特性[6].

区块链的共识机制让许多问题有了新的解决思路，其中一个重要的区块链应用就是身份认证.由于互联网应用及基础设施的发展，越来越多的人接入互联网生活[8].随着对数字身份的需求不断增长，人们生活的很大一部分将在网络中与服务进行交互，因此身份认证管理也成为研究的热点.简单来说，数字身份是人们通过电子方式向应用服务证明自己身份的一种手段.

分布式的身份认证方案通常可以表述为去中心化身份（decentralized identity,DID），或者是自我主权身份（self-sovereign identity,SSI）[9]，本文不对这两者区分，下文统一称为SSI.从本质上讲，SSI 是一个允许用户个人完全拥有和管理他们自我数字身份的系统，主张用户应独立于应用服务存在，用户的个人数字身份和个人信息完全由个人所拥有和控制，用户可以自行构建属于自己的可验证凭据（verifiable credentials,VC），而不需要通过中心化的第三方，如应用服务、中心机构等.

可信执行环境（trusted execution environment,TEE）是指在计算设备中与操作系统隔离的一块独立、安全、可信的软件执行环境，从硬件级别保障隐私、敏感数据计算的机密性、完整性.此方案中，用户需要在本地环境中计算VC 及零知识凭据，而个人用户很难具备较好的安全防护意识，其专业知识和习惯常常不具有为该计算提供安全防护的能力，让敌手有机可乘.因此，为客户端程序引入TEE 技术是必要的.

本文的主要贡献包括3 个方面：

1）提出了一种去中心属性签名[10]结合零知识证明的SSI 方案.区块链公开透明以及不可篡改的特点将约束管制应用机构的行为.用户可通过身份标识，注册特定应用服务的认证权限，自主生成VC.同时，为应对应用服务数量增加的场景，本文方案优化了用户重复生成VC 过程中的额外开销，用户的VC 可扩充生成，提高了方案的效率.

2）为用户生成VC 结合TEE 的方法.考虑到普通用户的环境安全性不足的问题，将用户的VC 生成过程置于TEE 中，降低VC 生成及多次VC 扩充过程中硬件级别风险，提高用户私钥的安全性.

3）设计了一种用户VC 冒用审计机制.身份被窃取并冒用的过程是难以察觉的，这一机制将使得冒用过程有迹可循.主要依赖将验证过程中对包含验证次数的计数哈希的内容记录到区块链，用较小的验证代价完成VC 的冒用审计.

1 相关工作

本文的研究对象是基于区块链和TEE 的属性签名身份认证方案，本节将介绍身份认证方案及TEE的相关研究现状.

1.1 身份认证方案

中心化身份、联邦身份和自我主权身份是系统身份认证发展的3 个阶段[9，11].中心化身份由应用服务直接控制身份，用户直接使用用户名及密码登录.这种方法模式简单、使用方便，且大量的用户数据由应用服务直接掌控，可以被应用服务分析优化服务内容，在今天仍然是大部分应用服务的身份认证手段.然而，身份数据的集中保存是一把双刃剑，首先是用户隐私难以保证，用户数据泄露问题时有发生[12]，且随着应用服务数量的增多，用户的密码管理负担也会更重.用户习惯对不同应用设置相同密码，当相同的密码泄露时，大量应用的身份安全将受到威胁.联邦身份主要由少量的身份提供者为用户提供数字身份，登录到其他应用.文献[13]提出了一种联邦身份架构，允许用户跨安全域动态分发身份信息，从而提高数字身份的可移植性.文献[14]利用安全断言标记语言进行联邦身份管理，降低用户管理成本，还进行了完整的安全性证明.OAuth2.0 协议[15]帮助第三方应用向存有用户身份信息的服务提供商按需获取用户的授权，整个过程是安全且用户可控的.国内应用常见的有通过微信、支付宝登录的登录方式，国外应用也有通过谷歌、微软登录的登录方式.智能手机设备的普及为联邦身份提供了条件，但身份提供者能跟踪用户登录行为，可以拒绝为用户提供身份，甚至冒用用户身份登录到第三方应用服务，用户身份仍然不能自主控制.

自我主权身份方案中，用户将利用密码学的手段，通过管理与个人身份认证有关的私钥信息，实现对自我身份的掌控.文献[]的uPort 协议使用以太坊智能合约地址作为用户身份标识符，文献[17]的Blockstack 通过使用virtualchains 以去中心化的方式解决了信任引导的问题，即网络上的新节点可以独立地验证所有数据绑定.Candid[18]用智能合约存储具有隐私保护的身份数据，用户可自主控制身份属性披露与否，同时还通过连接外部存储来扩大属性容量.文献[19]虽然与分布式公钥基础设施相关，但本质上也具有身份认证功能.虽然文献[16-19]所述的方案都满足了用户身份的分布式特点，但都忽略了用户自主保存私钥过程中的风险.一旦窃取到用户私钥，其他用户都可以伪造该用户身份登录到应用服务，且这个过程是用户不可察觉的.文献[20]的方案在登录时，如果用户身份被冒用则进行过身份验证，用户可以收到反馈，但该方案缺少对于应用的扩展支持，并且需要在用户环境下执行隐私风险较高的秘钥计算过程.

中心化身份、联邦身份和自我主权身份对比内容如表1 所示.其中，考虑到联邦身份方案中，管理用户数字身份的机构通常为互联网巨头公司，具有良好的安全防护能力，且公司的形象驱使它们尽力做好安全防护，所以安全风险较低.而中心化身份方案中有许多体量较小的公司，没有能力或没有侧重于安全防护，并且由于用户可能倾向于多个应用设置相同密码，所以安全风险较高.

Table 1 Comparison of Centralized Identity，Federated Identity and Self-Sovereign Identity表1 中心化身份、联邦身份和自我主权身份对比

Table 2 Symbols and Their Description表2 符号及其描述

1.2 可信执行环境

Intel 软件防护扩展（software guard extensions,SGX）[21]技术、AMD 内存加密（memory encryption）技术和ARM 的TrustZone 技术是各大平台具有代表性的TEE 技术.在本文方案中，我们选择普及率更高的Intel SGX 技术.

Intel SGX 是x86 架构的扩展，允许用户级代码创建名为飞地（enclaves）[21-22]的TEE.SGX 通过ECalls 和OCalls 进行飞地的调入和调出，Ecalls 是从飞地外部调用飞地内部的可信函数，而OCalls 则相反.飞地的调入和调出将会跨越安全边界，并对安全参数进行检查，因此会产生额外的性能开销.文献[23]测量了飞地的调入和调出取决于缓存命中或错过需要8 600～14 000 个周期.

TEE 常常被应用于分布式节点计算场景中.TC[24]使用SGX 完成MapReduce 分布式计算，同时保持相应的代码和数据的隐私性、正确性和完整性.TCounter[25]基于SGX 设计了CPU 资源耗费计数框架，保证云服务中的计算资源耗费准确，防止恶意云服务提供商虚报资源消耗.在身份认证方向上，Town crier[26]是在2015 年便提出的用链下TEE 为智能合约提供数据的方法.文献[27]用SGX 及区块链构建了身份认证方案，但方案中仍存在集中了大量用户身份信息的身份提供者，本质上仍是联邦身份方案.文献[28]则用了ARM 的Trustzone 保障用户数据的完整性和机密性.

2 预备知识

2.1 ElGamal 加密[29]

G是一个阶为素数p的乘法循环群，g是群G的生成元，对于一任意群内的元素y∈G，一定存在一个唯一的x∈Zq，使得等式gx=y成立.ElGamal 加密将分成3 个步骤：

1）生成密钥.选择一个随机数x∈Zp，计算gx=y，则ElGama 加密的公钥为（y，g，p），私钥为x.

2）加密.对于消息m，随机选择r∈Zp，计算c1=gr，c2=m×yr，用c1和c2构建密文对 〈c1,c2〉.

3）解密.对于密文对〈c1,c2〉，利用私钥x，计算

2.2 Sigma 协议[30]和Schnorr 协议[31]

设R⊆X×Y是一个基于NP 困难问题的关系，那么一对 (P,V) 构建在上的一个Sigma 协议为：

1）P是证明者算法，输入为一对 (x,y)∈R，V是验证者算法，输入为y∈Y；

2）P计算一个承诺C，将其发送给V；

3）V在接收到P发送的承诺C后，随机生成一个挑战值c，并发送给P；

4）在接收到来自V发送的挑战值c后，P根据c计算一个响应值z返回给V；

5）V通过验证输入y、承诺C和交互中的挑战值c、响应值z后，输出接受或拒绝.

Sigma 协议具有3 个性质：

1）正确性.在公共输入y上，如果诚实的证明者P得到的输入x使得 (x,y)∈R，那么验证者V总是接受.

2）可靠性.给定一个公共输入y，以及V关于y输出接受的2个会话 (C,c,z),(C,c′,z′),其中c≠c′，那么任何人都可以计算出x的值，使得 (x,y)∈R.

3）零知识性.存在一个高效的概率性算法Sim（称作模拟器），对于所有的输入 (y,c)∈R，其中S为挑战值空间，Sim 能够输出一个可接受的会话 (y,C,c,z)，并且该会话与诚实的P和V之间的会话分布相同.

Schnorr 协议是Sigma 协议中的一种.G是一个阶为素数q的循环群，其生成元为g∈G，假设一个证明者想要证明它知道某个群元素h=gx∈G的离散对数x.这里R={(x,h)∈Zq×G:gx=h}.如图1 所示，Schnorr 协议的交互过程为：

Fig.1 The interactive flow of Schnorr protocol[31]图1 Schnorr 协议交互流程[31]

1）P的输入为x,h=gx，V的输入为h；

2）P选择r∈RZq，计算承诺C=gr发送给V；

3）V选择挑战c∈RZq发送给P；

4）P根据挑战c,计算响应值z=r+cx返回给V；

5）V通过验证gz=Chc是否成立输出结果，若成立则输出接受，否则输出拒绝.

使用Fiat-Shamir 转换[32]，证明者P能够通过H(h,C)计算挑战值c，其中H是哈希算法，h是V的输入，C是P的承诺，因此Schnorr 协议可以变为非交互式的，只需要一个通信轮次.证明者可以通过承诺值C、挑战值c以及响应值z直接构造proof=(h,C=gr,c=H(h,C),z=r+cx)，将proof发送给 V，V可以通过验证proof直接输出接受或拒绝.

2.3 离散对数相等（discrete logarithm equality，DLEQ）零知识证明协议

DLEQ(g,G,t,T)用于证明离散对数loggG=logtT，当等式成立时验证者输出接受.

证明者P的输入为s∈Zq，计算G=gs,T=ts，向验证者证明 loggG=logtT.验证者的输入为 (g,G,t,T).协议交互流程为：

1）P选择随机数r∈Zp，计算承诺值C1=gr,C2=tr并发送给验证者V；

2）V收到 (C1,C2) 后，选择挑战值c∈Zp发送给P；

3）P根据挑战c计算响应值z=r+cs返回给V；

4）V通过验证gz=C1Gc和tz=C2Tc是否成立输出结果，如果成立输出接受，否则输出拒绝.

2.4 非交互式离散对数相等（non-interactive discrete logarithm equality,NIDLEQ）零知识证明协议

对DLEQ 协议使用Fiat-Shamir 转换[32]得到NIDLEQ 协议，证明者P能够通过H(C1,C2)计算挑战值c，其中H是哈希算法，C1和C2为P的承诺.证明者可以通过证明内容、承诺值C、挑战值c以及响应值z直接构造proof=(C1=gr,C2=tr,c=H(C1,C2),z=r+cs)，将proof发送给V，V通过验证c=H(C1,C2),gz=C1Gc和tz=C2Tc是否成立输出结果，如果都成立输出接受，否则输出拒绝.

3 系统模型与安全模型

3.1 系统模型

本文方案由三类通信单位及以太坊区块链组成，通信单位分别为全局控制中心、用户、应用服务.通信单位间的通信关系如图2 所示.

Fig.2 The system model of our scheme图2 本方案系统模型

1）全局控制中心.用于全局循环群的素数阶及生成元的生成，并上传到区块链供其他通信单位查询使用.与已有的身份认证方案的密钥生成中心（key generation center,KGC）不同，常规的密钥生成中心或者权威授权机构可能会承担为用户生成密钥的职责[33-35].本文方案的全局控制中心仅用于初始参数生成，参数将全部公开，不存在泄密风险，其工作可以被某一应用服务代替.本文方案为了更好地展示去中心化的特点，使得各应用程序角色均衡，将该部分内容单独置于全局控制中心.

2）用户.应用服务使用者，期望获得自主控制的去中心化身份，能快捷稳定地登录到应用服务中，通常为个人用户.这类节点单位的特点是操作人员专业性不足、程序执行环境安全性低，因此，面向用户的VC 生成及验证过程应在保证安全的前提下尽量简洁，用户内部设有TEE 从硬件级别保护程序执行.其安全模型将在3.2 节中详细定义.

3）应用服务.应用服务提供者，通过应用初始化加入到身份认证系统中，为用户提供注册凭据申请和应用验证服务.

4）区块链.根据区块链去中心化、不可篡改的特点，全局控制中心生成的初始参数、各应用服务公钥、用户登录次数计数哈希都将上传到区块链中供查询和审计，并且在一定程度上可以避免全局控制中心被攻击进而初始参数被修改导致全局故障.

节点行为如图2 所示.首先全局控制中心将进行全局初始化生成初始参数.各应用根据全局参数生成公私钥对，并将初始参数和公钥上传到区块链.用户首先需要完成初始信息的拟定，根据全局参数生成公私钥对，公钥即为用户标识.随后，用户向对于需要使用的应用服务提交注册申请，由应用服务提供注册凭证.用户根据注册凭证即可在TEE 里生成签名内容，形成VC.在用户请求使用某个应用服务，应用服务期望验证用户的身份时，用户需要向应用服务主动出示VC、非交互零知识证明凭据及登录次数计数哈希CNT.验证过程中应用服务将确认以下信息：①确认VC 有效性；②通过零知识证明凭据确定VC 使用者与VC 所有者对应；③验证用户登录次数计数连续性，即用户在上次登录与本次登录的登录次数计数是连续的，并在验证通过后将用户登录记录哈希更新上传到区块链，供用户审计.对于新增的应用服务，用户可以继续申请注册凭证，并在TEE中重新生成签名内容，形成新的可验证凭据.

3.2 安全模型

根据攻击者的执行权限，攻击者可分为第三方用户攻击者 A1及作恶应用服务攻击者 A2.攻击者A1可以通过执行5 方面内容获取信息：

1）A1可以查询所有链上公共可访问信息，包括全局参数、其他应用公钥、验证过程中生成的登录次数计数哈希.

2）A1可以根据区块链上的全局参数素数p、循环群G及生成元g，选取一个随机的用户私钥，并计算其公钥.

3）A1可以提交其全局标识向应用服务申请注册凭据.应用服务为其生成对应应用服务信息的用户属性基密钥及其中间参数，并传输给 A1.

4）A1可以向应用服务发起验证服务请求，但该过程能收到的信息是有限的，应用服务仅返回验证通过，或VC 可能被冒用.

5）A1可以获取到已完成应用验证过程的VC，本文不讨论该信息的获取过程，但这是证明重放攻击的前提.

比起攻击者 A1，攻击者 A2作为应用服务可以获取更多的信息，如可以获得所有曾在该应用服务中进行过应用验证服务的用户VC.

在我们的属性签名身份认证方案中，会考虑3 种类型的攻击：

1）证明伪造攻击.指攻击者试图伪造VC，被请求应用服务误以为攻击者的身份是有效的，从而通过用户身份验证请求.

2）证明重放攻击.指攻击者获取到了来自用户的一个或多个VC，试图重用这些证明以与被请求应用服务进行新的身份验证交互.

3）信息盗窃攻击.假设一个应用服务被攻击或者应用服务主动作恶，试图从接收到的VC 和区块链上的公共可访问信息中获取经过身份验证的用户身份信息，进行新的身份验证交互.

4 方案设计

本节主要提出完整的属性签名身份认证方案.该方案分为 6 个阶段：全局初始化、应用初始化、用户注册、VC 生成、VC 扩充及应用验证流程.该方案的首次生成时流程及扩充生成时流程如图3 所示.用户首次生成VC 时将进行VC 生成流程，否则用户将进行VC 扩充流程.用户首次执行VC 生成流程时，将保留属性签名的中间参数，在此情况下，用户可以在执行VC 扩充流程时提高效率.

Fig.3 Flowchart of our scheme图3 本方案流程图

4.1 全局初始化阶段

4.2 应用初始化

4.3 用户注册

4.4 VC 生成

3）对于i=1,2,…,n，计算根据结果计算c=H2(m,T1,T2,…,Tn,GIDp)；4）用n-t+1个点(0,c),(t+1,ct+1),…,(n,cn)构造n-t次拉格朗日插值多项式Pn-t(x)；5）计算

6）选择随机数bi∈Zp，计算承诺值挑战值zkci=H3(C1i,C2i),响应值zi=bi+wisp，i=1,2，…,n；7）输出签名 σ=(ci,di,Ti,ri,GIDp)(i=1,2,…,n)、多项式Pn-t(x)和proofZK=(C1i,C2i,zkci,zi)，并初始化登录次数计数哈希CNT=1，选择随机数wlast∈Zp，用于完成用户私钥泄露、冒用的审计.

4.5 应用验证

用户Userp期望向应用服务APPv进行身份验证，具体为3 个步骤.

1）用户利用ElGamal 加密算法选择随机数v∈Zp，计算密文参数w及密文CNTm，并组合构建proo fCNT，该步骤由用户在Intel SGX 环境中进行，即

2）使用签名及零知识证明凭据proofZK构建可验证凭据

用户发送VC到应用服务并更新CNT=CNT+1，wlast=w.

3）应用服务APPv将进行6 步验证：

①Pn-t(x)为n-t次多项式；

② 验证Pn-t(i)=ci,i=1,2,…,n，在此步骤不通过的验证请求，将被返回Pn-t(i)=ci等式不成立对应的序号i；

③验证Pn-t(0)=H2(m,T1,T2,…,Tn,GIDp)；

⑤ 验证proofCNT，首先验证w≠wlast，解密获得CNT明文

4.6 VC 扩充

当用户在已有VC 的情况下获取到新的注册凭据后，可以进行VC 扩充.假设签名人Userp已注册的应用服务信息集合为Ωp=用户通过KeyGen步骤申请到Appt+1的凭据AKt+1,GIDp,Paramt+1,GIDp，用户的VC 将通过以下5 个步骤更新.

1）随机选取d∈计算Rt+1＝gd；

2）计算Tt+1=并更新哈希结果c=H2(T1,T2,…,Tn,GIDp)；

3）用n－t个点(0,c),(t+2,ct+2),…,(n,cn)构造n-t-1次拉格朗日插值多项式Pn-t-1(x)；

4）根据新的拉格朗日插值多项式计算

5）更新签名σ=(ci,di,Ti,ri,GIDp)(i=1,2,…,n)和多项式Pn-t-1(x).

VC 扩充只需要更新签名及多项式即可，此过程不影响零知识证明凭据及链上登录次数计数哈希的验证.

5 分析与评估

本节将讨论本文方案在正常执行过程中的正确性及在3.2 节定义的安全模型下的安全性.同时实现VC 生成、VC 扩充及应用验证流程的算法，并评估其效率.

5.1 正确性证明

定理1.签名 σ的验证是正确的.

证明.根据方案的执行流程，正常运行下Pn-t(x)由n-t+1个点(0,c),(t+1,ct+1),…,(n,cn)构成，所以Pn-t(x)为n-t次多项式，且Pn-t(i)=ci,i=t+1,t+2,…,n.同时，在i=1,2,…,t时，ci由ci=Pn-t(i)计算得到，且Pn-t(0)=H2(m,T1,T2,…,Tn,GIDp)是显然成立的.

由Sigma 协议的正确性性质，验证者总是接受.因此签名 σ的验证是正确的.证毕.

定理2.零知识证明凭据的验证是正确的.

证明.对于验证是否 logRiTi=loggGIDp,其中Ri=若方案正常运行，由NIDLEQ 协议的正确性性质，验证者总是接受，因此零知识证明凭据的验证是正确的.证毕.

定理3.身份冒用审计凭据的验证是正确的.

证明.在不存在身份冒用、用户正常逐次进行身份验证的情况下，登录次数计数CNT=CNTlast+1总是成立，对于总是有以下等式成立：

因此身份冒用审计凭据的验证是正确的.证毕.

5.2 安全性分析

分析1.证明伪造攻击分析.

假设第三方用户攻击者 A1试图伪造用户VC，向应用服务发起应用验证请求.伪造VC 需要伪造4 个部分的内容，分别为签名 σ、多项式Pn-t(x)、零知识证明凭据proofZK、登录次数计数证明proofCNT.攻击者A1可以主动申请私钥及注册凭据构建签名及多项式，但签名内容GIDp是应用服务区分用户身份的关键.A1无法在不知道用户私钥US Kp的前提下通过NIDLEQ零知识证明协议构建proofZK，因此 A1进行伪造攻击的难度不小于求解 loggGIDp，即离散对数问题的难度.

分析2.证明重放攻击分析.

假设第三方用户攻击者 A1获取到来自用户的已完成应用验证过程的VC，试图重用这些证明以与被请求应用服务进行新的身份验证交互.在用户未进行新的VC 扩充之前，VC 除了proofCNT以外不会发生改变.

在应用验证的过程中，每一次验证都会对CNT进行自增的更新操作.proofCNT使用了ElGamal 加密算法，保证了CNT不被攻击者 A1得知.虽然ElGamal加密算法具有同态加密的特性，但验证过程中将拒绝加密参数相同的proofCNT，即w≠wlast.因此 A1无法在不知道应用服务私钥S K的前提下解密明文CNT及构建proofCNT，所以证明重放攻击在本方案中是无效的.

分析3.信息盗窃攻击分析.

应用服务攻击者 A2作恶，试图从接收到的VC和区块链上的公共可访问信息中获取经过身份验证的用户身份信息，进行新的身份验证交互.该攻击明显强于证明重放攻击，因为 A2应用服务直接掌握了应用服务私钥S K，可以直接解密用户proo fCNT访问到CNT，通过构建proofCNT+1，但该过程是有前提的.

proofCNT包含了3 个元素，即w,CNTm,wlast.其中wlast既可以用于应用服务与用户审计验证=H(GIDp,CNT-1,wlast)，同时也保证了A2构建proofCNT+1需要满足用户在应用服务的 A2处进行应用验证过程后，未与其他应用服务进行新的身份验证交互的条件.因此，A2有能力在一定时间区间内构建proo fCNT+1，进一步构建VC，与其他应用服务进行交互，但该过程会使 A2有3 点风险：

1）当 A2与其他应用服务验证完成后，区块链将进行信息更新链上信息，用户进行登录次数计数哈希审计可得知身份信息被冒用；

2）用户进行常规应用验证流程，由于wlast及CNT发生改变，应用验证将返回，可得知身份信息被冒用；

3）应用验证流程需要更新链上信息，由于区块链去中心化、公开透明、可追溯、不可篡改的特点，当用户得知身份信息被冒用后，用户可以直接追溯到用户最后一次正常验证的应用服务的 A2.

综上，本文方案存在应用服务在较短时间区间内信息盗窃攻击的可能性，但该过程是用户可审计、易察觉的，加之区块链可追溯、不可篡改的特性，该攻击的责任人将是明确的.

5.3 同类工作对比

本文方案是用户在TEE 下计算、管理秘钥的自主主权身份方案，不存在可能泄露秘钥信息的中心信息机构，且无法被重放攻击威胁.本节将与其他方案对比身份验证方案特性.文献[19]使用了开源框架ZoKrates 生成零知识证明凭据以认定可验证凭据的归属权.但该零知识证明凭据将被传输到链上，且在验证时该凭据会发送给验证者，因此恶意用户及恶意应用服务可以直接获取相应的用户证书及零知识证明凭据，登录到其它应用服务，实现证明重放攻击.文献[20]使得用户在身份存在冒用记录时收到反馈，形成对重放攻击的抵御，但该方案缺少对于应用服务的扩展支持，并且需要用户执行隐私风险较高的秘钥计算过程.文献[27]的身份认证方案在秘钥计算流程上用SGX 技术保证用户环境下的秘钥计算安全，但方案存在集中了大量用户身份信息的身份提供者及信息认证依赖方，本质上不是自我主权身份.文献[19,20,27]所述方案的特性比较如表3所示.

Table 3 Feature Comparison of Identity Authentication Schemes表3 身份认证方案特性对比

5.4 实验环境说明

本文方案的实验环境由本地物理机连接到服务器，并在服务器环境下开发完成.物理机硬件配置为：物理机型号联想小新Pro14，芯片Intel i9-12900H，内存16 GB，操作系统windows11.服务器配置如表4所示.

Table 4 Server Experimental Environment Configuration Instructions表4 服务器实验环境配置说明

EGo[36]是一个通过Go 语言构建TEE 应用程序的框架.通过EGo 可以模拟应用程序运行在加密和可验证的Intel SGX 飞地中.

在公共参数的选择上，使用了阶数p为1 024 位的素数群.为了更符合实际场景，我们设定用户注册的应用数量大致占总应用服务数量的2/3，如在图4中，VC 生成时间数据点（30，0.001 47）表示VC 生成算法执行时应用服务总数为30 个，用户拥有的注册凭据数量为20，算法执行时间为0.001 47 s.

Fig.4 VC generation time and verification algorithm time in common environment图4 普通环境中的VC 生成时间及验证算法时间

5.5 性能分析

首先考虑算法在常规环境中的效率.图4 是普通环境中的VC 生成及验证算法时间.由图4 可见，随着用户数量的增多，算法执行时间将持续上升，但可喜的是，应用程序总数为120 时，VC 生成时间不超过0.04 s，VC 验证时间将不超过0.2 s，这在实际应用场景中是可以接受的.

用户应用注册需要向应用服务申请新的注册凭据，该流程是简洁且基本固定的，在此不做讨论.但用户申请新的注册凭据，随后扩充VC 的过程是会频繁发生的.图5 是VC 生成时间及VC 扩充时间的比较，两者同是根据注册凭据信息计算VC，但VC 扩充算法将省去部分重复计算过程，提高运算效率.实验数据表明，在应用服务总数小于100 个时，效率的提升在50%以上，在120 个应用服务时效率提升大约为35%.

Fig.5 VC generation time and expansion time图5 VC 生成时间及VC 扩充时间

探究用户算法在可信执行环境中的执行情况将更有意义.正如我们在1.2 节提到的，在SGX 的应用中，飞地的调入和调出将会跨越安全边界，并对安全参数进行检查，因此会产生额外的性能开销，因此我们在实验中不仅计算VC 算法的时间，而且还要计算调用VC 算法的环境初始化时间.图6 是环境初始化及VC 生成算法在普通环境及SGX 环境中的VC 生成流程时间比较，可见在应用服务总数相同的情况下，SGX 环境中额外需要的时间大致为1.75 s，且在应用服务总数增长的过程中，该时间不存在明显增长.如果该计算过程在应用服务中执行，则从0.25 s的时间开销提升到2 s 的时间开销将导致服务器的吞吐量降低87.5%，但这个计算过程是在用户环境下执行的，用户在本方案仅需要关注自身的VC 生成，因此该时间差是完全可以接受的.

Fig.6 VC generation process time in different environments图6 不同环境中VC 生成流程时间

为了使用户身份泄露可审计，同时也防止针对VC 的重放攻击，方案引入了proofCNT.proo fCNT的组成决定了其大小是固定的，这在实验中得到了验证.图7 是不同应用服务数量下各验证凭据占用存储空间大小及proofCNT的生成时间.可以发现，相比签名主体及零知识证明凭据，proofCNT的额外通信开销可以忽略不计且与应用服务总数没有关联的.加之从时间上分析，proofCNT的生成时间总维持在0.001 4 s左右，说明了本方案的proofCNT设计是低负载且高效的.

Fig.7 The storage space occupied by each authentication credential and the generation time of proofCNT图7 各验证凭据占用存储空间大小及proofCNT 生成时间

6 总结

基于区块链和TEE 技术，本文提出并实现了一种去中心化的属性签名身份认证方案.

本文方案旨在从用户在身份认证流程中的需求出发，解决可验证凭据管理繁重、安全性不足的问题，结合Schnorr 协议与非交互式离散对数相等零知识证明协议，让用户自主构建身份信息.当用户需要更新身份时，可通过扩充可验证凭据的方式重新构建身份信息.

为了让用户完全控制自身的身份信息，将可验证凭据的生成与扩充流程置于用户本地的TEE 中，TEE 的引入保证了用户生成、扩充可验证凭据时的安全性，这对于通常来说安全防护意识不足、防护能力较差的用户环境而言是重要的.登录次数计数哈希的记录使得用户自身的身份信息以任何可能的方式泄露而被冒用的行为可察觉、可审计，使得用户可及时应对.通过实验验证分析，本文方案在实际应用中是高效可行的.

本文方案流程仅针对身份验证及身份冒用审计.在未来，对身份信息泄露后的身份信息归属判断及恢复行为会是我们研究的重点.

作者贡献声明：冉津豪提出了思路并做了源代码实现，撰写论文；蔡栋梁提出了优化思路并协助撰写论文.