Short version:
Is it expected to need to add policies to OpenJDK JRE java.policy in order to use JCE crypto library in a default installation from IcedTea-Web? Is it some sort of bug??
Long version:
I have this Swing app loaded thru WebStart which I'm trying to use with OpenJDK8 (either RedHat, AdoptOpenJDK or Coretto variants) + IcedTea WebStart (downloaded from here). Everything in my Swing app works but one panel.
I get some encrypted text stored somewhere and I decrypt it to be presented in a TextField using the following method:
public synchronized static String decrypt(String toDecrypt, byte[] key) {
Key keySpec = new SecretKeySpec(key, "AES");
try {
CIPHER.init(Cipher.DECRYPT_MODE, keySpec);
return new String(CIPHER.doFinal(toBytes(toDecrypt)));
}
catch (Exception e) {
throw new RuntimeException(e);
}
}
The panel where this process is done decrypts on load and it fails to load in the IcedTea-web included in RedHat OpenJDK (v1.7 I think) with an error saying:
at javax.crypto.Cipher.getInstance(Cipher.java:539) Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES
... 45 more
Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
I tried the code in this answer on Linux and Windows installations of OpenJDK and it says there's a difference in the providers available.
For Windows:
- SunPCSC version 1.8
- XMLDSig version 1.8
- SunSASL version 1.8
- SunJGSS version 1.8
- SunJSSE version 1.8
- SunEC version 1.8
- SunRsaSign version 1.8
- SUN version 1.8
For linux:
- SUN version 1.8
- SunRsaSign version 1.8
- SunEC version 1.8
- SunJSSE version 1.8
- SunJCE version 1.8
- SunJGSS version 1.8
- SunSASL version 1.8
- XMLDSig version 1.8
- SunPCSC version 1.8
SO, it seems to have the JCE missing.
I tried up to the last IcedTeaWeb available (v1.8) and all of them have the full list of providers configured by default:
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
Also the security policy unlimited
# Note: This property is currently used by the JDK Reference implementation.
# It is not guaranteed to be examined and used by other implementations.
#
crypto.policy=unlimited
BUT they seem to lack permissions for WebStart because I can decrypt and open the panel running the app from IntelliJ (no WebStart environment).
Finally, only on the last IcedTea-WebStart version (v1.8) I got an additional error message while loading the panel:
Denying permission: ("java.lang.RuntimePermission" "loadLibrary.sunmscapi")
Denying permission: ("java.security.SecurityPermission" "putProviderProperty.SunJCE")
It led me to try and add permissions in java.policy
permission java.security.SecurityPermission "putProviderProperty.SunJCE";
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.internal.spec";
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.rsa";
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.internal.interfaces";
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
And this way, my app finally works at last. But, as this is not documented anywhere, is it right to configure it this way? Am I setting up an insecure configuration? Is this something that should be fixed in OpenJDK? Thanks.
