2015年12月15日著名的网络设备厂商Juniper公司发出风险声明，其防火墙、VPN设备使用的操作系统具有重大安全风险，建议尽快升级相关版本。声明中提及两个重大风险：1）设备的SSH登录系统在输入任意用户名的情况下，使用超级密码“<<< %s(un='%s') = %u”后就可以最高权限登录系统。2）设备的VPN安全通道上传递的数据可以被攻击人解密、篡改和注入。下文就该VPN安全事件进行深入的分析。

2008年Juniper公司决定在其VPN设备的操作系统ScreenOS中引入随机数生成算法：Dual_EC_DRBG(Dual Elliptic Curve Deterministic Random Bit Generator)。该算法由美国情报机构NSA在2000年提出，在2004年纳入美国标准ANSI X9.82。同年NSA通过和RSA签署1千万美金的合同，RSA公司将该算法作为其广泛使用的密码应用开发包BSAFE的默认随机数生成算法。通过美国的NIST组织推动，在2005年该算法也被纳入ISO/IEC 18031。

 

Dual_EC_DRBG算法基本工作方式如下：在定义于32字节大小素域的椭圆曲线上选择两个阶p（p为256比特大小的素数）点P,Q后，根据初始化状态s0 (32字节数)，通过以下计算输出32字节“随机”数据。其中[s]R是在椭圆曲线上对R的倍点运算，x轴(R)是取点R的x轴向量值。

1. s1 = x轴([s0]P)

2. r1 = x轴([s1]Q)

3. s2 = x轴([s1]P)

4. r2 = x轴([s2]Q)

5. 输出 = 低三十字节(r1) || 高两字节(低三十字节(r2))

 

从该算法提出之日起，业界就质疑该算法的安全性，认为其有被植入了后门的可能。2007年8月微软的两个学者Shumow、Ferguson在密码学会议上报告利用Dual_EC_DRBG的方法。

1. 如果攻击人知道d: P=[d]Q, 知道算法的当次输出：低三十字节(r1) ，最多尝试64K次就找到某个或多个R=[s1]Q（r1只有2个字节未知，最多尝试64K次就可以确定[s1]Q 的x轴值，进而确定y轴值）

2. 计算x轴([d]R)=x轴([(d*s1)]Q)=x轴([s1][d]Q)=x轴([s1]P)=s2

3. 根据s2可以计算s3、s4、r3、r4和新的低三十字节(r3) || 高两字节(低三十字节(r4))

 

通过上面的分析可以看出，如果P、Q中只要有一个是由攻击人主动选择的，攻击人就可以计算出发起攻击的参数d，进而通过观察算法应用过程中暴露的某些“随机数”，计算出下个密码运算使用的“随机数”。因标准文本中的P、Q均有NSA提供，所以理论上NSA是可能破解使用该算法的密码系统的。

 

在这样的背景下Juniper公司于2008年在其ScreenOS中引入Dual_EC_DRBG算法并对VPN的密钥交换协议的实现进行相应的调整。其中涉及4个重要的变化：

1. 引人Dual_EC_DRBG算法作为随机数源。

2. 系统默认配置下直接将Dual_EC_DRBG算法输出作为系统随机数发生器输出。在特定命令配置后，系统将Dual_EC_DRBG算法输出作为另外一个随机数算法的随机种子。

3. 将VPN密钥交换协议IKE协议的Nonce字段从20字节修改为32字节。该Nonce字段是IKE协议中明文字段，包含随机数。

4. 一次性生成IKE协议过程需要的所有随机数，缓冲到队列中，也就是将协议中需要使用的Nonce，Diffie-Hellman(DH)交换中的随机私钥等一次性生成。

另外Juniper在实现Dual_EC_DRBG算法是并未使用ANSI X9.82中的点Q，而是自己生成了另外一个点Q'。经过以上的修改后，如果攻击者知道d': P=[d']Q'，通过观察IKE协议的报文交换首先获取协议中明文Noince字段中的32字节随机数，进而可以计算中协议后续过程中的所有随机数，包括DH交换中的随机私钥。在获得DH的随机私钥后，就可以计算协商的会话密钥进而对建立的VPN隧道进行解密、窜改等各种攻击操作。通过以上分析可以看出，如果Juniper公司不是随机生成点Q'，而是通过简单计算，如：随机选择256比特数e，计算d'=e-1 mod p (p是点P的阶)，Juniper公司就具备包括解密使用其设备进行VPN通信的各种能力。但故事并未在这里结束。。

在2013年6月根据爱德华斯诺登泄露的文件显示NSA通过执行一个称之为Bullrun项目将Dual_EC_DRBG算法植入标准、广泛使用的算法开发包等方式获得解密密码系统的能力。2013年10月Juniper发出声明其设备并不会受到NSA破解能力的威胁，因为1）Juniper使用了不同的点Q'。2）Dual_EC_DRBG算法的输出还会经过另外一个随机数生成算法进行运算。在2013年这个时间点上，这个声明中的两个关键点都不成立。其中关于第2）点，Juniper设备在默认情况下，直接将Dual_EC_DRBG算法的结果作为系统的随机数发生器输出。只有在使用一个非公开的命令配置后，Dual_EC_DRBG算法的结果才会被作为另外一个随机算法的种子。Juniper在2016年1月修改了这个声明[6]，去除了第二项。在网页存档系统中可以发现原始声明[3]。声明中的第1）点在2015年12月的风险提示中也被证明并不正确。Juniper提示通过代码审查发现，在2012年的某个时间，其公司的ScreenOS的源代码被篡改。其中Dual_EC_DRBG算法实现中原先使用的Q'被窜改为了另外一个X，Juniper发布补丁将被篡改的值恢复为原值，并决定在2016年中完全去除Dual_EC_DRBG算法算法。

 

在这个充满戏剧性的事件中，Juniper公司无论出于何种原因在其VPN上留下一个可以被被潜在利用的功能。因法律以及缺乏相关信息的原因，本文作者不能将该功能归类为错误的实现还是是有意的设计。至今未披露或者确定身份的攻击者冒着巨大的风险或者使用了高超的攻击技术手段，通过修改Juniper源代码服务器上的代码来获得了解密Juniper VPN设备保护的敏感数据的能力。而在过去4年或者8年期间用户对此一无所知。

参考文献

[1] D. Shumow and N. Ferguson. On the possibility of a back door in the NIST SP800-90 Dual Ec Prng. CRYPTO 2007 rump session, Aug. 2007. URL http://rump2007.cr.yp.to/15-shumow.pdf.

[2] Matthew Green. A Few Thoughts on Cryptographic Engineering. Jan. 2015. http://blog.cryptographyengineering.com/2015/01/hopefully-last-post-ill-ever-write-on.html.

[3]Juniper Networks. Juniper Networks product information about Dual_EC_DRBG. Knowledge Base Article KB28205, Oct. 2013.

https://web.archive.org/web/20151219210530/https://kb.juniper.net/InfoCenter/index?page=content&id=KB28205&pmv=print&actp=LIST.

[4] Juniper Networks. Out of Cycle Security Bulletin: ScreenOS: Multiple Security issues with ScreenOS (CVE-2015-7755, CVE-2015-7756). Dec. 15 2015.

https://kb.juniper.net/InfoCenter/index?page= content&id=JSA10713&cat=SIRT_1&actp=LIST.

[5] H. Moore. CVE-2015-7755: Juniper ScreenOS Authentication Backdoor. https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authenticationbackdoor, Dec. 2015.

[6]Juniper Networks. Juniper Networks product information about Dual_EC_DRBG. Knowledge Base Article KB28205, Jan. 8 2016.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB28205&pmv=print&actp=LIST

[7]Bullrun (decryption program) . Wikipedia, the free encyclopedia, Apr. 13, 2016. https://en.wikipedia.org/wiki/Bullrun_(decryption_program)

[8] S. Checkoway, S. Cohney, C. Garman, etc. A Systematic Analysis of the Juniper Dual EC Incident. Apr. 2016. http://eprint.iacr.org/2016/376.pdf