Re: FIPS certification document for OpenSsl
With more than one user on the machine there are a lot of potential "out of
band" ways to subvert the crypto.
Timing attacks, /tmp races, swap space attacks or just plain hacks and
attaching a debugger to the running process.
With this restriction the risks from most attacks which can't be dealt with
within the crypto. module disappear.
Peter
From: "Kyle Hamilton" <[EMAIL PROTECTED]>
To: openssl-dev@openssl.org
Date: 08/21/2008 02:19 AM
Subject:Re: FIPS certification document for OpenSsl
On Tue, Aug 19, 2008 at 5:10 PM, Steve Marquess
<[EMAIL PROTECTED]> wrote:
>> Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE
>> RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your
>> UNIX machine down to single-user mode during the build process. It
>> probably would not hurt to write down everything that you do in a
>> timestamped log so that you can prove that you have followed the
>> security policy.
>
> What he said -- and a good suggestion about the log. Though the "single
> user mode" restriction is intended to apply to runtime operation of the
> module, not necessarily just the module installation (creation). That
> restriction is in every validation that I've read for software on a
> general purpose computer. How can that be reconciled with the way such
> software is actually used? A good question, and one that I can't answer
> other than to note that the single user restriction is not unique to the
> OpenSSL FIPS Object Module; in years past I have pursued and been given
> multiple explanations, some quite elaborate, that I just don't get.
The best conjecture I've come up with: Relying on operating system
restrictions to protect the sanctity of the module's security boundary
effectively moves one of the most important functions of the module's
packaging outside the control of the module. For a chip, you can say
"it's inherent that the chip's pins are the only way to interact
across the boundary." If you don't have that inherent quality, then
without evidence to the contrary it must be assumed that anything can
reach across that boundary.
I'm probably completely off-base, but like I said, it's the best
conjecture I've got.
I'd actually be interested in figuring out what the SELinux extensions
would do to help (essentially adding mandatory ACLs to the Linux
kernel), but I don't have the cash to pony up for any kind of
evaluation or validation attempt for it. :)
-Kyle H
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: FIPS certification document for OpenSsl
Prashant Kumar wrote: Hello All, Where can I find the documentation for OpenSsl FIPS certification ? Any help is appreciated. See http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#918 and http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS certification document for OpenSsl
Kyle Hamilton wrote: The best conjecture I've come up with: Relying on operating system restrictions to protect the sanctity of the module's security boundary effectively moves one of the most important functions of the module's packaging outside the control of the module. For a chip, you can say "it's inherent that the chip's pins are the only way to interact across the boundary." If you don't have that inherent quality, then without evidence to the contrary it must be assumed that anything can reach across that boundary. I'm probably completely off-base, but like I said, it's the best conjecture I've got. The most coherent explanation I've seen comes right out of the CMVP Implementation Guidance (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf), section 6.1: "Background Historically, for a FIPS 140-1 and FIPS 140-2 validated software cryptographic module on a server to meet the single user requirement of Security Level 1, the server had to be configured so that only one user at a time could access the server. This meant configuring the server Operating System (OS) so that only a single user at a time could execute processes (including cryptographic processes) on the server. Consequently, servers were not being used as intended. Question/Problem AS06.04 states: "(Level 1 Only) The operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded)". What is the definition of concurrent operators in this context? Specifically, may Level 1 software modules be implemented on a server and achieve FIPS 140-2 validation? (Note: this question is also applicable to VPN, firewalls, etc.) Resolution Software cryptographic modules implemented in client/server architecture are intended to be used on both the client and the server. The cryptographic module will be used to provide cryptographic functions to the client and server applications. 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." That still doesn't make a lot of sense to me from a technical perspective, but it does seem to say that validated modules can be used on what we would consider multi-user, multi-tasking systems. Start asking about threading, forking, multiple cores, etc., though, and you start getting some odd responses. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS certification document for OpenSsl
On Tue, Aug 19, 2008 at 5:10 PM, Steve Marquess <[EMAIL PROTECTED]> wrote: >> Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE >> RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your >> UNIX machine down to single-user mode during the build process. It >> probably would not hurt to write down everything that you do in a >> timestamped log so that you can prove that you have followed the >> security policy. > > What he said -- and a good suggestion about the log. Though the "single > user mode" restriction is intended to apply to runtime operation of the > module, not necessarily just the module installation (creation). That > restriction is in every validation that I've read for software on a > general purpose computer. How can that be reconciled with the way such > software is actually used? A good question, and one that I can't answer > other than to note that the single user restriction is not unique to the > OpenSSL FIPS Object Module; in years past I have pursued and been given > multiple explanations, some quite elaborate, that I just don't get. The best conjecture I've come up with: Relying on operating system restrictions to protect the sanctity of the module's security boundary effectively moves one of the most important functions of the module's packaging outside the control of the module. For a chip, you can say "it's inherent that the chip's pins are the only way to interact across the boundary." If you don't have that inherent quality, then without evidence to the contrary it must be assumed that anything can reach across that boundary. I'm probably completely off-base, but like I said, it's the best conjecture I've got. I'd actually be interested in figuring out what the SELinux extensions would do to help (essentially adding mandatory ACLs to the Linux kernel), but I don't have the cash to pony up for any kind of evaluation or validation attempt for it. :) -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS certification document for OpenSsl
Kyle Hamilton wrote: > It's FIPS validation, not certification. (Not that I'm entirely sure > what the difference is, because when a validation is completed a > certificate is issued, but I've been corrected enough times by the > reps from the Open Source Software Institute that I don't dare call > it anything else. :)) ...and that comes from the feedback I received from CMVP outsiders over five years or so that finally left me flinching whenever I heard the "C" word. There is a difference that was explained to me more than once but I'll confess it escapes me now. > > Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE > RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your > UNIX machine down to single-user mode during the build process. It > probably would not hurt to write down everything that you do in a > timestamped log so that you can prove that you have followed the > security policy. What he said -- and a good suggestion about the log. Though the "single user mode" restriction is intended to apply to runtime operation of the module, not necessarily just the module installation (creation). That restriction is in every validation that I've read for software on a general purpose computer. How can that be reconciled with the way such software is actually used? A good question, and one that I can't answer other than to note that the single user restriction is not unique to the OpenSSL FIPS Object Module; in years past I have pursued and been given multiple explanations, some quite elaborate, that I just don't get. -Steve M. -- Steve Marquess Open Source Software institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS certification document for OpenSsl
It's FIPS validation, not certification. (Not that I'm entirely sure what the difference is, because when a validation is completed a certificate is issued, but I've been corrected enough times by the reps from the Open Source Software Institute that I don't dare call it anything else. :)) fips-1.2.0 has not completed the validation process, so the documentation does not exist. fips-1.1.2 has been validated with certificate 918. fips-1.1.1 validation is revoked, but was validated with certificate 733. (Interestingly, the csrc.nist.gov site doesn't show it as being revoked, but it is -- I expect this will be fixed in the near future) fips-1.0 is not available, but was validated with certificate 642. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm is the official list, and has links to both the certificates and the security policies. Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your UNIX machine down to single-user mode during the build process. It probably would not hurt to write down everything that you do in a timestamped log so that you can prove that you have followed the security policy. -Kyle H On Tue, Aug 19, 2008 at 11:02 AM, Prashant Kumar <[EMAIL PROTECTED]> wrote: > Hello All, > > Where can I find the documentation for OpenSsl FIPS certification ? > > Any help is appreciated. > > Regards, > Prashant. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
