Re: FIPS
Kyle Hamilton
expert, and it's entirely possible that I am misinterpreting something
that I read. If Steve M wants to weigh in and verify or debunk my
interpretation, I would not object! :)
The answer to your question is: there might be, but this is FAR beyond
the level where anyone other than a specialist will be able to help
you.
This can be done if (and only if) ALL of the following are true:
1) you can cobble up an environment where you create the fipscanister
using only unmodified sources into a binary that will load and run in
your monolithic environment, only using one of the four command lines
allowed by the Security Policy;
2) you can link the fipscanister.o file into your proprietary kernel,
including all its validation mechanisms (fips_premain.c);
3) you can port the OpenSSL code, 0.9.8j or later, into your proprietary ke=
rnel;
4) you can perform any steps necessary to configure 0.9.8j to realize
that the FIPS canister is there.
The security policy states only that the fipscanister.o must be
created in the manner detailed in the security policy, and
fips_premain.c must be compiled and linked in. Once it's created, you
can copy it anywhere, you can do anything with it, as long as you
don't violate the process of creation. (the process of creation
includes the embedding of the keyed MAC into the fipscanister.o
library.) You also cannot edit fips_premain.c, and your build
environment must include the fipscanister.o.sha1 and
fips_premain.c.sha1 files.
More notably, the security policy does NOT state that you must use the
provided fipsld script to link. As long as all the steps performed by
the fipsld script are performed, then you will be able to use
FIPS_mode_set() from within your monolithic kernel.
At least it sounds like you're not using shared libraries. This makes
things MUCH less difficult for you.
However, it is important to recognize that fipsld does everything it
can to set fips_premain.c to run before the main() entry point. Your
environment cannot allow for that -- but you still must set it up so
that FINGERPRINT_premain() runs before the first invocation to
FIPS_mode_set(). This should be done as early in your startup process
as possible, but if you want to make it possible to figure out what it
might complain about you MUST do it *AFTER* you initialize stdio (it
prints diagnostics to stderr).
Also, once your application is in FIPS mode, absolutely no other
source of cryptographic provision (no sources of random number
generation, no sources of hash algorithms, no sources of symmetric
cryptography, no sources of asymmetric cryptography) may be used*.
Once FIPS_mode_set() is called, OpenSSL will enforce this as relates
to calls into the library itself. However, it's your responsibility
to make sure that no other crypto implementations exist in your code.
Good luck!
-Kyle H
*: You actually can use other FIPS-validated modules to provide
cryptographic services to your application, but if you want to move
key data from one module to another you must first export it, with
encryption, from the one module that has it -- and then import it into
the other module and only then decrypt it. With OpenSSL, no
key-storage facilities are present, so you don't have much to worry
about on this score -- just remember that FIPS mandates that any
key-storage facilities only release their private and symmetric keys
once they've been encrypted.
2009/2/26 smitha daggubati <smith...@gmail.com>:
> Hello all,
> I am going through the FIPS userguide and security policy documents and h=
ave a few questions.
> We have a proprietary kernel where we already have ported the openssl cod=
e. Our proprietary kernel is a monolithic kernel and to port the openssl li=
brary we had to modify the openssl code. A simple example of the modificati=
ons we had to do was to replace "include stdio.h" with our specific files. =
There were other modifications as well but all were tailored with getting t=
he openssl sources to complie as part of our kernel and not any with the ge=
neral ssl code as such.
>
> Now we have plans to make our openssl FIPS Capable.=C2=A0 Going through t=
he Userguide and security doc looks like there are specific steps that need=
to be followed
> for
> =C2=A0a) compiling
> =C2=A0b) linking
>
> I can think of getting the fipscanister .o by following the exact compila=
tion steps mentioned in the userguide and then point my modified ssl source=
s to use the above fipscanister.o.(I am not even sure that this is possible=
without modifications but lets assume it is for now)
>
> =C2=A0I am not sure of the linking step though because as i said ealrier =
we have a monolithic kernel that means i cannot use the fipsld uility. Also=
it being a monolithic kernel there is no seperation between the applicatio=
n and the fipscanister library.
> Is there any way i can make my implementaion of openssl FIPS capable and =
FIPS compliant ?
>
> thanks for your time
>
> smitha
>
>
>
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Carl Young
> From: "Kyle Hamilton" <aero...@gmail.com>
> To: "openssl-users" <openss...@openssl.org>
> Sent: Friday, February 27, 2009 1:14 AM
> Subject: Re: FIPS
>
> Take everything I say here with a grain of salt: I'm not a FIPS
> expert, and it's entirely possible that I am misinterpreting something
> that I read. If Steve M wants to weigh in and verify or debunk my
> interpretation, I would not object! :)
>
> <snip>
>
> *: You actually can use other FIPS-validated modules to provide
> cryptographic services to your application, but if you want to move
> key data from one module to another you must first export it, with
> encryption, from the one module that has it -- and then import it into
> the other module and only then decrypt it. With OpenSSL, no
> key-storage facilities are present, so you don't have much to worry
> about on this score -- just remember that FIPS mandates that any
> key-storage facilities only release their private and symmetric keys
> once they've been encrypted.
Kyle,
Sorry to butt in on this thread. That was an excellent explanation, thanks.
Where, in FIPS140-2, does it mandate this level of key protection for
security level 1 or 2? Or, are you talking about the envelope of the process
using the crypto module rather than the crypto module envelope? NIST SP
800-57 has recommendations, but I couldn't see this in 140-2.
Thanks,
Carl
Steve Marquess
> The answer to your question is: there might be, but this is FAR
> beyond the level where anyone other than a specialist will be able to
> help you.
How true. I've hesitated to weigh in on this thread because of the
complications that make my head hurt.
> This can be done if (and only if) ALL of the following are true: 1)
> you can cobble up an environment where you create the fipscanister
> using only unmodified sources into a binary that will load and run in
> your monolithic environment, only using one of the four command
> lines allowed by the Security Policy; 2) you can link the
> fipscanister.o file into your proprietary kernel, including all its
> validation mechanisms (fips_premain.c); 3) you can port the OpenSSL
> code, 0.9.8j or later, into your proprietary kernel; 4) you can
> perform any steps necessary to configure 0.9.8j to realize that the
> FIPS canister is there.
>
> The security policy states only that the fipscanister.o must be
> created in the manner detailed in the security policy, and
> fips_premain.c must be compiled and linked in. Once it's created,
> you can copy it anywhere, you can do anything with it, as long as you
> don't violate the process of creation. (the process of creation
> includes the embedding of the keyed MAC into the fipscanister.o
> library.) You also cannot edit fips_premain.c, and your build
> environment must include the fipscanister.o.sha1 and
> fips_premain.c.sha1 files.
A good point. Once you have properly embedded fipscanister.o in an
application you can treat that application just like any other
software. A deployed (installed) validated module is both a thing (the
shared library or special object module in this case) and an
installation process, both of which are constrained by a set of rules
(the Security Policy). The installation process for most validated
products is typically "run setup.exe" or "copy the file(s) from the
distribution CD". In our case the installation process is more
involved. The first part of that installation process which creates
fipscanister.o is a push-button process with little room for creative
license -- you untar the one true tarball, ./config fips, make. The
part of the installation process that takes that fipscanister.o and
incorporates it into an application is *slightly* less constrained.
> More notably, the security policy does NOT state that you must use
> the provided fipsld script to link. As long as all the steps
> performed by the fipsld script are performed, then you will be able
> to use FIPS_mode_set() from within your monolithic kernel.
Yes, the fipsld script proper is not required (for the Windows platform
it isn't used at all). However, the two step linking operation that
fipsld performs is required. In this sense the cryptographic module
boundary at the point where fipscanister.o has been created consists not
only of that file but also the ancillary files fipscanister.o.sha1,
fips_premain.c, and fips_premain.c.sha1 files.
So, can the v1.2 fipscanister.o be legitimately used in a linux kernel
module? Theoretically I think it *may* be possible in a technical
sense, though I haven't written any kernel modules myself. Start with
fipscanister.o and the ancillary files, and roll your own fipsld
equivalent that performs the two step link. However, the kernel
contains other crypto that isn't validated (and isn't even from
openssl), so it's an interesting philosophical question to say under
what circumstances what parts of that Linux system can claim to be FIPS
validated. The usual block diagrams included in FIPS validations show
the operating system as one monolithic block, and kernel modules could
legitimately be considered to be part of the core O/S and hence not part
of any userspace application at all.
So, if the reason for adding the crypto to a kernel module was to
support a userspace application one could speculate that the application
could be FIPS validated independently of that kernel and hence that
kernel module. If the reason was to claim FIPS validation for the
entire kernel then you have a much bigger problem because of the other
existing crypto in the kernel.
At any rate I think that's a scripture question that would have to be
interpreted by the priesthood (the CMVP). It's certainly above my pay
grade.
-Steve M.
--
Steve Marquess
Open Source Software institute
marq...@oss-institute.org
smitha daggubati
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
thank you all for your time
On Fri, Feb 27, 2009 at 8:55 PM, Steve Marquess
<marq...@oss-institute.org>wrote:
--000e0cd5d022371c7f0463eb2b84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
thank you all for your time<br><br><div class=3D"gmail_quote">On Fri, Feb 2=
7, 2009 at 8:55 PM, Steve Marquess <span dir=3D"ltr"><<a href=3D"mailto:=
marq...@oss-institute.org">marq...@oss-institute.org</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"Ih2=
E3d">Kyle Hamilton wrote:<br>
> The answer to your question is: there might be, but this is FAR<br>
> beyond the level where anyone other than a specialist will be able to<=
br>
> help you.<br>
<br>
</div>How true. =A0I've hesitated to weigh in on this thread because of=
the<br>
complications that make my head hurt.<br>
<div class=3D"Ih2E3d"><br>
> This can be done if (and only if) ALL of the following are true: 1)<br=
>
> you can cobble up an environment where you create the fipscanister<br>
> using only unmodified sources into a binary that will load and run in<=
br>
> =A0your monolithic environment, only using one of the four command<br>
> lines allowed by the Security Policy; 2) you can link the<br>
> fipscanister.o file into your proprietary kernel, including all its<br=
>
> validation mechanisms (fips_premain.c); 3) you can port the OpenSSL<br=
>
> code, 0.9.8j or later, into your proprietary kernel; 4) you can<br>
> perform any steps necessary to configure 0.9.8j to realize that the<br=
>
> FIPS canister is there.<br>
><br>
> The security policy states only that the fipscanister.o must be<br>
> created in the manner detailed in the security policy, and<br>
> fips_premain.c must be compiled and linked in. =A0Once it's create=
d,<br>
> you can copy it anywhere, you can do anything with it, as long as you<=
br>
> =A0don't violate the process of creation. =A0(the process of creat=
ion<br>
> includes the embedding of the keyed MAC into the fipscanister.o<br>
> library.) =A0You also cannot edit fips_premain.c, and your build<br>
> environment must include the fipscanister.o.sha1 and<br>
> fips_premain.c.sha1 files.<br>
<br>
</div>A good point. =A0Once you have properly embedded fipscanister.o in an=
<br>
application you can treat that application just like any other<br>
software. =A0A deployed (installed) validated module is both a thing (the<b=
r>
shared library or special object module in this case) and an<br>
installation process, both of which are constrained by a set of rules<br>
(the Security Policy). =A0The installation process for most validated<br>
products is typically "run setup.exe" or "copy the file(s) f=
rom the<br>
distribution CD". =A0In our case the installation process is more<br>
involved. =A0The first part of that installation process which creates<br>
fipscanister.o is a push-button process with little room for creative<br>
license -- you untar the one true tarball, ./config fips, make. =A0The<br>
part of the installation process that takes that fipscanister.o and<br>
incorporates it into an application is *slightly* less constrained.<br>
<div class=3D"Ih2E3d"><br>
> More notably, the security policy does NOT state that you must use<br>
> the provided fipsld script to link. =A0As long as all the steps<br>
> performed by the fipsld script are performed, then you will be able<br=
>
> to use FIPS_mode_set() from within your monolithic kernel.<br>
<br>
</div>Yes, the fipsld script proper is not required (for the Windows platfo=
rm<br>
it isn't used at all). =A0However, the two step linking operation that<=
br>
fipsld performs is required. =A0In this sense the cryptographic module<br>
boundary at the point where fipscanister.o has been created consists not<br=
>
only of that file but also the ancillary files fipscanister.o.sha1,<br>
fips_premain.c, and fips_premain.c.sha1 files.<br>
<br>
So, can the v1.2 fipscanister.o be legitimately used in a linux kernel<br>
module? =A0Theoretically I think it *may* be possible in a technical<br>
sense, though I haven't written any kernel modules myself. =A0Start wit=
h<br>
fipscanister.o and the ancillary files, and roll your own fipsld<br>
equivalent that performs the two step link. =A0However, the kernel<br>
contains other crypto that isn't validated (and isn't even from<br>
openssl), so it's an interesting philosophical question to say under<br=
>
what circumstances what parts of that Linux system can claim to be FIPS<br>
validated. =A0The usual block diagrams included in FIPS validations show<br=
>
the operating system as one monolithic block, and kernel modules could<br>
legitimately be considered to be part of the core O/S and hence not part<br=
>
of any userspace application at all.<br>
<br>
So, if the reason for adding the crypto to a kernel module was to<br>
support a userspace application one could speculate that the application<br=
>
could be FIPS validated independently of that kernel and hence that<br>
kernel module. =A0If the reason was to claim FIPS validation for the<br>
entire kernel then you have a much bigger problem because of the other<br>
existing crypto in the kernel.<br>
<br>
At any rate I think that's a scripture question that would have to be<b=
r>
interpreted by the priesthood (the CMVP). =A0It's certainly above my pa=
y<br>
grade.<br>
<br>
-Steve M.<br>
<font color=3D"#888888"><br>
--<br>
Steve Marquess<br>
Open Source Software institute<br>
<a href=3D"mailto:marq...@oss-institute.org">marq...@oss-institute.org</a=
><br>
</font><div><div></div><div class=3D"Wj3C7c"><br>
______________________________________________________________________<br>
OpenSSL Project =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 <a href=3D"http://www.openssl.org" target=3D"_blank">http://www.openss=
l.org</a><br>
User Support Mailing List =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<a href=3D=
"mailto:openss...@openssl.org">openss...@openssl.org</a><br>
Automated List Manager =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
<a href=3D"mailto:majo...@openssl.org">majo...@openssl.org</a><br>
</div></div></blockquote></div><br>
--000e0cd5d022371c7f0463eb2b84--
Kyle Hamilton
> Kyle Hamilton wrote:
>> The answer to your question is: there might be, but this is FAR
>> beyond the level where anyone other than a specialist will be able to
>> help you.
>
> complications that make my head hurt.
I'm glad I'm not the only one who had to pull out the ibuprofen. :P
>> More notably, the security policy does NOT state that you must use
>> the provided fipsld script to link. =C2=A0As long as all the steps
>> performed by the fipsld script are performed, then you will be able
>> to use FIPS_mode_set() from within your monolithic kernel.
>
> Yes, the fipsld script proper is not required (for the Windows platform
> it isn't used at all). =C2=A0However, the two step linking operation that
> fipsld performs is required. =C2=A0In this sense the cryptographic module
> boundary at the point where fipscanister.o has been created consists not
> only of that file but also the ancillary files fipscanister.o.sha1,
> fips_premain.c, and fips_premain.c.sha1 files.
Er... my biggest question actually wasn't answered here. The two-step
linking process involves the creation of the library memory
image/memory segment (which is the entire reason for the
fips_premain.c requirement, I think?), but is it required that the
premain function actually be called before the entry point into the
program itself? If the answer to this is "yes", then it's not
possible -- the kernel needs to initialize itself and its data
structures before it can run any other code. If it's simply a
requirement that the premain code be executed before the library has
any opportunity to run any other initialization code, then it might be
possible.
It *would*, however, be a lot easier if it were a kernel module.
Aside from getting around the licensing issues (it'd taint the kernel,
but it wouldn't require GPL compatibility), it would also be possible
to run the premain code on load.
> So, can the v1.2 fipscanister.o be legitimately used in a linux kernel
> module? =C2=A0Theoretically I think it *may* be possible in a technical
> sense, though I haven't written any kernel modules myself. =C2=A0Start wi=
th
> fipscanister.o and the ancillary files, and roll your own fipsld
> equivalent that performs the two step link. =C2=A0However, the kernel
> contains other crypto that isn't validated (and isn't even from
> openssl), so it's an interesting philosophical question to say under
> what circumstances what parts of that Linux system can claim to be FIPS
> validated. =C2=A0The usual block diagrams included in FIPS validations sh=
ow
> the operating system as one monolithic block, and kernel modules could
> legitimately be considered to be part of the core O/S and hence not part
> of any userspace application at all.
Legally speaking (and this is primarily coming from the Free Software
Foundation's pages), the license of OpenSSL prevents the distribution
of a GPL'd software that links directly to it (in a monolithic sense),
unless the copyright owner of the GPL-licensed software adds an
explicit exemption for OpenSSL's "obnoxious BSD advertising clause"
requirement. This legal issue essentially makes it a non-starter in
the monolithic kernel concept currently discussed.
> So, if the reason for adding the crypto to a kernel module was to
> support a userspace application one could speculate that the application
> could be FIPS validated independently of that kernel and hence that
> kernel module. =C2=A0If the reason was to claim FIPS validation for the
> entire kernel then you have a much bigger problem because of the other
> existing crypto in the kernel.
This would be a VERY interesting mechanism to bring into the mainline
Linux kernel -- the ability to set a sysparm so that any call to any
of the crypto implementations will be redirected to the FIPS module
imported from OpenSSL.
However, there's an additional quandary in this concept: the FIPS
validation for OpenSSL is explicitly for a "single-user system". This
specifically means that any system with multiple users is in violation
of the security policy, and thus not running in a validated mode.
> At any rate I think that's a scripture question that would have to be
> interpreted by the priesthood (the CMVP). =C2=A0It's certainly above my p=
ay
> grade.
>
> -Steve M.
The CMVP was never set up to handle people wanting to do weird stuff
with cryptographic modules for which the source code is available.
Then again, it was never set up to handle open source in any manner
anyway.
The simplest answer I can come up with is: ugh. No. Just... no.
-Kyle H
Steve Marquess
> > ... Yes, the fipsld script proper is not required (for the Windows
> > platform it isn't used at all). However, the two step linking
> > operation that fipsld performs is required. In this sense the
> > cryptographic module boundary at the point where fipscanister.o has
> > been created consists not only of that file but also the ancillary
> > files fipscanister.o.sha1, fips_premain.c, and fips_premain.c.sha1
> > files.
>
> Er... my biggest question actually wasn't answered here. The
> two-step linking process involves the creation of the library memory
> image/memory segment (which is the entire reason for the
> fips_premain.c requirement, I think?), but is it required that the
> premain function actually be called before the entry point into the
> program itself? If the answer to this is "yes", then it's not
> possible -- the kernel needs to initialize itself and its data
> structures before it can run any other code. If it's simply a
> requirement that the premain code be executed before the library has
> any opportunity to run any other initialization code, then it might
> be possible.
There is no policy requirement to call FINGERPRINT_premain() at any
particular point prior to FIPS_mode_set(). There may be practical
problems, of course, if the integrity check is sabotaged.
> > ...
>
> Legally speaking (and this is primarily coming from the Free Software
> Foundation's pages), the license of OpenSSL prevents the
> distribution of a GPL'd software that links directly to it (in a
> monolithic sense), unless the copyright owner of the GPL-licensed
> software adds an explicit exemption for OpenSSL's "obnoxious BSD
> advertising clause" requirement. This legal issue essentially makes
> it a non-starter in the monolithic kernel concept currently
> discussed.
Good point about the licensing implications, I didn't address that topic
at all.
> > So, if the reason for adding the crypto to a kernel module was to
> > support a userspace application one could speculate that the
> > application could be FIPS validated independently of that kernel
> > and hence that kernel module. If the reason was to claim FIPS
> > validation for the entire kernel then you have a much bigger
> > problem because of the other existing crypto in the kernel.
>
> This would be a VERY interesting mechanism to bring into the mainline
> Linux kernel -- the ability to set a sysparm so that any call to any
> of the crypto implementations will be redirected to the FIPS module
> imported from OpenSSL.
I've had several discussions over the past few years with interested
parties about FIPS validation for the kernel crypto (not using OpenSSL,
but validating the current crypto). I do think it would be possible.
So far the requisite interest level isn't there to make it happen.
> However, there's an additional quandary in this concept: the FIPS
> validation for OpenSSL is explicitly for a "single-user system". This
> specifically means that any system with multiple users is in
> violation of the security policy, and thus not running in a validated
> mode.
Eh, the "single user" business is an odd one. It doesn't (depending on
who in the CMPV you ask, and when!) necessarily mean "user" in the sense
us code hackers think. Note for instance the reference in section 6.1
of the IG (Implementation Guidance): "... When a crypto module is
implemented in a server environment, the server application is the user
of the cryptographic module. The server application makes the calls to
the cryptographic module. Therefore, the server application is the
single user of the cryptographic module, even when the server
application is serving multiple clients."
A little reflection shows the absurdity of the notions that a) FIPS
validated modules can only be run on "single user mode" systems (in the
usual sense), b) the U.S. government mandates the use of only FIPS
validated crypto on all government systems, and c) nowadays crypto is
everywhere, in the most common of applications.
The fact is that the CMVP has never coherently reconciled the AS06.04
requirement with respect to modern general purpose multitasking, demand
paged virtual memory computers as actually used in the real world. I'm
working through that very issue on a pending validation right now, but I
don't expect a resolution beyond that one module.
> ...
>
> The CMVP was never set up to handle people wanting to do weird stuff
> with cryptographic modules for which the source code is available.
> Then again, it was never set up to handle open source in any manner
> anyway.
Actually it's arguably not really set up to deal with software of *any*
kind on general purpose computers, open or closed source. FIPS 140
originated at a time when cryptography was done in dedicated hardware
devices. It's a pretty strained fit to today's computing environment.
FIPS 140-3 is supposed to less of a mismatch.
-Steve M.
--
Steve Marquess
Open Source Software institute
marq...@oss-institute.org
______________________________________________________________________
rajan chittil
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I have some doudt regarding fips capbable openssl... If in my system , one
of the my application gets into fips mode .. whether that going to effect
other application to use fips enabled cryptography alogorithm.. .I have seen
in some fips enabled library, if one application gets into fips mode , whole
library will be in
fips mode and all the application in the system will be in fips mode. is
this true for openssl ? Is the fips enabled at system level or application
.
Thanks
Rajan
On Sun, Mar 1, 2009 at 4:22 AM, Steve Marquess
<marq...@oss-institute.org>wrote:
--000e0cd14eeed36f0e04641d0464
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>I have some doudt=A0 regarding fips capbable openssl... If in my syste=
m , one of the my=A0application=A0gets into fips mode .. whether=A0that=A0g=
oing to=A0effect other application=A0to use fips enabled cryptography alogo=
rithm..=A0.I have seen in some fips enabled=A0library, if=A0one application=
gets into fips mode ,=A0whole library will=A0be in=A0</div>
<div>fips mode and all the application in the system will be in fips mode. =
is this true for openssl ? Is the fips enabled at system level or applicati=
on =A0.</div>
<div>=A0</div>
<div>Thanks</div>
<div>Rajan<br><br></div>
<div class=3D"gmail_quote">On Sun, Mar 1, 2009 at 4:22 AM, Steve Marquess <=
span dir=3D"ltr"><<a href=3D"mailto:marq...@oss-institute.org" target=
=3D"_blank">marq...@oss-institute.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Kyle Hamilton wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> ... Yes, the fipsld script =
proper is not required (for the Windows=20
<div><br>> platform it isn't used at all). =A0However, the two step =
linking<br>> operation that fipsld performs is required. =A0In this sens=
e the<br>> cryptographic module boundary at the point where fipscanister=
.o has<br>
> =A0been created consists not only of that file but also the ancillary<=
br>> =A0files fipscanister.o.sha1, fips_premain.c, and fips_premain.c.sh=
a1<br>> =A0files.<br><br>=A0Er... my biggest question actually wasn'=
t answered here. =A0The<br>
=A0two-step linking process involves the creation of the library memory<br>=
=A0image/memory segment (which is the entire reason for the<br>=A0fips_prem=
ain.c requirement, I think?), but is it required that the<br>=A0premain fun=
ction actually be called before the entry point into the<br>
=A0program itself? =A0If the answer to this is "yes", then it'=
;s not<br>=A0possible -- the kernel needs to initialize itself and its data=
<br>=A0structures before it can run any other code. =A0If it's simply a=
<br>=A0requirement that the premain code be executed before the library has=
<br>
=A0any opportunity to run any other initialization code, then it might<br>=
=A0be possible.<br></div></blockquote><br>There is no policy requirement to=
call FINGERPRINT_premain() at any<br>particular point prior to FIPS_mode_s=
et(). =A0There may be practical<br>
problems, of course, if the integrity check is sabotaged.<br><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> ...=20
<div><br><br>=A0Legally speaking (and this is primarily coming from the Fre=
e Software<br>=A0Foundation's pages), the license of OpenSSL prevents t=
he<br>=A0distribution of a GPL'd software that links directly to it (in=
a<br>
=A0monolithic sense), unless the copyright owner of the GPL-licensed<br>=A0=
software adds an explicit exemption for OpenSSL's "obnoxious BSD<b=
r>=A0advertising clause" requirement. =A0This legal issue essentially =
makes<br>
=A0it a non-starter in the monolithic kernel concept currently<br>=A0discus=
sed.<br></div></blockquote><br>Good point about the licensing implications,=
I didn't address that topic at all.=20
<div><br><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> So, if the reason for addin=
g the crypto to a kernel module was to<br>> support a userspace applicat=
ion one could speculate that the<br>
> application could be FIPS validated independently of that kernel<br>&g=
t; and hence that kernel module. =A0If the reason was to claim FIPS<br>>=
validation for the entire kernel then you have a much bigger<br>> probl=
em because of the other existing crypto in the kernel.<br>
<br>=A0This would be a VERY interesting mechanism to bring into the mainlin=
e<br>=A0Linux kernel -- the ability to set a sysparm so that any call to an=
y<br>=A0of the crypto implementations will be redirected to the FIPS module=
<br>
=A0imported from OpenSSL.<br></blockquote><br></div>I've had several di=
scussions over the past few years with interested parties about FIPS valida=
tion for the kernel crypto (not using OpenSSL, but validating the current c=
rypto). =A0I do think it would be possible. =A0So far the requisite interes=
t level isn't there to make it happen.=20
<div><br><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">=A0However, there's an addit=
ional quandary in this concept: the FIPS<br>=A0validation for OpenSSL is ex=
plicitly for a "single-user system". This<br>
=A0specifically means that any system with multiple users is in<br>=A0viola=
tion of the security policy, and thus not running in a validated<br>=A0mode=
.<br></blockquote><br></div>Eh, the "single user" business is an =
odd one. =A0It doesn't (depending on who in the CMPV you ask, and when!=
) necessarily mean "user" in the sense us code hackers think. =A0=
Note for instance the reference in section 6.1 of the IG (Implementation Gu=
idance): "... When a crypto module is implemented in a server environm=
ent, the server application is the user of the cryptographic module. The se=
rver application makes the calls to the cryptographic module. Therefore, th=
e server application is the single user of the cryptographic module, even w=
hen the server application is serving multiple clients."<br>
<br>A little reflection shows the absurdity of the notions that a) FIPS val=
idated modules can only be run on "single user mode" systems (in =
the usual sense), b) the U.S. government mandates the use of only FIPS vali=
dated crypto on all government systems, and c) nowadays crypto is everywher=
e, in the most common of applications.<br>
<br>The fact is that the CMVP has never coherently reconciled the AS06.04 r=
equirement with respect to modern general purpose multitasking, demand page=
d virtual memory computers as actually used in the real world. =A0I'm w=
orking through that very issue on a pending validation right now, but I don=
't expect a resolution beyond that one module.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">=A0...=20
<div><br><br>=A0The CMVP was never set up to handle people wanting to do we=
ird stuff<br>=A0with cryptographic modules for which the source code is ava=
ilable.<br>=A0Then again, it was never set up to handle open source in any =
manner<br>
=A0anyway.<br></div></blockquote><br>Actually it's arguably not really =
set up to deal with software of *any* kind on general purpose computers, op=
en or closed source. =A0FIPS 140 originated at a time when cryptography was=
done in dedicated hardware devices. =A0It's a pretty strained fit to t=
oday's computing environment. =A0FIPS 140-3 is supposed to less of a mi=
smatch.=20
<div><br><br>-Steve M.<br><br>-- <br>Steve Marquess<br>Open Source Software=
institute<br><a href=3D"mailto:marq...@oss-institute.org" target=3D"_blan=
k">marq...@oss-institute.org</a><br><br>__________________________________=
____________________________________<br>
</div>
<div>
<div></div>
<div>OpenSSL Project =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 <a href=3D"http://www.openssl.org/" target=3D"_blank">http://ww=
w.openssl.org</a><br>User Support Mailing List =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0<a href=3D"mailto:openss...@openssl.org" target=3D"_blank">o=
penssl...@openssl.org</a><br>
Automated List Manager =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
<a href=3D"mailto:majo...@openssl.org" target=3D"_blank">majordomo@openss=
l.org</a><br></div></div></blockquote></div><br>
--000e0cd14eeed36f0e04641d0464--
David Schwartz
> I have some doudt regarding fips capbable openssl... If in my system ,
> one of the my application gets into fips mode .. whether that going to
> effect other application to use fips enabled cryptography alogorithm..
No.
> I have seen in some fips enabled library, if one application gets into
> fips mode , whole library will be in
> fips mode and all the application in the system will be in fips mode.
I don't believe this. I don't see how any system could do this and still
meet the various FIPS requirements for integrity checking and isolation.
> is this true for openssl ? Is the fips enabled at system level or
application .
Your notion of "system level" seems incoherent to me. It would be an
absolute disaster if one user could put another user's applications into
FIPS mode and stop them from interoperating with, say, systems that used MD5
signatures (when the user who ran that program intended that to work).
Nobody would design such an obviously broken system.
DS
Steve Marquess
> ... .I have seen in some fips enabled library, if one application gets
> fips mode and all the application in the system will be in fips mode.
That would be a strange library.
> is this true for openssl ? Is the fips enabled at system level or
> application .
>
The OpenSSL FIPS Object Module v1.2 (fipscanister.o) is an object
module, i.e. static code. It remains entirely private to the process
that contains it, and so what that process does with it can't affect
other processes.
If you embed fipscanister.o in a shared library, as most will do and as
is done automatically when building a "FIPS capable" OpenSSL
distribution, then it behaves like a shared library. The read-only data
and code are shared by all applications on the system that map that
library. The private copies of writable data belong to the respective
processes that map and make calls to the library, and again what one
process does with the API has absolutely no effect on other processes.
That said...
At this point in time the people who worry about FIPS 140 validated
products at all generally think only in terms of achieving "buzzword
compliance" for specific applications. By "buzzword compliance" I mean
that in practice the emphasis is almost exclusively on establishing
paperwork compliance with policy requirements mandating acquisition of
validated products, in order to market (as a vendor) or procure (as a
program manager) a specific product. Considerations of actually
*running* said products in FIPS mode are generally very secondary or
absent. Likewise consideration of cryptography not singled out for
scrutiny as requiring FIPS validation (e.g. kernel crypto, well known
products using crypto in apparently incidental ways) is minimal. As an
exercise for the reader, take a poll of the ciphersites accepted by many
government and DoD web servers today which indicate that said servers
obviously can't be in FIPS mode. I've long been amused by the fact that
*none* of the HTTPS proxies I've seen that are proliferating throughout
the U.S. DoD enforce use of FIPS compatible ciphers. FIPS validation
for now is a paper chase, not an operational reality.
But, in anticipation of a future time when FIPS mode might become an
operational reality we designed the OpenSSL FIPS Object Module to
potentially support a system-wide global FIPS mode switch. If all the
applications on a system use a FIPS capable OpenSSL library, and if all
those applications use the OPENSSL_config() call, then FIPS mode could
be enabled for all such applications in one fell swoop by appropriate
options in the system-wide openssl_conf file. System vendors could also
ship the same binary code to all customers, with only those customers
desiring FIPS mode changing that global configuration to enable it.
That may happen someday, but for now it's just one application at a time.
-Steve M.
--
Steve Marquess
Open Source Software institute
marq...@oss-institute.org
______________________________________________________________________
Kyle Hamilton
machine operating in FIPS mode (especially, as I've mentioned
previously on this or another list, with Windows Server up to 2003 --
I have not yet tested 2008 or Vista) tends to prevent interoperability
with non-FIPS-validated systems.
In my opinion this is a rather stupid state of affairs, since it means
that the only way to get things to work together is to disable
FIPS-validated operation mode. It should be a priority for NIST and
the cryptographic vendors to figure out a way to steer the general
public toward the algorithms specified as acceptable by the FIPS
standards, even if they (the members of the general public) don't use
FIPS-validated components. (FIPS 140-2 only affects procurement and
theoretically use by the US Federal Government, but there is nothing
which precludes interoperability with non-FIPS-validated systems --
other than the fact that most non-FIPS-validated systems don't support
the algorithms specified by FIPS 140-2.)
OpenSSL appears to be almost unique in that it supports all of the
ciphersuites specified by FIPS even when not in FIPS mode. Thus,
products built with it can (given the appropriate cipher string)
interoperate with FIPS-validated implementations.
A question: Is there/should there be a "FIPSCOMPAT" or equivalent
string which can be added to the cipher string, to add all
FIPS-specified ciphers to the cipher list? (I would also suggest
"FIPS" as a standalone cipher string, which would only be valid if the
library were already running in FIPS-validated mode.)
-Kyle H
On Mon, Mar 2, 2009 at 4:13 AM, Steve Marquess
<marq...@oss-institute.org> wrote:
> rajan chittil wrote:
>>
>> ... .I have seen in some fips enabled library, if one application gets
>> into fips mode , whole library will be in fips mode and all the applicat=
ion
>> in the system will be in fips mode.
>
> That would be a strange library.
>
>> is this true for openssl ? Is the fips enabled at system level or
>> application =C2=A0.
>>
>
> The OpenSSL FIPS Object Module v1.2 (fipscanister.o) is an object module,
> i.e. static code. =C2=A0It remains entirely private to the process that c=
ontains
> it, and so what that process does with it can't affect other processes.
>
> If you embed fipscanister.o in a shared library, as most will do and as i=
s
> done automatically when building a "FIPS capable" OpenSSL distribution, t=
hen
> it behaves like a shared library. =C2=A0The read-only data and code are s=
hared by
> all applications on the system that map that library. =C2=A0The private c=
opies of
> writable data belong to the respective processes that map and make calls =
to
> the library, and again what one process does with the API has absolutely =
no
> effect on other processes.
>
> That said...
>
> At this point in time the people who worry about FIPS 140 validated produ=
cts
> at all generally think only in terms of achieving "buzzword compliance" f=
or
> specific applications. =C2=A0By "buzzword compliance" I mean that in prac=
tice the
> emphasis is almost exclusively on establishing paperwork compliance with
> policy requirements mandating acquisition of validated products, in order=
to
> market (as a vendor) or procure (as a program manager) a specific product=
.
> =C2=A0Considerations of actually *running* said products in FIPS mode are
> generally very secondary or absent. =C2=A0Likewise consideration of crypt=
ography
> not singled out for scrutiny as requiring FIPS validation (e.g. kernel
> crypto, well known products using crypto in apparently incidental ways) i=
s
> minimal. =C2=A0As an exercise for the reader, take a poll of the ciphersi=
tes
> accepted by many government and DoD web servers today which indicate that
> said servers obviously can't be in FIPS mode. =C2=A0I've long been amused=
by the
> fact that *none* of the HTTPS proxies I've seen that are proliferating
> throughout the U.S. DoD enforce use of FIPS compatible ciphers. =C2=A0FIP=
S
> validation for now is a paper chase, not an operational reality.
>
> But, in anticipation of a future time when FIPS mode might become an
> operational reality we designed the OpenSSL FIPS Object Module to
> potentially support a system-wide global FIPS mode switch. =C2=A0If all t=
he
> applications on a system use a FIPS capable OpenSSL library, and if all
> those applications use the OPENSSL_config() call, then FIPS mode could be
> enabled for all such applications in one fell swoop by appropriate option=
s
> in the system-wide openssl_conf file. =C2=A0System vendors could also shi=
p the
> same binary code to all customers, with only those customers desiring FIP=
S
> mode changing that global configuration to enable it.
>
> That may happen someday, but for now it's just one application at a time.
>
> -Steve M.
>
> --
> Steve Marquess
> Open Source Software institute
> marq...@oss-institute.org
>
> ______________________________________________________________________
> OpenSSL Project =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.openssl.=
org
> User Support Mailing List =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0opens...@openssl.org
> Automated List Manager =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 majo...@openssl.org
Dr. Stephen Henson
>
> A question: Is there/should there be a "FIPSCOMPAT" or equivalent
> string which can be added to the cipher string, to add all
> FIPS-specified ciphers to the cipher list? (I would also suggest
> "FIPS" as a standalone cipher string, which would only be valid if the
> library were already running in FIPS-validated mode.)
>
The set of FIPS comparible ciphersuites is represented by the string "FIPS".
In FIPS mode you cannot select any other ciphersuites: non FIPS ciphersuites
are disabled.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk