<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Symbol";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thank you Valerie. Unfortunately this will have to wait until John is back from vacation (back on the 13<sup>th</sup>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Valerie Peng [mailto:valerie.peng@oracle.com]
<br>
<b>Sent:</b> Monday, July 6, 2020 8:02 PM<br>
<b>To:</b> John Gray <John.Gray@entrustdatacard.com>; security-dev@openjdk.java.net<br>
<b>Cc:</b> John Mahoney <John.Mahoney@entrustdatacard.com><br>
<b>Subject:</b> Re: [EXTERNAL]Re: SecureRandom regression with certain security providers<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>BTW, I have tentatively filed <a href="https://bugs.openjdk.java.net/browse/JDK-8248885">
https://bugs.openjdk.java.net/browse/JDK-8248885</a> for Entrust NSAE problem. Just FYI.<o:p></o:p></p>
<p>Valerie<o:p></o:p></p>
<div>
<p class="MsoNormal">On 7/6/2020 12:07 PM, Valerie Peng wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p>Hi John,<o:p></o:p></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. <o:p></o:p></p>
<p>Please find my questions and comments in line below.<o:p></o:p></p>
<div>
<p class="MsoNormal">On 7/3/2020 1:13 PM, John Gray wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.
<o:p></o:p></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.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoPlainText">If I change the highlighted line above (the last line) to the following, it works.<o:p></o:p></p>
<p class="MsoPlainText"> Security.insertProviderAt(new Entrust(), 1);<o:p></o:p></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…..<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoPlainText">Yes, it's indeed strange. Is the "entrustCsp" instance being modified in anyway after its creation?
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoPlainText">When it fails, the type and algorithm are “SecureRandom” and “DRBGUsingSHA512”
<o:p></o:p></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?
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.
<o:p></o:p></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>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.
<o:p></o:p></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? <o:p></o:p></p>
<p>Thanks for looking into this~<o:p></o:p></p>
<p>Valerie<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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..<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Thanks for your help! <o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></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>).
<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">John Gray<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Valerie Peng [<a 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 href="mailto:John.Gray@entrustdatacard.com"><John.Gray@entrustdatacard.com></a>;
<a href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><br>
Cc: John Mahoney <a href="mailto:John.Mahoney@entrustdatacard.com"><John.Mahoney@entrustdatacard.com></a>; Muthu Kannappan
<a href="mailto:muthu@entrustdatacard.com"><muthu@entrustdatacard.com></a><br>
Subject: Re: [EXTERNAL]Re: SecureRandom regression with certain security providers<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Hi John,<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Unfortunately this cannot wait til July 13th if this issue needs to be fixed for jdk 15.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></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.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Regards and an early happy July 4th,<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Valerie<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">On 7/2/2020 3:17 PM, Valerie Peng wrote:<o:p></o:p></p>
<p class="MsoPlainText">> I can certainly help you verify the fix. Let me know how I can help
<o:p></o:p></p>
<p class="MsoPlainText">> verify it for you. <span style="font-family:"Segoe UI Symbol",sans-serif">
😊</span><o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note: I will be on vacation next week, so I'll be back July 13th...
<o:p></o:p></p>
</div>
</blockquote>
</blockquote>
</div>
</body>
</html>