基于区块链的数字文凭认证及共享方案
2024-02-22马海峰高永福薛庆水李玉霞王俊华
马海峰，高永福，薛庆水，李玉霞，王俊华
(1.上海应用技术大学 计算机科学与信息工程学院，上海 201418；2.清华大学 网络科学与网络空间研究院，北京 100084)
0 引 言
目前随着互联网的发展，逐渐呈现着教育信息化的趋势，而且教育始终是所有人最关注的领域之一。由于新冠肺炎[1]的影响，越来越多的人选择在线学习，这进一步加快了在线教育的发展。网络教育带来便利的同时产生一些问题。例如，数字文凭的不安全性[2]、不同机构之间对文凭的接受程度不同。
在教育领域，已经逐渐有一些高校开始将区块链应用于数字文凭上，以记录用户的学习成果。Mike等[19]提供了一种基于以太坊基础设施的区块链平台，并且尝试着将其应用于流行的MOOC(massive open online courses)平台；OpenLearn平台允许学生进行课程注册，完成课程之后获得学习文凭，并对产生的交易进行加密和签名，但是该方案太过于理想，并未设计安全审计；Guo等[6]提出了一种基于区块链的数字版权管理方案，用于数字文凭的共享和管理，该方案使用智能合约来实现数字文凭的存储、验证。但是由于区块链的透明性，任何人均可以查看链上内容，数字文凭的内容具有隐私性，因此数字文凭的隐私无法完全被保护，这些方案在设计之初并未充分考虑隐私保护，因此数字文凭无法在不同的利益相关者之间进行广泛传播。
综合上述不足，该篇文章提出了一种改进的数字文凭共享验证方案。这篇文章的工作主要有如下几点：
(1)针对联盟链密钥分发中心的单点失效问题，为患者和机构引入组机制，组内成员进行环签密使用已有的环签密方案[18]，使该文章内的联盟链的密钥分发中心至多可以对n-1个恶意节点的作恶进行抵抗。
(2)相较文献[16]中使用的云存储，该方案采用了链下和链上的混合的数据存储模式，以减少区块链的存储负责，使用星际文件存储系统存储加密后的数字文凭，解决了数字文凭集中存储存在容易被非法篡改、删除的情况。
(3)用户的数字文凭数据通过发起交易，记录在智能合约中，可通过智能合约自动执行记录用户的所有行为，允许用户根据其数字文凭的访问记录。
(4)分析了联盟链生成区块的时间，以及结合改进后的环签密[18]后联盟链生成区块的时间和效率，并其它方案进行比较。最后根据安全分析显示，该方案比类似场景下的区块链方案的鲁捧性更强，安全性更高，且对联盟链区块的生成效率并无太多影响。
1 预备知识
1.1 双线性映射
(1)双线性性：对于任意a，b∈Zp和R，S∈G1， 有e(Ra，Rb)=e(R，S)ab；
(2)非退化性：存在R，S∈G1， 使得e(R，S)≠1G2。 这里1G2代表G2群的单位元；
1.2 区块链
区块链技术[7]作为一种前沿的分布式基础架构及计算范畴，正在重新定义数据的存储、验证、传输和管理方式。它以其独特的区块链数据结构为基础，不仅对数据进行加密验证，确保其真实性和完整性，还依托于分布式网络的节点通过共识算法共同作出数据更新的决策，从而对整个系统中数据一致性进行维护。区块链通过先进的密码学技术，为数据的传输和访问提供了强有力的安全保障，使得信息在各个节点间的传递既安全又可靠。此外，智能合约作为区块链技术的一个重要组成部分，由自动化的脚本代码构成，能够在预设条件触发时自动执行合约内容，这使得区块链的操作不仅高效，也减少了人为的干预和错误。区块链技术以其数据一致性、抗篡改能力和透明度等特点，在众多领域得到应用，例如车联网[8]、数字化医疗[9]、供应链管理[10]等各种学术领域当中，本文对其在数字化文凭验证和共享领域的应用进行了深入分析，指出利用区块链的特性能较好实现数字文凭的去中心化认证。
目前较为成熟的公共区块链有以太坊[11]和比特币等，但这两种网络都存在一个较为相似的问题，网络上写入数据的成本较高，这会加大教育机构的写入成本，因此该方案使用Hyperledger Fabric[12]联盟链存储数字文凭的哈希值。
1.3 IPFS系统
该方案使用分布式数据存储系统而不是中心化的云存储[13]。在分布式数据存储中，不存在单点故障，因为数据分散并存储在不同的节点中。此外，由于对等体可以直接分享内容，因此可以实现更快的数据访问，因为对等可以直接分享内容，而不像集中式存储有高带宽要求。使用行星际文件系统[14](IPFS)作为其分布式数据存储系统。作为其分布式数据存储系统[15]。IPFS定义了一个点对点协议，允许数据可以通过分布式节点进行访问。IPFS被与云存储服务相比，被认为是更快、更安全、更可靠的存储服务。它还旨在网络的数据冗余问题。这主要是因为IPFS使用内容寻址而不是位置寻址来识别存储在网络上的数据。IPFS使用数据文件的哈希值作为其标识符。文件的哈希值作为其标识符，这对数据来说始终是唯一的。在数据被更新或改变的情况下，将上传一个较新的数据版本。如果一个特定的数据文件被请求，数据标识符被用来在不同的对等体中定位该文件。IPFS上的一个节点，如果其存储的哈希值与内容标识符相匹配，标识符的节点将把数据文件返回给请求者。
2 方案详述
2.1 系统模型
该方案涉及5个角色，教育机构、用户、IPFS系统、联盟链系统、其它机构：
教育机构(educational institution，EI)：教育机构用来生成用户的数字文凭，教育机构负责将数字文凭加密后上传到IPFS系统，同时需将数字文凭的哈希值上传至区块链。
用户(User，U)：用户可在教育机构中学习，可以在IPFS获取到加密后的数字文凭。
IPFS系统：教育机构生成用户的数字文凭后，对数字文凭进行加密，加密后以IPFS对象形式上传至IPFS系统。
联盟链系统：教育机构生成用户的数字文凭之后，通过SHA-1算法求出数字文凭的哈希值，并且使用用户的id， 和哈希值构成键值对，存储值联盟链；公司或其它机构访问记录也一并上链。
其它机构：想要核实用户的数字文凭真实性的公司或者教育机构。
主要包括以下步骤：①系统初始化；②教育机构生成用户的数字文凭，将其加密后上传至IPFS系统；③教育机构将数字文凭的索引值与用户的ID存储至区块链系统；④用户通过CID从IPFS系统中将加密后的文凭取出；⑤用户使用自己的密钥解密文凭；⑥用户将文凭发送给想要验证的机构或公司；⑦机构或公司从区块链中根据用户的ID取出数字文凭的索引值，判断数字文凭是否属于用户。
2.2 安全模型
该方案设定为教育机构上传用户的数字文凭，原因是教育机构会生成用户的数字文凭，使用环签密签密后可直接上传。图1表示方案整个流程。
图1 方案流程
2.2.1 系统建立
该算法包括两个过程，分别为初始化参数设置以及建立辅助中心密钥。
2.2.2 密钥生成
密钥的生成算法主要有两个阶段构成：用户认证和密钥融合。
2.2.3 文凭签密
在该系统中，已经获得授权密钥的教育机构或个人用户可以进行文凭的签密操作。假设数字文凭的发送方的身份标识为ids， 即教育机构，接收方的身份标识为idr即文凭的验证者，待加密的数字文凭的内容为M∈G2。 发送方遵循如下的签密步骤来操作这些数据。
首先确定一个由发送方的标识构成的身份集合U=(id1，…，idt)，其中ids∈U包含了发送方的身份标签，发送方ids将在整个身份集的名义下生成一个经过认证的加密文本。
随后，发送方选择随机一个数k∈Zp， 并计算出加密文本R=k·P，C=M·e(k·A，H0(idr))， 均为先前确定的参数。
对于i∈{1，…，t}
2.2.4 信息上传
教育机构在通过IPFS网络上传数据之前，对数据进行签密，图2说明了数字文凭在上传到IPFS之前所经历的一系列步骤。
图2 文件上传
教育机构以IPFS对象的形式通过IPFS上传数据，该对象由数据字段和链接字段组成。数据字段由数据文件组成，链接字段由数据标识符组成。IPFS数据字段只能容纳256 kb的数据，因此，如果数据文件大于256 kb，则将其分解为多个IPFS对象，并存储在不同的节点上。
主对象由指向每个IPFS对象的链接字段组成，可用于定位其它对象并恢复数字文凭。
存储结束后，IPFS系统根据上传的IPFS对象，使用SHA2-256哈希算法对数字文凭进行哈希操作，生成一段哈希值，并返回给教育机构，教育机构到该哈希值之后，将其通过安全信道发送给用户。
教育机构在本地使用SHA-1哈希算法，求出用户的数字文凭的哈希值，得到索引值后，与用户id生成键值对，调用链码，上传至联盟链。
2.2.5 文凭获取
用户想要获得自己的数字文凭，将自己的数字文凭发送给其它机构时，需要根据自己所拥有的哈希值向IPFS系统发送一个获取数据请求。
IPFS根据用户发送过来的哈希值，根据哈希值在系统中寻找文件片，将文件片合并之后返回给查找的用户，用户拿到密文后解密。
2.2.6 文凭分享和身份验证
用户将文凭解密后，将本人的文凭通过安全信道发送给有需求的公司或者其它机构，当公司或者其它机构收到用户发来的数字文凭，并且想要验证该文凭是否属于用户，需要向联盟链发送获取用户id对应的数字文凭的哈希值的请求。
区块链根据公司或者其它机构发送过来的请求的用户id值，调用链码，返回给公司或者其它机构该用户的数字文凭的哈希值，该访问记录会存储至链上。
公司或者其它机构拿到该用户id的数字文凭的哈希值时，求出用户发送的数字文凭的哈希值，两者进行比较，若相同，则验证通过，否则，拉黑该用户。
2.3 智能合约设计
智能合约在联盟链启动时部署，可以通过智能合约上传文凭摘要、获取文凭摘要、记录用户行为，该章节中，主要介绍文中使用的智能合约和算法逻辑。智能合约使用编程语言Solidity编码。该文章设计的智能合约包括DiplomaRecord合约和BehaviorRecord合约。
2.3.1 上传文凭合约
算法1是Solidity语言的智能合约代码。定义了一个哈希表dipRec，用于存储每个用户上传的文凭记录。DipRec是一个结构体，包含了文凭的相关信息，如哈希值、索引、位置和元数据。
算法1:
Contract DiplomaRecord
Mapping(address=>DipRec[])dipRec; %定义上传文凭的哈希表
Struct DipRec{
byte hash;
byte index;
byte location;
byte metadata;
}
Function uploadRecord(index, hash, metadata)上传智能合约
Push DipRec (index, hash, location, metadata,userId)
into dipRec [userId];
uploadRecord函数是一个公开的函数，用于将文凭记录上传到智能合约。它接受3个参数：索引(index)、哈希值(hash)和元数据(metadata)。在函数内部，首先创建一个新的DipRec对象，并将传入的参数赋值给对应的字段。然后，将新的记录添加到dipRec哈希表中，使用当前用户的地址作为键。
2.3.2 获取文凭合约
算法2为getRecod函数，getRecord函数是一个公开的只读函数，用于获取指定用户的文凭记录。它接受一个地址类型的参数userId，并返回该用户的文凭记录数组。在函数内部，根据传入的userId作为键从dipRec哈希表中获取记录，并将其赋值给records数组。最后，通过return关键字返回该数组作为函数的结果。
算法2:
Contract DiplomaRecord
Mapping(address=>DipRec[])dipRec;
Struct DipRec{
byte hash;
byte index;
byte location;
byte metadata;
}
Function getRecord(userId)
Record = dipRec[userId];
Return record;
2.3.3 用户行为记录合约
算法3定义了一个名为“BehaviorRecord”的智能合约，其中包含了访问控制的功能。
算法3：
Contract BehaviorRecord
Mapping(address=>AccessStruct[]access)；%定义访问控制
Struct AccessStruct{
String txid；
Uint time；
Address requester；
}
DiplomaRecord diplomaRecord；
Function setContrat(address of DiplomaRecord)%初始化智能合约
diplomaRecord = DiplomaRecord(address of DiplomaRecord)
Function requestRecord(address，txid，location)
LogAccess(msg.sender，address，txid，location，“recorded”)
access是一个哈希表，用于存储每个地址对应的访问记录。AccessStruct结构体包含了访问记录的相关信息，如交易ID(txid)、访问时间(time)和请求者地址(requester)。
在setContract函数中，通过传入的 ofDiplomaRecord地址初始化了diplomaRecord 变量，该变量表示一个名为“DiplomaRecord”的智能合约实例。
requestRecord函数用于请求记录。它接受请求者地址(requester)、交易ID(txid)和位置(location)作为参数。首先，它将访问记录写入到access哈希表中，记录了访问者的相关信息和访问时间。接下来，它通过调用diploma-Record实例的record函数来记录访问行为，传递了交易ID和位置作为参数。
3 方案分析
3.1 安全性分析
3.1.1 隐私保护
对MLR(multimedia learning resources)所有者的数据采用环签密方案，充分保证了用户对本人数据的掌握权，再没有获得拥有着的授权的情况下，公司或者其它教育机构无法访问数据。其它教育机构访问MLR共享时，必须由拥有者发送MLR，同时公司或者其它教育机构访问联盟链的用户的MLR的哈希值，两者进行比较之后，可判断该MLR属于该用户，充分保证了数据拥有者的隐私。
3.1.2 防篡改、可溯源数据保护
该方案采用区块链技术，每一条数据记录都存储在区块链中。在数据存储阶段，对MLR进行hash计算，生成数据指纹。由于hash算法是单向的，只要数据被篡改，数据的hash值也会发生改变。在MLR分享阶段，对公司或者其它教育机构访问链上信息的记录进行留痕，数据拥有着随时可以查看数据的被访问情况。
3.1.3 保密性
在数字文凭M的安全处理方面，选用的加密协议较为关键，所用的环签密算法不仅确保了传输过程中文凭内容的保密性，还意味着在信息传递的完整路径中，每一环都不可能成为信息泄露的弱点。此类加密技术基于复杂的数学难题——BDDH假设，其不仅为数字文凭的加密提供了坚固的数学基础，而且通过随机预言机模型增加了额外的安全层。因此，通过这种环签密方案，可以确保即使是最高级别的未授权访问尝试，也无法破解加密的数字文凭，从而为数字文凭提供了一种高级的保护措施。
3.2 实验分析
在此实验研究中，审视了传统数字文凭管理策略与新提出的策略在操作效率和资源消耗方面的性能表现。旧有的处理机制要求用户进行大量的数据处理工作，包括下载、签名以及再次上传整个数据集，这不仅耗费时间，而且对网络和服务器的计算能力要求很高。相比之下，本研究提出的策略意在优化这些步骤，旨在减少数据处理的复杂性和提高效率。实验仿真环节针对两种方案在处理时间、计算需求、网络流量及存储效率等方面进行了细致的比较分析，以此来验证新策略在降低云存储系统负载和提升数据处理速度方面的有效性。表1为方案中开销所需符号。
表1 符号与含义
该文章实验在Ubuntu18.04系统下利用go语言进行编写，在Intel(R)Core(TM)i7-7700HQ @2.80 GHz CPU、16 G内存电脑上运行，使用Hyperledger Fabric1.4.2上实现并运行。进行实验的系统有两个组织，每个组织有3个peer节点和一个ca节点，系统有一个order排序节点。
图3展示了在联盟区块链环境下，整合环签名技术对于生成区块时间影响的对比研究。根据图示结果，我们可以观察到，在Hyperledger Fabric平台中引入环签密技术后，新区块的生成时间与之前未应用环签名技术时基本一致。这表明，尽管环签密技术的加入增强了系统的安全性，但其对于平台的执行效率几乎没有显著影响。因此，这一结果表明了该方案的实用性，不仅保障了数据的安全性和不可篡改性，也保持了系统的高效性。此外，该方案的应用还拓展了数字文凭共享功能的可能性，允许安全可信的文凭验证过程在保持高效的同时进行。
图3 联盟链生成区块时间
图4表示的是IPFS节点的配置信息，数字文凭上传之后会分布在各个IPFS节点上。
图4 IPFS节点配置信息
图5表示的是IPFS数据块打包完成后上传的过程。
图5 IPFS数据块打包完成
3.2.1 通信开销
方案中的通信主要集中在密钥生成中，密钥分发集群同用户的交互以及弱中心建立密钥。弱中心交互过程中，通信量为 n|s||G|， 密钥分发集群发送密钥给用户，通信量为n|G|+n|s|。
故本方案通信开销为n|G|+n|s|+n|s||G|。
3.2.2 计算开销
方案的计算开销主要集中在密钥合成的验证密钥部分，以及数据签密通信密钥合成计算量为HG|s||q|， 密钥合成计算量为 |e|+(n+1)n/2(|q|)， 签密计算量为d|q|+|z||q|+HG|s||q|+(n+1)n/2(|q|)。
故本方案计算开销为 |e|+((n+1)n+d+|z|)|q|+HG|s||q|。
3.3 方案对比
将这篇文章设计的方案与文献[3，4，16，17]构造的方案在通信、计算开销和性能方面进行比较。
本实验是将传统方案与本文方案在各项开销上进行对比。实验编程基于Python语言，并使用密码学库。实验的配置包括了对循环群的具体设定 |G|=160 bit，Zp*中元素的位长同样设定为|p|=160 bit，至于实验中所用的函数F，其设计是以产出24比特长度的输出，即F输出的位长 |TagF|=24 bit， 管理属性，即那些用于控制和管理系统行为的参数，其位长被设定为 |A(i)|=16 bit。
随着数据块数的增加，由图6(a)可以看出，数据块数的增加，本文研究提出的方法在通信成本上的优势逐渐显现，与传统方法相比有显著减少，图6(b)可以看出，数据块数量的增加使得新方法在计算成本上的效率提高更加明显，其优势也更加突出。
图6 通信与计算开销对比
表2可得，在保证匿名认证性得前提下，本方案设计的方案同时具备了签密、保密性、分布式密钥、分布式存储。因此、相对现有的同类型方案，该方案具有更好的安全性。
表2 方案对比
4 结束语
本文研究了基于联盟体链的数字文凭共享方案的隐私保护和认证问题。构建了一种安全的数字文凭共享方案，根据区块链的不可篡改性和环签密的正确性，实现了该方案中数字文凭的分布式防篡改、不可伪造和认证特性。针对数字文凭的集中存储方式容易被篡改和破坏的问题，提出了一种分布式文件存储系统——星际文件存储系统来存储加密的数字文凭。此外，该方案采用了与分布式密钥生成技术相的融合，有效规避了单点故障点的问题，并增强了方案抵抗多密钥管理中心合谋攻击的能力。
