JDK-8182386 : Crypto keys should be compatible between security providers
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2017-06-16
  • Updated: 2024-08-02
  • Resolved: 2024-08-02
Related Reports
Relates :  
JDK-8176183 - sun/security/mscapi/SignedObjectChain.java fails on Windows
Relates :  
JDK-8182388 - Backout 8182143
Relates :  
JDK-8064330 - Remove SHA224 from the default support list if SunMSCAPI enabled
Description
For example, if may not work if a key was generated by one provider, and then it's used for signing with another provider. Revert the following change to reproduce the issue

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a3276d8711b7

The test is going to fail on Windows when SunMSCAPI provider is enabled. See JDK-8176183 for details.
Comments
JDK-8064330 is more like algorithm incompatibility; it's due to a provider not supporting the list of algorithms needed by the JSSE cipher suites. One possible solution is for JSSE to find a provider supporting the requested algorithm and then use that provider to generate key also. As for key compatibility, not all provider would export keys (or expose key materials for other providers to reconstruct a key object) due to various reasons. FIPS providers need to keep the key material within its crypto boundary and native providers such as SunMSCAPI may not have support for extracting the key materials. Thus, it may not be possible to require keys be compatible among all providers. Closing this as "Will Not Fix".
02-08-2024
Updated Artem's link. Original work was done in jdk9/dev, but landed in jdk9/jdk9. This issue causes hacks like the following: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/82ed25c3cea9/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java#l415 We have to enable only algorithms which are supported by all providers which is hard and limit functionality.
10-04-2024
The hg link in Artem's comment is no longer accessible. The correct link is https://hg.openjdk.org/jdk9/jdk9/jdk/file/82ed25c3cea9/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java#l415
10-04-2024
The description is not quite right. The underlying providers should throw exception when it can't use given key or convert it to some key it can use. JCA will fail over to the remaining providers until one which accepts the given key. If none of providers accepts the given key, the call will fail.
28-02-2019
Comment from Bernd (ecki@zusammenkunft.net) in OpenJDK: http://mail.openjdk.java.net/pipermail/security-dev/2017-June/016016.html ------------------------------------------ I think the new bug description is backward, as you cannot expect to implement all algorithms in all providers or use a key class fron one provider in antoher (especially not if they use mechanisms in external APIs like PKCS11 or MSCAPI with HSM). "Crypto keys should be compatible between security providers" https://bugs.openjdk.java.net/browse/JDK-8182386 So the limiting of ciphers should be based on the actual provider used (or key selected) and not based on the subset of all providers present. Maybe something like "JSSE should adjust available ciphers based on effective provider". Its just a question how the current api can support that (this is also somewhat related to the point of key usage flags which also may restrict some ciphers which is only known until the actual Key instance can be examined). ------------------------------------------
17-06-2017
This issue causes hacks like the following: http://hg.openjdk.java.net/jdk9/dev/jdk/file/82ed25c3cea9/src/java.base/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java#l415 We have to enable only algorithms which are supported by all providers which is hard and limit functionality.
16-06-2017