NIST is now accepting comments on the latest draft of FIPS 140-3.

From the website:

Electronic comments may also be sent to: FIPS140-3@nist.gov with “Comments on Draft 140-3″ in the subject line.

I saw this article a few days ago but didn’t have the time to post a link. Thank you to the good folks at EWA-Canada for the reminder.

There is a new FIPS 140 Testing Laboratory: ACTL: authsec Conformance Testing Laboratory. This brings the total to 14 labs.

With the NIST queue for review standing at about 5 months, I do wish NIST would enlist the help of the labs to assist with the validation component. The increased timeline has been quite frustrating for our customers, and I’m working up a proposal for an operations plan to help NIST with this issue.

Check out this blog post at Tenable Security. Marcus always has interesting things to say. There’s some talk about assurance, where Marcus essentially says that assurance shouldn’t be an afterthought.

I agree. True assurance should be baked in to the design of a product or system. Unfortunately that rarely happens with some of the government assurance programs such as FIPS 140 or Common Criteria. I’ve leveraged the requirements and processes of these programs during product design (both during my tenure at Cisco and at Apex). From my experience, considering these requirements at product design provides a much more positive impact on design / development and smoother execution of documentation evaluation / product testing when conforming to FIPS 140 or CC. It’s ideal, but obviously not necessary.

Some of our customers have asked us to provide an analysis on the new testing of the RSA algorithm for FIPS 140-2 validations. Without going to too much depth (to respect their contracts and interests), I thought I would summarize that analysis here.

Basically, NIST CMVP requires testing against a vulnerability discovered in RSA a few months ago that allows attackers to forge a PKCS-1 signature. Vendors face the following implementation policies (from the NIST CMVP website):

1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 31, 2006.
2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.2.
3. It is strongly advised that any CMVP cryptographic module in the pre-validation phase re-test the RSA implementations with the new version of CAVS.
4. After December 31, 2006, all new received test reports to the CMVP pre-validation queue must use the CAVS5.2 to validate RSA.

A colleague sent me a note inquiring about the applicability regarding OpenSSL. If you’re running OpenSSL, you can

1. download versions version 0.9.7k or later or version 0.9.8c or later
2. apply this patch

We recently ran algorithm testing for a customer running OpenSSL and passed with no issues. Then again, since they meet the criteria above, we expected them to.

The best bet here is to have your implementation validated with CAVS5.2 to be sure this vulnerability is addressed. It may not be easy, but it beats having your customer fault you if this vulnerability is exploited in their environment. Here is a rare example of being able to use assurance as intended!

One of the FIPS 140-2 Level 2 requirements for a multiple-chip standalone module is that the module’s case should be “opaque within the visible spectrum.” I have a long history with this requirement, which I’ll share with you as I lead up to my true thoughts on the requirement.

At Cisco, we had a hell of a time trying to design hardware to meet this very subjective requirement. We would occasionally bring in a laboratory to provide an initial assessment, but rarely did we know whether or not we would pass until we began the actual testing cycle.

When I complain, I tend to offer a solution. My mission was to take our experience with this subjective requirement to NIST, explain our situation, discuss the issues, and offer a solution. Long story short, my efforts yielded Implementation Guidance 5.1, which essentially states that one should not be able to see model/part numbers of components within the boundary. It gave us something a bit more tangible to design products against. While it wasn’t a pure victory, it did give us something.

But it was a battle that shouldn’t have been fought. Why? Because the opacity requirement is worthless. It’s senseless. It encroaches on the (more important) aspect of systems assurance. Remember, when someone in the Federal government purchases a FIPS 140-validated solution, that solution is deployed into an environment that requires assurance at a systems level. Systems Assurance as a process essentially answers two basic questions:

1. Does the system do what it is intended to do?
2. Does the system do something it is not supposed to do?

(more on systems assurance later)

So why is the FIPS 140-2 requirement of opacity worthless? Well, it fails to consider the fact that the product is deployed into a system that, among other things, provides physical security and access control to the type of equipment that pursues FIPS 140. In order for anyone to have access to a typical FIPS 140-validated appliance, they must have access to the system in which it resides. And if the person has access, what value exists to say that they can’t see into the product?

Regardless, what security benefit does opacity provide? It’s quite easy to determine the part numbers of any product. Read datasheets. Read press releases of component manufacturers. Heck, buy one off of Ebay and open it up!

The Physical Security requirements at Level 2 need to disappear completely.

Prove me otherwise.

There are some very interesting things going on within NIST regarding FIPS 140 and within NSA regarding Common Criteria. There are some new areas of potential FIPS 140 implementation guidance from NIST, and CCEVS is redefining a couple of policies. We have been working with our customers to address these situations, and a few customers have asked why I haven’t updated the blog with more details.

So here’s my dilemma- I don’t think I should blog about them because they’re not public and/or official yet. This blog isn’t meant to be a rumor mill. I’m not the press, and I don’t care to publicly speculate on unsettled, unofficial information.

As new CCEVS policies are released or FIPS 140 Implementation Guidance is issued, we will issue announcements and comments accordingly.

I am frequently asked about the FIPS 140-2 validation program’s impact on product security. Of course, it depends on how “security” is defined, but most folks asking the question are asking about its effectiveness in finding and reducing vulnerabilities. There are cases were certain types of vulnerabilities may be minimized because of FIPS 140-2 validation, but it’s not a panacea product security.

Here is an example: Cisco Systems recently announced a vulnerability in their IKE implementation, affecting ASA/PIX appliances, IOS software, and the VPN 3K Concentrators.

The attack against the Internet Key Exchange (IKE) protocol described in the NTA Monitor advisory exploits the stateless nature of the IKE version 1 protocol. The goal of such an attack is to deplete the resources available on a device to negotiate IKE security associations, and block legitimate users from establishing a new security association.

Now, I’m not picking on my former employer here; it’s just an example. This is a serious vulnerability that affects FIPS-validated products… including products from other vendors. So why didn’t FIPS 140-2 catch this? Well, because that level of protocol scrutiny doesn’t fall within the scope of FIPS 140-2 validation. It’s as simple as that.

It’s also important/interesting to note that the products will maintain their FIPS 140-2 validation certificates.

For more details on this vulnerability, read this document from Cisco.

The saga still continues. Apparently the OpenSSL FIPS 140-2 certificate has been reinstated. I have a hard time believing this was just an “oops” on the part of NIST CMVP. Nevertheless, it’s back up there. Hopefully this didn’t cause too much confusion in the end-user community.

The saga continues. For a while now, the Security Policy for OpenSSL has been marked as “Not Available.” I have been asked literally four times today by different people about the situation and several other times during the past two weeks. It’s worth a blog post, though this post won’t directly answer all the questions.

A colleague sent me this news article, which actually provides little insight.

Here’s my favorite quote:

NIST is not saying why the certificate was removed.

“The CMVP does not provide information regarding the status or reason as in many cases it may be proprietary,” Easter said in his statement.

What about this case? I can go download the entire source code, so what is proprietary? Why isn’t NIST talking about this?

I have heard a lot of different things about the OpenSSL validation from various entities, and I have made a few of my own estimates. I believe there are other factors at play, but I don’t want those rumors to propagate here.

I have been asked twice in the past week if we are planning to become a FIPS 140 testing lab. The answer is still no. Here is a post for reference.

In case anyone missed it, SAIC is now an accredited Cryptographic Module Testing Laboratory. They’ll be one to watch. Given their success in the Common Criteria space (one look at the In-evaluation list gives you some indication), they should be poised to do quite well.