基于加密傳輸?shù)臉?biāo)識解析模型研究

左 鵬,賀智謀,袁 夢,張海闊,楊衛(wèi)平

(中國互聯(lián)網(wǎng)絡(luò)信息中心,北京 100190)

0 引 言

目前主流的標(biāo)識解析技術(shù)在設(shè)計之初，并未過多考慮安全因素，其產(chǎn)生的數(shù)據(jù)均明文傳輸[1-2]，導(dǎo)致相關(guān)協(xié)議在運(yùn)行過程中存在用戶隱私泄露問題。2013年6月，斯諾登曝光了美國國家安全局的“棱鏡計劃”，披露了美國政府對公眾用戶數(shù)據(jù)的大范圍監(jiān)控行為，引發(fā)舉世震驚[3]。標(biāo)識解析系統(tǒng)作為互聯(lián)網(wǎng)應(yīng)用的入口服務(wù)，其解析過程中產(chǎn)生的數(shù)據(jù)是互聯(lián)網(wǎng)用戶隱私保護(hù)的重要環(huán)節(jié)[4]。

針對域名解析隱私保護(hù)問題，業(yè)界提出了一些基于加密傳輸?shù)臋C(jī)制，如DoH、DoT等，這些技術(shù)標(biāo)準(zhǔn)旨在解決用戶端和DNS遞歸服務(wù)器間數(shù)據(jù)傳送的隱私保護(hù)問題，不能覆蓋遞歸服務(wù)器和權(quán)威服務(wù)器間查詢流程[5-6]。2016年，IETF發(fā)布了谷歌公司提出的RFC7871，允許遞歸服務(wù)器在外發(fā)查詢過程中攜帶用戶的IP地址，以獲取最優(yōu)的DNS應(yīng)答[7]，目前谷歌公司的公共遞歸服務(wù)8.8.8.8已支持該標(biāo)準(zhǔn)。由于該標(biāo)準(zhǔn)將客戶端的IP地址傳遞到了DNS權(quán)威服務(wù)器，因此DNS隱私保護(hù)問題被進(jìn)一步拓展到了遞歸服務(wù)器和權(quán)威服務(wù)器的交互環(huán)節(jié)。

截至目前，沒有成熟的技術(shù)方案支撐域名解析過程中遞歸服務(wù)器和權(quán)威服務(wù)器各節(jié)點(diǎn)間的加密傳輸，導(dǎo)致此過程中的用戶數(shù)據(jù)存在隱私泄露風(fēng)險。為此，本文通過充分調(diào)研國內(nèi)外研究現(xiàn)狀，并借鑒DNSSEC的信任鏈思想，提出一種新的基于加密傳輸?shù)臉?biāo)識解析模型?；谠撃Ｐ停瑥目蛻舳说竭f歸解析器，及遞歸解析器到權(quán)威服務(wù)器的每一步查詢，都通過加密傳輸完成，保障用戶隱私和數(shù)據(jù)的安全。

1 國內(nèi)外研究現(xiàn)狀

1.1 基于加密傳輸?shù)腄NS

針對域名隱私保護(hù)問題，2014年，國際互聯(lián)網(wǎng)工程任務(wù)組(Internet Engineering Task Force， IETF)成立了DNS隱私傳輸交換工作組，發(fā)布了基于TLS和DTLS加密傳輸?shù)腄NS技術(shù)標(biāo)準(zhǔn)[8]。2018年，IETF發(fā)布的RFC8484定義了基于HTTPS傳輸?shù)腄NS。此外，丹尼爾.伯恩斯坦提出了基于橢圓曲線加密算法的DNSCurve[9-10]，使用Curve25519交換會話密鑰，在緩存和服務(wù)器之間提供認(rèn)證和加密。這些標(biāo)準(zhǔn)可以較好地解決客戶端和遞歸服務(wù)器之間DNS隱私和查詢劫持等問題，但都無法覆蓋DNS遞歸服務(wù)器和DNS權(quán)威服務(wù)器之間的解析流程，且缺乏類似DNSSEC的信任傳遞模型，因此不能解決DNS解析全流程的隱私保護(hù)問題。

1.2 基于簽名技術(shù)的DNSSEC

2005年，IETF的DNS運(yùn)維工作組發(fā)布了DNS安全擴(kuò)展方案DNSSEC，其基于數(shù)字簽名技術(shù)實(shí)現(xiàn)遞歸解析器對DNS報文進(jìn)行完整性驗(yàn)證和來源性驗(yàn)證[11-13]，主要解決類似卡明斯基攻擊之類的數(shù)據(jù)篡改問題[14-15]。截至2018年底，超過90%的頂級域名已部署實(shí)施[16]。實(shí)施DNSSEC后，DNS報文仍然通過明文傳輸，因此DNSSEC本身無法解決DNS隱私保護(hù)問題。但其建立了權(quán)威服務(wù)器的信任鏈機(jī)制，實(shí)現(xiàn)了權(quán)威服務(wù)器各節(jié)點(diǎn)的信任傳遞，為實(shí)現(xiàn)全流程加密傳輸?shù)臉?biāo)識模型提供了借鑒思路。

1.3 域名最小化查詢

2016年，IETF發(fā)布RFC7816，提出了查詢域名最小化的DNS查詢方式[17]。普通的DNS查詢中，用戶查詢的域名全名將暴露給查詢過程中經(jīng)過的所有權(quán)威服務(wù)器，容易產(chǎn)生隱私泄露問題。DNS查詢最小化遵循發(fā)送的數(shù)據(jù)越少，隱私問題就越少的原則[18]，僅向較高級的權(quán)威服務(wù)器暴露部分域名，從而提升了DNS查詢過程中的私密性。在查詢域名最小化中，遞歸服務(wù)器和較低級的權(quán)威服務(wù)器依然能獲取到用戶所請求的域名全名，同時遞歸服務(wù)器仍能記錄用戶所有訪問記錄，查詢域名最小化只能提供較為有限的隱私保護(hù)。

1.4 域名廣播技術(shù)

域名廣播技術(shù)由Federrath等人[19]于2011年提出，主要是將近一段時間內(nèi)查詢量比較大的域名廣播到用戶機(jī)器上。遞歸服務(wù)器由于參與到了廣播的過程中，不再直接獲取用戶的訪問記錄，因此可緩解用戶隱私泄露問題。同時，由于熱門域名被緩存在用戶的機(jī)器上，域名廣播技術(shù)能較大程度地提升用戶的訪問速度。域名廣播技術(shù)的問題在于對現(xiàn)有的DNS解析架構(gòu)改動較大，同時需要在用戶的機(jī)器上占用大量空間，部署難度較大。

2 基于加密傳輸?shù)臉?biāo)識解析模型

2.1 模型總體架構(gòu)

本文提出一種新的基于加密傳輸?shù)娜鞒虡?biāo)識解析模型，借鑒DNSSEC的思想，并使用加密連接的身份認(rèn)證機(jī)制實(shí)現(xiàn)權(quán)威節(jié)點(diǎn)的身份認(rèn)證和信任傳遞，實(shí)現(xiàn)遞歸服務(wù)器和權(quán)威服務(wù)器間查詢隱私保護(hù)?？傮w架構(gòu)如圖1所示，分為安全套接層、傳輸層和應(yīng)用層，其核心在于應(yīng)用層實(shí)現(xiàn)基于加密傳輸?shù)男湃捂満凸?jié)點(diǎn)信任傳遞，將在2.2節(jié)詳細(xì)描述。其中，安全套接層采用SSL協(xié)議，為上層提供加密功能。傳輸層作為數(shù)據(jù)傳輸?shù)墓艿?，采用TCP或HTTP等協(xié)議實(shí)現(xiàn)。應(yīng)用層由樁解析器、遞歸解析器和權(quán)威解析器組成，實(shí)現(xiàn)基于加密傳輸?shù)臉?biāo)識解析功能。

圖1 系統(tǒng)總體架構(gòu)

模型的信任鏈部分借鑒了DNSSEC信任鏈的思想，但技術(shù)原理和目標(biāo)問題不同。從技術(shù)原理上講，DNSSEC通過電子簽名實(shí)現(xiàn)信任傳遞。具體地，各節(jié)點(diǎn)掌握一對或多對非對稱密鑰，使用私鑰對各自數(shù)據(jù)簽名，并提供公鑰給遞歸服務(wù)器用于數(shù)據(jù)驗(yàn)證。其中，子節(jié)點(diǎn)將公鑰的摘要提交至父節(jié)點(diǎn)，父節(jié)點(diǎn)對其簽名。遞歸解析器通過驗(yàn)證該公鑰的摘要并與子節(jié)點(diǎn)的公鑰進(jìn)行比對，從而驗(yàn)證子節(jié)點(diǎn)的身份。由此類推，實(shí)現(xiàn)各節(jié)點(diǎn)身份認(rèn)證傳遞。本文模型通過加密連接確保數(shù)據(jù)的隱私性。加密連接建立的過程中，通信雙方首先驗(yàn)證對方的身份，之后通過協(xié)商機(jī)制選擇加密傳輸所使用的密鑰。在上述過程中，通信雙方的身份通過非對稱加密進(jìn)行驗(yàn)證，非對稱加密同時確保了密鑰協(xié)商過程的私密性和可靠性，即使攻擊者對通信進(jìn)行攔截，也無法獲取密鑰協(xié)商期間的具體內(nèi)容或?qū)ζ溥M(jìn)行篡改[20-21]。從目標(biāo)問題上看，DNSSEC主要解決遞歸服務(wù)器解析過程中數(shù)據(jù)被篡改的問題。本文模型主要解決解析全流程的用戶隱私保護(hù)問題。

2.2 信任鏈建立

本文模型信任鏈通過加密連接過程中的身份認(rèn)證和加密傳輸實(shí)現(xiàn)。具體地，遞歸解析器首先與根節(jié)點(diǎn)建立加密連接，在此過程中，遞歸解析器根據(jù)根節(jié)點(diǎn)發(fā)布的證書對其身份進(jìn)行驗(yàn)證。一旦連接建立成功，則根節(jié)點(diǎn)身份認(rèn)證通過，之后遞歸解析器向根節(jié)點(diǎn)查詢一級節(jié)點(diǎn)的證書信息。由于全程加密傳輸，可保證該證書來自于根節(jié)點(diǎn)且無法被篡改。在獲取到一級節(jié)點(diǎn)證書后，遞歸解析器嘗試使用該證書和一級節(jié)點(diǎn)建立加密連接，一旦連接建立成功，則一級節(jié)點(diǎn)身份得到認(rèn)證，并繼續(xù)向一級節(jié)點(diǎn)查詢二級節(jié)點(diǎn)證書信息。由此，通過加密連接的身份認(rèn)證和加密傳輸下級節(jié)點(diǎn)的證書實(shí)現(xiàn)權(quán)威解析器各級節(jié)點(diǎn)的身份認(rèn)證。DNSSEC信任鏈與本文模型信任鏈如圖2所示。

圖2 DNSSEC信任鏈與本文模型信任鏈

對比DNSSEC和本文模型，DNSSEC的優(yōu)勢在于可實(shí)現(xiàn)數(shù)據(jù)來源性驗(yàn)證，即經(jīng)過DNSSEC簽名后的數(shù)據(jù)，傳輸鏈路上無論經(jīng)過何種方式傳輸，鏈路上的任何一方都不需要掌握簽名者的私鑰，最終接收方都可以驗(yàn)證該數(shù)據(jù)來自于簽名者。因此，實(shí)際應(yīng)用中，域名擁有者可以對自有數(shù)據(jù)簽名，再將域名托管至第三方運(yùn)營，方便簽名業(yè)務(wù)和解析托管業(yè)務(wù)分離。但DNSSEC的主要局限在于無法實(shí)現(xiàn)用戶的隱私保護(hù)，由于其使用電子簽名技術(shù)，經(jīng)過DNSSEC簽名后的報文仍然明文傳輸，第三方可以獲取用戶數(shù)據(jù)并窺探用戶隱私。此外，DNSSEC無法覆蓋用戶端和遞歸解析器間的鏈路，存在“最后一公里”問題[22]。本文模型的優(yōu)勢在于實(shí)現(xiàn)了標(biāo)識解析所有流程的加密傳輸，因此可實(shí)現(xiàn)全流程的用戶隱私保護(hù)。此外，由于數(shù)據(jù)加密傳輸，也保障了數(shù)據(jù)無法篡改。但其局限在于無法實(shí)現(xiàn)數(shù)據(jù)來源驗(yàn)證，域名擁有者若需托管域名到第三方，則第三方需要掌握域名擁有者用于加密連接的私鑰。因此，實(shí)際應(yīng)用中，若域名擁有者和域名托管第三方存在信任風(fēng)險，可采用DNSSEC和本模型結(jié)合的方式，同時實(shí)現(xiàn)數(shù)據(jù)來源性驗(yàn)證和用戶隱私保護(hù)。

2.3 系統(tǒng)工作流程

本文模型通過建立信任鏈，實(shí)現(xiàn)標(biāo)識解析過程中全流程加密傳輸。遞歸解析器和根節(jié)點(diǎn)的公鑰通過帶外方式發(fā)布，分別配置到樁解析器和遞歸解析器。假設(shè)遞歸解析器無緩存數(shù)據(jù)，解析數(shù)據(jù)存儲于二級節(jié)點(diǎn)。一次典型的標(biāo)識解析流程如圖3所示。

圖3 系統(tǒng)工作流程

系統(tǒng)工作流程具體描述如下：

1)樁解析器使用遞歸解析器的公鑰與其建立加密連接，并發(fā)送查詢請求。

2)遞歸解析器使用根節(jié)點(diǎn)的公鑰與其建立加密連接，并發(fā)送查詢請求。

3)根節(jié)點(diǎn)返回一級節(jié)點(diǎn)的服務(wù)地址和公鑰給遞歸解析器。

4)遞歸解析器使用一級節(jié)點(diǎn)的公鑰與其建立加密連接，并發(fā)送查詢請求。

5)一級節(jié)點(diǎn)返回二級節(jié)點(diǎn)的服務(wù)地址和公鑰給遞歸解析器。

6)遞歸解析器使用二級節(jié)點(diǎn)的公鑰與其建立加密連接，并發(fā)送查詢請求。

7)二級節(jié)點(diǎn)返回查詢應(yīng)答結(jié)果給遞歸解析器。

8)遞歸解析器返回查詢應(yīng)答結(jié)果給樁解析器。

2.4 與現(xiàn)有安全模型對比分析

目前，域名領(lǐng)域主要的安全模型有基于簽名技術(shù)的DNSSEC以及基于加密技術(shù)的DoT、DoH等。其中DNSSEC通過數(shù)字簽名實(shí)施來源性驗(yàn)證，通過數(shù)字摘要連接父子節(jié)點(diǎn)信任鏈，可保障遞歸解析器和權(quán)威解析器間的數(shù)據(jù)安全。但部署DNSSEC后，數(shù)據(jù)仍然明文傳輸，無法解決隱私保護(hù)問題。DoT等安全模型通過樁解析器和遞歸解析器的加密傳輸解決用戶端和遞歸解析器鏈路上的DNS劫持問題，但無法實(shí)現(xiàn)各權(quán)威節(jié)點(diǎn)的信任傳遞，因此不能覆蓋標(biāo)識解析全流程。本文模型基于加密傳輸技術(shù)，通過加密過程的身份認(rèn)證實(shí)現(xiàn)權(quán)威節(jié)點(diǎn)的信任傳遞，可實(shí)現(xiàn)標(biāo)識解析全流程加密傳輸，保障用戶隱私和數(shù)據(jù)完整性。各模型具體對比如表1所示。

表1 各安全模型技術(shù)對比

3 實(shí)驗(yàn)與分析

3.1 實(shí)驗(yàn)方法

為測試不同加密算法、密鑰長度、傳輸數(shù)據(jù)量等因素對加密傳輸下解析性能的影響及實(shí)際可用性，共設(shè)計了5組實(shí)驗(yàn)?；舅悸窞榛诓煌膫鬏攨f(xié)議和加密方法，在客戶端與服務(wù)端之間建立加密連接，并發(fā)送一定量的數(shù)據(jù)，計算平均解析時延和服務(wù)端CPU使用率并進(jìn)行安全性分析。

實(shí)驗(yàn)基于TLS協(xié)議對RSA和EC這2種加密算法進(jìn)行測試。其中，RSA算法測試的密鑰長度分別為512 bit、1024 bit和2048 bit(以下簡稱RSA512、RSA1024和RSA2048)，EC算法測試的密鑰長度分別為160 bit、256 bit和384 bit(以下簡稱EC160、EC256和EC384)。實(shí)驗(yàn)中密鑰對由JDK中的keytool工具生成，客戶端和服務(wù)端均為Java程序，JDK版本為JDK1.7.0_80。服務(wù)端和客戶端均運(yùn)行在CentOS release 6.5操作系統(tǒng)上。

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

3.2.1 不同加密算法和密鑰長度下解析時延測試(實(shí)驗(yàn)1)

本組實(shí)驗(yàn)基于TLS協(xié)議，使用不同加密算法和密鑰長度，以復(fù)用連接和不復(fù)用連接的方式與服務(wù)端進(jìn)行5000次通信，計算平均時延。不同加密算法和密鑰長度下基于TLS的平均時延如圖4所示。

圖4 不同加密算法和密鑰長度下基于TLS的平均時延

圖4結(jié)果顯示，不復(fù)用連接時，平均時延在11.48 ms～21.55 ms之間，復(fù)用連接時，平均解析時延顯著降低，相較于不復(fù)用連接，下降約98.5%。復(fù)用連接情況下，由于連接初始化過程會產(chǎn)生2次RTT(Round-Trip Time)的時延，因此復(fù)用連接可以明顯降低時延。此外，握手過程中使用指定的非對稱密鑰進(jìn)行密鑰協(xié)商，因此解析時延與算法復(fù)雜度和密鑰長度呈正相關(guān)。復(fù)用連接時，由于連接建立后雙方采用對稱加密進(jìn)行通信，因此握手過程中使用不同的加密算法和密鑰長度對解析時延影響不明顯。

3.2.2 不同響應(yīng)包大小下解析時延測試(實(shí)驗(yàn)2)

本組實(shí)驗(yàn)基于TLS協(xié)議，分別使用100 B、500 B、1 kB、10 kB和70 kB的報文，以復(fù)用連接和不復(fù)用連接的方式進(jìn)行5000次通信，計算平均時延。其中，加密連接使用RSA算法，密鑰長度為1024 bit。不同大小報文基于TLS的平均時延如圖5所示。

圖5 不同大小報文基于TLS的平均時延

與實(shí)驗(yàn)1類似，復(fù)用連接相較于不復(fù)用連接，解析時延顯著降低，平均約下降95.8%。總體上，解析時延與報文大小呈正相關(guān)。當(dāng)報文在10 kB及以下時，報文大小對解析時延影響不明顯，其中復(fù)用連接時，平均時延約為0.3 ms，不復(fù)用連接時平均時延約為10.46 ms。當(dāng)報文增長到70 kB時，解析時延出現(xiàn)明顯增長，相較與10 kB報文，復(fù)用連接情況下時延增加約161%，不復(fù)用連接情況下時延增加約40%。由此可看出，當(dāng)響應(yīng)包在70 kB以內(nèi)時，TLS建立連接消耗的時間遠(yuǎn)大于連接建立后數(shù)據(jù)加密傳輸?shù)臅r間。

3.2.3 加密傳輸下服務(wù)端CPU使用率測試(實(shí)驗(yàn)3)

本組實(shí)驗(yàn)測試了基于TCP協(xié)議和TLS協(xié)議通信時，服務(wù)端CPU使用率的變化情況，測試結(jié)果見圖6，圖中橫坐標(biāo)為采集CPU使用率的時間點(diǎn)，t為連接建立后采集的第一份CPU使用率數(shù)據(jù)。

圖6 TCP和TLS協(xié)議對服務(wù)端CPU的占用率

圖6結(jié)果顯示，無論是否采用加密連接，服務(wù)端的CPU使用率在連接建立時(t時刻)均有顯著增加，其中，TLS加密連接達(dá)到約24%，TCP非加密連接達(dá)到約17%，TLS加密連接相比TCP非加密連接CPU使用率提高約41%。在連接建立后(t時刻后)，TLS傳輸?shù)腃PU平均使用率約為13%，TCP傳輸?shù)腃PU平均使用率約為8%，TLS加密傳輸相比TCP非加密傳輸CPU使用率提高約63%。因此，加密連接傳輸相較于非加密連接傳輸將占用更高的CPU資源，實(shí)際環(huán)境中，若大量加密連接并發(fā)而造成資源不足，可通過拒絕接受新的加密連接或?qū)Σ糠钟脩糁С旨用苓B接的方式以節(jié)省資源，保障解析服務(wù)正常運(yùn)行。

3.2.4 現(xiàn)網(wǎng)環(huán)境下DNS查詢時延和報文大小測試(實(shí)驗(yàn)4)

為分析本文模型在實(shí)際場景下的可用性，本組實(shí)驗(yàn)測試了現(xiàn)網(wǎng)環(huán)境下DNS解析時延及報文大小。其中DNS查詢的解析時延，通過向1.2.4.8、8.8.8.8、114.114.114.114這3個公共遞歸服務(wù)查詢Alexa網(wǎng)站上排名前五的中國網(wǎng)站域名各5000次并計算平均時延得到，DNS報文大小通過向DNS根服務(wù)器、.com和.baidu.com的權(quán)威服務(wù)查詢各自域名的A記錄、NS記錄和DNSKEY記錄得到。

表2 現(xiàn)網(wǎng)環(huán)境DNS遞歸服務(wù)查詢時延 單位:ms

從表2可以看出，目前主流的公共遞歸服務(wù)平均解析時延均在100 ms以內(nèi)。其中，由于測試機(jī)到1.2.4.8的路由跳數(shù)最少，時延最小，為2 ms以內(nèi)。到8.8.8.8的時延最大，約50 ms～90 ms之間。到114.114.114.114的時延在兩者之間，約16 ms。

表3 現(xiàn)網(wǎng)環(huán)境DNS報文大小情況 單位:B

表3結(jié)果顯示，現(xiàn)網(wǎng)環(huán)境大部分DNS報文大小都在1 kB以下。其中，最大的DNS報文是根NS記錄的DNSSEC查詢，非DNSSEC查詢時，常見的A記錄、NS記錄的DNS報文大小一般在200 B以內(nèi)。

結(jié)合前3組實(shí)驗(yàn)情況，并以114.114.114.114解析結(jié)果為例，在解析時延方面，采用TLS復(fù)用連接方式時延約提升1.8%，不復(fù)用連接時延將提升95%。因此，為降低加密傳輸帶來的時延提升，在實(shí)際應(yīng)用中，應(yīng)盡可能復(fù)用已建立的鏈接，降低加密傳輸所帶來的時延和服務(wù)器的處理壓力，RFC1035也建議服務(wù)端在連接空閑2分鐘以上后再將連接關(guān)閉。同時，客戶端應(yīng)該將連接數(shù)量最小化，通過復(fù)用一個活躍的加密連接，在客戶端和服務(wù)端之間進(jìn)行多次通信，以有效降低時延[23]。

在報文大小方面，實(shí)驗(yàn)2結(jié)果顯示，當(dāng)報文在10 kB以下時，解析時延變化不明顯，以TLS為例，復(fù)用連接時，時延增加約0.3 ms。目前現(xiàn)網(wǎng)環(huán)境DNS報文大小大部分小于1 kB，因此該因素對解析時延無顯著影響。

3.2.5 模型安全性分析(實(shí)驗(yàn)5)

本組實(shí)驗(yàn)通過搭建2級權(quán)威節(jié)點(diǎn)解析器(10.192.195.17和10.192.195.21)及遞歸解析器(218.241.111.162)，對模型信任傳遞機(jī)制的安全性進(jìn)行驗(yàn)證和分析。結(jié)果如圖7和圖8所示，從圖中結(jié)果可知，遞歸解析器從初始狀態(tài)開始，通過查詢學(xué)習(xí)到各級權(quán)威節(jié)點(diǎn)的證書信息，實(shí)現(xiàn)信任傳遞，并全程通過加密方式傳送數(shù)據(jù)，保障了數(shù)據(jù)的私密性和完整性。

圖7 根服務(wù)器與下級節(jié)點(diǎn)的信任傳遞過程

圖8 本文模型下加密傳輸?shù)慕馕鼋Y(jié)果

本文模型依賴加密連接過程的身份認(rèn)證來實(shí)現(xiàn)信任傳遞，因此保障證書的安全非常關(guān)鍵。在證書發(fā)布方面，由于遞歸服務(wù)器和根服務(wù)器分別是用戶和遞歸服務(wù)器的查詢起點(diǎn)，因此它們的證書需通過帶外方式發(fā)布。實(shí)際應(yīng)用中，可采用加密傳輸、官方發(fā)布等類似DNS根區(qū)發(fā)布密鑰的方式，保障查詢起點(diǎn)的安全。在證書密鑰方面，由于現(xiàn)代計算機(jī)計算能力不斷增強(qiáng)，為防止密鑰被暴力破解，參考DNSSEC相關(guān)部署經(jīng)驗(yàn)，推薦使用的RSA密鑰長度應(yīng)不低于1024 bit，EC密鑰長度應(yīng)不低于160 bit，同時應(yīng)定期更換密鑰，保障密鑰安全。

4 結(jié)束語

本文提出的基于加密通信的標(biāo)識解析模型，實(shí)現(xiàn)了標(biāo)識系統(tǒng)各節(jié)點(diǎn)在加密方式下的信任傳遞，保障了標(biāo)識解析全流程下用戶隱私，同時由于數(shù)據(jù)加密傳輸，防止了數(shù)據(jù)被篡改，保障了數(shù)據(jù)傳輸安全。與現(xiàn)有的技術(shù)相比，本文模型具有一定的技術(shù)優(yōu)勢，但也存在一定的局限。與DNSSEC不同，本文設(shè)計的模型依賴標(biāo)識解析服務(wù)提供方的信任傳遞，由于缺乏數(shù)字簽名，不能實(shí)現(xiàn)類似DNSSEC的來源性驗(yàn)證。對于實(shí)際應(yīng)用較復(fù)雜的場景，如標(biāo)識擁有方與解析服務(wù)提供商存在信任風(fēng)險時，可采用數(shù)字簽名與本文模型結(jié)合的方式，進(jìn)一步加強(qiáng)數(shù)據(jù)安全的保護(hù)。同時，由于全流程加密傳輸，對于網(wǎng)絡(luò)流量監(jiān)測分析、惡意流量監(jiān)管等也提出了新的挑戰(zhàn)，需要進(jìn)一步研究。