Utilisation des bibliothèques partagées openssl-fips-2.0 dans Android

Question

J'ai été en mesure de suivre les instructions dans this question pour construire une bibliothèque partagée de openssl pour Android.

E.g.

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

Et

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

Cela génère libcrypto.so.1.0.0 et libssl.so.1.0.0 avec les liens symboliques correspondant à eux comme libcrypto.so et libssl.so.

Étant donné que le système de compilation NDK ne supporte pas les bibliothèques partagées avec version, j'ai dû utiliser les liens symboliques (avec PREBUILT_SHARED_LIBRARY). Cependant, avec ceci, les librairies finissent par arriver sur le périphérique en tant que libcrypto.so et libssl.so au lieu de libcrypto.so.1.0.0 et libssl.so.1.0.0 provoquant l'échec du chargement de ma librairie. pour les bibliothèques avec les noms de version.

La question liée mentionne le chargement des bibliothèques avec System.load (libcrypto.so.1.0.0) au lieu de System.loadLibrary() mais je n'ai pas réussi à faire fonctionner ceci même avec des chemins complets car comme mentionné plus tôt, le fichier est copié sur le périphérique sous le nom de libcrypto.so.

Quelqu'un l'a fait avec succès?

Note: J'ai également essayé de modifier la config openssl-1.0.1c et makefiles pour générer libcrypto.1.0.0.so (par exemple avec le numéro de version avant l'extension dans le nom de fichier et soname) et cela m'a permis de contourner le problème de chargement précédent. Cependant, avec cela, j'obtiens une erreur lorsque j'essaie d'activer le mode FIPS avec FIPS_module_mode_set (FIPS_R_FINGERPRINT_DOES_NOT_MATCH).

Je ne sais pas encore pourquoi cela se produit, mais cela pourrait être dû à un dépouillement de NDK de choses inutiles (voir ceci question) ... Je suis toujours en train de regarder ça aussi mais si quelqu'un en a L'information sur ceci aussi bien serait très appréciée. Laissez-nous identifier le problème correctement.

Answer 1

Ce n'est probablement pas la construction NDK qui cause des problèmes, et certainement pas l'éditeur de liens qui supprime les entrées inutilisées quand il construit une lib partagée à partir de la librairie statique. Tout d'abord, je ne suis pas sûr que vous pouvez fournir le mode FIPS dans un fichier APK habituel, sans recréer ou au moins enraciner Android (voir par exemple http://gcn.com/articles/2010/12/23/android-fips-security.aspx).

Il n'y a pas de problème pour System.load() de charger une .donc versionné lorsque vous a) spécifier le chemin complet correctement (par exemple System.load("/data/local/tmp/libssl.so.1.0.0")) et b) le fichier est livré à cette voie. Pour les premiers tests, je suggère de télécharger manuellement libcrypto.so.1.0.0 et libssl.so.1.0.0 à /sdcard/ et de voir si l'empreinte FIPS devient plus heureux.

Si l'emplacement sur /sdcard/ provoque un problème, vous pouvez essayer /data/local/ ou /data/local/tmp/. Vous pouvez également utiliser /data/data/(votre package)/files/. Ce dernier a un avantage: il sera automatiquement supprimé par le système lorsque votre application est désinstallée.

Pour créer une version .so (comme libcrypto.so.1.0.0) partie de votre fichier APK, copiez-la dans le dossier "assets" de votre projet. Il sera de la responsabilité de votre code Java de le copier à partir de là vers l'emplacement désigné sur le disque. Assurez-vous que ce code Java gère correctement les mises à niveau et les échanges de cartes SD.