Hi Valerie, I noticed this looked related to the Secure Random issue (https://bugs.openjdk.java.net/browse/JDK-8246383) and I noticed you had ported back the work-around you mentioned to me a few weeks ago. So I thought I would give it a try with the 11.08 pre-release since you had listed it backported to that stream.
I get a different error that looks like the identical error to (https://bugs.openjdk.java.net/browse/JDK-8248505) and the stack trace looks almost identical: Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219) at java.base/javax.crypto.JceSecurity.<clinit>(JceSecurity.java:80) ... 8 more Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider Entrust: Entrust: SecureRandom.DRBGusingSHA512 -> com.entrust.toolkit.security.crypto.random.DRBGusingSHA512 at java.base/java.security.Provider$Service.newInstance(Provider.java:1855) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) ... 10 more It looks like you are already looking at the issue, so I just thought I would let you know that it is affecting us as well. Cheers, John Gray -----Original Message----- From: security-dev [mailto:security-dev-r...@openjdk.java.net] On Behalf Of Valerie Peng Sent: Monday, June 29, 2020 4:56 PM To: security-dev@openjdk.java.net Subject: [EXTERNAL]Re: SecureRandom regression with certain security providers WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Hi Ioannis, Thanks for reporting this issue and the detailed info. I've filed https://bugs.openjdk.java.net/browse/JDK-8248505 for this. It seems that this is mostly due to the mixing of both legacy and service-based registration in the BC provider not working well with the fix in JDK-8246613. Another possible fix may be to prefer the SecureRandom service object from the putService call. Anyway, I will take a look. Regards, Valerie On 6/28/2020 10:14 PM, Ioannis Kakavas wrote: > Hi folks, > > Since the latest changes to SecureRandom[0], using certain ( I can reproduce > with one but others might have the same issue, see below ) security > providers, it is impossible to get an instance of SecurityRandom. The > following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: > > public class TestSecureRandom { > > public static void main(String[] args){ > assert Security.getProviders()[0].getName().equals("BCFIPS"); > SecureRandom random = new SecureRandom(); > } > } > > will fail with > > Exception in thread "main" java.lang.RuntimeException: > java.security.NoSuchAlgorithmException: Service not registered with Provider > BCFIPS: BCFIPS: SecureRandom.DEFAULT -> > org.bouncycastle.jcajce.provider.random.DefSecureRandom > attributes: {ImplementedIn=Software} > > at > java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) > at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219) > at TestSecureRandomBug.main(TestSecureRandomBug.java:8) > Caused by: java.security.NoSuchAlgorithmException: Service not registered > with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> > org.bouncycastle.jcajce.provider.random.DefSecureRandom > attributes: {ImplementedIn=Software} > > at > java.base/java.security.Provider$Service.newInstance(Provider.java:1857) > at > java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) > ... 2 more > > > I reported this to the authors of the security provider [2] and I will share > part of the analysis on why this fails here for the sake of completeness of > the report. > > The BCFIPS security provider overrides getService() and getServices() of > Provider and it has its own extension of the Provider.Service which > getService() returns. > However, getDefaultSecureRandomService() will always return a > java.security.Provider.Service and since we are calling newInstance > [3] on it, this fails as the > > if (provider.getService(type, algorithm) != this) { > throw new NoSuchAlgorithmException("Service not registered with > Provider " + provider.getName() + ": " + this); } > > can not be true. getService will return a > org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and > `this` is a java.security.Provider.Service. > > > I am not aware of other providers being affected by this ( the non FIPS > BouncyCastle Provider is not, since it's a legacy style security provider ) > but given the reason for the issue, I think there might be others affected. > With [0] being backported to all supported versions and BCFIPS being one of > the few available security providers that is FIPS 140-2 approved, this > introduces a significant issue for folks with fips compliance requirements. > > One potential fix that was proposed in [2] was to replace > > if (prngServices != null && !prngServices.isEmpty()) { > return prngServices.iterator().next(); > } > > with: > > if (prngServices != null && !prngServices.isEmpty()) { > Service rng = prngServices.iterator().next(); > return getService(rng.getType(), rng.getAlgorithm()); > } > > so that any provider extending Service, could work fine. > > Best Regards > Ioannis > > > [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff > [1] https://www.bouncycastle.org/fips-java/ > [2] > http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue- > in-BCFIPS-and-latest-JDK15-td4659964.html > [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55
