Re: FIPS 1.2 Security Policy issues
Thomas J. Hruska wrote: According to the FIPS 1.2 Security Policy, Appendix A, Platform 8 cannot be built as FIPS compliant because 'x84-64 asm' is a non-existent platform. There is no such thing as x84. It should say 'x86-64 asm'. Validation, from what I understand, only covers those platforms listed. Strictly-speaking, x86-64 asm is not able to be built as FIPS-compliant since it is not included in the list (despite supposedly being a tested platform). A comment on this statement: a validated *can* be generated from platforms not specifically listed (though generation of a validated module may not be possible on any such specific platform). According to the Implementation Guidance section G.5 a module may be vendor affirmed as validated if it is merely recompiled on a new platform. The CMVP provided the following statement which appeared in the first Security Policy (certificate #733): The OpenSSL FIPS Object Module, when generated from the identical unmodified source code, is Vendor Affirmed to be FIPS 1402 compliant when running on other supported computer systems provided the conditions described in IG G.5 (Reference 3), are met. On any platform the Module generated from the Module source code (the source files identified in Appendix B) is not validated if that source code is modified in any way. Following extensive consultation with the test lab we concluded that the typical use of C macros does not constitute source code modification. However, runtime substitution of assembler code for C code, as can occur with the OpenSSL build, is not mere recompilation. Hence the specific inclusion of the assembler code in the validation testing. Due to the relevance of word size to cryptographic operations we also elected to cover both 32/64 bit and big/little endian architectures. However, a plain C build (no-asm) on *any* platform where the build instructions in the Security Policy are faithfully followed will result in a validated module per the G.5 vendor affirmation, regardless of whether that platform was explicitly included in the validation testing. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS 1.2 Security Policy issues
Thomas J. Hruska wrote: According to the FIPS 1.2 Security Policy, Appendix A, Platform 8 cannot be built as FIPS compliant because 'x84-64 asm' is a non-existent platform. There is no such thing as x84. It should say 'x86-64 asm'. Validation, from what I understand, only covers those platforms listed. Strictly-speaking, x86-64 asm is not able to be built as FIPS-compliant since it is not included in the list (despite supposedly being a tested platform). 2. Verify that the SHA1 HMAC digest of the distribution file (see Appendix B). What exactly am I verifying? Either finish the sentence or remove the word 'that'. Since this sentence is grammatically incorrect which leads the reader to believe there is more to the step than mentioned, this step is thus incomplete. Following a path of strict logic, Appendix A, step 2's incomplete sentence makes it impossible to perform a FIPS validated build for any platform. Feedback on errors in the Security Policy is greatly appreciated, but please note I can't make any corrections to the officially approved version, it is frozen just like the source code. I will have an errata page for the Security Policy in the User Guide which is coming out Real Soon Now. The most critical step of FIPS validated builds in the past was to apply OS-level security measures to fipscanister (e.g. make specific files read-only to everyone but root/admin.). Is this done automatically now? Or what section of the Security Policy did I skim too quickly over that covers this? If it isn't covered in the Security Policy but needs to be done, does that invalidate the FIPS validation? Please take a look at some other Security Policy documents. You will note that they have a very stylized format, using FIPS-speak where terms can have different meanings than in a software engineering context. Think patent application instead of RFC. I didn't fully appreciate that fact for the first validation and drafted the initial Security Policy for a technical audience. During the validation processes I was told, again and again, that I was confusing the issues with facts and so progressively removed said extraneous technical detail until we wound up with this most recent Security Policy in the conventional style of other validations. The removed material makes up the User Guide. The righteous answer to your question is that the governing documents (scripture) for FIPS 140-2 are the FIPS 140-2 standard itself (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) and the Implementation Guidance document (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf). A more pragmatic answer is to note that strictly speaking almost no validated software module for general purpose computers is usable in the real world. Note for instance the standard Security Policy requirement for single user mode. I realize these are nitpicks. However, before I go through the massive undertaking of putting together a FIPS build for Windows, I need to know that these are non-issues. The last time I tried to do a FIPS build, it wasted two weeks of time better spent doing other things. I've wasted five years, welcome to the club :-) -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS 1.2 Security Policy issues
Steve Marquess wrote: Thomas J. Hruska wrote: According to the FIPS 1.2 Security Policy, Appendix A, Platform 8 cannot be built as FIPS compliant because 'x84-64 asm' is a non-existent platform. There is no such thing as x84. It should say 'x86-64 asm'. Validation, from what I understand, only covers those platforms listed. Strictly-speaking, x86-64 asm is not able to be built as FIPS-compliant since it is not included in the list (despite supposedly being a tested platform). 2. Verify that the SHA1 HMAC digest of the distribution file (see Appendix B). What exactly am I verifying? Either finish the sentence or remove the word 'that'. Since this sentence is grammatically incorrect which leads the reader to believe there is more to the step than mentioned, this step is thus incomplete. Following a path of strict logic, Appendix A, step 2's incomplete sentence makes it impossible to perform a FIPS validated build for any platform. Feedback on errors in the Security Policy is greatly appreciated, but please note I can't make any corrections to the officially approved version, it is frozen just like the source code. I will have an errata page for the Security Policy in the User Guide which is coming out Real Soon Now. The most critical step of FIPS validated builds in the past was to apply OS-level security measures to fipscanister (e.g. make specific files read-only to everyone but root/admin.). Is this done automatically now? Or what section of the Security Policy did I skim too quickly over that covers this? If it isn't covered in the Security Policy but needs to be done, does that invalidate the FIPS validation? Please take a look at some other Security Policy documents. You will note that they have a very stylized format, using FIPS-speak where terms can have different meanings than in a software engineering context. Think patent application instead of RFC. I didn't fully appreciate that fact for the first validation and drafted the initial Security Policy for a technical audience. During the validation processes I was told, again and again, that I was confusing the issues with facts and so progressively removed said extraneous technical detail until we wound up with this most recent Security Policy in the conventional style of other validations. The removed material makes up the User Guide. The righteous answer to your question is that the governing documents (scripture) for FIPS 140-2 are the FIPS 140-2 standard itself (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) and the Implementation Guidance document (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf). A more pragmatic answer is to note that strictly speaking almost no validated software module for general purpose computers is usable in the real world. Note for instance the standard Security Policy requirement for single user mode. I realize these are nitpicks. However, before I go through the massive undertaking of putting together a FIPS build for Windows, I need to know that these are non-issues. The last time I tried to do a FIPS build, it wasted two weeks of time better spent doing other things. I've wasted five years, welcome to the club :-) -Steve M. Thank you for the detailed explanations. I look forward to seeing the User Guide. -- Thomas Hruska Shining Light Productions Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: FIPS 1.2 Security Policy issues
I can sympathize with Steve, having gone through a Common Criteria certification and finally understanding that what I considered the truth was misleading to the validators, leading to numerous inconclusive verdicts. As to the real-worldness aspect, this is often a 'checkbox' that gives assurance that a 3rd party poked their educated nose into the product and found it reasonable. My quandary is that I need a productized (or non-SNAPSHOT) version of OpenSSL to work with the FIPS Object Module 1.2; I'm guessing it will be 0.9.8j. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Marquess Sent: Tuesday, November 25, 2008 4:24 AM To: openssl-users@openssl.org Subject: Re: FIPS 1.2 Security Policy issues Thomas J. Hruska wrote: According to the FIPS 1.2 Security Policy, Appendix A, Platform 8 cannot be built as FIPS compliant because 'x84-64 asm' is a non-existent platform. There is no such thing as x84. It should say 'x86-64 asm'. Validation, from what I understand, only covers those platforms listed. Strictly-speaking, x86-64 asm is not able to be built as FIPS-compliant since it is not included in the list (despite supposedly being a tested platform). 2. Verify that the SHA1 HMAC digest of the distribution file (see Appendix B). What exactly am I verifying? Either finish the sentence or remove the word 'that'. Since this sentence is grammatically incorrect which leads the reader to believe there is more to the step than mentioned, this step is thus incomplete. Following a path of strict logic, Appendix A, step 2's incomplete sentence makes it impossible to perform a FIPS validated build for any platform. Feedback on errors in the Security Policy is greatly appreciated, but please note I can't make any corrections to the officially approved version, it is frozen just like the source code. I will have an errata page for the Security Policy in the User Guide which is coming out Real Soon Now. The most critical step of FIPS validated builds in the past was to apply OS-level security measures to fipscanister (e.g. make specific files read-only to everyone but root/admin.). Is this done automatically now? Or what section of the Security Policy did I skim too quickly over that covers this? If it isn't covered in the Security Policy but needs to be done, does that invalidate the FIPS validation? Please take a look at some other Security Policy documents. You will note that they have a very stylized format, using FIPS-speak where terms can have different meanings than in a software engineering context. Think patent application instead of RFC. I didn't fully appreciate that fact for the first validation and drafted the initial Security Policy for a technical audience. During the validation processes I was told, again and again, that I was confusing the issues with facts and so progressively removed said extraneous technical detail until we wound up with this most recent Security Policy in the conventional style of other validations. The removed material makes up the User Guide. The righteous answer to your question is that the governing documents (scripture) for FIPS 140-2 are the FIPS 140-2 standard itself (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) and the Implementation Guidance document (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf ). A more pragmatic answer is to note that strictly speaking almost no validated software module for general purpose computers is usable in the real world. Note for instance the standard Security Policy requirement for single user mode. I realize these are nitpicks. However, before I go through the massive undertaking of putting together a FIPS build for Windows, I need to know that these are non-issues. The last time I tried to do a FIPS build, it wasted two weeks of time better spent doing other things. I've wasted five years, welcome to the club :-) -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
FIPS 1.2 Security Policy issues
According to the FIPS 1.2 Security Policy, Appendix A, Platform 8 cannot be built as FIPS compliant because 'x84-64 asm' is a non-existent platform. There is no such thing as x84. It should say 'x86-64 asm'. Validation, from what I understand, only covers those platforms listed. Strictly-speaking, x86-64 asm is not able to be built as FIPS-compliant since it is not included in the list (despite supposedly being a tested platform). 2. Verify that the SHA1 HMAC digest of the distribution file (see Appendix B). What exactly am I verifying? Either finish the sentence or remove the word 'that'. Since this sentence is grammatically incorrect which leads the reader to believe there is more to the step than mentioned, this step is thus incomplete. Following a path of strict logic, Appendix A, step 2's incomplete sentence makes it impossible to perform a FIPS validated build for any platform. The most critical step of FIPS validated builds in the past was to apply OS-level security measures to fipscanister (e.g. make specific files read-only to everyone but root/admin.). Is this done automatically now? Or what section of the Security Policy did I skim too quickly over that covers this? If it isn't covered in the Security Policy but needs to be done, does that invalidate the FIPS validation? I realize these are nitpicks. However, before I go through the massive undertaking of putting together a FIPS build for Windows, I need to know that these are non-issues. The last time I tried to do a FIPS build, it wasted two weeks of time better spent doing other things. -- Thomas Hruska Shining Light Productions Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
