AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.

Thu Mar 14 16:30:52 UTC 2019

Hello,

is there no case where the passed-in key cannot be used by the SunJCE provider? Isnt that a main reason to use an alternative Provider and PKCS11 especially? I think similiar could be said for MSCAPI (but I think they have no keyhandles for secret keys) or other FIPS Keystores which do not allow to Export key material.

One Option would be to make the Mac an Parameter, then at least new Code could specify different implementers. It still would break existing PKCS11 deployments (at least for those where the keymaterial is not exportable)

I would argue that the case when you use a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway.

I thin I havent seen what the case for the init falure in BC MAC was, is this also key related?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Jamil Nimeh
Gesendet: Donnerstag, 14. März 2019 17:18
An: Bernd Eckenfels; OpenJDK Dev list
Betreff: Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.

Hi Bernd, thanks for the feedback, comments below:
On 3/14/19 8:58 AM, Bernd Eckenfels wrote:
Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval?

(I think the change is good in General but that case Needs to be decided).
JN: Yes, there is definitely an approval process which is in progress.  The CSR link in the original email is the approval process for a behavioral change like this.  The fix itself, even if it is good, won't go back until the CSR is approved.
As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers.  And for a long time this worked.  But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail.  And it fails not because the PRF algorithm isn't found, it fails on init.  If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure.  There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence.
There's no easy way get the best of both worlds.  By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly).  So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case).
Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2.  The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE.

Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature.

Gruss
Bernd

* OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf 
-- 
http://bernd.eckenfels.net

Von: Jamil Nimeh
Gesendet: Donnerstag, 14. März 2019 16:36
An: OpenJDK Dev list
Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.

Hello all,

This review will change the SunJCE implementation of PBKDF2 so that it 
always uses the SunJCE version of the PRF algorithm internally.

Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/

JBS: https://bugs.openjdk.java.net/browse/JDK-8218723

CSR: https://bugs.openjdk.java.net/browse/JDK-8220531

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190314/3c1f2fc3/attachment.htm>