Welcome to the Acumen Security Blog

Archives for April 2014

Our Philosophy on Certifications

Hi everyone! Thanks for checking out our blog.  Today I thought it would be nice to share some of the philosophies on which Acumen Security is built. These philosophies came from our unique experiences on both sides of the table both as a certification lab and as a vender of certified products.

We’re the experts so you don’t have to be!

You don’t need to understand all the nuances and history. You don’t care what requirements looked like five years or why this document was written like this or that. You care about understanding what you need to do to get that checkbox and get your product out into the hands of government customers.  Ambiguity is the enemy of efficiency when it comes to certification. We believe it is our responsibility to you as the customer to take the ambiguity out of certification. Now if you want to know all the history of FIPS or CC we can give you that too. We’ve both been in the industry for well over ten years and have either collaborated with or competed against just about everyone in the industry.  But we’re guessing you have more important things to do like building world class products!

We will only ask you to do the bare minimum required (although we’ll make sure our recommendations make sense)!

Whether it’s functionality in a product, the dreaded word ‘evidence,’ or even the initial decision to get a product certified, we’re only going to ask you to do what is absolutely necessary.  If you believe a full product certification is necessary, but you already incorporate a FIPS certified software module, we’re going to suggest you consider skipping the FIPS certification and concentrate on things that are more productive for you, not necessarily for us. On the flip-side, if you have a product that meets current certification requirements but may not meet fast-approaching requirements (think key size transitions, new functional requirements, etc.), we will suggest that you start the process of roadmapping those features or even delaying the certification so that the effort is more meaningful long term. We’ve planned many certification and feature roadmaps in our years in the industry, we’ll help you do the same. In the end, we are going to do our best to make product certification as easy and meaningful as possible for you.

We will be proactive!

Does this sound familiar to you? You are finalizing the last bit of a certification when you get an email from an evaluator/tester saying that they have found a non-compliance.  This can be devastating (and costly) to engineering, release ops, program management, and most importantly your customers that you have promised to deliver certified products. We at Acumen Security understand this pain intimately.  To avoid this, we perform thorough assessments early in our engagement.  This is not just limited to your product. If a certification requirement does not necessarily make sense for your product, we will work with the certifying agency to ensure we have buy-in for your system up front rather than in the end when failure to get buy-in could mean a six month delay for your certification. We’ll set-up and test your product upfront to ensure that we’re ready to go when you’re ready to ship. In short, we’ll do everything we can to ensure the quickest and least surprising certification possible.

And finally, we’re partners!

In the end, we’re on this journey together.  At Acumen Security we absolutely understand that we couldn’t be here without you.  We strive to provide you a level of service and value that will allow us to not only partner with you on this certification but also the next and the next after that.  Acumen succeeds when you succeed in meeting your certification related procurement needs in the most effective and efficient way possible.  Certifications don’t have to be complicated, let us help show you the way!

Well, did these philosophies resonate with you? Let us know if you agree or disagree, give us a call or drop us a note. We are always up for a good discussion! Also, follow us on Twitter and like us on Facebook, we’ll keep you up-to-date on the ever changing world of government certifications.

NIST Updated SP 800-90A… open for comments

As some of you might recall, in the aftermath of Snowden revelations which cast aspersions on SP 800-90A DRBG’s security and integrity, NIST took the unprecedented step to withdraw SP 800-90A and open up a draft for comments.

This week NIST officially published a revised draft (found here) and has opened up public comments until May 23, 2014. Comments must be sent to RBG_comments@nist.gov with “Comments on SP 800-90A” in the subject line.

Acumen did a diff between this draft and the previously published standard and found the biggest change (no surprises here!) was removal of the Dual EC DRBG. This change was absolutely expected since it was this option of SP 800-90A DRBG that was considered to be weak (some say have a backdoor using skeleton keys)

Apart from this there are a number of other changes that could potentially impact future FIPS validations. These are enumerated below (Appendix F has a high level summary):

1. Definition of entropy source has been updated. Rather than pointing to SP 800-90B, this revision defines the entropy source as:

A combination of a noise source (e.g., thermal noise or hard drive seek times), health tests, and an optional conditioning component that produce random bitstrings to be used by an RBG

The interesting part here is that entropy source is defined as including health tests as well as (optional) conditioning. But this remains same as the definition in SP 800-90B so should be no surprises here.

2. In section 7, this revision changes the definition of DRBG. While previously it was “assumed” that DRBG are the mechanisms defined in SP 800-90A, the revision defines the DRBG as the DRBG mechanism and an approved entropy source (more on what is an entropy source is covered below).

3. Section 8.4 has been updated to require (it is a SHALL statement now) the crypto module not to use pseudorandom bits for an application that requires a higher security strength than the DRBG is instantiated to support. Based on the wording (and example provided) if the DRBG is instantiated to 128 bits security strength it cannot be used to generate 256 bit AES key. Previously it was understood that generating 256 bits of AES key would require two calls to the 128 bit based DRBG and as such security strength would be maintained (2 times 128 bits). The authors seem to imply this assumption is not correct.

4. Section 8.6.5 talks about entropy input and requires that the entropy input has to be obtained from within the cryptographic boundary. This could mean that for software modules (especially libraries) the entropy input would need to come from within the module itself. This potentially creates issues evaluating software modules that require HW entropy sources. The draft revision and SP 800-90C does define a concept of distributed DRBG boundary which could allow for hardware entropy sources however the last statement of section 8.5 seemingly closes the door on this by requiring that the sub-boundaries be the same or fully contained within a separate cryptographic module boundary. We believe there needs to be further clarification on DRBG boundary, distributed boundaries and how these relate to cryptographic module boundary.

5. Section 8.6.7 now requires that the nonce must be generated within the cryptographic boundary and defines how the nonce can be constructed (it provides four options). Note that it seems to be acceptable to generate the nonce in a different module as long as the module is FIPS validated and there is a secure  channel to transmit the nonce between the two modules

6. Section 11.3.1 now explicitly defines in what order the health tests (KATs for the most part) will be performed. In our experience most modules do run the tests in the order specified however it does affect FIPS requirements and something to consider. Another requirement to note is that internal state needs to be carried forward between the various health tests. This is described in good detail in 11.3.2-11.3.4 sections.

As you can see above there are a few questions that need further clarification especially around the definition of DRBG boundary and it’s relationship to crytographic boundary. Acumen will be reaching out to the authors and CMVP to get a better understanding. We will provide updates on what we find. We will also be submitting comments seeking clarifications on #3 and #4.

It would be a good idea to keep an eye on this draft and track progress to ensure any design/code changes are accounted for in your development plan!

For those interested in looking at the raw diffs, they can be found here (requires Name and Email). Be warned the diffs look ugly!