<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>BTW, I have tentatively filed
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8248885">https://bugs.openjdk.java.net/browse/JDK-8248885</a> for Entrust NSAE
problem. Just FYI.</p>
<p>Valerie<br>
</p>
<div class="moz-cite-prefix">On 7/6/2020 12:07 PM, Valerie Peng
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:405c49ec-8295-49a2-f7e4-002b393a05c3@oracle.com">
<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"
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 class="moz-txt-link-rfc2396E"
href="mailto:John.Gray@entrustdatacard.com"
moz-do-not-send="true"><John.Gray@entrustdatacard.com></a>;
<a class="moz-txt-link-abbreviated"
href="mailto:security-dev@openjdk.java.net"
moz-do-not-send="true">security-dev@openjdk.java.net</a><br>
Cc: John Mahoney <a class="moz-txt-link-rfc2396E"
href="mailto:John.Mahoney@entrustdatacard.com"
moz-do-not-send="true"><John.Mahoney@entrustdatacard.com></a>;
Muthu Kannappan <a class="moz-txt-link-rfc2396E"
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>
</body>
</html>