[EXTERNAL]Re: SecureRandom regression with certain security providers
Valerie Peng
valerie.peng at oracle.com
Tue Jul 7 01:14:26 UTC 2020
Ok, thank you John.
Valerie
On 7/6/2020 5:55 PM, John Mahoney wrote:
>
> Thank you Valerie. Unfortunately this will have to wait until John is
> back from vacation (back on the 13^th )
>
> *From:*Valerie Peng [mailto:valerie.peng at oracle.com]
> *Sent:* Monday, July 6, 2020 8:02 PM
> *To:* John Gray <John.Gray at entrustdatacard.com>;
> security-dev at openjdk.java.net
> *Cc:* John Mahoney <John.Mahoney at entrustdatacard.com>
> *Subject:* Re: [EXTERNAL]Re: SecureRandom regression with certain
> security providers
>
> BTW, I have tentatively filed
> https://bugs.openjdk.java.net/browse/JDK-8248885
> <https://bugs.openjdk.java.net/browse/JDK-8248885> for Entrust NSAE
> problem. Just FYI.
>
> Valerie
>
> On 7/6/2020 12:07 PM, Valerie Peng wrote:
>
> Hi John,
>
> 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.
>
> Please find my questions and comments in line below.
>
> On 7/3/2020 1:13 PM, John Gray wrote:
>
> 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.
>
> 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.
>
> If I change the highlighted line above (the last line) to the
> following, it works.
>
> Security.insertProviderAt(new Entrust(), 1);
>
> 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…..
>
> Yes, it's indeed strange. Is the "entrustCsp" instance being
> modified in anyway after its creation?
>
> When it fails, the type and algorithm are “SecureRandom” and
> “DRBGUsingSHA512”
>
> Is “DRBGUsingSHA512" the expected default algorithm for Entrust
> provider? Is it being picked up as expected if basing on
> registration ordering?
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> Thanks for looking into this~
>
> Valerie
>
> It looks like I **could** 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..
>
> Thanks for your help!
>
> Happy July 4^th (I live in Ottawa Canada, so we had our
> muted Canada day celebrations a couple days ago on July 1^st ).
>
> John Gray
>
> -----Original Message-----
> From: Valerie Peng [mailto:valerie.peng at oracle.com]
> Sent: Thursday, July 2, 2020 8:34 PM
> To: John Gray <John.Gray at entrustdatacard.com>
> <mailto:John.Gray at entrustdatacard.com>;
> security-dev at openjdk.java.net
> <mailto:security-dev at openjdk.java.net>
> Cc: John Mahoney <John.Mahoney at entrustdatacard.com>
> <mailto:John.Mahoney at entrustdatacard.com>; Muthu Kannappan
> <muthu at entrustdatacard.com> <mailto:muthu at entrustdatacard.com>
> Subject: Re: [EXTERNAL]Re: SecureRandom regression with
> certain security providers
>
> Hi John,
>
> Unfortunately this cannot wait til July 13th if this issue
> needs to be fixed for jdk 15.
>
> 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.
>
> Regards and an early happy July 4th,
>
> Valerie
>
> On 7/2/2020 3:17 PM, Valerie Peng wrote:
>
> > 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200706/a829a6e2/attachment.htm>
More information about the security-dev
mailing list