ACM通信

研究突出了

我把钥匙放在哪里了?: Juniper Dual EC事件的教训

斯蒂芬·切克威，雅各布·马斯基维茨，克里斯蒂娜·加曼，约书亚·弗里德，沙南·科尼，马修·格林，纳迪亚·海宁格，拉尔夫-菲利普·温曼，埃里克·雷斯科拉，霍瓦夫·沙查姆
ACM通信，2018年11月，第61卷第11期，第148-155页
10.1145 / 3266291
评论

2015年12月，瞻博网络(Juniper Networks)宣布，该公司的NetScreen虚拟专用网(VPN)路由器操作系统ScreenOS存在多个安全漏洞，这些漏洞是由未经授权的代码造成的。这些漏洞中更复杂的是被动VPN解密能力，通过更改双椭圆曲线(EC)伪随机数生成器使用的参数之一来启用。

在本文中，我们描述了针对该事件所进行的ScreenOS随机性和VPN密钥建立协议子系统的完全独立分析的结果。虽然Dual EC对于可以选择椭圆曲线参数的攻击者是不安全的，但Juniper曾在2013年声称ScreenOS包含针对这种类型攻击的对策。我们发现，与Juniper的公开声明相反，ScreenOS VPN实现自2008年以来一直容易受到攻击者的被动利用，攻击者选择了Dual EC曲线点。该漏洞的出现是由于Juniper的对策缺陷以及一系列更改，这些更改都是在2008年的一个版本中包含Dual EC时同时引入的。我们通过修改固件来安装我们自己的参数，在一个真实的NetScreen设备上演示了这个漏洞，并且我们展示了可以在不观察任何其他网络流量的情况下被动地解密单独的VPN会话。这个事件是一个重要的例子，说明随机数生成、工程和验证指南在实践中是如何失败的。此外，它对设计美国和其他地方执法机构所设想的那种安全的“例外访问”或“密钥托管”方案的可行性提出了进一步的怀疑。

回到顶部

1.简介

2015年12月，Juniper宣布，一次“内部代码审查”显示，ScreenOS中存在未经授权的代码，可能会让知情的攻击者[…]解密VPN连接。”作为回应，Juniper发布了补丁版本的ScreenOS，这是受影响的NetScreen设备的操作系统，但拒绝透露有关入侵和漏洞的任何进一步信息。

根据Juniper的建议，包括我们团队在内的全球安全研究人员立即开始检查ScreenOS固件，以找到Juniper已经修补的漏洞。他们发现，使ScreenOS加密可被破解的改变，除了替换Juniper伪随机数生成器中的几个嵌入常数外，没有任何作用。这导致攻击者能够解密连接的原因是Juniper的设计决定使用nsa设计的双EC伪随机数生成器(PRNG)。^4，12双EC有一个有问题的特性，即知道其中一个输入参数的离散对数(问)相对于生成器点，并能够观察到来自PRNG的少量连续字节，然后可以计算生成器的内部状态，从而预测所有未来的输出。的离散对数是非常关键的问仍然未知。ScreenOS代码的改变取代了Juniper的选择问攻击者选择了一个。

从一个角度来看，Juniper事件只是一个特别复杂的软件漏洞，这本身就很有趣。然而，更重要的是，它揭示了“例外访问”技术的争议话题，该技术将允许执法官员访问加密数据的明文。任何例外访问系统的一个关键组成部分是限制授权人员访问，最常见的建议方法是用执法部门已知的密钥(或多个密钥)对目标密钥材料进行加密，然后对其进行严格控制。在ScreenOS中使用双EC创建了什么实际上是一个特殊的访问系统问作为公钥和的离散日志问作为私有解密密钥。历史上，对异常访问系统的分析主要集中在控制解密密钥的难度上。在ScreenOS的具体案例中，我们不知道是否有人能够访问相应的密钥，但Juniper事件赤裸裸地说明了另一种风险:攻击者修改系统的例外访问能力，以将授权的公钥替换为自己控制下的公钥，从而将设计用于执法的例外访问系统变成了为攻击者工作的系统。

在本文中，我们试图讲述这一事件的故事，通过追溯近十年来数十次ScreenOS固件修订的司法逆向工程拼凑起来，以及在NetScreen硬件上的实验验证。我们首先提供Dual EC本身的背景，然后研究它在ScreenOS中的使用方式，以及为什么这会导致如此严重的漏洞，然后研究事件本身的历史，最后考虑我们可以从这个故事中汲取什么教训。

回到顶部

2.屏幕中的双EC

密码系统通常包括确定性prng，它将少量的秘密内部状态扩展为一个值流，目的是与真正的随机性难以区分。能够预测PRNG输出的攻击者通常能够破坏依赖于它的任何协议实现，例如，通过能够预测加密密钥(应该保持秘密)或nonces(应该经常保持不可预测)。

对偶电子编码(Dual EC)是由美国国家标准与技术研究所(NIST)标准化的一种基于椭圆曲线运算的密码PRNG。对偶EC有三个公共参数:椭圆曲线和曲线上的两个点称为椭圆曲线P而且Q。ScreenOS使用椭圆曲线P-256并设置P根据NIST特别出版物800-90的规定，为P-256的标准发生器。⁴该标准还规定了问但ScreenOS使用Juniper自己的椭圆曲线点问代替。P-256定义的有限域大约有2个²⁵⁶元素。P-256上的点由256位数对组成(x, y)满足椭圆曲线方程。Dual EC的内部状态是一个256位的数字年代。

让x的函数x椭圆曲线点的-坐标;| |是连接;lsb_n(·)为返回最不显著值的函数n按大端序排列的输入字节数;和msb_n(·)为返回最有效值的函数n字节。从初始状态开始年代₀，一次调用Dual EC实现生成一个32伪随机字节输出一个新的国家年代₂作为

在哪里sP而且平方表示P-256上的标量乘法。

2007年，Shumow和Ferguson证明了这一点¹⁶Dual EC受到了一个知道其价值的对手的状态重建攻击d这样P＝dQ谁能观察到一个单一的输出值。关键是要把这个点乘起来年代₁问通过d生成内部状态x（d·年代₁问) =x（年代₁P) =年代₂．虽然年代₁问本身是不可知的，30之32B之其x协调(即r₁)构成的第30B项输出，攻击者可以猜出剩余的字节;的x椭圆曲线点的-坐标决定了其y-坐标到符号。

假设攻击者知道的离散对数问，主要困难是恢复一个完整的输出值;只知道部分值的攻击者必须穷尽搜索其余的值。的字节数减少时，候选的数量呈指数增长r₁在少于26B的情况下，恢复是难以处理的。在ScreenOS中，Dual EC总是用来一次生成32B的输出，因此攻击是直接的。当30 b的r₁和Juniper的实现一样，攻击者必须考虑2¹⁶候选点。从攻击者的角度来看，这是最佳情况。

重要的是，就公众所知，双重电子商务是安全的，可以抵御知道的攻击者P而且问但不知道d,恢复d将需要计算离散对数的能力，这将打破一般的椭圆曲线密码学。

回到顶部

3.Screenos PRNG子系统

清单1显示了在ScreenOS版本6.2.0r1中实现PRNG的函数的反编译源代码;在6.2和6.3系列的其他版本中也有相同的功能。它由两个prng组成，Dual EC和ANS X9.31(附录A.2.4;Ref。²)．

注意，像函数和变量名这样的标识符没有出现在二进制文件中;我们根据对每个符号的表观功能的分析来分配这些名称。类似地，编译/反编译过程也不会保留特定的控制流构造。例如,为第21行的循环实际上是一个而循环或其他结构在Juniper的源代码。然而，反编译保留了原始代码的功能。为了清晰起见，我们省略了联邦信息处理标准(FIPS)检查，以确保X9.31生成器不会生成重复的输出。

肤浅的解读prng_generate ()函数表明Dual EC仅用于为X9.31 PRNG生成键，并且它是返回给调用者的X9.31的输出输出全球缓冲区)。第2节中描述的Dual EC漏洞需要原始的Dual EC输出，因此不能应用它。事实上，Juniper 2013年的一篇知识库文章⁸就是这个。(我们将在第6节进一步讨论这个知识库文章。)

在这篇阅读中prng_reseed ()函数偶尔被调用以重新播种X9.31 PRNG状态。这个函数调用Dual EC生成器，将其输出定向到32B缓冲区输出。它从这个缓冲区中提取X9.31生成器的种子和密码密钥。通过X9.31的种子，prng_generate ()函数每次生成8B的X9.31输出(第23行)输出，循环直到生成32B的输出(第2126行)。每次调用的x9_31_generate_block更新X9.31种子状态种子缓冲区。

上面给出的直接解读是错误的。

首先，也是最重要的，指数中调用X9.31 PRNG的循环的控制变量prng_generate ()第21行是一个全局变量。的prng_reseed ()函数，如果被调用，则将其设置为32，其结果是，每当PRNG被重新播种时，指数在循环开始时已经大于31，因此不会执行对X9.31 PRNG的调用。^一个

第二，在默认配置中，one_stage_rng ()总是返回false，所以prng_reseed ()总是叫。在默认配置中，X9.31循环为从来没有调用。(有一个没有文档的ScreenOS命令，设置关键one-stage-rng,使one_stage_rng ()总是返回true;运行此命令会导致一个不同的PRNG漏洞，本文的完整版本对此进行了讨论。⁵）

第三,prng_reseed ()碰巧使用了输出在Dual EC将部分输出复制到保存X9.31种子和密钥的其他全局缓冲区之前，将其作为双EC输出的暂存区。这是同一个全局缓冲区prng_generate ()函数应该填充X9.31输出，但失败了。中查找PRNG输出时输出，他们发现的是32B的原始双EC输出。

为了进行比较，清单2显示了在Juniper改进之前，ScreenOS 6.1中PRNG函数的反编译源代码。在ScreenOS 6.1中，循环计数器，指数，是局部变量而不是全局变量;X9.31 PRNG每10,000次调用从系统熵中重新播种，而不是每次调用和从Dual EC中重新播种;PRNG输出被放置在调用者提供的缓冲区中，而不是全局变量中。

此外，ScreenOS 6.1 PRNG子系统一次产生20B，而不是像ScreenOS 6.2和6.3那样一次产生32B。我们将在下一节中讨论这种差异的意义。

回到顶部

4.与艾克

ScreenOS实现IPsec (Internet Protocol Security) VPN协议。为了选择保护VPN会话的密钥，客户端和ScreenOS设备进行IKE (Internet Key Exchange)^7，11握手。

在同一个ScreenOS 6.2版本中，该版本添加了Dual EC(章节2)，并修改了PRNG子系统以暴露原始的Dual EC输出(章节3)，Juniper对IKE实现进行了集群更改，使知道Dual EC秘密的攻击者有可能进行攻击d解密VPN连接。在这些部分的其余部分中，我们将简要描述IKE的相关特性，然后解释这些变化的影响。

4.1.艾克的概述

IKE及其继任者IKEv2是传统的基于diffie - hellman的握手协议引发剂和应答器)建立安全联盟(SA)，由参数和一组用于加密通讯的密钥组成。有些不同寻常的是，IKE由两个阶段组成:

第一阶段建立一个“IKE SA”，它与端点绑定，但不与任何特定类别的非IKE网络流量绑定。在此阶段，双方交换DH (Diffie-Hellman)份额和nonces，并将它们组合成派生密钥。端点可以通过多种方式进行身份验证，包括签名密钥和静态配置的共享密钥。

第二阶段建立安全联盟，保护非ike流量(通常为IPsec)。这个阶段的IKE消息使用第一阶段建立的密钥进行保护。这个阶段可能涉及到DH交换，但也可能只包括nonces交换，在这种情况下，子SA密钥来源于在第一阶段建立的共享秘密。

IKEv2将这些阶段称为“初始交换”和“初始交换”。CREATE_CHILD_SA,”分别;为了简单起见，我们将在本文的其余部分中使用IKEv1阶段1/阶段2术语。

对于以ScreenOS为响应方的IKE攻击，攻击过程如下:(1)使用第一阶段的响应方nonce，计算Dual EC状态;(2)预测响应方的DH私钥，计算IKE SA的DH共享密钥，用于生成第一组密钥;(3)使用这些流量密钥解密第二阶段流量，以恢复发起方和响应方的nonces和公钥;(4)恢复响应者的私钥，要么通过运行Dual EC向前(最好的情况)，要么通过使用新的响应者nonce重复Dual EC攻击;(5)使用应答者的私钥和发起者的公钥计算第二阶段安全联盟的共享秘密，从而计算出流量密匙;(6)使用流量密钥对VPN流量进行解密。

然而，尽管这在原则上是简单的，但仍存在许多实际的复杂性和潜在的实现决策，这些实现决策可能使这种攻击更容易或更困难(甚至不切实际)，如下所述。

4.2.现时标志尺寸

为了使Dual EC状态重构成为可能，攻击者需要的不仅仅是看到原始的Dual EC输出。她至少需要26B的x单椭圆曲线点的-坐标恢复双EC态;更少的字节将不足(第2节)。

对攻击者来说幸运的是，ScreenOS的Dual EC实现返回的32B中的前30B属于x-坐标，正如我们在第二节中看到的。对于攻击者来说，幸运的是，ScreenOS的PRNG子系统在调用时也返回32B，这些是由Dual EC调用返回的32B，如我们在第3节中所见。最后，ScreenOS发出的IKE nonces有32B长，并且是由单个PRNG调用产生的。总结一下:在ScreenOS 6.2和6.3中，IKE nonces总是由一个点的30B组成x-坐标和下一个点的2Bx-协调Shumow-Ferguson重建的最佳情况。

这一点值得详述。IKE标准允许任何nonce长度在8到256B之间(Section 5;Ref。⁷)．Adrian等人在互联网范围内扫描IKE响应器。^3.发现大多数人使用20B nonces。我们不知道长度超过20B的nonces在密码方面有什么优势。ScreenOS 6.1发送了20B nonces，正如我们在第3节中提到的，它的PRNG子系统每次调用都会生成20B。在ScreenOS 6.2中，Juniper引入Dual EC，重写PRNG子系统一次产生32B，修改IKE子系统发送32B nonces。

4.3.Nonces和DH键

攻击者知道d与朱尼珀的观点相对应问并观察ScreenOS设备生成的IKE nonce，可以在nonce生成时重新计算该设备的Dual EC状态。她可以向前滚动该状态以预测后续的PRNG输出，但不能返回以恢复早期的输出。ScreenOS使用它的PRNG生成IKE Diffie-Hellman共享，因此攻击者将能够预测在她看到的瞬间生成的DH私钥，并计算使用这些IKE握手建立的VPN连接的会话密钥。

当攻击者有一个靠近ScreenOS设备的网络接头，并且可以观察到许多IKE握手时，这种场景显然是适用的。但是，如果攻击者的网络点靠近VPN呢客户端而不是?她可能只观察到一个VPN连接。如果一个连接的nonce是在DH共享之后产生的，攻击者将无法恢复该会话的密钥。

对ScreenOS IKE代码的表面解读似乎排除了单连接攻击:包含DH共享的KE有效载荷确实被编码了之前含有nonce的Nr有效载荷。

不过，ScreenOS还包含一个预生成功能，可以维护一个nonce和DH密钥池，用于新的IKE连接，减少握手延迟，这对攻击者来说很方便。池机制相当复杂，它的设计似乎是为了确保总是有足够多的键可用，同时避免在设备上消耗太多的运行时间。

独立的先入先出(FIFO)队列是为nonces、为每个支持的有限域DH组(MODP 768、MODP 1024、MODP 1536和MODP 2048)和(在版本6.3中)为每个支持的椭圆曲线组(ECP 256和ECP 384)维护的。这些队列的大小取决于已为任何给定组启用的VPN配置的数量。例如，如果为一个组启用了单个配置，那么该组的队列大小将为2。nonce队列的大小被设置为所有DH队列的总和的两倍。在启动时，系统将所有队列填满。每秒运行一次的后台任务向未满的队列添加一个条目。如果需要nonce或DH共享，而对应的队列为空，则动态生成一个新值。

队列按优先级顺序填充。关键是，nonce队列被分配了最高的优先级;紧随其后的是按密码强度降序排列的组(ECP 384到MODP 768)。这意味着在许多(但不是所有)情况下，IKE握手的nonce将从Dual EC输出流中提取早些时候这使得单连接攻击成为可能。

图1显示了生成值的序列(有些理想化)，其中的数字表示IKE阶段1交换前后生成队列项的顺序。图1一个启动后的情况:前4个值用于填充nonce队列，后2个值用于生成DH共享。因此，当交换发生时，它使用值1作为nonce，值5作为key，允许攻击者从值1获得Dual EC状态，然后向前计算找到DH共享。阶段1交换完成后，消耗一个DH共享和一个nonce，执行定时补队列任务后，状态如下所示图1 b，新值用阴影表示。

图1。IKE握手过程中的Nonce队列行为。数字表示生成顺序，握手后生成的值用阴影表示。在DH交换过程中，输出1和输出5作为nonce和key推进队列，并生成新的输出填充队列的末端。

根据配置的不同，IKE阶段2交换过程中会同时使用一个nonce和一个DH共享，或者只使用一个nonce。如果交换系统同时使用了一个nonce和一个DH共享，则脱队的nonce会在脱队的DH共享之前生成。该属性将继续为后续的IKE握手保留，前提是握手没有完全耗尽队列。如果重新填充任务没有优先在任何DH组队列之前重新填充nonce队列，单连接攻击就不可能发生。如果nonce队列和DH共享队列的长度相同，IKE阶段2使用nonce但不使用DH共享的配置中就不会出现单连接攻击。

ScreenOS 6.1预生成DH共享，但不生成nonces;我们所描述的nonce队列是在ScreenOS 6.2和Dual EC中添加的。如果没有添加nonce队列，任何握手都不会容易受到单连接解密攻击。

在一个阶段1交换中存在多个非完全的阶段2交换，多个DH组被积极用于连接、队列耗尽或某些竞态条件的情况下，情况就更加复杂，IKE握手阶段有可能在其nonce之前产生其DH共享。单连接解密攻击将失败的握手。详情请参阅本文的完整版本。⁵

4.4.恢复交通的钥匙

如果攻击者能够预测到一次IKE交换中ScreenOS设备的DH共享对应的Diffie-Hellman私钥，就可以计算出该交换的DH共享秘密。有了DH共享密钥的知识，计算用于加密和认证正在建立的VPN会话的会话密钥是很简单的，尽管细节取决于IKE协议版本和端点之间认证的方式;详情请参阅本文全文。⁵

对于通过数字签名验证的IKEv1连接，攻击者知道计算会话密钥所需的一切。对于通过公钥加密验证的IKEv1连接，将对端nonce加密在对方的RSA公钥下，从而阻止攻击。使用预共享密钥进行认证的IKEv1连接介于两者之间:攻击者除了需要知道DH共享密钥外，还需要知道预共享密钥来计算会话密钥。如果预共享密钥是强的，那么连接仍然是安全的。对攻击者来说幸运的是，许多真实的VPN配置使用弱预共享密钥(实际上是密码);在记录了IKE握手并恢复了DH共享密钥的情况下，攻击者就可以对预共享密钥发起离线字典攻击。相比之下，攻击者将能够以相同的方式计算IKEv2连接的会话密钥，而不管它们是如何认证的。

计算出会话密钥后，攻击者就可以解密并读取VPN流量，如果愿意的话，还可以对其进行篡改。

回到顶部

5.实验验证

为了验证我们上面描述的攻击，我们购买了一台Juniper安全服务网关550M VPN设备。我们提出了自己的观点问和相应的对偶EC秘密d。我们修改了固件版本6.3.0r12来放置我们的点问，匹配双EC已知答案测试(KAT)值和(非加密)固件校验和，然后我们在设备上安装了修改后的固件。(我们的设备没有安装代码签名证书，所以我们不需要为修改后的固件创建有效的加密签名。)

使用新的固件，我们为设备配置了三个独立的VPN网关，分别为IKEv1的预共享密钥配置、IKEv1的1024位RSA签名证书配置和IKEv2的预共享密钥配置。我们使用strongSwan VPN软件作为启动器连接到每个网关，并记录到我们设备的流量。我们成功地解密了每个连接，通过恢复双EC状态和流量密钥仅使用该连接的捕获数据包。

回到顶部

6.杜松事件的历史

Juniper事件的历史始于近10年前。^b2008年10月，Juniper发布了ScreenOS 6.2。如上所述，此版本(1)使用自定义的双EC替换了用于(重新)播种ANS X9.31 PRNG的熵收集过程问点;(2)修改了X9.31补种逻辑，改为每一次补种，而不是每一万次补种;(3)改变了循环计数器中的prng_generate过程以及过程的输出为全局变量，与reseed过程共享，从而确保伪随机值是由Dual EC生成的，而不是X9.31;(4)将IKE nonce长度从20B修改为32B;(5)增加了一次预生成队列。

前四个变化的结果是，不管是谁知道这个整数d相应的杜松的问可以被动地解密(一些)VPN流量。前四个更改对本文描述的攻击都至关重要。第五个变化在许多情况下支持单连接攻击，但对于多连接攻击不是必须的。

这种情况持续了四年。在ScreenOS 6.2.0r15(2012年9月)和ScreenOS 6.3.0r12(2012年8月)发布之前的某个时刻，有人修改了Juniper的源代码。基于Juniper后来发布的打了补丁的固件修订版，修改非常小x- Juniper的双EC坐标问改变了对双EC已知答案测试的预期反应。结果，能够被动解密ScreenOS的VPN流量的人从那些知道Juniper的人改变了d(如果有的话)给那些了解新事物的人d对应于变化后的问(可能是进行更改的攻击者)。

显然与2012年的更改无关，第二次源代码修改被做了。在ScreenOS 6.3.0r17(2013年4月)发布之前，一个硬编码的SSH和Telnet密码被插入到Juniper的代码中。使用此密码登录将获得管理员访问权限。

2013年9月初，《纽约时报》发表了一篇基于斯诺登文件的文章，强烈暗示美国国家安全局(NSA)设计了双电子商务系统，使其容易受到攻击。¹⁵这篇文章没有提到Dual EC;相反，它指的是2006年的NIST标准，该标准有一个“致命的弱点，在2007年被两位微软密码专家发现”，大概指的是Dan Shumow和Niels Ferguson在2007年CRYPTO大会上的演讲。¹⁶该报告导致NIST撤回了对双电子商务的建议。¹⁴

在NIST撤回推荐后，Juniper随后发布了一篇知识库文章，解释了他们在ScreenOS中使用Dual EC。

ScreenOS确实使用了Dual_EC_DRBG标准，但被设计成不使用Dual_EC_DRBG作为其主要随机数生成器。ScreenOS以一种不容易受到暴露出来的可能问题影响的方式使用它。它没有使用NIST推荐的曲线点，而是使用自生成的基本点，然后将输出作为FIPS/ANSI X.9.31的输入[原文如此PRNG，它是ScreenOS加密操作中使用的随机数生成器。⁸

第一种缓解方法是使用自生成基点，它只防御本文描述的攻击问是为了让没人知道d；Juniper没有提供任何证据证明这一点。正如我们在第3节中所描述的，Juniper声称Dual EC的输出仅被用作X9.31的输入是不正确的。

2015年12月17日，Juniper发布了一份超出周期的安全公告⁹针对ScreenOS: CVE-2015-7755的两个安全问题^c(“管理访问”)和CVE-2015-7756^d(“VPN解密”)。

这个公告特别有趣，因为它不是通常的开发人员错误报告，而是由未知的攻击者插入到ScreenOS的恶意代码:

在最近的一次内部代码审查中，Juniper发现ScreenOS中未经授权的代码可以允许知识丰富的攻击者获得对NetScreen®设备的管理访问权限，并解密VPN连接。一旦我们发现了这些漏洞，我们就对此事展开了调查，并致力于为最新版本的ScreenOS开发和发布补丁版本。¹⁰

该公告在世界范围内引发了一连串的逆向工程活动，包括我们的团队。“管理访问”问题很快被确定为2013年的源代码修改。摩尔对这个问题进行了广泛的讨论。¹³我们对本文中描述的“VPN解密”问题的分析表明，2012年的代码修改是罪魁祸首。

我们的分析有几点值得注意。首先，2012年的代码修改表明Juniper的2013年知识库文章⁸是不正确的，当它说ScreenOS使用Juniper自己的问因为那个时候，ScreenOS是和攻击者的一起发货的Q。其次，到2015年底，Juniper知道双重EC可以在ScreenOS中被利用。尽管如此，Juniper最初的修复是恢复问指向它们在每个受影响的ScreenOS修订中的初始值。最终，在媒体报道了我们的结果后，Juniper承诺从他们的PRNG子系统中删除Dual EC。

回到顶部

7.例外访问和Nobus

自2014年以来，执法官员一直在警告说，他们正在“走向黑暗”:无处不在的端到端加密使被截获的通信变得不可读，威胁到调查。他们呼吁科技公司重新设计他们的产品，以便在法院下令的情况下解密被截获的通信。计算机科学家一直抵制这种“例外访问”的授权，他们认为，无论何种机制实现这种授权，都将构成一个可能被第三方利用的漏洞。¹

设计不引入漏洞的特殊访问机制的尝试至少可以追溯到1993年，当时美国国家安全局推出了“快船”(Clipper)，这是一种嵌入硬件平台的加密算法，具有内置的“密钥托管”功能，在这种算法中，加密密钥在美国政府已知的密钥下单独加密。这种机制就是“NOBUS”，用美国国家安全局的行话来说，意思是“除了我们谁也没有”(第281页;Ref。⁶):数据将以密码学的方式对没有密匙的人保密，而对有密匙的人则是透明的。

虽然为Clipper设计的密钥托管机制涉及到在托管密钥下加密流量密钥，但也有可能围绕Dual EC这样的系统构建一个例外的访问机制，托管密钥是的离散日志Q。这里的主线是关键只有授权人员才能知道。

无论Juniper选择Dual EC的意图是什么，它的使用实际上创建了一个特殊的访问系统:其中的关键是d的值对应Juniper的选择Q。我们无法知道是否有人知道这件事d价值与否，Juniper没有描述它们是如何产生的Q。然而，在2012年前后，一些组织获得了更改Juniper源代码存储库的能力。他们利用这个权限改变了双EC点问给他们选择的人，实质上是交换了托管密钥。在2012年9月至2015年12月期间，Juniper发布的ScreenOS官方版本包含了入侵者的观点问杜松的相反。到运行受影响版本的NetScreen设备的VPN连接容易被入侵者解密，假设他们知道对应于他们点的dQ。

回到顶部

8.教训

我们研究的ScreenOS漏洞为密码系统的设计提供了重要的更广泛的教训，我们在这里进行总结。

8.1.对于协议设计师

允许nonces的长度变化，特别是大于唯一标识会话所需的长度，这可能是一个坏主意。作者不知道IPsec允许的256B nonces的任何加密原理;它只是邀请实现公开敏感状态，有意或无意。^e

添加低熵共享秘密作为密钥派生输入有助于防止熵失效。我们观察到IKEv1和IKEv2在ScreenOS漏洞可利用性方面的差异，这完全是由于两种协议对预共享密钥的不同使用造成的。不幸的是IKEv2更容易被利用。

8.2.对于实现者和代码审查员

密码学代码必须是本地可审计的:它必须以这样一种方式编写:隔离地检查函数或模块，使读者能够理解其行为。

ScreenOS的实现未能满足这一准则。核心有一个循环计数器prng_generate例程被定义为全局变量，并在子例程中进行更改。这是一个足够令人惊讶的模式，以至于几位有经验的研究人员在威廉·平卡斯做出贡献之前，就知道这个程序可能存在bug，但却没有发现它。的prng_generate而且prng_reseed例程重用相同的32B缓冲区，输出，用于两个完全不同的目的:用于种子X9.31的双EC输出，以及来自PRNG子系统的输出。ScreenOS使用预生成队列使得很难确定是先生成nonces还是DiffieHellman共享。读过独立实现IKE的顶级函数代码的人会得出这样的结论:DiffieHellman共享首先生成，而实际情况通常相反。

Juniper遭受的状态恢复攻击表明，实现可能希望完全避免暴露随机数生成器的原始输出，也许可以在将任何PRNG输出用作nonce之前对其进行散列处理。我们还可以设计实现，使不同的协议组件使用不同的prng，从而将nonce安全性与密钥安全性分开。

上面的几个错误代表了糟糕的软件工程实践。密码代码评审，无论是内部的还是外部的(例如，FIPS验证)，都应该考虑代码质量。

8.3.在NIST

Juniper在设计和验证随机数生成器时遵循当时的最佳实践。他们使用了nist认证的算法，遵循fips推荐的程序，使用测试向量验证输出，并遵循通常推荐的工程指南，使用PRNG作为潜在不安全随机数生成器的白器，至少在理论上删除了使Dual EC脆弱的结构化输出。

在本例中，三种方法都失败了。特别是，在FIPS认证过程中没有发现美白对策的严重缺陷。这暗示了未来在验证密码系统方面的研究工作的潜力。其中一个步骤是跟踪任何缓冲区(特别是共享缓冲区)的起源和使用，并强制执行一个规则，即所有随机数生成器的输出都可以追溯到适当的加密函数，如块密码或散列。某种形式的覆盖分析也可能揭示了美白从来没有执行过。

在FIPS准则要求使用全局状态的程度上，它们与我们上面的建议背道而驰，即加密代码是本地可审计的。

产品由认可的实验室根据FIPS标准进行评估。ScreenOS通过了X9.31 PRNG的FIPS认证，但是评估ScreenOS的实验室没有发现X9.31从未被调用，也没有检测到第3节中描述的Dual EC实现中的缺陷。NIST应该重新审视其实验室认证计划，以确保更彻底的审核，特别是对随机子系统代码的审核。

8.4.对攻击者

攻击者对随机数生成子系统的选择是有指导意义的。长期以来，在理论上，随机数生成器一直被视为盗窃替代攻击的目标，¹⁸但这一事件告诉我们，这种威胁比学术文献中所知的更为真实。

从攻击者的角度来看，到目前为止，ScreenOS PRNG攻击最吸引人的特性是能够显著破坏ScreenOS的安全性没有产生任何外部可检测到的迹象，表明ScreenOS设备是易受攻击的。这与之前众所周知的PRNG故障形成了对比，这些故障都是外部可见的，在Debian的PRNG漏洞中，¹⁷实际上是通过观察试验发现的。实际上，包含攻击者提供的参数的ScreenOS版本似乎产生了与以前版本的输出在密码学上无法区分的输出，因此阻止了任何测试或测量发现问题。

8.5.为记者

关于Juniper泄露的大部分报道都集中在2012年对随机性子系统和2013年对登录代码进行的未经授权的更改上。相比之下，我们对ScreenOS发行版的法医调查强调，在2008年6.2系列中所做的更改是最重要的。

这些改变，引入了Dual EC并改变了其他子系统以这样的方式攻击者知道的离散日志问就我们所知，是Juniper工程师添加的，而不是攻击者。这引发了一些问题:

ScreenOS 6.2系列的新随机性子系统是如何开发出来的?它满足了什么要求?Juniper是如何解决Dual EC的?咨询了哪些组织?Juniper的观点怎么样问生成的吗?

我们无法仅通过访问固件来回答这些问题。Juniper的源代码版本控制系统，他们的bug跟踪系统，他们的内部电子邮件档案，以及Juniper工程师的回忆可能有助于回答这些问题。

尽管有很多机会，包括向他们的首席安全官提出公开问题，以及就这一事件举行国会听证会，^fJuniper要么失败了，要么明确拒绝提供任何进一步的细节。

8.6.为决策者

关于例外访问的很多争论都集中在是否可能构建安全的例外访问机制上，其中“安全”被定义为只允许执法部门进行授权访问。很明显，构建这样一个系统的主要困难之一是解密目标数据所需的任何密钥材料都有泄露的风险。

2012年对ScreenOS的Dual EC常量进行的未经授权的更改说明了一种新的威胁:另一方有能力修改目标软件，为自己的目的颠覆异常访问机制，而只需要极少的可检测到的更改。重要的是，因为PRNG的输出对于任何不知道的离散对数的实体来说都是随机的问，这样的更改对用户和供应商可能做的任何测试都是不可见的。相比之下，如果攻击者想要在一个程序中引入一个特殊的访问机制，而该程序还没有这种机制，那么攻击者通常必须进行一系列极具侵入性的更改，从而增加被发现的风险。

在ScreenOS的案例中，攻击者能够破坏联邦政府使用的一个主要产品，并且多年未被发现。这对有可能建立一种只有适当当局才能使用的特殊存取系统的主张提出了严重挑战;任何关于这样一个系统的新提议都应该承担举证责任，证明它不能像ScreenOS那样被颠覆。

回到顶部

致谢

该材料部分基于美国国家科学基金会资助的工作，奖项EFMA-1441209, CNS-1505799, CNS-1010928, CNS-1408734和CNS-1410031;Mozilla基金会;思科公司的礼物;和海军研究办公室根据合同N00014-14-1-0333。

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.

---

没有发现记录