牛建林，任志宇，杜學(xué)繪

（信息工程大學(xué)，河南 鄭州 450001）

0 引言

跨域認(rèn)證一直是網(wǎng)絡(luò)安全界尤為關(guān)注的問題。盡管目前有許多關(guān)于跨域訪問的解決方案，不同信任域的不同設(shè)備可以很容易地在當(dāng)前網(wǎng)絡(luò)框架下互聯(lián)，但是仍有許多信任與安全的問題尚待解決。目前，多數(shù)認(rèn)證的解決方案是基于公鑰基礎(chǔ)設(shè)施（PKI，public key infrastructure）[1]的。在PKI中，引入證書權(quán)威機構(gòu)（CA，certificate authority）作為可信第三方（TTP，trusted third party）。隨著實體的數(shù)目增加，伴隨而來的大量證書的管理，給系統(tǒng)帶來了不小的負(fù)擔(dān)。此外，PKI體系面臨諸多風(fēng)險，尤其是CA易受到攻擊[2]。近幾年由于誤操作導(dǎo)致的CA泄露事件也層出不窮[3]。傳統(tǒng)的跨域解決方案過度依賴于可信第三方，導(dǎo)致敏感數(shù)據(jù)被集中地存儲起來。被集中存儲的海量敏感數(shù)據(jù)對攻擊者而言也是個不小的誘惑。

聯(lián)盟鏈（consortium blockchain）是一種準(zhǔn)入型區(qū)塊鏈[4]。它有保存著分布式賬本的多個節(jié)點，但是每個節(jié)點必須得到驗證后才能加入聯(lián)盟鏈。聯(lián)盟鏈保留著公有鏈的諸多特性，如能夠建立節(jié)點間信任、鏈上數(shù)據(jù)不易篡改等。此外，相較于公有鏈，聯(lián)盟鏈具有交易速度更快、能夠更好保護數(shù)據(jù)隱私等特性，已在解決多方信任問題中得到一些應(yīng)用[5]。聯(lián)盟鏈通過密碼學(xué)算法建立分布式賬本，具有“組織”的概念，這與跨域認(rèn)證場景中“域”的概念是相契合的。相較傳統(tǒng)的引入多中心的方法而言，它具有防篡改、便于審計等優(yōu)勢。因此，借助聯(lián)盟鏈的這些特性來解決跨域認(rèn)證中的域間信任問題，不失為一種好的方法。

基于身份的密碼體制（IBC，identity-based cryptography）方案可以有效規(guī)避證書管理等方面的問題，自Shamir[6]提出IBC后，2001年，Boneh等[7]提出了更為實用的身份加密方案，他們利用雙線性映射完成了基于身份的加密和簽名。此后，有不少學(xué)者基于IBC針對跨域認(rèn)證問題提出了解決方案。彭華熹[8]提出一種基于IBC的跨域認(rèn)證方案，但由于其中存在大量的雙線性映射的運算，并不適合輕量化的場景使用。Bellare等[9]利用橢圓曲線加法群提出了一種基于身份的簽名算法，避免了復(fù)雜的雙線性對運算，提高了基于身份的認(rèn)證效率。羅長遠(yuǎn)等[10]在此基礎(chǔ)上，改進了驗證部分，并證明了其安全性。Yuan等[11]提出一種跨IBC和PKI域的EIMAKP方案，但計算負(fù)載和通信負(fù)載較大。

隨著區(qū)塊鏈技術(shù)研究的發(fā)展，基于區(qū)塊鏈的跨域認(rèn)證方案被提出。周致成等[12]設(shè)計了一種基于區(qū)塊鏈的PKI跨域認(rèn)證方案。馬曉婷等[13]據(jù)此設(shè)計了一種基于聯(lián)盟鏈的跨異構(gòu)域認(rèn)證方案，有效降低了計算和通信負(fù)載，但在實際上仍舊是基于證書體系的認(rèn)證方案，且未對鏈上讀寫性能進行分析。Shen等[14]將聯(lián)盟鏈與IBC結(jié)合，提出了針對工業(yè)物聯(lián)網(wǎng)的跨域認(rèn)證方案。

基于此，本文將改進的IBC體制與聯(lián)盟鏈結(jié)合，提出一種新的方法來解決跨域認(rèn)證的問題。但這樣的結(jié)合會引發(fā)出一些新的問題待解決，面臨的挑戰(zhàn)如下。

1) 區(qū)塊鏈的可存儲數(shù)據(jù)限制。由于寫入鏈上數(shù)據(jù)需要共識，且賬本在每個節(jié)點上都有一份副本。倘若存儲的數(shù)據(jù)過大，必然導(dǎo)致鏈上寫入時延過大和數(shù)據(jù)冗余[15]。

2) IBC中的身份注銷問題。由于IBC中身份由用戶自己定義，因此身份注冊后如何將其注銷是一個需要解決的問題。

3) 身份隱私的保護。鏈上信息公開，若身份信息完全不加以處理地上鏈，則其隱私無法得到保護。

4) 匿名身份難以監(jiān)管。對身份進行匿名后，雖然隱私受到保護，但存在匿名身份難以監(jiān)管的問題。

為解決上述問題和應(yīng)對這些挑戰(zhàn)，本文提出了一種基于聯(lián)盟鏈的跨域認(rèn)證方法。本文工作和創(chuàng)新點如下。

1) 針對跨域應(yīng)用場景，設(shè)計身份認(rèn)證和密鑰協(xié)商方案。

2) 設(shè)計了一種身份管理方法，解決IBC中身份難以注銷的問題和匿名身份難以監(jiān)管的問題。

3) 針對鏈上的存儲限制，基于IPFS提出一種安全可靠的分布式鏈下存儲方案。

1 跨域認(rèn)證方案設(shè)計

本節(jié)介紹跨域認(rèn)證方案的細(xì)節(jié)。在跨域認(rèn)證場景中假定有兩個安全域，分別為域A和域B，如圖1所示。

圖1 跨域認(rèn)證場景Figure 1 A cross-domain authentication scenario

1.1 整體架構(gòu)

本文方案使用聯(lián)盟鏈為不同的安全域構(gòu)建信任關(guān)系，避免了可信第三方的引入。在進行跨域認(rèn)證時，聯(lián)盟鏈能夠保證各個域數(shù)據(jù)的一致性，且能夠成為跨域認(rèn)證的可信數(shù)據(jù)共享平臺。

本文的跨域認(rèn)證方案使用多中心的方式，緩解了在進行跨域訪問時只有一個認(rèn)證中心的密鑰托管和單點失效等問題。對于域內(nèi)訪問，本文方案并未解決中心化帶來的問題，如域內(nèi)只有一個KGC導(dǎo)致的密鑰托管問題和單點失效問題。但如果在域內(nèi)設(shè)置多個中心，必然導(dǎo)致計算負(fù)載急劇上升。目前的方案是在安全性與可用性之間進行折中的結(jié)果。

整個方案分為4層架構(gòu)[14]，分別為：實體層、代理層、區(qū)塊鏈層和存儲層。整體架構(gòu)如圖2所示。

圖2 認(rèn)證方案架構(gòu)Figure 2 Architecture of authentication scheme

（1）實體層

實體層包含用戶客戶端、服務(wù)提供者（SP，service provider）、認(rèn)證服務(wù)器（AS，authentication server）和KGC。用戶客戶端主要是用戶用于訪問服務(wù)的設(shè)備，如計算機、手持終端設(shè)備等。它們的主要行為是訪問服務(wù)和在需要認(rèn)證時請求KGC為自己生成密鑰。SP是各個域中的服務(wù)提供商，為用戶提供資源訪問服務(wù)。在一個域中，只有一個KGC，它為本域內(nèi)的用戶和SP生成認(rèn)證所需的私鑰。在認(rèn)證過程中，KGC與認(rèn)證服務(wù)器和區(qū)塊鏈代理服務(wù)器一起完成認(rèn)證的工作。在認(rèn)證的過程中，還需要進行簽名和驗簽的工作，這些工作同樣在KGC服務(wù)器上完成，在圖中將兩者分立開來是為了更清楚地表示它們的分工關(guān)系。為便于區(qū)分，本文將用戶歸屬域的認(rèn)證服務(wù)器稱為HAS（home authentication server），將跨域訪問目標(biāo)域的認(rèn)證服務(wù)器稱為FAS（foreign authentication server）。

（2）代理層

在代理層設(shè)區(qū)塊鏈代理服務(wù)器（BAS，blockchain agent server）。在每個域中，需要設(shè)置一個聯(lián)盟鏈的節(jié)點用于維護全局賬本。這個節(jié)點在本域的信息進行變更時需要將新的域信息寫入?yún)^(qū)塊鏈，在認(rèn)證其他域的實體的訪問信息時查詢此域的鏈上信息。倘若這些工作全由KGC完成，勢必給KGC服務(wù)器帶來較大負(fù)擔(dān)。因此，需要引入BAS單獨完成讀寫鏈上數(shù)據(jù)的任務(wù)。

（3）區(qū)塊鏈層

在區(qū)塊鏈層，本文方案使用聯(lián)盟鏈作為其底層架構(gòu)。各個域的信息將存儲于聯(lián)盟鏈。在認(rèn)證過程中，不同的域根據(jù)域ID向聯(lián)盟鏈查詢相關(guān)安全域的數(shù)據(jù)。可以預(yù)見的是，域內(nèi)信息的數(shù)據(jù)量會比較大。由于區(qū)塊鏈中存儲較大的數(shù)據(jù)量必然導(dǎo)致交易時延過大以致不可接受，所以選擇將數(shù)據(jù)的摘要存儲于鏈上，具體域內(nèi)的數(shù)據(jù)信息則存儲于存儲層。

鏈上存儲的域內(nèi)信息數(shù)據(jù)以Key-Value的形式進行存儲，數(shù)據(jù)存儲格式如圖3所示。

圖3 鏈上數(shù)據(jù)存儲格式Figure 3 Data field on blockchain

IDdomain是安全域的唯一標(biāo)識符。Addripfs是數(shù)據(jù)在IPFS上的地址。由于IPFS是一種基于內(nèi)容尋址的方式，文件系統(tǒng)根據(jù)文件的摘要生成其唯一的地址。這樣設(shè)計，既保證了鏈上數(shù)據(jù)不至于過大，又避免了文件被篡改。

（4）存儲層

實際的域內(nèi)信息數(shù)據(jù)被存儲于一個JSON文件。域內(nèi)信息包括安全域的名稱、域內(nèi)主要公開的系統(tǒng)參數(shù)、域內(nèi)主公鑰和域內(nèi)實體的公鑰列表。這個公鑰列表中存儲的是臨時身份，用于跨域認(rèn)證。這個JSON文件將被存儲于區(qū)塊鏈外的IPFS[16]存儲系統(tǒng)。IPFS是一種基于內(nèi)容尋址的系統(tǒng)，它將文件內(nèi)容經(jīng)過摘要算法和編碼算法計算得到一個唯一的地址。若文件被修改，此地址將發(fā)生巨大變化。這種在鏈上存儲IPFS地址信息、在IPFS中存儲實際數(shù)據(jù)的方式，能夠防篡改和突破鏈上存儲限制。

1.2 身份管理方案

由上文可知，IBC方案將用戶的身份作為用于認(rèn)證的公鑰。在此，提出永久的自主權(quán)身份和臨時身份。永久的自主權(quán)身份由用戶自主控制，而臨時身份的有效期很短，用于跨域認(rèn)證時使用。

1) 永久的自主權(quán)身份。用戶在加入這個安全域時，先向KGC進行注冊。出于隱私保護的考慮，將身份屬性信息的摘要存儲于鏈上，身份信息數(shù)據(jù)存儲于用戶自己的設(shè)備。一旦注冊，用戶擁有對身份數(shù)據(jù)的完全控制權(quán)。KGC根據(jù)這個身份對用戶進行管理。用戶也可以根據(jù)需要，自主選擇是否向SP披露個人屬性信息以及披露多少信息。

2) 臨時身份。用戶設(shè)備生成隨機數(shù)N，再將此隨機數(shù)與永久身份結(jié)合發(fā)送給KGC。KGC在其后面加上身份期限再用監(jiān)管公鑰對其加密，生成臨時身份公鑰。KGC再根據(jù)此身份公鑰生成私鑰。例如，用戶生成隨機數(shù)N來構(gòu)造臨時身份，KGC據(jù)此生成公鑰，其中PKs為監(jiān)管公鑰，PK為永久公鑰，Te為過期時間。若需要監(jiān)管，則監(jiān)管方通過監(jiān)管私鑰解密，可恢復(fù)出臨時身份對應(yīng)的永久身份，達(dá)到監(jiān)管和審計的目的。隨后，生成私鑰sktemp。臨時身份有效時間較短，可根據(jù)具體安全需求來確定（如7天）。

1.3 基于身份的密碼體制

考慮將標(biāo)識密碼算法應(yīng)用于本文方案，但由于此方案引入?yún)^(qū)塊鏈代理和臨時身份，需要在密鑰生成階段對此算法加以改進。

系統(tǒng)初始化：KGC生成的系統(tǒng)參數(shù)包括橢圓曲線識別符cid，橢圓曲線基域Fq的參數(shù)；橢圓曲線方程參數(shù)a和b；扭曲線參數(shù)β；曲線階的素因子N和相對于N的余因子cf；曲線E(Fq)相對于N的嵌入次數(shù)k；(d1整除k)的N階循環(huán)子群G1的生成元P1；(d2整除k)的N階循環(huán)子群G2的生成元P2；雙線性對e的識別符eid；同態(tài)映射ψ:G2→G1；雙線性對e的值域為N階乘法循環(huán)群G1×G2→GT；簽名私鑰生成函數(shù)識別符hid。

產(chǎn)生私鑰：KGC先選擇簽名主私鑰ks∈[1,N?1]，隨后計算簽名主公鑰Ppub-s=[ks]P2，其中Ppub-s∈G2，KGC妥善秘密保管ks，公開Ppub-s。假設(shè)用戶A的標(biāo)識為IDA，生成臨時公鑰，KGC計算t1=H1? (PKtemp-A||hid,N)+ks。若t1≠0，計算用戶私鑰，否則，重新產(chǎn)生簽名主私鑰，計算公開Ppub-s，并將已有用戶的私鑰全部更新。

參數(shù)公開與鏈上存儲：將生成的系統(tǒng)參數(shù)與更新后的PKtemp列表存儲至IPFS文件系統(tǒng)，并將此IPFS地址與本域ID打包發(fā)送至BAS以存儲于鏈上。

1.4全認(rèn)證

全認(rèn)證包括臨時身份生成和跨域認(rèn)證（如圖4所示）兩個階段。做以下規(guī)定：[M]Alice表示使用Alice私鑰進行的簽名；{M}Alice表示使用Alice公鑰加密的信息。

圖4 跨域認(rèn)證過程Figure 4 Cross-domain authentication process

（1）臨時身份生成階段

域A中的用戶UA需要首先確認(rèn)自己的臨時身份是否過期。若過期，按照身份管理方案重新生成臨時身份IDtemp-A。UA生成隨機數(shù)N，向HAS發(fā)送請求，申請臨時身份。HAS收到后，若消息新鮮，則驗證身份，并請求KGC根據(jù)私鑰生成規(guī)則生成公私鑰對(PKtemp-A,sktemp-A)。

HAS生成公私鑰對后，更新存儲本域信息的JSON文件，重新存儲于IPFS，并向BASA發(fā)送請求，將新生成的IPFS地址更新至鏈上。HAS將更新后的文件信息通過更新接口update()寫入聯(lián)盟鏈分布式賬本中。

得到部署成功的信息之后，BASA將給HAS發(fā)送是否成功信息。

HAS收到鏈上寫入數(shù)據(jù)成功的消息后，給UA秘密發(fā)送公私鑰對(PKtemp-A,sktemp-A)。

（2）跨域認(rèn)證階段

UA生成隨機數(shù)N，構(gòu)造消息5text。將構(gòu)造的消息進行簽名后加密發(fā)送至SPB，隨后轉(zhuǎn)發(fā)至FAS。其中，ext為擴展字段，可以用來傳遞擴展信息或者密鑰協(xié)商信息。

FAS收到UA的認(rèn)證請求后，根據(jù)IDdomain向BASB發(fā)送鏈上查詢請求。

BASB將查詢到的域A的地址發(fā)送給FAS。FAS隨后根據(jù)IPFS地址去獲取域內(nèi)信息。隨后根據(jù)獲得的A域的信息，驗證UA的簽名。若驗證通過，F(xiàn)AS中建立臨時賬戶記錄。此賬戶供將來重認(rèn)證時使用。lifetime為此賬戶的有效期，其值可以根據(jù)安全需要設(shè)定，若超過此有效期，F(xiàn)AS刪除此賬戶記錄。

FAS驗證通過后，向UA發(fā)送驗證成功信息。其中，為用戶的身份索引，UA將以此作為之后重認(rèn)證的憑證。

1.5 重認(rèn)證

在身份有效期內(nèi)，用戶再次訪問域B中的資源提供者SPB。此時可以直接通過FAS對用戶快速認(rèn)證。重認(rèn)證過程如下。

用戶生成隨機數(shù)N與自己的身份索引和擴展信息，擴展信息中包含協(xié)商密鑰。將上述信息使用臨時身份密鑰進行簽名后，秘密發(fā)送給FAS。FAS根據(jù)身份索引查找本地記錄，若查到，則根據(jù)此用戶記錄和本地數(shù)據(jù)庫中域A的系統(tǒng)參數(shù)，對用戶進行驗證。若存在用戶記錄和簽名驗證成功，通過用戶認(rèn)證。

FAS向SPB發(fā)送包含協(xié)商密鑰的擴展信息，SPB生成自己的協(xié)商密鑰，隨后計算會話密鑰。

SPB將自己生成的協(xié)商密鑰放于3ext'，發(fā)送給FAS。

FAS向UA發(fā)送驗證成功信息和包含密鑰協(xié)商信息的擴展信息。UA根據(jù)此計算會話密鑰。

至此重認(rèn)證過程結(jié)束。

1.6 密鑰協(xié)商

用戶訪問資源服務(wù)時需要通過加密來保證信息傳輸?shù)陌踩珵榱藗鬏斝?，不可能使用非對稱的加密方式。因此，需要通過協(xié)商會話的對稱加密密鑰，保證信息傳輸安全和完全正向保密（PFS，perfect forward secrecy）。在此，使用短時Diffie-Hellman體制進行密鑰交換。

以用戶UA和SPB典型的密鑰交換過程為例，基本過程如下：UA選擇自己的秘密指數(shù)a，SPB選擇自己的秘密指數(shù)b，UA發(fā)送gamodp給SPB，SPB發(fā)送gbmodp給UA。最終雙方分別計算后，協(xié)商出共享的會話密鑰Ks=gabmodp。

通常，上述的短時Diffie-Hellman體制極易遭到中間人攻擊，所以將此密鑰協(xié)商過程放在認(rèn)證過程中進行?？梢詫⑸鲜鲂畔⒎胖翑U展信息ext中，以滿足對安全性的需求。

2 安全性分析

2.1 協(xié)議的安全性證明

SVO邏輯屬于BAN類邏輯，是一種較為成熟可靠的形式化分析工具[17]。本節(jié)基于SVO邏輯，對協(xié)議進行形式化證明。在SVO邏輯中，證明分為初始假設(shè)、協(xié)議目標(biāo)和協(xié)議分析3個部分。

（1）基本公理

這里僅列舉本文在證明此協(xié)議安全性時涉及的基本公理[18]。

（2）初始假設(shè)

H1. 系統(tǒng)初始化已經(jīng)完畢，且各個域的實體已經(jīng)完成認(rèn)證，擁有公私鑰。

H2. 聯(lián)盟鏈中節(jié)點間是可信的。

（3）協(xié)議目標(biāo)

（4）協(xié)議分析

Step 1由Msg1和假設(shè)H1、H3、H4、H5、公理A3，可得

Step 2由Msg2、Msg3和R1，根據(jù)假設(shè)H2、H6、H7，可得

Step 3根據(jù)Msg4，由假設(shè)H3、H4、H5，結(jié)合R2，利用公理A4，可得

Step 4根據(jù)Msg6、Msg7，由假設(shè)H8、H9，結(jié)合R3，利用公理A5，可得

此時達(dá)到協(xié)議目標(biāo)G3。

Step 5利用R3、R4結(jié)論，F(xiàn)AS利用查詢得到的信息，對AU簽名進行驗證，由假設(shè)H10、H11，利用公理A1、A4，可得

此時達(dá)到協(xié)議目標(biāo)G1。

Step 6利用Msg8，由假設(shè)H8，公理A5，可得

此時達(dá)到協(xié)議目標(biāo)G2。

至此已達(dá)到所有協(xié)議目標(biāo)。

2.2 安全屬性分析

（1）協(xié)議安全性

在構(gòu)建信任方面，本文方案通過聯(lián)盟鏈這種可準(zhǔn)入鏈的方式為不同安全域的實體建立信任。經(jīng)過SVO證明，表明協(xié)議是安全的。另外使用的密鑰協(xié)商方案在認(rèn)證建立時進行密鑰協(xié)商，使用短時密鑰協(xié)商，保證了完全正向保密安全。

（2）抗重放攻擊

在認(rèn)證過程中，使用隨機數(shù)來保證消息新鮮。即使消息被敵手從中間截獲，也會由于消息不具有實效性而導(dǎo)致認(rèn)證失敗。這樣能夠有效阻止攻擊者通過重放來進行攻擊。

（3）抗中間人攻擊

在認(rèn)證過程中，實體之間的重要消息通過先簽名后加密的方式進行傳輸。簽名不可偽造。信道中的攻擊者若對消息篡改，將使驗簽無法通過。通過此方法，有效地阻止了中間人攻擊。

（4）身份匿名性

在此方案中，認(rèn)證時使用的是臨時身份。臨時身份生成的過程使身份具有一定的匿名性，而且一段時間后，身份將不再可用，避免了身份被惡意跟蹤，保證了一定限度上的身份匿名性。

（5）可審計

在身份管理方案中，加入了可監(jiān)管公私鑰，在發(fā)生惡意事件時，可對身份信息和身份的行為進行監(jiān)管和審計。

3 性能分析

3.1 負(fù)載性能分析

為合理地比較本文方案與其他方案的性能，參考Kilinc等[19]的實驗，對運算時間進行模擬分析。其實驗環(huán)境為：Intel Pentium Dual CPU E2200 2.2 GHz, 2048 MB RAM, Ubuntu 12.04.1 LTS 32 bit操作系統(tǒng)。

在簽名方案中，設(shè)置參數(shù)如下。

使用256 bit的BN曲線，橢圓曲線方程

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

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

嵌入次數(shù)k=12

（1）計算負(fù)載

在認(rèn)證過程中，實體會執(zhí)行相關(guān)的密碼學(xué)算法運算。做以下規(guī)定：公鑰加密為PE，公鑰解密為PD，非對稱簽名AS，非對稱驗簽AV，點乘PM，選擇隨機數(shù)RNG，基于身份簽名IBS，基于身份驗簽IBV，密碼雜湊算法H。

根據(jù)認(rèn)證過程，統(tǒng)計分析得出從臨時身份獲取到密鑰協(xié)商的總計算負(fù)載如表1所示。

表1 計算負(fù)載Table 1 Computation overhead

為進一步評價本協(xié)議的計算量，將本文方案的跨域協(xié)議計算負(fù)載與其他方案進行比較，如表2所示。在不同用戶數(shù)時，不同方案的耗時對比如圖5和圖6所示。對比分析發(fā)現(xiàn)，本文協(xié)議用戶端上的計算負(fù)載表現(xiàn)與文獻[13]方案基本相同，優(yōu)于文獻[10]方案和文獻[12]方案；在服務(wù)端，略優(yōu)于文獻[10]方案，明顯好于文獻[12]方案和文獻[13]方案。

圖5 用戶端耗時比較Figure 5 Time-consuming on user-side

圖6 服務(wù)端耗時比較Figure 6 Time-consuming on server-side

表2 計算負(fù)載比較Table 2 Comparison of computation overhead

（2）通信負(fù)載

這一部分評估了本文方案認(rèn)證過程中的通信負(fù)載。

在本文方案中，用戶的臨時身份大小為32 byte，隨機數(shù)為2 byte，擴展信息為32 byte，簽名后的簽名信息為96 byte。據(jù)此推算，UA首先向FAS發(fā)送了82 byte的驗證請求信息，F(xiàn)AS查詢BASB的通信過程為66 byte，最后UA收到的認(rèn)證結(jié)果信息為52 byte。統(tǒng)計上述負(fù)載，可以得到在認(rèn)證過程的通信總負(fù)載為296 byte。

相較于文獻[13]方案（通信負(fù)載為130 byte），本方文案有較大的通信負(fù)載，但明顯低于文獻[12]方案（通信負(fù)載為340 byte），因此本文方案在通信效率上是較高的。

3.2 聯(lián)盟鏈性能分析

本文方案基于聯(lián)盟鏈構(gòu)建信任關(guān)系。在認(rèn)證過程中，需要向鏈中寫入和查詢認(rèn)證相關(guān)信息。因此，在聯(lián)盟鏈中，寫入和查詢參數(shù)是一個對可用性影響比較大的指標(biāo)。為評估本文方案的可用性，借助Hyperledger-Caliper，對Hyperledger Fabric的讀寫性能進行測試和分析。實驗環(huán)境為：Intel Core i5 7500@3.4 GHz CPU；8 GB RAM; Ubuntu 18.04 LTS操作系統(tǒng)。

測試后的結(jié)果如圖7和圖8所示。易見，并發(fā)數(shù)對query操作時延的影響不大。query操作的時延總是在極低的水平，基本在10 ms以內(nèi)。因為在區(qū)塊鏈中進行query操作時，會從本地存儲的賬本中直接讀取數(shù)據(jù)，基本上沒有時間上的損耗，所以query操作的時延能夠如此之低。然而寫操作的時延是隨著并發(fā)數(shù)的增加不斷增加的。并發(fā)數(shù)超過50時，時延開始增加得非常迅速。在并發(fā)數(shù)為100時，時延達(dá)到5 s。得到這個結(jié)果也是意料之中的，因為隨著并發(fā)數(shù)的增加，共識的壓力在逐步增大，最終導(dǎo)致寫時延增加。在本文方案中，write操作只有在生成臨時身份時才存在，操作并不頻繁，時延能夠滿足需求。以上結(jié)果表明，聯(lián)盟鏈在時延表現(xiàn)方面，具有良好的可用性。

圖7 鏈上query操作時延Figure 7 Query latency on blockchain

圖8 鏈上write操作時延Figure 8 Write latency on blockchain

4 結(jié)束語

針對目前跨域認(rèn)證的依賴可信第三方、域間不易建立信任的安全難題，本文參考IBC體制，提出了一種基于聯(lián)盟鏈的跨域認(rèn)證機制。針對跨域場景，本文設(shè)計了包括全認(rèn)證和重認(rèn)證在內(nèi)的跨域認(rèn)證協(xié)議和密鑰協(xié)商方案；設(shè)計了一套身份管理方法，在保證身份匿名性的同時，確保用戶行為可監(jiān)管、可審計。針對區(qū)塊鏈的數(shù)據(jù)存儲限制，本文結(jié)合IPFS提出了一種鏈下分布式認(rèn)證信息數(shù)據(jù)存儲方案。最后，使用SVO邏輯對認(rèn)證協(xié)議的安全性進行了證明，表明其具有良好的安全性。分析了計算負(fù)載和通信負(fù)載，與現(xiàn)有的相關(guān)方案相比，有較低的計算負(fù)載和良好的通信負(fù)載。測試了聯(lián)盟鏈的性能，分析表明，在時延表現(xiàn)方面，其具有良好的可用性。