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

Thu Mar 14 17:12:48 UTC 2019

Hello Bernd, once again I appreciate your comments and have some of my 
own in-line,

On 3/14/2019 9:30 AM, Bernd Eckenfels wrote:
>
> 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.
>
JN: Is there no case?  None that I'm aware of, none that have caused any 
bugs that I know of - the SecretKey object is made within SunJCE's 
PBKDF2KeyImpl code (looks like it is just a SecretKey wrapper around the 
password bytes).  It seems like it should work for pretty much any 
password handed in AFAICT.

If you were going to have a FIPS keystore come into play, why would you 
not use that 3rd party provider for the PBKDF2 SecretKeyFactory in its 
entirety?  That way the resulting SecretKey from a generation operation 
would hopefully live on the FIPS keystore serviced by that provider.  
For SunJCE I think you'd end up having a SecretKey that lived in SunJCE 
since you're only going to a 3rd party provider for the HMAC 
calculations.  It just feels a little odd to hang a security argument on 
a 3rd party provider for HMAC, but be willing to do the encompassing 
PBKDF2 on SunJCE.

All that said, I think even if HMAC is obtained from SunJCE, the 
underlying MessageDigest probably would come from that 3rd party 
provider.  But of course there's no key involved, no init to be done, so 
it's less prone to going wonky.
>
> 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)
>
JN: An option, certainly, but one that would mean at least an API change 
to PBEKeySpec so the Mac could be passed into the SecretKeyFactory.  
That would require much more careful consideration and it would prevent 
backporting this bugfix since PBEKeySpec is set in stone for any 
released JDK.

> 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.
>
JN: Generally yes, but not for a case where you ask explicitly for 
PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm, 
String provider).  That's what happened when the bug occurred. While I 
don't think it would happen otherwise on BC FIPS (I haven't checked but 
I assume it has PBKDF2WithHmacSHA1), it is possible for automatic 
selection to land on SunJCE for that SKF algorithm if some other higher 
priority provider doesn't have PBKDF2WithHmacSHA1, but does have 
HmacSHA1 with some FIPS-like key restrictions (which seems like a 
realistic possibility).
>
> I thin I havent seen what the case for the init falure in BC MAC was, 
> is this also key related?
>
JN: If you look at the original bug the stack trace is there.  In short 
BC is throwing org.bouncycastle.crypto.IllegalKeyException because the 
key that is being handed to it while running in FIPS mode is less than 
112 bits (according to the exception message).
>
> Gruss
>
> Bernd
>
> -- 
> http://bernd.eckenfels.net
>
> *Von: *Jamil Nimeh <mailto:jamil.j.nimeh at oracle.com>
> *Gesendet: *Donnerstag, 14. März 2019 17:18
> *An: *Bernd Eckenfels <mailto:ecki at zusammenkunft.net>; OpenJDK Dev 
> list <mailto:security-dev at openjdk.java.net>
> *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 <mailto:jamil.j.nimeh at oracle.com>
>     *Gesendet: *Donnerstag, 14. März 2019 16:36
>     *An: *OpenJDK Dev list <mailto:security-dev at openjdk.java.net>
>     *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.java.net/pipermail/security-dev/attachments/20190314/9e2e0e48/attachment.html>