On 01/29/2014 07:16 PM, Nath, Satyajit wrote:
> Hi,
>
> While building the fips object module on our OS (FreeBSD 7.1 based)
> according to the instructions in
> http://www.openssl.org/docs/fips/UserGuide-2.0.pdf, we ran into a
> bug. We have things mostly working starting with
> http://www.openssl.org/source/openssl-fips-2.0.2.tar.gz. We can do
> an untar; make; make config to build the fips_canister.o and related
> pices.
>
> But there's a small bug we need to fix ... The bug is the one
> documented in http://rt.openssl.org/Ticket/Display.html?id=2440. ...
> /technically/ we'll be modifying the contents of what we extracted
> from the fips tar file, i.e. the integrity check best practice noted
> in section 4.1.2 of the user guide won't pass. ...
I'm going to give you a short answer and a long answer.
Short answer:
No, you can't change the contents of the source distribution tarball.
Not *any* change, for any reason, no matter how trivial. The Security
Policy is quite clear about that (Appendix B):
"The set of files specified in this tar file constitutes the complete
set of source files of this module. There shall be no additions,
deletions, or alterations of this set as used during module build."
Long answer:
The typical software developer finds the short answer very
unsatisfactory, to the point where statements like that in Appendix B
just don't register. For years I've found myself saying over and over
again "Yes, that is really what it means. Yes, I know it doesn't make
any sense but...". The more experienced the developer, the harder it is
for the unique FIPS 140-2 perspective to sink in.
With no disrespect intended towards any faith or beliefs, one technique
I find useful in understanding the FIPS 140-2 mindset is mapping to to
ecclesiastical concepts like "scripture", "dogma", and "exorcism" (or
"sanctification").
FIPS 140-2 has formal "scripture" (the FIPS 140-2 and subordinate FIPS
standards, the Implementation Guidance and Derived Test Results) and
also epistles from the "priesthood" (the CAVP and CMVP). That scripture
dates from long ago (when cryptography wasn't ubiquitous and was
implemented with discrete component electronics). It is confusing and
contradictory in places and has been creatively interpreted over the
years. As with most scripture you will find conflicting interpretations
from different parties. Only the high priesthood can make authoritative
pronouncements, and they're generally reluctant to directly address
earthly specifics.
The most fundamental dogmas of FIPS 140-2 are:
1) Cryptographic implementations not blessed by FIPS 140-2 validation
are entirely worthless, equivalent to plaintext ("evil", in other words).
2) The validation process (exorcism or sanctification, take your pick)
assures the purity of the cryptographic implementation ("module"). The
validation process has heavily stylized rituals that are largely
independent of the actual content of the implementation.
3) Preservation of that purity, by guarding against any change
whatsoever (corruption) is paramount. That sanctity is more important
than security, performance, or any practical considerations of actual use.
There is more but everything really revolves around these fundamental
dogmas. Understand those and you'll be able to answer most questions
about FIPS 140-2.
The software developer will immediately object that "everyone knows"
software must continually evolve to remain secure and relevant; a
perspective that has been the accepted consensus in the IT community for
a long time. The experienced software developer knows that all
non-trivial software has bugs, and continuing change is essential in the
constant arms race between attacker and defender.
FIPS 140-2 is a very different world. In that world we couldn't
implement the otherwise complete mitigation of the "Lucky 13" side
channel in the FIPS module. In that world our Dual EC DRBG passed the
ritual algorithm testing many times, with a fatal bug completely
preventing actual use. And so forth ... but thus has it ever been.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
