域名系统 (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 方法对于网络社交和大数据交换领域的改进与影响, 进一步减小互联网隐私泄露风险.
来源: http://network.51cto.com/art/201906/597450.htm