Dual_EC_DRBG output using untrusted curve constants may be predictable

Overview

Output of the Dual Elliptic Curve Deterministic Random Bit Generator (DUAL_EC_DRBG) algorithm may be predictable by an attacker who has chosen elliptic curve parameters in advance.

Description

NIST SP 800-90A defines three elliptic curves for use in Dual_EC_DBRG but does not describe the provenance of the parameters used to define the curves. Noted cryptographers and cryptographic vendors have expressed concern that an attacker who has carefully chosen parameters used to define the curves could predict the output of Dual_EC_DBRG. Due to these concerns, and since Dual_EC_DRBG is an approved Federal Information Processing Standard (FIPS), NIST has reopened Special Publication 800-90 for comment. The CERT/CC has contacted vendors that are identified by NIST as being FIPS-certified Dual_EC_DRBG implentors. We have included their responses below and in the Vendor Information section.

This issue is an instance of CWE-327: Use of a Broken or Risky Cryptographic Algorithm.

Dual_EC_DRBG is also specified in ISO/IEC 18031:2011 Information technology – Security techniques – Random bit generation.

NIST explains the issue in a bulletin:

Concern has been expressed about one of the DRBG algorithms in SP 800-90/90A and ANS X9.82: the Dual Elliptic Curve Deterministic Random Bit Generation (Dual_EC_DRBG) algorithm. This algorithm includes default elliptic curve points for three elliptic curves, the provenance of which were not described. Security researchers have highlighted the importance of generating these elliptic curve points in a trustworthy way. This issue was identified during the development process, and the concern was initially addressed by including specifications for generating different points than the default values that were provided. However, recent community commentary has called into question the trustworthiness of these default elliptic curve points.

CERT/CC is not aware of any demonstrated or reported attacks against applications of Dual_EC_DRBG.

Based on responses from vendors and publicly available information, the following vendors do not use DUAL_EC_DRBG in their products:

* Cisco
* Catbird Networks

The following vendors do use DUAL_EC_DRBG in their products, but** it is not enabled** by default:

* Blackberry
* Cummings Engineering
* Juniper (only in ScreenOS)
* Lancope
* McAfee
* Microsoft 
* Mocana
* OpenSSL (only in the FIPS module)
* SafeLogic

The following vendors do use DUAL_EC_DRBG in their products, andit is enabled by default:

* RSA

Further details for each vendor are available in the Vendor Information section below.

Impact

A remote, unauthenticated attacker with minimal knowledge of the vulnerable system and the ability to conduct a brute force attack against an affected application may be able to guess secret key material. Secondary impacts include authenticated access to the system through the affected service or the ability to perform man-in-the-middle attacks.

---

Solution

Apply an Update

Some of the vendors listed have provided an update:

* [McAfee](<https://kc.mcafee.com/corporate/index?page=content&id=SB10067>)

Discontinue use of Dual_EC_DRBG

The NIST bulletin recommends organizations discontinue use of the algorithm until its security concerns are mitigated:

NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A,no longer be used.

There are several other DRBG algorithms available for generating random numbers, including those based on hash functions and block ciphers. Utilizing one of those algorithms will mitigate the risk of this vulnerability.

Generate elliptic curves with known provenance
While not compatible with FIPS specifications, generating your own elliptic curves will provide assurance that random numbers cannot be predicted. See section A.2 of Appendix A in NIST SP 800-90A for more information.

Regenerate key material
Due to the nature of the flaw, any key material generated using Dual_EC_DRBG should be considered insecure. After changing algorithms or generating new curves, the key material must be regenerated. Vendor-specific instructions for doing this can also be found in the Vendor Information section of this document.

Vendor Information

274923

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

McAfee __ Affected

Notified: October 03, 2013 Updated: March 25, 2014

Status

Affected

Vendor Statement

"On September 17, 2013 an Edward Snowden leak indicated that the NSA may have a skeleton key to decrypt messages using the Dual Elliptic Curve (EC) Deterministic Random Bit Generation (DRBG) algorithm in RSA’s BSafe library. This was followed by NIST reopening SP800-90 due to some concerns the community has regarding the security of the DUAL_EC_DRBG algorithm.

The RSA BSafe crypto libraries are widely used for C, C++, and Java based programs used by many vendors, including McAfee. The libraries are also certified as FIPS 140-2 thus providing an avenue to certifying products as directed by NIST.

Impact:
Currently, McAfee has three (3) products that use Dual EC DBRG, and thus, are vulnerable.
Vulnerability Manager for Databases (DVM) / Database Activity Monitoring (DAM)
Network Security Management (NSM) appliances
McAfee Firewall Enterprise Control Center (MFE CC)
NOTE: MFE CC uses the CryptoJ BSAFE and Dual EC DRBG in FIPS mode only. Customers who do not run in FIPS mode never use Dual EC DRBG. The use of Dual EC DRBG was removed in 5.3.2

This issue is resolved in each of the vulnerable products per the release schedule in the Remediation section of this article."

Vendor References

• https://kc.mcafee.com/corporate/index?page=content&id=SB10067

RSA Security, Inc. __ Affected

Notified: September 23, 2013 Updated: October 16, 2013

Status

Affected

Vendor Statement

"Due to the debate around the Dual EC DRBG standard highlighted recently by the National Institute of Standards and Technology (NIST), NIST re-opened for public comment its SP 800-90 standard which covers Pseudo-random Number Generators (PRNG).

For more information about the announcement see:

<http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-A Rev 1 B and C&gt;

The ITL Security Bulletin mentioned in this announcement includes the following:

“Recommending against the use of SP 800-90A Dual Elliptic Curve Deterministic Random Bit Generation: NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A, no longer be used.”

The currently released and supported versions of the BSAFE libraries (including Crypto-J 6.1.x and Crypto-C ME 4.0.x) and of the RSA DPM clients and servers use Dual EC DRBG as the default PRNG, but most libraries do support other PRNGs that customers can use. We are providing guidance to our customers on how to change the PRNG from the default in their existing implementation.

In the current product documentation, RSA has provided technical guidance for RSA BSAFE Toolkits and RSA DPM customers to change the PRNG in their implementation.

RSA will change the default RNG in RSA BSAFE Toolkits and RSA DPM as appropriate and may update the algorithm library as needed."

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

• <http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/&gt;

Research in Motion (RIM) __ Affected

Notified: October 03, 2013 Updated: February 18, 2014

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

<http://jeffreycarr.blogspot.com/2014/01/blackberry-ltd-nsa-and-encryption.html&gt;

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23274923 Feedback>).

CatBird Not Affected

Notified: November 06, 2013 Updated: November 07, 2013

Status

Not Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Cisco Systems, Inc. __ Not Affected

Notified: October 03, 2013 Updated: November 07, 2013

Status

Not Affected

Vendor Statement

Cisco Response

Cisco is aware of the industry discussion regarding the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) and the recent decision of the U.S. National Institute of Standards and Technology (NIST) to reopen the 800-90A Special Publication (SP) to public review.

Cisco applauds the decision for increased public review of cryptographic standards and will monitor for any updates to NIST SP 800-90A.

Cisco has completed an internal investigation and has confirmed that the Dual_EC_DRBG is not in use in any Cisco products.

Additional Information

Cisco licenses third-party components that include the Dual_EC_DRBG; however, this Deterministic Random Bit Generator (DRBG) is not in use in any Cisco products.

Cisco products that use DRBGs for encryption are compliant with either the older ANSI X9.31 standard or the newer NIST SP 800-90A standard. The 800-90A-compliant crypto libraries in Cisco products have four DRBG options available to Cisco developers, but the standard Cisco implementation is Advanced Encryption Standard Counter mode (AES-CTR), not Dual_EC_DRBG. Additionally, there are no configuration modifications that could enable Dual_EC_DRBG.

Cisco provides strong encryption options that comply with international standards and local regulations. We are always watching for stronger encryption options, and if we find such an option, it will be implemented for the benefit of our customers.

Status of this Notice: Final

THIS DOCUMENT IS PROVIDED ON AN “AS IS” BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

• <http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131016-ec-drbg&gt;

Cummings Engineering __ Not Affected

Notified: October 08, 2013 Updated: October 16, 2013

Status

Not Affected

Vendor Statement

"The DUAL_EC_DRBG is disabled in all releases; it is not selectable by any configuration options on our products, and is not utilized in any compatibility modes either."

Vendor Information

DUAL_EC_DRBG is disabled and not user selectable in all software.

Juniper Networks, Inc. __ Not Affected

Notified: October 03, 2013 Updated: November 07, 2013

Status

Not Affected

Vendor Statement

"Due to recent statements (top of page #2) by the US National Institute of Standards and Technology (NIST) concerning the security of the Dual_EC_DRBG cryptographic algorithm, Juniper Networks would like to make the following statements:

The following product families do not utilize Dual_EC_DRBG:

1. Junos - Any product running Junos
2. Junos Pulse Secure Access Service (SSL-VPN / IVE OS)
3. Junos Pulse Access Control Service (UAC)
4. Junos Pulse
5. Junos Space
6. JunosE
7. CTP/CTPView

The following product families do utilize Dual_EC_DRBG, but do not use the pre-defined points cited by NIST:

1. ScreenOS*

• ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations."

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

• <http://kb.juniper.net/KB28205&gt;

Lancope __ Not Affected

Notified: October 07, 2013 Updated: December 09, 2013

Status

Not Affected

Vendor Statement

Lancope’s products do not enable Dual_EC_DRBG by default. For those customers who have taken the extra step of enabling Dual_EC_DRBG, Lancope has provided guidance to our user community regarding how to enable alternatives. If you are a Lancope customer in need of guidance information, please contact technical support.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Microsoft Corporation Not Affected

Notified: October 03, 2013 Updated: November 07, 2013

Status

Not Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

• <http://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx&gt;
• <http://technet.microsoft.com/en-us/library/cc750357.aspx&gt;

Mocana __ Not Affected

Notified: October 10, 2013 Updated: November 07, 2013

Status

Not Affected

Vendor Statement

The Dual_EC_DRBG algorithm was one of three random number generators made available to developers as options in DSF, NanoCrypto, and related products. All DSF components, including NanoCrypto, default to using FIPS 186 pseudorandom number generation, NOT Dual_EC_DRBG. The flawed Dual_EC_DRBG algorithm is available as an option in our DSF SDKs, and your developers may have “turned it on” at build time, overriding the Mocana default selection of FIPS 186; or they may have explicitly called the ECDRBG engine. If neither of these two steps were taken, then the random number generation algorithm used is not the compromised Dual_EC_DRBG.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

• <http://www2.mocana.com/l/7062/2013-10-15/mkbny/7062/123972/Security_advisory_NIST_SP_800_90A_Dual_EC_DRBG_Final.pdf&gt;

OpenSSL __ Not Affected

Notified: October 03, 2013 Updated: October 16, 2013

Status

Not Affected

Vendor Statement

"`The OpenSSL FIPS module is a cryptographic module which has been put through FIPS 140-2 testing. It is completely separate from OpenSSL itself.

If certain versions of OpenSSL are linked against that module they become “FIPS capable” and redirect cryptographic operations to the OpenSSL FIPS module.`

`If OpenSSL is not linked against the FIPS module the DUAL_EC_DRBG is not available at all.

The DUAL_EC_DRBG is not used by default in any versions of OpenSSL.

It is implemented in the current version of the OpenSSL FIPS module but the FIPS capable versions of OpenSSL will not use it by default. Specific calls need to be made to use the DUAL_EC_DRBG: i.e. it cannot be used “by accident”.

In other words unless the application makes very specific calls to enable the DUAL_EC_DRBG it will never be used."`

Vendor Information

Only the OpenSSL FIPS module implements DUAL_EC_DRBG but it is not enabled by default. The standard distributions of OpenSSL do not utilize DUAL_EC_DRBG.

SafeLogic __ Not Affected

Notified: October 08, 2013 Updated: October 16, 2013

Status

Not Affected

Vendor Statement

“Dual EC DRBG is one of many algorithms available for use within CryptoComply for Mobile and CryptoComply for Server modules, but requires specific customer action to select and activate the algorithm in question. Our default is AES 256 CTR, which is covered in Section 10.2 of SP 800-90A.”

Vendor Information

CryptoComply for Mobile and CryptoComply for Server modules do not utilize DUAL_EC_DRBG by default. The algorithm is implemented but requires user action to select and enable.

Panzura Unknown

Notified: October 16, 2013 Updated: October 16, 2013

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor References

SafeNet Unknown

Notified: October 03, 2013 Updated: October 03, 2013

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor References

View all 14 vendors __View less vendors __

CVSS Metrics

Group	Score	Vector
Base	7.1	AV:N/AC:H/Au:N/C:C/I:C/A:N
Temporal	5.2	E:U/RL:W/RC:UC
Environmental	1.8	CDP:MH/TD:L/CR:H/IR:H/AR:ND

References

• <http://www.nist.gov/director/cybersecuritystatement-091013.cfm&gt;
• <http://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.pdf&gt;
• <http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf&gt;
• <http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-A Rev 1 B and C&gt;
• <http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html&gt;
• <http://rump2007.cr.yp.to/15-shumow.pdf&gt;
• <http://eprint.iacr.org/2006/117.pdf&gt;
• <http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/&gt;
• <https://lwn.net/Articles/566329/&gt;
• <https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html&gt;
• <http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html&gt;
• <https://lwn.net/Articles/566329/&gt;
• <http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54945&gt;

Acknowledgements

Dan Shumow, Niels Ferguson (2007) and Daniel Brown (2006) published information related to this issue.

This document was written by Chris King.

Other Information

CVE IDs:	CVE-2007-6755
Date Public:	2007-08-21 Date First Published: