Building openssl fips 2.0 shared without version for Android

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Building openssl fips 2.0 shared without version for Android

ken@bitzermobile.com

I have built android on windows, iOS, and android successfully, but with android I had to do a workaround for the versioning using this link:

http://stackoverflow.com/questions/12269563/using-openssl-fips-2-0-shared-libraries-in-android

 

Is there an environment variable or switch I can pass to config to accomplish this?

 

 

 

Ken Montagna 

Earth-Security14x14http://www.BitzerMobile.com

 

Reply | Threaded
Open this post in threaded view
|

Re: Building openssl fips 2.0 shared without version for Android

Andy Polyakov-2
Ken Montagna wrote:
> I have built android on windows, iOS, and android successfully, but with
> android I had to do a workaround for the versioning using this link:
>
> http://stackoverflow.com/questions/12269563/using-openssl-fips-2-0-shared-libraries-in-android
>
>  
>
> Is there an environment variable or switch I can pass to config to
> accomplish this?

This is not answer to question, but another question.

There is one thing I fail to understand. Is it correctly understood that
we are talking about Java application and that you can't call OpenSSL
functions directly from VM? That you have to interface OpenSSL and your
Java code through JNI layer that follows specific naming and argument
passing convention? And if this is the case, wouldn't it be more
appropriate to embed libcrypto.a into your JNI shared library instead?
You'd have to collect the .a libraries from shared OpenSSL build (so
that code is compiled as position-independent), you'd have to link your
JNI with fipsld, but you wouldn't have to fight with System.load [and
handle SD card swaps]...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Building openssl fips 2.0 shared without version for Android

ken@bitzermobile.com
Very good point, I agree.  The advantage of the shared object is I don't
need to sign the entire application again (fipsld). I wrote a very simple
jni wrapper for the FIPS_mode_set function that can be called anywhere
within the application.

#include <openssl/crypto.h>
#include <jni.h>
#include <jni_log.h>
#include <string.h>

void Java_com_mycompany_util_setFipsModeEnabled(JNIEnv* env, jobject
javaThis, jboolean isEnabled) {
    LOGD("in set Fips enabled");
    if (isEnabled) {
        if(FIPS_mode_set(1)) {
            LOGD("FIPS mode enabled");
        }else {
            LOGE("Error in enabling FIPS mode");
            ERR_load_crypto_strings();
            ERR_print_errors_fp(stderr);
            exit(1);
        }
    }else{
       LOGD("FIPS mode is not enabled");
    }
}

To your point I did it as you suggested with iOS. I  have it working both
ways. I was just curious/asking why the versioning is only done in the Linux
build.

Thanks for the response
Ken

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Andy Polyakov
Sent: Friday, November 09, 2012 7:06 AM
To: [hidden email]
Subject: Re: Building openssl fips 2.0 shared without version for Android

Ken Montagna wrote:

> I have built android on windows, iOS, and android successfully, but
> with android I had to do a workaround for the versioning using this link:
>
> http://stackoverflow.com/questions/12269563/using-openssl-fips-2-0-sha
> red-libraries-in-android
>
>  
>
> Is there an environment variable or switch I can pass to config to
> accomplish this?

This is not answer to question, but another question.

There is one thing I fail to understand. Is it correctly understood that we
are talking about Java application and that you can't call OpenSSL functions
directly from VM? That you have to interface OpenSSL and your Java code
through JNI layer that follows specific naming and argument passing
convention? And if this is the case, wouldn't it be more appropriate to
embed libcrypto.a into your JNI shared library instead?
You'd have to collect the .a libraries from shared OpenSSL build (so that
code is compiled as position-independent), you'd have to link your JNI with
fipsld, but you wouldn't have to fight with System.load [and handle SD card
swaps]...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Building openssl fips 2.0 shared without version for Android

Andy Polyakov-2
> Very good point, I agree.  The advantage of the shared object is I don't
> need to sign the entire application again (fipsld).

My understanding is that native methods are always collected in shared
library. Shared library containing FIPS module is the only one that
needs to be fingerprinted. So why are you referring to "entire application"?

> I wrote a very simple
> jni wrapper for the FIPS_mode_set function that can be called anywhere
> within the application.
>
> #include <openssl/crypto.h>
> #include <jni.h>
> #include <jni_log.h>
> #include <string.h>
>
> void Java_com_mycompany_util_setFipsModeEnabled(JNIEnv* env, jobject
> javaThis, jboolean isEnabled) {
>     LOGD("in set Fips enabled");
>     if (isEnabled) {
>         if(FIPS_mode_set(1)) {

And then what? How does your application call OpenSSL functions [that
invoke FIPS module]? Or do you count that shared libcrypto that you load
overrides system libcrypto.so? It's possible, but it's error-prone
solution...
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Building openssl fips 2.0 shared without version for Android

ken@bitzermobile.com
I have a common c library on top of openssl to abstract it from our
applications we use for devices and servers.  We can easily plug in any
version of openssl going forward. On Android we had an existing jni wrapper
for our common library that I compile with android ndk. Sorry,  I realize is
not obvious from my previous reply and I didn't mention it before.  As you
can see it is not error prone as we have the same code executing everywhere
the same way.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Andy Polyakov
Sent: Friday, November 09, 2012 12:04 PM
To: [hidden email]
Subject: Re: Building openssl fips 2.0 shared without version for Android

> Very good point, I agree.  The advantage of the shared object is I
> don't need to sign the entire application again (fipsld).

My understanding is that native methods are always collected in shared
library. Shared library containing FIPS module is the only one that needs to
be fingerprinted. So why are you referring to "entire application"?

> I wrote a very simple
> jni wrapper for the FIPS_mode_set function that can be called anywhere
> within the application.
>
> #include <openssl/crypto.h>
> #include <jni.h>
> #include <jni_log.h>
> #include <string.h>
>
> void Java_com_mycompany_util_setFipsModeEnabled(JNIEnv* env, jobject
> javaThis, jboolean isEnabled) {
>     LOGD("in set Fips enabled");
>     if (isEnabled) {
>         if(FIPS_mode_set(1)) {

And then what? How does your application call OpenSSL functions [that invoke
FIPS module]? Or do you count that shared libcrypto that you load overrides
system libcrypto.so? It's possible, but it's error-prone solution...
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Building openssl fips 2.0 shared without version for Android

Andy Polyakov-2
> I have a common c library on top of openssl to abstract it from our
> applications we use for devices and servers.  We can easily plug in any
> version of openssl going forward. On Android we had an existing jni wrapper
> for our common library that I compile with android ndk.

Wouldn't it be most appropriate to link together OpenSSL, your lib and
JNI to single .so and be done with it? Even more appropriate would be to
limit exported symbols to JNI methods so that other components don't
"contaminate" dynamic linker name space nor library itself won't fall
victim to "contamination". Latter is by all means is definition of
"error-prone."
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Building openssl fips 2.0 shared without version for Android

ken@bitzermobile.com
We are going off topic on my question.  Which is just, is android openssl
builds going to continue to have versions?

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Andy Polyakov
Sent: Saturday, November 10, 2012 3:32 PM
To: [hidden email]
Subject: Re: Building openssl fips 2.0 shared without version for Android

> I have a common c library on top of openssl to abstract it from our
> applications we use for devices and servers.  We can easily plug in
> any version of openssl going forward. On Android we had an existing
> jni wrapper for our common library that I compile with android ndk.

Wouldn't it be most appropriate to link together OpenSSL, your lib and JNI
to single .so and be done with it? Even more appropriate would be to limit
exported symbols to JNI methods so that other components don't "contaminate"
dynamic linker name space nor library itself won't fall victim to
"contamination". Latter is by all means is definition of "error-prone."
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Building openssl fips 2.0 shared without version for Android

Andy Polyakov-2
> We are going off topic on my question.  Which is just, is android openssl
> builds going to continue to have versions?

First of all it's hardly appropriate to build it as lib[crypto|ssl].so.
So essentially it's .so.1.0.0.so vs. say .1.0.0.so. Complain appears to
be that .so.1.0.0 doesn't play well with System.load. Would .1.0.0.so
play better? Can you flip order in Configure line and verify?

But once again. Is it even meaningful to perform System.load on OpenSSL
shared library? It doesn't contain any JNI methods, so you can't use it
directly. If it has to be shared library, then shouldn't JNI.so be
linked with it? I mean shouldn't System.load on JNI.so bring in
lib[crypto|ssl].so.1.0.0 automatically?
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]