一種dns數(shù)據(jù)包隱私保護方法
【技術領域】
[0001]本發(fā)明屬于網絡技術、信息安全技術領域，具體涉及一種DNS數(shù)據(jù)包隱私保護方法。
【背景技術】
[0002]在互聯(lián)網蓬勃發(fā)展的今天，互聯(lián)網用戶迅猛增加，各種上層應用層出不窮。域名服務系統(tǒng)(Domain Name System，DNS)作為解析互聯(lián)網資源名字及互聯(lián)網資源地址的基礎服務，其重要性愈發(fā)突出。而作為DNS解析入口的根服務體系，其安全穩(wěn)定是整個域名解析業(yè)務正常高效運作的先決條件。
[0003]DNS是一種將域名映射為某些預定義類型資源記錄(如IP地址)的分布式互聯(lián)網服務系統(tǒng)。作為一種互聯(lián)網應用層的資源尋址服務，域名服務是其它互聯(lián)網絡應用服務的基礎，常見的互聯(lián)網絡應用服務(如Web服務、電子郵件服務、FTP服務等)都以域名服務為基礎來實現(xiàn)資源的尋址和定位。
[0004]DNS的原始協(xié)議是一種輕量級協(xié)議，它不能對服務數(shù)據(jù)內容提供安全保證；而且DNS數(shù)據(jù)在互聯(lián)網上以明文方式進行傳輸，數(shù)據(jù)在傳輸過程中很容易遭到劫持或篡改。由于DNS協(xié)議本身不提供數(shù)據(jù)內容的完整性保護機制，因此接收方無法判別接收到的消息是否遭到篡改及來源是否正確；此外，DNS協(xié)議的實現(xiàn)通常以UDP協(xié)議為基礎，缺乏通信的可靠性保證，這進一步加重了消息被篡改或被偽造的可能性。正是由于DNS協(xié)議所暴露出來的以上安全缺陷，促使了 DNSSEC的產生和發(fā)展。
[0005]DNSSEC協(xié)議是一個針對DNS協(xié)議的安全擴展，它通過給DNS的應答消息添加基于非對稱加密算法的數(shù)字簽名，來保證數(shù)據(jù)未經篡改且來源正確；再通過域名體系自下而上逐級向父域提交自己的公共密鑰，來實現(xiàn)整個域名體系的逐級安全認證。具體而言，DNSSEC為DNS數(shù)據(jù)提供了三方面的安全保障:(I)來源驗證:保證DNS應答消息來自被授權的權威服務器；(2)完整性驗證:保證DNS應答消息在傳輸途中未經篡改；(3)否定存在驗證:當用戶請求一個不存在的域名時，DNS服務器也能夠給出包含數(shù)字簽名的否定應答消息，以保證這個否定應答的可靠性。
[0006]DNSSEC本質上是在域名系統(tǒng)樹形授權體系的基礎上，再建立一套基于密碼學手段的簽名/驗證體系，也就是信任鏈體系，通過信任鏈上的逐級安全驗證，來確保DNS查詢結果的真實可靠(數(shù)據(jù)完整性和非否認性)。
[0007]然而，通過互聯(lián)網進行通信的應用程序也面臨信息被偷聽、篡改或偽造的威脅，為應對上述威脅，當前互聯(lián)網數(shù)據(jù)的傳輸一般采用傳輸層安全(Transport Layer Security,TLS)協(xié)議，對信道進行加密，來確保數(shù)據(jù)的完整性、機密性。傳輸層安全協(xié)議使用了數(shù)據(jù)加密與簽名技術，其安全程度的高低取決于其使用的密鑰，若私鑰被泄漏或公鑰被偽造，則所傳輸數(shù)據(jù)的安全性將嚴重削弱甚至完全喪失。
[0008]傳輸層安全協(xié)議利用密鑰算法在互聯(lián)網上提供端點身份認證與通信保密，其基礎是數(shù)字認證機構(Certificat1n Authority, CA)，即通過數(shù)字證書來綁定公鑰與相關信息(包括所有者的名字、CA名稱、公鑰的有效期、CA的數(shù)字簽名等)。數(shù)字認證機構會妥善保管其私鑰，為TLS服務器簽發(fā)數(shù)字證書，并將其公鑰提供給TLS客戶端。TLS客戶端將數(shù)字認證機構的公鑰視為“信任錨點”，并以此來驗證TLS服務器證書的有效性。驗證通過后，TLS服務器與客戶端之間就可以進行安全通信了。
[0009]上述公共CA模式雖應用廣泛，但仍存在不盡如人意的地方，給信息的安全傳輸帶來隱患。如CA模式允許任何CA為TLS服務器簽發(fā)數(shù)字證書，這會使系統(tǒng)變得脆弱，一旦某個CA違背安全承諾，不管是因為主觀原因還是客觀原因(如私鑰發(fā)生泄漏)，必將造成該CA簽發(fā)的所有數(shù)字證書失去安全功能。
[0010]基于DNSSEC協(xié)議，IETF DANE工作組設計了一種新的DNS資源記錄TLSA(TLSA僅是一種資源記錄的名稱，無其它含義)，以使用DNSSEC基礎設施來保存TLS協(xié)議中用到的數(shù)字證書或公鑰。DANE協(xié)議的核心是:依托DNSSEC基礎設施來限制TLS服務器可用的CA范圍，從而使區(qū)操作員可以聲明可供TLS客戶端使用的數(shù)字簽名的范圍。假設客戶端為Charlie，在其訪問example, cn時，可以收到上述TLSA資源記錄，并使用上述內容來驗證其收到的、來自example, cn的TLS數(shù)字證書。若該證書由Bob簽發(fā)，則有效；否則無效。
[0011 ] DANE協(xié)議使用DNSSEC基礎設施來保存TLS協(xié)議中用到的數(shù)字證書或公鑰，這使得DANE協(xié)議繼承了 DNSSEC協(xié)議的各種優(yōu)點。雖然原理與CA模型類似，但它在以下三個方面對傳統(tǒng)的CA模型做了改進:
[0012](I)密鑰是與DNS中的域名相綁定，而不是與任意的標識符相綁定，以便各類互聯(lián)網協(xié)議使用；
[0013](2)簽名后的公鑰可以通過DNS系統(tǒng)來獲取，客戶端只需發(fā)送一個普通的DNS請求就可查詢到所需的公鑰，公鑰的分發(fā)非常簡單；
[0014](3) 一個區(qū)(zone)的密鑰只能由其父區(qū)的密鑰來簽名，例如，區(qū)“example, com”的密鑰只能由區(qū)com”來簽名，而區(qū)com”的密鑰只能由根密鑰來簽名。
[0015]雖然DNSSEC提供了對DNS數(shù)據(jù)進行完成性和來源的驗證，且DANE基于DNSSEC提供了一種互聯(lián)網命名實體的證書管理和驗證機制。但DNS仍然是一種明文傳輸協(xié)議，在客戶端和遞歸服務器及遞歸服務器和權威服務器之間缺乏對傳輸數(shù)據(jù)包的加密保護，以最大限度地保障DNS數(shù)據(jù)的隱私性。

【發(fā)明內容】

[0016]本發(fā)明針對上述問題，提出一種DNS數(shù)據(jù)包隱私保護方法，能夠保證DNS數(shù)據(jù)傳輸?shù)碾[私性。
[0017]本發(fā)明的一種DNS數(shù)據(jù)包隱私保護方法，其步驟包括:
[0018]I)客戶端、遞歸服務器和權威服務器生成并維護各自的非對稱密鑰對；
[0019]2)客戶端在發(fā)起DNS請求時，將其公鑰信息包含在DNS請求數(shù)據(jù)包中；同理，遞歸服務器發(fā)起DNS請求時，將其公鑰信息包含在DNS請求數(shù)據(jù)包中；
[0020]3) DNS請求發(fā)起方將DNS請求數(shù)據(jù)包用對端服務器公鑰進行加密，然后發(fā)給對端服務器；
[0021]4)對端服務器用自己的私鑰解密接收到的包含DNS請求發(fā)起方公鑰信息的DNS請求數(shù)據(jù)包，并對返回的響應數(shù)據(jù)包以DNS請求數(shù)據(jù)包包含的公鑰進行加密，然后發(fā)送給DNS請求發(fā)起方；
[0022]5)DNS請求發(fā)起方用自己的私鑰解密接收到的響應數(shù)據(jù)包，得到最終查詢結果。
[0023]進一步地，所述遞歸服務器在反向區(qū)中維護包含其公鑰信息的TLSA資源記錄，所述權威服務器在正向區(qū)中維護包含其公鑰信息的TLSA資源記錄。
[0024]進一步地，步驟2)對DNS請求數(shù)據(jù)包的包頭格式進行擴展，以在DNS請求數(shù)據(jù)包中攜帶DNS請求發(fā)起方的公鑰信息，所述擴展包括兩個部分:
[0025]a)在保留的字段中增加一個字節(jié)的標志位PP，表明這個DNS請求者希望應答者對數(shù)據(jù)包進行加密，且在Additoanl字段中攜帶請求者公鑰信息；
[0026]b) ARC0UNT置為1，表明在請求數(shù)據(jù)包中包含一個Addit1nal字段，用于存儲請求者公鑰信息。
[0027]進一步地，所述請求者公鑰信息基于EDNSO格式，攜帶在請求消息的Addit1nal字段中，所述Addit1nal字段包括:
[0028]OPT1N-CODE:表明存儲用戶公鑰信息的EDNSO選項編號；
[0029]OPT10N-LENGTH:選項長度；
[0030]TYPE:密鑰生成算法；
[0031 ] KEY-DATA:公鑰數(shù)據(jù)。
[0032]本發(fā)明基于DNS的成熟和標準化協(xié)議，提出了一種DNS擴展協(xié)議，用于加密客戶端與遞歸服務器、遞歸服務器與權威服務器之間交互的DNS數(shù)據(jù)包，能夠保證DNS數(shù)據(jù)傳輸?shù)碾[私性。
【附圖說明】
[0033]圖1是實施例中擴展的DNS包頭示意圖。
[0034]圖2是攜帶請求消息的Addit1nal字段中RDATA格式示意圖。
[0035]圖3是客戶端和遞歸服務器數(shù)據(jù)包加密流程圖。
[0036]圖4是遞歸服務器和權威服務器數(shù)據(jù)包加密流程圖。
【具體實施方式】
[0037]為使本發(fā)明的上述目的、特征和優(yōu)點能夠更加明顯易懂，下面通過具體實施例和附圖，對本發(fā)明做進一步說明。
[0038]本發(fā)明提出的DNS數(shù)據(jù)包隱私保護方法，用于加密客戶端與遞歸服務器、遞歸服務器與權威服務器之間交互的DNS數(shù)據(jù)包，具體改進之處包括:1.提出基于DANE協(xié)議維護DNS服務器(包含遞歸服務器與權威服務器)的公鑰信息；2.客戶端自己生成并維護非對稱密鑰對，在發(fā)起DNS請求時，將其公鑰信息包含在DNS請求數(shù)據(jù)包中；同理，遞歸服務器發(fā)起DNS請求時，將其公鑰信息包含在DNS請求數(shù)據(jù)包中；擴展DNS信令消息，使其包含數(shù)據(jù)包發(fā)起方的公鑰信息；3.DNS請求數(shù)據(jù)包用對端服務器公鑰進行加密；4.接收到包含公鑰信息的DNS請求數(shù)據(jù)包后，服務器首先用自己的私鑰進行解密，并對返回的響應數(shù)據(jù)包以DNS請求數(shù)據(jù)包包含的公鑰進行加密。
[0039]I) DNS服務器公鑰信息維護
[0040]對于遞歸服務器來說，一般只有IP地址信息；但是對于權威服務器來說，一般具有NS資源記錄，標明該服務器的名字。因此，本發(fā)明中所用的DNS服務器公鑰信息維護可能存在兩種情況:在正向區(qū)中(如.cn，.com等)；在反向區(qū)中(如ip6.arpa和in-addr.arpa)。如果服務器有名字，即在正向區(qū)中維護包含其公鑰信息的TLSA資源記錄，如果服務器僅有IP地址，即在反向區(qū)中維護包含其公鑰信息的TLSA資源記錄。
[0041]舉例如下:
[0042]A)遞歸服務器公鑰信息維護
[0043]假設某遞歸服務器的IP地址為1.2.4.8，那么該服務器生成公鑰信息后，在in-addr.arpa區(qū)中維護如下資源記錄:
[0044]_53._udp.8.4.2.1.1n-addr.arpa Lifetime IN TLSA Pub_key-Server
[0045]其中各字段含義如下:
[0046]._53._udp.8.4.2.1.1n-addr.arpa標識這個遞歸服務器的TLSA記錄對應名字，表示地址為1.2.4.8的服務器基于UDP在53端口提供DNS解析服務；
[0047].Lifetime標識這個TLSA記錄的有效時間，服務器應該在該記錄過期之間及時更新資源記錄，本發(fā)明不限定該Lifetime的具體時長。此外，對于服務器采用何種方式進行密鑰輪轉也不予限定；
[0