Issue using security providers in OpenJDK

[alfabravoteam]

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 OpenJDK8 installation from IcedTea-Web? Is it some sort of bug or misconfiguration in the Windows versions of OpenJDK?? Sorry if this is not the right place to ask for this, dunno which project should get this one.

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 SO 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.

[karianna]

I'd try with ITW 1.8.3 downloaded from adoptopenjdk.net

[alfabravoteam]

No joy. Same permission denied to use JCE classes. It only works by adding those lines in the JRE's lib/security/java.policy file.

[patris70]

Hi @alfabravoteam,

I had problem with Java crypto and worked for me, try this: Copy both US_export_policy.jar and local_policy.jar from lib\security\policy\unlimited folder direct to lib\security folder

[judovana]

@alfabravoteam hi! I need to settle few things: "in IntelliJ it works" This can be misleading, as idea can have JDK embedded. Are you sure yours do not have? If you are unsure, can you try the application as plain /jre/your/javaws/is/using/java -cp your_jar your_main ? If it works, can you run it with security manager on? Can you extract your code to minimal working example? Are you bound to jce provider? Is it possibel your aes key is to short or exact algorithm disabled(see java.security)? Is your application signed? Does it require some permissions?