基于区块链的身份信息共享认证方案*

黑一鸣, 刘建伟, 管晔玮

北京航空航天大学 网络空间安全学院, 北京100191

1 引言

在当今时代, 各行业机构为方便用户管理和服务都需要获取并认证用户的身份信息. 目前大多数认证方案都是为了保障认证的效率和准确率[1,2], 而忽视了身份信息的隐私性和安全性. 从用户隐私角度来看,用户并不清楚身份信息获取者的实际需求, 一旦信息获取者超越其访问权限, 非法获取用户额外的身份信息, 则用户个人隐私难以受到保护. 从便捷性角度来看, 用户每到一个新场景下都要重新注册并认证身份信息, 这导致用户很多冗余操作, 且工作效率不高. 从数据安全角度来看, 用户身份数据是是分布在各机构服务器上的, 由于他们的存储安全性参差不齐, 一旦出现信息泄漏或个别服务器故障, 后果非常严重.

综合来看, 可控权限的安全身份信息共享认证问题亟待解决.

2005 年, Sahai 和Waters 为了解决上述的身份信息隐私性和安全性的问题, 在身份基加密方案[3]的基础上提出了属性基加密方案[4]. 该方案较好地解决了用户隐私信息保护问题, 并且可以实现细粒度的访问控制.

2008 年, 中本聪提出比特币网络[5], 区块链技术正式进入人们视野, 区块链中比较有代表性的技术是智能合约技术[6]. 智能合约是一种允许在没有第三方参与的情况下, 以代码方式形成、验证或执行合同的计算机协议[7]. 其透明化和程序化的特点适合于完成数据存储、数据访问和数据更新操作. 目前最主流的智能合约系统是以太坊[8].

1.1 本文贡献

第一, 本方案基于属性基加密技术, 由可信注册机构设置各行业机构的身份信息访问权限, 防止用户不必要的隐私暴露.

第二, 本文使用区块链的智能合约技术实现身份信息共享和更新, 避免了身份信息多次重复注册填写,方便了信息共享及身份认证工作.

第三, 本方案使得身份信息注册标准化, 基于区块链的分布式存储结构, 相对普通中心化存储服务器模型的鲁棒性更高.

第四, 本方案在自行搭建的以太坊私链上进行了性能测试工作, 实验结果表明了本方案具有可行性.

1.2 相关研究工作

1997 年, Szabo[6]提出了智能合约的概念, 他指出计算机代码可以替代机械设备进行复杂交易的处理, 但当时缺乏可信的运行环境, 并没有得到重视. 直到区块链技术的流行才推动了它的发展. 目前智能合约技术已经应用到了很多方面, 其中包括商品拍卖交易[9]、共享经济[10]和商品交易[11]等. 尽管如此,智能合约仍处于较为初级的阶段, 存在着很多问题. 首先, 智能合约的开发需要一定的编程能力, 没有相关学习背景的用户难以参与合约编写和审计. 另外, 智能合约还存在异常处理脆弱[11]、数据来源不可靠[12]、隐私易泄露[9,13]等安全隐患. 针对智能合约开发壁垒问题, 现有比较好的解决方案有半自动合约开发[14]和形式化验证. 针对智能合约的安全性问题, 可使用OYENTE[12]和Hawk[9]工具进行检测.

2001 年, Boneh[15]提出了身份基加密(Identity-based Encryption, IBE). Nico Döttling 和Sanjam Garg[14]于2017 年提出了变色龙加密方案, 利用变色龙哈希函数压缩公钥, 提高了IBE 的效率. 该类加密方案以用户身份作为公钥, 其存在用户隐私暴露等安全问题. Sahai 和Waters 为解决IBE 存在的问题, 提出了属性基加密[4]的方案. 在该方案中, 用户不需要公开自己所有的身份信息, 确保了用户信息的隐私性和安全性. 另外, 解密者需要满足属性条件才能正确解密, 确保了数据的保密性. 2006 年, Goyal等人[16]提出了密钥策略属性基加密方案(KP-ABE). 将用户的密钥与系统的访问控制策略相联系, 密文与用户的属性集相联系. 2016 年, Wang[17]等人对KP-ABE 中的密钥生成过程和解密过程进行了优化, 用访问受限树来描述访问策略, 给出了一种密钥生成效率高, 解密成本低的KP-ABE 方案. 但该类方案中, 用户对数据的访问控制能力较弱. 2007 年, Bethencourt 等人[18]提出密文策略属性基加密方案(CP-ABE). 与KP-ABE 相反, 该方案将密文与系统的访问控制策略相联系, 密钥与用户的属性集相联系.后来Goyal 等人[19]给出了CP-ABE 的安全性证明并改进了该方案, 使其支持更高级的访问结构. Liang等人[20]改进了Goyal 等人的方案, 给出了更快的加解密算法且其生成的密文长度更短. 然而, 这些方案的密文长度均取决于属性集的大小. Zhou 和Huang[21]提出的方案不仅能获得固定长度的密文, 访问结构也不会呈指数增加. 上述的方案中, 密文总是和显式的访问结构绑定发送, 这样会泄露访问控制结构中的敏感信息. 2012 年, Lai[22]提出了一种能够部分隐藏访问结构的CP-ABE 方案, 并在完全安全模型下证明了该方案的安全性. 2013 年, Hur[23]对此提出了新的方案, 该方案对访问策略进行盲化处理, 保护了访问策略, 该方案在通用群模型下被证明是安全的. 2017 年, Qiu 等人[24]针对基于属性的可检索加密方案, 提出了访问策略保护方案, 使用非对称双线性映射实现了访问策略的隐藏, 能够抵抗关键字猜测攻击. 随着访问策略控制算法的逐渐成熟, 密钥滥用成为一个新的亟待解决的问题. 密钥滥用包括非法密钥共享和密钥滥发两种情况. 其中非法密钥分享指的是用户故意泄露自己的属性密钥信息; 非法密钥分发指的是属性中心滥发属性密钥. 在当前的ABE 方案中, 属性中心分配给用户的私钥往往仅和用户属性有关, 而不包含用户的独有特征信息, 导致密钥滥用现象相当普遍, 这对ABE 方案的安全性和可靠性造成了严重的威胁. Zhang 等人[25]给出了一个能实现黑盒追溯的CP-ABE 方案, 该方案不仅支持灵活且细粒度的用户属性撤销操作且能快速追溯泄露属性密钥的恶意用户. 2017 年, Yu 等人[26]介绍了一种可问责CP-ABE 方案. 该方案将用户身份嵌入到属性密钥中, 支持第三方公开追溯泄露密钥者的身份且能准确判断是恶意用户还是属性中心需要对泄露的密钥负责. 2018 年, Jiang[27]提出一个结合了秘密分享技术的ABE 方案, 在实现追踪泄露密钥用户的同时解决了属性密钥的滥发的问题. 在现实生活中, 用户的属性密钥往往是由多个属性中心进行管理的. 为了契合实际应用的场景, 2007 年, Chase[28]实现了多属性授权中心的ABE 方案: 用户的密钥由多个授权中心分配, 单个或少数中心非法的密钥分发行为无法影响整个系统的安全性, 在一定程度上增强了系统的鲁棒性. 但其存在两个问题, 一是方案中存在一个中央授权机构, 其行为不可控(可能是恶意的). 二是该方案仅支持有限集合的属性, 不利于权限的扩展. 文献[29] 中方案展示了一个无中央授权机构的ABE 架构. 在该方案中, 所有的属性中心都彼此独立地为用户发放各自管理的属性密钥. 针对第二个问题, Yang 等人[30]利用合数阶双线性群, 提出了一种支持权限扩展的多授权中心ABE 方案, 并利用双系统加密方法证明该方案是安全的.

2 背景

2.1 符号定义

表1 符号定义Table 1 Notations

2.2 以太坊

当前支持智能合约的主流区块链系统有以太坊、codius 和hyperledger 等. 以太坊是其中最为活跃的公有链系统, 它提供了去中心化的以太坊虚拟机来处理智能合约, 具有图灵完备性. 执行以太坊合约中的函数需要消耗一定的交易费用gas.

以太坊上智能合约的运行原理如图1 所示. 首先, 以太坊客户端发送调用合约函数的指令给以太坊节点; 然后, 以太坊节点将该指令输入其本地以太坊虚拟机, 按合约规则执行指令并返回结果; 最后, 以太坊节点互相对比验证运算结果, 根据系统共识机制将结果记录到链上.

图1 以太坊智能合约运行原理Figure 1 Execution principle of smart contracts on Ethereum

2.3 属性基加密

属性基加密方案的主要思路是: 用户利用某特定属性集进行加密. 解密时, 只有解密者的属性集合满足一定条件才能正确解密密文. 基本描述如下:

(1) (PK,MK) ←Setup(d): 该算法由授权机构执行, 输入安全参数d, 输出系统公钥PK 以及主私钥MK.

(2) SK ←KeyGen(PK,MK,W): 该算法由授权机构执行, 输入系统公钥PK、主私钥MK, 用户属性集合W, 生成该用户的私钥SK.

(3) CT ←Encrypt(PK,W′,M): 该算法由发送方执行, 利用系统公钥PK、属性集W′对消息M进行加密, 生成密文CT.

(4) M ←Decrypt(PK,SK,CT): 该算法由消息接收方执行, 利用系统公钥PK、私钥SK 解密CT,生成明文消息M.

属性基加密方案可分为两类: KP-ABE 和CP-ABE. 它们均是在上述基本方案的基础上做了一些改进. 本系统为保证发送者对信息的访问控制能力, 将使用CP-ABE 方案. 在CP-ABE 方案中, 发送方可以用自己定义的访问控制结构A 代替基本加密过程中的属性集W′, 用户私钥仍旧通过属性集W 进行生成. 在这个设定下, 解密方只有满足了访问结构才能正确解密. 其工作流程如图2 所示.

3 方案构造

3.1 系统架构

本文方案的身份信息共享认证系统是由多个分布式职能域包含的节点组成的区块链网络, 系统架构如图3 所示.

本方案中的职能域是根据机构的职能进行分类的, 例如医院域是所有医疗节点的集合, 教育域是所有学校节点的集合. 而从宏观上来看, 职能域又可以被分为注册域和查询域两大类. 注册域是可以进行User 身份信息注册和身份信息更新的节点组成的域. 注册域中有一个权限最高的可信节点(或者节点组)Center. 注册域的其余节点都要在Center 进行注册, 并由Center 颁发数字证书; 查询域是可以进行身份信息查询的节点所组成的域, 本方案中的所有职能域都属于查询域.

图2 CP-ABE 方案Figure 2 Scheme of CP-ABE

图3 系统架构Figure 3 System structure

3.2 区块链构造

区块链: 方案中的区块链结构参照以太坊系统. 在区块中以智能合约作为交易的形式来记录注册的身份信息.

智能合约: 我们将方案中的合约命名为身份注册合约, 合约的结构如图4. 其功能是记录注册的身份信息, 并支持查询域中节点的查询及注册域节点的更新.

图4 身份注册合约结构Figure 4 Structure of registration contract

本文的身份注册合约可分为变量区和函数区两部分. 变量区包括: (1) 全局变量. 包含映射结构VaildRegistrars (地址到布尔类型的映射, 用于标识合法的注册域用户) 和UsersMap (地址到用户数据结构Struct 的映射). (2) 与用户数据相关的Struct 结构: Certificate 为采用Base64 标准编码的数字证书字符串, 这里的数字证书归属于对应用户的注册域节点; Tvalid为Unix 时戳, 代表注册用户的身份有效期;Sig(Tvalid) 为该注册域节点对Tvalid的签名; PropertyList 为属性基加密后的用户身份信息集合(以字符串形式存在), 其包含了用户不同的加密身份信息.

函数区包括: (1) 注册域节点执行的注册函数, 有add() 和setStruct() 两个函数. add() 只能由Center 调用, 输入一个注册域节点的地址来实现链上注册(即令该注册域节点的地址在VaildRegistrars映射结果为true). setStruct() 只能由完成链上注册的注册域节点调用, 函数的输入为用户链上地址, 用户的Struct 信息, 其目的是实现用户身份数据的更新. (2) 查询域节点执行的查询函数. 包括获取注册特定用户身份的注册域节点信息的getInfo() 和获得特定用户加密身份信息的getProperty(). 函数的具体细节如下:

函数1 add()Input: a registered node’s address R.add Output: NULL 1 S = msg.sender 2 if S == Center.address then 3 VaildRegistrars[R.add] = true 4 end函数2 setStruct()Input: a user’s address U.add, a property list Pro, a digital certificate Certificate, a timer Tvalid, a digital signature Sig(Tvalid)Output: a Flag 1 S = msg.sender 2 if VaildRegistrars[S]==true then 3 UsersMap(U.add).PropertyList = Pro 4 UsersMap(U.add).Certificate = Certificate 5 UsersMap(U.add).Tvalid = Tvalid 6 UsersMap(U.add).Sig(Tvalid) = Sig(Tvalid)7 Flag = true 8 end 9 else 10 Flag = false 11 end 12 return Flag函数3 getInfo()Input: a user’s address U.add Output: Certificate, Tvalid, Sig(Tvalid)1 return UsersMap(U.add).Certificate,UsersMap(U.add).Tvalid,UsersMap(U.add).Sig(Tvalid)函数4 getProperty()Input: a user’s address U.add Output: a PropertyList 1 return UsersMap(U.add).PropertyList

节点: 方案中的所有节点均为记账节点, 由独立域中所有节点的服务器充当, 主要负责维护区块链账本. 记账节点采用POW 共识机制, 将身份注册合约打包并记录在区块内, 以获取一定收益. 查询域中的节点可以访问合约中的数据, 而只有注册域中的节点才可以发布和更新身份注册合约.

3.3 身份信息共享认证方案

本文的方案分为身份注册合约发布、身份信息注册、身份信息查询认证和身份信息更新4 个部分. 身份注册合约发布是Center 节点根据注册域节点的信息部署或更新身份注册合约的过程. 身份信息注册是User 通过注册域的节点将身份信息注册到区块链上成为Registrant 的过程. 身份信息查询认证即需要获取身份信息的节点根据Registrant 给出的地址信息到链上查询, 并将查询结果与Registrant 给出的信息对比验证的过程. 身份信息更新即注册域中的节点更新Registrant 身份信息的过程.

3.3.1 身份注册合约发布

(1) 注册域节点信息注册. 节点到Center 申请成为注册节点, Center 记录所有注册节点.

(2) 身份注册合约部署. Center 发布身份注册合约, 由记账节点打包部署到区块链上.

(3) 链上注册. Center 调用add 函数添加合法的注册域节点到VaildRegistrars 结构中.

3.3.2 身份信息注册

身份注册总体流程如图5 所示.

(1) 信息填写.

(i) User 在注册域节点填报详细的身份信息, 包括个人信息、家庭信息及生物认证信息等.

(2) 属性基加密身份信息.

(ii) 注册域节点根据身份信息分类标准(以个人信息、家庭信息和生物认证信息分类为例), 将注册者身份信息分类.

(iii) 注册域节点根据信息的分类情况采用不同的访问控制结构对信息进行属性基加密. 这里为保证加解密效率, 并压缩存储空间, 将采用混合加密的手段加密. 即使用属性基加密手段加密一个AES 加密密钥, 并用AES 算法加密各分类信息. 最后将两部分拼接作为本次加密结果.

(3) 发布身份注册信息.

(iv) 注册域节点调用setStruct() 将属性基加密后的信息发布到身份注册合约中.

图5 身份注册流程图Figure 5 Flow diagram of registration

3.3.3 身份信息查询认证

身份信息查询适应的场景是区块链中的任意节点想查询或核实某Registrant 身份信息. 这里我们假设查询者已经向属性密钥授权中心提供自己的属性集合, 并获得了授权中心计算返回的相应解密属性密钥.

(1) 获取Registrant 在链上的地址.

(i) 查询者请求查询Registrant 身份信息, Registrant 给出其在区块链上的地址.

(2) 查询者获取Registrant 的身份信息.

(ii) 查询者根据Registrant 的地址调用getInfo() 获取相应注册域节点的证书Certificate、有效期限Tvalid、期限签名Sig(Tvalid).

(iii) 查询者通过证书信息验证注册节点身份. 验证通过后再验证对期限签名的有效性.

(iv)若步骤(iii)验证通过, 则证明Registrant 身份有效. 查询者调用合约中的getProperty()方法来获取属性基加密后的身份信息集合. 若验证不通过, 则认定Registrant 身份无效, 结束查询.

(3) 查询者根据其解密属性密钥进行对链上获取到的该Registrant 的身份信息进行解密操作, 获得该查询者被授权可以访问到的数据.

(4) 查询者将其被授权访问得到的数据与Registrant 当前给出的身份信息做比对, 以认证其身份.

3.3.4 身份信息更新

身份信息更新操作适应的场景是某注册完成人的身份信息发生改变或者注册信息过期.

(1) 注册域的节点重新采集Registrant 身份信息.

(2) 注册域节点对更新后的数据重新分类并进行属性基加密操作.

(3) 注册域节点调用合约的setStruct() 方法, 传入待更新目标用户的地址和该用户的Struct 信息.

(4) 矿工先根据VaildRegistrars 结构核实函数调用者身份, 若调用者为注册域节点, 则根据set-Struct() 方法传入的参数进行更新. 否则, 不执行更新操作.

4 性能分析

本实验对方案中的身份注册合约进行实际测试. 本方案的实验硬件环境为Intel(R) Core(TM) i5-8300H CPU @ 2.3 GHz,RAM 为8 GB. 本方案的实验软件环境为geth-windows-amd64-1.8.8 和Ethereum-Wallet-win64-0-11-1. 基于以太坊搭建私有链, 设定困难为值为0x20000.

信息采集: 为满足实验测试的需求, 本方案采集数据包括三种类型: 个人信息, 家庭信息及生物特征信息. 其中个人信息包含姓名, 性别, 身份证号, 学历. 家庭信息包括家庭成员信息, 家庭住址, 籍贯. 生物特征信息包括人脸特征和指纹特征.

本实验采用目前常用的基于深度学习的ResNet 算法[31]提取用户人脸信息. 我们采用1024 维度的特征提取参数, 并以32 位浮点数进行保存, 获得的人脸图像的特征结果大小为4 KB. 本实验基于指纹特征提取算法[32], 可在保证认假率小于0.0001% 且拒真率小于0.75% 的前提下, 获得指纹特征大小为512 B. 我们设定个人信息数据量大小为400 B, 家庭信息数据大小为600 B. 综合所有个人身份信息,总的单样本数据量大小约为5.5 KB.

合约测试实验: 本实验利用solidity 实现了文中的身份注册合约, 并在搭建的私链上完成了测试. 我们测试了部署身份注册合约和执行合约中各函数的gas 花费以评估本文方案经济性. 在测试实际花费时,我们选择了3Gwei (每gas 对应3Gwei 以太币) 和6Gwei (每gas 对应6Gwei 以太币) 两种汇率, 并将实际花费最终统一换算为美元表示.

测试的结果如表2 所示. 由测试结果可以看出, 合约的部署花费以及执行add、getInfo、getProperty等函数的花费较低, 其中getInfo、getProperty 这两个查询函数的调用不需要额外花费. 而由于setStruct函数在调用时需要传入较大的数据量, 所以经济性上相对较差.

为减少调用setStruct 函数时的花费, 本文也支持一种均衡的方案: 只向合约中传输一个存放了特定用户Struct 信息的链接及该信息的哈希值, 而把实际的信息放到链下存储. 采用该方案的gas 消耗仅为88 605. 但是此均衡方案需要执行重定向和数据完整验证操作, 所以在效率方面稍显不足.

表2 注册合约中不同函数的花费Table 2 Cost of diあerent functions in registration contract

效率测试实验: 本实验将比较普通加密存取和属性基加密结合区块链两类方案, 以评估方案的效率情况. 第一类方案即方案一: 采用AES 加解密明文身份信息, 并基于数据库进行存取对比操作; 第二类方案基于区块链系统采用CP-ABE 和AES 结合的混合加解密方式, 即利用CP-ABE 加(解) 密AES 密钥,并利用该密钥对明文数据进行AES 加(解) 密. 其包含两个具体方案, 它们的密文大小和数据加解密时间不同. 方案二: 加密手段采用文献[33] 中的方案结合AES, 数据存储查询基于区块链的智能合约. 方案三:数据存储查询与方案二相同, 解密手段采用文献[34] 的方案结合AES.

下面对各个方案的加解密算法性能进行比较. 其中, 明文数据大小均为5.5 KB, 属性基加密的系统属性集大小为20, 用户属性集大小为20, 策略属性集大小为5.

表3 不同方案的性能Table 3 Performance of diあerent schemes

结合表3 中的结果, 我们进行了各方案的整体信息存储(包括数据加密和存储过程) 与查询(包括信息查询和解密过程) 测试. 测试结果如图6 和图7 所示.

图6 身份信息存储耗时Figure 6 Time cost of storing identity information

图7 身份信息查询耗时Figure 7 Time cost of searching identity information

由图6 和图7 可见, 普通的AES 加密结合数据库存储的方案(即方案一), 在数据存储和查询性能上都要优于后两种方案. 但是, 单一的AES 加密无法满足可控权限的身份信息共享需求. 方案三相对方案二的存储耗时长, 但查询耗时短, 且与方案一的查询性能相近. 在本设计方案中, 一般来说数据存储是一次性的, 而数据的查询是多次进行的. 所以综合上述情况, 我们认为方案三更加适合本文的需求.

5 总结

本文设计了基于区块链的身份信息共享认证方案. 在数据存储方面, 存储的数据量稍大于传统的基于AES 算法的数据存储方案. 在数据查询方面, 由于各区块链节点都拥有全部注册者身份信息, 因此减少了并发查询的压力. 在数据更新方面, 更新函数只能由更新域中的节点调用, 并且合约会根据更新时间戳进行判断执行更新操作, 每次只执行最近的更新操作, 保证了全网一致的更新操作. 综合实验性能, 我们认为该方案具有较强的可行性.