何青松 王 珒 范月霞

(中國(guó)船舶重工集團(tuán)公司第七二二研究所 武漢 430205)

?

基于CPK數(shù)字簽名的TLS改進(jìn)協(xié)議*

何青松 王 珒 范月霞

(中國(guó)船舶重工集團(tuán)公司第七二二研究所 武漢 430205)

基于TLS(transport layer security)協(xié)議在防“抗抵賴(lài)性”上的不足,提出了一種針對(duì)TLS協(xié)議的認(rèn)證改進(jìn)方案,在保持TLS協(xié)議原有安全性的前提下,引入了基于CPK數(shù)字簽名的驗(yàn)證機(jī)制,對(duì)TLS協(xié)議中握手協(xié)議和記錄協(xié)議分別進(jìn)行了擴(kuò)展與改進(jìn),并且支持在握手協(xié)議中對(duì)數(shù)字簽名及密鑰進(jìn)行動(dòng)態(tài)協(xié)商,同時(shí)兼容原有的TLS協(xié)議。

組合公鑰; 數(shù)字簽名; TLS協(xié)議

Class Number TP393

1 引言

TLS(transport layer security)協(xié)議[1]用于在兩個(gè)通信實(shí)體間建立安全的信息傳輸通道,從而實(shí)現(xiàn)身份認(rèn)證、數(shù)據(jù)加密傳輸?shù)裙δ?。目?TLS協(xié)議已成為了事實(shí)上的工業(yè)標(biāo)準(zhǔn),廣泛地應(yīng)用于互聯(lián)網(wǎng)。但是,由于互聯(lián)網(wǎng)應(yīng)用環(huán)境的復(fù)雜和變化,對(duì)TLS協(xié)議提出了新的要求,有必要對(duì)TLS進(jìn)行改進(jìn)和擴(kuò)展,從而增加其機(jī)密性和完整性。本文從數(shù)字簽名入手,引入了基于CPK數(shù)字簽名的驗(yàn)證機(jī)制,通過(guò)對(duì)TLS協(xié)議進(jìn)行分析,提出TLS協(xié)議的握手協(xié)議和記錄協(xié)議改進(jìn)方法,從而使改進(jìn)和擴(kuò)展后的TLS協(xié)議內(nèi)部直接支持CPK數(shù)字簽名機(jī)制,以滿(mǎn)足應(yīng)用的需要。

2 TLS協(xié)議分析

TLS協(xié)議主要由兩個(gè)屬于不同層次上的協(xié)議組成:記錄協(xié)議(TLS record protocol)和握手協(xié)議(TLS handshake protocol)[9]。記錄協(xié)議位于可靠傳輸協(xié)議層上面,處于TLS協(xié)議中的底層,用于透明封裝各種高級(jí)應(yīng)用層協(xié)議;握手協(xié)議位于TLS協(xié)議的高層,用于在服務(wù)器和客戶(hù)傳輸數(shù)據(jù)之前進(jìn)行一些必要的準(zhǔn)備工作,如認(rèn)證對(duì)方身份,協(xié)商加密算法,以及利用公鑰加密技術(shù)生成私有信息等。

2.1 握手協(xié)議分析[8]

握手協(xié)議用于完成以下四個(gè)功能:

1) 協(xié)商客戶(hù)端與服務(wù)器之間的加密算法套件;

2) 協(xié)商所選擇加密算法使用的隨機(jī)密鑰等數(shù)據(jù);

3) 認(rèn)證服務(wù)器或者客戶(hù)端;

4) 協(xié)商實(shí)現(xiàn)會(huì)話(huà)重用等高級(jí)特征。

握手協(xié)議的主要過(guò)程[2]如圖1所示。

圖1 TLS握手協(xié)議

2.2 記錄協(xié)議分析

圖2 TLS記錄協(xié)議

TLS協(xié)議通過(guò)在握手協(xié)議之下的記錄協(xié)議來(lái)傳輸數(shù)據(jù)。發(fā)送時(shí),記錄協(xié)議把數(shù)據(jù)分成若干的數(shù)據(jù)塊,記錄協(xié)議生成MAC校驗(yàn)碼用于保證數(shù)據(jù)完整性,對(duì)MAC校驗(yàn)碼與數(shù)據(jù)片進(jìn)行加密處理,生成加密密文,再附帶記錄層的協(xié)議頭,就組成了記錄協(xié)議的一條記錄段,被發(fā)送給接收方。接收時(shí),接收方按照相反的操作,首先解開(kāi)密文數(shù)據(jù),其次對(duì)數(shù)據(jù)進(jìn)行校驗(yàn),以保證數(shù)據(jù)的完整性。

記錄協(xié)議的數(shù)據(jù)發(fā)送過(guò)程[3]如圖2所示。

2.3 應(yīng)用中存在的問(wèn)題

TLS協(xié)議自身也存在著不足,只能實(shí)現(xiàn)身份認(rèn)證和通信數(shù)據(jù)加密,無(wú)法為通信雙方提供簽名機(jī)制,從而無(wú)法提供抗抵賴(lài)的功能[4]。所以,在目前基于TLS應(yīng)用中,往往都是采用單獨(dú)的方式實(shí)現(xiàn)數(shù)字簽名和驗(yàn)證的過(guò)程,然后再利用TLS協(xié)議進(jìn)行封裝傳輸,這會(huì)給各種應(yīng)用增加額外的處理和傳輸負(fù)擔(dān),降低了應(yīng)用處理的效率。此外,各種應(yīng)用在進(jìn)行數(shù)字簽名和驗(yàn)證過(guò)程時(shí),難以直接獲得證書(shū)公、私鑰對(duì)等數(shù)據(jù)[7],不如由CPK直接產(chǎn)生所需的公、私鑰對(duì)密鑰數(shù)據(jù),由與證書(shū)私鑰打交道的TLS協(xié)議直接處理。因此,有必要在TLS協(xié)議中增加簽名的機(jī)制。

3 基于CPK的數(shù)字簽名改進(jìn)

基于已經(jīng)公布的橢圓曲線(xiàn)的數(shù)字簽名方案,本文設(shè)計(jì)出一種新的基于CPK的數(shù)字簽名方案。

3.1 密鑰提取過(guò)程

設(shè)給定用戶(hù)A的身份IDA,注冊(cè)中心為該用戶(hù)生成組合密鑰對(duì)(dA,PA),將它存儲(chǔ)在U-key中,然后發(fā)給用戶(hù)A。

簽名過(guò)程:域參數(shù)T=(a,b,G,n,p),根據(jù)發(fā)送方A的標(biāo)識(shí)產(chǎn)生組合密鑰對(duì)(dA,PA),進(jìn)行簽名:

1) 選擇一個(gè)隨機(jī)或偽隨機(jī)數(shù),使得0

2) 計(jì)算kG=(x1,y1);

3) 計(jì)算r1=x1modn,r2=y1modn,如果r1=0且r2=0,則回到第1)步;

4) 計(jì)算消息M的摘要值:H=Hash(M);

5) 計(jì)算簽名:s=(k+r1dA-r2H) modn,如果s=0則回到第1)步;

6) 發(fā)送消息M和簽名(r1,r2,s)給接收驗(yàn)證者B。

3.2 驗(yàn)證過(guò)程

驗(yàn)證方B接收到A對(duì)消息M的簽名后,根據(jù)A的標(biāo)識(shí)由公鑰因子矩陣生成的A的公鑰PA。因?yàn)锽有由注冊(cè)管理中心發(fā)放的含有B的密鑰U-key,其中包含公鑰因子矩陣。

1) 驗(yàn)證是否0

2) 計(jì)算消息M的摘要值:H=Hash(M);

3) 計(jì)算數(shù)值:(s+r2H)G-r1PA=(x′,y′);

4) 計(jì)算數(shù)值:w1=x′ modn,w2=y′ modn,如果w1=r1且w2=r2,則接收簽名;否則就拒絕接受簽名,從而丟棄消息M。

驗(yàn)證算法過(guò)程:

(s+r2H)G-r1PA=(k+r1dA-r2H+r2H)G-r1PA

=kG+r1dAG-r1PA

=kG+r1PA-r1PA

=kG

=(x′,y′)

4 TLS協(xié)議的改進(jìn)

4.1 握手協(xié)議的擴(kuò)展

改進(jìn)在握手協(xié)議時(shí),TLS客戶(hù)和服務(wù)器必須對(duì)協(xié)議中的ClientHello和ServerHello消息進(jìn)行擴(kuò)展,分別要具備聲明自身是否支持CPK簽名和指出是否要求對(duì)方出示簽名的協(xié)商機(jī)制。其次,按照TLS擴(kuò)展草案[5]中規(guī)定的擴(kuò)展協(xié)議格式,增加了signature_supported和signature_required兩個(gè)擴(kuò)展消息類(lèi)型,并分別在ClientHello消息和ServerHello消息中添加相應(yīng)的數(shù)據(jù)段,使其擴(kuò)展為ClientHelloDS消息和ServerHelloDS消息。其中,signature_supported和signature_required的取值均為0或1,并且根據(jù)不同的組合方式,其含義分別為:不支持簽名協(xié)議、支持簽名協(xié)議和不需要對(duì)方出示簽名、需要對(duì)方出示簽名四種類(lèi)型,并且規(guī)定當(dāng)signature_required為1時(shí),signature_supported必須為1。修改之后的協(xié)議描述如下:

1) 客戶(hù)端發(fā)送ClientHelloDS消息;

2) 服務(wù)器接收該消息,做出如下處理,同時(shí)生成ServerHelloDS消息。

(1)若ClientHelloDS.Signature_required=ServerHelloDS.Signature_required=0,則客戶(hù)端與服務(wù)器都不需要對(duì)方出示簽名;

(2)若ClientHelloDS.Signature_required=1,ServerHelloDS.Signature_required=0,則僅客戶(hù)端要求服務(wù)器出示簽名;

(3)若ClientHelloD.Signature_required=0,ServerHelloDS.signature_required=1,則僅服務(wù)器要求客戶(hù)端出示簽名,服務(wù)器還要發(fā)送CertificateRequest消息,要求客戶(hù)端出示自己的證書(shū);

(4)若ClientHelloDS.Signature_required=ServerHelloDS.Signature_required=1,則客戶(hù)端與服務(wù)器分別要求對(duì)方出示數(shù)字簽名,同時(shí),服務(wù)器還要向客戶(hù)端發(fā)送CertificateRequest消息,要求客戶(hù)端出示自己的證書(shū);

3) 客戶(hù)端驗(yàn)證服務(wù)器發(fā)送的證書(shū),生成ClientKeyExchange消息,發(fā)送給服務(wù)器。同時(shí),若收到服務(wù)器的CertificateRequest消息,則發(fā)送Certificate消息;

4) 服務(wù)器與客戶(hù)端分別計(jì)算出加密的密鑰和MAC校驗(yàn)碼;上述流程如圖3所示。

圖3 改進(jìn)的TLS握手協(xié)議

在這個(gè)握手流程中,根據(jù)以下流程處理:

1) 如果TLS通信雙方都不要求對(duì)方出示簽名,則握手流程與通常的TLS握手協(xié)議完全相同。

2) 如果通信的一方要求另一方出示簽名,則另一方必須在握手過(guò)程中給出自己的數(shù)字證書(shū),從而使對(duì)方可以驗(yàn)證自己對(duì)數(shù)據(jù)的簽名,否則必須向?qū)Ψ浇o出no-certificate的警告。

3) 當(dāng)TLS通信雙方的一方不支持簽名時(shí),若對(duì)方出示簽名,直接向?qū)Ψ浇o出一個(gè)signature-unsupported的警告。

4.2 記錄協(xié)議的擴(kuò)展

在TLS通信雙方完成握手過(guò)程之后,需要利用記錄協(xié)議來(lái)完成具體的CPK數(shù)字簽名和簽名串的傳輸。為與原有記錄協(xié)議的數(shù)據(jù)區(qū)分,并且兼容原有的協(xié)議格式,因此對(duì)記錄協(xié)議的數(shù)據(jù)包頭部進(jìn)行擴(kuò)展設(shè)計(jì),增加一種新的數(shù)據(jù)內(nèi)容類(lèi)型signature_data,表示該數(shù)據(jù)包為簽名頭,并在簽名頭之后附加標(biāo)識(shí)簽名的原始數(shù)據(jù)的長(zhǎng)度。處理流程為:

1) 發(fā)送方在發(fā)送完這個(gè)特殊的數(shù)據(jù)包之后,緊跟著發(fā)送用于簽名的原始數(shù)據(jù)。

2) 接收方在確認(rèn)簽名頭和原始數(shù)據(jù)都接收成功的情況下,對(duì)簽名進(jìn)行驗(yàn)證。

3) 如果接收方驗(yàn)證通過(guò),則繼續(xù)進(jìn)行接下來(lái)的數(shù)據(jù)傳輸,否則,接收方發(fā)送一個(gè)signature-verify-failed警告,通知簽名驗(yàn)證失敗。

整個(gè)發(fā)送過(guò)程如圖4所示。

圖4 改進(jìn)的TLS握手協(xié)議

5 協(xié)議改進(jìn)安全性分析

5.1 擴(kuò)展TLS協(xié)議分析

改進(jìn)后的握手協(xié)議增加了兩個(gè)擴(kuò)展字段,按照TLS擴(kuò)展草案的規(guī)定,并未透露額外的信息,因此不存在安全性問(wèn)題。

在記錄協(xié)議中,增加的額外數(shù)據(jù)并沒(méi)有帶來(lái)安全問(wèn)題。增加的CPK簽名的數(shù)據(jù)包完全是在原有TLS協(xié)議的安全機(jī)制下進(jìn)行傳輸?shù)?同樣是要經(jīng)過(guò)壓縮、生成MAC及加密的保護(hù)過(guò)程,沒(méi)有減弱協(xié)議的安全強(qiáng)度。

5.2 擴(kuò)展CPK數(shù)字簽名分析

擴(kuò)展的CPK數(shù)字簽名[10]是基于CPK組合公鑰技術(shù)和橢圓曲線(xiàn)離散對(duì)數(shù)問(wèn)題[6]設(shè)計(jì)的改進(jìn)方案,因此,基于CPK數(shù)字簽名機(jī)制的TLS協(xié)議并未帶來(lái)額外的安全隱患。其安全性分析如下:

1) 機(jī)密性:攻擊者無(wú)法從簽名中求解出k或私鑰dA。即便知道A的公鑰PA,也無(wú)法從算式dAG=PA計(jì)算出dA來(lái)。而隨機(jī)數(shù)k是由A自己隨時(shí)生成,別人無(wú)從知道。另外在簽名方程中存在兩個(gè)未知數(shù),從而保證攻擊者無(wú)法竊取A的私鑰dA或隨機(jī)數(shù)k來(lái)偽造簽名。

2) 完整性:攻擊者如果截獲簽名并篡改消息明文得M′,驗(yàn)證者B可以計(jì)算M′的摘要值Hash(M′)與Hash(M)進(jìn)行比較。若Hash(M)=Hash(M′),則簽名驗(yàn)證失敗,可得出消息明文已被篡改。

4) 該簽名方案和簽名驗(yàn)證方案均不含求逆運(yùn)算,所以提高了數(shù)字簽名的速度。

6 結(jié)語(yǔ)

本文提出了一種TLS協(xié)議的改進(jìn)方案,該方案在保持TLS協(xié)議原有的安全性的基礎(chǔ)上,引進(jìn)了基于CPK數(shù)字簽名及驗(yàn)證機(jī)制,并對(duì)現(xiàn)有的TLS協(xié)議簇進(jìn)行了改進(jìn)和擴(kuò)展,用于支持CPK數(shù)字簽名和驗(yàn)證的動(dòng)態(tài)協(xié)商。這不僅為T(mén)LS協(xié)議添加了“抗抵賴(lài)”的安全特性,同時(shí)在性能上也并未增加額外的負(fù)擔(dān),從而進(jìn)一步增加了TLS協(xié)議的安全性和實(shí)用性。

[1] Dierks T, Allen C. RFC 2246, The TLS Protocol, Version 1[S]. 1999.

[2] 任江,袁宏春.對(duì)SSL協(xié)議及其安全性分析[J].電子科技大學(xué)學(xué)報(bào),1998,27(4):416-420.

[3] Rescorla E. SSL and TLS: Designing and Building Secure Systems[M]. USA: Addison-Wesley,2000.

[4] 候小梅,莫鴻強(qiáng),毛宗源.基于SSL協(xié)議的電子商務(wù)解決方案[J].計(jì)算機(jī)工程與應(yīng)用,2001(8):35-37.

[5] Blake-Wilson S, Nystrom M, Hopwood D, et al. TLS Extensions. Internet-Draft: draft-ietf-tls-extensions-05.txt.[EB/OL]. http://www.ietf.org/internet-drafts/draft-ietf-tls-extensions-05.txt,2002.

[6] Rabah, Kefa. Elliptic curves cryptography over binary finite field GF (2m)[J]. Information Technology Journal, v5, nl, January,2006:204-229.

[7] 宋志敏,王衛(wèi)京,南相浩.SSLV3.0及其安全性分析[J].計(jì)算機(jī)工程與應(yīng)用,2000(10):145-149.

[8] PENG Changyan, ZHANG Quan, TANG Chaojing. Improved TLS handshake protocols using identity-based cryptography[C]//International Symposium on Information Engineering and Electronic Commerce. Changsha: IEEE Press,2009:135-139.

[9] DIERKS T, RESCORLA E. The transport layer security(TLS) protocol version 1.2[EB/OL]. [2011-06-29]. http://tools.ietf.org/html/rfc5246#section-7.4.1,2008.

[10] 南湘浩.CPK密碼體制與網(wǎng)際安全[M].北京:國(guó)防工業(yè)出版社,2008:32-44.

TLS Improved Protocol Based on CPK Digital Signature

HE Qingsong WANG Jing FAN Yuexia

(No. 722 Research Institute of CSIC, Wuhan 430205)

As TLS(transfer layer security) standard is deficiency and does not implicitly sign data. This paper describes an approach for modifying the TLS protocol to support theunderlying digital signature mechanism based CPK. The proposal modifies the handshake protocol to negotiate the mechanism about digital signature and dynamic key exchange, and the record layer protocol which signs and verifies the application data. The new TLS protocol is backwards compatible to allow the client to interoperate with an ordinary TLS server.

CPK, digital signature, transfer layer security(TLS) protocol

2014年9月11日,

2014年10月31日

何青松,男,碩士,工程師,研究方向:信息安全。王珒,女,碩士,工程師,研究方向:信息安全。范月霞,女,碩士,工程師,研究方向:信息安全。

TP393

10.3969/j.issn1672-9730.2015.03.024