TLS1.3 后量子安全遷移方案、實(shí)現(xiàn)和性能評(píng)測(cè)*

張 楓, 潘天雨, 趙運(yùn)磊

復(fù)旦大學(xué) 計(jì)算機(jī)科學(xué)技術(shù)學(xué)院, 上海200433

1 背景

數(shù)字通信是眾多關(guān)鍵服務(wù)(包括遠(yuǎn)程醫(yī)療、網(wǎng)上銀行、電子商務(wù)、機(jī)器自動(dòng)化、移動(dòng)和云計(jì)算) 的推動(dòng)者, 完全滲透到了人們?nèi)粘Ｉa(chǎn)和生活之中, 使得當(dāng)今世界越來(lái)越依賴于數(shù)字通信.數(shù)字通信的一個(gè)核心需求是安全, 并且這種需求在未來(lái)會(huì)變得越來(lái)越重要.為了給數(shù)字通信提供安全保障, 國(guó)際互聯(lián)網(wǎng)工程任務(wù)組(Internet Engineering Task Force, IETF) 研發(fā)和制定了因特網(wǎng)安全傳輸層協(xié)議(transport layer security,TLS),用于在數(shù)字網(wǎng)絡(luò)上建立加密的通信隧道,為網(wǎng)絡(luò)數(shù)據(jù)提供保密性、認(rèn)證和數(shù)據(jù)完整性.TLS是實(shí)際中部署和應(yīng)用最為廣泛的密碼協(xié)議, 數(shù)據(jù)研究表明, 全球每天產(chǎn)生大約230個(gè)TLS 鏈接[1], 超過(guò)60% 的互聯(lián)網(wǎng)數(shù)據(jù)是通過(guò)基于TLS 的安全HTTPS 協(xié)議實(shí)現(xiàn)的[2,3].而且, 隨著互聯(lián)網(wǎng)用戶對(duì)加密和隱私需求的增加, 預(yù)計(jì)作為工業(yè)標(biāo)準(zhǔn)的TLS 的使用頻率將繼續(xù)增長(zhǎng)[4].

公鑰密碼學(xué)為開(kāi)放網(wǎng)絡(luò)上的數(shù)字通信提供安全保障, 它是包括TLS 在內(nèi)的所有互聯(lián)網(wǎng)協(xié)議的安全基石. 這些協(xié)議的基本結(jié)構(gòu)是相似的, 首先使用公鑰密碼算法進(jìn)行實(shí)體認(rèn)證并建立共享密鑰, 然后利用該共享密鑰使用對(duì)稱(chēng)密碼算法提供機(jī)密性和數(shù)據(jù)完整性.然而這種依賴于(橢圓曲線) 離散對(duì)數(shù)和大整數(shù)素因子分解難題的公鑰密碼算法面臨量子計(jì)算機(jī)強(qiáng)大計(jì)算能力的威脅.Shor 量子算法[5,6]可在多項(xiàng)式時(shí)間內(nèi)解決離散對(duì)數(shù)和素因子分解問(wèn)題, 使得當(dāng)前使用的公鑰算法不再安全, 給我們的網(wǎng)絡(luò)安全帶來(lái)了嚴(yán)重隱患.而且, 作為全球研究熱點(diǎn)的量子計(jì)算機(jī)正在以量子體積每年翻倍的“量子摩爾定律” 向前發(fā)展.一旦這種量子霸權(quán)(quantum supremacy)[7]成為現(xiàn)實(shí), 現(xiàn)有公鑰密碼體制將發(fā)生顛覆性的崩塌.

量子計(jì)算機(jī)的發(fā)展引起了信息技術(shù)和安全研究人員的關(guān)注, 研發(fā)部署抗量子攻擊的新型產(chǎn)品得到了相關(guān)組織、機(jī)構(gòu)和企業(yè)的廣泛關(guān)注, 如國(guó)際標(biāo)準(zhǔn)化組織ISO、美國(guó)國(guó)家安全局NSA、美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)研究院NIST、歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì)ETSI、Google、Amazon 和Microsoft 等都在開(kāi)展相關(guān)研究.2015年, 歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì)(European Telecommunications Standards Institute, ETSI) 成立了一個(gè)量子安全工作組, 旨在對(duì)工業(yè)界和學(xué)術(shù)界關(guān)于實(shí)際應(yīng)用量子安全密碼的各種建議進(jìn)行評(píng)估; 同年, 歐盟啟動(dòng)抗量子密碼算法項(xiàng)目PQCRYPTO 和SAFECRYPTO, 致力于后量子密碼學(xué)研究, 開(kāi)發(fā)新的加密系統(tǒng), 以防止可能發(fā)生的量子計(jì)算機(jī)攻擊; 2016 年, 美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)研究院(National Institute of Standards and Technology, NIST) 正式啟動(dòng)了征集抗量子密碼算法的公共項(xiàng)目, 該項(xiàng)目主要關(guān)注抗量子算法的安全性, 旨在標(biāo)準(zhǔn)化公鑰加密(public key encryption, PKE)、密鑰封裝(key encapsulation mechanism,KEM) 和數(shù)字簽名這3 類(lèi)基本的抗量子公鑰密碼算法.在國(guó)內(nèi), 中國(guó)密碼學(xué)會(huì)(Chinese Association for Cryptologic Research, CACR) 于2019 年開(kāi)展了全國(guó)密碼算法設(shè)計(jì)競(jìng)賽, 征集抗量子密碼算法并逐步開(kāi)展國(guó)產(chǎn)密碼算法標(biāo)準(zhǔn)化, 加強(qiáng)自主可控的量子密碼算法國(guó)產(chǎn)化進(jìn)程.一旦標(biāo)準(zhǔn)機(jī)構(gòu)標(biāo)準(zhǔn)化了抗量子密鑰交換和數(shù)字簽名方案的算法, 后量子密碼的采用將取決于將這些算法集成到現(xiàn)有通信協(xié)議和互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的進(jìn)展.

然而將這些后量子算法集成到現(xiàn)有協(xié)議(如TLS、IKEv2、SSH) 中, 并與當(dāng)今互聯(lián)網(wǎng)基礎(chǔ)設(shè)施共存并不是一件容易的事情, 存在各種各樣的挑戰(zhàn).這些挑戰(zhàn)包括: 后量子密碼算法和傳統(tǒng)算法在算法處理邏輯和消息結(jié)構(gòu)上有很大不同; 后量子算法在計(jì)算速度上與傳統(tǒng)算法有較大差異, 繁重的操作會(huì)在通信信道兩端增加網(wǎng)絡(luò)延遲; 后量子算法比傳統(tǒng)算法相比要傳輸?shù)臄?shù)據(jù)量大大增加, 加重了通信開(kāi)銷(xiāo)等.隨著后量子算法的發(fā)展和標(biāo)準(zhǔn)化, 已經(jīng)存在各種各樣為T(mén)LS 生態(tài)提供抗量子密碼特性的準(zhǔn)備工作.我們至少可以看到三條主要的工作路線:

(1) 將后量子算法集成到符合現(xiàn)有協(xié)議格式和消息流的規(guī)范(草案) 中[8–13].這些工作主要集中在TLS 后量子密鑰交換上, 因?yàn)榇_保密鑰交換可以抵抗量子攻擊的需求更為急迫.一個(gè)當(dāng)前并不具備量子計(jì)算能力的攻擊者可以先行監(jiān)控并記錄下通信數(shù)據(jù), 在具備量子計(jì)算能力之后再對(duì)它們解密.對(duì)于軍事、政治和醫(yī)療等任何必須長(zhǎng)期保密的關(guān)鍵信息來(lái)說(shuō), 這是一個(gè)高度的威脅.

(2) 完成這種集成的原型實(shí)現(xiàn)[14–20], 觀測(cè)它們是否滿足協(xié)議和軟件中的現(xiàn)有限制.相關(guān)的一系列工作源于Google 的實(shí)驗(yàn)[14,21].隨后Google、Cloudflare 和其他公司合作,通過(guò)修改客戶機(jī)瀏覽器和邊緣服務(wù)器支持在TLS 1.3 中使用混合密鑰交換方案(將后量子密鑰交換算法和傳統(tǒng)的橢圓曲線Diffie-Hellman 密鑰交換組合, 產(chǎn)生混合密鑰交換)[20,22].Open quantum safe (OQS)[18]則提供了對(duì)于后量子算法以及TLS 1.2 和TLS 1.3 中的混合密鑰交換的原型集成.

(3) 在實(shí)驗(yàn)室模擬網(wǎng)絡(luò)環(huán)境[16,17]或?qū)嶋H的網(wǎng)絡(luò)環(huán)境[14,19–21]中評(píng)估集成了后量子算法(密鑰交換和認(rèn)證) 后TLS 的性能.與傳統(tǒng)公鑰算法相比, 后量子密鑰封裝機(jī)制(key encapsulation mechanism, KEM) 和數(shù)字簽名方案較慢的計(jì)算速度和超長(zhǎng)的公鑰/密文長(zhǎng)度使得孤立地測(cè)量這些算法的性能很容易, 然而在現(xiàn)實(shí)的網(wǎng)絡(luò)環(huán)境中準(zhǔn)確地測(cè)量這些算法在協(xié)議上下文中的性能則是非常困難的[22].Braithwaite 和Langley 等[14,15,19–21]在TLS 中使用后量子密鑰交換算法的實(shí)驗(yàn)非?，F(xiàn)實(shí), 但是實(shí)驗(yàn)選擇使用的后量子算法有限, 沒(méi)有涉及認(rèn)證部分, 并且實(shí)驗(yàn)結(jié)果無(wú)法復(fù)制, 特別是無(wú)法準(zhǔn)確反映時(shí)延和丟包率等網(wǎng)絡(luò)屬性單獨(dú)對(duì)協(xié)議運(yùn)行造成的影響.

現(xiàn)存這些工作主要集中在建立抗量子機(jī)密性的密鑰交換.因?yàn)橐粋€(gè)試圖破解機(jī)密性的敵手可以監(jiān)聽(tīng)通訊中加密的敏感數(shù)據(jù)并保存下來(lái), 等待具備量子計(jì)算能力的時(shí)候追溯攻擊存儲(chǔ)的會(huì)話記錄, 這對(duì)于必須長(zhǎng)期保密的信息而言是一個(gè)很大的威脅.相比較而言, 認(rèn)證只需要在建立連接的時(shí)候是安全的, 不需要在整個(gè)數(shù)據(jù)的生命周期中一直維持這種安全性.這意味著在大規(guī)模商用量子計(jì)算機(jī)出現(xiàn)之前, 身份認(rèn)證是不易受到攻擊的, 因此抗量子的認(rèn)證不像抗量子的機(jī)密性那么迫切, 對(duì)后量子認(rèn)證的研究相對(duì)較少.盡管如此, 后量子認(rèn)證工作邏輯上更加復(fù)雜, 而且涉及到公鑰認(rèn)證的核心基礎(chǔ)設(shè)施PKI, 成本更加高昂, 升級(jí)更加耗時(shí), 涉及范圍也更廣.尤其是互聯(lián)網(wǎng)的PKI 系統(tǒng)的所有信任都集中在根CA, 一旦該信任點(diǎn)出現(xiàn)故障,后果將是災(zāi)難性的.此外, 后量子簽名算法較低的計(jì)算性能, 較大的公鑰和簽名, 以及由此產(chǎn)生的數(shù)字證書(shū)明顯變大的事實(shí), 肯定會(huì)影響TLS 握手時(shí)的性能, 損壞用戶體驗(yàn).因此, 研究后量子簽名算法對(duì)于TLS的應(yīng)用也是非常重要的[23], 非常有必要盡早盡快開(kāi)展對(duì)后量子簽名算法的研究并開(kāi)始將PKI 系統(tǒng)向后量子安全遷移的工作.

本文探討將TLS 1.3 協(xié)議向后量子安全遷移的方案, 介紹實(shí)現(xiàn)的方法, 比較在TLS1.3 中使用不同后量子密碼套件的性能差異. 較之現(xiàn)有國(guó)內(nèi)外進(jìn)展, 本文的工作更加全面, 同時(shí)關(guān)注了后量子密鑰交換和身份認(rèn)證, 全面集成NIST 和中國(guó)密碼算法設(shè)計(jì)競(jìng)賽[24,25]的后量子格基密鑰封裝算法和簽名算法; 較之之前關(guān)于后量子TLS 算法的實(shí)驗(yàn)片面涉及密鑰交換或身份認(rèn)證, 我們的實(shí)驗(yàn)也更加詳實(shí), 全面評(píng)估了在TLS1.3 協(xié)議中同時(shí)使用后量子密鑰交換和后量子認(rèn)證在不同網(wǎng)絡(luò)環(huán)境下的性能. 本文的主要工作包括以下4 個(gè)方面:

(1) 聚焦TLS 1.3, 探討在TLS 1.3 中集成后量子格基密碼算法的思想和方法, 給出了TLS 1.3 后量子遷移方案.通過(guò)對(duì)TLS 1.3 做必要修改, 將適合協(xié)議遷移的、標(biāo)準(zhǔn)化可能性大的格密碼算法集成到TLS 1.3 中, 實(shí)現(xiàn)TLS 1.3 協(xié)議向后量子安全平滑過(guò)渡, 并且可以與標(biāo)準(zhǔn)協(xié)議兼容.這些方案使用了混合模式的密鑰交換和混合模式的數(shù)字簽名(身份認(rèn)證).

(2) 實(shí)現(xiàn)了后量子安全的TLS 1.3 密碼庫(kù).綜合考慮代碼架構(gòu), 實(shí)現(xiàn)上的安全性和使用上的通用性等因素, 我們?cè)突x定的格密碼算法, 并將它們集成到Facebook 的TLS 1.3 實(shí)現(xiàn)庫(kù)fizz 中.集成的算法包括了進(jìn)入NIST 第二輪的后量子KEM 算法和簽名算法以及中國(guó)密碼算法設(shè)計(jì)競(jìng)賽第二輪優(yōu)勝算法aigis-enc、aigis-sig、akcn-mlwe 和mulan.利用該庫(kù)建立的加密隧道在握手階段可以采用后量子安全的密鑰交換算法和簽名算法, 用于抵抗具有量子計(jì)算能力的敵手.

(3) 構(gòu)建了一個(gè)測(cè)試TLS 協(xié)議在各種網(wǎng)絡(luò)條件下性能的實(shí)驗(yàn)框架.該框架使用Linux 內(nèi)核的網(wǎng)絡(luò)棧能夠精確獨(dú)立地調(diào)整鏈路延遲和丟包率等特性, 允許我們?cè)谝慌_(tái)機(jī)器上模擬客戶機(jī)-服務(wù)器進(jìn)行網(wǎng)絡(luò)實(shí)驗(yàn), 精確量化在建立TLS 連接時(shí)因?yàn)閬G包或者網(wǎng)絡(luò)延遲產(chǎn)生的影響.

(4) 在一個(gè)經(jīng)典的TLS 1.3 的應(yīng)用場(chǎng)景下對(duì)修改后的fizz 進(jìn)行大規(guī)模全面測(cè)試, 保證修改后產(chǎn)品的正確性和兼容性, 并檢查各種格密碼算法對(duì)TLS 握手性能產(chǎn)生的影響.測(cè)試結(jié)果表明, 盡管后量子算法會(huì)對(duì)TLS 1.3 的握手開(kāi)銷(xiāo)產(chǎn)生一定影響, 但是考慮到后量子算法微秒級(jí)的運(yùn)行時(shí)間, 網(wǎng)絡(luò)延遲隱藏了這些算法大部分計(jì)算性能上的差異, 但在高質(zhì)量(較小網(wǎng)絡(luò)延遲和較低丟包率) 的鏈路上, 算法性能是決定因素; 后量子算法的公鑰/密文/簽名大幅增加, 尤其是使用后量子算法生成的證書(shū)鏈長(zhǎng)度增加較大, 但TCP 分段機(jī)制可以保證協(xié)議正常運(yùn)行, 在丟包率較高的鏈路上, 傳輸報(bào)文少的算法能夠體現(xiàn)帶寬優(yōu)勢(shì).實(shí)驗(yàn)結(jié)果也為不同網(wǎng)絡(luò)條件下如何選擇后量子算法提供指導(dǎo),有助于后量子算法進(jìn)一步標(biāo)準(zhǔn)化和TLS 1.3 標(biāo)準(zhǔn)向后量子安全遷移和平滑過(guò)渡.

2 相關(guān)工作

2.1 TLS1.3 協(xié)議

TLS 運(yùn)行在TCP/IP 協(xié)議棧上, 提供端到端的身份認(rèn)證, 并在它們之間建立加密的通信隧道, 提供通信數(shù)據(jù)的機(jī)密性、完整性和真實(shí)性保證. 它廣泛用于保護(hù)web(HTTPS), 文件傳輸(FTP)、電子郵件(SMTP, POP) 和許多其它應(yīng)用程序的流量和數(shù)據(jù).2018 年8 月, IETF 正式發(fā)布了RFC8446[26], 宣布最新版TLS 協(xié)議TLS 1.3 標(biāo)準(zhǔn)的建立.TLS 1.3 比前一代TLS 1.2 有了顯著改進(jìn), 包括消除了不安全或過(guò)時(shí)的特性、部分加密握手消息、消除往返減少握手延遲等:

(1) 性能提升.握手延遲是影響TLS 性能的最大因素.完整模式的TLS 1.3 只需要一次往返(round trip time, RTT) 就可以完成握手, 并且添加了對(duì)0-RTT 的支持.相比TLS 1.2, TLS 1.3 的握手時(shí)間減半, 性能得到了極大提升.

(2) 安全性提升.TLS 1.3 刪除了之前版本中一些不安全的密碼算法, 轉(zhuǎn)而采用現(xiàn)代密碼算法和操作模式, 進(jìn)一步保障了安全性.另外, 在TLS 1.2 協(xié)議中握手消息全部是明文傳輸, TLS 1.3 協(xié)議對(duì)部分握手內(nèi)容進(jìn)行加密傳輸, 可以應(yīng)對(duì)大規(guī)模的監(jiān)控, 加強(qiáng)了隱私保護(hù).

(3) 全方位簡(jiǎn)化協(xié)議邏輯.TLS 1.3 采用了和TLS 1.2 協(xié)議完全不同的設(shè)計(jì)理念, 一個(gè)典型的改變是密碼組件(ciphersuites, 包括密鑰交換方法、數(shù)字簽名方案和對(duì)稱(chēng)密碼方案) 的協(xié)商邏輯.TLS 1.2 使用整體密碼組件的設(shè)計(jì)思想, 一次性協(xié)商所有使用的密碼方法, TLS 1.3 則分別協(xié)商密碼組件的每個(gè)部分.

TLS 1.3 協(xié)議邏輯方面的改變使得協(xié)商更加靈活, 每一個(gè)算法都使用沒(méi)有內(nèi)部結(jié)構(gòu)的枚舉值標(biāo)識(shí).如果要在協(xié)議中使用一個(gè)算法, 只需要讓運(yùn)行協(xié)議的雙方都理解該算法標(biāo)識(shí)符并將其映射到對(duì)應(yīng)的算法處理邏輯即可.這為不改變TLS1.3 協(xié)議的語(yǔ)法、語(yǔ)義和同步而集成后量子算法提供了方便.圖1 展示了TLS 1.3 完整1-RTT 握手過(guò)程, 該過(guò)程主要密包括密鑰交換、發(fā)送服務(wù)器參數(shù)和認(rèn)證三個(gè)部分.密鑰交換用于選擇TLS 協(xié)議版本和加密的算法, 協(xié)商算法所需的參數(shù), 這些消息是明文傳輸; 發(fā)送服務(wù)器參數(shù)用于協(xié)商握手協(xié)議的其它通信參數(shù), 例如是否需要認(rèn)證客戶端, 支持何種應(yīng)用層協(xié)議等, 這些消息是密文傳輸; 認(rèn)證用于對(duì)服務(wù)器進(jìn)行認(rèn)證(包括可選的客戶端認(rèn)證), 提供密鑰確認(rèn)和驗(yàn)證握手完整性, 這些消息加密傳輸.

圖1 完整1-RTT 模式TLS1.3 握手協(xié)議Figure 1 Full 1-RTT TLS1.3 handshake

首先, 客戶端生成用于密鑰交換的臨時(shí)公私鑰對(duì), 并向服務(wù)器發(fā)送ClientHello 消息, 該消息攜帶了隨機(jī)數(shù)、客戶端支持的協(xié)議版本、密碼組件等重要信息和一些可能存在的擴(kuò)展(extension).這些擴(kuò)展包括: signature_algorithms, 用于指示支持的簽名算法列表; supported_groups, 用于指示支持的橢圓曲線類(lèi)型; key_share, 用于表示supported_groups 中每一個(gè)橢圓曲線的公鑰信息等.

第二步, 服務(wù)器響應(yīng)ClientHello 消息, 它計(jì)算自己的臨時(shí)密鑰對(duì), 確定所需的加密參數(shù), 產(chǎn)生包含服務(wù)器隨機(jī)數(shù)和key_share 擴(kuò)展的ServerHello 消息并將該消息發(fā)送給客戶端.其中key_share 擴(kuò)展包含了協(xié)商的橢圓曲線和服務(wù)器的公鑰信息.此時(shí), 通過(guò)組合ClientHello 和ServerHello 消息, 兩個(gè)實(shí)體生成共享密鑰, 此后的消息使用此密鑰加密.

第三步, 服務(wù)器繼續(xù)加密發(fā)送EncryptedExtension 消息、Certificate 消息和CertificateVerify 消息.其中, EncryptedExtensions 消息攜帶了無(wú)關(guān)密鑰交換的其它擴(kuò)展, Certificate 消息攜帶了服務(wù)器證書(shū)鏈;CertificateVerify 消息攜帶的是服務(wù)器對(duì)到當(dāng)前為止的所有消息的簽名, 該簽名使用的私鑰和簽名算法同Certificate 消息攜載的服務(wù)器證書(shū)公鑰和簽名算法對(duì)應(yīng).最后, 服務(wù)器發(fā)送Finished 消息來(lái)結(jié)束握手, 該消息包含了迄今為止交換的所有消息的消息認(rèn)證碼.

最后, 客戶端用加密的Finished 消息回復(fù)ServerHello.如果服務(wù)器需要客戶端認(rèn)證, 客戶端需要在Finished 消息之前發(fā)送Certificate 消息和CertificateVerify 消息.另外, 出于兼容性的目的, 雙方可以在交互期間發(fā)送Change Cipher Spec 消息指示自此開(kāi)始發(fā)送的消息都是加密過(guò)的.

RFC8446[26]完整說(shuō)明了TLS 1.3 的握手流程和消息格式, 文獻(xiàn)[27] 詳細(xì)描述了TLS1.3 的計(jì)算邏輯和處理步驟.

2.2 PKI 和X.509 證書(shū)

身份認(rèn)證確保信息和數(shù)據(jù)的來(lái)源是正確的, 即數(shù)據(jù)或消息來(lái)自它聲稱(chēng)的信源.如果沒(méi)有身份認(rèn)證, 接收者收到的消息可能已經(jīng)被惡意實(shí)體篡改, 發(fā)送者也可能將消息發(fā)送到錯(cuò)誤一方, 從而導(dǎo)致機(jī)密信息的泄漏.大部分互聯(lián)網(wǎng)安全通信協(xié)議需要在連接建立階段使用數(shù)字證書(shū)進(jìn)行單向或雙向的身份認(rèn)證.數(shù)字證書(shū)的核心是使用數(shù)字簽名技術(shù)保證源數(shù)據(jù)(被簽名數(shù)據(jù)) 的真實(shí)性和完整性, 杜絕數(shù)據(jù)在網(wǎng)絡(luò)傳輸過(guò)程中被偽造篡改.數(shù)字證書(shū)的格式遵循ITU-T(國(guó)際電信聯(lián)盟電信標(biāo)準(zhǔn)局)X.509 標(biāo)準(zhǔn)[28,29], 該標(biāo)準(zhǔn)規(guī)定了數(shù)字證書(shū)須遵循的格式以保證使用數(shù)字證書(shū)的系統(tǒng)間的互操作性.目前通用的X.509 版本是X.509 V3.符合X.509 標(biāo)準(zhǔn)的證書(shū)稱(chēng)為X.509 證書(shū), 它通過(guò)數(shù)字簽名技術(shù)綁定實(shí)體身份和公鑰.數(shù)字通信中的許多協(xié)議的身份認(rèn)證都是通過(guò)X.509 數(shù)字證書(shū)來(lái)進(jìn)行的.X.509 數(shù)字證書(shū)經(jīng)常使用PEM 或DER 格式編碼, 它們的大小可以根據(jù)屬性值、算法和其中的擴(kuò)展高度可變.目前Internet 上最常見(jiàn)的證書(shū)大小在0.5–1.5 KB 之間.

數(shù)字證書(shū)的管理是通過(guò)公鑰基礎(chǔ)設(shè)施(public key infrastructure, PKI) 進(jìn)行的.通過(guò)PKI 管理密鑰和數(shù)字證書(shū), 網(wǎng)絡(luò)實(shí)體之間可以建立一個(gè)可信的通信環(huán)境.PKI 基礎(chǔ)設(shè)施由多個(gè)部分組成, 證書(shū)頒發(fā)機(jī)構(gòu)(certificate authority, CA) 是它的核心.CA 負(fù)責(zé)頒發(fā)數(shù)字證書(shū), 綁定實(shí)體的身份和相關(guān)公鑰.實(shí)體身份包含在證書(shū)的Subject 字段中, 實(shí)體的公鑰與頒發(fā)者所用的簽名算法存儲(chǔ)在證書(shū)的subjectPublicKeyInfo字段.證書(shū)還包含有證書(shū)有效期(validity) 和用于指示其它一些功能的擴(kuò)展(extension) 字段.CA 使用自己的私鑰和指定的簽名算法對(duì)證書(shū)進(jìn)行簽名, 并將簽名添加到證書(shū)的簽名字段中.

在X.509 PKI 的頂部有一些可信的CA, 它們用自己的私鑰簽署自己的證書(shū), 稱(chēng)為根CA (root CA).根CA 可以直接頒發(fā)證書(shū)給服務(wù)器,更一般的情況是根CA 頒發(fā)證書(shū)給中間CA(intermediate CA,ICA).之后, 出于安全目的根CA 保持脫機(jī)狀態(tài), 由ICA 為服務(wù)器或其它ICA 頒發(fā)證書(shū), 由此形成PKI 樹(shù)形管理結(jié)構(gòu).由此過(guò)程創(chuàng)建的證書(shū)信任鏈可以包含任意多個(gè)證書(shū), 但一般情況下該證書(shū)鏈由兩到四個(gè)證書(shū)組成,并把CA 或ICA 簽署給服務(wù)器的證書(shū)稱(chēng)為葉子證書(shū).在會(huì)話建立階段, 需要認(rèn)證的實(shí)體需要將證書(shū)鏈發(fā)送給認(rèn)證端, 認(rèn)證端讀取葉子證書(shū)獲取其頒發(fā)機(jī)構(gòu)(issuer) 的信息, 去系統(tǒng)查找該機(jī)構(gòu)的證書(shū); 如果該證書(shū)不是根證書(shū)就繼續(xù)遞歸查找直到獲取根證書(shū); 如果根證書(shū)是可信任的, 則用根證書(shū)的公鑰驗(yàn)證下一級(jí)證書(shū)的有效性并回溯進(jìn)行, 直到通過(guò)葉子證書(shū)頒發(fā)者的公鑰驗(yàn)證葉子證書(shū)的合法性.

2.3 格密碼算法

由于目前使用的公鑰密碼體制會(huì)被量子計(jì)算機(jī)在多項(xiàng)式時(shí)間攻破, 為保護(hù)關(guān)鍵基礎(chǔ)設(shè)施和敏感資產(chǎn),需要尋找能夠抵抗這種攻擊的替代方案.這些研究的目標(biāo)是確定無(wú)法在多項(xiàng)式時(shí)間內(nèi)通過(guò)量子算法解決的NP 困難問(wèn)題或子問(wèn)題[30].其中, 為傳統(tǒng)計(jì)算機(jī)部署一套新的公鑰密碼系統(tǒng), 以抵御量子計(jì)算機(jī)攻擊的方法因?yàn)榭梢愿玫丶嫒莠F(xiàn)有的計(jì)算機(jī)體系結(jié)構(gòu)和網(wǎng)絡(luò)基礎(chǔ)設(shè)施, 便于實(shí)現(xiàn)抗量子算法向現(xiàn)有應(yīng)有和協(xié)議遷移過(guò)渡, 具備較強(qiáng)的競(jìng)爭(zhēng)力.這種新的密碼系統(tǒng)被稱(chēng)為后量子密碼(post quantum cryptography).目前, 已經(jīng)存在很多后量子密碼算法, 業(yè)界認(rèn)為以下五種類(lèi)型的后量子算法是有希望的替代方案:

· 基于hash 的(hash-based cryptosystems)

· 基于編碼的(code-based cryptosystems)

· 基于多變量的(multivariate cryptosystems)

· 基于同源的(supersingular isogeny cryptosystems)

· 基于格的(lattice-based cryptosystems)

其中, 基于格的密碼算法簡(jiǎn)單并且可以高度并行化, 在安全性、公私鑰尺寸、計(jì)算速度上達(dá)到了更好的平衡, 甚至可以在某些情況下表現(xiàn)出比傳統(tǒng)基于數(shù)論構(gòu)造的密碼算法更快的計(jì)算速度[31].與其它幾種后量子密碼實(shí)現(xiàn)相比, 在相同的安全強(qiáng)度下, 它更適用于實(shí)際應(yīng)用.尤其是近年來(lái), 基于格的LWE (learning with errors) 問(wèn)題和RLWE (ring-LWE) 問(wèn)題的密碼學(xué)構(gòu)造發(fā)展迅速, 被認(rèn)為是最有希望被標(biāo)準(zhǔn)化的技術(shù)路線之一.本文, 我們關(guān)注于將最具競(jìng)爭(zhēng)力的格密碼算法集成到TLS 1.3 使其向后量子安全遷移.

3 方案設(shè)計(jì)

將后量子密碼算法集成到TLS 1.3 協(xié)議中有替換模式和混合模式兩種方案.替換模式(drop-in replacement) 直接將協(xié)議中原有的傳統(tǒng)公鑰算法替換為后量子密碼算法.混合模式(hybrid mode) 則保留協(xié)議中原有的傳統(tǒng)公鑰算法, 同時(shí)再集成一個(gè)后量子密碼算法.混合模式的密鑰交換分別使用傳統(tǒng)密鑰交換算法和后量子密鑰交換算法, 然后將通過(guò)這些算法得到的信息組合在一起用于推演密鑰; 混合模式的簽名算法使用傳統(tǒng)公鑰算法產(chǎn)生一個(gè)簽名, 再使用后量子簽名算法產(chǎn)生一個(gè)簽名, 驗(yàn)簽時(shí)需要兩個(gè)簽名值都通過(guò)驗(yàn)證.

3.1 混合模式

替換模式的安全性完全依賴于替換進(jìn)來(lái)的后量子密碼算法.然而, 當(dāng)用戶對(duì)新興的后量子密碼假設(shè)缺乏信心時(shí), 或者因?yàn)楸粡?qiáng)制要求遵循現(xiàn)行行業(yè)規(guī)范, 必須在使用后量子密碼算法的同時(shí)使用傳統(tǒng)公鑰算法時(shí), 替換模式不能工作.為了適應(yīng)這種需求, 出現(xiàn)了混合模式.混合模式在保留協(xié)議原有公鑰算法的同時(shí)加入了后量子密碼算法, 并確保只要其中一個(gè)密碼算法是安全的, 則組合算法就是安全的.對(duì)于混合模式密鑰交換, 只要其中一個(gè)密鑰交換算法未被攻破, 就可以保持混合密鑰交換算法會(huì)話密鑰的安全, 應(yīng)用程序數(shù)據(jù)的機(jī)密性就能得到保證.對(duì)于混合模式數(shù)字簽名, 只要在會(huì)話建立時(shí)其中一個(gè)數(shù)字簽名方案未被攻破, 協(xié)議就可以提供安全認(rèn)證.這種混合模式有利于實(shí)現(xiàn)后量子密碼安全算法的漸進(jìn)式部署, 使得現(xiàn)存協(xié)議及其應(yīng)用向后量子安全的過(guò)渡更加平滑.當(dāng)然, 混合模式也可能使協(xié)議的網(wǎng)絡(luò)通信量更大, 遷移方案設(shè)計(jì)更復(fù)雜.對(duì)于混合模式的使用應(yīng)該滿足以下3 個(gè)需求:

(1) 混合模式方案的計(jì)算代價(jià)不能過(guò)于高昂.一般來(lái)說(shuō), 混合模式的計(jì)算性能取決于它所包含的單個(gè)密碼算法的性能, 組合使用應(yīng)該不會(huì)實(shí)質(zhì)性地影響整個(gè)算法的性能.

(2) 低延遲.使用混合模式不應(yīng)顯著增加建立連接所需要的延遲.影響延遲的因素主要包括所用特定算法的計(jì)算性能和要傳輸?shù)南⒌拇笮?后量子算法的公鑰/密文/簽名大小從數(shù)百字節(jié)到幾千字節(jié)不等, 而傳統(tǒng)密碼算法的對(duì)應(yīng)值僅僅在一百字節(jié)上下, 我們必須考察權(quán)衡由此帶來(lái)的改變是否滿足TLS 在延遲方面的設(shè)計(jì)需求.

(3) 混合模式的使用不會(huì)增加額外的消息流, 改變算法原有的消息結(jié)構(gòu)和處理邏輯.很難說(shuō)明改變了協(xié)議消息結(jié)構(gòu)和處理邏輯后的協(xié)議還是原有的協(xié)議.

盡管混合模式給我們帶來(lái)了積極的因素, 但是也存在不少挑戰(zhàn).那么, 在使用混合模式的時(shí)候需要考慮以下幾個(gè)關(guān)鍵問(wèn)題:

(1) 混合模式組合的算法數(shù)量是固定的還是可變的？如果是固定的話, 那么應(yīng)該是多少？這個(gè)問(wèn)題上似乎沒(méi)有共識(shí), 一些互聯(lián)網(wǎng)草案[9,10,12]將用于TLS 混合模式的密鑰協(xié)商中使用的算法數(shù)目固定為兩個(gè), 另外一些草案[8,11]則認(rèn)為混合模式可以具有更多的可變數(shù)目的算法.

(2) 如何協(xié)商混合模式使用的算法和參數(shù)？包括TLS 在內(nèi)的很多協(xié)議的算法協(xié)商都采用以下步驟:一方按照其意愿向另一方發(fā)送其支持的算法列表, 另一方根據(jù)自己的支持算法列表從收到的列表中選擇單個(gè)算法進(jìn)行響應(yīng).如果找不到相互支持的算法, 則引發(fā)錯(cuò)誤或協(xié)議重啟事件.使用混合模式的時(shí)候一個(gè)主要的抉擇是選擇協(xié)商方法, 是單獨(dú)協(xié)商混合模式中的每一個(gè)算法還是把混合模式的算法作為一個(gè)整體進(jìn)行協(xié)商？

(3) 如何選擇混合模式要組合的算法以及如何安全組合算法數(shù)據(jù)？在使用混合模式的時(shí)候只要其中一個(gè)算法是安全,則可以保證算法的組合是安全的.那么,應(yīng)該如何確定要組合的算法以及如何組合來(lái)自多個(gè)算法的共享密鑰,異或、級(jí)聯(lián)還是通過(guò)密鑰推導(dǎo)函數(shù)？在機(jī)密性方面,Even 和Goldreich探索了多個(gè)對(duì)稱(chēng)加密方案的組合[32].文獻(xiàn)[33–35] 研究了組合多個(gè)公鑰加密方案, Harnik 等人構(gòu)建了“健壯組合器”(roust combiner), 可以在保留每個(gè)方案安全屬性的同時(shí)將多個(gè)方案編譯成為一個(gè)混合方案[34].最近, Giacon[36]和Bindel[37]等人探討對(duì)密鑰封裝機(jī)制的組合.在數(shù)字簽名方面, Bindel 等考察了數(shù)字簽名方案的合并方法[38].特別需要注意的是在進(jìn)行組合的時(shí)候,應(yīng)該確保選擇的算法具有匹配的安全級(jí)別.

對(duì)于第一個(gè)問(wèn)題, 本文傾向于使用將混合模式的算法固定為2, 其中一個(gè)是經(jīng)典算法, 一個(gè)是后量子算法.一方面, 這是最簡(jiǎn)潔最方便的處理方式; 另一方面, 在混合模式中使用多個(gè)算法是在對(duì)所有算法的安全性都沒(méi)有足夠信心時(shí)寄希望至少其中一個(gè)是安全的無(wú)奈之舉.而在我們的方案中, 經(jīng)典算法使用的是原有協(xié)議中的算法, 后量子算法使用的是經(jīng)過(guò)NIST 評(píng)估或者是在中國(guó)密碼算法競(jìng)賽獲勝的后量子算法, 可以確信這種組合能夠達(dá)到我們期望的安全性能.對(duì)于第二個(gè)問(wèn)題, 我們傾向于將混合模式的算法作為一個(gè)整體進(jìn)行協(xié)商.因?yàn)閱为?dú)協(xié)商混合模式的每一個(gè)算法需要修改協(xié)議的消息格式和邏輯.對(duì)于一個(gè)改變了協(xié)議消息格式和交互邏輯的協(xié)議, 很難說(shuō)它還是原協(xié)議或者保持原協(xié)議的特性.對(duì)于TLS 1.3 來(lái)說(shuō), 我們需要為混合模式定義新的算法標(biāo)識(shí)符(NamedGroups 或SignatuerSchemes 中的條目), 并將新的算法標(biāo)識(shí)符映射到混合模式的處理邏輯上.此時(shí), 協(xié)議雙方在協(xié)商的時(shí)候仍然可以使用原有的協(xié)議邏輯和消息格式,保證協(xié)議在語(yǔ)法、語(yǔ)義和同步上同原協(xié)議的一致性.在確定混合模式使用的算法固定為一個(gè)經(jīng)典算法和一個(gè)后量子算法且作為整體來(lái)進(jìn)行協(xié)商的時(shí)候, 我們傾向于選擇安全級(jí)別匹配的算法進(jìn)行組合, 然后按照經(jīng)典密鑰和后量子密鑰的順序?qū)蚕砻荑€進(jìn)行級(jí)聯(lián)操作.這不僅是因?yàn)檫@種操作方式簡(jiǎn)單且易于理解, 更是因?yàn)閭鹘y(tǒng)密碼算法結(jié)構(gòu)一般是對(duì)稱(chēng)的, 雙方接發(fā)的消息具有相同的長(zhǎng)度, 而后量子KEM 算法通常沒(méi)有對(duì)稱(chēng)結(jié)構(gòu), 接收和發(fā)送的消息長(zhǎng)度并不一樣.先處理傳統(tǒng)算法的做法方便我們對(duì)算法數(shù)據(jù)進(jìn)行解析.這種設(shè)計(jì)方案簡(jiǎn)化了操作流程, 保證了協(xié)議的完整性和安全性, 同時(shí)避免了組合爆炸大量占用TLS 協(xié)議算法標(biāo)識(shí)預(yù)留位的現(xiàn)象.

3.2 后量子密鑰交換

在標(biāo)準(zhǔn)TLS 1.3 中, 密鑰協(xié)商使用的是橢圓曲線上的Diffie-Hellman (ECDH) 算法.客戶端發(fā)送ClientHello 請(qǐng)求, 并在該消息中攜帶supported_groups 擴(kuò)展(extension) 來(lái)指示客戶端支持的橢圓曲線類(lèi)型; 同時(shí), 客戶端需要提供key_share 擴(kuò)展發(fā)送每一個(gè)其所支持的橢圓曲線對(duì)應(yīng)的公鑰(橢圓曲線上的點(diǎn)).服務(wù)器收到ClientHello 消息得到了supported_groups 值并依據(jù)自己支持的橢圓曲線類(lèi)型選擇雙方共同接受的橢圓曲線參數(shù), 計(jì)算自己的公私鑰, 提取ClientHello 消息key_Share 擴(kuò)展中相應(yīng)的值(公鑰),計(jì)算共享密鑰(此時(shí)為handshake_traffic_key), 并用ServerHello 消息回復(fù)客戶端, 同時(shí)在ServerHello消息的key_share 擴(kuò)展中存放其選擇的橢圓曲線和相應(yīng)的公鑰.客戶端在接收到ServerHello 消息之后根據(jù)服務(wù)器的公鑰和自己的私鑰計(jì)算共享密鑰(此時(shí)為handshake_traffic_key).因?yàn)槭褂貌煌柠}值, 服務(wù)器和客戶端生成的handshake_traffic_key 并不相同, 但彼此可以計(jì)算對(duì)方的handshake_traffic_key,保證通訊正常進(jìn)行.

TLS 協(xié)議規(guī)范要求服務(wù)器先使用客戶端的公鑰和自己的私鑰生成共享密鑰, 再發(fā)送自己的公鑰給客戶端, 這為我們使用后量子KEM 算法提供可能.另外, TLS 1.3 中key_share 擴(kuò)展的最大容量是216-1=65 535 字節(jié), 這一容量可以支持大部分(混合模式)后量子KEM 算法的消息, 但是考慮到client的key_share 可以同時(shí)包含多個(gè)算法和算法公鑰, 我們需要關(guān)注這一點(diǎn), 確保TLS 的上下文配置不會(huì)導(dǎo)致key_share 超出該值的限制.

由于標(biāo)準(zhǔn)TLS 協(xié)議的密鑰交換運(yùn)行過(guò)程采用了對(duì)稱(chēng)的DH 算法, 客戶端和服務(wù)器的消息結(jié)構(gòu)、計(jì)算邏輯和處理步驟完全一致, 作用對(duì)等, 因此密鑰交換算法無(wú)需標(biāo)識(shí)身份.但NIST 和中國(guó)密碼算法設(shè)計(jì)競(jìng)賽規(guī)定可用于密鑰交換的是密鑰封裝算法, 它具有不同于DH 密鑰交換的消息結(jié)構(gòu)和處理邏輯.在協(xié)議的實(shí)現(xiàn)中必須注意到這種變化.為了在TLS 1.3 中可以使用后量子密鑰交換算法或者混合模式密鑰交換算法, 首先需要擴(kuò)展NamedGroup 中定義的橢圓曲線枚舉值, 將它們偽裝成為一個(gè)新的橢圓曲線, 并將其映射到對(duì)應(yīng)的執(zhí)行邏輯和處理流程.

混合模式要在協(xié)議雙方協(xié)商出兩個(gè)密鑰交換算法, 一個(gè)是傳統(tǒng)的ECDH 算法, 一個(gè)是后量子KEM算法.如3.1 節(jié)所述, 我們是把混合模式的兩個(gè)算法作為一個(gè)整體進(jìn)行協(xié)商.但是使用這種協(xié)商方式可能會(huì)存在組合爆炸的情況, 也就是說(shuō)傳統(tǒng)密碼和后量子密碼的組合形式太多, 增加了雙方在密鑰交換過(guò)程的處理負(fù)擔(dān), 缺乏抽象化和泛化能力, 也增加了實(shí)現(xiàn)部署的工作量.考慮到TLS 1.3 標(biāo)準(zhǔn)中, 在握手中進(jìn)行密鑰交換可供選擇的橢圓曲線數(shù)量是有限的, 而且不同密鑰交換方法可提供的安全級(jí)別也并不一樣, 我們按照安全級(jí)別匹配經(jīng)典算法和后量子算法, 不會(huì)產(chǎn)生組合大爆炸的問(wèn)題.此外, 我們的方案設(shè)計(jì)將混合模式的每一種組合都偽裝成為一個(gè)新的橢圓曲線進(jìn)行處理, 將算法的處理細(xì)節(jié)限制在crypto 層, 保證TLS 1.3 協(xié)議本身的邏輯沒(méi)有改變.

3.3 后量子認(rèn)證

在TLS 協(xié)議中, 密鑰交換用來(lái)生成對(duì)稱(chēng)加密算法的共享密鑰以建立機(jī)密性, 數(shù)字簽名用于身份認(rèn)證,這里主要涉及到兩個(gè)擴(kuò)展和一個(gè)消息.擴(kuò)展signature_algorithms_cert 用來(lái)告知對(duì)方自己可以支持的證書(shū)簽名方案; 擴(kuò)展signature_algorithms 用來(lái)告知對(duì)方自己可以支持的對(duì)協(xié)議數(shù)據(jù)進(jìn)行簽名的方案.這兩個(gè)擴(kuò)展都是算法標(biāo)識(shí)符列表.如果沒(méi)有signature_algorithms_cert 擴(kuò)展, signature_algorithms 擴(kuò)展也可以用于實(shí)現(xiàn)signature_algorithms_cert 的指示功能.加密傳輸?shù)南ertificateVerify 則攜帶了對(duì)當(dāng)前transcript 數(shù)據(jù)的簽名.

如同對(duì)密鑰交換混合模式的討論, 后量子混合簽名算法仍然按照單個(gè)簽名算法進(jìn)行處理, 其包含的每一個(gè)算法都應(yīng)該作用于要處理的消息, 公鑰是單個(gè)算法公鑰的級(jí)聯(lián), 簽名是單個(gè)算法簽名的級(jí)聯(lián).在集成后量子簽名算法的時(shí)候我們需要在SignatureScheme 中添加后量子簽名算法或者其混合模式的枚舉值,并將該值映射到對(duì)應(yīng)的處理過(guò)程.證書(shū)鏈的接收者應(yīng)該按照TLS 1.3 協(xié)議規(guī)范, 在signature_algorithms或signature_algorithms_cert 列表中加入該枚舉值以支持新的算法.

因?yàn)門(mén)LS 協(xié)議中需要認(rèn)證的一方的公鑰通常是通過(guò)X.509 證書(shū)來(lái)傳遞, 另外一個(gè)和簽名算法密切相關(guān)的是識(shí)別、解析和處理X.509 證書(shū).在TLS 1.3 中, X.509 證書(shū)或證書(shū)鏈的最大默認(rèn)值為224-1 字節(jié),簽名大小限制為216-1 字節(jié).這些長(zhǎng)度允許我們?cè)赥LS 1.3 協(xié)議中傳輸超長(zhǎng)的后量子證書(shū)和簽名.但是大多數(shù)后量子簽名方案的公鑰和簽名大小為10–200 KB, 這比今天典型的0.5 KB 左右的密鑰和簽名長(zhǎng)度要大得多, 就造成了傳輸證書(shū)和處理證書(shū)的巨大開(kāi)銷(xiāo).這些開(kāi)銷(xiāo)包括消息本身規(guī)模造成的傳播時(shí)延、傳輸時(shí)延, 處理時(shí)延和IP 分片造成的包含少量數(shù)據(jù)的MTU 帶來(lái)的開(kāi)銷(xiāo). 另外, 為了使用后量子簽名算法, 新的算法OID(object identifier, 對(duì)象標(biāo)識(shí)符又稱(chēng)為物聯(lián)網(wǎng)域名) 需要定義, 至少在協(xié)議通訊方之間達(dá)成共識(shí).X.509 證書(shū)中使用算法OID 標(biāo)識(shí)使用的簽名算法, 通過(guò)對(duì)X.509 算法OID 進(jìn)行擴(kuò)充, 定義新的算法標(biāo)識(shí)符, 將它們對(duì)應(yīng)于后量子簽名方案參數(shù)和結(jié)構(gòu), 可以在X.509 中添加對(duì)新的后量子簽名方案的支持.

盡管TLS 1.3 標(biāo)準(zhǔn)規(guī)定Certificate 消息可以傳輸實(shí)體對(duì)應(yīng)與不同算法的多個(gè)證書(shū), 也即通過(guò)兩個(gè)證書(shū)鏈來(lái)傳輸混合簽名算法的公鑰和簽名.但這種處理方式需要大量時(shí)間開(kāi)銷(xiāo)檢查證書(shū)列表以匹配混合模式簽名算法, 一種更簡(jiǎn)單的方法是讓一個(gè)X.509 證書(shū)包含多個(gè)算法的公鑰和多個(gè)算法的簽名.通過(guò)為每一個(gè)要使用的混合算法添加新的OID, 然后向上映射到X.509 證書(shū)的生成和管理, 添加PKI 對(duì)新的混合簽名方案的支持并用于TLS 身份認(rèn)證.一個(gè)完全遵循X.509 證書(shū)數(shù)據(jù)結(jié)構(gòu)和編碼規(guī)范的后量子證書(shū)如圖2 所示, 該證書(shū)使用級(jí)聯(lián)的方法容納混合模式后量子簽名方案的公鑰和簽名, 并需要在證書(shū)使用者之間就后量子簽名方案或者其混合模式的OID 之間達(dá)成共識(shí).

圖2 后量子證書(shū)Figure 2 Post quantum certificate

4 實(shí)現(xiàn)和實(shí)驗(yàn)設(shè)置

4.1 TLS 1.3 后量子集成實(shí)現(xiàn)

我們的目標(biāo)聚焦在TLS 1.3, 從安全性、性能、可維護(hù)、兼容性和開(kāi)放等原則以及模塊化設(shè)計(jì)的需要考慮, 我們選擇改造Facebook 的TLS 1.3 協(xié)議實(shí)現(xiàn)庫(kù)fizz 進(jìn)行后量子安全遷移.因?yàn)槟壳捌毡檎J(rèn)為量子計(jì)算機(jī)對(duì)對(duì)稱(chēng)密碼的影響有限, 遷移方案主要體現(xiàn)在握手過(guò)程的密鑰交換和認(rèn)證階段.需要注意的是fizz僅僅是TLS 1.3 協(xié)議的實(shí)現(xiàn), 它并不涉及密碼算法和證書(shū)處理的細(xì)節(jié), 對(duì)密碼算法和證書(shū)的處理依賴于其它算法庫(kù), 如OpenSSL 和libsodium 等.為在fizz 中增加對(duì)NIST 后量子算法的支持, 我們使用了Open Quantum Safe 項(xiàng)目提供的開(kāi)源庫(kù)liboqs, 該庫(kù)已經(jīng)提供了使用后量子密碼算法的統(tǒng)一接口; 為在fizz 中增加對(duì)中國(guó)密碼算法設(shè)計(jì)競(jìng)賽算法的支持, 我們首先需要將相應(yīng)代碼原型化, 然后在fizz 中使用統(tǒng)一接口進(jìn)行調(diào)用.另外, 因?yàn)橐?、解析和處理X.509 證書(shū), 我們需要在OpenSSL 庫(kù)中加入(混合) 后量子簽名算法, 并將其映射到對(duì)X.509 證書(shū)的處理.以上的操作均被視為是在crypto 層完成, 沒(méi)有涉及TLS 協(xié)議本身.下面簡(jiǎn)述設(shè)計(jì)方案的具體實(shí)現(xiàn).

密鑰交換. TLS 1.3 密鑰交換沒(méi)有提供KEM 風(fēng)格的接口.標(biāo)準(zhǔn)TLS 1.3 的密鑰交換使用的是基于橢圓曲線上的Diffie-Hellman 算法, 客戶端和服務(wù)器在握手階段密鑰生成、公鑰交換和共享秘密的計(jì)算處理完全一樣.但是NIST 提供的可用于密鑰交換的后量子KEM 算法和DH 密鑰交換完全不同, 客戶端和服務(wù)器具有不同的處理邏輯和消息結(jié)構(gòu).為了讓TLS 1.3 可以處理這種接口, 需要將KEM 偽裝成為DH 橢圓曲線上的密鑰交換, 適配標(biāo)準(zhǔn)TLS 1.3 的處理邏輯和消息結(jié)構(gòu).Fizz 中用KeyExchange 類(lèi)抽象了密鑰交換算法, 為了能夠使用后量子KEM, 需要在該類(lèi)中增加bool IsServer() 接口, 用于標(biāo)記在KEM形式密鑰協(xié)商過(guò)程中參與者的身份(客戶端還是服務(wù)器), 使得計(jì)算過(guò)程差異化.而傳統(tǒng)的DH 密鑰交換可以忽略這個(gè)過(guò)程(函數(shù)體為空).

統(tǒng)一了不同密鑰交換算法的接口, 我們就可以將后量子密鑰算法視作是對(duì)crypto 層函數(shù)的調(diào)用, 同樣的接口根據(jù)密碼算法的來(lái)源可以有不同的實(shí)現(xiàn).從KeyExchange 派生出的HybridKeyExchange 類(lèi)用于實(shí)現(xiàn)混合模式密鑰交換, 利用組合設(shè)計(jì)模式(composition design pattern), 該類(lèi)一方面可以重用原有代碼,簡(jiǎn)化實(shí)現(xiàn), 另一方面可以隱藏混合方案的實(shí)現(xiàn)細(xì)節(jié), 讓混合方案和非混合方案, 經(jīng)典算法和后量子KEM算法都可以具有相同的調(diào)用接口.這種抽象、繼承、派生和組合的設(shè)計(jì)與實(shí)現(xiàn)把所有關(guān)于算法的處理邏輯都放置在crypto 層, SSL 層僅僅需要擴(kuò)展NamedGroup 并建立NamedGroup 枚舉值和類(lèi)實(shí)體之間的映射關(guān)系即可.此時(shí), 在TLS 1.3 中加入后量子KEM 算法及其混合模式時(shí), 只是考慮如何合適地組合經(jīng)典算法和后量子算法生成混合方案, 不會(huì)涉及到復(fù)雜的TLS 執(zhí)行邏輯, 沒(méi)有改變協(xié)議的語(yǔ)法、語(yǔ)義和同步,也不會(huì)改變協(xié)議復(fù)雜并脆弱的狀態(tài)機(jī)而影響到協(xié)議的安全.這種實(shí)現(xiàn)方式也讓我們?cè)谶x擇后量子算法的時(shí)候具有更大的自由度和靈活性, 代碼的可維護(hù)性、可擴(kuò)展性和靈活性也更強(qiáng).圖3 展示了密鑰協(xié)商類(lèi)圖結(jié)構(gòu).其中OpenSSLKeyExchange 類(lèi)實(shí)現(xiàn)了標(biāo)準(zhǔn)TLS1.3 協(xié)議中密鑰交換算法, 即secp256r1、secp384r1和secpr521 橢圓曲線群上的DH 密鑰交換, 調(diào)用的是OpenSSL 中的代碼; X25519KeyExchange 類(lèi)實(shí)現(xiàn)的是x25519 橢圓曲線群上的DH 密鑰交換, 調(diào)用的是libsodium 中的代碼; AKCNKeyExchange 類(lèi)提供了對(duì)中國(guó)密碼算法設(shè)計(jì)競(jìng)賽中aigis-enc 和akcn-mlwe 的實(shí)現(xiàn).HybridKeyExchange 是透明處理混合模式密鑰協(xié)商算法的類(lèi), 該類(lèi)采用設(shè)計(jì)模式中的“composition pattern” 隱藏混合模式算法內(nèi)部的實(shí)現(xiàn)結(jié)構(gòu),可以重用KeyExchange 其它派生類(lèi)的代碼.

圖3 組合模式的擴(kuò)展密鑰交換類(lèi)圖Figure 3 Extended key exchange class diagram of composite pattern

認(rèn)證. 與使用繼承和多態(tài)機(jī)制處理密鑰交換算法的方式不同, 我們使用泛化來(lái)處理不同簽名方案的不同處理邏輯.為了在TLS 1.3 中增加(混合) 后量子簽名算法, 我們需要擴(kuò)展SignatureScheme, 增加(混合) 后量子簽名算法的枚舉值, 并在SSL 層中通過(guò)模板偏特化(partial specialize) 和類(lèi)型萃取(trait) 技術(shù), 建立不同簽名算法和處理邏輯之間的映射關(guān)系.需要注意的是, 如2.2 節(jié)所述, TLS 的認(rèn)證環(huán)節(jié)包含了證書(shū)識(shí)別和處理, 而fizz 中的證書(shū)識(shí)別和處理是通過(guò)OpenSSL 進(jìn)行的, 我們需要修改標(biāo)準(zhǔn)OpenSSL,在其中為每一個(gè)要使用的(混合) 后量子簽名算法增加可以在PKI 中唯一標(biāo)識(shí)該算法的OID, 確保該對(duì)象標(biāo)識(shí)符能夠被PKI 和TLS 通信雙方理解, 然后添加算法到OpenSSL 的通用信封公鑰對(duì)象(general envelop public key, EVP_PKEY), 并向上映射到X.509 證書(shū)的解析和管理.盡管過(guò)程非常復(fù)雜繁瑣, 在OpenSSL 中實(shí)現(xiàn)一個(gè)新的簽名方案并不困難, 處理流程主要集中在實(shí)現(xiàn)OpenSSL 高層密碼函數(shù)抽象接口EVP (high level cryptographic functions) 上.

如3.1 節(jié)討論那樣, 使用混合模式將TLS 1.3 向后量子安全遷移, 可能會(huì)存在組合爆炸的情況, 也就是說(shuō)傳統(tǒng)密碼算法和后量子密碼算法的組合形式太多, 增加了實(shí)現(xiàn)部署的工作量.為避免這種現(xiàn)象, 也從安全實(shí)現(xiàn)的角度考慮, 我們將安全強(qiáng)度匹配的經(jīng)典算法和后量子算法進(jìn)行組合.具體而言, 混合模式將安全強(qiáng)度為I 和II 的后量子算法和橢圓曲線secp256r1 上的經(jīng)典算法綁定, 安全強(qiáng)度為III 和IV 的后量子算法和橢圓曲線secp384r1 的經(jīng)典算法綁定, 安全強(qiáng)度為V 的后量子算法和橢圓曲線secp521r1 上的算法綁定.表1 和表2 展示的是我們網(wǎng)絡(luò)仿真實(shí)驗(yàn)中使用的混合算法的組合方案和混合方案的消息長(zhǎng)度, 這些后量子算法包括KEM 算法kyber[39]、saber[40]和ntru[41], 簽名算法dilithium[42]和falcon[43].其中有關(guān)長(zhǎng)度的列中每一項(xiàng)的單位是字節(jié), + 前面代表經(jīng)典方案的長(zhǎng)度, + 后面代表后量子方案的長(zhǎng)度.表1 中msg1 是客戶端發(fā)送給服務(wù)器端的消息, 其包含了經(jīng)典密鑰交換算法的公鑰和后量子KEM 算法的公鑰; msg2 是服務(wù)器返回給客戶端的消息, 其包含了經(jīng)典密鑰交換算法的公鑰和后量子KEM 算法的密文.所謂經(jīng)典算法是指對(duì)應(yīng)橢圓曲線上的DH 算法.表2 中沒(méi)有包含私鑰信息, 因?yàn)楹灻惴ǖ乃借€無(wú)需傳輸, 不會(huì)產(chǎn)生運(yùn)載負(fù)荷.其中經(jīng)典算法是指對(duì)應(yīng)橢圓曲線上的ECDSA 算法.同前面的約定一樣, + 前面代表經(jīng)典方案的長(zhǎng)度, + 后面代表后量子方案的長(zhǎng)度.為了描述方便, 我們使用算法的簡(jiǎn)稱(chēng), 如用p256代表橢圓曲線secp256r1, 用ntru 算法最后三個(gè)數(shù)字代表其全稱(chēng), 省去中間算法參數(shù)的描述, 如用ntru509替代ntruhps2048509.在涉及混合模式算法名稱(chēng)時(shí), 我們經(jīng)常省去經(jīng)典算法的名字, 如用kyber512 代表p256_kyber512, 用falcon1024 代表p521_falcon1024.需要說(shuō)明的是: 第一, falcon 算法的簽名長(zhǎng)度是可變的, 表中顯示的是平均長(zhǎng)度; 第二, 后量子算法尤其是后量子簽名算法運(yùn)行并不穩(wěn)定, 運(yùn)行時(shí)間經(jīng)常會(huì)有較大的變化.參考4 和表5 中相關(guān)算法運(yùn)行時(shí)間的標(biāo)準(zhǔn)差數(shù)值, 后量子算法運(yùn)行時(shí)間的標(biāo)準(zhǔn)差都比較大,甚至可以達(dá)到幾十或者幾百; 第三, 通過(guò)數(shù)字證書(shū)傳輸?shù)暮灻凸€通常使用DER 編碼或BASE64 編碼, 長(zhǎng)度上會(huì)有增加, 表中的數(shù)據(jù)并沒(méi)有考慮因?yàn)檫@些額外的處理細(xì)節(jié)而發(fā)生的改變.

表1 混合模式密鑰交換算法消息長(zhǎng)度Table 1 Message length of hybrid-mode key exchange scheme

表2 混合模式簽名算法消息長(zhǎng)度Table 2 Message length of hybrid-mode signature scheme

更多細(xì)節(jié)和處理請(qǐng)參考方案的代碼實(shí)現(xiàn)https://github.com/gudengxia/PQTLS1_3.git.

4.2 實(shí)驗(yàn)設(shè)置

為了在實(shí)驗(yàn)中控制網(wǎng)絡(luò)特性, 依賴于Linux 內(nèi)核中流量控制(traffic control, TC) 和網(wǎng)絡(luò)虛擬化命名空間(net namespace, netns), 我們開(kāi)發(fā)實(shí)現(xiàn)了一個(gè)網(wǎng)絡(luò)仿真框架.

Linux 內(nèi)核提供了創(chuàng)建網(wǎng)絡(luò)命名空間的能力, 這些命名空間相當(dāng)于內(nèi)核網(wǎng)絡(luò)堆棧的一個(gè)副本.每個(gè)命名空間都有自己的路由、網(wǎng)絡(luò)地址、防火墻規(guī)則、端口和網(wǎng)絡(luò)設(shè)備, 這意味著使用netns 創(chuàng)建的網(wǎng)絡(luò)空間相互獨(dú)立.因此, 使用netns 網(wǎng)絡(luò)空間可以在本地虛擬化出多個(gè)獨(dú)立網(wǎng)絡(luò), 使得我們可以在單個(gè)系統(tǒng)上模擬復(fù)雜的協(xié)議運(yùn)行環(huán)境.

我們使用虛擬以太網(wǎng)設(shè)備(virtual device, veth-pair)連接兩個(gè)不同命名空間.內(nèi)核網(wǎng)絡(luò)仿真(netem)模塊可以控制這些虛擬以太網(wǎng)設(shè)備上的數(shù)據(jù)傳輸, 指示內(nèi)核對(duì)通過(guò)以太網(wǎng)設(shè)備的數(shù)據(jù)包進(jìn)行分類(lèi)、管理、檢測(cè)擁塞和處理?yè)砣? 控制從以太網(wǎng)設(shè)備發(fā)出的數(shù)據(jù)包的網(wǎng)絡(luò)延遲和丟包率等.為了給鏈路一個(gè)xms 的往返時(shí)間, netem 指示內(nèi)核對(duì)網(wǎng)絡(luò)虛擬設(shè)備(veth-pair) 的每個(gè)傳出包應(yīng)用x/2 ms 的延遲, 為了給鏈路一個(gè)期望的丟包率y%, netem 指示內(nèi)核以y% 的概率丟棄鏈路兩端設(shè)備上的傳出包.使用netns 建立模擬網(wǎng)絡(luò)環(huán)境并利用netem 控制網(wǎng)絡(luò)特性, 我們能夠隔離出不同網(wǎng)絡(luò)特性對(duì)TLS 1.3 的握手性能產(chǎn)生的影響.

實(shí)驗(yàn)中, 我們創(chuàng)建了三個(gè)網(wǎng)絡(luò)命名空間, 并使用veth 連接它們, 第一個(gè)網(wǎng)絡(luò)命名空間ns1 表示客戶機(jī)所在網(wǎng)絡(luò), 第二個(gè)命名空間ns2 表示服務(wù)器所在網(wǎng)絡(luò), 第三個(gè)命名空間ns-router 表示連接客戶端和服務(wù)器的路由網(wǎng)絡(luò).客戶端網(wǎng)絡(luò)ns1 通過(guò)虛擬網(wǎng)卡veth1 連接到路由網(wǎng)絡(luò)ns-router 的虛擬網(wǎng)絡(luò)接口veth1-router, 服務(wù)器網(wǎng)絡(luò)ns2 通過(guò)虛擬網(wǎng)卡veth2 連接到路由網(wǎng)絡(luò)ns-router 的虛擬網(wǎng)絡(luò)接口veth2-router.通過(guò)開(kāi)啟linux 內(nèi)核ip 轉(zhuǎn)發(fā)功能, 處于不同網(wǎng)絡(luò)的客戶端和服務(wù)器實(shí)現(xiàn)互聯(lián).圖4 顯示了我們實(shí)驗(yàn)使用的模擬網(wǎng)絡(luò)環(huán)境.

圖4 實(shí)驗(yàn)?zāi)M網(wǎng)絡(luò)Figure 4 Simulated network in experiments

我們通過(guò)網(wǎng)絡(luò)延遲來(lái)模擬客戶端距離服務(wù)器的物理距離和經(jīng)過(guò)的路由器和網(wǎng)關(guān)數(shù)量, 低延遲代表距離較近, 數(shù)據(jù)包傳輸需要經(jīng)過(guò)的網(wǎng)關(guān)或路由器較少, 高延遲代表距離較遠(yuǎn), 數(shù)據(jù)包傳輸需要經(jīng)過(guò)的網(wǎng)關(guān)或路由器較多.丟包率用來(lái)模擬網(wǎng)絡(luò)質(zhì)量, 低丟包率用來(lái)模擬高質(zhì)量的有線以太網(wǎng), 高丟包率用來(lái)模擬低質(zhì)量的網(wǎng)絡(luò)或者高負(fù)載的wifi 網(wǎng)絡(luò).對(duì)于每組網(wǎng)絡(luò)延遲, 我們考察丟包率在0% 到10%(概率獨(dú)立地應(yīng)用于每個(gè)分組) 之間變化時(shí)對(duì)TLS 1.3 握手的影響.根據(jù)Mozilla 在2019 年9 月和10 月對(duì)Firefox (nightly 71) 中丟棄的數(shù)據(jù)包進(jìn)行的監(jiān)測(cè)顯示, 在臺(tái)式計(jì)算機(jī)上, 數(shù)據(jù)包丟失率高于5% 的情況并不多見(jiàn): 例如,在WEBRTC_AUDIO_QUALITY_OUTBOUND_PACKETLOSS_RATE 的分布中, 所收集的3550萬(wàn)個(gè)樣本中, 67% 的數(shù)據(jù)包丟失率低于0.1%, 89% 的數(shù)據(jù)包丟失率小于1%, 95% 的數(shù)據(jù)包丟失率小于4.3%, 97% 的數(shù)據(jù)包丟失率小于20%[22,24].

在服務(wù)器的命名空間, 我們運(yùn)行修改版本的fizz 服務(wù)器, 它可以依次處理來(lái)自客戶端的網(wǎng)絡(luò)請(qǐng)求.在客戶端命名空間中, 我們批量運(yùn)行fizz 修改版本的客戶端, 記錄每一次握手所需時(shí)間并在握手完成后立即關(guān)閉, 開(kāi)始運(yùn)行下一次握手.對(duì)于延遲和丟包率的每一對(duì)組合, 實(shí)驗(yàn)運(yùn)行6000 次測(cè)試.更詳細(xì)的實(shí)驗(yàn)測(cè)試平臺(tái)的設(shè)置和實(shí)驗(yàn)代碼可以參考https://github.com/gudengxia/TestPlatform.git.這些實(shí)驗(yàn)是在一臺(tái)安裝Linux 操作系統(tǒng)(Ubuntu Server 20.04.1 LTS) 的臺(tái)式電腦上進(jìn)行的, 該電腦擁有一個(gè)4 核CPU, 其型號(hào)為Intel(R) Core(TM) i5-7400T CPU @ 2.40 GHz, 擁有8 GB 內(nèi)存.

5 實(shí)驗(yàn)結(jié)果與分析

我們的網(wǎng)絡(luò)仿真實(shí)驗(yàn)僅測(cè)試TLS 1.3 1-RTT 模式握手所需的時(shí)間.大部分情況下后量子密碼算法性能差距在幾十微秒, 對(duì)比網(wǎng)絡(luò)傳播時(shí)延和傳輸時(shí)延, 建立TLS 連接時(shí)因?yàn)槊艽a算法的處理時(shí)延造成的性能差距并不明顯.一般情況下, 網(wǎng)絡(luò)上一個(gè)數(shù)據(jù)包的往返時(shí)間(round trip time, RTT) 大概在幾毫秒甚至于幾百毫秒, 建立TLS 握手則需要更大的開(kāi)銷(xiāo), 可以預(yù)見(jiàn)后量子算法性能上的差距對(duì)TLS 握手造成的影響有限, 網(wǎng)絡(luò)延遲越大, 這種差異的可見(jiàn)性(被感知的可能性) 越小.

在我們的大規(guī)模實(shí)驗(yàn)基本結(jié)束并開(kāi)始撰寫(xiě)本文之際, NIST 的評(píng)估過(guò)程已經(jīng)從第二輪轉(zhuǎn)向第三輪, 而在第三輪中選擇的5 種格基后量子算法都在我們的測(cè)試之列.我們重點(diǎn)介紹了對(duì)這些算法的評(píng)估和測(cè)試,盡管使用的是第二輪的代碼, 我們也正在逐步將我們的代碼向NIST 第三輪的算法遷移.實(shí)驗(yàn)中, 我們假設(shè)一個(gè)經(jīng)典的TLS 應(yīng)用場(chǎng)景, 身份認(rèn)證是單向的, 也即服務(wù)器需要傳輸X.509 證書(shū)鏈向客戶端認(rèn)證身份, 客戶端保持匿名, 不需要向服務(wù)器傳輸證書(shū)鏈認(rèn)證身份.所有TLS 1.3 握手都使用完整1-RTT 模式的握手, 并且客戶端發(fā)送的supported_groups 中只包含一個(gè)混合密鑰交換算法和其公鑰, 以盡可能減少ClientHello 消息的長(zhǎng)度, 隔離后量子算法產(chǎn)生報(bào)文長(zhǎng)度差異對(duì)握手連接帶來(lái)的影響.在實(shí)驗(yàn)中, 我們使用的證書(shū)鏈長(zhǎng)度為2, root CA 使用混合后量子簽名算法生成自簽證書(shū)(CA 證書(shū)), 并負(fù)責(zé)簽署ICA 的證書(shū);ICA 負(fù)責(zé)簽署服務(wù)器的證書(shū).服務(wù)器需要傳輸包含了ICA 的證書(shū)和自身證書(shū)的證書(shū)鏈到客戶端, 客戶端使用CA 的公鑰驗(yàn)證ICA 的證書(shū), 使用ICA 的公鑰認(rèn)證服務(wù)器的證書(shū).因?yàn)樽C書(shū)的私鑰和CA 對(duì)證書(shū)的簽名在線下進(jìn)行, 所以, 在我們的實(shí)驗(yàn)場(chǎng)景中, TLS 握手需要一次密鑰交換、一次簽名和三次驗(yàn)簽.另外,我們按照安全級(jí)別綁定使用的混合后量子密鑰交換算法和混合后量子簽名算法.對(duì)于NIST Level 1 的每一個(gè)后量子密鑰交換算法擁有兩種選擇dilithium2 和falcon512, 而對(duì)于Level 3 和Level 5 的后量子密鑰交換算法只能有一種選擇.我們測(cè)試了每一種組合其發(fā)送的ClientHello 和ServerHello 報(bào)文的大小.盡管在TLS 1.3 中集成格基后量子算法大大增加了握手過(guò)程需要傳輸?shù)臄?shù)據(jù)量, 但是TCP/IP 協(xié)議的分段機(jī)制可以保證協(xié)議的正常運(yùn)行.表3 描述了在TLS 1.3 中使用NIST 第2 輪密碼算法的混合模式產(chǎn)生的ClientHello 報(bào)文和ServerHello+ 報(bào)文的長(zhǎng)度, 長(zhǎng)度的單位是字節(jié).ServerHello+ 表示了ServerHello消息和隨其發(fā)送的EncrytedExtentions、CertificateRequest、Certificate、CertificateCerify 和Finished等消息.因?yàn)樵趯?shí)驗(yàn)中, 對(duì)于確定安全級(jí)別的后量子算法, 其綁定的經(jīng)典算法已經(jīng)確定, 所以表中用后量子算法的名字簡(jiǎn)稱(chēng)混合模式的名字.注意這些長(zhǎng)度并不是確定值, 它們會(huì)隨著TLS 鏈接上下文參數(shù)以及證書(shū)的不同而高度可變, 實(shí)驗(yàn)盡可能采用相同的配置參數(shù)和極簡(jiǎn)的擴(kuò)展結(jié)構(gòu)抑制這種變化.

5.1 密鑰交換

總體而言, 在NIST 的三種KEM 算法中, kyber 和saber 具有相似的時(shí)間性能, 但是kyber 公鑰較大, saber 公鑰較短; ntru 算法具有較短的公鑰和密文, 但是其性能較之其它兩種算法相差較大.表4 是關(guān)于NIST 第二輪密鑰封裝算法消息長(zhǎng)度和算法單獨(dú)運(yùn)行時(shí)性能相關(guān)信息的描述, 其中長(zhǎng)度相關(guān)數(shù)據(jù)的單位是字節(jié), mean 是算法的平均運(yùn)行時(shí)間, 單位是μs, St.Dev. 是運(yùn)行時(shí)間的標(biāo)準(zhǔn)差.從時(shí)間上比較, 在相同安全級(jí)別下saber 算法的運(yùn)行效率最高, kyber 次之, 但這種差距一般在十個(gè)微秒左右, 相較于TLS 握手的整體開(kāi)銷(xiāo)并不明顯; ntru 算法的效率同以上兩者差距很大, 運(yùn)行也最不穩(wěn)定, 尤其是密鑰生成算法, 其耗時(shí)是前兩者的幾十倍.從帶寬角度考慮, ntru 最優(yōu), saber 次之, kyber 最差.考慮到以太網(wǎng)中MTU 值一般為1500 字節(jié), 也即TCP 分段可以容納的數(shù)據(jù)為1460 字節(jié), 不同后量子密鑰封裝算法公鑰之間的差值最多只會(huì)導(dǎo)致ClientHello 消息增加一個(gè)TCP 報(bào)文(IP 包).表3 中的數(shù)據(jù)也表明, 除了安全級(jí)別Level II 中p384_kyber768 和p384_dilithium4 組合, 以及安全級(jí)別Level V 中p521_kyber1024 和p521_falcon1024 組合, TLS 1.3 在使用混合模式的密鑰交換算法時(shí)運(yùn)載它們產(chǎn)生的ClientHello 消息只需要1 個(gè)TCP 報(bào)文, 運(yùn)載p384_kyber768 和521_kyber1024 的公鑰則需要一個(gè)額外的TCP 報(bào)文.三個(gè)算法密文長(zhǎng)度的差距也在1460 字節(jié)范圍內(nèi), 至多會(huì)產(chǎn)生一個(gè)額外的報(bào)文, 而且ServerHello+ 消息的容量主要來(lái)自證書(shū)鏈, 密文長(zhǎng)度的差距帶來(lái)實(shí)質(zhì)性的影響并不大, 在我們的實(shí)驗(yàn)中也沒(méi)有出現(xiàn)因?yàn)槊芪拈L(zhǎng)度的差別而導(dǎo)致產(chǎn)生額外TCP 報(bào)文的現(xiàn)象.根據(jù)這種分析, 我們認(rèn)為密鑰交換算法公鑰和密文長(zhǎng)度給TLS 1.3 的握手性能帶來(lái)的影響極小, 相應(yīng)的實(shí)驗(yàn)結(jié)果也證實(shí)了這種推論, 因此實(shí)驗(yàn)主要關(guān)注在TLS 1.3 中使用后量子密鑰封裝算法計(jì)算性能對(duì)握手造成的影響.

表3 ClientHello 和ServerHello+ 消息長(zhǎng)度Table 3 Message length of clientHello and serverHello

表4 NIST 第二輪密鑰封裝算法單獨(dú)運(yùn)行的性能Table 4 Performace of KEM scheme moved on to NIST round 2 running separately

圖5 是我們?cè)赥LS1.3 協(xié)議中使用相同簽名算法和不同密鑰交換算法時(shí)握手時(shí)間隨丟包率上升而產(chǎn)生的變化曲線.每一幅子圖中橫坐標(biāo)代表丟包率, 縱坐標(biāo)是握手時(shí)間, 單位是ns.子圖文字中的RTT 值是實(shí)驗(yàn)所用模擬網(wǎng)絡(luò)的round trip time, Signature 說(shuō)明的是握手所使用的作為基線的后量子簽名算法.圖中算法使用的混合模式的簡(jiǎn)稱(chēng).對(duì)每一組算法的每一個(gè)丟包率, 我們運(yùn)行6000 次握手并計(jì)算其平均運(yùn)行時(shí)間, 曲線代表平均握手時(shí)間隨丟包率的變化情況.

為了比較 NIST Level 1 的后量子混合密鑰交換算法, 我們分別使用 p256_dilithium2 和p256_falcon512 作為基線. 圖5(a) 是使用p256_falcon512 簽名算法, RTT 為5.5 ms 時(shí), 使用三種不同密鑰交換算法握手所需平均時(shí)間隨丟包率的變化; 圖5(b) 是使用p256_dilithium2 簽名算法, RTT為30 ms 時(shí), 使用三種不同密鑰交換算法握手所需平均時(shí)間隨丟包率的變化. 圖5(c) 和圖5(d) 分別是比較NIST Level 3 和NIST Level 5 的混合密鑰交換算法時(shí)平均握手時(shí)間隨丟包率的變化. 其中圖5(c) 中的實(shí)驗(yàn)使用p384_dilithium4 作為基線; 圖5(d) 中的實(shí)驗(yàn)使用p521_falcon1024 作為基線. 這兩組實(shí)驗(yàn)使用的RTT 值都為1 ms. 使用不同基線的實(shí)驗(yàn)結(jié)果表明, (混合模式)kyber 和saber 算法在TLS 握手時(shí)間開(kāi)銷(xiāo)上幾乎不可區(qū)分, 在延遲較小和丟包率較低的鏈路上, 仍然可以清晰看到以上兩者體現(xiàn)出來(lái)的對(duì)ntru 的優(yōu)勢(shì), 這和單個(gè)算法的評(píng)測(cè)一致. 也就是說(shuō), 在高質(zhì)量(具有較小延遲和較低丟包率) 鏈路上, 公鑰和密文大小對(duì)握手完成時(shí)間影響極小, 影響握手性能的主要是密碼算法的計(jì)算時(shí)間. 隨著網(wǎng)絡(luò)延遲的增加和丟包率的上升, TLS 的握手開(kāi)銷(xiāo)會(huì)逐漸增大, TLS 握手幾十毫秒甚至更多的開(kāi)銷(xiāo)使得后量子算法幾十微秒的差距變得不是那么明顯, 網(wǎng)絡(luò)延遲會(huì)完全隱藏算法性能的差異.

圖5 TLS1.3 中使用不同后量子密鑰交換算法握手性能隨丟包率的變化Figure 5 Performances of handshake in TLS1.3 using different PQ key exchange algorithms associated with packet loss

5.2 認(rèn)證

如本節(jié)開(kāi)始所述, 在我們實(shí)驗(yàn)場(chǎng)景中證書(shū)鏈的結(jié)構(gòu)是CA→ICA→Server, 為了認(rèn)證證書(shū)需要二次驗(yàn)簽操作; 服務(wù)器生成CertificateVerify 消息需要使用與證書(shū)中公鑰相對(duì)應(yīng)的私鑰對(duì)整個(gè)握手進(jìn)行簽名, 客戶端需要使用服務(wù)器證書(shū)的公鑰驗(yàn)證該簽名.因此在整個(gè)握手階段需要進(jìn)行一次簽名和三次驗(yàn)簽操作.因?yàn)椴煌瑓?shù)dilithium 提供的安全級(jí)別為I、II 和III, 不同參數(shù)falcon 提供的安全級(jí)別為I 和V, 考慮到需要在相同安全級(jí)別下比較算法的性能, 實(shí)驗(yàn)中對(duì)簽名算法的比較只能集中在Level 1 安全級(jí)別的算法p256_dilithium2 和p256_falcon512.表5 是關(guān)于NIST 第二輪簽名算法消息長(zhǎng)度和運(yùn)行性能相關(guān)信息,其中關(guān)于長(zhǎng)度相關(guān)數(shù)據(jù)的單位是字節(jié), 時(shí)間相關(guān)數(shù)據(jù)的單位是μs, 需要注意的是falcon512 的簽名長(zhǎng)度并不固定, 表中列出的是平均長(zhǎng)度.表中數(shù)據(jù)可以看出, 盡管falcon512 在帶寬方面具有較大的優(yōu)勢(shì), 可以使得其在TLS 握手中可以少傳遞2–3 個(gè)報(bào)文(依賴于證書(shū)的大小和證書(shū)鏈的長(zhǎng)度).但是其計(jì)算性能同dilithium2 有相當(dāng)差距, 可以預(yù)見(jiàn)在丟包率較低的鏈路上, 其帶寬優(yōu)勢(shì)并不能充分發(fā)揮.實(shí)驗(yàn)結(jié)果也同預(yù)先分析相符.

表5 NIST 第二輪簽名算法單獨(dú)運(yùn)行的性能Table 5 Performace of signature scheme moved on to NIST round 2 running separately

和密鑰交換類(lèi)似, 網(wǎng)絡(luò)延遲會(huì)隱藏簽名算法性能上的差距.但在延遲較小的鏈路上, p256_dilithium2的計(jì)算性能優(yōu)勢(shì)能夠得到體現(xiàn), 如圖6 所示. 圖中橫坐標(biāo)代表丟包率, 縱坐標(biāo)是握手時(shí)間, 單位是ns, 圖中文字的RTT 值是實(shí)驗(yàn)鏈路中round trip time,KEX 說(shuō)明的是使用的作為基線的后量子密鑰封裝算法.圖中可以看出,隨著丟包率的增加,p256_falcon512 的性能劣勢(shì)會(huì)慢慢消減,甚至體現(xiàn)出對(duì)p256_dilithium2的優(yōu)勢(shì).參考表3 中的數(shù)據(jù),使用dilithium2 的握手需要8 個(gè)報(bào)文傳遞其ServerHello 消息,使用falcon512的握手僅需要5 個(gè)報(bào)文傳遞其ServerHello 消息, 少傳遞的三個(gè)報(bào)文會(huì)使其隨著丟包率的增長(zhǎng)掩蓋其計(jì)算性能上劣勢(shì). 一方面, 因?yàn)橐獋鬟f的報(bào)文較少, 需要重傳的報(bào)文相應(yīng)減少, 會(huì)減少TLS 握手時(shí)的傳播時(shí)延; 另一方面, 隨著丟包率的增加握手開(kāi)銷(xiāo)也會(huì)增長(zhǎng), 從而淹沒(méi)了算法計(jì)算性能上的差異.圖6(a) 具體展示了使用ntru509 作為基線的兩種不同簽名算法TLS 平均握手時(shí)間隨丟包率的變化.在10% 丟包率左右, dilithium2 相對(duì)于falcon512 的性能優(yōu)勢(shì)消失殆盡. 此后, 隨著丟包率的上升, falcon512 的帶寬優(yōu)勢(shì)越來(lái)越明顯.圖6(b) 是握手時(shí)間的差值隨丟包率的變化.該圖清晰表明了使用p256_dilithium2 較使用p256_falcon512 的優(yōu)勢(shì)在10% 丟包率左右反轉(zhuǎn)的現(xiàn)象.數(shù)據(jù)的抖動(dòng)一方面是因?yàn)閬G包是概率事件, 另一方面是因?yàn)楹罅孔铀惴ㄓ绕涫呛罅孔雍灻惴ㄟ\(yùn)行并不穩(wěn)定, 經(jīng)常具有較大的方差(標(biāo)準(zhǔn)差).盡管如此,該實(shí)驗(yàn)結(jié)果表明了在丟包率較高的鏈路上, 具有較短公鑰/簽名的falcon512 算法擁有優(yōu)勢(shì).

圖6 TLS1.3 中使用不同簽名算法握手性能隨丟包率的變化Figure 6 Handshake of performances in TLS1.3 using different PQ signature algorithms associated with packet loss

另一種分析方法是分析握手時(shí)間的躍遷.一般情況下, 一個(gè)算法的運(yùn)行時(shí)間雖然會(huì)有變化, 但如同自然界的大部分現(xiàn)象, 這種變化會(huì)比較平緩.基于這種認(rèn)識(shí), 可以認(rèn)為導(dǎo)致握手時(shí)間發(fā)生突然躍遷的事件極有可能是丟包.通過(guò)將相同丟包率下的6000 次握手時(shí)間排序, 我們選擇幾個(gè)不同丟包率下發(fā)生躍遷的片段查看TLS 握手時(shí)間的變化.圖7 的兩張子圖分別是我們?cè)谑褂胮256_kyber512 作為密鑰交換算法時(shí),在RTT 為2.5 ms 的鏈路上使用不同簽名算法握手時(shí)間的躍遷圖.圖中縱坐標(biāo)是握手時(shí)間, 單位是ns.圖7(a) 是丟包率在10% 時(shí)發(fā)生在第5760–5800 個(gè)數(shù)據(jù)之間的片段, 圖7(b) 是丟包率在6% 時(shí)發(fā)生在第5900–5995 個(gè)數(shù)據(jù)之間的片段.圖中可以看出, dilithium2 比f(wàn)alcon512 更早發(fā)生躍遷, 因?yàn)樗枰獋鬟f更多的報(bào)文; 隨著丟包率的增長(zhǎng), 躍遷發(fā)生的也越早.實(shí)驗(yàn)結(jié)果符合我們的推理.

圖7 TLS1.3 中使用不同簽名算法平均握手時(shí)間的躍遷Figure 7 Transition of average handshake time for different signature algorithms in TLS1.3

5.3 國(guó)產(chǎn)后量子密碼算法

除了集成和測(cè)試NIST 第二輪中的格基密碼算法, 我們也原型化了中國(guó)密碼算法設(shè)計(jì)競(jìng)賽獲獎(jiǎng)的后量子KME 算法aigis-enc 和akcn-mlwe、后量子簽名算法aigis-sig 和mulan, 并集成到fizz 中在TLS1.3握手時(shí)使用它們或者它們的混合模式, 測(cè)試它們的性能并和其N(xiāo)IST 等價(jià)算法進(jìn)行了比較.為了描述方便, 我們?nèi)匀恢皇褂煤罅孔铀惴ǖ拿Q(chēng)代表其混合模式, 并且簡(jiǎn)稱(chēng)akcn-mlwe 為akcn, 有時(shí)也把a(bǔ)igis-enc和aigis-sig 統(tǒng)稱(chēng)為aigis.這些算法中, akcn 對(duì)比kyber768, mulan 對(duì)比dilithium3, 使用的是C 語(yǔ)言版本; aigis-enc 對(duì)比kyber768-90s, aigis-sig 對(duì)比dilithium3, 使用的是avx2 代碼.算法的實(shí)際性能評(píng)測(cè)如表6、表7 和表8 所示, 表中關(guān)于長(zhǎng)度相關(guān)數(shù)據(jù)的單位是字節(jié), 時(shí)間相關(guān)數(shù)據(jù)的單位是μs.表6 是密鑰封裝算法的評(píng)測(cè)對(duì)比, 比較可以得出中國(guó)密碼算法設(shè)計(jì)競(jìng)賽的akcn 在性能比kyber768 的參考實(shí)現(xiàn)略有提升, aigis-enc 比較kyber768-90s 的avx2 實(shí)現(xiàn)性能些許下降; 國(guó)產(chǎn)的兩種后量子KEM 算法具有較短的公鑰和密文.表7 是簽名算法的評(píng)測(cè)對(duì)比, 比較可以得出mulan 性能優(yōu)于dilithium3 的參考實(shí)現(xiàn), aigis-sig的性能優(yōu)于dilithium3 的avx2 實(shí)現(xiàn).表中數(shù)據(jù)表明所有的差距都在數(shù)十微秒之間, 可以預(yù)見(jiàn)計(jì)算性能對(duì)TLS 握手產(chǎn)生的影響幾乎可以忽略.但KEM 算法akcn 和aigis-enc 的公鑰長(zhǎng)度的減少恰好可以使TLS的ClientHello 消息少產(chǎn)生一個(gè)TCP 報(bào)文(IP 包), mulan 和aigis-sig 較短的公鑰/簽名使ServerHello+消息少產(chǎn)生一個(gè)TCP 報(bào)文, 在握手過(guò)程共節(jié)省2 個(gè)報(bào)文.具體TLS 消息長(zhǎng)度參考表8 中的數(shù)據(jù).

表6 國(guó)產(chǎn)后量子KEM 算法和對(duì)應(yīng)NIST 后量子KEM 算法性能比較Table 6 Comparison of performance between Chinese KEM and referential NIST’s KEM

表7 國(guó)產(chǎn)后量子簽名算法和對(duì)應(yīng)NIST 后量子簽名算法性能比較Table 7 Comparison of performance between Chinese signature and referential NIST’s signature

表8 TLS1.3 握手階段報(bào)文長(zhǎng)度Table 8 Length of packets in TLS1.3’s handshake

實(shí)測(cè)性能如圖8 所示, 不管是 p384_akcn-mlwe 和 p256_mulan 的組合對(duì)比 p384_kyber768和 p256_dilithium3 的 (C 參考實(shí)現(xiàn)) 組合, 還是 p384_aigis-enc 和 p256_aigis-sig 的組合對(duì)比p384_kyber768-90s 和p256_dilithium3 的(avx2 實(shí)現(xiàn)) 組合都表現(xiàn)出非常接近的性能.然而, 隨著丟包率的上升,中國(guó)密碼算法競(jìng)賽的算法由于較小的帶寬產(chǎn)生的優(yōu)勢(shì)會(huì)有所體現(xiàn).其中,圖8(a)是aigis-enc 和aigis-sig 的組合比較kyber768-90s 和dilithium3 的組合,圖8(b)是akcn 和mulan 的組合比較kyber768和dilithium3 的組合.因?yàn)樵谟?jì)算性能上和NIST 的算法沒(méi)有明顯差距而擁有帶寬優(yōu)勢(shì), 中國(guó)密碼算法競(jìng)賽的算法更加適于實(shí)際應(yīng)用.

圖8 國(guó)產(chǎn)后量子密碼算法在TLS1.3 中的性能Figure 8 Performances of Chinese post quantum algorithms in TLS1.3

6 總結(jié)

量子算法可以攻破目前使用的公鑰密碼體制, 對(duì)我們的網(wǎng)絡(luò)安全構(gòu)成重大威脅.為保護(hù)關(guān)鍵基礎(chǔ)設(shè)施和機(jī)密資產(chǎn), 必須盡快開(kāi)展將后量子安全等價(jià)產(chǎn)品取代現(xiàn)有密碼系統(tǒng)的工作, 公鑰密碼替換的任務(wù)更加緊迫.本文我們分析了NIST 后量子密碼項(xiàng)目和中國(guó)密碼算法設(shè)計(jì)競(jìng)賽的格基后量子密碼算法, 并從性能、安全級(jí)別和公鑰/密文/簽名大小等方面對(duì)它們進(jìn)行了比較; 探討了將這些算法集成到TLS 1.3 的可行性和方法, 介紹了將后量子密鑰封裝和簽名算法及其混合模式添加到TLS 1.3 時(shí)需要對(duì)標(biāo)準(zhǔn)草案做出的必要修改, 并在Facebook 的fizz 庫(kù)上實(shí)現(xiàn)了后量子安全的TLS 1.3 協(xié)議, 能夠使其與當(dāng)今的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施共存.此外, 我們還構(gòu)建了一個(gè)測(cè)試TLS 協(xié)議在各種網(wǎng)絡(luò)條件下性能的實(shí)驗(yàn)框架, 可以在一臺(tái)機(jī)器上模擬客戶機(jī)-服務(wù)器網(wǎng)絡(luò)實(shí)驗(yàn), 精確量化僅僅由網(wǎng)絡(luò)延遲或路由上的丟包對(duì)建立TLS 連接產(chǎn)生的影響.測(cè)試結(jié)果表明, TCP/IP 的分段機(jī)制可以保證具有超長(zhǎng)報(bào)文的后量子TLS 1.3 協(xié)議正常運(yùn)行; 網(wǎng)絡(luò)延遲是影響握手時(shí)間的主要因素, 它隱藏了大部分后量子算法計(jì)算性能上的差異; 對(duì)于密鑰交換算法, 公鑰和密文長(zhǎng)度的差異并沒(méi)有給在TLS 中使用它們帶來(lái)實(shí)質(zhì)性的影響; 在高質(zhì)量的鏈路上, dilithium 簽名算法因?yàn)橛?jì)算性能的優(yōu)勢(shì)有具有較強(qiáng)的競(jìng)爭(zhēng)力, 而在丟包率較大的鏈路上, falcon 會(huì)體現(xiàn)出它的帶寬優(yōu)勢(shì).我們的實(shí)驗(yàn)結(jié)果也為在不同網(wǎng)絡(luò)條件下對(duì)后量子算法的使用提供指導(dǎo), 有助于后量子算法進(jìn)一步標(biāo)準(zhǔn)化和TLS 1.3向后量子發(fā)展和遷移.

我們將繼續(xù)擴(kuò)展我們的實(shí)驗(yàn), 建模不同條件下在TLS 1.3 中使用后量子密碼算法帶來(lái)的影響.同時(shí),我們正在將我們的后量子TLS 1.3 庫(kù)從NIST 第二輪的代碼向NIST 第三輪的代碼進(jìn)行遷移, 并在我們的模擬網(wǎng)絡(luò)架構(gòu)下測(cè)試升級(jí)后各種算法組合的實(shí)際運(yùn)行性能.下一步的工作方向還包括建立高性能后量子算法原型庫(kù), 提供調(diào)用后量子算法的統(tǒng)一API, 簡(jiǎn)化對(duì)NIST 和中國(guó)密碼算法競(jìng)賽后量子算法的使用,這是因?yàn)槲覀儼l(fā)現(xiàn)liboqs 中實(shí)現(xiàn)的后量子算法的性能和單獨(dú)測(cè)試單個(gè)算法的性能經(jīng)常有較大的出入, 會(huì)在一定程度上影響測(cè)量的準(zhǔn)確性.除此之外, 我們也正在逐步開(kāi)展在Nginx Web 服務(wù)器中配置并使用我們修改后的后量子TLS 1.3 庫(kù)的工作, 并嘗試在實(shí)際網(wǎng)絡(luò)中建立后量子安全的TLS 1.3 加密信道.