域名系统(DNS)是互联网基础服务,是互联网访问的重要入口,域名隐私保护是 DNS安全的研究热点。本文提出了一种基于用户数据报协议的DNS传输中用户隐私保护的加密方法:DNSDEA。该方法采用PKI加密体系与DNS协议相融合,不仅解决了域名隐私保护问题,而且与传统DNS体系相兼容,保持了DNS系统的简单、高效的技术特点。

域名系统(domain name system,DNS)是互联网的重要基础服务之一,主要通过域名和互联网协议地址(IP)等互联网基础资源之间的映射与转换,实现标识和定位互联网上服务器和服务入口。DNS是一个相对成熟的全球性分布式数据库,为互联网提供高效稳定的互联网标识解析服务。

1983 年,Mockapetris提出 DNS 架构,随后该构架在不断地持续演进和优化。在设计之初,域名系统在域名协议方面并没有考虑完备的安全机制。1999年,DNS安全扩展协议(domain name system security extensions,DNSSEC)被提出,其能够有效降低中间人攻击的风险,保证 DNS传输数据的完整性,从而提升 DNS系统的安全服务能力。2010年,互联网域名的根服务开始部署 DNSSEC服务,标志着域名服务开始向安全服务方向迈进,DNS 也从一个简单的名址转换服务向复杂的、可信的解析服务发展,传输层安全协议DANE(DNS-based authentication of named entities)就是基于 DNSSEC协议将数字证书通过 DNS服务进行发布,以确保证书来自特定的证书颁发机构。

随着互联网普及率的不断提高及其对生产生活的不断渗透,人们已经对互联网产生了越来越强的依赖性,当前的互联网已不仅是获取和分享信息的途径,而且已成为大多数传统行业业务系统的基础载体,因此隐私问题已经成为互联网亟待解决的一个重要问题。DNS 主要采用用户数据报协议(user datagram protocol,UDP)协议明文传输方式进行名址转换,虽然DNSSEC协议提升了数据篡改难度,但是依然采用明文方式提供解析服务。作为互联网基础服务,DNS 对于用户隐私保护依然表现出了脆弱性。目前 DNS 有关安全的命题被真正解决得还较少,而其中的隐私问题也已成为行业关注的焦点问题并逐渐得到重视。一方面,行业内采用查询最小化(query minimization)方法降低隐私窃取风险,使用数据最小化(data minimization)原理减少 DNS权威服务收集个人隐私信息;另一方面,针对 DNS 解析服务过程中隐私泄露的问题,国际组织Internet Engineering Task Force(IETF)于 2014年专门成立 The DNS PRIVate Exchange(DPRIVE)工作组讨论并制定 DNS 隐私保护协议,希望采用数据加密传输的方式实现 DNS隐私保护。基于此背景,本文提出一种基于UDP的DNS传输中用户隐私保护的加密方法。

研究现状

当前,绝大多数 DNS 服务和终端之间的数据交换(主要包含请求和反馈)采用明文、非加密的方式进行,这将导致用户隐私暴露在互联网通信中,其隐私方面的脆弱性将会被黑客所利用,例如黑客可以收集用户的访问痕迹(查询时间、访问内容、用户IP地址等)等信息分析用户习惯等。针对这个问题,目前主要有以下两种方法保护DNS查询过程中的用户隐私。

DNS数据报文加密

Dempsky 提出了 DNSCurve 方法,该方法基于现有 DNS 体系架构,使用Curve25519 在客户端和服务器端交换密钥以及提供认证和数据加密。服务端的公钥存放在“NS”记录中发送给客户端,因此使用 DNSCurve加密DNS报文并不会带来额外查询延迟。DNSCrypt是DNSCurve比较有名的一个实现,已在 OpenDNS的服务上得到广泛部署,用来解决终端用户的隐私保护问题。类似的ConfidentialDNS也使用了 DNS的扩展机制为 DNS协议增加加密功能。它提出一种新的资源记录类型“ENCRYPT”来传送 DNS服务器的公钥到客户端。然后客户端使用服务器公钥加密 DNS 查询请求,以及用来加密 DNS响应的客户端公钥,从而实现对 DNS请求和反馈数据进行加密保护。这两种方案虽然能有效解决 DNS 明文传输所带来的脆弱性问题,但是需要在DNS通信两端都部署安装插件(或升级解析软件)实现DNS通信从明文到密文的目标,推广成本较大,所以目前使用并不广泛。

DNS通信链路加密

TLS(transport layer security)是一种为网络通信提供数据保密以及完整性的安全协议,它在传输层对网络连接进行加密。目前 TLS 最常见的一种应用是HTTPS协议,它使用公钥加密对网站进行认证,同时使用对称加密对数据传输进行加密。TLS需要 TCP协议来保证信道的可靠传输,不能直接用来加密保护 UDP协议的数据,如果 DNS希望使用 TLS加密保护数据,就必须使用 TCP协议。然而现状是绝大部分的 DNS查询使用 UDP协议,切换为 TCP协议是一个长期的过程,并且代价巨大。因此,就现阶段来说,DNS-over-TLS并不是一个可行的隐私保护方案。

DTLS(datagram transport layer security)数据包传输层安全协议是在TLS架构上提出的一种扩展,能够支持 UDP 协议。DTLS 使得直接加密 UDP 协议的 DNS 查询报文变得可行。IETF草案提出的DNS-over-DTLS详细描述了如何使用DTLS技术加密DNS报文。

DNS-over-TLS 和 DNS-over-DTLS 使用互联网标准协议 TLS 和 DTLS 来实现 DNS 密文通信。这两种方法都是采用 TLS 协议进行 DNS 改进,但该方法需要在通信之前需要建立握手、认证等一系列复杂网络通信才能实现,对于访问量巨大、开销相对较小的 DNS服务提出了较高的网络开销和性能要求。

上述两种方法对于延迟敏感、高吞吐量的互联网基础服务DNS来说,都带来了较大挑战。

DNS密文通信方法

提出了一种新的 DNS加密通信方法DNSDEA(DNS data encryption algorithm),该方法在现有 DNS架构和报文格式下采用非对称加密算法的密文方式通信。通过DNS查询传输客户端的公钥,以降低基于TLS等方法建立链接的开销,减低查询延时。同时,利用其无状态特性提高服务端的并发性。

报文结构

1)加密标记位。为标记一个 DNS 报文是否为加密报文,将 DNS 报文头部后的第一个字节定位为加密标记位。对于一个正常的未加密 DNS 报文,该字节表示查询域名第一段的长度,按照互联网协议标准(request for comments,RFC),长度应小于 64。将该字节拓展为加密标记位,若该字节小于 64,表示 DNS报文为非加密报文,若大于64,表示该报文为加密报文。

2)密钥格式。DNSDEA 采用非对称加密方法,在 DNS 终端和DNS 服务端分别独立生成通信密钥对(含公钥和私钥)。DNS 服务端的公钥通过现有的证书颁发架构(certificate authority infrastructure)发布,使用该 DNS 服务端的客户需手动配置该公钥。DNS客户端使用的密钥在查询过冲中临时生成。考虑到查询效率等因素,DNS客户端密钥在一段时间内可重复使用。

客户端的公钥由客户端在DNS 报文的附加段以EDNS0 格式添加,通过 DNS 查询发送给 DNS 服务端。具体格式如图1所示。

图1 EDNS0格式传输PKI公钥密钥

密钥的具体内容存放在上面的选项数据中,其中前两个字节为算法标记位,标识该密钥使用的加密算法,之后两个字节为预留的标识位,最后一部分为具体的公钥数据。具体格式如图2所示。

图2 密钥格式

3)密报文格式。加密的 DNS报文的头部与普通的 DNS报文保持一致,头部后一个字节为加密标记位。标记位后两个字节为加密数据的长度,最后一部分为的加密数据,具体格式如图3所示。

图3 加密后的DNS报文格式

加密查询方法

使用 DNSDEA 方法时,DNS 终端需要手动配置DNS服务端的公钥。服务端的公钥可通过 PKI体系进行验证。在 DNS终端向 DNS服务端发送查询请求时,使用 DNS 服务端的公钥对请求资源记录(RRset)进行加密,将DNS终端的公钥制作成RRset并使用DNS服务端的公钥将其加密,生成 DNS 报文格式数据,传输给DNS服务端。

DNS 终端将按照 DNS 协议要求,将生成的 DNS 查询报文发送给 DNS 服务端,DNS 服务端使用自身私钥进行解密还原待查询的域名记录和 DNS终端的公钥信息,按照 DNS查询逻辑寻找查询结果,使用还原出来的DNS终端公钥对查询结果进行加密,发送给DNS终端。

DNS 终端接收到应答报文后,使用其私钥信息将应答报文的应答资源记录(RRset)进行解密,并按照DNS协议进行处理。

具体流程如图 4所示。以 www.example.com查询为例,实现加密查询方法,主要分以下步骤:(1)服务端通过 PKI发布公钥,客户端手动配置服务端公钥;(2)客户端生成密钥对;(3)客户端构造 www.example.com 的查询包,将客户端的公钥添加在查询包的附加段,并用服务端公钥加密后,将查询包发送给服务端;(4)服务端收到加密的查询包,使用服务端私钥解密,获取 DNS查询内容和客户端公钥;(5)服务端构造 www.example.com的应答包,并用客户端的公钥加密后,将应答包发送给客户端;(6)客户端收到加密的应答包,使用客户端私钥解密,获得www.example.com的应答内容。

图4 加密DNS查询流程

实验及分析

为测试 DNSDEA 的可行性,进行了相关实验,对DNSDEA 和基于 TLS、DTLS 加密方法的 DNS 查询进行对比,以验证DNSDEA 的可行性及相对于目前较流行加密方法的低延迟优势。

实验方法

由于 DNS 查询主要通过 UDP 传输,因此实验主要关注 DNSDEA 和基于 DTLS 加密方法下 DNS 查询包延迟。实验分别测试了两种加密方法使用RSA和ECC算法情况下不同大小数据包的性能表现,通过发起多次DNS查询取平均值,计算各方法下DNS查询时延,比较两种方法在DNS加密使用上的特点。

实验使用openssl-0.9.8 和crypto++5.6.5 加密库实现 RSA和 ECDSA加密,通过编程模拟了两种加密方法下DNS服务端和客户端的软件行为。客户端DNS查询均通过脚本定时循环调用实现,因此基于 DTLS加密的查询每次触发新的 DTLS连接,未使用历史会话。实验运行环境为CentOS 5.7,服务端和客户端分别部署在北京同城的不同节点。

实验结果与分析

1)固定通信字节时延对比。采用10 Bit的通信数据,利用不同强度的密钥进行测试,实验结果如图5所示。

图5 两种DNS加密方法时延比较

从实验结果来看,在密钥长度相等的情况下,基于DTLS 加密的 DNS 查询由于在建立连接的过程中密钥协商耗时较大,DNS 查询整体延时大于 DNSDEA 方法下DNS延时。在RSA加密算法下,加密强度越小,密钥越短,与 DTLS方法比较,DNSDEA性能是 DTLS方法的2.79倍(定义加速比为DTLS方法与DNSDEA时延之比,其比率越高则说明 DNSDEA 时延越低,速度越快);随着RSA密钥长度的增长到2048 Bit时,由于DNSDEA需要将客户端的密钥加密后,通过 DNS 报文传送给服务端,加密耗时明显增长,但总时延仍低于 DTLS 加密方法(图6(a))。

图6 ECDSA算法下两种DNS加密方法加速比

使用 ECDSA 加密算法情况下,密钥长度为 112、160、256 Bit时,DNSDEA对密钥加密的开销小于DTLS密钥协商的通信开销,因此总体网络延时优于 DTLS方法,但随着加密强度增加到521Bit时,DNSDEA对密钥本身加密的开销显著增长,明显大于 DTLS密钥协商的通信开销,造成加密后的 DNS 查询时延急剧增长,在ECDSA 512下,性能低于DTLS方法(图6(b))。

2)固定密钥长度时延对比。使用RSA算法,选取密钥长度为1024位,测试了不同长度的DNS报文在DNSDEA、DTLS方法的时延情况,实验结果如图7所示。

图7 RSA在1024位密钥长度下的时延对比

由于 DTLS在密钥协商成功后,采用对称密钥加密数据,因此随着 DNS报文的加大,基于 DTLS 的 DNS加密方法时延增长不明显,而 DNSDEA 在 DNS 报文较大时,其传输时延明显增长(图8)。

图8 1024位密钥长度下DTLS与DNSDEA的加速比

实验可以看出,在 1024 位密钥加密条件下,采用DNSDEA 传输时延整体明显低于基于 DTLS 的 DNS 加密方法。

综上所述,在密钥长度和传输报文较小时,DNSDEA时延明显低于 DTLS方法;基于 DTLS加密的方法,由于在连接建立后,双方采用对称密钥加密,其耗时的增长幅度要小于 DNSDEA;由于多数 DNS 报文的大小一般都在 200Byte 以内,因此相较于 DTLS 方法,DNSDEA 可以明显降低 DNS 加密传输时延。此外,DNSDEA 基于 DNS传输,其无状态的特性也可以明显提升服务端的并发性。

随着互联网个人隐私问题得到更多人的关注,DNS隐私泄露问题将会越发突出。针对 DNS个人隐私问题的现有技术进行分析,在现有技术解决方法基础上提出了一种新的DNS加密通信方法:DNSDEA。与传统方法相比,该方法在现有 DNS 架构和报文格式下采用非对称加密算法的密文方式通信,不仅完成了 DNS 个人隐私保护,而且提升了域名解析核心算法的并行粒度,降低了 DNS终端与 DNS服务端之间的通信开销,有效保持了DNS低延迟的特性。

针对 RSA、椭圆加密算法(ECC)等加密算法进行了实验,以期为后续通信加密应用研究和 DNS 安全解析并行化研究提供一定参考,并且深入探索 DNSDEA 方法针对 DNSSEC TLSA协议的扩展,提升加密通信安全水平。后续将深入研究 DNSDEA方法对于网络社交和大数据交换领域的改进与影响,进一步减小互联网隐私泄露风险。

参考文献(略)

作者简介

本文作者:张海阔,陆忠华,陈闻宇,陈连栋,左鹏,王珏,徐彦之

作者简介:张海阔,中国科学院计算机网络信息中心,中国科学院大学,中国互联网络信息中心,博士研究生,研究方向为计算机系统结构;陈闻宇(通信作者),中国科学院计算机网络信息中心,中国科学院大学,中国互联网络信息中心,高级工程师,研究方向为计算机系统结构。

注:本文发表于《科技导报》2019 年第8期,有删节。

声明:本文来自科技导报,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。