FIPS OM 2.0 in application shared library?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FIPS OM 2.0 in application shared library?

mclellan, dave

Hi.   We are experimenting with the FIPS 2.0 Object Module RC1 and the recent GA of OpenSSL 1.0.1.   We have a successful FIPS-capable build of OpenSSL and we’ve verified it with the openssl CLI with OPENSSL_FIPS=1 set.  Our experiments are currently limited to Linux X86_64, and we are not using assembler optimizations

 

We are able to build FIPS into our application shared library in two scenarios:

1.       Where our shared library links against the libcrypto.so and libssl.so (and fipscanister.o obviously). 

2.       Where our shared library links statically with libcrypto.a and libssl.a (and fipscanister.o obviously).  The reasons we want to do this are too messy for this mail.

 

When the application calls FIPS_mode_set(),  in Case 1 above (shared), it is successful.  In Case 2 (static), FIPS_mode_set() returns “fingerprint mistmatch” .   

 

The User Guide implies both in sections 5.3 and 5.4 that linking FIPS OM/OpenSSL into an application shared library is permitted and acceptable. 

 

THE MAIN QUESTION IS:    is Case #2 supported?   Should we be able to create an application shared library with a statically linked libcrypto.a (and fipscanister.o)?   If the answer is YES, then we’ll return to our drawing board.   If the answer is NO, then we move to a different drawing board.

 

Thanks for a simple YES or NO, but other explanatory details are welcome.

 

Dave

 

+-+-+-+-+-+-+
Dave McLellan, Symmetrix Software Engineering
EMC Corporation, 176 South St, Hopkinton MA
Mail Stop 176-B1 1/P-36
office 508-249-1257, fax 508-497-8027
cell 978-500-2546
+-+-+-+-+-+-+

 

Reply | Threaded
Open this post in threaded view
|

Re: FIPS OM 2.0 in application shared library?

Dr. Stephen Henson
On Mon, Apr 23, 2012, [hidden email] wrote:

> Hi.   We are experimenting with the FIPS 2.0 Object Module RC1 and the recent GA of OpenSSL 1.0.1.   We have a successful FIPS-capable build of OpenSSL and we've verified it with the openssl CLI with OPENSSL_FIPS=1 set.  Our experiments are currently limited to Linux X86_64, and we are not using assembler optimizations
>
> We are able to build FIPS into our application shared library in two scenarios:
>
> 1.       Where our shared library links against the libcrypto.so and libssl.so (and fipscanister.o obviously).
>
> 2.       Where our shared library links statically with libcrypto.a and libssl.a (and fipscanister.o obviously).  The reasons we want to do this are too messy for this mail.
>
> When the application calls FIPS_mode_set(),  in Case 1 above (shared), it is successful.  In Case 2 (static), FIPS_mode_set() returns "fingerprint mistmatch" .
>
> The User Guide implies both in sections 5.3 and 5.4 that linking FIPS OM/OpenSSL into an application shared library is permitted and acceptable.
>
> THE MAIN QUESTION IS:    is Case #2 supported?   Should we be able to create an application shared library with a statically linked libcrypto.a (and fipscanister.o)?   If the answer is YES, then we'll return to our drawing board.   If the answer is NO, then we move to a different drawing board.
>
> Thanks for a simple YES or NO, but other explanatory details are welcome.
>
>

The short answer is YES.

The longer answer is that if you link to an FIPS capable OpenSSL shared
library you don't need to perform any special link procedure because the
signature is already embedded in the shared library. If you statically link
then you need to embed the signature in the application (which might be an
exectuable or a shared library) so if you aren't using the "fipsld" utility
for the shared library link that's what's causing the problem.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: FIPS OM 2.0 in application shared library?

mclellan, dave
Hi Dr. Steve. Thank you very much.  

In our static case, we are using fipsld to link libcrypto and fipscanister with our objects.   It seems successful, and produces a loadable shared library.  But the self-test of FIPS_mode_set() is unable to match the signature.  

So we will keep experimenting.  

Thanks again.

Dave.

+-+-+-+-+-+-+
Dave McLellan, Symmetrix Software Engineering
EMC Corporation, 176 South St, Hopkinton MA
Mail Stop 176-B1 1/P-36
office 508-249-1257, fax 508-497-8027
cell 978-500-2546
+-+-+-+-+-+-+




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dr. Stephen Henson
Sent: Tuesday, April 24, 2012 6:07 AM
To: [hidden email]
Subject: Re: FIPS OM 2.0 in application shared library?

On Mon, Apr 23, 2012, [hidden email] wrote:

> Hi.   We are experimenting with the FIPS 2.0 Object Module RC1 and the recent GA of OpenSSL 1.0.1.   We have a successful FIPS-capable build of OpenSSL and we've verified it with the openssl CLI with OPENSSL_FIPS=1 set.  Our experiments are currently limited to Linux X86_64, and we are not using assembler optimizations
>
> We are able to build FIPS into our application shared library in two scenarios:
>
> 1.       Where our shared library links against the libcrypto.so and libssl.so (and fipscanister.o obviously).
>
> 2.       Where our shared library links statically with libcrypto.a and libssl.a (and fipscanister.o obviously).  The reasons we want to do this are too messy for this mail.
>
> When the application calls FIPS_mode_set(),  in Case 1 above (shared), it is successful.  In Case 2 (static), FIPS_mode_set() returns "fingerprint mistmatch" .
>
> The User Guide implies both in sections 5.3 and 5.4 that linking FIPS OM/OpenSSL into an application shared library is permitted and acceptable.
>
> THE MAIN QUESTION IS:    is Case #2 supported?   Should we be able to create an application shared library with a statically linked libcrypto.a (and fipscanister.o)?   If the answer is YES, then we'll return to our drawing board.   If the answer is NO, then we move to a different drawing board.
>
> Thanks for a simple YES or NO, but other explanatory details are welcome.
>
>

The short answer is YES.

The longer answer is that if you link to an FIPS capable OpenSSL shared
library you don't need to perform any special link procedure because the
signature is already embedded in the shared library. If you statically link
then you need to embed the signature in the application (which might be an
exectuable or a shared library) so if you aren't using the "fipsld" utility
for the shared library link that's what's causing the problem.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]