基于联盟链的跨域认证方案

牛建林，任志宇，杜学绘

（信息工程大学，河南 郑州 450001）

0 引言

跨域认证一直是网络安全界尤为关注的问题。尽管目前有许多关于跨域访问的解决方案，不同信任域的不同设备可以很容易地在当前网络框架下互联，但是仍有许多信任与安全的问题尚待解决。目前，多数认证的解决方案是基于公钥基础设施（PKI，public key infrastructure）[1]的。在PKI中，引入证书权威机构（CA，certificate authority）作为可信第三方（TTP，trusted third party）。随着实体的数目增加，伴随而来的大量证书的管理，给系统带来了不小的负担。此外，PKI体系面临诸多风险，尤其是CA易受到攻击[2]。近几年由于误操作导致的CA泄露事件也层出不穷[3]。传统的跨域解决方案过度依赖于可信第三方，导致敏感数据被集中地存储起来。被集中存储的海量敏感数据对攻击者而言也是个不小的诱惑。

联盟链（consortium blockchain）是一种准入型区块链[4]。它有保存着分布式账本的多个节点，但是每个节点必须得到验证后才能加入联盟链。联盟链保留着公有链的诸多特性，如能够建立节点间信任、链上数据不易篡改等。此外，相较于公有链，联盟链具有交易速度更快、能够更好保护数据隐私等特性，已在解决多方信任问题中得到一些应用[5]。联盟链通过密码学算法建立分布式账本，具有“组织”的概念，这与跨域认证场景中“域”的概念是相契合的。相较传统的引入多中心的方法而言，它具有防篡改、便于审计等优势。因此，借助联盟链的这些特性来解决跨域认证中的域间信任问题，不失为一种好的方法。

基于身份的密码体制（IBC，identity-based cryptography）方案可以有效规避证书管理等方面的问题，自Shamir[6]提出IBC后，2001年，Boneh等[7]提出了更为实用的身份加密方案，他们利用双线性映射完成了基于身份的加密和签名。此后，有不少学者基于IBC针对跨域认证问题提出了解决方案。彭华熹[8]提出一种基于IBC的跨域认证方案，但由于其中存在大量的双线性映射的运算，并不适合轻量化的场景使用。Bellare等[9]利用椭圆曲线加法群提出了一种基于身份的签名算法，避免了复杂的双线性对运算，提高了基于身份的认证效率。罗长远等[10]在此基础上，改进了验证部分，并证明了其安全性。Yuan等[11]提出一种跨IBC和PKI域的EIMAKP方案，但计算负载和通信负载较大。

随着区块链技术研究的发展，基于区块链的跨域认证方案被提出。周致成等[12]设计了一种基于区块链的PKI跨域认证方案。马晓婷等[13]据此设计了一种基于联盟链的跨异构域认证方案，有效降低了计算和通信负载，但在实际上仍旧是基于证书体系的认证方案，且未对链上读写性能进行分析。Shen等[14]将联盟链与IBC结合，提出了针对工业物联网的跨域认证方案。

基于此，本文将改进的IBC体制与联盟链结合，提出一种新的方法来解决跨域认证的问题。但这样的结合会引发出一些新的问题待解决，面临的挑战如下。

1) 区块链的可存储数据限制。由于写入链上数据需要共识，且账本在每个节点上都有一份副本。倘若存储的数据过大，必然导致链上写入时延过大和数据冗余[15]。

2) IBC中的身份注销问题。由于IBC中身份由用户自己定义，因此身份注册后如何将其注销是一个需要解决的问题。

3) 身份隐私的保护。链上信息公开，若身份信息完全不加以处理地上链，则其隐私无法得到保护。

4) 匿名身份难以监管。对身份进行匿名后，虽然隐私受到保护，但存在匿名身份难以监管的问题。

为解决上述问题和应对这些挑战，本文提出了一种基于联盟链的跨域认证方法。本文工作和创新点如下。

1) 针对跨域应用场景，设计身份认证和密钥协商方案。

2) 设计了一种身份管理方法，解决IBC中身份难以注销的问题和匿名身份难以监管的问题。

3) 针对链上的存储限制，基于IPFS提出一种安全可靠的分布式链下存储方案。

1 跨域认证方案设计

本节介绍跨域认证方案的细节。在跨域认证场景中假定有两个安全域，分别为域A和域B，如图1所示。

图1 跨域认证场景Figure 1 A cross-domain authentication scenario

1.1 整体架构

本文方案使用联盟链为不同的安全域构建信任关系，避免了可信第三方的引入。在进行跨域认证时，联盟链能够保证各个域数据的一致性，且能够成为跨域认证的可信数据共享平台。

本文的跨域认证方案使用多中心的方式，缓解了在进行跨域访问时只有一个认证中心的密钥托管和单点失效等问题。对于域内访问，本文方案并未解决中心化带来的问题，如域内只有一个KGC导致的密钥托管问题和单点失效问题。但如果在域内设置多个中心，必然导致计算负载急剧上升。目前的方案是在安全性与可用性之间进行折中的结果。

整个方案分为4层架构[14]，分别为：实体层、代理层、区块链层和存储层。整体架构如图2所示。

图2 认证方案架构Figure 2 Architecture of authentication scheme

（1）实体层

实体层包含用户客户端、服务提供者（SP，service provider）、认证服务器（AS，authentication server）和KGC。用户客户端主要是用户用于访问服务的设备，如计算机、手持终端设备等。它们的主要行为是访问服务和在需要认证时请求KGC为自己生成密钥。SP是各个域中的服务提供商，为用户提供资源访问服务。在一个域中，只有一个KGC，它为本域内的用户和SP生成认证所需的私钥。在认证过程中，KGC与认证服务器和区块链代理服务器一起完成认证的工作。在认证的过程中，还需要进行签名和验签的工作，这些工作同样在KGC服务器上完成，在图中将两者分立开来是为了更清楚地表示它们的分工关系。为便于区分，本文将用户归属域的认证服务器称为HAS（home authentication server），将跨域访问目标域的认证服务器称为FAS（foreign authentication server）。

（2）代理层

在代理层设区块链代理服务器（BAS，blockchain agent server）。在每个域中，需要设置一个联盟链的节点用于维护全局账本。这个节点在本域的信息进行变更时需要将新的域信息写入区块链，在认证其他域的实体的访问信息时查询此域的链上信息。倘若这些工作全由KGC完成，势必给KGC服务器带来较大负担。因此，需要引入BAS单独完成读写链上数据的任务。

（3）区块链层

在区块链层，本文方案使用联盟链作为其底层架构。各个域的信息将存储于联盟链。在认证过程中，不同的域根据域ID向联盟链查询相关安全域的数据。可以预见的是，域内信息的数据量会比较大。由于区块链中存储较大的数据量必然导致交易时延过大以致不可接受，所以选择将数据的摘要存储于链上，具体域内的数据信息则存储于存储层。

链上存储的域内信息数据以Key-Value的形式进行存储，数据存储格式如图3所示。

图3 链上数据存储格式Figure 3 Data field on blockchain

IDdomain是安全域的唯一标识符。Addripfs是数据在IPFS上的地址。由于IPFS是一种基于内容寻址的方式，文件系统根据文件的摘要生成其唯一的地址。这样设计，既保证了链上数据不至于过大，又避免了文件被篡改。

（4）存储层

实际的域内信息数据被存储于一个JSON文件。域内信息包括安全域的名称、域内主要公开的系统参数、域内主公钥和域内实体的公钥列表。这个公钥列表中存储的是临时身份，用于跨域认证。这个JSON文件将被存储于区块链外的IPFS[16]存储系统。IPFS是一种基于内容寻址的系统，它将文件内容经过摘要算法和编码算法计算得到一个唯一的地址。若文件被修改，此地址将发生巨大变化。这种在链上存储IPFS地址信息、在IPFS中存储实际数据的方式，能够防篡改和突破链上存储限制。

1.2 身份管理方案

由上文可知，IBC方案将用户的身份作为用于认证的公钥。在此，提出永久的自主权身份和临时身份。永久的自主权身份由用户自主控制，而临时身份的有效期很短，用于跨域认证时使用。

1) 永久的自主权身份。用户在加入这个安全域时，先向KGC进行注册。出于隐私保护的考虑，将身份属性信息的摘要存储于链上，身份信息数据存储于用户自己的设备。一旦注册，用户拥有对身份数据的完全控制权。KGC根据这个身份对用户进行管理。用户也可以根据需要，自主选择是否向SP披露个人属性信息以及披露多少信息。

2) 临时身份。用户设备生成随机数N，再将此随机数与永久身份结合发送给KGC。KGC在其后面加上身份期限再用监管公钥对其加密，生成临时身份公钥。KGC再根据此身份公钥生成私钥。例如，用户生成随机数N来构造临时身份，KGC据此生成公钥，其中PKs为监管公钥，PK为永久公钥，Te为过期时间。若需要监管，则监管方通过监管私钥解密，可恢复出临时身份对应的永久身份，达到监管和审计的目的。随后，生成私钥sktemp。临时身份有效时间较短，可根据具体安全需求来确定（如7天）。

1.3 基于身份的密码体制

考虑将标识密码算法应用于本文方案，但由于此方案引入区块链代理和临时身份，需要在密钥生成阶段对此算法加以改进。

系统初始化：KGC生成的系统参数包括椭圆曲线识别符cid，椭圆曲线基域Fq的参数；椭圆曲线方程参数a和b；扭曲线参数β；曲线阶的素因子N和相对于N的余因子cf；曲线E(Fq)相对于N的嵌入次数k；(d1整除k)的N阶循环子群G1的生成元P1；(d2整除k)的N阶循环子群G2的生成元P2；双线性对e的识别符eid；同态映射ψ:G2→G1；双线性对e的值域为N阶乘法循环群G1×G2→GT；签名私钥生成函数识别符hid。

产生私钥：KGC先选择签名主私钥ks∈[1,N−1]，随后计算签名主公钥Ppub-s=[ks]P2，其中Ppub-s∈G2，KGC妥善秘密保管ks，公开Ppub-s。假设用户A的标识为IDA，生成临时公钥，KGC计算t1=H1⋅ (PKtemp-A||hid,N)+ks。若t1≠0，计算用户私钥，否则，重新产生签名主私钥，计算公开Ppub-s，并将已有用户的私钥全部更新。

参数公开与链上存储：将生成的系统参数与更新后的PKtemp列表存储至IPFS文件系统，并将此IPFS地址与本域ID打包发送至BAS以存储于链上。

1.4全认证

全认证包括临时身份生成和跨域认证（如图4所示）两个阶段。做以下规定：[M]Alice表示使用Alice私钥进行的签名；{M}Alice表示使用Alice公钥加密的信息。

图4 跨域认证过程Figure 4 Cross-domain authentication process

（1）临时身份生成阶段

域A中的用户UA需要首先确认自己的临时身份是否过期。若过期，按照身份管理方案重新生成临时身份IDtemp-A。UA生成随机数N，向HAS发送请求，申请临时身份。HAS收到后，若消息新鲜，则验证身份，并请求KGC根据私钥生成规则生成公私钥对(PKtemp-A,sktemp-A)。

HAS生成公私钥对后，更新存储本域信息的JSON文件，重新存储于IPFS，并向BASA发送请求，将新生成的IPFS地址更新至链上。HAS将更新后的文件信息通过更新接口update()写入联盟链分布式账本中。

得到部署成功的信息之后，BASA将给HAS发送是否成功信息。

HAS收到链上写入数据成功的消息后，给UA秘密发送公私钥对(PKtemp-A,sktemp-A)。

（2）跨域认证阶段

UA生成随机数N，构造消息5text。将构造的消息进行签名后加密发送至SPB，随后转发至FAS。其中，ext为扩展字段，可以用来传递扩展信息或者密钥协商信息。

FAS收到UA的认证请求后，根据IDdomain向BASB发送链上查询请求。

BASB将查询到的域A的地址发送给FAS。FAS随后根据IPFS地址去获取域内信息。随后根据获得的A域的信息，验证UA的签名。若验证通过，FAS中建立临时账户记录。此账户供将来重认证时使用。lifetime为此账户的有效期，其值可以根据安全需要设定，若超过此有效期，FAS删除此账户记录。

FAS验证通过后，向UA发送验证成功信息。其中，为用户的身份索引，UA将以此作为之后重认证的凭证。

1.5 重认证

在身份有效期内，用户再次访问域B中的资源提供者SPB。此时可以直接通过FAS对用户快速认证。重认证过程如下。

用户生成随机数N与自己的身份索引和扩展信息，扩展信息中包含协商密钥。将上述信息使用临时身份密钥进行签名后，秘密发送给FAS。FAS根据身份索引查找本地记录，若查到，则根据此用户记录和本地数据库中域A的系统参数，对用户进行验证。若存在用户记录和签名验证成功，通过用户认证。

FAS向SPB发送包含协商密钥的扩展信息，SPB生成自己的协商密钥，随后计算会话密钥。

SPB将自己生成的协商密钥放于3ext'，发送给FAS。

FAS向UA发送验证成功信息和包含密钥协商信息的扩展信息。UA根据此计算会话密钥。

至此重认证过程结束。

1.6 密钥协商

用户访问资源服务时需要通过加密来保证信息传输的安全，但为了传输效率，不可能使用非对称的加密方式。因此，需要通过协商会话的对称加密密钥，保证信息传输安全和完全正向保密（PFS，perfect forward secrecy）。在此，使用短时Diffie-Hellman体制进行密钥交换。

以用户UA和SPB典型的密钥交换过程为例，基本过程如下：UA选择自己的秘密指数a，SPB选择自己的秘密指数b，UA发送gamodp给SPB，SPB发送gbmodp给UA。最终双方分别计算后，协商出共享的会话密钥Ks=gabmodp。

通常，上述的短时Diffie-Hellman体制极易遭到中间人攻击，所以将此密钥协商过程放在认证过程中进行。可以将上述信息放至扩展信息ext中，以满足对安全性的需求。

2 安全性分析

2.1 协议的安全性证明

SVO逻辑属于BAN类逻辑，是一种较为成熟可靠的形式化分析工具[17]。本节基于SVO逻辑，对协议进行形式化证明。在SVO逻辑中，证明分为初始假设、协议目标和协议分析3个部分。

（1）基本公理

这里仅列举本文在证明此协议安全性时涉及的基本公理[18]。

（2）初始假设

H1. 系统初始化已经完毕，且各个域的实体已经完成认证，拥有公私钥。

H2. 联盟链中节点间是可信的。

（3）协议目标

（4）协议分析

Step 1由Msg1和假设H1、H3、H4、H5、公理A3，可得

Step 2由Msg2、Msg3和R1，根据假设H2、H6、H7，可得

Step 3根据Msg4，由假设H3、H4、H5，结合R2，利用公理A4，可得

Step 4根据Msg6、Msg7，由假设H8、H9，结合R3，利用公理A5，可得

此时达到协议目标G3。

Step 5利用R3、R4结论，FAS利用查询得到的信息，对AU签名进行验证，由假设H10、H11，利用公理A1、A4，可得

此时达到协议目标G1。

Step 6利用Msg8，由假设H8，公理A5，可得

此时达到协议目标G2。

至此已达到所有协议目标。

2.2 安全属性分析

（1）协议安全性

在构建信任方面，本文方案通过联盟链这种可准入链的方式为不同安全域的实体建立信任。经过SVO证明，表明协议是安全的。另外使用的密钥协商方案在认证建立时进行密钥协商，使用短时密钥协商，保证了完全正向保密安全。

（2）抗重放攻击

在认证过程中，使用随机数来保证消息新鲜。即使消息被敌手从中间截获，也会由于消息不具有实效性而导致认证失败。这样能够有效阻止攻击者通过重放来进行攻击。

（3）抗中间人攻击

在认证过程中，实体之间的重要消息通过先签名后加密的方式进行传输。签名不可伪造。信道中的攻击者若对消息篡改，将使验签无法通过。通过此方法，有效地阻止了中间人攻击。

（4）身份匿名性

在此方案中，认证时使用的是临时身份。临时身份生成的过程使身份具有一定的匿名性，而且一段时间后，身份将不再可用，避免了身份被恶意跟踪，保证了一定限度上的身份匿名性。

（5）可审计

在身份管理方案中，加入了可监管公私钥，在发生恶意事件时，可对身份信息和身份的行为进行监管和审计。

3 性能分析

3.1 负载性能分析

为合理地比较本文方案与其他方案的性能，参考Kilinc等[19]的实验，对运算时间进行模拟分析。其实验环境为：Intel Pentium Dual CPU E2200 2.2 GHz, 2048 MB RAM, Ubuntu 12.04.1 LTS 32 bit操作系统。

在签名方案中，设置参数如下。

使用256 bit的BN曲线，椭圆曲线方程

基域特征p(t)=36t4+36t3+24t2+6t+1

群的阶N(t)=36t4+36t3+18t2+6t+1

嵌入次数k=12

（1）计算负载

在认证过程中，实体会执行相关的密码学算法运算。做以下规定：公钥加密为PE，公钥解密为PD，非对称签名AS，非对称验签AV，点乘PM，选择随机数RNG，基于身份签名IBS，基于身份验签IBV，密码杂凑算法H。

根据认证过程，统计分析得出从临时身份获取到密钥协商的总计算负载如表1所示。

表1 计算负载Table 1 Computation overhead

为进一步评价本协议的计算量，将本文方案的跨域协议计算负载与其他方案进行比较，如表2所示。在不同用户数时，不同方案的耗时对比如图5和图6所示。对比分析发现，本文协议用户端上的计算负载表现与文献[13]方案基本相同，优于文献[10]方案和文献[12]方案；在服务端，略优于文献[10]方案，明显好于文献[12]方案和文献[13]方案。

图5 用户端耗时比较Figure 5 Time-consuming on user-side

图6 服务端耗时比较Figure 6 Time-consuming on server-side

表2 计算负载比较Table 2 Comparison of computation overhead

（2）通信负载

这一部分评估了本文方案认证过程中的通信负载。

在本文方案中，用户的临时身份大小为32 byte，随机数为2 byte，扩展信息为32 byte，签名后的签名信息为96 byte。据此推算，UA首先向FAS发送了82 byte的验证请求信息，FAS查询BASB的通信过程为66 byte，最后UA收到的认证结果信息为52 byte。统计上述负载，可以得到在认证过程的通信总负载为296 byte。

相较于文献[13]方案（通信负载为130 byte），本方文案有较大的通信负载，但明显低于文献[12]方案（通信负载为340 byte），因此本文方案在通信效率上是较高的。

3.2 联盟链性能分析

本文方案基于联盟链构建信任关系。在认证过程中，需要向链中写入和查询认证相关信息。因此，在联盟链中，写入和查询参数是一个对可用性影响比较大的指标。为评估本文方案的可用性，借助Hyperledger-Caliper，对Hyperledger Fabric的读写性能进行测试和分析。实验环境为：Intel Core i5 7500@3.4 GHz CPU；8 GB RAM; Ubuntu 18.04 LTS操作系统。

测试后的结果如图7和图8所示。易见，并发数对query操作时延的影响不大。query操作的时延总是在极低的水平，基本在10 ms以内。因为在区块链中进行query操作时，会从本地存储的账本中直接读取数据，基本上没有时间上的损耗，所以query操作的时延能够如此之低。然而写操作的时延是随着并发数的增加不断增加的。并发数超过50时，时延开始增加得非常迅速。在并发数为100时，时延达到5 s。得到这个结果也是意料之中的，因为随着并发数的增加，共识的压力在逐步增大，最终导致写时延增加。在本文方案中，write操作只有在生成临时身份时才存在，操作并不频繁，时延能够满足需求。以上结果表明，联盟链在时延表现方面，具有良好的可用性。

图7 链上query操作时延Figure 7 Query latency on blockchain

图8 链上write操作时延Figure 8 Write latency on blockchain

4 结束语

针对目前跨域认证的依赖可信第三方、域间不易建立信任的安全难题，本文参考IBC体制，提出了一种基于联盟链的跨域认证机制。针对跨域场景，本文设计了包括全认证和重认证在内的跨域认证协议和密钥协商方案；设计了一套身份管理方法，在保证身份匿名性的同时，确保用户行为可监管、可审计。针对区块链的数据存储限制，本文结合IPFS提出了一种链下分布式认证信息数据存储方案。最后，使用SVO逻辑对认证协议的安全性进行了证明，表明其具有良好的安全性。分析了计算负载和通信负载，与现有的相关方案相比，有较低的计算负载和良好的通信负载。测试了联盟链的性能，分析表明，在时延表现方面，其具有良好的可用性。