Vulnerability Note VU#274923

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.

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, and it is enabled by default:

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

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.