[openssl-users] FIPS: Common method executed in case of error
jonetsu at teksavvy.com
Tue Mar 10 13:28:41 UTC 2015
> From: "Steve Marquess" <marquess at openssl.com>
> Date: 03/10/15 08:56
Thanks for your reply.
> You're talking about a Level 2 validation (or higher)? You most
> definitely do *not* want to include the OS or applications in the
> "cryptographic module boundary" for Level 1.
It's a level 2. The behaviour of the unit as a whole is
validated. As an example amongst many, there will be no Linux
console prompt available in FIPS mode.
> I think you're going to be shocked at the cost (in time and money) to
> validate a hacked OpenSSL FIPS module, compared to using it as-is or a
> "change letter" update.
That brings a question. I'm currently using 1.0.1k with the 2.0
FIPS module for development purposes. This may seem a bit blunt,
but, is it possible at all to use 1.0.1k to benefit from the FIPS
validation ? Based on recent comments I would think not. Going
back to a pre-heartbleed version ? Is there any way to benefit
from the gained OpenSSL FIPS validation at all ?
> That's because the CMVP has introduced a number of new
> requirements since the current FIPS module was validated (in
> 2012), and any new validation will now need to satisfy
Again, is there any benefit to be gained from using a once
validated OpenSSL FIPS ? What would be the bugs fixed/ security
updates trade-off ?
> That means not only non-trivial code hacks unrelated to yours,
> but also a new paper shuffle for the "arm waving" (DTR)
> components of the validation process. The cost of the latter
> dwarfs the former; which is why we have not attempted a new
> validation ourselves.
Hmmm... If this goes through, would it be possible for OpenSSL to
benefit from any validation our unit can get ?
> But, that cost could be dwarfed in turn by that of a Level 2 or 3
> validation of a turnkey system including OS and apps.
Thanks again for your comments, much appreciated.
More information about the openssl-users