blocks|key|1280321|text|在安装程序期间，只需提示用户并下载DOS批处理脚本或Bash+shell脚本，然后将JCE复制到适当的系统位置即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1280322|我曾经不得不为服务器run服务这样做，而不是一个正式的安装程序，我只提供了脚本来设置应用程序，然后用户就可以运行它。您可以将应用程序设置为不可运行，直到它们运行安装脚本。您还可以让应用程序抱怨JCE丢失，然后要求下载并重新启动应用程序？|1280323|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

During installation of your program, just prompt the user and have a DOS Batch script or a Bash shell script download and copy the JCE into the proper system location.

I used to have to do this for a server webservice and instead of a formal installer, I just provided scripts to setup the app before the user could run it. You can make the app un-runnable until they run the setup script. You could also make the app complain that the JCE is missing and then ask to download and restart the app?

blocks|key|1280400|text|对于我们的应用程序，我们有一个客户端-服务器架构，并且我们只允许在服务器级别解密/加密数据。因此，这里只需要JCE文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1280401|我们还有另一个问题，我们需要在客户端机器上更新一个安全jar，通过JNLP，它会在第一次运行时覆盖${java.home}/lib/security/和JVM中的库。|offset|length|style|CODE|1280402|这让它起作用了。|1280403|entityMap^0|0|1D|Q|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

For our application, we had a client server architecture and we only allowed decrypting/encrypting data in the server level. Hence the JCE files are only needed there. 

We had another problem where we needed to update a security jar on the client machines, through JNLP, it overwrites the libraries in<code>${java.home}/lib/security/</code> and the JVM on first run. 

That made it work.

blocks|key|1280460|text|有关替代密码库的信息，请查看Bouncy+Castle。它有AES和许多附加功能。它是一个自由的开源库。不过，您必须使用轻量级、专有的Bouncy+Castle+API才能正常工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1280461|entityMap|0|LINK|mutability|MUTABLE|url|http://www.bouncycastle.org/^0|E|D|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

For an alternative cryptography library, have a look at <a href="http://www.bouncycastle.org/" rel="noreferrer">Bouncy Castle</a>. It has AES and a lot of added functionality. It's a liberal open source library. You will have to use the lightweight, proprietary Bouncy Castle API for this to work though.

blocks|key|1280510|text|据我所知，Bouncy+Castle仍然需要安装罐子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1280511|我做了一个小测试，似乎证实了这一点：|1280512|http://www.bouncycastle.org/wiki/display/JA1/Frequently%2BAsked%2BQuestions|offset|length|1280513|entityMap|0|LINK|mutability|MUTABLE|url|http://www.bouncycastle.org/wiki/display/JA1/Frequently%2BAsked%2BQuestions^0|0|0|0|1Z|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Bouncy Castle still requires jars installed as far as I can tell.

I did a little test and it seemed to confirm this:

<a href="http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions" rel="noreferrer">http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions</a>

blocks|key|1495342|text|以下是解决方案：http://middlesphere-1.blogspot.ru/2014/06/this-code-allows-to-break-limit-if.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1495343|//this+code+allows+to+break+limit+if+client+jdk/jre+has+no+unlimited+policy+files+for+JCE.
//it+should+be+run+once.+So+this+static+section+is+always+execute+during+the+class+loading+process.
//this+code+is+useful+when+working+with+Bouncycastle+library.
static+{
++++try+{
++++++++Field+field+=+Class.forName("javax.crypto.JceSecurity").getDeclaredField("isRestricted");
++++++++field.setAccessible(true);
++++++++field.set(null,+java.lang.Boolean.FALSE);
++++}+catch+(Exception+ex)+{
++++}
}|code-block|syntax|javascript|1495344|entityMap|0|LINK|mutability|MUTABLE|url|http://middlesphere-1.blogspot.ru/2014/06/this-code-allows-to-break-limit-if.html^0|8|29|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

Here is solution: <a href="http://middlesphere-1.blogspot.ru/2014/06/this-code-allows-to-break-limit-if.html">http://middlesphere-1.blogspot.ru/2014/06/this-code-allows-to-break-limit-if.html</a>

<pre><code>//this code allows to break limit if client jdk/jre has no unlimited policy files for JCE.
//it should be run once. So this static section is always execute during the class loading process.
//this code is useful when working with Bouncycastle library.
static {
 try {
 Field field = Class.forName("javax.crypto.JceSecurity").getDeclaredField("isRestricted");
 field.setAccessible(true);
 field.set(null, java.lang.Boolean.FALSE);
 } catch (Exception ex) {
 }
}
</code></pre>

blocks|key|1495460|text|你可以使用方法|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1495461|javax.crypto.Cipher.getMaxAllowedKeyLength(String+transformation)|code-block|syntax|javascript|1495462|要测试可用的密钥长度，请使用该密钥长度并通知用户正在发生的情况。例如，说明您的应用程序由于未安装策略文件而回退到128位密钥的情况。有安全意识的用户将安装策略文件，其他用户将继续使用较弱的密钥。|1495463|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

You could use method

<pre><code>javax.crypto.Cipher.getMaxAllowedKeyLength(String transformation)
</code></pre>

to test the available key length, use that and inform the user about what is going on. Something stating that your application is falling back to 128 bit keys due to the policy files not being installed, for example. Security conscious users will install the policy files, others will continue using weaker keys.

blocks|key|1495507|text|从JDK8u102开始，发布的依赖于反射的解决方案将不再有效:这些解决方案设置的字段现在是final+(https://bugs.openjdk.java.net/browse/JDK-8149417)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1495508|看起来又回到了(a)使用Bouncy+Castle，或者(b)安装JCE策略文件。|1495509|entityMap|0|LINK|mutability|MUTABLE|url|https://bugs.openjdk.java.net/browse/JDK-8149417^0|19|5|1G|1C|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

As of JDK 8u102, the posted solutions relying on reflection will no longer work: the field that these solutions set is now <code>final</code> (<a href="https://bugs.openjdk.java.net/browse/JDK-8149417">https://bugs.openjdk.java.net/browse/JDK-8149417</a>).

Looks like it's back to either (a) using Bouncy Castle, or (b) installing the JCE policy files.

blocks|key|1495543|text|这是ntoskrnl+answer的更新版本。它还包含一个函数，用于删除注释中提到的最后一个修饰符，如Arjan。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1495544|此版本适用于JRE+8u111或更高版本。|1495545|private+static+void+removeCryptographyRestrictions()+{
++++if+(!isRestrictedCryptography())+{
++++++++return;
++++}
++++try+{
++++++++/*
+++++++++*+Do+the+following,+but+with+reflection+to+bypass+access+checks:
+++++++++*+
+++++++++*+JceSecurity.isRestricted+=+false;+JceSecurity.defaultPolicy.perms.clear();
+++++++++*+JceSecurity.defaultPolicy.add(CryptoAllPermission.INSTANCE);
+++++++++*/
++++++++final+Class<?>+jceSecurity+=+Class.forName("javax.crypto.JceSecurity");
++++++++final+Class<?>+cryptoPermissions+=+Class.forName("javax.crypto.CryptoPermissions");
++++++++final+Class<?>+cryptoAllPermission+=+Class.forName("javax.crypto.CryptoAllPermission");

++++++++Field+isRestrictedField+=+jceSecurity.getDeclaredField("isRestricted");
++++++++isRestrictedField.setAccessible(true);
++++++++setFinalStatic(isRestrictedField,+true);
++++++++isRestrictedField.set(null,+false);

++++++++final+Field+defaultPolicyField+=+jceSecurity.getDeclaredField("defaultPolicy");
++++++++defaultPolicyField.setAccessible(true);
++++++++final+PermissionCollection+defaultPolicy+=+(PermissionCollection)+defaultPolicyField.get(null);

++++++++final+Field+perms+=+cryptoPermissions.getDeclaredField("perms");
++++++++perms.setAccessible(true);
++++++++((Map<?,+?>)+perms.get(defaultPolicy)).clear();

++++++++final+Field+instance+=+cryptoAllPermission.getDeclaredField("INSTANCE");
++++++++instance.setAccessible(true);
++++++++defaultPolicy.add((Permission)+instance.get(null));
++++}
++++catch+(final+Exception+e)+{
++++++++e.printStackTrace();
++++}
}

static+void+setFinalStatic(Field+field,+Object+newValue)+throws+Exception+{
++++++field.setAccessible(true);

++++++Field+modifiersField+=+Field.class.getDeclaredField("modifiers");
++++++modifiersField.setAccessible(true);
++++++modifiersField.setInt(field,+field.getModifiers()+&+~Modifier.FINAL);

++++++field.set(null,+newValue);
+++}

private+static+boolean+isRestrictedCryptography()+{
++++//+This+simply+matches+the+Oracle+JRE,+but+not+OpenJDK.
++++return+"Java(TM)+SE+Runtime+Environment".equals(System.getProperty("java.runtime.name"));
}|code-block|syntax|javascript|1495546|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/22492582/1266705|1|https://stackoverflow.com/users/6178459/arjan^0|2|8|0|1F|5|1|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]|$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|12|8|@]|9|@]|C|$I|J]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]|S|$5|N|O|P|C|$Q|T]]]]

Here's a updated version of <a href="https://stackoverflow.com/a/22492582/1266705">ntoskrnl</a> answer.
It additionally contains a function to remove the final modifier like <a href="https://stackoverflow.com/users/6178459/arjan">Arjan</a> mentioned in the comments.

This version works with JRE 8u111 or newer.

<pre><code>private static void removeCryptographyRestrictions() {
 if (!isRestrictedCryptography()) {
 return;
 }
 try {
 /*
 * Do the following, but with reflection to bypass access checks:
 * 
 * JceSecurity.isRestricted = false; JceSecurity.defaultPolicy.perms.clear();
 * JceSecurity.defaultPolicy.add(CryptoAllPermission.INSTANCE);
 */
 final Class&lt;?&gt; jceSecurity = Class.forName("javax.crypto.JceSecurity");
 final Class&lt;?&gt; cryptoPermissions = Class.forName("javax.crypto.CryptoPermissions");
 final Class&lt;?&gt; cryptoAllPermission = Class.forName("javax.crypto.CryptoAllPermission");

 Field isRestrictedField = jceSecurity.getDeclaredField("isRestricted");
 isRestrictedField.setAccessible(true);
 setFinalStatic(isRestrictedField, true);
 isRestrictedField.set(null, false);

 final Field defaultPolicyField = jceSecurity.getDeclaredField("defaultPolicy");
 defaultPolicyField.setAccessible(true);
 final PermissionCollection defaultPolicy = (PermissionCollection) defaultPolicyField.get(null);

 final Field perms = cryptoPermissions.getDeclaredField("perms");
 perms.setAccessible(true);
 ((Map&lt;?, ?&gt;) perms.get(defaultPolicy)).clear();

 final Field instance = cryptoAllPermission.getDeclaredField("INSTANCE");
 instance.setAccessible(true);
 defaultPolicy.add((Permission) instance.get(null));
 }
 catch (final Exception e) {
 e.printStackTrace();
 }
}

static void setFinalStatic(Field field, Object newValue) throws Exception {
 field.setAccessible(true);

 Field modifiersField = Field.class.getDeclaredField("modifiers");
 modifiersField.setAccessible(true);
 modifiersField.setInt(field, field.getModifiers() &amp; ~Modifier.FINAL);

 field.set(null, newValue);
 }

private static boolean isRestrictedCryptography() {
 // This simply matches the Oracle JRE, but not OpenJDK.
 return "Java(TM) SE Runtime Environment".equals(System.getProperty("java.runtime.name"));
}
</code></pre>

I have an app that uses 256-bit AES encryption which is not supported by Java out of the box. I know to get this to function correctly I install the JCE unlimited strength jars in the security folder. This is fine for me being the developer, I can install them.

My question is since this app will be distributed, end users most likely will not have these policy files installed. Having the end user download these just to make the app function is not an attractive solution. 

Is there a way to make my app run without overwriting files on the end user machine? A third party software that can handle it without the policy files installed? Or a way to just reference these policy files from within a JAR?

How to avoid installing "Unlimited Strength" JCE policy files when deploying an application?

服务器

Java

我有一个使用256位AES加密的应用程序，Java不支持它的开箱即用。我知道为了让它正常工作，我在安全文件夹中安装了JCE无限强度jars。这对我作为开发者来说很好，我可以安装它们。我的问题是，由于此应用程序将被分发，最终用户很可能不会安装这些策略文件。让最终用户下载这些内容只是为了让应用程序具有功能，这不是一个有吸引...

问如何避免在部署应用程序时安装“无限强度”的JCE策略文件？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何避免在部署应用程序时安装“无限强度”的JCE策略文件？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何避免在部署应用程序时安装“无限强度”的JCE策略文件？
EN