陸思奇,周思淵,毛 穎

1(解放軍信息工程大學(xué),河南 鄭州 450001)

2(信息安全國(guó)家重點(diǎn)實(shí)驗(yàn)室(中國(guó)科學(xué)院 信息工程研究所),北京 100093)

3(中國(guó)科學(xué)院大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院,北京 100093)

網(wǎng)絡(luò)安全協(xié)議能夠解決信息的傳輸安全問(wèn)題,以互聯(lián)網(wǎng)工程任務(wù)組(Internet engineering task force,簡(jiǎn)稱(chēng)IETF)為代表的有關(guān)組織,為了彌補(bǔ)基本的TCP/IP 協(xié)議簇在安全方面的設(shè)計(jì)缺陷,對(duì)現(xiàn)有的TCP/IP 協(xié)議簇進(jìn)行設(shè)計(jì)和改進(jìn),從而構(gòu)成了包含多層網(wǎng)絡(luò)安全協(xié)議的TCP/IP 協(xié)議簇安全架構(gòu),傳輸層安全協(xié)議TLS(transport layer security)就是這個(gè)安全架構(gòu)中重要的組成部分.

TLS 協(xié)議是在安全套階層協(xié)議SSL(secure socket layer)獲得了推廣使用之后,由IETF 基于SSL3.0 協(xié)議[1]制定的正式行業(yè)標(biāo)準(zhǔn)[2],TLS1.2[3]為當(dāng)前大部分瀏覽器和使用HTTPS 協(xié)議的Web 服務(wù)主要使用的版本.然而,隨著網(wǎng)絡(luò)環(huán)境日趨復(fù)雜,TLS1.2 也開(kāi)始暴露出越來(lái)越多的漏洞,既有加密算法的漏洞,如RC4 的漏洞[4],也有協(xié)議設(shè)計(jì)中的漏洞,如 Lucky 13[5]、POODLE[6]、Logjam[7]、三次握手攻擊[8],以及實(shí)現(xiàn)過(guò)程中的漏洞,如Heartbleed[9]、狀態(tài)機(jī)攻擊[10]等.雖然很多安全漏洞已經(jīng)通過(guò)不定期更新和補(bǔ)丁解決,但由于TLS 龐大的規(guī)模以及許多不同的設(shè)置,這些反復(fù)的修改增加了TLS 的復(fù)雜性和部署難度.因此,IETF 的TLS 工作組開(kāi)始著手設(shè)計(jì)“下一代TLS”——TLS1.3.目前,TLS1.3 正處于草案階段[11],吸引了協(xié)議研究者們的廣泛關(guān)注,既有針對(duì)TLS1.3攻擊方法的研究,如證書(shū)轉(zhuǎn)發(fā)攻擊[12]、中間人攻擊[13]、DROWN[14]、Client AuthenticationAttack[15,16],也有對(duì)TLS1.3 的安全性分析和建議,如OPTLS[17],TLS-Attacker 模型[18]等.

為了滿(mǎn)足更高的安全需求,設(shè)計(jì)開(kāi)發(fā)出更加安全穩(wěn)定的網(wǎng)絡(luò)安全協(xié)議,對(duì)網(wǎng)絡(luò)安全協(xié)議進(jìn)行更加嚴(yán)格、可信的分析,一直以來(lái)就是信息安全和密碼學(xué)領(lǐng)域的一大熱點(diǎn).形式化方法使用數(shù)學(xué)的方法描述和推理計(jì)算機(jī)系統(tǒng),具有準(zhǔn)確的語(yǔ)法以及語(yǔ)義,并通過(guò)精確的數(shù)學(xué)手段和強(qiáng)大的分析工具實(shí)現(xiàn)技術(shù)支持.簡(jiǎn)而言之,就是規(guī)范語(yǔ)言加形式推理[19].形式化方法遍歷搜索協(xié)議在運(yùn)行過(guò)程中所有可能的狀態(tài),往往能夠挖掘出安全協(xié)議中難以發(fā)現(xiàn)的細(xì)微漏洞,是目前非常流行的安全協(xié)議分析方法.

本文參考了Krawczyk 等人[17]關(guān)于OPTLS 的工作,使用形式化分析工具Scyther 分析了CK 模型下對(duì)Early Data 的具體攻擊.一方面,Early Data 不具有PFS 安全,數(shù)據(jù)可能被攻擊者竊取;另一方面,Early Data 無(wú)法抵抗KCI 攻擊.根據(jù)分析結(jié)果,本文對(duì)TLS1.3 協(xié)議進(jìn)行了優(yōu)化,有效提高了協(xié)議的安全性.

本文第1 節(jié)介紹TLS1.3 和Syther 等預(yù)備知識(shí).第2 節(jié)為使用Scyther 工具對(duì)TLS1.3 協(xié)議進(jìn)行分析的過(guò)程和結(jié)論.第3 節(jié)基于TLS1.3 中的1-RTT semi-static 模式設(shè)計(jì)一種優(yōu)化的協(xié)議,在CK 安全模型下從安全性證明和形式化分析的角度證明優(yōu)化協(xié)議能夠抵抗KCI 攻擊,并進(jìn)行效率分析.第4 節(jié)對(duì)本文的工作進(jìn)行小結(jié),進(jìn)一步明確后續(xù)研究方向.

1 預(yù)備知識(shí)

1.1 Scyther簡(jiǎn)介

Scyther 是一款形式化分析安全協(xié)議的工具,該工具由牛津大學(xué)的Cremers 教授及其團(tuán)隊(duì)[20]所開(kāi)發(fā).這款工具綜合運(yùn)用了定理證明以及模型檢測(cè)等分析技術(shù),具有如下特點(diǎn).

(1)能夠多協(xié)議并行分析;

(2)能夠通過(guò)無(wú)限會(huì)話(huà)來(lái)驗(yàn)證協(xié)議;

(3)能夠通過(guò)描述協(xié)議,產(chǎn)生所有協(xié)議可能行為的有限表示;

(4)能夠通過(guò)組合敵手能力構(gòu)造各種安全模型.

Scyther 對(duì)協(xié)議分析者最友好的一面是其基于按鈕的使用界面以及可視化的分析結(jié)果,這使得協(xié)議的研究過(guò)程能夠更加方便和直觀.除此之外,Scyther 通過(guò)控制主體執(zhí)行輪數(shù)和約束狀態(tài)空間對(duì)搜索狀態(tài)進(jìn)行雙重限制,與之前僅通過(guò)約束狀態(tài)空間的方法相比,減少了攻擊漏報(bào)的可能性,而且不會(huì)因?yàn)闋顟B(tài)爆炸而出現(xiàn)無(wú)分析結(jié)果的情況.Scyther 的協(xié)議形式化語(yǔ)言SPDL 簡(jiǎn)單易學(xué),盡可能分割我們?cè)诎踩珔f(xié)議形式化分析中的要點(diǎn),即明確區(qū)分了協(xié)議的靜態(tài)描述、動(dòng)態(tài)行為以及敵手模型.更進(jìn)一步講,該語(yǔ)言模型實(shí)現(xiàn)了多方協(xié)議并行運(yùn)作的直觀掌控、安全聲明的局部化、局部常量與角色實(shí)例的綁定以及初始敵手知識(shí)集合的簡(jiǎn)明定義.

Scyther 曾經(jīng)被用來(lái)分析過(guò)許多著名協(xié)議,除了Cremers[21,22]曾經(jīng)用其分析過(guò)IKEv1 和IKEv2 協(xié)議套件和ISO/IEC 9798 系列認(rèn)證協(xié)議,Yang 和Oleshchuk 等人[23,24]還使用Scyther 分析了群認(rèn)證協(xié)議,Ray 和Chowdhury等人[25]則使用Scyther 分析了物聯(lián)網(wǎng)協(xié)議.該工具最新的版本為Scyther v1.1.3(標(biāo)準(zhǔn)版本,如果需要支持更多敵手模型,可以選擇Scyther Compromise,其最新的版本為Scyther Compromise-0.9.2).除此之外,該團(tuán)隊(duì)還開(kāi)發(fā)了兩款相關(guān)的工具,分別是Scyther-proof[26]和Tamarin[27].

本文使用的Scyther 工具版本為Scyther Compromise-0.9.1,該工具可在Linux,Windows 和Mac OS X 系統(tǒng)下運(yùn)行.文中實(shí)驗(yàn)所選擇的系統(tǒng)環(huán)境為英特爾i5 的2.5GHz 處理器、Ubuntu-16.04 操作系統(tǒng)、4G 內(nèi)存的筆記本電腦.對(duì)Ubuntu 原有源進(jìn)行添加和更新后,安裝python,graphviz,python-wxgdk3.0 插件,解壓后即可使用.

1.2 CK安全模型

CK(canetti-krawczyk)模型[28]對(duì)敵手的能力進(jìn)行了形式化的描述,反映了敵手在開(kāi)放網(wǎng)絡(luò)環(huán)境中擁有的真實(shí)攻擊能力:除了能夠調(diào)度協(xié)議事件以及控制通信鏈路以外,攻擊者還能夠訪問(wèn)協(xié)議中使用或生成的一些秘密信息.具體來(lái)說(shuō),CK 模型定義了一個(gè)“中間人”攻擊者A,A全面控制通信鏈路,能夠攔截和修改消息、延遲或阻止消息傳遞、插入自己的消息、在不同的會(huì)話(huà)中交互消息以及安排所有會(huì)話(huà)的激活和會(huì)話(huà)消息的傳遞.此外,A還被允許通過(guò)以下查詢(xún)獲取信息.

(1)會(huì)話(huà)狀態(tài)暴露(session-state reveal):針對(duì)還未完成的會(huì)話(huà)(如輸出會(huì)話(huà)密鑰之前),A能夠通過(guò)此查詢(xún)得到特定會(huì)話(huà)的狀態(tài)(如臨時(shí)DH值的秘密指數(shù),即臨時(shí)私鑰);

(2)會(huì)話(huà)密鑰查詢(xún)(session-key query):在單個(gè)會(huì)話(huà)完成后,A能夠通過(guò)此查詢(xún)得到會(huì)話(huà)密鑰(在現(xiàn)實(shí)中,該查詢(xún)可通過(guò)密碼學(xué)分析、已知密鑰攻擊等方法實(shí)現(xiàn));

(3)腐化參與者(party corruption):A能夠攻陷實(shí)體,得到長(zhǎng)期私鑰以及和會(huì)話(huà)具體相關(guān)的信息.此時(shí),A可控制通信方所有行為.

這種模型允許攻擊者顯示一方測(cè)試會(huì)話(huà)時(shí)的長(zhǎng)期私鑰或顯示一方的臨時(shí)私鑰,能幫助敵手獲得更強(qiáng)的攻擊能力.

1.3 TLS1.3的安全性質(zhì)

TLS1.3 握手協(xié)議旨在通過(guò)認(rèn)證密鑰交換機(jī)制(AKE)來(lái)協(xié)商密鑰,這些密鑰可以被記錄層用來(lái)提供關(guān)鍵的安全保證,包括消息的保密性和完整性.在0-RTT 握手的情況下,應(yīng)用程序數(shù)據(jù)由PSK 保護(hù),作為客戶(hù)端第1 條消息的一部分.

本文分析TLS1.3 協(xié)議以下安全性質(zhì).

1.會(huì)話(huà)密鑰安全:一個(gè)密鑰協(xié)商協(xié)議被稱(chēng)為會(huì)話(huà)密鑰安全的,如果它對(duì)于任何攻擊者都滿(mǎn)足如下性質(zhì):

(1)未被攻陷的協(xié)議參與者在完成匹配的會(huì)話(huà)后生成的會(huì)話(huà)密鑰相同;

(2)攻擊者從協(xié)議輸出的會(huì)話(huà)密鑰和一個(gè)隨機(jī)值中區(qū)分出會(huì)話(huà)密鑰的概率不超過(guò)0.5+ε(ε為一個(gè)可以忽略不計(jì)的概率);

2.完美前向安全PFS(perfect forward secrecy)[29]:即使已經(jīng)泄露了用來(lái)產(chǎn)生會(huì)話(huà)密鑰的長(zhǎng)期密鑰,也不會(huì)影響到之前使用的會(huì)話(huà)密鑰的安全性,從而確保了之前通信內(nèi)容也是安全的.這意味著假設(shè)存在一個(gè)敵手能夠腐化服務(wù)器獲得長(zhǎng)期私鑰,在這之前的會(huì)話(huà)密鑰仍然能夠保證安全性,或者導(dǎo)出密鑰時(shí)不使用長(zhǎng)期密鑰,而是使用臨時(shí)參數(shù)完成密鑰生成;

3.抗密鑰泄露偽裝攻擊KCI(key compromise impersonation):如果參與協(xié)議的用戶(hù)A的長(zhǎng)期私鑰泄露,則攻擊者能夠利用A的私鑰偽裝成A的身份與其他用戶(hù)執(zhí)行協(xié)議,而不能偽裝成其他用戶(hù)與A成功完成協(xié)議.

1.4 GDH問(wèn)題

(1)CDH 問(wèn)題:輸入g,gx,gy,輸出gxy;

(2)DDH 問(wèn)題:輸入gx,gy,gz,判定gxy=gz是否成立.

在此基礎(chǔ)上,定義GDH(gap diffie-hellman)問(wèn)題[30]:在假定擁有解決DDH 問(wèn)題的有效方法的前提下,求解CDH 問(wèn)題.即:輸入g,gx,gy和一個(gè)解決了DDH 問(wèn)題的PPT 算法,輸出gxy.

2 TLS1.3協(xié)議的形式化分析

2.1 TLS握手協(xié)議

絕大多數(shù)的安全協(xié)議都采用了“認(rèn)證密鑰協(xié)商+對(duì)稱(chēng)加密傳輸”的結(jié)構(gòu),TLS 也是如此.因此,TLS 的主體就是使用對(duì)稱(chēng)加密傳輸信息的記錄協(xié)議,以及為記錄協(xié)議生成雙方共享密鑰的握手協(xié)議.除此之外,TLS 還有兩個(gè)比較簡(jiǎn)單的輔助協(xié)議:用來(lái)報(bào)錯(cuò)和安全斷連的警告協(xié)議和用來(lái)通知對(duì)方從握手協(xié)議切換到記錄協(xié)議的更改密碼規(guī)范協(xié)議.其中,后者因?yàn)樽饔貌淮?已經(jīng)在TLS1.3 草案中被刪除.以上的4 個(gè)協(xié)議構(gòu)成了圖1 的TLS 協(xié)議分層框架.以TCP 為例,記錄協(xié)議在TCP 流上提供分包,其他協(xié)議都封裝在記錄協(xié)議的包里,然后在TCP 層傳輸.

Fig.1 TLS protocol stack圖1 TLS 協(xié)議棧

在TLS 的協(xié)議棧中,握手協(xié)議是最關(guān)鍵的部分,也是TLS1.3 主要修改的部分.因此,本文針對(duì)TLS1.3 的分析主要是對(duì)TLS1.3 握手協(xié)議的分析.對(duì)于TLS1.3 握手協(xié)議的細(xì)節(jié),后面將在第2.3 節(jié)中進(jìn)行詳細(xì)的介紹,這里只對(duì)基本的TLS 握手協(xié)議流程進(jìn)行描述.

建立TCP 連接之后,開(kāi)始進(jìn)入TLS 的握手階段.在這個(gè)階段,客戶(hù)端和服務(wù)器交換參數(shù)并進(jìn)行密鑰協(xié)商,傳統(tǒng)的握手協(xié)議流程如圖2所示(圖中白底框表示可選的消息,或者在某些情況可能會(huì)發(fā)送的消息).

Fig.2 Basic handshake protocol flow圖2 基本握手協(xié)議流程

2.2 1-RTT握手和0-RTT數(shù)據(jù)

TLS1.3 在TLS1.2 的基礎(chǔ)上做了許多重大改進(jìn),比如在記錄協(xié)議層禁用AEAD 之外的其他算法、在握手協(xié)議層去除靜態(tài)RSA 和DH 密鑰協(xié)商以及去除更改密碼規(guī)范協(xié)議等等.上述這些改進(jìn)的目的同之前TLS 的升級(jí)一樣,都是為了增強(qiáng)TLS 的安全性.除此之外,IETF 還考慮了一個(gè)更現(xiàn)實(shí)的問(wèn)題,那就是提升協(xié)議的運(yùn)行速度.在互聯(lián)網(wǎng)普及的今天,Web 服務(wù)的成功與否與網(wǎng)頁(yè)加載速度的快慢有著密切聯(lián)系,Amazon 公司曾在實(shí)驗(yàn)中發(fā)現(xiàn):如果網(wǎng)頁(yè)加載延遲100ms,銷(xiāo)售量就會(huì)隨之減少1%.而對(duì)于服務(wù)器在地理位置上相距很遠(yuǎn)的用戶(hù)來(lái)說(shuō),網(wǎng)絡(luò)的延遲則更加不能忽略.因此,人們希望既不犧牲安全性又能夠盡量地降低協(xié)議的運(yùn)行時(shí)間.針對(duì)這一需求,TLS1.3 做出了如下改進(jìn).

(1)RTT 握手支持;

(2)RTT 數(shù)據(jù)支持.

RTT 是Round Trip Time 的縮寫(xiě),即消息的往返時(shí)間.對(duì)于TLS1.2 來(lái)說(shuō),完成一次握手需要兩個(gè)RTT:第1 個(gè)是ClientHello 和ServerHello,用于協(xié)商密鑰交換算法以及各種不同的密碼參數(shù);第2 個(gè)是ClientKeyExchange和ServerKeyExchange,也就是使用前一個(gè)RTT 協(xié)商的算法和參數(shù)進(jìn)行密鑰交換.TLS1.3 為了減少RTT,決定取消第1 個(gè)RTT,讓客戶(hù)端緩存最近服務(wù)器使用的算法和參數(shù),直接使用該緩存的算法和參數(shù),與服務(wù)器進(jìn)行密鑰交換.如果客戶(hù)端使用的算法和參數(shù)錯(cuò)誤,則服務(wù)器返回HelloRetryRewuest 消息,告知正確的算法和參數(shù),讓客戶(hù)端重啟握手,這就是1-RTT 握手.該握手方式的可行性來(lái)源于TLS1.3 對(duì)算法的削減,許多不安全的算法被拋棄,剩下的密鑰協(xié)商算法其實(shí)只有屈指可數(shù)的幾種.而可用的密鑰協(xié)商算法越少,那么1-RTT 握手成功的可能性就越高;并且即使客戶(hù)端使用了錯(cuò)誤的算法,也只需要增加一個(gè)RTT 的代價(jià),和TLS1.2 相比沒(méi)有增加額外的RTT.這樣,TLS1.3 基本沒(méi)有副作用,便大大降低了TLS 握手協(xié)議所需要的平均時(shí)長(zhǎng).

除了上述的1-RTT 握手,TLS1.3 還借鑒了Google 的QUIC 協(xié)議[31],設(shè)計(jì)了一個(gè)0-RTT 數(shù)據(jù)的解決方案.所謂0-RTT,是指在握手協(xié)議的第1 條消息中就允許客戶(hù)端發(fā)送一些數(shù)據(jù)而不必等到握手協(xié)議結(jié)束.具體的解決方法是:允許客戶(hù)端緩存服務(wù)器的長(zhǎng)期公鑰,在第1 條消息中直接利用該長(zhǎng)期公鑰生成一個(gè)會(huì)話(huà)密鑰發(fā)送部分應(yīng)用層數(shù)據(jù),另一部分應(yīng)用層數(shù)據(jù)則等到完整的握手協(xié)議之后發(fā)送.在現(xiàn)實(shí)應(yīng)用中,對(duì)于近期曾經(jīng)訪問(wèn)過(guò)的網(wǎng)站,用戶(hù)可以在第1 次向服務(wù)器發(fā)送消息時(shí)就帶上一部分應(yīng)用數(shù)據(jù),從而達(dá)到提高網(wǎng)頁(yè)加載速度的目的.

值得注意的是:0-RTT 數(shù)據(jù)只是在1-RTT 握手的基礎(chǔ)上添加的數(shù)據(jù),這個(gè)數(shù)據(jù)也被稱(chēng)為Early Data,握手的其他部分依然保持1-RTT 原有的消息.另外,這些數(shù)據(jù)不能抵抗重放攻擊,該漏洞可通過(guò)一些獨(dú)立于密鑰交換的其他機(jī)制解決,如果想要利用0-RTT 機(jī)制,則應(yīng)該在應(yīng)用層提供重放保護(hù).

2.3 支持0-RTT數(shù)據(jù)的模式

TLS1.3 有3 種模式支持0-RTT 數(shù)據(jù):1-RTT semi-static,PSK,PSK-DHE.圖3 為包含0-RTT 數(shù)據(jù)的消息交互過(guò)程,表1 表示各部分交互消息的意義,表2 為3 種模式所使用的密鑰導(dǎo)出表.

Fig.3 Handshake process that contains 0-RTT data flow圖3 包含0-RTT 數(shù)據(jù)的握手流程

Table 1 Protocol notation表1 符號(hào)定義

Table 2 Key derivation table表2 密鑰導(dǎo)出表

由圖可知,客戶(hù)端Client 通過(guò)chello 消息傳遞密鑰協(xié)商的參數(shù),通過(guò)ceks 傳遞密鑰協(xié)商過(guò)程中的臨時(shí)公鑰gx,并利用服務(wù)器的長(zhǎng)期公鑰加密(或客戶(hù)端臨時(shí)私鑰和服務(wù)器長(zhǎng)期公鑰計(jì)算得出的eadk=gxs)保護(hù)Early Data 發(fā)送給服務(wù)器Server,服務(wù)器端接收到消息后,向客戶(hù)端Client 回復(fù)密鑰協(xié)商的參數(shù)shello、臨時(shí)公鑰gy以及用共享密鑰gxy保護(hù)的消息,該消息包括服務(wù)器的長(zhǎng)期公鑰和對(duì)協(xié)議傳遞消息的確認(rèn).

2.3.1 1-RTT semi-static 模式

首先分析1-RTT semi-static 模式.在使用Scyther 引擎提供的SPDL 語(yǔ)言進(jìn)行描述時(shí),為了區(qū)別臨時(shí)私鑰和長(zhǎng)期私鑰,本文采用在臨時(shí)密鑰生成時(shí)加入隨機(jī)數(shù)tempx和tempy的方法,即用(sk(c),tempx),(sk(s),tempy)表示客戶(hù)端、服務(wù)器的臨時(shí)私鑰,用g1(sk(c),tempx),g1(sk(s),tempy)表示客戶(hù)端、服務(wù)器的臨時(shí)公鑰.因?yàn)閠empx和tempy是保密的,這樣在長(zhǎng)期私鑰被泄露時(shí),能夠保證臨時(shí)私鑰仍然是安全的.此外,本文使用CK 模型作為安全模型,這種模型允許攻擊者顯示一方測(cè)試會(huì)話(huà)時(shí)的靜態(tài)私鑰(長(zhǎng)期私鑰)或顯示一方的臨時(shí)私鑰,能幫助敵手獲得更強(qiáng)的攻擊條件和能力.Scyther 工具在Settings標(biāo)簽里面提供了強(qiáng)安全模型的設(shè)置面板,根據(jù)Cas Cremers[32,33]對(duì)CK等強(qiáng)安全模型的研究,CK 模型允許敵手得知通信方長(zhǎng)期私鑰和協(xié)議執(zhí)行過(guò)程的中間狀態(tài),用以解釋CK 模型下的前向保密性Long-term Key Reveal after claim(PFS)、密鑰泄露偽裝攻擊Actor(KCI[34])和狀態(tài)泄露攻擊State Reveal.此外,雙方協(xié)商的共享密鑰還要求抵抗已知會(huì)話(huà)密鑰泄露攻擊Session-Key Reveal.因此,敵手模型的設(shè)置如圖4所示.最后點(diǎn)擊“Verify automatic claims”進(jìn)行自動(dòng)驗(yàn)證,結(jié)果如圖5所示.

Fig.4 Setting attacker model圖4 設(shè)置敵手模型

Fig.5 Attack paths of 1-RTT semi-static mode圖5 1-RTT semi-stati 模式的攻擊路徑

從運(yùn)行結(jié)果可以看出:Scyther 工具分別在客戶(hù)端和服務(wù)器的角度對(duì)協(xié)議執(zhí)行過(guò)程中所有參數(shù)的機(jī)密性進(jìn)行了驗(yàn)證,并對(duì)雙方的雙向認(rèn)證過(guò)程中的一致性Niagree 和同步性Nisynch 進(jìn)行驗(yàn)證.關(guān)于Early Data 參數(shù)的機(jī)密性驗(yàn)證,結(jié)果是不安全的(fail),分別在客戶(hù)端和服務(wù)器端存在兩種攻擊,點(diǎn)擊“1 attack”按鈕可查看詳細(xì)的攻擊路徑,分別如圖6 和圖7所示.此外,Scyther 還分析出了一些其他的攻擊,如隨機(jī)數(shù)rc/rs 和協(xié)議參數(shù)negotc/ negots的機(jī)密性,這些參數(shù)在協(xié)議交互過(guò)程中本就是明文通信的,它們的泄露并不影響認(rèn)證密鑰協(xié)商過(guò)程的安全性,所以它們的安全性不在考慮范圍之內(nèi).而關(guān)于認(rèn)證方面,Niagree 和Nisynch 所展示的攻擊則與圖7 中的攻擊路徑完全相同,這也說(shuō)明密鑰泄露偽裝攻擊KCI 破壞的是雙方的認(rèn)證安全.

Fig.6 Early Data leaked in 1-RTT semi-static mode圖6 1-RTT semi-static 模式下的Early Data 泄露

Fig.7 KCI attack in 1-RTT semi-static mode圖7 1-RTT semi-static 模式下的KCI 攻擊

圖6 中的攻擊描述的是1-RTT semi-static 模式下Early Data 的泄露過(guò)程,兩個(gè)run 之間交互的路徑表示正常的協(xié)議交互流程.可以觀察到:在扮演客戶(hù)端角色的Bob(C)向扮演服務(wù)器角色的Alice(S)發(fā)送消息M7(即Bob的公鑰)時(shí),敵手可以截獲這條消息,再通過(guò)CK 模型腐化Alice 獲得Alice 的長(zhǎng)期私鑰,從而計(jì)算出用于加密Early Data 的密鑰eadk.這時(shí)再截獲M11 消息,即可對(duì)其中加密的Early Data 進(jìn)行解密.

具體攻擊描述如下.

(1)客戶(hù)端C與服務(wù)器S正常通信,C使用自己的私鑰和S中的長(zhǎng)期公鑰計(jì)算出密鑰eadk,用eadk 加密在第1 條消息中發(fā)送的Early Data.此外,C還需要向S發(fā)送自己的公鑰;

(2)攻擊者A截獲C向S發(fā)送的C的公鑰以及加密后的Early Data 密文;

(3)A使用C的公鑰和通過(guò)腐化參與者獲取的S的長(zhǎng)期私鑰計(jì)算出密鑰eadk;

(4)A使用eadk 解密Early Data,獲得明文.

圖7 中的攻擊路徑描述的是1-RTT semi-static 模式下KCI 攻擊的流程.攻擊者在扮演客戶(hù)端的角色Bob(C)向扮演服務(wù)器的角色Alice(S)發(fā)送消息M7(即Bob 的公鑰)時(shí)將其截獲,再通過(guò)CK 模型腐化Alice 獲得Alice的長(zhǎng)期私鑰,從而計(jì)算出密鑰eadk.此時(shí),攻擊者可以自己偽造一個(gè)新的Early Data,用eadk 加密發(fā)送給Alice,則Alice 會(huì)將這條偽造的消息當(dāng)作是Bob 發(fā)送的Early Data,并繼續(xù)進(jìn)行之后正常的協(xié)議流程.這樣,攻擊者就能夠成功冒充Bob 向Alice 發(fā)送消息.

具體攻擊描述如下.

(1)客戶(hù)端C與服務(wù)器S正常通信,C使用自己的私鑰和S 中的長(zhǎng)期公鑰計(jì)算出密鑰eadk,用eadk 加密在第1 條消息中發(fā)送的Early Data.此外,C還需要向S發(fā)送自己的公鑰;

(2)攻擊者A截獲C向S發(fā)送的C的公鑰;

(3)A使用C的公鑰和通過(guò)通過(guò)腐化參與者獲取的S的長(zhǎng)期私鑰計(jì)算出密鑰eadk;

(4)A可以任意偽造Early Data,使用eadk 加密發(fā)送給S,S則會(huì)認(rèn)為這條消息來(lái)自于C.

綜上所述,根據(jù)Scyther 分析的結(jié)果,1-RTT semi-static 模式下的0-RTT 數(shù)據(jù)存在如下漏洞.

(1)0-RTT 數(shù)據(jù)沒(méi)有PFS 安全;

(2)無(wú)法抵抗KCI 攻擊,即:如果服務(wù)器的長(zhǎng)期私鑰被攻擊者竊取了,則攻擊者可以偽裝成任意客戶(hù)端向服務(wù)器發(fā)送任意偽造的Early Data.當(dāng)然,攻擊者擁有服務(wù)器的長(zhǎng)期私鑰,模擬服務(wù)器與客戶(hù)端通信也是平凡的;

(3)0-RTT 中的數(shù)據(jù)能夠被跨連接重放.

2.3.2 PSK 模式

如表2所示,在PSK 模式中,所有的密鑰都由一個(gè)預(yù)共享密鑰psk 導(dǎo)出.因此,在用SPDL 語(yǔ)言描述時(shí),將psk定義為const 常量,表示敵手有獲取它的能力.點(diǎn)擊“Verify automatic claims”進(jìn)行自動(dòng)驗(yàn)證,得到如圖8所示結(jié)果.

Fig.8 Attack paths of PSK mode圖8 PSK 模式的攻擊路徑

從運(yùn)行結(jié)果中可以看出:如果psk 被泄露,則Early Data 和Application Data 都將失去安全性,即二者均沒(méi)有達(dá)到PFS 安全的要求.這是由于PSK 模式下,雙方?jīng)]有臨時(shí)私鑰和臨時(shí)公鑰參與密鑰協(xié)商過(guò)程,在強(qiáng)安全模型下,整個(gè)協(xié)議僅使用一個(gè)psk 導(dǎo)出密鑰會(huì)導(dǎo)致攻擊者能夠偽造協(xié)議中的任何消息,包括Finished 消息中的MAC,攻擊路徑如圖9所示.

Fig.9 MAC forged in PSK mode圖9 PSK 模式下的MAC 偽造

在該攻擊中,一個(gè)已知psk 的攻擊者可以截獲扮演客戶(hù)端的角色Bob(C)的ClientHello(圖中表示為chello)消息,并偽造一個(gè)ServerHello(圖中表示為shello)消息返回給Bob;最后計(jì)算出對(duì)應(yīng)的MAC,加密發(fā)送給Bob,其中,計(jì)算MAC 的密鑰sfk 和握手密鑰htk 都由psk 導(dǎo)出.

具體攻擊描述如下.

(1)攻擊者A通過(guò)一定方法獲取客戶(hù)端C與服務(wù)器S的預(yù)共享密鑰psk;

(2)A劫持C與S的會(huì)話(huà),攔截所有C向S發(fā)送的消息;

(3)A偽造一個(gè)ServerHello 消息返回給C;

(4)A使用psk 計(jì)算一個(gè)MAC,MAC 的內(nèi)容包括C發(fā)送的ClientHello 消息、A偽造的ServerHello 消息以及psk 的值;

(5)A將MAC 用psk 加密發(fā)送給C,完成1-RTT 握手,偽裝成服務(wù)器與C建立會(huì)話(huà).

可以說(shuō),這種模式的安全性完全取決于psk 的保密性,一旦psk 被攻擊者獲取,整個(gè)協(xié)議流程都將變得極其不安全.

2.3.3 PSK-DHE 模式

PSK-DHE 在PSK 模式的基礎(chǔ)上增加了一輪DH 交換,使Application Data 滿(mǎn)足PFS 安全的要求.為了區(qū)分臨時(shí)私鑰和長(zhǎng)期私鑰,采用與第2.3.1 節(jié)相同的方式表示客戶(hù)端與服務(wù)器的臨時(shí)私鑰.運(yùn)行結(jié)果如圖10所示.

Fig.10 Attack paths of PSK-DHE mode圖10 PSK-DHE 模式的攻擊路徑

從圖10 中可以看出:Data 的Secret 屬性為OK,即Application Data 滿(mǎn)足PFS 安全.由于PSK-DHE 模式的架構(gòu)與1-RTT semi-static 模式類(lèi)似,只是把使用服務(wù)器長(zhǎng)期密鑰進(jìn)行的一輪DH 交換改為使用預(yù)共享密鑰機(jī)制,因此可以看到:PSK-DHE 模式中,Early Data 的安全性類(lèi)似1-RTT semi-static 模式,仍然沒(méi)有達(dá)到PFS 安全,也不能抵抗KCI 攻擊.攻擊路徑如圖11(a)和圖11(b)所示,攻擊流程與1-RTT semi-static 模式下攻擊相同.

Fig.11 Early Data leaked and KCI attack in PSK-DHE mode圖11 PSK-DHE 模式下的Early Data 泄露和KCI 攻擊

3 優(yōu)化協(xié)議方案

從上述結(jié)果可以看出:對(duì)于一個(gè)能夠獲取服務(wù)器長(zhǎng)期私鑰的敵手來(lái)說(shuō),0-RTT 數(shù)據(jù)將變得不再安全.事實(shí)上,這一問(wèn)題對(duì)于Google 的QUIC 協(xié)議同樣存在,但是因?yàn)镼UIC 協(xié)議主要應(yīng)用在谷歌瀏覽器上,在訪問(wèn)網(wǎng)站時(shí),通常使用GET 作為建立連接的第1 個(gè)請(qǐng)求,所以0-RTT 中的數(shù)據(jù)敏感性可能并不是很高,故其安全性可以選擇忽視.然而對(duì)于使用POST 作為第1 個(gè)請(qǐng)求的連接,比如微信的短連接,發(fā)送給服務(wù)器端的都是上層安全性要求很高的業(yè)務(wù)數(shù)據(jù),在這種情況下,0-RTT 數(shù)據(jù)的安全問(wèn)題必須考慮.對(duì)此,服務(wù)器長(zhǎng)期私鑰對(duì)應(yīng)的公鑰其緩存時(shí)間必須嚴(yán)格限制.通常,服務(wù)器通過(guò)ServerConfiguration 消息將長(zhǎng)期公鑰發(fā)送給客戶(hù)端.ServerConfiguration 的數(shù)據(jù)結(jié)構(gòu)如下.

其中,expiration_date 就是該ServerConfiguration 的有效使用期限,被設(shè)定為小于7 天.也就是說(shuō),客戶(hù)端緩存服務(wù)器半靜態(tài)公鑰的時(shí)間不得超過(guò)7天.

3.1 優(yōu)化協(xié)議的結(jié)構(gòu)

從ServerConfiguration 的有效使用期限可以看出,客戶(hù)端需要頻繁地緩存半靜態(tài)公鑰.這對(duì)于握手協(xié)議的效率來(lái)說(shuō)造成了一定的影響,并且也無(wú)法從根本上解決0-RTT 數(shù)據(jù)的安全性問(wèn)題.關(guān)于0-RTT 數(shù)據(jù)的安全性問(wèn)題,根據(jù)第2 節(jié)中形式化分析的結(jié)果,主要包括沒(méi)有PFS 安全和無(wú)法抵抗KCI 攻擊.本文基于1-RTT semi-static模式設(shè)計(jì)了一種新的支持0-RTT 數(shù)據(jù)的協(xié)議,該協(xié)議可以有效抵抗KCI 攻擊,提高了0-RTT 數(shù)據(jù)的安全性.協(xié)議的消息交互過(guò)程如圖12所示,由圖可見(jiàn):相比原協(xié)議傳輸,優(yōu)化后的協(xié)議在原Early Data 消息的基礎(chǔ)上,添加了客戶(hù)端對(duì)Early Data 和時(shí)間戳的簽名.

Fig.12 Handshake process of the optimized protocol圖12 優(yōu)化協(xié)議的握手流程

服務(wù)器在收到客戶(hù)端的第1 條消息后,首先計(jì)算出eadk 對(duì)0-RTT 數(shù)據(jù)進(jìn)行解密,然后使用客戶(hù)端的公鑰對(duì)其中的簽名進(jìn)行解密,解密后對(duì)時(shí)間戳進(jìn)行驗(yàn)證.此外,將時(shí)間戳TimeStamp 放在簽名中,同樣防止了敵手對(duì)時(shí)間戳的篡改,從而排除重放攻擊的可能,再與Early Data 的Hash 值進(jìn)行對(duì)比:如果二者不匹配,則認(rèn)為這不是一個(gè)合法的客戶(hù)端發(fā)送的0-RTT 數(shù)據(jù),服務(wù)器應(yīng)該選擇立即丟棄這個(gè)數(shù)據(jù).

3.2 優(yōu)化協(xié)議的安全性證明

本文采用了CK 模型對(duì)上述優(yōu)化協(xié)議進(jìn)行分析,該模型在可信的計(jì)算環(huán)境下能夠簡(jiǎn)化協(xié)議的設(shè)計(jì),使協(xié)議更加具有普遍性和實(shí)用性.

使用基于game 的方法對(duì)優(yōu)化協(xié)議的安全性進(jìn)行分析,證明在簽名算法的安全性和Gap-DH 問(wèn)題的復(fù)雜性以及密鑰導(dǎo)出函數(shù)的安全性的前提下,該協(xié)議能夠抵抗KCI 攻擊.證明過(guò)程注意以下兩點(diǎn).

(1)session-key query 查詢(xún)的密鑰為Early Data 的密鑰eadk,而不是Application Data 的密鑰atk;

(2)定義匹配的會(huì)話(huà)為(chello,ssks)相等的會(huì)話(huà)(只針對(duì)eadk,不針對(duì)atk).

定理1.在假設(shè)服務(wù)器證書(shū)機(jī)制的安全性、求解Gap-DH 的困難性、密鑰導(dǎo)出函數(shù)的安全性、客戶(hù)端簽名機(jī)制的安全性的前提下,優(yōu)化協(xié)議能夠抵抗KCI 攻擊.

?正確性

假設(shè)一個(gè)誠(chéng)實(shí)的協(xié)議參與者擁有抗重放機(jī)制來(lái)產(chǎn)生chello,那么chello 唯一識(shí)別ceks=gs.也就是說(shuō),對(duì)于一對(duì)匹配的會(huì)話(huà),協(xié)議雙方的chello,ceks,ssks 都相同,因此計(jì)算出相同的eadk.

?安全性

接下來(lái)定義一系列Game.

(1)Game 0:優(yōu)化協(xié)議的真實(shí)執(zhí)行過(guò)程;

(2)Game 1:服務(wù)器證書(shū)不可偽造.游戲規(guī)則與Game 0 相同,在該游戲中,攻擊者使用隨機(jī)值ssks*代替gs,因?yàn)楹灻蛘咂渌魏斡糜谡J(rèn)證ssks 的方案是安全的,因此攻擊者無(wú)法贏得Game 1.也就是說(shuō),攻擊者不能隨意偽造服務(wù)器的證書(shū);

(3)Game 2:eadk 的安全性.該游戲發(fā)生在s被泄露之前,游戲規(guī)則與Game 0 相同,但是攻擊者不能使用party corruption 查詢(xún).在該游戲中,攻擊者查詢(xún)gxs,或者從隨機(jī)值和gxs中區(qū)分出gxs.根據(jù)Gap-DH 困難性假設(shè):在給出g,gx,gs和DDH 查詢(xún)的前提下,計(jì)算gxs是困難的.即,攻擊者贏得Game 2 的概率等同于求解Gap-DH 難題;

(4)Game 3:eadk 的安全性.該游戲發(fā)生在s被泄露之前,游戲規(guī)則與Game 0 相同,但是攻擊者不能使用party corruption 查詢(xún).在該游戲中,攻擊者在一個(gè)會(huì)話(huà)完成后,用隨機(jī)值代替另一個(gè)會(huì)話(huà)的eadk*.因?yàn)?/p>

密鑰導(dǎo)出函數(shù)是安全的.

? 對(duì)eadk 的session-key query 查詢(xún)不影響eadk*,因?yàn)閏hello*≠chello;

? atk,sfk 甚至atk*的泄露,都不會(huì)影響eadk*.

因此,攻擊者無(wú)法贏得Game 3.

(5)Game 4:Earlydata 的真實(shí)性和可靠性.該游戲規(guī)則與Game 0 相同,攻擊者在該游戲中用隨機(jī)值代替Sigsk(c)(Hash(Earlydata)).因?yàn)橛糜诤灻鸈arlydata 的密鑰sk(c)和算法是安全的,所以攻擊者無(wú)法贏得Game 4.也就是說(shuō),攻擊者可以通過(guò)party corruption 使s泄露,并計(jì)算出eadk,進(jìn)一步得到Earlydata 的內(nèi)容,但是偽造Sigsk(c)(Hash(Earlydata))是困難的,因此保證了Early Data 消息來(lái)源的真實(shí)性和可靠性.

綜上所述,優(yōu)化協(xié)議能夠防止攻擊者偽裝成任意客戶(hù)端偽造Early Data 消息,從而有效抵抗KCI 攻擊.

3.3 優(yōu)化協(xié)議的形式化分析

利用Scyther 工具對(duì)優(yōu)化后的協(xié)議進(jìn)行分析,這里在編寫(xiě)形式化語(yǔ)言時(shí)需要特別注意對(duì)簽名密鑰的描述.

簽名的公私鑰對(duì)必須具備兩條基本屬性.

(1)在CK 模型下用于簽名的私鑰仍然是保密的;

(2)簽名的公鑰是公開(kāi)的.

因?yàn)镾cyther 對(duì)于角色C來(lái)說(shuō)只有一個(gè)私鑰就是sk(c),為了區(qū)分臨時(shí)私鑰和長(zhǎng)期私鑰,之前在第2.3.1 節(jié)中提到了在sk(c)后加一個(gè)隨機(jī)數(shù)的解決方案,也就是用(sk(c),sigx)的形式來(lái)表示簽名密鑰(sigx 為隨機(jī)數(shù)).但是這里因?yàn)楣€是公開(kāi)的,那么也就是說(shuō)敵手必須要知道(pk(c),sigx),而pk(c)是已知的,所以這種表達(dá)方式會(huì)讓敵手得到sigx,再加上設(shè)置了CK 模型的前提下,C的私鑰sk(c)也是已知的,那么(sk(c),sigx)同樣能夠被敵手得知.因此,本文使用sk(c,sigx)來(lái)表示簽名私鑰.經(jīng)過(guò)實(shí)驗(yàn)證明:在敵手已知pk(c,sigx)和pk(c),并且設(shè)置CK 模型使得sk(c)也是不安全的前提下,sk(c,sigx)仍然是安全的.

根據(jù)之前的實(shí)驗(yàn)發(fā)現(xiàn):使用“Verify automatic claims”會(huì)分析出很多不影響實(shí)驗(yàn)結(jié)果的攻擊路徑,不僅降低了工具的分析效率,而且很多攻擊路徑對(duì)實(shí)驗(yàn)也沒(méi)有幫助,因此,針對(duì)性地在SPDL 語(yǔ)言中加入claim 語(yǔ)句.

?claim(c,Secret,Earlydata);

?claim(s,Secret,Earlydata);

?claim(s,Niagree);

?claim(s,Nisynch);

在搜索攻擊的設(shè)置選項(xiàng)里,選擇“Find all attacks”而不是“Find best attack”,以防漏報(bào).觀察運(yùn)行結(jié)果,發(fā)現(xiàn)所有的攻擊路徑描述的都是同一種攻擊,如圖13所示.

在一次運(yùn)行過(guò)程中,攻擊者截獲客戶(hù)端Bob(C)的公鑰并腐化服務(wù)器Alice(S)得到其長(zhǎng)期私鑰,計(jì)算出這一次通信的eadk,從而得到Early Data 和對(duì)應(yīng)的簽名;在另一次運(yùn)行過(guò)程時(shí),攻擊者可以將這兩條消息作為0-RTT里面的數(shù)據(jù),用這一次通信的eadk 加密發(fā)送給客戶(hù)端Bob,完成對(duì)Early Data 的重放攻擊.

具體攻擊如下.

(1)客戶(hù)端C與服務(wù)器S正常通信,C使用此次通信C的私鑰和S的長(zhǎng)期公鑰計(jì)算出密鑰eadk,用eadk加密在第1 條消息中發(fā)送的Early Data 以及Early Data 摘要的簽名;此外,C還需要向S發(fā)送此次通信C的公鑰;

(2)攻擊者A截獲C向S發(fā)送的此次通信C的公鑰以及加密后的Early Data 和Early Data 摘要的簽名;

(3)A使用C此次通信的公鑰和通過(guò)腐化參與者獲取的S的長(zhǎng)期私鑰計(jì)算出加密此次通信的eadk;

(4)A使用eadk 解密獲得Early Data 和Early Data 摘要的簽名;

(5)在C和S的另一次通信中,A可以用步驟(4)中獲得的Early Data 和Early Data 摘要的簽名替換本次通信中的Early Data 和Early Data 摘要的簽名,完成消息的重放.

Fig.13 Raplay attack to Early Data in the optimized protocol圖13 優(yōu)化協(xié)議中Early Data 的重放攻擊

對(duì)比1-RTT semi-static 模式中claim(s,Niagree)所描述的KCI 攻擊(如圖14所示)可以發(fā)現(xiàn):優(yōu)化協(xié)議中,攻擊者發(fā)送的Early Data 數(shù)據(jù)仍然為合法客戶(hù)端所發(fā)送的數(shù)據(jù),攻擊者只能夠?qū)ζ浜?jiǎn)單重放;而1-RTT semi-static模式中的Early Data 數(shù)據(jù)為IntruderString,即攻擊者自己定義的消息,在這種情況下,攻擊者不僅可以重放消息,甚至可以對(duì)重放的消息進(jìn)行任意篡改,其風(fēng)險(xiǎn)顯然遠(yuǎn)大于優(yōu)化協(xié)議中的重放攻擊.

綜上所述,相比之前的1-RTT semi-static 模式,該優(yōu)化協(xié)議能夠有效抵抗KCI 攻擊,驗(yàn)證了之前的證明結(jié)果.PSK-DHE 模式與1-RTT semi-static 模式類(lèi)似,同樣可以運(yùn)用該優(yōu)化協(xié)議的思路,在Early Data 上加一層簽名,即可保證0-RTT 中的數(shù)據(jù)能夠抵抗KCI 攻擊.表3 總結(jié)了1-RTT semi-static 模式和優(yōu)化協(xié)議的安全性對(duì)比.

Fig.14 KCI attack in 1-RTT semi-static mode圖14 1-RTT semi-static 模式下的KCI 攻擊

Table 3 Security comparison表3 安全性對(duì)比

可以看出:優(yōu)化協(xié)議有效提高了0-RTT 數(shù)據(jù)的安全性,防止了攻擊者冒充合法用戶(hù)與服務(wù)器建立非法鏈接.對(duì)于重放攻擊的問(wèn)題,在簽名中添加時(shí)間戳,有效防止了敵手對(duì)時(shí)間戳的篡改和偽造,服務(wù)器通過(guò)對(duì)時(shí)間戳的驗(yàn)證實(shí)現(xiàn)了抗重放機(jī)制.

3.4 優(yōu)化協(xié)議的效率分析

為了分析優(yōu)化協(xié)議的效率,表4 對(duì)比了1-RTT semi-static 模式和優(yōu)化協(xié)議所需要的主要密碼工具.

Table 4 Main password tools comparison表4 主要密碼工具對(duì)比

從表中可以看出:優(yōu)化協(xié)議與1-RTT semi-static 模式相比,多使用了一個(gè)簽名(在傳輸服務(wù)器的長(zhǎng)期公鑰證書(shū)的時(shí)候還需要另一個(gè)簽名,這個(gè)簽名是二者都必需的),并且為Early Data 增加一個(gè)簽名沒(méi)有增加發(fā)送的消息數(shù),仍然在0-RTT 發(fā)出,因此不會(huì)增加協(xié)議的運(yùn)行時(shí)間.此外,增加的簽名也不會(huì)影響到其他消息,特別是Finished消息,因?yàn)楹灻臄?shù)據(jù)不包括在MAC 的內(nèi)容中,因此不會(huì)影響到MAC 的計(jì)算效率.需要注意的是:優(yōu)化協(xié)議使用的簽名算法建議采用固定的算法,這樣就不需要再增加chello 消息中協(xié)議參數(shù)的內(nèi)容,從而防止增加MAC 計(jì)算的內(nèi)容.

綜上所述,優(yōu)化協(xié)議只增加了一個(gè)簽名的代價(jià),對(duì)于現(xiàn)代計(jì)算機(jī)的處理速度以及網(wǎng)絡(luò)的傳輸速度來(lái)說(shuō),這個(gè)代價(jià)是非常小的,然而換來(lái)的卻是能夠抵抗KCI 攻擊的安全性提升.

4 結(jié)束語(yǔ)

針對(duì)TLS1.3 協(xié)議中3 種支持0-RTT 數(shù)據(jù)的模式,本文使用形式化分析工具Scyther 對(duì)其進(jìn)行了分析,找到了0-RTT 數(shù)據(jù)的泄露和KCI 攻擊兩種攻擊,進(jìn)一步提出了一種優(yōu)化協(xié)議,該優(yōu)化協(xié)議相比原來(lái)的3 種模式能夠抵抗KCI 攻擊和重放攻擊,通過(guò)增加一個(gè)簽名的微小代價(jià),有效提高了0-RTT 數(shù)據(jù)的安全性,特別在使用POST作為第1 個(gè)請(qǐng)求的連接時(shí),這樣的安全性提升是必要的.