<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi John,</p>
<p>Thanks for looking into this on your end. It's interesting how
Entrust has to do this deletion/re-insertion of providers and it's
interesting that adding a new instance of Entrust provider inside
the Security.insertProviderAt() call makes this problem go away. <br>
</p>
<p>Please find my questions and comments in line below.</p>
<div class="moz-cite-prefix">On 7/3/2020 1:13 PM, John Gray wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR11MB2585921E11E2DEB577A5C9CEEE6A0@DM6PR11MB2585.namprd11.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<div class="WordSection1">
<p class="MsoPlainText">Thanks for your comments! They sparked
off a lot more investigation on my end. I created a test
provider and could not reproduce the issue. That led me to
investigate how our provider was being installed. We use our
own internal Initializer() class to install providers in
various orders (we have had to work around bugs in different
JVM's in the past). That work-around required we remove the
provider from the Security provider list (basically to clean
it out), then we run a simple crypto test with a new
instantiation, and then install that provider in 1st
position.
</p>
</div>
</blockquote>
<p>Does this Initializer() class does all this before the new
SecureRandom() call? Does the Entrust provider remove or changes
its registrations ever, i.e. is the provider mutable? One possible
scenario for legacy provider which add/remove registrations is
that every update to the legacy map will leads to new re-parsing
and new service being created as a result which may leads to
failing the check inside Service.newInstance() call and thus the
NSAE.<br>
</p>
<blockquote type="cite"
cite="mid:DM6PR11MB2585921E11E2DEB577A5C9CEEE6A0@DM6PR11MB2585.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoPlainText">If I change the highlighted line above
(the last line) to the following, it works.</p>
<p class="MsoPlainText">
Security.insertProviderAt(new Entrust(), 1);</p>
<p class="MsoPlainText">Having to make such a change seems
strange. It seems that creating a new provider, using it to
get an instance of an algorithm, and then adding that same
provider into first position doesn’t work. I'm guessing
because of the recent changes you made the provider can’t be
used before it is inserted into the provider order because it
may hold onto some data from the previous usage? So this led
me to investigate some more…..</p>
</div>
</blockquote>
<p class="MsoPlainText">Yes, it's indeed strange. Is the
"entrustCsp" instance being modified in anyway after its creation?
<br>
</p>
<blockquote type="cite"
cite="mid:DM6PR11MB2585921E11E2DEB577A5C9CEEE6A0@DM6PR11MB2585.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoPlainText">When it fails, the type and algorithm
are “SecureRandom” and “DRBGUsingSHA512”
</p>
</div>
</blockquote>
<p>Is “DRBGUsingSHA512" the expected default algorithm for Entrust
provider? Is it being picked up as expected if basing on
registration ordering? <br>
</p>
<blockquote type="cite"
cite="mid:DM6PR11MB2585921E11E2DEB577A5C9CEEE6A0@DM6PR11MB2585.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoPlainText">The Provider.getService() code fails to
match the “previousKey” ServiceKey type and algorithms. In
my test code I was testing an AES algorithm, so the previous
key type and Algorithm is “Cipher” and “<span>AES/CBC/PKCS5PADDING”
in the getService() call which doesn’t match the type
“SecureRandom” and “DRBGUsingSHA512”. So it looks like
there is a bug caused by holding on to existing data.
</span></p>
</div>
</blockquote>
The previousKey is just an optimization to avoid repetitive
allocation on the same type and algorithm. If either of these two
does not match, it will be discarded and new key object created for
subsequent calls. So, this should not be the root cause.<br>
<blockquote type="cite"
cite="mid:DM6PR11MB2585921E11E2DEB577A5C9CEEE6A0@DM6PR11MB2585.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoPlainText">So I think when I create a brand new
Entrust() instance it works because the previous ServiceKey()
contains the correct data and it matches. Debugging showed
it to work that way. So I think using a provider before
installing it in the provider order is what is causing the
issue because of internal data in the Provider class.
</p>
</div>
</blockquote>
<p>There is something deeper for the Entrust NSAE problem instead of
the previousKey usage per my comment above. Could you please
double check the Initializer class and whether the Entrust
provider entries are modified after it's constructed and when new
SecureRandom() is called? <br>
</p>
<p>Thanks for looking into this~</p>
<p>Valerie<br>
</p>
<blockquote type="cite"
cite="mid:DM6PR11MB2585921E11E2DEB577A5C9CEEE6A0@DM6PR11MB2585.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoPlainText">It looks like I *<b>could</b>* put in
this weird work-around (just create a fresh instance of
Entrust()) when installing the provider to work around the
issue, but I wonder if there will be other consequences
because of the way this previousKey is used? I can make the
simple change to our toolkit without breaking FIPS (the
initialization class is not in the FIPS boundary). In fact,
I assume I don’t need to keep that old work-around for the old
IBM JVM anymore either..</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Thanks for your help! </p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Happy July 4<sup>th</sup> (I live in
Ottawa Canada, so we had our muted Canada day celebrations a
couple days ago on July 1<sup>st</sup>).
</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">John Gray</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Valerie Peng [<a class="moz-txt-link-freetext" href="mailto:valerie.peng@oracle.com">mailto:valerie.peng@oracle.com</a>] <br>
Sent: Thursday, July 2, 2020 8:34 PM<br>
To: John Gray <a class="moz-txt-link-rfc2396E" href="mailto:John.Gray@entrustdatacard.com"><John.Gray@entrustdatacard.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><br>
Cc: John Mahoney <a class="moz-txt-link-rfc2396E" href="mailto:John.Mahoney@entrustdatacard.com"><John.Mahoney@entrustdatacard.com></a>;
Muthu Kannappan <a class="moz-txt-link-rfc2396E" href="mailto:muthu@entrustdatacard.com"><muthu@entrustdatacard.com></a><br>
Subject: Re: [EXTERNAL]Re: SecureRandom regression with
certain security providers</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Hi John,</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Unfortunately this cannot wait til July
13th if this issue needs to be fixed for jdk 15.</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Maybe you can try the webrev out or
share more details on how Entrust provider does its
registration and what Provider APIs it overrides. I need more
info to help identifying the trigger for the NSAE in Entrust's
case. I have verified that the current webrev works with
BCFIPS provider.</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Regards and an early happy July 4th,</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Valerie</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">On 7/2/2020 3:17 PM, Valerie Peng wrote:</p>
<p class="MsoPlainText">> I can certainly help you verify the
fix. Let me know how I can help
</p>
<p class="MsoPlainText">> verify it for you. <span>
😊</span></p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> Note: I will be on vacation next
week, so I'll be back July 13th...
</p>
</div>
</blockquote>
</body>
</html>