1

I was able to follow directions in this question to build a shared lib of openssl for Android.

E.g.

cd openssl-fips-2.0/
./config
make
make install

And

cd openssl-1.0.1c/
./config fips --with-fipsdir=/usr/local/ssl/fips-2.0/ shared
make depend
make

This generates libcrypto.so.1.0.0 and libssl.so.1.0.0 with corresponding symbolic links to them as libcrypto.so and libssl.so.

Since the NDK build system doesn't support versioned shared libraries I had to use the symbolic links (with PREBUILT_SHARED_LIBRARY). However, with this, the libraries end up getting to the device as libcrypto.so and libssl.so instead of as libcrypto.so.1.0.0 and libssl.so.1.0.0 causing my library to fail to load as it is looking for the libraries with the version names.

The linked question mentions loading the libraries with System.load(libcrypto.so.1.0.0) instead of with System.loadLibrary() but I have not been able to get this to work even with full paths since as mentioned earlier, the file is copied to the device as libcrypto.so.

Anyone done this successfully?

Note: I've also tried modifying the openssl-1.0.1c config and makefiles to generate libcrypto.1.0.0.so (e.g. with the version number before the extension in the filename and soname) and this allowed me to get around the previous loading issue. However, with that I get an error when I try to turn on FIPS mode with FIPS_module_mode_set (FIPS_R_FINGERPRINT_DOES_NOT_MATCH).

I don't know yet why that is happening, but it could be due to NDK stripping of 'unneeded' stuff (see this question)... I'm still looking at this as well but if someone has some info on this as well it would be MUCH appreciated.

Community
  • 1
  • 1
Jari Niskala
  • 13
  • 1
  • 5
  • have you seen this discussion http://stackoverflow.com/questions/11091905/android-build-openssl-fips-2-0 before you posted your question? – Alex Cohn Sep 06 '12 at 12:34
  • Yeah, I tried to just add followup comment to it since it looked like at least brewphone got it working but since i don't have enough cred, I wasn't able to do it. And when I added an 'answer' it got deleted. – Jari Niskala Sep 07 '12 at 00:27
  • That question is linked to this as well. – Jari Niskala Sep 07 '12 at 00:28
  • I managed to build a version-less `libcrypto.so`, see http://stackoverflow.com/a/33869277/4735903. – Loic Nov 23 '15 at 11:03

1 Answers1

2

Let us identify the problem correctly. It's likely not the NDK build that causes problems, and definitely not the linker which strips away unused entries when it builds a shared lib from static lib.

First of all, I am not sure you can deliver FIPS mode in a usual APK, without rebuilding or at least rooting Android (see for example http://gcn.com/articles/2010/12/23/android-fips-security.aspx).

There is no problem for System.load() to load a versioned .so when you a) specify the full path correctly (e.g. System.load("/data/local/tmp/libssl.so.1.0.0")) and b) the file is delivered to that path. For the first tests, I would suggest to manually upload libcrypto.so.1.0.0 and libssl.so.1.0.0 to /sdcard/ and see if FIPS fingerprint becomes happier.

If the location on /sdcard/ causes any problem, you can try /data/local/ or /data/local/tmp/. You can also use /data/data/(your package)/files/. The latter has one advantage: it will be automatically deleted by the system when your app is uninstalled.

To make a versioned .so (like libcrypto.so.1.0.0) part of your APK, copy it to the assets folder of your project. It will be responsibility of your Java code to copy it from there to the designated location on disk. Make sure this Java code handles correctly upgrades and SD card swaps.

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • Thanks Alex! It turned out that I needed to package the un-stripped libs as content and then copy them to the apps data folder after which the System.load("/data/data/myapp/files/libcrypto.so.1.0.0") and System.load("/data/data/myapp/files/libssl.so.1.0.0") did the trick. Interestingly, just changing the makefiles to put the version number before the .so extension caused the fingerprint to fail even though the fips stuff was not touched. – Jari Niskala Sep 12 '12 at 16:32
  • Great news! Good luck with your project! – Alex Cohn Sep 12 '12 at 17:11
  • You don't by any chance know any way to NOT have the stripped libcrypto.so and libssl.so to not be part of the apk? – Jari Niskala Sep 12 '12 at 22:52
  • Currently my Android.mk file for my jni library includes the openssl crypto and ssl libs as LOCAL_SHARED_LIBRARIES which eventually results in those files being copied into my apk file. However, the files that actually are copied to the device are the stripped files without the versioning, they can't be used then I do my System.load calls. So as discussed in this, I end up including the 'real' libcrypto.so.1.0.0 and libssl.so.1.0.0 files as content to get them included in the apk so I can load them in my code. – Jari Niskala Sep 13 '12 at 16:22
  • So while this works, it means that my apk ends up having two crypto and two ssl libs in the apk and on the device making my apk file about 2MBs larger than it has to be. Ideally I would like to just replace the libcrypto.so with libcrypto.so.1.0.0 during the packaging phase of the apk. – Jari Niskala Sep 13 '12 at 16:24
  • Currently looking into modifying the build.xml file to see if I could just replace the libs there before packaging in the post-compile step. – Jari Niskala Sep 13 '12 at 16:34
  • Keep it simple. Use LOCAL_LDLIBS to point to hour crypto and ssl libs wherever they reside, and they will not be automatically copied to the APK. See http://stackoverflow.com/questions/6041934/can-shared-library-call-another-shared-library – Alex Cohn Sep 13 '12 at 20:24
  • Thanks Alex. That made it cleaner. I just ended up leaving it with my app having to copy the file out of assets before loading them. – Jari Niskala Sep 14 '12 at 20:43