Is there a practical way to determine which JCE crypto providers are in use?

Question

We have configured a Java product to use only FIPS-validated RSA JCE crypto providers. However, the product won't work when only the RSA libraries are listed in java.security. Therefore, something is requesting non-FIPS algorithms from another provider.

By the process of elimination, we can tell which jars are necessary for successful operation, but that doesn't tell us which algorithms are being requested, or by whom.

This seems like a frequently asked question, but evidently we haven't stumbled on the right documentation or Google search string: Is there any reliable, convenient, and consistent mechanism to determine which JCE providers are being used in a running JVM instance?

Applause

Answer 1

Well you can enumerate providers using Security.getProviders();

Here's an example listing providers and the algorithms they implement.

Acoustic

Thank you Bruno. Having this list is helpful, but I'm still at a loss to determine which clients are receiving which algorithms from which providers at run-time. The product needs to run only with FIPS-certified algorithms, or if that is not possible, we have to be able to explain/justify which clients are not, and why not. So far, we have not discovered a means to obtain that information. – Applause

No idea tbh, save instrumenting the code at runtime which seems quite the blunt weapon. – Thailand

Answer 2

To complement @Bruno's answer you can use jshell and type in

java.security.Security.getProviders();

Here's an example of how to do it with Docker

$ echo "java.security.Security.getProviders();" | docker run -i --rm amazoncorretto:17 jshell
May 11, 2022 10:29:57 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
|  Welcome to JShell -- Version 17.0.3
|  For an introduction type: /help intro

jshell> java.security.Security.getProviders()$1 ==> Provider[12] { 
  SUN version 17, 
  SunRsaSign version 17, 
  SunEC version 17, 
  SunJSSE version 17, 
  SunJCE version 17, 
  SunJGSS version 17, 
  SunSASL version 17, 
  XMLDSig version 17, 
  SunPCSC version 17, 
  JdkLDAP version 17, 
  JdkSASL version 17, 
  SunPKCS11 version 17 }

jshell>

Predispose

Answer 3

I'll suggest implementing your own ClassLoader, and have it log debug information.

Though, I'm not sure whether that will let you know about every class that loads FooJCEProvider, and not just the first class to load FooJCEProvider.

Alternately, have you tried to use jconsole? "the class loading MBean also has the Verbose attribute, which can be set to enable or disable class loading verbose tracing"

Worth

I perked up momentarily when you mentioned the ClassLoader, but as you point out, that could have some shortcomings as well. I think I'll still investigate further though, to see what the actual behavior is. – Applause

Answer 4

As Bruno stated, you can iterate through all the providers.

At run-time you can check which provider your Cipher is using with the getProvider method.

Complected

Perhaps I wasn't clear enough in my original post... This is a third party product, that we need to configure to use FIPS validated providers only (RSA). Since the product won't run correctly with only RSA installed in the JRE, we are trying to determine which features/components are using the non-FIPS providers. This has to be done "from the outside" of a rather complex product, which includes services/daemons, as well as Eclipse-based and browser-based GUI elements. Our original attempt to create our own JCE provider to "hook" crypto engine requests was not successful. – Applause

Answer 5

Does System.setProperty("javax.net.debug","all") give you anything useful?

Thousandfold

Thanks Dave, but no, that doesn't seem to provide the kind of information we're looking for (we're using more than just SSL/TLS). What we're really looking for, I suppose, is a "hook" in JCE that would give us a stack trace (or something) that would indicate which cyphers are being allocated two what (or whom). The JCE architecture doesn't seem to support that kind of behavior. – Applause