OF F ERING S

B LOG

CASE STUDIES

CAREERS

NEW S & EVENTS

RESOURCES

AB OUT US

CONTACT

MA RCH 8, 2012

SSL Key
Generation
Weaknesses
BY

Carl Livitt

For those that are new to PKI (Public Key

Infrastructure) or those that want a quick refresher, the
following video is a great explanation and metaphor
based on colors and clocks:

Public Key Cryptography: Diffie-Hellman Key Exchange

By Art of the Problem

Use original player

Whether the problem is influenced more by Moores

Law or by Murphys Law, history tells us that every so

often there is a publicly disclosed key generation flaw
in a popular encryption algorithm. For example:
February 2012 Ron was wrong, Whit is right
August 2009 Compromise of SSL-protected
communication
May 2008 Debian/Ubuntu OpenSSL Random
Number Generator Vulnerability
December 2008 MD5 considered harmful today
In most cases we see issues with random number
generation rather than the core design of SSL
security.

In the recent paper titled Ron was wrong, Whit is

right Lenstra, Hughes, Augier, Bos, Kleinjung, and
Wachter present technical findings related to a
weakness of RSA crypto keys.
This post will present a condensed version of the
paper with the aim of clarifying the issue, its impact,
and the systems that are affected. Additionally some
recommendations will be outlined for how to prepare
and protect your assets from the next inevitable crypto
weakness discovery.

SSL is Not the Problem

At the heart of the public confusion is a concern that

SSL encryption itself is flawed; it is not, and the
research paper does not describe any inherent
weaknesses in SSL or other methods of encryption.
The security of SSL and other asymmetric
cryptographic systems relies upon secrets that are
difficult to calculate or guess; the secrets take the form
of extremely large prime numbers that are generated
once per cryptographic certificate. Any failure in the
confidentiality of a certificates secret prime number(s)
will result in the certificate being compromised,
rendering it useless for the purposes of encryption
and signing.
As long as a certificates secrets remain secret, SSL
remains strong.

The Root Cause

The actual issue under discussion in the research
paper is the way in which cryptographic keys (and the
associated prime numbers) are generated.
What the researchers found is that a number of realworld SSL certificates have been generated with the
same prime numbers. Researchers determined that
the massive primes were not random. In fact there
was a great deal of repetition amongst certificates
belonging to unrelated people, companies, and
systems.
Because of the lack of randomness, the researchers

were able to use simple algorithms dating from

Euclids era to quickly and easily calculate the secrets
belonging to a quarter million SSL certificates from
systems all around the world.
The underlying cause of the issue is not yet known,
although tentative suggestions are pointing toward a
broken key generation implementation that is shared
amongst several types of embedded devices.

What Type of Crypto Systems are

Affected?
As far as we know, the scope of the problem is limited
to SSL certificates that use 1024-bit RSA keys. Not all
1024-bit RSA keys are affected.
For now it is reasonable to assume the most widely
affected systems will be HTTPS web servers.
The research indicates that only small subsets of RSA
keys were generated insecurely. While the origin of
each affected RSA key is not yet known, there are
strong indicators that the keys were created on
embedded systems such as routers and firewalls.

What Systems are NOT Affected?

All indicators from the current research (Q1 2012)
suggest that only SSL certificates are affected. Other
systems such as PGP keys, RSA tokens, and other
RSA-based keys are either not affected or there is
insufficient data to draw solid conclusions.

It should be kept in mind that it is RSA key generation

that is affected; the applications and systems that rely
on RSA keys are not the culprit.

The Impact
If an adversary were able to calculate the secrets for
an SSL certificate, they would be able to create a
duplicate of that certificate. With a duplicate it would
be possible to achieve these goals:
Decrypt any data that was encrypted using the
compromised certificates
Impersonate any system that used the
certificate as a form of authentication
Tamper with encrypted data in transit
Modify encrypted data at rest

The Likelihood of Successful

Attacks
Practical real-world attacks are hard. This is because
an adversary must not only exploit RSA key
generation weaknesses, but must also be in a position
to intercept encrypted network traffic, or to steal
encrypted data from a server, or to somehow insert
themself between two users in the middle of an SSLencrypted conversation.
As such, the most easily to exploit targets will be
internal network systems as opposed to external
(Internet-facing) systems. This is because it is much
easier for a malicious user to disrupt, redirect, or

intercept traffic on a corporate LAN than it is on the

Internet.
A sufficiently knowledgeable person with access to (a)
a compromised key, and (b) an internal corporate
network connection may be able to exploit the RSA
weaknesses to intercept, decrypt, and modify SSLencrypted network data.
The likelihood of an adversary performing the same
attack against, for example, an Internet-facing HTTPS
server is far less likely. Such an attack is hampered by
the difficulty of intercepting network communications
between a web server and its users.
It should be noted, however, that certain nation states
and ISPs do have the capability to monitor and
intercept the connection between a user and a
service.

Next Steps
It is almost inevitable that tools will be released to
exploit this situation. For example, weaknesses in
Windows password hashing algorithms led to the
release of L0phtcrack; similarly, weaknesses in Wi-Fi
WEP encryption led to the release of AirCrack,
NetStumbler, and many other cracking tools.
It would be prudent to anticipate such tools and
attacks, and prepare systems in advance. The
following steps are highly recommended:
Establish a plan and policy to regularly review

critical crypto systems, specifically for

following key management best practices. See
Transport Layer Protection Cheat Sheet on
OWASP for details on best practices.
Perform scans against all known corporate
SSL-encrypted assets, such as HTTPS web
servers, email servers, SSL VPNs, etc. The
scans should check for the presence of 1024bit RSA certificates. See SSLScan in the
additional resources for more technical details
on how to perform such analysis.
Revoke certificates affected by the 1024-bit
RSA vulnerability and those that do not follow
NIST standards for recommended key length.
The private key used to generate the cipher
key must be sufficiently strong for the
anticipated lifetime of the private key and
corresponding certificate. The current best
practice is to select a key size of at least 2048.
Keys of length 1024 are considered obsolete
as of the beginning of 2010.
Regenerate all such certificates with
sufficiently strong keys and deploy them to the
affected servers.

Additional Resources
OWASP Testing SSL-TLS
OWASP Transport Layer Protection Cheat
Sheet
SSLScan Fast SSL Scanner
Penetration Tester Scripting SSL Tests

NIST: Recommendation for Key Management

Primal Fear: Demuddling The Broken Moduli
Bug
Ron was wrong, Whit is right - Lenstra,
Hughes, Augier, Bos, Kleinjung, and Wachter
encryption, ssl

SHA RE
Tweet

Like

CONTA CT US

Share

Next >

SHA RE WITH US

4 600 E. W ASH ING TON ST. SUITE 3 00

F ACEB OOK

LINKEDIN

PH OENIX, AZ 8503 4 UNITED STATES

G OOG LE

EM AIL

PLUS

TW ITTER

+1(4 80)621- 8967

CONTACT@B ISH OPF OX. COM

OF F ERING S
CASE STUDIES
NEW S & EVENTS
B LOG
CAREERS
CONTACT
COPY RIG H T 2013 B ISH OP F OX

RESOURCES

AB OUT US