New issue HW based providers (e.g. PKCS11) + SSL.

[Xuelei Fan]

Hi Jeroen,

Thanks for the report.  The issue now is tracked as

   https://bugs.openjdk.java.net/browse/JDK-8149017

Thanks,
Xuelei

On 2/10/2016 8:32 PM, Jeroen Cranendonk wrote:
> Hi!____
> 
> __ __
> 
> This issue has already been reported under review ID: JI-9029195, but I
> haven’t heard anything from it yet.____
> 
> So I thought I’d also try the mailing list. I would like to know at
> least if my analysis is correct :)____
> 
> __ __
> 
> I’ve been investigating an issue we ran into after a Java update on one
> of our products.____
> 
> I think it was introduced here:____
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/fe1c420a8982 or http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3e9d6880f36f____
> 
> The latter is the same change, re-applied. JDK 7 and 9 have the same
> change I think.____
> 
> This would be included in the JRE 'fix' #8081297: "Unable to process
> PreMasterSecret Tomcat issue", first seen in Java SE 7u85 b34,____
> 
> __ __
> 
> I think the issue is caused in RSAClientKeyExchange, because of this
> change:____
> 
>              Cipher cipher =
> JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1);____
> 
> -            cipher.init(Cipher.UNWRAP_MODE, privateKey,____
> 
> -                    new TlsRsaPremasterSecretParameterSpec(____
> 
> -                            maxVersion.v, currentVersion.v),____
> 
> -                    generator);____
> 
> -            preMaster = (SecretKey)cipher.unwrap(encrypted,____
> 
> -                                "TlsRsaPremasterSecret",
> Cipher.SECRET_KEY);____
> 
> +            needFailover = !KeyUtil.isOracleJCEProvider(____
> 
> +                                       
> cipher.getProvider().getName());____
> 
> +            if (needFailover) {____
> 
> +                cipher.init(Cipher.DECRYPT_MODE, privateKey);____
> 
> __ __
> 
> If you condense it, this :____
> 
>    Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1);____
> 
>    cipher.init(…);____
> 
> __ __
> 
> Has been changed to:____
> 
>    Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1);____
> 
> *   cipher.getProvider();____*
> 
>    cipher.init(…);____
> 
> __ __
> 
> The problem is that calling getProvider, or any method on a Cipher
> instance, forces it to skip the delayed provider selection which is
> built into Cipher.____
> 
> __ __
> 
> For details on delayed provider selection see the source code of Cipher:____
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/share/classes/javax/crypto/Cipher.java____
> 
> Especially the chooseFirstProvider() method, which also has debug
> logging for this specific case. (Using "-Djava.security.debug=jca" you
> should get the message "Cipher: Cipher.init() not first method called").____
> 
> __ __
> 
> In many cases this won’t cause a problem, but when using a hardware
> token based provider (e.g. PKCS11), this can cause SSL connections to
> fail being set up, especially if it’s not the first provider in the list
> of security providers. For my current customer this is a big problem,
> because they use hardware tokens for everything :)____
> 
> __ __
> 
> For anyone not familiar with delayed provider selection:____
> 
> It means that when a Cipher instance is created, it doesn’t know yet
> which provider it will be using, because we haven’t provided it with the
> key it should use yet. Once we call it’s init method, with the key to
> use, it is able to select a provider. It will try every available
> provider implementing the selected algorithm, and will keep trying until
> it find one which can use the key: It doesn’t throw a
> InvalidKeyException.____
> 
> This is important for hardware based providers like PKCS11, because they
> use key’s which are a handle to the key stored in hardware, and only
> their own Cipher can handle this key.____
> 
> __ __
> 
> I would really like to know if my assessment is accurate. I would also
> really like to know how to make sure this gets fixed in a timely manner
> (I understand that the most optimistic ‘timely’ would be the next JRE
> release, or the one after that) ;)____
> 
> __ __
> 
> I can readily provide more details, a self contained example is harder
> because a hardware based provider is required :)
> 
> 
> Thank you for your attention!____
> 
> 
> ____
> 
> Cheers,____
> 
> Jeroen Cranendonk
> 
>