Issue with Loading oqsprovider.so on Android using OSSL_PROVIDER_load

[moganty]

Describe the bug

I have successfully built oqsprovider.so for the ARM64 architecture (Android) and its dependencies: libcrypto, libssl, and liboqs. However, during runtime, I encountered an issue where OSSL_PROVIDER_load fails to load oqsprovider.

To Reproduce Steps to reproduce the behaviour:

usecase is to create a PQC based X509 CSR on android device.

• In an Android application create a NDK module to build a JNI to create X509 CSR

• build the libraries libssl, libcrypto, liboqs, liboqsprovider using Android toolchain

• inside the NDK module's src/jnilibs/arm64-v8a folder add all libraries.

• In the source code add below code to use oqsprovider

OSSL_LIB_CTX *libctx = initialize_openssl(confPath, "oqsprovider");

// Function to initialize OpenSSL and load necessary providers
OSSL_LIB_CTX *initialize_openssl(const char *config_path, const char *provider_name) {
   OSSL_LIB_CTX *libctx = OSSL_LIB_CTX_new();
   if (!libctx) {
      // fprintf(stderr, "Error creating OpenSSL library context\n");
       return NULL;
   }

   if (!OSSL_LIB_CTX_load_config(libctx, config_path)) {
      // fprintf(stderr, "Error loading OpenSSL configuration\n");
       OSSL_LIB_CTX_free(libctx);
       return NULL;
   }

   if (!OSSL_PROVIDER_load(libctx, provider_name)) {
       // fprintf(stderr, "Error loading provider: %s\n", provider_name);
      // Print detailed OpenSSL errors
       while ((err = ERR_get_error()) != 0) {
           char err_msg[256];
           ERR_error_string_n(err, err_msg, sizeof(err_msg));
           //printf("OpenSSL Error: %s\n", err_msg);
           __android_log_print(ANDROID_LOG_ERROR, LOG_TAG,"OpenSSL error:%s",err_msg);
       }
       OSSL_LIB_CTX_free(libctx);
       return NULL;
   }

   return libctx;
}

Expected behavior

oqsprovider should be loaded by the function OSSL_PROVIDER_load

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: Android
• OpenSSL version : 3.3.2
• oqsprovider version : 0.6.1

Errors:

Open SSL error: error:12800067:DSO support routines::could not load the shared library Open SSL error: error:12800067:DSO support routines::could not load the shared library Open SSL error: error:07880025:common libcrypto routines::reason(37) Error loading provider error: error:00000000:lib(0)::reason(0)

Additional context code works perfectly when ran for macOS.

[baentsch]

Thanks for the more detailed report @moganty . Unfortunately I do not have an environment available that would allow me to reproduce this problem. Further (accordingly), I do not consider Android a supported platform. Lastly, the problem can very well have to do with issues in openssl or liboqs on Android.

[baentsch]

As per comment above, problem cannot be reproduced locally. Please provide suggestions how to do this and/or a PR fixing things, ideally together with a CI-based test, @moganty . Otherwise we'll have to close the issue.

[RodriM11]

I have previously avoided the use of configuration files when in Android environments, due to the inherent difficulty of the NDK to organize all libraries and configuration files in a way they can be used as with a Linux, macOS, Windows, etc... Not saying it is not possible, simply was simpler for me to do it other ways.

An alternative solution to be able to load oqsprovider might be to use OSSL_PROVIDER_add_builtin with the appropriate ossl_provider_init_fn (which depends on the nature of your compilation of the oqsprovider). You can see an example to load the provider this way on static_oqsprovider.c (and simply adapt it to a shared module if desired). This solution is only viable is your config file is just one to indicate use of the provider, if the config file is expected to load additional information then you probably need to find some alternative solution. Hope this helps!

[baentsch]

Thanks for the response, @RodriM11 ! As no further comments came for a long time I assume the issue is resolved. Please reopen if it didn't, @moganty .