OpenSSL Now FIPS 140-2 Certified

The process took five years:

The biggest frustration OSSI encountered by the seemingly endless delays is that now the software that was validated by the CMVP is more than three years old. "[This toolkit] is branched from version 0.9.7, but 0.9.8 is already available and 0.9.9 is in development," says Marquess. "We're glad it's available, but now it's dated. We understand a lot better what the CMVP's requirements are, though, so validation will go more smoothly next time around. We also know the criticism we'll encounter, and we'll nail them with the next release."

This is one problem with long certification cycles; software development cycles are faster.

Tags: ,

Posted on February 21, 2007 at 12:17 PM • 14 Comments

Comments

Anonymous Cow-ard • February 21, 2007 1:11 PM

The question still remains:
Can Bruce Schneier design a cipher so secure that he cannot break it?

Anon-31 • February 21, 2007 1:43 PM

Bruce, this is quite a common problem with certification cycles. Do you have any suggestions to shorten certification cycles?

radiantmatrix • February 21, 2007 1:49 PM

What's interesting to me in that article is the two major causes cited for the long validation. First, that the CMVP folks had to validate source instead of binaries (meaning, no doubt, trying every possible config option set). Second, that many people -- especially competitors -- made complaints in order to slow down the process.

The OpenSSL folks seem to have the right attitude about it, though:

"With other software [tested by CMVP], all the proprietary information is treated as trade secrets and we can't comment on it. On the one hand, that gives someone an advantage to disparage our work. On the other hand, we've been scrutinized and tested in the open, so we have a much more solid validation than the others."

snark • February 21, 2007 2:02 PM

To paraphrase Bruce Schneier, in \fIApplied Cryptography\fR, the reason certification takes so long is that \fBevery\fR possible set of options needs to be validated. If you have 20 independent, binary, options, you have 2^20 possible combinations(about 10^6).
This can be made smaller by making software simple.
``Complexity is the enemy of security''

rmg • February 21, 2007 3:07 PM

It should be pointed out that normal certifications for FIPS compliance are quick (months, not years), as they test pre-compiled binaries against test vectors. OpenSSL took longer because they had to do it at the source code level. They did this because it is open source, and therefore impossible to verify every possible compiled version of the code on every supported platform and against every dependency combination.

UNTER • February 21, 2007 3:21 PM

See why proprietary code is better? It only takes months to certify it!

(Bill Gates laughs evilly)

Filias Cupio • February 21, 2007 4:26 PM

It seems I'm developing a habit of putting security-related tidbits into the comments of whatever the most recent article in this blog is. Bruce, let me know if you think this is inappropriate.

Anyhow, back to the off-topic: New Scientist report an interesting anti-cellphone-theft measure. You need to enter a password every time put a number into the phone's memory, or anytime you call a number not in the phone's memory. This lets you use the phone without often needing to enter the password, but makes it essentially useless to anyone not in posession of the password.
http://www.newscientisttech.com/article/dn11212-invention-hot-lap-prevention.html
(third item. The second item is also security related.)

I've already thought of (and possibly suggested on this blog) a very similar scheme for online banking. Substitute "make a payment" for "make a call", "add an account to a white list" for "enter number into the phone's memory" and "turn up at a bank branch and sign papers" for "enter password." As such, I don't think this is worthy of a patent, but that is a different argument.

Eric • February 21, 2007 5:14 PM

The comments are on an important point: the certification cycle for commercial software is much shorter. So while there is an interesting debate about whether the test cycle *needs* to be longer for source code, if this is fair, more thorough, etc. Bruce's high-level comment about software development cycles being faster than certification cycles is not accurate for commercial software. Speaking from the perspective of a commercial vendor who did not obstruct the OpenSSL validation.

Filias Cupio • February 21, 2007 5:32 PM

So they could have provided binaries for (say) x86, PowerPC Linux and BSD, and had those quickly certified, had they wished to? (And encouraged OS vendors to submit an OpenSSL compiled against their OS?)

Stefan Wagner • February 21, 2007 8:48 PM

@Filias:
If you get the sources, to compile it yourself, you may fiddle around with all the compilerflags (optimize for 386, 486, 586, 686 ... for size, for speed, for a compromize, ...) include debug-information or not and so on.

Ian Woollard • February 21, 2007 11:30 PM

"Can Bruce Schneier design a cipher so secure that he cannot break it?"

Yes, and he can design a cipher so secure that only he can break it as well :-)

Piotr • February 22, 2007 2:16 AM

@Filias Cupio

"I've already thought of (and possibly suggested on this blog) a very similar scheme for online banking. Substitute "make a payment" for "make a call", "add an account to a white list" for "enter number into the phone's memory" and "turn up at a bank branch and sign papers" for "enter password." As such, I don't think this is worthy of a patent, but that is a different argument."


I'm not sure about other countries, but this scheme is used for years in Poland by at least one bank. You can create "defined payment" (target account, amount, etc), which must be authorized by one time password (you are already logged in by SSL, of course). Once defined, you can make such payment by a single click (when you are logged in), but editing anything requires one time password.

T Veesenmayer • February 22, 2007 8:37 AM

Some of the comments above are misleading. Binary-only libraries are also inspected at the source level during 140-x validation, and open/free/source-available ones are also tested in binary form (eventually, after source reviews). 140-x testing formally covers only selected, well-defined configurations, even if the module may be configured. This restriction is enforced mainly for the benefit of end-users, who should be able to easily check whether they run a version that has been actually tested. The only important difference between source-available and closed-source products is how much of the support documentation becomes public. For binary-only apps, most documentation remains confidential between the vendor, test lab, and NIST.

Otherwise, part of the hurdles for Openssl were real and technical (incorrect module definition), which were corrected. The rest are described in quotes above. A comparable closed-source product, without the backstabbing, would have passed through the progress several times faster, but still possibly in more than a year. Some of the 140-x process is not technically challenging, just mandates things that are unusual in everyday development, and sorting those out (changing procedures etc) can take a while, even if it does not change technical content.

Otherwise, minor nitpick, which NIST insists on correcting: FIPS 140-x modules should not be called "certified", rather "validated". Even if there's a certificate issued in the end, the term is validation to avoid implying NIST endorses a module (somewhat related to `CYA' described in another blog entry).

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..