Closed Bug 434128 Opened 16 years ago Closed 16 years ago

Check NSS's root CA cert store for compromised keys

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: david, Assigned: hecker)

References

(
URL
)

Details

Attachments

(1 file)

Hashes and CKA_LABELs for nssckbi/trunk
8.64 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
Build Identifier: 

See CVE-2008-0166 at the cited Web site.  

The discussion of this at the Risks Forum 25.15 indicates that "All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected."  This includes root certificates.  Certificate authorities should be queried to determine if any of them used OpenSSL on Debian-based systems to generate their root certificates.  

Reproducible: Always




For the Risks Forum 25.15, see <http://catless.ncl.ac.uk/Risks/25.15.html>.  Look for the entries titled "Debian OpenSSL Predictable PRNG Toys" and "Debian OpenSSL Vulnerability".  

As Frank Hecker indicated, it is unlikely that any root certificate in Mozilla product databases is affected.  However, it is best to ask than to make an assumption.
To clarify, the problem exists only for Debian-based implementations of OpenSSL.  Other Linux and also UNIX implementations are not affected.  
CAs that are included in NSS don't tell us exactly how they generated their keys. There is nothing we can do unless a CA notifies us that this was the case. The best we can do is review the list of CAs that were added after September 2006.

Julien: can we extract the keys into a suitable format and then run them through some of the weak key detector scripts which have been written?

Gerv
Gervase,

What format of keys do these tools accept ? Can any of them just read a DER cert and extract the public key from them ? That would be the best way if possible. You can use certutil to extract the DER of all our roots.

Generally because of its PKI nature we avoid manipulating public keys outside of certs in NSS, except when doing cert requests.

I'm afraid I'm not an expert on key formats. The details of the tools are here:
http://wiki.debian.org/SSLkeys
Start reading at the heading "Testing keys using ssh-vulnkey". You probably want dowkd.pl. The changelog says the latest version has:
"Integrated PEM support (Available with the file option)"
if that's any use.

I can't see that there'd be any harm in extracting keys from NSS to check them with this tool. It's not like you are making modifications and then trying to put them back again.

Gerv

Someone has released a source tarball containing a program that
builds against (patched) openSSL libraries on Ubuntu Linux.  See
https://launchpad.net/ubuntu/+source/openssl-blacklist/0.2

The sources reportedly contain SHA1 hashes of all the invalid RSA public
keys of lengths 1k and 2k bits, and contains (limited ?) support for keys
of length 512, 4k and 8k.  The latest version of it (v 0.2, at the URL
above) reportedly will take an X.509 cert and determine if the cert's
public key is one of those for which it has a known hash.  Since it is
based on OpenSSL, I expect that it will expect certs to be in PEM format.

I have not attempted to build it.  I do not have Ubuntu Linux, so I
expect it would take considerable porting just to build it.  Also, IINM,
it assumes that you already have the patched OpenSSL built and installed.

If we had that program working and running on a platform to which we
all have access, then presumably it would not be a big job to write a
script to test all the certs in nssckbi against that program.  An
outline of the steps would be:

1. get certutil to output a list of all the nicknames of built-in certs
2. for each nickname in that list,
-     get certutil to output the cert in PEM, and
-     run the program

I estimate that this might be as much as a week's time of work, especially
for someone who has no access to that (or a comparable) Linux platform,
and who has never before built or used openSSL.
(In reply to comment #6)
> Someone has released a source tarball containing a program that
> builds against (patched) openSSL libraries on Ubuntu Linux.  See
> https://launchpad.net/ubuntu/+source/openssl-blacklist/0.2

See also bug 435082.

> If we had that program working and running on a platform to which we
> all have access, then presumably it would not be a big job to write a
> script to test all the certs in nssckbi against that program.  An
> outline of the steps would be:
> 
> 1. get certutil to output a list of all the nicknames of built-in certs
> 2. for each nickname in that list,
> -     get certutil to output the cert in PEM, and
> -     run the program

DER is also fine for OpenSSL, the only thing to note is that the hashes are based on a particular format of OpenSSL's output, i.e. "Modulus=CADFA20..." (the initial string is included in the SHA1 calculation).

> I estimate that this might be as much as a week's time of work, especially
> for someone who has no access to that (or a comparable) Linux platform,
> and who has never before built or used openSSL.

Using a quickly hacked up version of http://cool.haxx.se/cvs.cgi/curl/lib/mk-ca-bundle.pl, I've created the attached list, which consists of the SHA1 "blacklist hashes" of all 123 certs currently in trunk.

When checking the hashes against the currently available blacklist.RSA-{1024,2048} files from Ubuntu, no matches are found. There are a number of certs with key sizes other than 1024 or 2048, so this should only be considered a preliminary result.
Kaspar: that's excellent. Many thanks. Can we expect you to test the list from NSS against a 4096-bit list when it appears?

Gerv
Note that any certs issued before September 2006 are not at risk, unless 
they coincidentally just happen to have one of the public keys that could 
also have been generated by the defective Debian OpenSSL software.
That should be statistically extremely improbable.  Much of the security 
of public key systems depends on that improbability.

So, the remaining question seems to be: are there any certs with RSA public
key sizes other than 1024 and 2048 that were issued after September 2006.

Kaspar, do you happen to know the answer to that question?
Summary: Possible Certificate Vulnerability → Check NSS's root CA cert store for compromised keys
(In reply to comment #9)
> So, the remaining question seems to be: are there any certs with RSA public
> key sizes other than 1024 and 2048 that were issued after September 2006.
> 
> Kaspar, do you happen to know the answer to that question?

No. I don't have information from these CAs about when exactly they generated their key pair. I would be very surprised to learn, however, if the generation of any of these root keys is based on a software PRNG (OpenSSL's, specifically).

If you want to infer the date of key generation from the notBefore field in the certificates, then here's the data for all non-1024/2048 bit keys in nssckbi:

1000 bit modulus
----------------

Verisign/RSA Secure Server CA
Not Before: Nov  9 00:00:00 1994 GMT


4096 bit modulus
----------------

AOL Time Warner Root Certification Authority 2
Not Before: May 29 06:00:00 2002 GMT

GeoTrust Universal CA
Not Before: Mar  4 05:00:00 2004 GMT

GeoTrust Universal CA 2
Not Before: Mar  4 05:00:00 2004 GMT

America Online Root Certification Authority 2
Not Before: May 28 06:00:00 2002 GMT

QuoVadis Root CA 2
Not Before: Nov 24 18:27:00 2006 GMT

QuoVadis Root CA 3
Not Before: Nov 24 19:11:23 2006 GMT

StartCom Certification Authority
Not Before: Sep 17 19:46:36 2006 GMT

Taiwan GRCA
Not Before: Dec  5 13:23:33 2002 GMT

Swisscom Root CA 1
Not Before: Aug 18 12:06:20 2005 GMT

SwissSign Platinum CA - G2
Not Before: Oct 25 08:36:00 2006 GMT

SwissSign Gold CA - G2
Not Before: Oct 25 08:30:35 2006 GMT

SwissSign Silver CA - G2
Not Before: Oct 25 08:32:46 2006 GMT

DigiNotar Root CA
Not Before: May 16 17:19:36 2007 GMT
(In reply to comment #10)

Kaspar, thanks a lot for that list.  I am willing to treat the notBefore
date as a upper bound for key gen dates.  I'm willing to believe that 
the certs were not given notBefore dates that are earlier than the dates
on which the keys were generated.  So, using your list, I see these CAs
that have any chance of having been generated with a software PRNG based
on OpenSSL code.

> StartCom Certification Authority Not Before: Sep 17 19:46:36 2006 GMT
> SwissSign Platinum CA - G2       Not Before: Oct 25 08:36:00 2006 GMT 
> SwissSign Gold CA - G2           Not Before: Oct 25 08:30:35 2006 GMT
> SwissSign Silver CA - G2         Not Before: Oct 25 08:32:46 2006 GMT
> QuoVadis Root CA 2               Not Before: Nov 24 18:27:00 2006 GMT
> QuoVadis Root CA 3               Not Before: Nov 24 19:11:23 2006 GMT
> DigiNotar Root CA                Not Before: May 16 17:19:36 2007 GMT

I know that at least one of those WAS generated using OpenSSL, but I
don't know if they used a hardware PRNG, nor if it was Debian Linux.

This is a very short list, just 4 CA companies, and we have good 
communication channels with at least 3 of them.  I suggest that we ask 
them straight up if their root CAs were generated with OpenSSL on Linux
using a software PRNG.  

Just for clarity, the openssl-blacklist that Ubuntu developed (and is now in Debian), contains the openssl-vulnkey tool, which is a python script. The hash is a sha1sum of the modulus of an x509 certificate or rsa private, and the modulus is retrieved using openssl. On package build, the full hashes from the source are made smaller (to least significant 80 bytes) for space. A particular version of openssl is not required, but we versioned it to help ensure that users got the upgraded package.

So in terms of NSS or anything else, all you need is the modulus prefixed with 'Modulus='. Eg:
Modulus=D33C5D6E98B0EA4EAB...

Key Generation in the SwissSign CA
==================================
1. For Root Keys we use the Hardware Random Number Generator in the SafeNet
Luna CA3 Token. This is true for these CAs
SwissSign Platinum CA - G2
SwissSign Gold CA - G2
SwissSign Silver CA - G2

2. For Issuing CAs, issued by any one of the three Root CAs listed above, we
use the Hardware RNG in the SafeNet Luna SA HSM. This is true for all currently
active Production CAs that issue end user certificates. (The list would be
somewhat longish, so I'll not add all these CAs here)

3. For Subscriber certificates that use CA generated key material (Online Keys)
we use our own version of OpenSSL. We had to do this, because we have added
some functions that were required by the CA Software. Our Version of the Code
is based on the original source and therefore not affected by this particular
bug.

To summarize: SwissSign is not affected by this issue. Our Customers are not
affected unless they supplied their own key material and have generated these
keys with an affected version of openssl. 

I hope this helps to clarify the situation at SwissSign.

CCing representatives of StartCom, Quo Vadis and Diginotar.

Gentlemen: if you have something you'd rather not say publicly, please email security@mozilla.org. Otherwise, please clarify the situation with regard to the RNG used to generate your roots.

Gerv
Also the StartCom CA is not affected by this bug in any way. I've covered this on the mailing list already: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/3fffc42277bba13e
Hello:
We confirm that the QuoVadis Root CA2 and QuoVadis Root CA3 certificates are not affected by the Debian/OpenSSL bug.
Regards, Stephen Davidson
QuoVadis
Hello:

DigiNotar confirms that the Diginotar Root CA is not affected in any way by the Debian/OpenSSL bug. 

Regards,

Kick
Manager, Product management & development
Great. Nelson, Julien, David: can we close this bug, then?

Gerv
worksforme
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
A more useful question for the CAs is whether they will
check the certificates they have issued and revoke the
ones that contain the compromised public keys.
At this stage we haven't done this for now at StartCom, which falls under the subscriber obligation as per policy. We've revoked every certificate which was requested due to the Debian bug and the amount of those requests lives up to the expectations in relation to possible affected subscribers.
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: