As I mentioned in my last post, NIST issued FIPS 140-2 Level 1certificates for NSS. I'm pleased to announce that NIST has just issued the Level 2 certificate. You can see the notification here.

We feel that a Level 2 validation better represents the way our customers deploy NSS-based applications. For example, Level 2 testing allows us to run on a multi-user OS, in multi-user mode, whereas Level 1 requires that tests be conducted with a single user on the machine (which isn't how our customers deploy NSS-based apps). Level 2 testing is also performed on an operating system that "is evaluated at the CC [Common Criteria] evaluation assurance level EAL2 (or higher)".

Level 2 certificates for software are rare. And to the best of my knowledge, NSS is still the only open source crypto library to obtain a Level 2 certificate (the highest available for software modules).

This Level 2 certificate is a big win for the NSS team. Thanks to eveyone who helped!

NIST has issued the FIPS 140-2 Level 1 certificate for NSS 3.11.4.  You can see the certificate here. We expect the Level 2 certificate (currently the highest level possible for software) within a few weeks.  Although Level 1 validation is sufficient for most purposes, we feel that the requirements of Level 2 better reflect the way customers deploy security-enabled products, so we go to the added time and expense to achieve that higher level validation. 

This is the fourth FIPS validation for the NSS crypto libraries.

What does this really mean? 

First, we use this version of NSS in Firefox 2.x.  People who work in the U.S. Federal Government generally must use products that have obtained FIPS 140 certificates (when those products use cryptography).  Now that Firefox is using a FIPS 140-validated version of NSS, Government users can upgrade from Netscape Communicator (yes, you read that correctly) to Firefox 2.0. 

Second, RHEL 5.0 ships with this version of NSS as a shared library.  Apps like RHEL smartcard login, Firefox, and Thunderbird use this shared library and are able to inherit this newly issued FIPS 140 validation.  Further, we're embarking on an effort to NSS-enable a number of key applications in Linux (OpenSSH, stunnel, pam_pkcs11, etc.) to extend the reach of this validation.

Those of you who track this sort of thing in detail will want to understand this next point.  What we submitted to NIST for validation was not all of NSS.  Instead, we put all the code that was subject to FIPS 140 guidelines into a shared library module called the "Soft Token" (/usr/lib/libsoftokn3.so on RHEL). We very cleverly numbered the Soft Token module we submitted to NIST to be version "3.11.4".  So here's the confusing part:  "NSS 3.11.4" includes "Soft Token 3.11.4".  "NSS 3.11.5" and "NSS 3.11.7" also include "Soft Token 3.11.4". So it's not really correct to talk about NSS 3.11.4 being FIPS validated since NIST actually reviewed Soft Token 3.11.4. In hindsight, we should have started the Soft Token numbering with 1.0, and submitted "NSS Soft Token 1.0" to NIST.  Live and learn...

I'll update my blog when the Level 2 certificate shows up on the NIST web site.

Good news: NIST has moved NSS from the "Coordination" stage into the "Finalization" stage! This is, as the name would imply, the final stage on our quest to obtain our fourth set of FIPS 140 certificates.

I'll post again when we have the final certificates.

I read with interest a press release from Dolby titled "Dolby Digital Cinema Recommended for FIPS Level 3 Certification by InfoGard".  In it, they announce that Dolby's FIPS testing lab, Infogard, has submitted Dolby's FIPS 140 paperwork to NIST.

That, by itself, isn't all that interesting.  But I didn't understand why Dolby would be using advanced cryptography until I read this part of the press release:

The FIPS 140 specifications are designed to make sure products that are sold to the US Government meet some minimum standard for things like key hygiene. They were not designed to allow companies to prove that they had implemented Digital Rights Management (DRM) properly.

I poked around and found a document titled "Digital Cinema System Specification Version 1", dated April 12, 2007. It has a number of interesting sections, including requirements like:

• Secure integrated circuits used for Digital Cinema security applications shall be of the type designed to resist physical and logical attacks, and shall ensure that a physical attack destroys CSPs prior to exposure. Devices meeting the “secure silicon” level of protection shall only be required to meet FIPS 140-2 level 3 row (area) five: "physical security requirements.”
• The AES cipher, operating in CBC mode with a 128 bit key, shall be used for Digital Cinema content encryption.
• Digital Certificates are the means by which the Security Manager identifies other security devices, and is also used in establishing Transport Layer Security (TLS) connections.

While it seems quite logical for the motion picture industry to leverage existing rigorous testing processes to ensure all participants meet the same standards (instead of inventing their own), it was a bit of a surprise to me to learn that they were doing so to keep people from copying movies.

As I've written before, we are working to renew the FIPS 140 validation of the NSS crypto libraries.  As of last week, we are now in the "Coordination" phase with NIST.  In this phase, NIST will ask questions about our documentation, and we will attempt to answer them to their satisfaction.

The next and final phase is called "Finalization".  Let's hope the "Coordination" phase goes smoothly!

I mentioned in November that the fourth FIPS 140 validation for the NSS crypto libraries was moving along. At that time it moved from "IUT" (Implementation Under Test) to "Pending Review". 

The most recent Pre-Validation List from NIST [PDF] shows that NSS has recently moved from "Pending Review" to "In Review". That status means that reviewers have been assigned to the NSS case. (You can read more about the various stages here.) This is a big step forward, and we hope the process will continue uneventfully.

While I'm thinking about FIPS 140, I should mention that Wan-Teh Chang, one of the NSS engineers, will be delivering a talk titled "The Joy of FIPS 140-2 Validation" at the RSA Conference in February.  If you are going to the RSA Conference, be sure to check out Wan-Teh's talk!

The NSS team has been preparing to submit the latest version of NSS for FIPS 140-2 validation at Security Levels 1 and 2.  We completed the necessary documentation, passed the conformance testing, and submitted our docs to NIST last week.  This week, NIST "pre-validation list" (Page 8 of the PDF) shows that NSS moved from "IUT" (Implementation Under Test) to "Pending Review". That means that the ball is in NIST's court, and they may take up to 3 months to issue the final validation certificates.

When the certificates are issued, it will be the fourth FIPS validation for NSS, the first being way back in 1997.

The Firefox 2 Beta 1 milestone was released today. There are a number of changes in the cryptography of this release that are noteworthy:

1. When Firefox makes an OCSP request to validate a web server's certificate, it now uses whatever proxy you set up for normal HTTP traffic. (Bugzilla Bug 111384)
2. Support added for Elliptic Curve Cryptography (ECC) in TLS. There's a test server here.  Please be gentle with this server. If it starts to melt we'll have to take it offline.
   
3. SSL2 is off by default. (Bugzilla Bug 236933)
4. The weak ciphers (keys less than 64-bits long) are off by default.
5. It supports the TLS server name indication extension to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. (See RFC http://www.ietf.org/rfc/rfc3546.txt)

Please run this software on a test machine.  It's a test release.  If you encounter any problems with the cryptography of this beta build, please file a bug here: https://bugzilla.mozilla.org/  (or contact me directly at blord at redhat)

The schedule for FF2 is at http://wiki.mozilla.org/Firefox2/Schedule and shows an August final release, but there's also a link to an online calendar that shows the final bits shipping at the end of September.

We continue to work towards FIPS 140-2 level 2 validation for the NSS crypto libraries.  When that effort is completed and NIST awards NSS the new validation certificates, people in the U.S. Government (and other places that value FIPS 140 validation) will be able to use the latest versions of Firefox and Thunderbird.

The recent version of the NSS crypto libraries that are undergoing FIPS 140 validation (for the fourth time since 1997!) are now listed on NIST's "FIPS 140-1 and FIPS 140-2 Pre-validation List " page. This is an important milestone on the path to obtaining FIPS 140-2 validation. 

You can learn more about the NSS FIPS effort here:

• http://www.mozilla.org/projects/security/pki/nss/fips/
• http://wiki.mozilla.org/FIPS_Validation

Here's a little crypto news that's been on my mind lately.

The NSS crypto libraries, the first FIPS-validated open-source crypto implementation, is now well on it's way to completing it's 4rd round of FIPS 140 (Level 2) validation. On 1/20/2006 we received the certificates from NIST for AES, Triple DES, SHS, and HMAC.

This is an important milestone. We'll use the FIPS version of NSS in upcoming versions of Red Hat products like the Directory Server and Certificate System. We will also use these libraries in upcoming versions of Firefox and Thunderbird, allowing people in the U.S. Government to upgrade from older versions of the Netscape products (like Netscape Communictor 4.7 in some cases!).

I went through some old docs a few days ago, and was reminded that NSS received its first validation in 1997 as part of the Netscape products. In 2001 we open sourced NSS (after the U.S. export regs changes and the RSA patent expired). In that same year NSS also received its second round of FIPS 140 Level 2 validation, the first as an open source product.

If you've read this far, these links might interest you:
http://wiki.mozilla.org/FIPS_Validation
http://www.mozilla.org/projects/security/pki/nss/fips/
http://www.mozilla.org/projects/security/pki/nss/overview.html