Hmm, there must be something else which Entrust provider does besides
the usual sequence of put(String, String) calls? The regression test
DefaultAlgo.java covers both the cases of pure legacy, i.e. put(String,
String) calls, and pure service providers, i.e. putService(...) calls.
Is there anything special that Entrust provider does which may lead to
this NSAE? This NSAE is thrown when the service mismatches what returned
by calling getService(...) on Entrust provider.
Regards,
Valerie
On 7/2/2020 1:57 PM, John Gray wrote:
Thanks for the quick reply!
We don't override the putService() or getService() calls in our Entrust
provider. Our provider has been around for a very long time (since JDK 1.2
days).
We use the key value mapping via put():
For example, your newer code must pick it up by looking at this mapping:
put("SecureRandom.DRBGusingSHA512","com.entrust.toolkit.security.crypto.random.DRBGusingSHA512");
I guess this is considered the "old style" from what I see in the e-mail thread
below. Our provider is FIPS certified and in the FIPS boundary, so having to make
changes to it breaks our FIPS certification which is always a pain.
I can certainly help you verify the fix. Let me know how I can help verify it
for you. 😊
Note: I will be on vacation next week, so I'll be back July 13th...
Cheers,
John Gray
-----Original Message-----
From: Valerie Peng <valerie.p...@oracle.com>
Sent: Thursday, July 2, 2020 4:37 PM
To: John Gray <john.g...@entrustdatacard.com>; security-dev@openjdk.java.net
Cc: John Mahoney <john.maho...@entrustdatacard.com>; Muthu Kannappan
<mu...@entrustdatacard.com>
Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security
providers
Hi John,
Thanks for the feedback, it certainly helps to know which providers are
affected to help us give this the right priority and the right fix.
So, does Entrust provider also override
Provider.putService()/getService() calls like BCFIPS provider does?
I am about to send out the webrev on this issue now and would like to make sure
the current fix would work with Entrust's scenario. Is it possible that you can
help verifying it? Or I can do it too if it does not require hardware setup.
Regards,
Valerie
On 7/2/2020 9:11 AM, John Gray wrote:
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
