CN105141612A - 一种dns数据包隐私保护方法 - Google Patents

一种dns数据包隐私保护方法 Download PDF

Info

Publication number
CN105141612A
CN105141612A CN201510552889.9A CN201510552889A CN105141612A CN 105141612 A CN105141612 A CN 105141612A CN 201510552889 A CN201510552889 A CN 201510552889A CN 105141612 A CN105141612 A CN 105141612A
Authority
CN
China
Prior art keywords
server
dns
public key
client
dns request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201510552889.9A
Other languages
English (en)
Inventor
延志伟
耿光刚
李晓东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Internet Network Information Center
Original Assignee
China Internet Network Information Center
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Internet Network Information Center filed Critical China Internet Network Information Center
Priority to CN201510552889.9A priority Critical patent/CN105141612A/zh
Publication of CN105141612A publication Critical patent/CN105141612A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及一种DNS数据包隐私保护方法,其步骤包括:1)客户端、递归服务器和权威服务器生成并维护各自的非对称密钥对;2)客户端或递归服务器在发起DNS请求时,将自己的公钥信息包含在DNS请求数据包中;3)DNS请求发起方将DNS请求数据包用对端服务器公钥进行加密,然后发给对端服务器;4)对端服务器用自己的私钥解密接收到的包含DNS请求发起方公钥信息的DNS请求数据包,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密,然后发送给DNS请求发起方;5)DNS请求发起方用自己的私钥解密接收到的响应数据包,得到最终查询结果。本发明能够保证DNS数据传输的隐私性。

Description

一种DNS数据包隐私保护方法
技术领域
本发明属于网络技术、信息安全技术领域,具体涉及一种DNS数据包隐私保护方法。
背景技术
在互联网蓬勃发展的今天,互联网用户迅猛增加,各种上层应用层出不穷。域名服务***(DomainNameSystem,DNS)作为解析互联网资源名字及互联网资源地址的基础服务,其重要性愈发突出。而作为DNS解析入口的根服务体系,其安全稳定是整个域名解析业务正常高效运作的先决条件。
DNS是一种将域名映射为某些预定义类型资源记录(如IP地址)的分布式互联网服务***。作为一种互联网应用层的资源寻址服务,域名服务是其它互联网络应用服务的基础,常见的互联网络应用服务(如Web服务、电子邮件服务、FTP服务等)都以域名服务为基础来实现资源的寻址和定位。
DNS的原始协议是一种轻量级协议,它不能对服务数据内容提供安全保证;而且DNS数据在互联网上以明文方式进行传输,数据在传输过程中很容易遭到劫持或篡改。由于DNS协议本身不提供数据内容的完整性保护机制,因此接收方无法判别接收到的消息是否遭到篡改及来源是否正确;此外,DNS协议的实现通常以UDP协议为基础,缺乏通信的可靠性保证,这进一步加重了消息被篡改或被伪造的可能性。正是由于DNS协议所暴露出来的以上安全缺陷,促使了DNSSEC的产生和发展。
DNSSEC协议是一个针对DNS协议的安全扩展,它通过给DNS的应答消息添加基于非对称加密算法的数字签名,来保证数据未经篡改且来源正确;再通过域名体系自下而上逐级向父域提交自己的公共密钥,来实现整个域名体系的逐级安全认证。具体而言,DNSSEC为DNS数据提供了三方面的安全保障:(1)来源验证:保证DNS应答消息来自被授权的权威服务器;(2)完整性验证:保证DNS应答消息在传输途中未经篡改;(3)否定存在验证:当用户请求一个不存在的域名时,DNS服务器也能够给出包含数字签名的否定应答消息,以保证这个否定应答的可靠性。
DNSSEC本质上是在域名***树形授权体系的基础上,再建立一套基于密码学手段的签名/验证体系,也就是信任链体系,通过信任链上的逐级安全验证,来确保DNS查询结果的真实可靠(数据完整性和非否认性)。
然而,通过互联网进行通信的应用程序也面临信息被偷听、篡改或伪造的威胁,为应对上述威胁,当前互联网数据的传输一般采用传输层安全(TransportLayerSecurity,TLS)协议,对信道进行加密,来确保数据的完整性、机密性。传输层安全协议使用了数据加密与签名技术,其安全程度的高低取决于其使用的密钥,若私钥被泄漏或公钥被伪造,则所传输数据的安全性将严重削弱甚至完全丧失。
传输层安全协议利用密钥算法在互联网上提供端点身份认证与通信保密,其基础是数字认证机构(CertificationAuthority,CA),即通过数字证书来绑定公钥与相关信息(包括所有者的名字、CA名称、公钥的有效期、CA的数字签名等)。数字认证机构会妥善保管其私钥,为TLS服务器签发数字证书,并将其公钥提供给TLS客户端。TLS客户端将数字认证机构的公钥视为“信任锚点”,并以此来验证TLS服务器证书的有效性。验证通过后,TLS服务器与客户端之间就可以进行安全通信了。
上述公共CA模式虽应用广泛,但仍存在不尽如人意的地方,给信息的安全传输带来隐患。如CA模式允许任何CA为TLS服务器签发数字证书,这会使***变得脆弱,一旦某个CA违背安全承诺,不管是因为主观原因还是客观原因(如私钥发生泄漏),必将造成该CA签发的所有数字证书失去安全功能。
基于DNSSEC协议,IETFDANE工作组设计了一种新的DNS资源记录TLSA(TLSA仅是一种资源记录的名称,无其它含义),以使用DNSSEC基础设施来保存TLS协议中用到的数字证书或公钥。DANE协议的核心是:依托DNSSEC基础设施来限制TLS服务器可用的CA范围,从而使区操作员可以声明可供TLS客户端使用的数字签名的范围。假设客户端为Charlie,在其访问example.cn时,可以收到上述TLSA资源记录,并使用上述内容来验证其收到的、来自example.cn的TLS数字证书。若该证书由Bob签发,则有效;否则无效。
DANE协议使用DNSSEC基础设施来保存TLS协议中用到的数字证书或公钥,这使得DANE协议继承了DNSSEC协议的各种优点。虽然原理与CA模型类似,但它在以下三个方面对传统的CA模型做了改进:
(1)密钥是与DNS中的域名相绑定,而不是与任意的标识符相绑定,以便各类互联网协议使用;
(2)签名后的公钥可以通过DNS***来获取,客户端只需发送一个普通的DNS请求就可查询到所需的公钥,公钥的分发非常简单;
(3)一个区(zone)的密钥只能由其父区的密钥来签名,例如,区“example.com”的密钥只能由区“.com”来签名,而区“.com”的密钥只能由根密钥来签名。
虽然DNSSEC提供了对DNS数据进行完成性和来源的验证,且DANE基于DNSSEC提供了一种互联网命名实体的证书管理和验证机制。但DNS仍然是一种明文传输协议,在客户端和递归服务器及递归服务器和权威服务器之间缺乏对传输数据包的加密保护,以最大限度地保障DNS数据的隐私性。
发明内容
本发明针对上述问题,提出一种DNS数据包隐私保护方法,能够保证DNS数据传输的隐私性。
本发明的一种DNS数据包隐私保护方法,其步骤包括:
1)客户端、递归服务器和权威服务器生成并维护各自的非对称密钥对;
2)客户端在发起DNS请求时,将其公钥信息包含在DNS请求数据包中;同理,递归服务器发起DNS请求时,将其公钥信息包含在DNS请求数据包中;
3)DNS请求发起方将DNS请求数据包用对端服务器公钥进行加密,然后发给对端服务器;
4)对端服务器用自己的私钥解密接收到的包含DNS请求发起方公钥信息的DNS请求数据包,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密,然后发送给DNS请求发起方;
5)DNS请求发起方用自己的私钥解密接收到的响应数据包,得到最终查询结果。
进一步地,所述递归服务器在反向区中维护包含其公钥信息的TLSA资源记录,所述权威服务器在正向区中维护包含其公钥信息的TLSA资源记录。
进一步地,步骤2)对DNS请求数据包的包头格式进行扩展,以在DNS请求数据包中携带DNS请求发起方的公钥信息,所述扩展包括两个部分:
a)在保留的字段中增加一个字节的标志位PP,表明这个DNS请求者希望应答者对数据包进行加密,且在Additoanl字段中携带请求者公钥信息;
b)ARCOUNT置为1,表明在请求数据包中包含一个Additional字段,用于存储请求者公钥信息。
进一步地,所述请求者公钥信息基于EDNS0格式,携带在请求消息的Additional字段中,所述Additional字段包括:
OPTION-CODE:表明存储用户公钥信息的EDNS0选项编号;
OPTION-LENGTH:选项长度;
TYPE:密钥生成算法;
KEY-DATA:公钥数据。
本发明基于DNS的成熟和标准化协议,提出了一种DNS扩展协议,用于加密客户端与递归服务器、递归服务器与权威服务器之间交互的DNS数据包,能够保证DNS数据传输的隐私性。
附图说明
图1是实施例中扩展的DNS包头示意图。
图2是携带请求消息的Additional字段中RDATA格式示意图。
图3是客户端和递归服务器数据包加密流程图。
图4是递归服务器和权威服务器数据包加密流程图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面通过具体实施例和附图,对本发明做进一步说明。
本发明提出的DNS数据包隐私保护方法,用于加密客户端与递归服务器、递归服务器与权威服务器之间交互的DNS数据包,具体改进之处包括:1.提出基于DANE协议维护DNS服务器(包含递归服务器与权威服务器)的公钥信息;2.客户端自己生成并维护非对称密钥对,在发起DNS请求时,将其公钥信息包含在DNS请求数据包中;同理,递归服务器发起DNS请求时,将其公钥信息包含在DNS请求数据包中;扩展DNS信令消息,使其包含数据包发起方的公钥信息;3.DNS请求数据包用对端服务器公钥进行加密;4.接收到包含公钥信息的DNS请求数据包后,服务器首先用自己的私钥进行解密,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密。
1)DNS服务器公钥信息维护
对于递归服务器来说,一般只有IP地址信息;但是对于权威服务器来说,一般具有NS资源记录,标明该服务器的名字。因此,本发明中所用的DNS服务器公钥信息维护可能存在两种情况:在正向区中(如.cn,.com等);在反向区中(如ip6.arpa和in-addr.arpa)。如果服务器有名字,即在正向区中维护包含其公钥信息的TLSA资源记录,如果服务器仅有IP地址,即在反向区中维护包含其公钥信息的TLSA资源记录。
举例如下:
A)递归服务器公钥信息维护
假设某递归服务器的IP地址为1.2.4.8,那么该服务器生成公钥信息后,在in-addr.arpa区中维护如下资源记录:
_53._udp.8.4.2.1.in-addr.arpaLifetimeINTLSAPub_key-Server
其中各字段含义如下:
●_53._udp.8.4.2.1.in-addr.arpa标识这个递归服务器的TLSA记录对应名字,表示地址为1.2.4.8的服务器基于UDP在53端口提供DNS解析服务;
●Lifetime标识这个TLSA记录的有效时间,服务器应该在该记录过期之间及时更新资源记录,本发明不限定该Lifetime的具体时长。此外,对于服务器采用何种方式进行密钥轮转也不予限定;
●IN标识这是一条互联网类型(InternetClass)的资源记录;
●TLSA标识此资源记录类型为TLSA;
●Pub_key-Server标识这个服务器所使用的公钥信息。
递归服务器对应的私钥(Pte_key-Server)保密维护。
B)权威服务器公钥信息维护
假设.cn的权威服务器的NS为ns1.cn,那么该服务器生成公钥信息后,在.cn区中维护如下资源记录:
_53._udp.ns1.cnLifetimeINTLSAPub-key_Server
其中各个字段含义如下:
●_53._udp.ns1.cn标识这个权威服务器的TLSA记录对应名字,表示服务器名字为ns1.cn的服务器基于UDP在53端口提供DNS解析服务;
●Lifetime标识这个TLSA记录的有效时间,服务器应该在该记录过期之间及时更新资源记录,本发明不限定该Lifetime的具体时长。此外,对于服务器采用何种方式进行密钥轮转也不予限定;
●IN标识这是一条互联网类型(InternetClass)的资源记录;
●TLSA标识此资源记录类型为TLSA;
●Pub_key-Server标识这个服务器所使用的公钥信息。
权威服务器对应的私钥(Pte_key-Server)由其对应服务器保密维护。
2)客户端密钥生成
客户端可以基于任何算法(RSA、Elgamal和背包算法等)生成非对称密钥对,其中私钥为Pte_key-Client,公钥为Pub_key-Client。
3)DNS请求数据包扩展
为了传递公钥信息,发起DNS请求一方需要在DNS请求数据包中携带发起方的公钥信息,对DNS数据包的包头格式扩展如图1所示。
本发明对DNS数据包的包头扩展主要包括两个部分:
a)在保留的字段中增加一个字节的标志位(PP,PrivacyProtection),表明这个DNS请求者希望应答者对数据包进行加密,且在Additoanl字段中携带请求者公钥信息;
b)ARCOUNT置为1,表明在请求数据包中包含一个Additional字段,用于存储请求者公钥信息。
本发明所述请求者公钥信息基于EDNS0格式,携带在请求消息的Additional字段中(OPT=41)。Additional字段中RDATA具体格式如图2所示。本发明称该选项为Client-Pub_key,其各部分含义如下:
OPTION-CODE:表明存储用户公钥信息的EDNS0选项编号;
OPTION-LENGTH:选项长度;
TYPE:密钥生成算法;
KEY-DATA:公钥数据。
4)DNS数据隐私保护流程
基于上述扩展协议和数据,本发明提出完整的DNS数据包隐私保护流程。
A)客户端与递归服务器数据加密流程如图3所示。
●客户端首先通过DANE查询所配置的递归服务器的公钥信息(Pub_key-Server-R);
●客户端请求某个域名,在DNS查询消息中设置PP为1,表明请求递归服务器对响应数据包进行加密处理,此外,客户端在请求消息中通过EDNS0携带Client-Pub_key选项,其中包含客户端的公钥信息为Pub_key-Client。客户端用递归服务器的公钥Pub_key-Server-R对这个扩展的DNS请求数据包进行加密,并发送给递归服务器;
●递归服务器使用Pub_key-Server-R对应的私钥进行数据包解密之后,得到客户端请求的域名以及客户端的公钥信息(Pub_key-Client),递归服务器用该公钥信息对响应数据包进行加密;
●客户端只有通过Pub_key-Client对应的私钥才能解密响应数据包,得到最终查询结果。
基于上述流程,DNS请求数据包和DNS响应数据包都进行了加密处理,保障了DNS信令消息的隐私性。
B)递归服务器与权威服务器数据加密流程如图4所示。
●递归服务器先通过DANE查询所请求权威服务器的公钥信息(Pub_key-Server-A);
●递归服务器查询该权威服务器时,在DNS查询消息中设置PP为1,表明请求权威服务器对响应数据包进行加密处理,此外,递归服务器在请求消息中通过EDNS0携带Client-Pub_key选项,其中包含递归服务器的公钥信息为Pub_key-Server-R。递归服务器用权威服务器的公钥Pub_key-Server-A对这个扩展的DNS请求数据包进行加密,并发送给权威服务器;
●权威服务器使用Pub_key-Server-A对应的私钥进行数据包解密之后,得到递归服务器请求的域名以及递归服务器的公钥信息(Pub_key-Server-R),权威服务器用该公钥信息对响应数据包进行加密;
●递归服务器只有通过Pub_key-Server-R对应的私钥才能解密响应数据包,得到最终查询结果。
基于上述流程,DNS请求数据包和DNS响应数据包都进行了加密处理,保障了DNS信令消息的隐私性。
以上实施例仅用以说明本发明的技术方案而非对其进行限制,本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明的精神和范围,本发明的保护范围应以权利要求书所述为准。

Claims (6)

1.一种DNS数据包隐私保护方法,其特征在于,包括如下步骤:
1)客户端、递归服务器和权威服务器生成并维护各自的非对称密钥对;
2)客户端在发起DNS请求时,将其公钥信息包含在DNS请求数据包中;同理,递归服务器发起DNS请求时,将其公钥信息包含在DNS请求数据包中;
3)DNS请求发起方将DNS请求数据包用对端服务器公钥进行加密,然后发给对端服务器;
4)对端服务器用自己的私钥解密接收到的包含DNS请求发起方公钥信息的DNS请求数据包,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密,然后发送给DNS请求发起方;
5)DNS请求发起方用自己的私钥解密接收到的响应数据包,得到最终查询结果。
2.如权利要求1所述的方法,其特征在于:所述递归服务器在反向区中维护包含其公钥信息的TLSA资源记录,所述权威服务器在正向区中维护包含其公钥信息的TLSA资源记录。
3.如权利要求1所述的方法,其特征在于:步骤2)对DNS请求数据包的包头格式进行扩展,以在DNS请求数据包中携带DNS请求发起方的公钥信息,所述扩展包括两个部分:
a)在保留的字段中增加一个字节的标志位PP,表明这个DNS请求者希望应答者对数据包进行加密,且在Additoanl字段中携带请求者公钥信息;
b)ARCOUNT置为1,表明在请求数据包中包含一个Additional字段,用于存储请求者公钥信息。
4.如权利要求3所述的方法,其特征在于:所述请求者公钥信息基于EDNS0格式,携带在请求消息的Additional字段中,所述Additional字段包括:
OPTION-CODE:表明存储用户公钥信息的EDNS0选项编号;
OPTION-LENGTH:选项长度;
TYPE:密钥生成算法;
KEY-DATA:公钥数据。
5.如权利要求3或4所述的方法,其特征在于,客户端与递归服务器的数据加密流程包括:
a)客户端通过DANE查询所配置的递归服务器的公钥信息Pub_key-Server-R;
b)客户端请求某个域名,在DNS查询消息中设置PP为1,表明请求递归服务器对响应数据包进行加密处理,并且客户端在请求消息中通过EDNS0携带客户端的公钥信息Pub_key-Client;客户端用递归服务器的公钥Pub_key-Server-R对这个扩展的DNS请求数据包进行加密,并发送给递归服务器;
c)递归服务器使用Pub_key-Server-R对应的私钥进行数据包解密之后,得到客户端请求的域名以及客户端的公钥信息Pub_key-Client,递归服务器用该公钥信息对响应数据包进行加密;
d)客户端通过Pub_key-Client对应的私钥解密响应数据包,得到最终查询结果。
6.如权利要求3或4所述的方法,其特征在于,递归服务器与权威服务器的数据加密流程包括:
a)递归服务器通过DANE查询所请求权威服务器的公钥信息Pub_key-Server-A;
b)递归服务器查询该权威服务器时,在DNS查询消息中设置PP为1,表明请求权威服务器对响应数据包进行加密处理,并且递归服务器在请求消息中通过EDNS0携带递归服务器的公钥信息Pub_key-Server-R;递归服务器用权威服务器的公钥Pub_key-Server-A对这个扩展的DNS请求数据包进行加密,并发送给权威服务器;
c)权威服务器使用Pub_key-Server-A对应的私钥进行数据包解密之后,得到递归服务器请求的域名以及递归服务器的公钥信息Pub_key-Server-R,权威服务器用该公钥信息对响应数据包进行加密;
d)递归服务器通过Pub_key-Server-R对应的私钥解密响应数据包,得到最终查询结果。
CN201510552889.9A 2015-09-01 2015-09-01 一种dns数据包隐私保护方法 Pending CN105141612A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510552889.9A CN105141612A (zh) 2015-09-01 2015-09-01 一种dns数据包隐私保护方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510552889.9A CN105141612A (zh) 2015-09-01 2015-09-01 一种dns数据包隐私保护方法

Publications (1)

Publication Number Publication Date
CN105141612A true CN105141612A (zh) 2015-12-09

Family

ID=54726820

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510552889.9A Pending CN105141612A (zh) 2015-09-01 2015-09-01 一种dns数据包隐私保护方法

Country Status (1)

Country Link
CN (1) CN105141612A (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108400953A (zh) * 2017-02-06 2018-08-14 中兴通讯股份有限公司 控制终端上网及终端上网的方法,路由器设备及终端
CN108476246A (zh) * 2015-09-25 2018-08-31 微软技术许可有限责任公司 计算机网络中的安全域名解析
CN109413076A (zh) * 2018-11-06 2019-03-01 北京奇虎科技有限公司 域名解析方法及装置
CN110113364A (zh) * 2019-05-29 2019-08-09 深圳市网心科技有限公司 域名劫持防御方法及装置、计算机装置及存储介质
CN111615820A (zh) * 2018-10-15 2020-09-01 华为技术有限公司 通过向grs服务器发送关键值进行域名解析的方法及设备
CN111953678A (zh) * 2020-08-11 2020-11-17 福州职业技术学院 一种验证dns请求安全性的方法及***
CN113014561A (zh) * 2021-02-18 2021-06-22 支付宝(杭州)信息技术有限公司 一种dns请求报文的隐私保护方法及装置
CN113347144A (zh) * 2021-04-14 2021-09-03 西安慧博文定信息技术有限公司 一种互逆加密数据的方法、***、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101242426A (zh) * 2007-02-06 2008-08-13 华为技术有限公司 建立传输层安全连接的方法、***及装置
CN101841521A (zh) * 2010-01-22 2010-09-22 中国科学院计算机网络信息中心 对dns报文中的身份信息进行认证的方法、服务器和***
CN103929435A (zh) * 2014-05-05 2014-07-16 中国科学院计算机网络信息中心 一种基于dnssec及dane协议的可信验证方法
CN104702714A (zh) * 2015-03-31 2015-06-10 北京奇虎科技有限公司 Dns安全查询方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101242426A (zh) * 2007-02-06 2008-08-13 华为技术有限公司 建立传输层安全连接的方法、***及装置
CN101841521A (zh) * 2010-01-22 2010-09-22 中国科学院计算机网络信息中心 对dns报文中的身份信息进行认证的方法、服务器和***
CN103929435A (zh) * 2014-05-05 2014-07-16 中国科学院计算机网络信息中心 一种基于dnssec及dane协议的可信验证方法
CN104702714A (zh) * 2015-03-31 2015-06-10 北京奇虎科技有限公司 Dns安全查询方法和装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
M. DEMPSKY: "DNSCurve: Link-Level Security for the Domain Name System draft-dempsky-dnscurve-01", 《IETF》 *
许海涛等: "DNS 数据安全解决方案", 《计 算 机 系 统 应 用》 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108476246A (zh) * 2015-09-25 2018-08-31 微软技术许可有限责任公司 计算机网络中的安全域名解析
CN108400953A (zh) * 2017-02-06 2018-08-14 中兴通讯股份有限公司 控制终端上网及终端上网的方法,路由器设备及终端
CN111615820B (zh) * 2018-10-15 2022-04-05 华为技术有限公司 通过向grs服务器发送关键值进行域名解析的方法及设备
CN111615820A (zh) * 2018-10-15 2020-09-01 华为技术有限公司 通过向grs服务器发送关键值进行域名解析的方法及设备
CN109413076A (zh) * 2018-11-06 2019-03-01 北京奇虎科技有限公司 域名解析方法及装置
CN109413076B (zh) * 2018-11-06 2022-11-29 北京奇虎科技有限公司 域名解析方法及装置
CN110113364A (zh) * 2019-05-29 2019-08-09 深圳市网心科技有限公司 域名劫持防御方法及装置、计算机装置及存储介质
CN110113364B (zh) * 2019-05-29 2022-02-25 深圳市网心科技有限公司 域名劫持防御方法及装置、计算机装置及存储介质
CN111953678B (zh) * 2020-08-11 2022-04-12 福州职业技术学院 一种验证dns请求安全性的方法及***
CN111953678A (zh) * 2020-08-11 2020-11-17 福州职业技术学院 一种验证dns请求安全性的方法及***
CN113014561A (zh) * 2021-02-18 2021-06-22 支付宝(杭州)信息技术有限公司 一种dns请求报文的隐私保护方法及装置
CN113014561B (zh) * 2021-02-18 2022-09-06 支付宝(杭州)信息技术有限公司 一种dns请求报文的隐私保护方法及装置
CN113347144A (zh) * 2021-04-14 2021-09-03 西安慧博文定信息技术有限公司 一种互逆加密数据的方法、***、设备及存储介质

Similar Documents

Publication Publication Date Title
CN105141612A (zh) 一种dns数据包隐私保护方法
Seth et al. Practical security for disconnected nodes
CN103354498B (zh) 一种基于身份的文件加密传输方法
Tan et al. A secure and authenticated key management protocol (SA-KMP) for vehicular networks
CN105577383A (zh) 密码密钥的管理
CN102355663B (zh) 基于分离机制网络的可信域间快速认证方法
KR20050037244A (ko) 인증서를 이용한 기기 인증 방법 및 상기 방법을 이용하여기기 인증을 수행하는 디지털 컨텐츠 처리 기기
CN112351019B (zh) 一种身份认证***及方法
CN111865988B (zh) 一种基于区块链的无证书密钥管理方法、***及终端
CN104486325A (zh) 一种基于RESTful的安全登陆认证方法
CN111080299B (zh) 一种交易信息的防抵赖方法及客户端、服务器
CN107493165A (zh) 一种具有强匿名性的车联网认证及密钥协商方法
CN101808142A (zh) 通过路由器或交换机实现可信网络连接的方法和装置
CN104468859A (zh) 支持携带服务地址信息的dane扩展查询方法和***
CN103428692A (zh) 可问责且隐私保护的无线接入网络认证方法及其认证***
CN104410635A (zh) 一种基于dane的ndn安全认证方法
CN102340487B (zh) 多信任域之间的完整性报告传递方法和***
KR100984275B1 (ko) 안전하지 않은 통신 채널에서 비인증서 공개키를 사용한 보안키 생성 방법
KR100970552B1 (ko) 비인증서 공개키를 사용하는 보안키 생성 방법
CN108696539B (zh) 一种安全、公平及保护隐私的信息服务代理方法
CN114866244A (zh) 基于密文分组链接加密的可控匿名认证方法、***及装置
CN115189903A (zh) 一种车联网中支持隐私保护的分布式访问控制方法
CN113641985A (zh) 一种分布式可信组织身份访问控制***及方法
KR101042834B1 (ko) 모바일 환경을 위한 자체인증 사인크립션 방법
KR100972743B1 (ko) 마니모의 이동 애드 혹 네트워크에 속한 이동 라우터 간에인증 토큰을 이용한 상호 인증 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20151209

RJ01 Rejection of invention patent application after publication