0

I am implementing a cloud solution for an extension to my companies automated call system. To do so, I need to encrypt the user data that is communicated between our on premises database and Amazon Web Service. I have implemented AES encryption on both sides but found that our Cisco JRE is running Java 7 and requires that I update our JRE to allow Unlimited Strength Cryptography.

My solution was found here: Java Security: Illegal key size or default parameters?

Based off of my research, I do not foresee any problems updating this policy as this is essentially removing a "MAX_LENGTH" global variable. But as this is my first time delving into this type of java development I want to double check. Are there any considerations or potential issues that I may encounter when updating our Java 7 JRE security policy to Unlimited Strength Cryptography?

Jacob C
  • 53
  • 1
  • 7
  • 1
    The only issue I'm aware of is whether you violate the export restrictions, which is a legal issue. See the `README.txt` file. There should be no issues with the code. – Andreas Aug 14 '19 at 16:45
  • Our product will not be exported so that wont be an issue. Am I correct in my analysis that this is essentially removing a restriction/limit and nothing else? – Jacob C Aug 14 '19 at 16:47
  • 1
    Correct. It simply makes stronger ciphers available. If you run [this code](https://stackoverflow.com/a/34403337/5221149) before and after applying the new policy files, you'll see the difference. – Andreas Aug 14 '19 at 16:49
  • You're using an antiquated Java version for security sensitive applications. The security policy files will not have a negative impact, but what about the Java version itself? You do understand that it probably doesn't receive any security updates anymore, right? How do you know that you're not vulnerable against buffer overruns in the native code, to name just one possible issue? – Maarten Bodewes Aug 14 '19 at 21:30

1 Answers1

2

Andreas @https://stackoverflow.com/users/5221149/andreas is correct. It is only a legal issue in the first part. Not all encryption methods/chipers are legal worldwide. Some countries do not allow the distribution of software with strong-encryption because of reasons. (most times a political decision between: security and control v.s. privacy)

Please make sure you don't distribute strong-encryption software to these countries and violate their law.

I would say: Unless you are developing cryptographic algorithms yourself or debug these you won't see any difference in your programm's behaviour.

In my experience the JCE Unlimited Strength Cryptography is needed most times if you have server-client communications with a webserver that supports only "strong" TLS/SSL ciphers. (a webserver admin can define the supported SSL/TLS ciphers, it is good practice to keep multiple options to get nearly 99% of the clients, however it depends on the provided webservice and how secure and up-to-date you want your SSL/TLS connections)

The JCE Unlimited Strength Cryptography policy files for java8 oracle can be found here: https://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

for java7 oracle use this one instead: https://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

PS: from java9 oracle the JCE Unlimited Strength Cryptography policy files will be shipped and enabled by default. For all openJDK java versions they are enabled by default as well. See here https://github.com/open-eid/cdoc4j/wiki/Enabling-Unlimited-Strength-Jurisdiction-Policy

zeg
  • 432
  • 2
  • 9