Как избежать установки файлов политики Unlimited Strength JCE при развертывании приложения?

Есть несколько часто цитируемых решений этой проблемы. К сожалению, ни один из них не является полностью удовлетворительным:

• Установите файлы политики неограниченной стойкости. Хотя это, вероятно, правильное решение для вашей рабочей станции разработчика, быстро становится серьезной проблемой (если не препятствием), когда нетехнические пользователи устанавливают файлы на каждый компьютер. Невозможно распространить файлы вместе с вашей программой; они должны быть установлены в каталог JRE (который может быть даже доступен только для чтения из-за разрешений).
• Пропустите JCE API и используйте другую криптографическую библиотеку, например Bouncy Castle. Для этого подхода требуется дополнительная библиотека размером 1 МБ, что может стать серьезной нагрузкой в ​​зависимости от приложения. Также кажется глупым дублировать функции, включенные в стандартные библиотеки. Очевидно, что API также полностью отличается от обычного интерфейса JCE. (BC действительно реализует поставщика JCE, но это не помогает, поскольку ограничения силы ключа применяются до передачи реализации.) Это решение также не позволит вам использовать 256-битный TLS ( SSL), потому что стандартные библиотеки TLS вызывают JCE изнутри, чтобы определить какие-либо ограничения.

Но есть отражение. Что вы не можете сделать с помощью отражения?

private static void removeCryptographyRestrictions() {
    if (!isRestrictedCryptography()) {
        logger.fine("Cryptography restrictions removal not needed");
        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");

        final Field isRestrictedField = jceSecurity.getDeclaredField("isRestricted");
        isRestrictedField.setAccessible(true);
        final Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        modifiersField.setInt(isRestrictedField, isRestrictedField.getModifiers() & ~Modifier.FINAL);
        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));

        logger.fine("Successfully removed cryptography restrictions");
    } catch (final Exception e) {
        logger.log(Level.WARNING, "Failed to remove cryptography restrictions", e);
    }
}

private static boolean isRestrictedCryptography() {
    // This matches Oracle Java 7 and 8, but not Java 9 or OpenJDK.
    final String name = System.getProperty("java.runtime.name");
    final String ver = System.getProperty("java.version");
    return name != null && name.equals("Java(TM) SE Runtime Environment")
            && ver != null && (ver.startsWith("1.7") || ver.startsWith("1.8"));
}

Просто вызовите removeCryptographyRestrictions() из статического инициализатора или другого перед выполнением любых криптографических операций.

Часть JceSecurity.isRestricted = false - это все, что нужно для прямого использования 256-битных шифров; однако без двух других операций Cipher.getMaxAllowedKeyLength() по-прежнему будет сообщать 128, а 256-битные наборы шифров TLS не будут работать.

Этот код работает в Oracle Java 7 и 8 и автоматически пропускает процесс в Java 9 и OpenJDK, где он не нужен. В конце концов, будучи уродливым взломом, он, скорее всего, не работает на виртуальных машинах других производителей.

Он также не работает в Oracle Java 6, потому что там скрыты частные классы JCE. Обфускация не меняется от версии к версии, поэтому технически поддержка Java 6 все еще возможна.

Теперь это больше не требуется ни для Java 9, ни для каких-либо недавних выпусков Java 6, 7 или 8. Наконец! :)

Согласно JDK-8170157 неограниченная криптографическая политика теперь включена по умолчанию.

Конкретные версии из выпуска JIRA:

• Java 9 (10, 11 и т.д ..): Любой официальный релиз!
• Java 8u161 или новее (доступно сейчас)
• Java 7u171 или новее (доступно только через My Oracle Support)
• Java 6u181 или новее (доступно только через My Oracle Support)

Обратите внимание, что если по какой-то странной причине в Java 9 требуется старое поведение, его можно настроить с помощью:

Security.setProperty("crypto.policy", "limited");

Вот решение: http://middlesphere-1.blogspot.ru/2014/06/this-code-allows-to-break-limit-if.html

//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) {
    }
}

Начиная с JDK 8u102 опубликованные решения, основанные на отражении, больше не будут работать: поле, установленное этими решениями, теперь равно final (https://bugs.openjdk.java.net/browse/JDK-8149417).

Похоже, он вернулся либо к (а) использованию Bouncy Castle, либо (б) к установке файлов политики JCE.

Насколько я могу судить, Bouncy Castle все еще требует установки фляг.

Я провел небольшой тест, и он, похоже, подтвердил это:

http://www.bouncycastle.org/wiki/display/JA1/Frequent+Asked+Questions

Альтернативную библиотеку криптографии можно найти на странице Bouncy Castle. Он имеет AES и множество дополнительных функций. Это либеральная библиотека с открытым исходным кодом. Однако вам придется использовать легкий проприетарный API Bouncy Castle, чтобы это работало.

Вы можете использовать метод

javax.crypto.Cipher.getMaxAllowedKeyLength(String transformation)

чтобы проверить доступную длину ключа, используйте ее и проинформируйте пользователя о том, что происходит. Что-то, говорящее о том, что ваше приложение возвращается к 128-битным ключам, например, из-за того, что файлы политики не установлены. Пользователи, заботящиеся о безопасности, будут устанавливать файлы политик, другие продолжат использовать более слабые ключи.

Для нашего приложения у нас была архитектура клиент-сервер, и мы разрешали дешифрование / шифрование данных только на уровне сервера. Следовательно, файлы JCE нужны только там.

У нас была еще одна проблема, когда нам нужно было обновить jar-файл безопасности на клиентских машинах через JNLP, он перезаписывает библиотеки in${java.home}/lib/security/ и JVM при первом запуске.

Это заставило его работать.

Вот обновленная версия ответа ntoskrnl. Он дополнительно содержит функцию для удаления последнего модификатора, такого как Arjan, упомянутого в комментариях.

Эта версия работает с JRE 8u111 или новее.

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"));
}

Вот модифицированная версия кода @ ntoskrnl с isRestrictedCryptography проверкой фактическим Cipher.getMaxAllowedKeyLength, slf4j и поддержка инициализации singleton из начальной загрузки приложения следующим образом:

static {
    UnlimitedKeyStrengthJurisdictionPolicy.ensure();
}

Этот код правильно перестанет искажать отражение, когда неограниченная политика станет доступной по умолчанию в Java 8u162, как предсказывает ответ @cranphin.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.crypto.Cipher;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.security.NoSuchAlgorithmException;
import java.security.Permission;
import java.security.PermissionCollection;
import java.util.Map;

// https://stackoverflow.com/questions/1179672/how-to-avoid-installing-unlimited-strength-jce-policy-files-when-deploying-an
public class UnlimitedKeyStrengthJurisdictionPolicy {

    private static final Logger log = LoggerFactory.getLogger(UnlimitedKeyStrengthJurisdictionPolicy.class);

    private static boolean isRestrictedCryptography() throws NoSuchAlgorithmException {
        return Cipher.getMaxAllowedKeyLength("AES/ECB/NoPadding") <= 128;
    }

    private static void removeCryptographyRestrictions() {
        try {
            if (!isRestrictedCryptography()) {
                log.debug("Cryptography restrictions removal not needed");
                return;
            }
            /*
             * Do the following, but with reflection to bypass access checks:
             *
             * JceSecurity.isRestricted = false;
             * JceSecurity.defaultPolicy.perms.clear();
             * JceSecurity.defaultPolicy.add(CryptoAllPermission.INSTANCE);
             */
            Class<?> jceSecurity = Class.forName("javax.crypto.JceSecurity");
            Class<?> cryptoPermissions = Class.forName("javax.crypto.CryptoPermissions");
            Class<?> cryptoAllPermission = Class.forName("javax.crypto.CryptoAllPermission");

            Field isRestrictedField = jceSecurity.getDeclaredField("isRestricted");
            isRestrictedField.setAccessible(true);
            Field modifiersField = Field.class.getDeclaredField("modifiers");
            modifiersField.setAccessible(true);
            modifiersField.setInt(isRestrictedField, isRestrictedField.getModifiers() & ~Modifier.FINAL);
            isRestrictedField.set(null, false);

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

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

            Field instance = cryptoAllPermission.getDeclaredField("INSTANCE");
            instance.setAccessible(true);
            defaultPolicy.add((Permission) instance.get(null));

            log.info("Successfully removed cryptography restrictions");
        } catch (Exception e) {
            log.warn("Failed to remove cryptography restrictions", e);
        }
    }

    static {
        removeCryptographyRestrictions();
    }

    public static void ensure() {
        // just force loading of this class
    }
}

Во время установки программы просто предложите пользователю загрузить пакетный сценарий DOS или сценарий оболочки Bash и скопировать JCE в соответствующее системное место.

Раньше мне приходилось делать это для серверного веб-сервиса, и вместо формального установщика я просто предоставлял сценарии для настройки приложения, прежде чем пользователь сможет его запустить. Вы можете сделать приложение недоступным для запуска, пока они не запустят сценарий установки. Вы также можете заставить приложение пожаловаться на отсутствие JCE, а затем попросить загрузить и перезапустить приложение?