<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Ok, thank you John.<br>
</p>
<p>Valerie<br>
</p>
<div class="moz-cite-prefix">On 7/6/2020 5:55 PM, John Mahoney
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR11MB2618534533339F39910167529A660@DM6PR11MB2618.namprd11.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<div class="WordSection1">
<p class="MsoNormal"><span>Thank you Valerie. Unfortunately
this will have to wait until John is back from vacation
(back on the 13<sup>th</sup>)</span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span> Valerie
Peng [<a class="moz-txt-link-freetext" href="mailto:valerie.peng@oracle.com">mailto:valerie.peng@oracle.com</a>]
<br>
<b>Sent:</b> Monday, July 6, 2020 8:02 PM<br>
<b>To:</b> 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>
<b>Cc:</b> John Mahoney
<a class="moz-txt-link-rfc2396E" href="mailto:John.Mahoney@entrustdatacard.com"><John.Mahoney@entrustdatacard.com></a><br>
<b>Subject:</b> Re: [EXTERNAL]Re: SecureRandom
regression with certain security providers</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p>BTW, I have tentatively filed <a
href="https://bugs.openjdk.java.net/browse/JDK-8248885"
moz-do-not-send="true">
https://bugs.openjdk.java.net/browse/JDK-8248885</a> for
Entrust NSAE problem. Just FYI.</p>
<p>Valerie</p>
<div>
<p class="MsoNormal">On 7/6/2020 12:07 PM, Valerie Peng wrote:</p>
</div>
<blockquote>
<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. </p>
<p>Please find my questions and comments in line below.</p>
<div>
<p class="MsoNormal">On 7/3/2020 1:13 PM, John Gray wrote:</p>
</div>
<blockquote>
<div>
<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.</p>
<blockquote>
<div>
<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?
</p>
<blockquote>
<div>
<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?
</p>
<blockquote>
<div>
<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 “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.
</p>
</div>
</blockquote>
<p class="MsoNormal">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>
<br>
</p>
<blockquote>
<div>
<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? </p>
<p>Thanks for looking into this~</p>
<p>Valerie</p>
<blockquote>
<div>
<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
href="mailto:valerie.peng@oracle.com"
moz-do-not-send="true">mailto:valerie.peng@oracle.com</a>]
<br>
Sent: Thursday, July 2, 2020 8:34 PM<br>
To: John Gray <a
href="mailto:John.Gray@entrustdatacard.com"
moz-do-not-send="true"><John.Gray@entrustdatacard.com></a>;
<a href="mailto:security-dev@openjdk.java.net"
moz-do-not-send="true">security-dev@openjdk.java.net</a><br>
Cc: John Mahoney <a
href="mailto:John.Mahoney@entrustdatacard.com"
moz-do-not-send="true"><John.Mahoney@entrustdatacard.com></a>;
Muthu Kannappan
<a href="mailto:muthu@entrustdatacard.com"
moz-do-not-send="true"><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>
</blockquote>
</div>
</blockquote>
</body>
</html>