Re: [openssl-users] FIPS mode restrictions and DES
>> One point is that if this is a delivery for someone
>> subject to the FIPS-only procurementrequirement
>> imposed on various US Government related entities,
>> then whatever OS theyuse, MUST (by that requirement)
>> have already passed this for its password handling.
>
> This is *technically* true, in the narrow sense that supposedly any OS
> used in DoD should be CC certified and so forth. Should not must.
>
> In practice it is very common -- at FIPS 140-2 Level 1 -- for software
> *products* to use FIPS 140-2 validated crypto on non-certified,
> non-validated operating systems. Just take a look at Table 2 in the
> OpenSSL FIPS Object Module Security Policy:
>
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf
>
> and note that of the 101 platforms ("OEs") appearing there, most of
> those operating systems are neither CC certified nor have any other FIPS
> 140-2 validated crypto. Keep in mind that at Level 1 the validation
> applies to the cryptographic module, not the calling application that
> uses that module nor the operating system that runs it.
Another example is the various frameworks that provide the TextEdit
boxes where passwords are entered. FIPS requires zeroization at level
1, and I guarantee none of those frameworks wipe the memory from the
TextEdit.
Hell, Apple has a secure allocator that does not even bother calling
the secure deleter. It calls the default deleter for some reason. See
the source code for libsecurity_utilities at [1,2,3].
And Apple really could have used zeroization:
http://www.cnet.com/news/mac-os-x-lion-reveals-passwords-in-sleep-mode/.
As this vulnerability shows, wiping secrets from memory is not a
theoretical defense.
[1]
http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/SecKeychainItem.cpp
[2]
http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/Item.cpp
[3]
http://www.opensource.apple.com/source/libsecurity_utilities/libsecurity_utilities-38535/lib/alloc.cpp
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto "libraries" to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu wrote: > Salz, Rich wrote > > As the old joke goes, "if you have to ask, you can't afford it." > > Well, exploration can be free. I noticed that Strongswan uses a plug-in > architecture for crypto that seemingly allows the use of OpenSSL instead of > the kernel for crypto operations, for use under FIPS. Does anyone have an > idea of the order of magnitude in performance loss this could be for IPSec, > to use crypto from OpenSSL instead of the kernel ? > > Regards. > > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto "libraries" to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu wrote: > Salz, Rich wrote > > As the old joke goes, "if you have to ask, you can't afford it." > > Well, exploration can be free. I noticed that Strongswan uses a plug-in > architecture for crypto that seemingly allows the use of OpenSSL instead of > the kernel for crypto operations, for use under FIPS. Does anyone have an > idea of the order of magnitude in performance loss this could be for IPSec, > to use crypto from OpenSSL instead of the kernel ? > > Regards. > > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 04/14/2015 09:42 AM, jonetsu wrote:
>
>
>> From: "Steve Marquess" Date: 04/14/15 09:31
>>
>
>> and note that of the 101 platforms ("OEs") appearing there, most
>> of those operating systems are neither CC certified nor have any
>> other FIPS 140-2 validated crypto. Keep in mind that at Level 1 the
>> validation applies to the cryptographic module, not the calling
>> application that uses that module nor the operating system that
>> runs it.
>
> I came across a Red Hat Security Policy document that clearly puts
> the XFRM out of the Security Policy domain. See section 1.1.2, page
> 8, in:
>
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1386.pdf
>
> This blurs the concept of FIPS validation. Looks more and more that
> the validation will only care about what is being declared as going
> for validation. In this case (policy might have changed since 2010)
> they simply say that no, we do not declare the crypto done via XFRM
> as part of the Security Policy. And the FIPS lab says, OK, fine.
> Hmmm
No, it doesn't blur anything. That is a Level 1 validation. At Level 1
only the "cryptographic module" is within scope of the FIPS 140-2
validation. The "cryptographic module" is a concept that is rather
precisely defined in that context. You often hear the term "boundary" in
reference to cryptographic modules.
The operating system, and any crypto it may contain, is out of scope ==
outside the boundary. The calling application(s), and any other crypto
it may contain, is out of scope. Any other applications residing on the
same system, and any crypto they may contain, are out of scope.
The Level 1 validation covers *only* the specific "cryptographic module".
-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/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 04/13/2015 01:30 PM, Jakob Bohm wrote:
> ..
>>
>> With the very unique exception of the OpenSSL FIPS Object Module, there
>> are no FIPS 140-2 validated cryptographic modules that can be obtained
>> in source form and compiled by the end user. The fact that Red Hat (or
>> whomever) has taken open source code and obtained a FIPS 140-2
>> validation of binaries generated from that code does you no good unless
>> you have those specific binaries, which is to say you're a commercial
>> customer paying for a commercial license from that vendor.
>>
>> Then, even for the OpenSSL FIPS module the validation imposes some
>> pretty perverse constraints (from the usual software engineering
>> perspective). You have to start with a snail-mailed CD, you have to
>> build the binary module in a very special way that will conflict with
>> whatever configuration management you use, etc.; you have to treat it
>> differently that all the other software components of your product. FIPS
>> 140-2 is the tail that wags the dog.
>>
>> -Steve M.
> Of cause.
>
> One point is that if this is a delivery for someone
> subject to the FIPS-only procurementrequirement
> imposed on various US Government related entities,
> then whatever OS theyuse, MUST (by that requirement)
> have already passed this for its password handling.
This is *technically* true, in the narrow sense that supposedly any OS
used in DoD should be CC certified and so forth. Should not must.
In practice it is very common -- at FIPS 140-2 Level 1 -- for software
*products* to use FIPS 140-2 validated crypto on non-certified,
non-validated operating systems. Just take a look at Table 2 in the
OpenSSL FIPS Object Module Security Policy:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf
and note that of the 101 platforms ("OEs") appearing there, most of
those operating systems are neither CC certified nor have any other FIPS
140-2 validated crypto. Keep in mind that at Level 1 the validation
applies to the cryptographic module, not the calling application that
uses that module nor the operating system that runs it.
-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/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
> From: "Steve Marquess"
> Date: 04/14/15 09:31
> and note that of the 101 platforms ("OEs") appearing there, most of
> those operating systems are neither CC certified nor have any other FIPS
> 140-2 validated crypto. Keep in mind that at Level 1 the validation
> applies to the cryptographic module, not the calling application that
> uses that module nor the operating system that runs it.
I came across a Red Hat Security Policy document that clearly puts the XFRM out
of the Security Policy domain. See section 1.1.2, page 8, in:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1386.pdf
This blurs the concept of FIPS validation. Looks more and more that the
validation will only care about what is being declared as going for validation.
In this case (policy might have changed since 2010) they simply say that no,
we do not declare the crypto done via XFRM as part of the Security Policy. And
the FIPS lab says, OK, fine. Hmmm
Regards.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Salz, Rich wrote > As the old joke goes, "if you have to ask, you can't afford it." Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
> If I may, I'd like to ask about including the Linux kernel in the validation. As the old joke goes, "if you have to ask, you can't afford it." ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Thanks for all the comments, they're much appreciated. It is a Debian system, so there is no Red Hat FIPS validation (or SuSE which also has one I think) or validated components that can be used. If I may, I'd like to ask about including the Linux kernel in the validation. Now, including glibc2 was a pretty bad idea, it cannot get better with the kernel. In this case, IPSec (libreswan) is using the kernel's crypto functions. So it seems there would be no way out of this one. Any insight on this matter ? - thanks. Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57533.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 13/04/2015 18:48, Steve Marquess wrote: On 04/13/2015 12:14 PM, Jakob Bohm wrote: On 13/04/2015 17:48, Salz, Rich wrote: In other words, is the only practical and viable option regarding this to re-implement crypt() using EVP methods ? - thanks. Yes. That would be so much easier than anything you can imagine. Yes, the only thing easier would be if someone (maybe Red Hat) already has a FIPS validatedopen source implementation of crypt(). And even if Red Hat does, you would be limited to using the specific commercial versions of RHEL that included that specific validated binary module. With the very unique exception of the OpenSSL FIPS Object Module, there are no FIPS 140-2 validated cryptographic modules that can be obtained in source form and compiled by the end user. The fact that Red Hat (or whomever) has taken open source code and obtained a FIPS 140-2 validation of binaries generated from that code does you no good unless you have those specific binaries, which is to say you're a commercial customer paying for a commercial license from that vendor. Then, even for the OpenSSL FIPS module the validation imposes some pretty perverse constraints (from the usual software engineering perspective). You have to start with a snail-mailed CD, you have to build the binary module in a very special way that will conflict with whatever configuration management you use, etc.; you have to treat it differently that all the other software components of your product. FIPS 140-2 is the tail that wags the dog. -Steve M. Of cause. One point is that if this is a delivery for someone subject to the FIPS-only procurementrequirement imposed on various US Government related entities, then whatever OS theyuse, MUST (by that requirement) have already passed this for its password handling. This provides a baseline of already validated stuff on which other contractors can thenbuild, with reasonable care to the (bureaucratic) FIPS requirements. So if the OPs customer is already using/requiring a specificLinux/BSD/Solaris/etc. distribution, and that distributioncontains a FIPS 140-2 validated crypt() function for its loginprocessing, then the OP could reuse that. Red Hat is anexample here. Another possibility is that Red Hat or some other open source supplier to the US government has already reimplemented crypt() in terms of some other FIPS-validated piece of software, such as the OpenSSL FIPS module, with that crypt() reimplementation being outside the cryptographic boundary and thus reusable on other "platforms" with the same FIPS module. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 04/13/2015 12:14 PM, Jakob Bohm wrote: > On 13/04/2015 17:48, Salz, Rich wrote: >>> In other words, is the only >>> practical and viable option regarding this to re-implement crypt() >>> using EVP >>> methods ? - thanks. >> Yes. That would be so much easier than anything you can imagine. > Yes, the only thing easier would be if someone (maybe Red Hat) > already has a FIPS validatedopen source implementation of > crypt(). And even if Red Hat does, you would be limited to using the specific commercial versions of RHEL that included that specific validated binary module. With the very unique exception of the OpenSSL FIPS Object Module, there are no FIPS 140-2 validated cryptographic modules that can be obtained in source form and compiled by the end user. The fact that Red Hat (or whomever) has taken open source code and obtained a FIPS 140-2 validation of binaries generated from that code does you no good unless you have those specific binaries, which is to say you're a commercial customer paying for a commercial license from that vendor. Then, even for the OpenSSL FIPS module the validation imposes some pretty perverse constraints (from the usual software engineering perspective). You have to start with a snail-mailed CD, you have to build the binary module in a very special way that will conflict with whatever configuration management you use, etc.; you have to treat it differently that all the other software components of your product. FIPS 140-2 is the tail that wags the dog. -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/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 13/04/2015 17:48, Salz, Rich wrote: In other words, is the only practical and viable option regarding this to re-implement crypt() using EVP methods ? - thanks. Yes. That would be so much easier than anything you can imagine. Yes, the only thing easier would be if someone (maybe Red Hat) already has a FIPS validatedopen source implementation of crypt(). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
> In other words, is the only > practical and viable option regarding this to re-implement crypt() using EVP > methods ? - thanks. Yes. That would be so much easier than anything you can imagine. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Thanks for the comments - much appreciated. The following question might be on the naive side of things, but then I'm all new to this. Since crypt() in glibc2 supports SHA-256 and SHA-512 for password, and assuming that these two are FIPS compatible, what would be the (financial) overhead of having the crypto part of glibc2 go through validation ? It sounds very odd, not to mention very expensive, but I'm asking nevertheless, in case there is a possibility. In other words, is the only practical and viable option regarding this to re-implement crypt() using EVP methods ? - thanks. Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57527.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
