溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹

發(fā)布時(shí)間:2020-08-10 23:35:03 來源:ITPUB博客 閱讀:186 作者:安全劍客 欄目:網(wǎng)絡(luò)安全
本文提出了一種基于用戶數(shù)據(jù)報(bào)協(xié)議的DNS傳輸中用戶隱私保護(hù)的加密方法:DNSDEA。該方法采用PKI加密體系與DNS協(xié)議相融合,不僅解決了域名隱私保護(hù)問題,而且與傳統(tǒng)DNS體系相兼容,保持了DNS系統(tǒng)的簡單、高效的技術(shù)特點(diǎn)。

域名系統(tǒng)(DNS)是互聯(lián)網(wǎng)基礎(chǔ)服務(wù),是互聯(lián)網(wǎng)訪問的重要入口,域名隱私保護(hù)是 DNS安全的研究熱點(diǎn)。本文提出了一種基于用戶數(shù)據(jù)報(bào)協(xié)議的DNS傳輸中用戶隱私保護(hù)的加密方法:DNSDEA。該方法采用PKI加密體系與DNS協(xié)議相融合,不僅解決了域名隱私保護(hù)問題,而且與傳統(tǒng)DNS體系相兼容,保持了DNS系統(tǒng)的簡單、高效的技術(shù)特點(diǎn)。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹
域名系統(tǒng)(domain name system,DNS)是互聯(lián)網(wǎng)的重要基礎(chǔ)服務(wù)之一,主要通過域名和互聯(lián)網(wǎng)協(xié)議地址(IP)等互聯(lián)網(wǎng)基礎(chǔ)資源之間的映射與轉(zhuǎn)換,實(shí)現(xiàn)標(biāo)識(shí)和定位互聯(lián)網(wǎng)上服務(wù)器和服務(wù)入口。DNS是一個(gè)相對(duì)成熟的全球性分布式數(shù)據(jù)庫,為互聯(lián)網(wǎng)提供高效穩(wěn)定的互聯(lián)網(wǎng)標(biāo)識(shí)解析服務(wù)。

1983 年,Mockapetris提出 DNS 架構(gòu),隨后該構(gòu)架在不斷地持續(xù)演進(jìn)和優(yōu)化。在設(shè)計(jì)之初,域名系統(tǒng)在域名協(xié)議方面并沒有考慮完備的安全機(jī)制。1999年,DNS安全擴(kuò)展協(xié)議(domain name system security extensions,DNSSEC)被提出,其能夠有效降低中間人攻擊的風(fēng)險(xiǎn),保證 DNS傳輸數(shù)據(jù)的完整性,從而提升 DNS系統(tǒng)的安全服務(wù)能力。2010年,互聯(lián)網(wǎng)域名的根服務(wù)開始部署 DNSSEC服務(wù),標(biāo)志著域名服務(wù)開始向安全服務(wù)方向邁進(jìn),DNS 也從一個(gè)簡單的名址轉(zhuǎn)換服務(wù)向復(fù)雜的、可信的解析服務(wù)發(fā)展,傳輸層安全協(xié)議DANE(DNS-based authentication of named entities)就是基于 DNSSEC協(xié)議將數(shù)字證書通過 DNS服務(wù)進(jìn)行發(fā)布,以確保證書來自特定的證書頒發(fā)機(jī)構(gòu)。

隨著互聯(lián)網(wǎng)普及率的不斷提高及其對(duì)生產(chǎn)生活的不斷滲透,人們已經(jīng)對(duì)互聯(lián)網(wǎng)產(chǎn)生了越來越強(qiáng)的依賴性,當(dāng)前的互聯(lián)網(wǎng)已不僅是獲取和分享信息的途徑,而且已成為大多數(shù)傳統(tǒng)行業(yè)業(yè)務(wù)系統(tǒng)的基礎(chǔ)載體,因此隱私問題已經(jīng)成為互聯(lián)網(wǎng)亟待解決的一個(gè)重要問題。DNS 主要采用用戶數(shù)據(jù)報(bào)協(xié)議(user datagram protocol,UDP)協(xié)議明文傳輸方式進(jìn)行名址轉(zhuǎn)換,雖然DNSSEC協(xié)議提升了數(shù)據(jù)篡改難度,但是依然采用明文方式提供解析服務(wù)。作為互聯(lián)網(wǎng)基礎(chǔ)服務(wù),DNS 對(duì)于用戶隱私保護(hù)依然表現(xiàn)出了脆弱性。目前 DNS 有關(guān)安全的命題被真正解決得還較少,而其中的隱私問題也已成為行業(yè)關(guān)注的焦點(diǎn)問題并逐漸得到重視。一方面,行業(yè)內(nèi)采用查詢最小化(query minimization)方法降低隱私竊取風(fēng)險(xiǎn),使用數(shù)據(jù)最小化(data minimization)原理減少 DNS權(quán)威服務(wù)收集個(gè)人隱私信息;另一方面,針對(duì) DNS解析服務(wù)過程中隱私泄露的問題,國際組織Internet Engineering Task Force(IETF)于2014年專門成立 The DNS PRIVate Exchange(DPRIVE)工作組討論并制定 DNS 隱私保護(hù)協(xié)議,希望采用數(shù)據(jù)加密傳輸?shù)姆绞綄?shí)現(xiàn) DNS隱私保護(hù)?;诖吮尘埃疚奶岢鲆环N基于UDP的DNS傳輸中用戶隱私保護(hù)的加密方法。

研究現(xiàn)狀

當(dāng)前,絕大多數(shù) DNS 服務(wù)和終端之間的數(shù)據(jù)交換(主要包含請(qǐng)求和反饋)采用明文、非加密的方式進(jìn)行,這將導(dǎo)致用戶隱私暴露在互聯(lián)網(wǎng)通信中,其隱私方面的脆弱性將會(huì)被黑客所利用,例如黑客可以收集用戶的訪問痕跡(查詢時(shí)間、訪問內(nèi)容、用戶IP地址等)等信息分析用戶習(xí)慣等。針對(duì)這個(gè)問題,目前主要有以下兩種方法保護(hù)DNS查詢過程中的用戶隱私。

DNS數(shù)據(jù)報(bào)文加密

Dempsky 提出了 DNSCurve 方法,該方法基于現(xiàn)有 DNS 體系架構(gòu),使用Curve25519 在客戶端和服務(wù)器端交換密鑰以及提供認(rèn)證和數(shù)據(jù)加密。服務(wù)端的公鑰存放在“NS”記錄中發(fā)送給客戶端,因此使用 DNSCurve加密DNS報(bào)文并不會(huì)帶來額外查詢延遲。DNSCrypt是DNSCurve比較有名的一個(gè)實(shí)現(xiàn),已在 OpenDNS的服務(wù)上得到廣泛部署,用來解決終端用戶的隱私保護(hù)問題。類似的ConfidentialDNS也使用了 DNS的擴(kuò)展機(jī)制為 DNS協(xié)議增加加密功能。它提出一種新的資源記錄類型“ENCRYPT”來傳送 DNS服務(wù)器的公鑰到客戶端。然后客戶端使用服務(wù)器公鑰加密 DNS 查詢請(qǐng)求,以及用來加密 DNS響應(yīng)的客戶端公鑰,從而實(shí)現(xiàn)對(duì) DNS請(qǐng)求和反饋數(shù)據(jù)進(jìn)行加密保護(hù)。這兩種方案雖然能有效解決DNS 明文傳輸所帶來的脆弱性問題,但是需要在DNS通信兩端都部署安裝插件(或升級(jí)解析軟件)實(shí)現(xiàn)DNS通信從明文到密文的目標(biāo),推廣成本較大,所以目前使用并不廣泛。

DNS通信鏈路加密

TLS(transport layer security)是一種為網(wǎng)絡(luò)通信提供數(shù)據(jù)保密以及完整性的安全協(xié)議,它在傳輸層對(duì)網(wǎng)絡(luò)連接進(jìn)行加密。目前 TLS 最常見的一種應(yīng)用是HTTPS協(xié)議,它使用公鑰加密對(duì)網(wǎng)站進(jìn)行認(rèn)證,同時(shí)使用對(duì)稱加密對(duì)數(shù)據(jù)傳輸進(jìn)行加密。TLS需要 TCP協(xié)議來保證信道的可靠傳輸,不能直接用來加密保護(hù) UDP協(xié)議的數(shù)據(jù),如果 DNS希望使用 TLS加密保護(hù)數(shù)據(jù),就必須使用 TCP協(xié)議。然而現(xiàn)狀是絕大部分的 DNS查詢使用 UDP協(xié)議,切換為 TCP協(xié)議是一個(gè)長期的過程,并且代價(jià)巨大。因此,就現(xiàn)階段來說,DNS-over-TLS并不是一個(gè)可行的隱私保護(hù)方案。

DTLS(datagram transport layer security)數(shù)據(jù)包傳輸層安全協(xié)議是在TLS架構(gòu)上提出的一種擴(kuò)展,能夠支持 UDP 協(xié)議。DTLS 使得直接加密 UDP 協(xié)議的 DNS 查詢報(bào)文變得可行。IETF草案提出的DNS-over-DTLS詳細(xì)描述了如何使用DTLS技術(shù)加密DNS報(bào)文。

DNS-over-TLS 和 DNS-over-DTLS 使用互聯(lián)網(wǎng)標(biāo)準(zhǔn)協(xié)議 TLS 和 DTLS 來實(shí)現(xiàn) DNS 密文通信。這兩種方法都是采用 TLS 協(xié)議進(jìn)行 DNS 改進(jìn),但該方法需要在通信之前需要建立握手、認(rèn)證等一系列復(fù)雜網(wǎng)絡(luò)通信才能實(shí)現(xiàn),對(duì)于訪問量巨大、開銷相對(duì)較小的 DNS服務(wù)提出了較高的網(wǎng)絡(luò)開銷和性能要求。

上述兩種方法對(duì)于延遲敏感、高吞吐量的互聯(lián)網(wǎng)基礎(chǔ)服務(wù)DNS來說,都帶來了較大挑戰(zhàn)。

DNS密文通信方法

提出了一種新的 DNS加密通信方法DNSDEA(DNS data encryption algorithm),該方法在現(xiàn)有 DNS架構(gòu)和報(bào)文格式下采用非對(duì)稱加密算法的密文方式通信。通過DNS查詢傳輸客戶端的公鑰,以降低基于TLS等方法建立鏈接的開銷,減低查詢延時(shí)。同時(shí),利用其無狀態(tài)特性提高服務(wù)端的并發(fā)性。

報(bào)文結(jié)構(gòu)

1)加密標(biāo)記位。為標(biāo)記一個(gè) DNS 報(bào)文是否為加密報(bào)文,將 DNS 報(bào)文頭部后的第一個(gè)字節(jié)定位為加密標(biāo)記位。對(duì)于一個(gè)正常的未加密 DNS 報(bào)文,該字節(jié)表示查詢域名第一段的長度,按照互聯(lián)網(wǎng)協(xié)議標(biāo)準(zhǔn)(request for comments,RFC),長度應(yīng)小于 64。將該字節(jié)拓展為加密標(biāo)記位,若該字節(jié)小于 64,表示 DNS報(bào)文為非加密報(bào)文,若大于64,表示該報(bào)文為加密報(bào)文。

2)密鑰格式。DNSDEA 采用非對(duì)稱加密方法,在 DNS 終端和DNS 服務(wù)端分別獨(dú)立生成通信密鑰對(duì)(含公鑰和私鑰)。DNS 服務(wù)端的公鑰通過現(xiàn)有的證書頒發(fā)架構(gòu)(certificate authority infrastructure)發(fā)布,使用該 DNS 服務(wù)端的客戶需手動(dòng)配置該公鑰。DNS客戶端使用的密鑰在查詢過沖中臨時(shí)生成??紤]到查詢效率等因素,DNS客戶端密鑰在一段時(shí)間內(nèi)可重復(fù)使用。

客戶端的公鑰由客戶端在DNS 報(bào)文的附加段以EDNS0 格式添加,通過 DNS 查詢發(fā)送給 DNS 服務(wù)端。具體格式如圖1所示。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹
密鑰的具體內(nèi)容存放在上面的選項(xiàng)數(shù)據(jù)中,其中前兩個(gè)字節(jié)為算法標(biāo)記位,標(biāo)識(shí)該密鑰使用的加密算法,之后兩個(gè)字節(jié)為預(yù)留的標(biāo)識(shí)位,最后一部分為具體的公鑰數(shù)據(jù)。具體格式如圖2所示。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹
3)密報(bào)文格式。加密的 DNS報(bào)文的頭部與普通的 DNS報(bào)文保持一致,頭部后一個(gè)字節(jié)為加密標(biāo)記位。標(biāo)記位后兩個(gè)字節(jié)為加密數(shù)據(jù)的長度,最后一部分為的加密數(shù)據(jù),具體格式如圖3所示。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹

加密查詢方法

使用 DNSDEA 方法時(shí),DNS 終端需要手動(dòng)配置DNS服務(wù)端的公鑰。服務(wù)端的公鑰可通過 PKI體系進(jìn)行驗(yàn)證。在 DNS終端向 DNS服務(wù)端發(fā)送查詢請(qǐng)求時(shí),使用 DNS 服務(wù)端的公鑰對(duì)請(qǐng)求資源記錄(RRset)進(jìn)行加密,將DNS終端的公鑰制作成RRset并使用DNS服務(wù)端的公鑰將其加密,生成 DNS 報(bào)文格式數(shù)據(jù),傳輸給DNS服務(wù)端。

DNS 終端將按照 DNS 協(xié)議要求,將生成的 DNS 查詢報(bào)文發(fā)送給 DNS 服務(wù)端,DNS服務(wù)端使用自身私鑰進(jìn)行解密還原待查詢的域名記錄和 DNS終端的公鑰信息,按照 DNS查詢邏輯尋找查詢結(jié)果,使用還原出來的DNS終端公鑰對(duì)查詢結(jié)果進(jìn)行加密,發(fā)送給DNS終端。

DNS 終端接收到應(yīng)答報(bào)文后,使用其私鑰信息將應(yīng)答報(bào)文的應(yīng)答資源記錄(RRset)進(jìn)行解密,并按照DNS協(xié)議進(jìn)行處理。

具體流程如圖 4所示。以 www.example.com查詢?yōu)槔?,?shí)現(xiàn)加密查詢方法,主要分以下步驟:(1)服務(wù)端通過 PKI發(fā)布公鑰,客戶端手動(dòng)配置服務(wù)端公鑰;(2)客戶端生成密鑰對(duì);(3)客戶端構(gòu)造 www.example.com 的查詢包,將客戶端的公鑰添加在查詢包的附加段,并用服務(wù)端公鑰加密后,將查詢包發(fā)送給服務(wù)端;(4)服務(wù)端收到加密的查詢包,使用服務(wù)端私鑰解密,獲取 DNS查詢內(nèi)容和客戶端公鑰;(5)服務(wù)端構(gòu)造www.example.com的應(yīng)答包,并用客戶端的公鑰加密后,將應(yīng)答包發(fā)送給客戶端;(6)客戶端收到加密的應(yīng)答包,使用客戶端私鑰解密,獲得www.example.com的應(yīng)答內(nèi)容。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹

實(shí)驗(yàn)及分析

為測(cè)試 DNSDEA 的可行性,進(jìn)行了相關(guān)實(shí)驗(yàn),對(duì)DNSDEA 和基于 TLS、DTLS 加密方法的 DNS 查詢進(jìn)行對(duì)比,以驗(yàn)證DNSDEA 的可行性及相對(duì)于目前較流行加密方法的低延遲優(yōu)勢(shì)。

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

由于 DNS 查詢主要通過 UDP 傳輸,因此實(shí)驗(yàn)主要關(guān)注 DNSDEA 和基于 DTLS 加密方法下 DNS 查詢包延遲。實(shí)驗(yàn)分別測(cè)試了兩種加密方法使用RSA和ECC算法情況下不同大小數(shù)據(jù)包的性能表現(xiàn),通過發(fā)起多次DNS查詢?nèi)∑骄?,?jì)算各方法下DNS查詢時(shí)延,比較兩種方法在DNS加密使用上的特點(diǎn)。

實(shí)驗(yàn)使用openssl-0.9.8 和crypto++5.6.5 加密庫實(shí)現(xiàn) RSA和 ECDSA加密,通過編程模擬了兩種加密方法下DNS服務(wù)端和客戶端的軟件行為??蛻舳薉NS查詢均通過 腳本 定時(shí)循環(huán)調(diào)用實(shí)現(xiàn),因此基于 DTLS加密的查詢每次觸發(fā)新的 DTLS連接,未使用歷史會(huì)話。實(shí)驗(yàn)運(yùn)行環(huán)境為 CentOS  5.7,服務(wù)端和客戶端分別部署在北京同城的不同節(jié)點(diǎn)。

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

1)固定通信字節(jié)時(shí)延對(duì)比。采用10 Bit的通信數(shù)據(jù),利用不同強(qiáng)度的密鑰進(jìn)行測(cè)試,實(shí)驗(yàn)結(jié)果如圖5所示。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹
從實(shí)驗(yàn)結(jié)果來看,在密鑰長度相等的情況下,基于DTLS 加密的 DNS 查詢由于在建立連接的過程中密鑰協(xié)商耗時(shí)較大,DNS 查詢整體延時(shí)大于 DNSDEA 方法下DNS延時(shí)。在RSA加密算法下,加密強(qiáng)度越小,密鑰越短,與 DTLS方法比較,DNSDEA性能是 DTLS方法的2.79倍(定義加速比為DTLS方法與DNSDEA時(shí)延之比,其比率越高則說明 DNSDEA 時(shí)延越低,速度越快);隨著RSA密鑰長度的增長到2048 Bit時(shí),由于DNSDEA需要將客戶端的密鑰加密后,通過 DNS 報(bào)文傳送給服務(wù)端,加密耗時(shí)明顯增長,但總時(shí)延仍低于 DTLS 加密方法。
使用 ECDSA 加密算法情況下,密鑰長度為 112、160、256 Bit時(shí),DNSDEA對(duì)密鑰加密的開銷小于DTLS密鑰協(xié)商的通信開銷,因此總體網(wǎng)絡(luò)延時(shí)優(yōu)于 DTLS方法,但隨著加密強(qiáng)度增加到521Bit時(shí),DNSDEA對(duì)密鑰本身加密的開銷顯著增長,明顯大于 DTLS密鑰協(xié)商的通信開銷,造成加密后的 DNS 查詢時(shí)延急劇增長,在ECDSA 512下,性能低于DTLS方法。
2)固定密鑰長度時(shí)延對(duì)比。使用RSA算法,選取密鑰長度為1024位,測(cè)試了不同長度的DNS報(bào)文在DNSDEA、DTLS方法的時(shí)延情況,實(shí)驗(yàn)結(jié)果如圖7所示。
基于隱私保護(hù)技術(shù)的DNS通信協(xié)議介紹
由于 DTLS在密鑰協(xié)商成功后,采用對(duì)稱密鑰加密數(shù)據(jù),因此隨著 DNS報(bào)文的加大,基于 DTLS 的 DNS加密方法時(shí)延增長不明顯,而 DNSDEA 在 DNS 報(bào)文較大時(shí),其傳輸時(shí)延明顯增長。
實(shí)驗(yàn)可以看出,在 1024 位密鑰加密條件下,采用DNSDEA 傳輸時(shí)延整體明顯低于基于DTLS 的 DNS 加密方法。

綜上所述,在密鑰長度和傳輸報(bào)文較小時(shí),DNSDEA時(shí)延明顯低于 DTLS方法;基于DTLS加密的方法,由于在連接建立后,雙方采用對(duì)稱密鑰加密,其耗時(shí)的增長幅度要小于DNSDEA;由于多數(shù) DNS 報(bào)文的大小一般都在 200Byte 以內(nèi),因此相較于 DTLS 方法,DNSDEA 可以明顯降低 DNS 加密傳輸時(shí)延。此外,DNSDEA 基于 DNS傳輸,其無狀態(tài)的特性也可以明顯提升服務(wù)端的并發(fā)性。

隨著互聯(lián)網(wǎng)個(gè)人隱私問題得到更多人的關(guān)注,DNS隱私泄露問題將會(huì)越發(fā)突出。針對(duì)DNS個(gè)人隱私問題的現(xiàn)有技術(shù)進(jìn)行分析,在現(xiàn)有技術(shù)解決方法基礎(chǔ)上提出了一種新的DNS加密通信方法:DNSDEA。與傳統(tǒng)方法相比,該方法在現(xiàn)有 DNS 架構(gòu)和報(bào)文格式下采用非對(duì)稱加密算法的密文方式通信,不僅完成了 DNS 個(gè)人隱私保護(hù),而且提升了域名解析核心算法的并行粒度,降低了 DNS終端與 DNS服務(wù)端之間的通信開銷,有效保持了DNS低延遲的特性。

針對(duì) RSA、橢圓加密算法(ECC)等加密算法進(jìn)行了實(shí)驗(yàn),以期為后續(xù)通信加密應(yīng)用研究和 DNS 安全解析并行化研究提供一定參考,并且深入探索 DNSDEA 方法針對(duì) DNSSEC TLSA協(xié)議的擴(kuò)展,提升加密通信安全水平。后續(xù)將深入研究 DNSDEA方法對(duì)于網(wǎng)絡(luò)社交和大數(shù)據(jù)交換領(lǐng)域的改進(jìn)與影響,進(jìn)一步減小互聯(lián)網(wǎng)隱私泄露風(fēng)險(xiǎn)。


向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI