高效的隱私保護在線開票服務認證方案

馬如慧 曹 進* 李 暉 楊朝中

①(西安電子科技大學網絡與信息安全學院 西安 710126)

②(中國科學院國家授時中心 西安 710600)

1 引言

隨著我國科學技術的飛速發(fā)展，互聯(lián)網技術的應用逐漸普及，各個領域與互聯(lián)網的關系也越來越密切。我國《國民經濟與社會發(fā)展第十三個五年規(guī)劃綱要》明確指出“完善稅收征管方式，提高稅收征管效能，推行電子發(fā)票”。傳統(tǒng)的紙質發(fā)票存在難以分發(fā)、存儲、管理以及高成本等特點，不利于促進財務管理。推行電子發(fā)票憑據有利于進一步提高稅務部門工作效率、降低管理成本、杜絕虛假發(fā)票、促進綠色發(fā)展[1]。

但是，在線開具電子憑據也帶來了許多新的挑戰(zhàn)。首先，電子憑據需由國家稅務總局授權開具。國家稅務總局應進一步完善電子憑據系統(tǒng)功能，提供功能全面、統(tǒng)一、可信的操作平臺，以滿足用戶通過電子憑據系統(tǒng)進行電子憑據開具等日常服務功能。其次，電子憑據的開具依托于互聯(lián)網，需要在網絡中傳輸大量的個人隱私信息和企業(yè)信息。如果公共傳輸信道被不法分子入侵，與交易有關的隱私信息將泄露[2]。因此，開具電子憑據過程中保護用戶和企業(yè)的隱私至關重要。最后，為防止企業(yè)或個人虛開發(fā)票以騙取出口退稅、偷稅等問題，在線開具電子憑據的過程中應該認證企業(yè)和個人的合法性，保障只有合法的用戶可申請開具電子憑據，且只有合法的企業(yè)才可授權用戶開具電子憑據。此外，為防止惡意用戶盜取他人身份申請開具電子憑據，在開具電子憑據的過程中應多方面驗證申請者的身份，例如只有提供有效身份證信息且人臉檢測一致的情況下，才可發(fā)起電子憑據開具申請。綜上所述，研究安全可靠的隱私保護在線開具電子憑據認證方案是十分必要的。

近年來，學術界已有大量的研究者提出了電子憑據系統(tǒng)設計方案[3–9]，但是均未考慮在線開具電子憑據的認證安全性。學術界的研究者針對不同的應用場景已經提出了大量的認證方案。由于電子憑據的開具涉及用戶、企業(yè)以及國家稅務總局三方，所以主要考慮三方認證方案[10–16]。文獻[10–12]針對無線傳感網絡分別提出了一個認證方案。這3個方案都實現了用戶側與網關的認證以及服務網絡側與網關的認證。但是，文獻[10]并未實現用戶匿名性、不可鏈路性等，文獻[11]未實現不可鏈路性且無法抵抗用戶假冒攻擊等，文獻[12]未實現不可鏈路性。文獻[13,14]針對工業(yè)物聯(lián)網場景提出了兩個隱私保護的認證方案。這兩個方案都可以實現相互認證、匿名性、不可鏈路性等。但是，文獻[13]由于用戶和服務器的身份標識易于暴露導致增加了長期密鑰泄露的風險。文獻[14]采用橢圓曲線密碼學(Elliptic Curve Cryptography, ECC)保護用戶的隱私標識，產生了較多的計算開銷。文獻[15]針對多個云服務器的車聯(lián)網場景提出了一個隱私保護的認證方案。但是，該方案并未完美實現相互認證且耗費了大量的計算和通信開銷。文獻[16]針對無線醫(yī)療傳感器網絡提出了一個認證方案。該方案可以實現相互認證、匿名性等安全特性，但是該方案基于大整數分解困難問題加密隱私數據，產生了較多的通信開銷。綜上所述，現有三方認證方案存在各種安全和性能缺陷。因此，針對電子憑據在線開具場景設計安全高效的認證方案是當前亟需解決的問題。

本文針對電子憑據在線開具場景設計了一個隱私保護認證方案。在該方案中，國家稅務總局管理一個電子憑據系統(tǒng)，申請開具電子憑據的用戶和合法的企業(yè)均需注冊到電子憑據系統(tǒng)中以獲得長期共享密鑰。注冊完成后，與企業(yè)完成交易的用戶利用長期共享密鑰在電子憑據收票方手機應用(APPlication, APP)上發(fā)起開票申請，電子憑據系統(tǒng)驗證用戶身份并通過相應合法企業(yè)驗證用戶的交易信息，進而為用戶開具電子憑據。本文的貢獻總結如下：

(1) 本文提出了一個統(tǒng)一的電子憑據在線開票系統(tǒng)，該系統(tǒng)包括3部分：電子憑據系統(tǒng)、電子憑據收票方手機APP以及電子憑據開票方服務器，分別用于國家稅務總局、用戶以及企業(yè)完成交易后電子憑據的在線開具。

(2) 本文在電子憑據在線開票系統(tǒng)的基礎之上提出了在線開票服務認證方案。該方案利用橢圓曲線Diffie-Hellman算法實現了用戶、企業(yè)等實體在線注冊過程中的隱私安全，依據身份證信息和人臉信息完成了發(fā)票開具請求前的本地驗證避免惡意用戶盜取他人身份申請開具電子憑據，基于預共享密鑰機制分別實現了用戶、企業(yè)與電子憑據系統(tǒng)的相互認證，并且采用對稱加解密算法確保了電子憑據的安全傳輸等。此外，在該方案中，用戶和企業(yè)的真實身份標識信息、交易信息以及發(fā)票信息等隱私內容均加密后傳輸，且采用及時更新的匿名標識代表用戶的真實身份標識。

(3) 本文采用形式化分析工具Tamarin和非形式化安全分析證明了提出方案的安全性，結果證明本文方案可以滿足相互認證、匿名性、不可鏈路性、數據機密性以及抵抗重放攻擊和用戶假冒攻擊。此外，本文在計算開銷和通信開銷方面評估了提出方案的性能，結果顯示本文方案耗費較少的通信開銷和計算開銷。

2 系統(tǒng)模型、安全需求和設計思想

2.1 系統(tǒng)模型

如圖1所示，電子憑據開票系統(tǒng)主要包括3個部分：電子憑據系統(tǒng)，開票方以及收票方。

圖1 電子憑據開票系統(tǒng)

電子憑據系統(tǒng)是國家稅務總局管理的在線電子憑據開具系統(tǒng)，主要負責為合法用戶開具電子憑據，內置電子憑據開具服務器、用戶認證服務器以及信息核驗服務器。

(1) 電子憑據開具服務器：負責根據收票方與開票方交易的產品或服務的項目和金額等信息形成電子憑據，并反饋給收票方。

(2) 用戶認證服務器：負責驗證收票方的合法性，若驗證成功，則向信息核驗服務器反饋成功認證通知并將用戶交易信息傳輸給信息核驗服務器。若驗證失敗，則直接向收票方發(fā)送開票失敗消息。

(3) 信息核驗服務器：負責核驗用戶交易相關信息的正確性。若核驗成功，則向電子憑據開具服務器反饋成功核驗通知。若核驗失敗，則向收票方發(fā)送開票失敗消息。

開票方是指與收票方完成在線支付交易并為收票方提供產品或者服務的企業(yè)，例如京東等。每個合法企業(yè)都需要在本地安裝一個電子憑據開票方服務器，負責電子憑據交易信息的核驗等。每個合法的開票方都具備一個唯一合法的企業(yè)標識。

收票方是指支付購買產品或服務的費用而收取電子憑據的個人或單位用戶。每個需要開具電子憑據的收票方用戶需本地下載一個電子憑據收票方手機APP，并且在該APP上完成電子憑據的申請與獲取。每個合法的收票方都具備一個唯一合法的身份證。

2.2 安全需求

為防止攻擊者執(zhí)行假冒攻擊虛開發(fā)票或提供虛假發(fā)票等問題，在線開票服務認證方案應該滿足以下幾個安全需求。

相互認證：收票方與電子憑據系統(tǒng)以及開票方與電子憑據系統(tǒng)間均需完成相互認證以抵抗假冒攻擊以及中間人攻擊等。

隱私保護：開具電子憑據過程中保護收票方與開票方的隱私是至關重要的。隱私保護主要涉及3方面內容：收票方和開票方身份標識的匿名性、不可鏈路性以及隱私數據的機密性。

(1) 匿名性：應防止攻擊者獲得收票方和開票方的真實身份標識[17]。

(2) 不可鏈路性：應防止攻擊者通過認證過程中公開傳輸的消息區(qū)分出兩條消息是否來自同一個收票方/開票方[17]。

(3) 數據機密性：應防止攻擊者竊取收票方和開票方的隱私數據，例如交易信息、電子憑據信息等。

抵抗重放攻擊：開具電子憑據過程中應防止攻擊者重放之前的數據以重復開具電子憑據等問題。

2.3 設計思想

收票方用戶在開票方企業(yè)提供的官方APP上成功完成貨品或者服務交易之后，可在線從電子憑據系統(tǒng)獲取此次交易的電子憑據，具體包括以下兩個步驟。首先，收票方需本地下載電子憑據收票方手機APP并利用其有效身份證以及人臉信息完成注冊，而開票方則需安裝電子憑據開票方服務器并利用其合法的營業(yè)執(zhí)照等信息完成注冊。隨后，收票方通過電子憑據收票方手機APP向電子憑據系統(tǒng)發(fā)起某次交易開票請求消息。電子憑據系統(tǒng)收到收票方的開票請求后，首先驗證收票方的身份信息，驗證成功后，通過相應的開票方企業(yè)的電子憑據開票方服務器核驗該收票方此次開具電子憑據交易信息的正確性。核驗成功后，電子憑據系統(tǒng)為收票方開具電子憑據并安全地交付給收票方。收票方驗證電子憑據有效后，向電子憑據系統(tǒng)發(fā)送確認消息。進而，電子憑據系統(tǒng)向開票方發(fā)送核驗確認消息，開票方記錄此次交易已開具電子憑據。

3 方案設計

方案主要包括3個階段：系統(tǒng)設置階段、在線注冊階段以及開具電子憑據認證階段。完成系統(tǒng)設置之后，開票方與收票方分別向電子憑據系統(tǒng)發(fā)起在線注冊請求，電子憑據系統(tǒng)分別為開票方和收票方分配長期共享密鑰。隨后，當收票方完成交易并請求開具電子憑據時，電子憑據系統(tǒng)、開票方以及收票方利用各自的長期共享密鑰執(zhí)行開具電子憑據認證過程完成三方認證以及電子憑據的安全分發(fā)。

3.1 系統(tǒng)設置階段

電子憑據系統(tǒng)執(zhí)行如下操作：

(1) 選擇主密鑰Ke，選取一個橢圓曲線E上的循環(huán)群G，其中G的階為q，生成元為P，選取私鑰sk∈Zq?，公鑰pk=sk·P。

(2) 選擇兩個安全的哈希函數h1,h2，一個帶密鑰的哈希函數f1以及一個密鑰導出函數KDF。

(3) 根據公安部身份驗證系統(tǒng)所需的身份證信息與人臉信息的綁定關系，選擇一個bind函數。bind函數一般為哈希函數，不會泄露輸入信息。

(4) 選擇對稱加密算法ENC和解密算法DEC以及模糊提取生成算法Gen和再生算法Rep。模糊提取算法的詳細內容可參考文獻[18,19]。

(5) 公開(q,P,pk,h1,h2,f1,KDF,bind,ENC,DEC,Gen,Rep)。表1列出了本文用到的主要符號及定義。

表1 符號定義

3.2 在線注冊階段

由于電子憑據收票方手機APP和電子憑據開票方服務器與電子憑據系統(tǒng)之間都是通過網絡連接，所以本文考慮在線注冊。

3.2.1 收票方在線注冊階段

收票方i將其身份證標識等內容安全地傳輸給電子憑據系統(tǒng)。電子憑據系統(tǒng)驗證內容的有效性后，為收票方提供長期共享密鑰。具體如下：戳。隨后，電子憑據收票方手機APP將注冊請求消息(ci,si,Ri,ti0)發(fā)送給電子憑據系統(tǒng)。

3.2.2 開票方在線注冊階段MKj和LKj分別代表注冊過程中開票方的臨時加密密鑰和完整性密鑰，tj0為當前時間戳。最后，電子憑據開票方服務器將注冊請求消息(cj,sj,Rj,tj0)發(fā)送給電子憑據系統(tǒng)。

(3) 電子憑據開票方服務器驗證sej，驗證成功后解密cej獲得Kj，并且本地安全存儲Kj。

3.3 開具電子憑據認證階段

(6) 電子憑據系統(tǒng)驗證Ri，驗證成功則記錄此次開具操作，計算消息認證碼Re=f1(TLKj,eIDi′||sIDj′||mi||succ)并將開票信息核驗確認消息(Re)發(fā)送給開票方；驗證失敗則記錄已開具電子憑據Me無效。

(7) 開票方j的電子憑據開票方服務器驗證Re，驗證成功后在其存儲模塊中記錄此次交易已經開具發(fā)票。

4 安全分析

4.1 非形式化安全分析

相互認證。在注冊過程中，電子憑據系統(tǒng)通過驗證收票方提供的身份標識等信息以及開票方提供的營業(yè)執(zhí)照等信息分別認證收票方與開票方。此外，由于收票方與開票方都采用了電子憑據系統(tǒng)的公鑰加密隱私數據后傳輸給電子憑據系統(tǒng)，所以只有電子憑據系統(tǒng)可以獲得收票方與開票方提供的隱私信息，進而產生有效的消息認證碼sei和sej。因此，收票方與開票方可分別通過驗證電子憑據系統(tǒng)返回的sei和sej認證電子憑據系統(tǒng)。在認證過程中，收票方、開票方和電子憑據系統(tǒng)之間分別共享臨時密鑰TKi,TKj，進而可利用TKi/TKj導出消息認證碼Si/Sei/Sj/Sej。電子憑據系統(tǒng)可通過核驗Si和Sj分別認證收票方與開票方。收票方可通過核驗Sei認證電子憑據系統(tǒng)，而開票方可通過核驗Sej認證電子憑據系統(tǒng)。因此，本文的方案可以實現收票方與電子憑據系統(tǒng)以及開票方與電子憑據系統(tǒng)之間的相互認證。

匿名性。在注冊過程中，收票方/開票方的身份標識信息eIDi/sIDj采用臨時密鑰MKi/MKj加密后傳輸給電子憑據系統(tǒng)。只有電子憑據系統(tǒng)可以計算出MKi/MKj進而導出收票方/開票方的真實身份標識。在認證過程中，采用匿名身份標識HIDi代表收票方且每次認證完成后均會更新HIDi，只有電子憑據系統(tǒng)可以根據其主密鑰Ke從HIDi中導出收票方的真實身份標識eIDi。任何不知道主密鑰Ke的攻擊者是無法獲得收票方的真實身份標識。此外，收票方/開票方的真實身份標識eIDi/sIDj均采用臨時加密密鑰TMKj/TMKi加密后傳輸，攻擊者沒有解密密鑰不可能獲得。因此，本方案可以實現匿名性。

不可鏈路性。在注冊過程中，由于隨機數ri/rj以及時間戳ti0/tj0的使用，消息隨機變化，攻擊者無法推斷出兩條公開傳輸的消息是否來自同一個發(fā)送者。在認證過程中，由于每個開具電子憑據的認證過程都需更新匿名身份標識HIDi且更新過程中采用隨機數bi?來計算新的匿名標識，攻擊者不可能將匿名身份標識與某特定的收票方關聯(lián)。此外由于時間戳ti/tj的使用，收票方、開票方以及電子憑據認證系統(tǒng)在每個會話中使用的臨時密鑰TKi/TKj都不相同，進而每個會話中產生的消息(HIDi,Hbi,Ci,Si,ti)/(Cj,Sj,tj)/(Cei,Sei)/(Cej,Sej,tej)各不相同，攻擊者無法將不同的消息鏈路到同一個發(fā)送者。因此本方案可實現不可鏈路性。

數據機密性。在注冊過程中，收票方的身份信息eIDi和開票方的企業(yè)信息sIDj,Mj等隱私數據均采用臨時共享密鑰MKi/MKj加密后傳輸，攻擊者沒有相應的密鑰，不可能獲得隱私數據。在認證過程中，收票方的交易信息Mi，訂單編號信息mi，企業(yè)側存儲的訂單交易信息mj以及電子憑據信息Me均采用臨時密鑰TMKi/TMKj加密后傳輸，攻擊者沒有相應的密鑰，不可能獲得隱私數據。因此本方案可確保數據機密性。

抵抗重放攻擊。由于隨機數ri/rj，時間戳ti0/tj0以及ti/tej/tj的使用，本文的方案可以抵抗重放攻擊。

抵抗用戶假冒攻擊。在注冊過程中，電子憑據收票方手機APP會檢測身份證照片信息與活體人臉采集信息的一致性，如果一致才會允許收票方發(fā)起注冊。其次，電子憑據系統(tǒng)會借助第三方公安部身份驗證系統(tǒng)識別用戶身份信息的有效性，識別成功后，才會給電子憑據收票方手機APP預置長期共享密鑰。然后，在認證過程中，只有收票方給電子憑據收票方手機APP提供特定有效的身份證信息和人臉信息，收票方才能通過驗證并發(fā)起開票請求。因此，本方案可以抵抗用戶假冒攻擊。

4.2 形式化驗證工具：Tamarin

本小節(jié)采用形式化驗證工具Tamarin[20]證明了本文提出方案的安全性。Tamarin是當前主流的協(xié)議形式化分析工具，可以建立無限驗證、可變全局狀態(tài)、歸納和循環(huán)引用，內置Diffie-Hellman冪指數運算、XOR運算、對稱加密以及解密運算等操作[21]。Tamarin內置Dolev-Yao敵手模型，即敵手對通信網絡有絕對控制權，可以竊聽、刪除、插入、修改和攔截公共信道上的消息。Tamarin工具是基于硬件工作過程的模擬，將協(xié)議流程采用多集重寫規(guī)則rule模型化，而協(xié)議的安全目標則采用lemma描述。Tamarin工具能夠自動輸出lemma驗證結果，即如果某lemma滿足，輸出verified；如果某lemma不滿足，則輸出falsified并給出反例，以便設計者能夠快速發(fā)現協(xié)議安全漏洞并對協(xié)議進行修改。在Tamarin模型化過程中，Fr(～x)代表選擇新值x，$代表公開， All代表全局量化， Ex代表存在量化，= = >代表推出，# 代表時間戳前綴，而F@#i代表事件F發(fā)生在時間點i。我們在Linux平臺下搭建了Tamarin仿真測試模型，在本方案的Tamarin模型中，主要有3個實體User, Enterprise以及System，分別代表方案中的收票方、開票方以及電子憑據系統(tǒng)。具體過程如下：

(1) Tamarin初始配置過程為：

由于提出方案中僅采用了一些簡單的哈希、對稱加密以及異或等操作，因此初始配置過程本文采用Tamarin內置的hashing, symmetric-encryption以及xor函數。具體設置為：

(c) 電子憑據系統(tǒng)在開具電子憑據認證過程中的操作采用4個重寫規(guī)則System1, System2,System3以及System4模型化，其中，規(guī)則System1表示電子憑據系統(tǒng)收到收票方發(fā)送的開票請求消息并向開票方發(fā)送開票信息核驗請求消息的過程，規(guī)則System2表示電子憑據系統(tǒng)收到開票方發(fā)送的開票信息核驗響應消息之后的驗證過程，規(guī)則System3表示電子憑據系統(tǒng)向收票方發(fā)送開票響應消息的過程，規(guī)則System4表示電子憑據系統(tǒng)收到開票確認消息之后的驗證過程。具體為：

(d) 開票方在開具電子憑據認證過程中的操作采用兩個重寫規(guī)則Enterprise1和Enterprise2模型化，其中Enterprise1表示開票方收到開票信息核驗請求消息之后的驗證過程，Enterprise2表示開票方向電子憑據系統(tǒng)發(fā)送開票信息核驗響應消息的過程。具體為：

本文定義了多個all-traces類型的lemma證明了方案的安全特性。具體地，SystemAuthUser涉及電子憑據系統(tǒng)對收票方的認證。為了實現該屬性，我們在規(guī)則User1中標記了SendRequest($User,Si)行為，且在規(guī)則System1中標記了Eq(Si1, Si)以及RecvRequest($User, Si)行為。若RecvRequest($User, Si)行為發(fā)生則表明電子憑據系統(tǒng)已成功核驗消息認證碼。而當RecvRequest($User, Si)行為發(fā)生時，SendRequest($User, Si)行為一定已經發(fā)生過且RecvRequest($User, Si)行為只發(fā)生了1次，則表明電子憑據已成功認證收票方。同理，EnterpriseAuthSystem涉及開票方對電子憑據系統(tǒng)的認證，SystemAuthEnterprise涉及電子憑據系統(tǒng)對開票方的認證，userAuthSystem涉及收票方對電子憑據系統(tǒng)的認證，SystemAuthUser2再次涉及電子憑據系統(tǒng)對收票方的認證。此外，本文采用Secrecy-Message定義方案中隱私數據Mi,mi,Me以及mj的機密性。具體定義為：

圖2 Tamarin驗證結果

5 性能分析

本節(jié)評估了本文所提方案與其他認證流程較為相似的方案[13,14,16]的計算開銷和通信開銷。

5.1 計算開銷

本小節(jié)對比了所提方案與其他方案[13,14,16]在認證過程中的計算開銷。本文僅考慮耗時較多的密碼學操作，具體包括點乘操作Tp、模平方操作Te、中國剩余定理求解操作Tcrt、切比雪夫多項式操作Tc、模糊提取操作Tr、對稱加解密操作Ts以及哈希操作Th。本文方案中采用的h1,h2,f1以及KDF等函數操作均采用Th標識。根據文獻[22,23]可得上述密碼學操作計算時間為Tp= 63.08 ms,Tc= 21.02 ms,Tr= 63.08 ms,Ts= 8.70 ms,Th= 0.50 ms,Te=60Th以及Tcrt= 22Th。

由于注冊過程只需執(zhí)行1次，而認證需執(zhí)行多次，因此本文僅對比相關方案在認證過程中的計算開銷。文獻[13]在認證過程中執(zhí)行了3次點乘操作以協(xié)商臨時密鑰保護身份標識、3次點乘操作計算會話密鑰保護后續(xù)數據的安全性、1次模糊提取操作以及多次輕量級的哈希操作等。文獻[14]在認證過程中執(zhí)行了3次點乘操作以協(xié)商臨時密鑰保護身份標識的安全性、8次對稱加解密操作、1次模糊提取操作以及多次哈希操作等。文獻[16]在認證過程中執(zhí)行了4次切比雪夫多項式操作以計算會話密鑰保護后續(xù)數據的安全性、1次模平方操作以保護身份標識的安全性、1次中國剩余定理求解操作以及多次哈希操作等。本文方案在認證過程中執(zhí)行了8次對稱加解密操作以保護隱私數據的安全性、1次模糊提取操作以及多次哈希操作等。表2列出了對比方案在認證過程的計算開銷?；谏鲜雒艽a學操作的計算時間，圖3顯示了對比方案在認證過程中隨著認證次數的增加的總計算開銷的對比結果。結果顯示，本文方案認證過程中的計算開銷遠小于文獻[13,14]方案認證過程中的計算開銷，而稍大于文獻[16]認證過程中的計算開銷，但是文獻[16]方案會耗費大量的通信開銷。

圖3 計算開銷對比結果

表2 計算開銷

5.2 通信開銷

本小節(jié)對比了提出方案與其他方案在認證過程中的通信開銷。為了公平起見，本文定義對比方案中的安全等級均等價于高級加密標準(Advanced Encryption Standard, AES) 128 bit[24,25]。具體地，假設用于對稱加密、解密的密鑰為128 bit，基于橢圓曲線密碼學算法的密鑰長度為256 bit以及基于大整數分解密碼算法的密鑰長度為3072 bit等。另外，普通哈希的輸出值一般為256 bit，帶密鑰哈希的輸出值一般為128 bit，隨機數為128 bit，時間戳為32 bit。此外，在同一場景下，由于對比方案均需傳輸相同的隱私數據Mi等內容，假設隱私數據的長度以及身份標識信息等內容的長度均為128 bit。本文方案中，哈希函數h1和h2的輸出均為256 bit，但是h1僅保留128 bit有效位；f1輸出為128 bit；KDF采用帶密鑰的哈希函數計算，輸出值也為128 bit；bind采用h2計算，輸出值為256 bit。

在認證過程中，文獻[13,14,16]方案均有4條信令消息，而本文方案額外考慮到發(fā)票確認需要6條信令消息。表3列出了本文方案與其他相關方案在認證過程的通信開銷的對比結果。對比結果顯示，本文方案認證過程中的通信開銷小于文獻[13,14,16]方案認證過程中的通信開銷。

表3 通信開銷

6 結論

本文提出了一個統(tǒng)一的電子憑據開票系統(tǒng)，并此系統(tǒng)基礎之上提出了一個隱私保護的電子憑據在線開具認證方案。通過該方案，完成交易的用戶可在線發(fā)起開具電子憑據請求，請求消息核驗通過后即可獲得相應的電子憑據。安全和性能分析結果表明該方案可以在耗費較少的認證開銷的情況下實現較多的安全屬性，包括相互認證、匿名性、不可鏈路性、數據機密性以及抵抗重放攻擊和用戶假冒攻擊等。