bc-java

bc-java copied to clipboard

Starting JDK 16, JEP 396 (https://openjdk.java.net/jeps/396) will start enforcing strong encapsulation and deny reflective access to jdk internal classes. It is observed that BC provider relies on some jdk internal classes through reflection and fail as a result when switching to jdk 16. Below are a few examples of such illegal accesses reported by specifying "--illegal-access=debug" option: Illegal reflective access by org.bouncycastle.jcajce.provider.drbg.DRBG (file:) to constructor sun.security.provider.Sun() at org.bouncycastle.jcajce.provider.drbg.DRBG.findSource(Unknown Source) at org.bouncycastle.jcajce.provider.drbg.DRBG.(Unknown Source) at org.bouncycastle.jcajce.provider.drbg.DRBG$Mappings.configure(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider.loadAlgorithms(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider.setup(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider.access$000(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at org.bouncycastle.jce.provider.BouncyCastleProvider.(Unknown Source) at Interop.main(Interop.java:91)

Illegal reflective access by org.bouncycastle.jcajce.provider.drbg.DRBG (file::) to constructor sun.security.provider.SecureRandom() at org.bouncycastle.jcajce.provider.drbg.DRBG.findSource(Unknown Source) at org.bouncycastle.jcajce.provider.drbg.DRBG.(Unknown Source) at org.bouncycastle.jcajce.provider.drbg.DRBG$Mappings.configure(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider.loadAlgorithms(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider.setup(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider.access$000(Unknown Source) at org.bouncycastle.jce.provider.BouncyCastleProvider$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at org.bouncycastle.jce.provider.BouncyCastleProvider.(Unknown Source) at Interop.main(Interop.java:91)

Here is the recommended approach for detecting/fix such illegal accesses: Use an existing release, such as JDK 11, to test existing code with --illegal-access=warn to identify any internal elements accessed via reflection, then use --illegal-access=debug to pinpoint the errant code, and then finally test with --illegal-access=deny.

Thanks for the report. We've had a couple of reports of this, it's always gone back to getInstanceStrong() being misconfigured. Usually as an accidental side affect of removing the SunMSCAPI provider (which will disable access to Windows RNG). The reflective access is a last ditch attempt to try and find an entropy source in the JVM. I'll agree the way the problem manifests is not helpful to a user.

Java 8 made finding an entropy source a lot easier with the introduction of getInstanceStrong(). Is there a way to get access to the JVMs seed generator in Java 16?

The real source of the problem was the static SecureRandom.getSeed() which creates a new SecureRandom() under the hood, which in turn invokes the provider mechanism, which usually results in a stack overflow exception if the BC provider has been put first. Ideally (for us) there would be a way of just asking for a string of bytes as entropy, like getSeed() but without the need to create a SecureRandom. If we were able to do that there would be no need for the reflective code, even in the situation where getInstanceStrong() was not usable (actually we probably would not be using that either).

Inactive.