基于改進無證書公鑰密碼的輕量級DTLS協(xié)議設(shè)計

許國棟 劉光杰 喬森 陸賽杰 趙華偉

0 引言

隨著萬物互聯(lián)時代的到來,物聯(lián)網(wǎng)技術(shù)正深刻改變著世界．指數(shù)級增長的物聯(lián)網(wǎng)設(shè)備,在給人們帶來便利的同時,也面臨著眾多威脅和安全挑戰(zhàn)[1]．物聯(lián)網(wǎng)安全逐漸引起了工程界和學術(shù)研究者的廣泛關(guān)注．在眾多物聯(lián)網(wǎng)安全問題中,協(xié)議安全是實現(xiàn)點到點和端到端安全通信的基石,因此也成為了物聯(lián)網(wǎng)安全研究的熱點．網(wǎng)絡協(xié)議研究者起初設(shè)計網(wǎng)絡協(xié)議時主要考慮了可用性,而忽略了安全性問題．作為傳輸層協(xié)議典型代表的TCP、UDP協(xié)議本身也不具備安全性．SSL/TLS協(xié)議在TCP協(xié)議之上提供數(shù)據(jù)的加密傳輸服務,而DTLS協(xié)議(DatagramTLS)擴展自TLS協(xié)議架構(gòu),為UDP協(xié)議提供端到端的安全通道．DTLS協(xié)議也可與物聯(lián)網(wǎng)相關(guān)應用層協(xié)議結(jié)合來實現(xiàn)安全通信．例如,CoAP協(xié)議[2]經(jīng)DTLS加密后形成的CoAPs協(xié)議,被廣泛應用于物聯(lián)網(wǎng)的端到端安全通信中[3-4]．

握手是DTLS協(xié)議完成身份認證和秘鑰協(xié)商的必要機制.然而,傳統(tǒng)DTLS協(xié)議的握手過程更多是基于公鑰證書,但基于證書的公鑰密碼體系在證書管理、身份認證與加密等方面存在不足．一方面,證書管理包括證書的撤銷、發(fā)放和存儲等環(huán)節(jié),增加了系統(tǒng)的開銷;另一方面,身份認證與加密包括通信終端的身份合法性認證、基于公鑰的傳輸數(shù)據(jù)加密等過程,增加了計算開銷．因此,本文主要研究基于無證書公鑰密碼的DTLS握手協(xié)議.針對該問題,研究者們也探索了諸多無證書[5]的解決方案．2003年,Boneh等[6]構(gòu)建了第一個基于身份的加密方案(Identity Based Encryption,IBE)．然而,IBE方案使用雙線性對運算，且用戶的私鑰完全由私鑰生成器(Private Key Generator,PKG)生成,這不僅造成更高的計算代價,還引發(fā)出私鑰托管問題．文獻[7]實現(xiàn)了基于身份標識(Identify-Based Cryptography,IBC)的DTLS協(xié)議,但此方案中的用戶私鑰仍完全由PKG產(chǎn)生．若PKG節(jié)點遭受攻擊,惡意節(jié)點將獲取用戶私鑰,進而竊聽合法用戶間的通信內(nèi)容．文獻[8]提出了一種用戶私鑰生成方案來解決密鑰托管問題,首先使用系統(tǒng)私鑰生成初始秘鑰值,再疊加上一個隨機數(shù),構(gòu)成一部分用戶私鑰,但此方案在安全性證明方面還存在不足．文獻[9]提出了一種雙密鑰對的方案,即PKG隨機選取兩個秘鑰值作為系統(tǒng)私鑰,并將其中一個秘鑰值加上僅通過系統(tǒng)私鑰產(chǎn)生的一部分用戶私鑰作為用戶最終的部分私鑰,但與文獻[8]相比又增加了部分計算量,降低了方案的實現(xiàn)效率,難以滿足計算成本受限型節(jié)點的安全通信需求．

針對上述問題,本文改進了產(chǎn)生用戶部分私鑰的運算方法,提出了一種基于離散對數(shù)運算的無證書公鑰加密(Discrete Logarithm based Certificate-Less Public Key Cryptography,DL-CL-PKC)方案,此方案主要有兩個優(yōu)勢:一是規(guī)避了基于身份標識的方案中雙線性映射帶來的運算復雜度;二是此方案中私鑰生成器只需要生成一對系統(tǒng)密鑰值,節(jié)省了一對密鑰值的生成過程和后續(xù)的存儲空間．最后設(shè)計并實現(xiàn)了基于DL-CL-PKC的DTLS協(xié)議．改進的DTLS協(xié)議不僅簡化了握手過程,并且可以在不使用證書情況下實現(xiàn)安全加密通信．

1 改進的無證書公鑰密碼體制

本文改進的無證書方案是基于離散對數(shù)運算而設(shè)計的,該體制主要包括密鑰管理方案設(shè)計和密鑰更新方案設(shè)計．下面將依次介紹離散對數(shù)數(shù)學難題的定義以及無證書方案中的密鑰管理和密鑰更新．

1.1 離散對數(shù)難題

本文主要是基于離散對數(shù)數(shù)學難題,設(shè)計了新的用戶部分私鑰生成算法．離散對數(shù)難題描述為:對于給定的m,x和p,通過公式y(tǒng)=mxmodq很容易計算得出y,但是若給定參數(shù)y,a和p想計算出x則極其困難．目前來說離散對數(shù)的計算難度與RSA算法中大整數(shù)因數(shù)分解的難度相同,因此并沒有有效的方法可以計算出模為素數(shù)的離散對數(shù)問題．本文基于離散對數(shù)難題重新設(shè)計DTLS握手協(xié)議主要基于兩個原因:一方面RSA算法的加解密過程是非對稱的且存在大量的模冪運算,本文采用對稱加解密,提高了無證書方案的計算效率;另一方面RSA算法的加密公鑰存儲在證書中,不符合本文方案基于無證書的原則,無法達到降低系統(tǒng)開銷的目的．基于離散對數(shù)難題,也衍生出一些相關(guān)密碼體制,如ElGmal加密體制[10]、Diffe-Hellman密鑰交換方法[11]以及Schnorr數(shù)字簽名方法[12]．離散對數(shù)難題與大整數(shù)因數(shù)分解的安全性分析如下:

2)大整數(shù)因數(shù)分解.第一步選擇兩個大素數(shù)p,q;第二步計算模數(shù)n=p×q和L=φ(n)=(p-1)(q-1),選擇滿足gcd(e,L)=1的e,并計算出滿足d·e≡1modL的d(1

1.2 密鑰管理

科研人員一直致力于密鑰管理的簡化研究．著名密碼學專家Shamir[13]率先提出了基于身份的密碼體制的概念,作為其核心組成的私鑰生成器(Private Key Generator,PKG),也是本文設(shè)計的無證書公鑰密碼體制中的重要組成部分．PKG產(chǎn)生無證書公鑰加密方案中用戶的部分私鑰,省略證書參與用戶身份驗證的步驟．

無證書公鑰加密方案中密鑰管理如圖1所示．由于PKG單獨生成IBE加密方案中的用戶私鑰存在安全隱患,所以本文提出將用戶私鑰的產(chǎn)生過程分為兩個階段：首先用戶向PKG節(jié)點請求生成部分私鑰;其次則由用戶根據(jù)PKG節(jié)點發(fā)送的系統(tǒng)參數(shù)隨機生成另一部分私鑰,并對PKG節(jié)點和其他用戶不可見．然后用戶公布自己的公鑰．密鑰管理包括以下幾個方面:

圖1 DL-CL-PKC密鑰管理方案Fig.1 Key management scheme for DL-CL-PKC

1)PKG節(jié)點初始化之后,監(jiān)聽兩個通信終端的部分私鑰生成請求;

2) PKG節(jié)點將產(chǎn)生的系統(tǒng)參數(shù)和公私鑰發(fā)送給監(jiān)聽到請求的兩個通信終端;

3) PKG節(jié)點將根據(jù)客戶端或服務端的ID產(chǎn)生相應的部分私鑰發(fā)送給客戶端或服務端;

4)客戶端或服務端通過系統(tǒng)參數(shù)再隨機選取一個秘密值作為另一部分私鑰,并通過這兩部分私鑰計算出完全的私鑰．

下面根據(jù)上述描述給出具體方案．

1)系統(tǒng)參數(shù)生成

公開系統(tǒng)參數(shù)param:{a,b,g,x,y,H1,H2}．

2)部分私鑰提取

假設(shè)用戶A的身份為IDA,PKG節(jié)點計算用戶A的部分私鑰,步驟如下:

① 計算hA=H1(IDA);

3)完整公私鑰生成

4)加密(cl-encrypt)

用戶B將消息發(fā)送給用戶A,步驟執(zhí)行如下:

③ 用戶B將C=(N,M)發(fā)送給給用戶A．

5)解密(cl-decrypt)

當用戶A接收到用戶B發(fā)送來的加密報文C,用戶A計算m=M?H2(NSA)恢復出明文信息．解密過程如下驗證推導所示:

1.3 密鑰更新

密鑰是加密通信的關(guān)鍵,因此為了保證系統(tǒng)的安全性,必須在一定周期內(nèi)進行更新(主要是對用戶私鑰的更新)．基于無證書公鑰加密方案中的密鑰更新過程主要包括以下兩個步驟:

1)預先設(shè)定密鑰更新周期,時間周期設(shè)置得越短則系統(tǒng)安全性越高．為了讓密鑰更新的周期更加合理,可根據(jù)網(wǎng)絡動態(tài)和需求,實時恰當?shù)卣{(diào)整更新周期．

1.4 安全性分析

在本文設(shè)計的加密體制中,主要考慮以下兩種攻擊類型:

第一種攻擊.假設(shè)攻擊者獲取了系統(tǒng)私鑰,就會帶來安全威脅,即攻擊者利用獲取的系統(tǒng)私鑰去生成用戶的部分私鑰,這里攻擊者作為不可信的PKG節(jié)點．但是由于此方案中用戶完全私鑰的部分是由用戶自己生成的,并且不對外公開,因此不可信的PKG節(jié)點無法獲取用戶完全的私鑰,也就無法去監(jiān)聽與其他用戶之間的通信內(nèi)容．

第二種攻擊.假設(shè)攻擊者作為一個不合法的用戶,獲取的是某個合法用戶完整的私鑰,但是由于此方案采用了離散對數(shù)運算,不合法的用戶無法通過合法用戶的私鑰去倒推出系統(tǒng)私鑰,也不可能去生成其他合法用戶的私鑰,因此它只能與其他用戶之間進行通信,是無法監(jiān)聽到甚至解密其他用戶之間的通信內(nèi)容的．

這樣在系統(tǒng)更新用戶私鑰時,不合法的用戶在向PKG節(jié)點申請部分私鑰時就無法通過PKG節(jié)點的身份認證,原先獲取的私鑰也就失效了．

2 基于改進無證書公鑰密碼的DTLS協(xié)議設(shè)計

本文設(shè)計的基于無證書公鑰加密的DTLS協(xié)議主要針對握手協(xié)議進行改進．由于目前DTLS握手協(xié)議雙方在進行通信認證時仍然需要加載證書,增加了握手過程的復雜性和成功建立通信連接所占用的時間．因此,在DTLS協(xié)議中引入改進的無證書公鑰密碼體制,設(shè)計新的握手協(xié)議,可有效避免證書的交換和驗證的過程,減少通信雙方需要傳遞的信息量和交互的回合數(shù),從而縮短通信連接建立的時間．

2.1 DTLS握手協(xié)議

DTLS協(xié)議建立在傳輸層協(xié)議之上、應用層協(xié)議之下,在完成加密算法、密鑰協(xié)商、服務器端認證后,即可建立應用層協(xié)議的通信．因此,后續(xù)應用層協(xié)議發(fā)送的數(shù)據(jù)都會進行加密處理,以保證網(wǎng)絡通信中數(shù)據(jù)的安全．圖2a給出的是一次完整的DTLS握手流程．DTLS v1.2中ClientHello和ServerHello消息序列中包含一個預共享密鑰(pre_shared_key),DTLS v1.3的ClientHello和ServerHello在DTLS v1.2基礎(chǔ)上又增加了一個密鑰共享(key_share)的擴展部分．關(guān)于握手消息序列,文獻[14]進行了較為詳盡的介紹,因此本文不在此贅述．

圖2 傳統(tǒng)DTLS握手消息序列與改進DTLS握手消息序列Fig.2 Traditional DTLS handshake message sequences (a) and improved DTLS handshake message sequences (b)

2.2 改進DTLS握手協(xié)議設(shè)計

本文提出的改進DTLS握手協(xié)議通過+key_share*擴展在Client端與Server端間交換公鑰信息,并將其重命名為+publickey_share*．而Client端和Server端的私鑰,一部分由私鑰生成器根據(jù)兩者的ID生成,另一部分由自身根據(jù)系統(tǒng)參數(shù)隨機生成．本文所設(shè)計的握手協(xié)議如圖2b所示,握手過程如下:

1)Client端向Server端發(fā)送一個沒有攜帶cookie值的ClientHello報文,以確認Server端已經(jīng)啟用．

2)Server端收到此報文后,回復攜帶cookie值的HelloRetryRequest給Client端．

3)Client端從HelloRetryRequest報文中取出cookie值,放入新的ClientHello報文中發(fā)送,擴展+publickey_share*中附帶自身的公鑰信息．

4)Server端驗證Client端發(fā)送的ClientHello報文中攜帶的cookie值,選擇合適的加密算法(本文設(shè)計為DTLS_PKC_WITH_AES_128_CBC_SHA512)和壓縮算法,并生成隨機數(shù),通過ServerHello報文發(fā)送到Client端,擴展中攜帶自身的公鑰信息．

5)Server端發(fā)送ChangeCipherSpec報文告知Client端密碼規(guī)范已發(fā)生改變,接下來將利用協(xié)商相同的安全密鑰來保障數(shù)據(jù)的安全傳輸．Server端通過密鑰交換算法生成預主密鑰,預主密鑰通過與隨機數(shù)進行偽隨機運算生成主密鑰以及會話密鑰．

預主密鑰生成過程如下:

(gSS)SCmodq=gSSSCmodq=

(gSC)SSmodq=(gSCmodq)SSmodq=

6)Server端利用協(xié)商好的算法和密鑰,將Finished報文加密后發(fā)送給Client端．此報文用于驗證密鑰交換是否成功．

7)Client端在收到Server端發(fā)送的ServerHello、ChangeCipherSpec和Finished報文后計算出相應的會話密鑰,解密Finished報文并對其數(shù)據(jù)進行驗證．驗證通過發(fā)送ChangeCipherSpec報文告知Server端接下來使用協(xié)商相同的安全密鑰來保障數(shù)據(jù)的安全傳輸．

8)Client端利用協(xié)商的算法和密鑰,加密Finished報文后發(fā)送給Server端,Server端解密此報文并驗證,驗證通過后,兩者即可正式建立連接．

對比圖2a與2b可以發(fā)現(xiàn),與傳統(tǒng)的DTLS握手過程相比,本文在握手消息ClientHello和ServerHello中使用擴展+publickey_share*交換公鑰信息,并省略了握手過程中與證書相關(guān)的交互報文．

2.3 無證書公鑰加密算法及握手協(xié)議實現(xiàn)

握手協(xié)議中的無證書公鑰加密算法(Discrete Logarithm based Certificate-Less Public Key Cryptography,DL-CL-PKC)可以通過GMP庫[15]來實現(xiàn).GMP庫是一種高精度的算術(shù)運算庫,可支持對浮點數(shù)、有符號整數(shù)等數(shù)據(jù)類型進行相關(guān)算術(shù)運算．它旨在為所有需要更高精度的應用程序提供最快的算法．DL-CL-PKC算法主要分為PKG節(jié)點初始化函數(shù)、部分私鑰生成函數(shù)、完全私鑰生成函數(shù)、用戶公鑰生成函數(shù)以及加密和解密函數(shù)．為了程序后續(xù)的調(diào)用,將主要算法進行了封裝．主要函數(shù)接口如表1所示.

表1 DL-CL-PKC算法函數(shù)接口Table 1 Function interfaces for the DL-CL-PKC algorithm

通過上述封裝的算法,可以在wolfSSL[16]庫中實現(xiàn)基于該算法的DTLS握手協(xié)議,具體可分為以下兩個步驟:

1)定義新的加密套件

DTLS握手過程所涉及的多種算法(密鑰交換、認證、對稱加密及哈希算法),都是通過加密套件進行定義的．測試程序會根據(jù)選擇的加密套件去執(zhí)行相應算法,本文所定義的加密套件是DTLS_PKC_WITH_AES_128_CBC_SHA512,此加密套件表明密鑰協(xié)商算法是DL-CL-PKC,對稱加密算法采用128位的AES[17]算法,加密模式采用CBC模式,哈希算法采用SHA512．

2)密鑰協(xié)商

Client端和Server端互換公鑰信息后,Client端使用密鑰交換算法計算預主密鑰,并加密發(fā)送給Server端,Server端解密得到預主密鑰,接著Server端通過預主密鑰結(jié)合隨機數(shù)做偽隨機算法后得到主密鑰和后續(xù)會話的密鑰．

通過以上兩個步驟,雙方即可在省略證書加載和認證過程的情況下正式建立連接．

3 實驗分析

本文分別在 Ubuntu 18.04.3、CentOS 3.10.0和Deepin 5.4.50系統(tǒng)上實現(xiàn)基于無證書公鑰密碼的DTLS協(xié)議．Client端將本文定義的加密套件通過ClientHello報文發(fā)送給Server端,Server端選擇此加密套件,實施本文提出的握手方法.如果Server端沒有選擇此加密套件也可以跳轉(zhuǎn)到其他加密套件,本文以PSK和ECDHE為兩個備用套件．

實驗環(huán)境為戴爾臺式機,處理器是Core(TM) i7-9700,擁有內(nèi)存32 GB,虛擬機類型為VMware Workstation Pro,虛擬機分配虛擬內(nèi)存為4 GB,虛擬機系統(tǒng)為Ubuntu 18.04.3、CentOS 3.10.0和Deepin 5.4.50．

通過將本文設(shè)計的基于DL-CL-PKC算法的DTLS握手協(xié)議與DTLS兩個備用套件PSK[18]、ECDHE[19]和基于身份標識的DTLS握手協(xié)議方案[7]進行對比,通過比較它們的消息傳輸開銷和連接時延來檢驗本文所設(shè)計方案的性能．

3.1 消息傳輸開銷

通過wireshark分別抓取4種方案交互傳輸?shù)膱笪?對比4種握手過程中產(chǎn)生的信息字節(jié)數(shù),結(jié)果如表2所示.首先可以看出DTLS備用的2個套件的交互次數(shù)都是6次,而本文提出的方案與基于身份標識的DTLS握手協(xié)議方案都將交互次數(shù)減少了1次;其次在這些交互過程中由于剔除證書發(fā)送和驗證過程,使本文設(shè)計的方案和基于身份標識的DTLS握手協(xié)議方案所需傳輸?shù)奈帐窒?shù)量也有所減少,相比PSK,發(fā)送的消息數(shù)減少了3條,而相比ECDHE,減少了8條,大大降低了握手過程中的通信流量,且本文所提方案的握手消息字節(jié)略小于基于身份標識的DTLS握手協(xié)議方案．

表2 4種方案消息傳輸開銷Table 2 Messaging overhead for the four schemes

3.2 連接時間

分別測出4種方案在以linux為內(nèi)核的3種操作系統(tǒng)中的連接時間,測量方法是記錄發(fā)送第一個報文開始到建立連接所用的時間,并且對這4種方案的連接時延進行多次測量,最后求出平均值,結(jié)果如圖3所示．由于PSK是直接以雙方事先就已經(jīng)約定好的密鑰為基礎(chǔ)來進行加密通信的,所以此方案節(jié)省了在握手過程中計算密鑰所花費的時間,并且PSK方案[18]也不需要進行證書的認證,同樣節(jié)省了連接時間,最終都可以在較小時延下完成連接,但是PSK方案安全性較低.ECDHE方案[19]需要解析證書以作認證,所以花費時間較多,完成連接的時延最大.PBC方案[7]同樣實現(xiàn)了基于無證書的DTLS握手過程,節(jié)省了連接時間,但此方案沒有考慮到PKG節(jié)點遭受攻擊造成系統(tǒng)私鑰和合法用戶私鑰泄露的問題.而本文所提方案在考慮安全性的前提下,省去證書驗證環(huán)節(jié),也可以在相對較小的時延下建立連接．和ECDHE方案[19]相比,本文所提的方案將連接時延降低了40%以上;和PBC方案[7]采用雙線性對運算獲取共享密鑰和后續(xù)會話密鑰相比,本文采用運算速度更快的離散對數(shù)運算,因此握手連接時間更短．

圖3 3種操作系統(tǒng)下的4種方案連接時間對比Fig.3 Comparison of connection time between four schemes under three operating systems

4 結(jié)束語

本文利用離散對數(shù)運算,實現(xiàn)了DL-CL-PKC算法,設(shè)計并實現(xiàn)基于改進離散對數(shù)運算的無證書公鑰密碼的DTLS握手協(xié)議,此方案可將Client端和Server端產(chǎn)生的公鑰通過擴展+publickey_share分別發(fā)送到對端,參與后續(xù)會話密鑰的生成,簡化了握手過程,減少了交互次數(shù),節(jié)省了通信開銷．實驗結(jié)果表明,本文在不降低原先DTLS安全性的基礎(chǔ)上,很大程度地縮短了連接建立時間．下一步工作將從物聯(lián)網(wǎng)應用層協(xié)議入手,將本文設(shè)計的無證書方案與應用層協(xié)議集成起來并實現(xiàn)基于無證書DTLS協(xié)議的應用層協(xié)議的加密．