One Key to Sign Them All Considered Vulnerable: Evaluation of DNSSEC in the Internet

Evaluation of DNSSEC in the Internet)

This paper is included in the Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’17).

问题是什么？为什么重要？问题由那些因素导致？
已有工作如何解决？为什么已有工作解决不了
本论文是怎么解决？总体思想是什么？各个模块是怎么设计的？为什么？
实验评估：实验环境？性能指标？效果？
读后感：妙处是什么？哪些不足？
作者背景介绍

摘要

第一次对互联网上DNSSEC-signed 域名进行测量；
收集了2.1M DNSSEC key,其中1.9M是RSA keys
35％使用RSA密钥签名，这些密钥与其他域共享其模数，66％使用太短的密钥（1024bit甚至更小）或模数GCD> 1的密钥与其他域的模数

DNSSEC keys Validation Engine

知识点

DNS欺骗攻击和缓存污染

用户在用域名（www.example.com）访问某一个网站时，用户的计算机一般会通过一个域名解析服务器（Resolver Server，也称递归服务器（Recursive Server））把域名转换成IP地址。解析服务器一般需要通过查询根域名服务器（root）、顶级域名服务器（TLD）、 权威域名服务器（Authoritative Name Server），通过递归查询的方式最终获得目标服务器的IP地址，然后交给用户的计算机。在此过程中，攻击者都可以假冒应答方（根、顶级域、权威域、或解析服务器）给请求方发送一个伪造的响应，其中包含一个错误的IP地址。发送请求的用户计算机或者解析服务器很傻、很天真地接受了伪造的应答，导致用户无法访问正常网站，甚至可以把重定向到一个伪造的网站上去。由于正常的DNS解析使用UDP协议而不是TCP协议，伪造DNS的响应报文比较容易；如果攻击者可以监听上述过程中的任何一个通信链路，这种攻击就易如反掌。

更加糟糕的是，由于DNS缓存（Cache）的作用，这种错误的记录可以存在相当一段时间（比如几个小时甚至几天），所有使用该域名解析服务器的用户都无法访问真正的服务器。攻击者可能是黑客、网络管理者等等（比如利用用户的拼写错误，把对不存在域名NXDOMAIN的访问重定向到一个广告页面）。

DNSSEC

Domain Name System Security Extensions (DNSSEC)DNS安全扩展
DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制
起因： DNS 解析的请求者无法验证它所收到的应答信息的真实性，而DNSSEC给解析服务器提供了防止上当受骗的武器，即一种可以验证应答信息真实性和完整性的机制。利用密码技术，域名解析服务器可以验证它所收到的应答（包括域名不存在的应答）是否来自于真实的服务器，或者是否在传输过程中被篡改过。

DNSSEC依靠数字签名保证DNS应答报文的真实性和完整性。权威域名服务器用自己的私有密钥对资源记录（Resource Record, RR）进行签名，解析服务器用权威服务器的公开密钥对收到的应答信息进行验证。如果验证失败，表明这一报文可能是假冒的，或者在传输过程、缓存过程中被篡改了。

DNSSEC增加了四种类型的资源记录： RRSIG（Resource Record Signature）、DNSKEY(DNS Public Key)、DS(Delegation Signer)、NSEC(Next Secure)。

DNSKEY：资源记录存储的是公开密钥

example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmy…… aNvv4w== )

256:它是一个16比特的数，如果第7位（左起为第0位。这一位是区密钥（Zone Key）标志, 记为ZK）为1，则表明它是一个区密钥，该密钥可以用于签名数据的验证，而且资源记录的所有者（example.com.）必须是区的名字
3:DNSKEY
5:算法（Algorithm）字段，标识签名所使用的算法的种类
最后括号中的是公开密钥（Public Key）字段，它的格式依赖于算法字段

权威域的管理员通常用两个密钥配合完成对区数据的签名。一个是Zone-Signing Key(ZSK)，另一个是Key-Signing Key(KSK)。ZSK用于签名区数据，而KSK用于对ZSK进行签名。这样做的好处有二：

（1）用KSK密钥签名的数据量很少，被破解（即找出对应的私钥）概率很小，因此可以设置很长的生存期。这个密钥的散列值作为DS记录存储在上一级域名服务器中而且需要上级的数字签名，较长的生命周期可以减少密钥更新的工作量。

（2）ZSK签名的数据量比较大，因而破解的概率较大，生存期应该小一些。因为有了KSK的存在，ZSK可以不必放到上一级的域名服务中，更新ZSK不会带来太大的管理开销（不涉及和上级域名服务器打交道）

RRSIG记录

RRSIG资源记录存储的是对资源记录集合（RRSets）的数字签名

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
…
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

类型覆盖（The Type Covered Field）：表示这个签名覆盖什么类型的资源记录，本例中是A；

算法：数字签名算法，同DNSKEY记录的算法字段；本例中5表示RSA/SHA-1。

标签数量（The Labels Field）：被签名的资源域名记录所有者（host.example.com.）中的标签数量，如本例中为3，*.example.com.为2，“.”的标签数量为0。

接下来的几个字段分别是被签名记录的TTL、有效期结束时间、开始时间。

然后（2642）是密钥标签（Key Tag），它是用对应公钥数据简单叠加得到的一个16比特整数。如果一个域有多个密钥时（如一个KSK、一个ZSK），Key Tag可以和后面的签名者字段（example.com.）共同确定究竟使用哪个公钥来验证签名。

DS记录

DS（Delegation Signer）记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链。不过，不像DNSKEY存储在资源记录所有者所在的权威域的区文件中，DS记录存储在上级域名服务器（Delegation）中，比如example.com的DS RR存储在.com的区中。

dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A98631FAD1A292118 )

DS 之后的字段依次是密钥标签（Key Tag）、算法、和散列算法（1代表 SHA-1）。后面括号内的内容是dskey.example.com.密钥SHA-1计算结果的16进制表示。Example.com必须为这个记录数字签名，以证实这个DNSKEY的真实性。

NSEC记录

NSEC记录是为了应答那些不存在的资源记录而设计的。为了保证私有密钥的安全性和服务器的性能，所有的签名记录都是事先（甚至离线）生成的。服务器显然不能为所有不存在的记录事先生成一个公共的“不存在”的签名记录，因为这一记录可以被重放（Replay）；更不可能为每一个不存在的记录生成独立的签名，因为它不知道用户将会请求怎样的记录。

DNSSEC 在线检查工具

• Verisign
• DNSViz

研究背景

针对于DNS攻击：DNS 缓存中毒、DNS劫持
DNSSEC提出
对DNSSEC keys在signed domins 产生的漏洞进行研究

• 在密钥生成期间节省随机性或故障
• 缺乏使用的key的验证系统

一系列针对于如何抵抗dns缓存中毒的技术研究

IETF设计DNSSEC来捡起DNS缓存中毒攻击，但是由于DNSSEC步数需要DNS设施的改变，DNSSEC部署情况十分缓慢。尽管DNSSEC在1997年被提出，但是目前测量显示部署不超过25%；

本文对signed 域名 产生的DNSSEC密钥安全性进行研究；漏洞的研究没有依赖在线DNSSEC检查器

本文工作类似于TLS/SSH key 漏洞测量工作，这项工作指出问题的关键性在于在必要产生的过程中没有充分加密，

贡献

1. 由DNSSEC的测量显示在加密的适用性互联网面临很大挑战，它的设计需要更加仔细并且具有更好的自动性
2. 识别了DNSSEC密钥在产生上的一些漏洞，设计了检测DNSSEC漏洞的框架——DNSSEC keys validation engine，它收集来自不同地方的DNSSEC keys，分析它们的安全性并且生成报告。分析主要关注RSA keys，报告主要包含：密钥共享模块、共享密钥和弱密钥
3. 使用我们的工具在互联网上收集900k signed 域名下的2.1MDNSSEC keys，其中1.9M为RSA keys。
4. 基于发现的问题讨论了最佳的密钥产生实践
5. 在线网页列出漏洞signed domains和DNSSEC keys：www.dnssec.sit.fraunhofer.de/

相似工作

vulnerable cryptigraphy

加密系统的安全性依赖于密钥产生过程。攻击者可以利用随机数产生器无效的随机性进行攻击。

• 2008. Debian OpenSSL产生的“随机数”可被预测
• SSL/TLS：不同的产生故障
• Heninger等人对TLS证书扫描发现由于随机性产生器RNGs的有1%的漏洞关于SSH 主机与其证书
• 我们表明具有随机性的问题并非局限于嵌入式设备，但更重要的是，即使是大型和流行的DNS主机提供商和注册商，也会在多个签名域中引入漏洞。

measurement of DNSSEC

• 测量DNSSEC适用的域signed domains的比重
• signed domains错误配置
• 验证resolvers比重的测量
• Xone enumeration against NSEC3
• 执行大规模DNS测量的挑战
• 本次工作依赖于900K signed domains

背景知识

DNSSEC

DNS response返回的记录可使用户与仿冒的IP地址进行通讯，DNSSEC基于数据的完整性和源验证，对DNS resource 记录进行签名。

• New Resource Records（RRs）:该记录用于存放我们当前域名每一条记录的 DNSSEC 签名
• DNSKEY:该记录用于存放我们用于检查 DNSSEC 签名的公钥
• DS:该记录用于存放 DNSSEC 公钥的散列值
• NSEC:用于验证不存在的资源记录
• Trust Anchor and Chain of Trust
• DNSSEC Cryptographic Building Blocks

参考资料

RSA

公钥：n、e
私钥：n、d
参考资料

• 如果n可以被因数分解，d就可以算出，也就意味着私钥被破解
• 存在一个有效的算法，它接收e和因子p和q，并计算d。若许多参与者共享 $(e_i, N)，公钥(d_i, N)$
• 存在一个算法可以从 $e_i, /fina (N)$ 计算出 $d_i$
• GCD

实验

DNSSEC keys 验证工具

challenges：

1. 支持动态，简单生成新数据源；
2. 每天从数据源执行高效和快速的数据收集；
3. 到期时更新密钥；
4. 允许对密钥域和注册表进行在线验证

数据源

爬取种子

1. 从ICANN中获取root和TLD域文件（1301个不同的TLDs）
2. 扫描Alexa top 1M的域名（依赖Alexa domains 作为SLD）
3. sonar DNS project：每天扫描IPv4地址空间发现DNS resource records

DNSSEC keys 爬取

如何获取所有的DNSSEC-signed 域名？
DKrawler：每天扫描一次

共收集到 900K 个signed domains，共有2.1M DNSKEY records，其中1.9M使用了RSA；

收集瓶颈：发送requests后等待时间；异步爬取DNS 服务器

report：共享模块密钥，共享密钥、弱密钥、DNSSEC适用性

online vulnerable keys

www.dnssec.sit.fraunhofer.de

扫描时间表、种子、DNS 记录值、种子列表、DNS keys、协议、TTL、算法、扫描历史、key长度

评估DNSSEC适用性

主要关注：TLD、Alexa流行域名

87.6% TLD 是signed， 1.6% Alexa