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.ni...@oracle.com>
*Gesendet: *Donnerstag, 14. März 2019 17:18
*An: *Bernd Eckenfels <mailto:e...@zusammenkunft.net>; OpenJDK Dev
list <mailto:security-dev@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.ni...@oracle.com>
*Gesendet: *Donnerstag, 14. März 2019 16:36
*An: *OpenJDK Dev list <mailto:security-dev@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
