InvalidKeyException Неверный размер ключа

У меня есть тест, который отлично работает на моем MacBook Pro для разработки, но не работает в режиме непрерывной интеграции с сервером TeamCity.

Ошибка следующая:

java.security.InvalidKeyException: Illegal key size
    at javax.crypto.Cipher.a(DashoA13*..)
    at javax.crypto.Cipher.init(DashoA13*..)
    at javax.crypto.Cipher.init(DashoA13*..)

И модуль разработки, и TeamCity используют Java 1.6, а я использую библиотеку BouncyCastle для необходимости специального шифрования AES.

Код следующий:

private byte[] aesEncryptedInfo(String info) throws UnsupportedEncodingException, IllegalBlockSizeException, BadPaddingException, InvalidKeyException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidParameterSpecException, InvalidAlgorithmParameterException, NoSuchProviderException {
    Security.addProvider(new BouncyCastleProvider());
    SecretKey secret = new SecretKeySpec(CUSTOMLONGSECRETKEY.substring(0, 32).getBytes(), "AES");
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding", "BC");
    cipher.init(Cipher.ENCRYPT_MODE, secret, new IvParameterSpec(VECTOR_SECRET_KEY.getBytes()));
    return cipher.doFinal(info.getBytes("UTF-8"));
}

ОБНОВЛЕНИЕ

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

ОБНОВЛЕНИЕ 2

Я фактически перешел на использование BouncyCastle, чтобы избежать этого ограничения. Обратите внимание, что это работает только в том случае, если вы напрямую используете собственные классы BC, а не поставщик BC.


person Vladimir    schedule 05.10.2010    source источник
comment
В качестве альтернативы вы можете использовать более слабые ключи :-) (128 бит по-прежнему считается безопасным, и вам не нужно устанавливать этот файл политики)   -  person Peter Štibraný    schedule 05.10.2010
comment
Кстати, у Bouncy Castle такое же ограничение: bouncycastle.org/wiki/display/ JA1 / Часто + задаваемые + вопросы (первый вопрос / ответ)   -  person Peter Štibraný    schedule 05.10.2010
comment
Bouncy Castle предоставляет два API: FAQ, на который вы ссылаетесь, посвящен провайдеру Bouncy Castle, который является реализацией JCE и имеет ограничения JCE, и API-интерфейсом Bouncy Castle, который не ограничен.   -  person Jules    schedule 02.03.2012


Ответы (5)


Эта ошибка означает, что ваша виртуальная машина Java использует политику, которая разрешает только ограниченные размеры криптографических ключей из-за экспортных законов США.

Java 9 и выше

Файлы политики юрисдикции с неограниченной надежностью включены в Java 9 и используются по умолчанию (см. Обновления безопасности в Руководстве по миграции на Java 9).

Если вы получаете эту ошибку с Java 9, это может означать, что конфигурация политики была изменена на более строгую политику (limited), см. Инструкции в руководстве по миграции:

Файл политики юрисдикции JCE по умолчанию не ограничен

Если вашему приложению ранее требовались файлы политики юрисдикции с неограниченной надежностью Java Cryptography Extension (JCE), то вам больше не нужно загружать или устанавливать их. Они включены в JDK и активированы по умолчанию.

Если ваша страна или использование требует более строгой политики, ограниченные файлы криптографической политики Java по-прежнему доступны.

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

См. Свойство crypto.policy Security в файле <java-home>/conf/security/java.security или Конфигурация криптографической стойкости в Руководстве разработчика по безопасности Standard Edition для платформы Java.

Java 8 и более ранние версии

Java 8 (обновление 161) и выше

Начиная с Java 8 Update 161, Java 8 по умолчанию использует политику юрисдикции с неограниченной надежностью. Если вы получаете эту ошибку, это может означать, что конфигурация была изменена на limited. См. Инструкции в следующем разделе для Java 8 (обновление 151) или в предыдущем разделе для Java 9, чтобы снова изменить его на unlimited.

Java 8 (обновление 151) и выше

Начиная с Java 8 (обновление 151), политика юрисдикции неограниченной силы включена в Java 8, но не используется по умолчанию. Чтобы включить его, вам нужно отредактировать java.security файл в <java_home>/jre/lib/security (для JDK) или <java_home>/lib/security (для JRE). Раскомментируйте (или добавьте) строку

crypto.policy=unlimited

Убедитесь, что вы редактируете файл с помощью редактора, запущенного от имени администратора.

Изменение политики вступает в силу только после перезапуска JVM (это особенно важно для длительно выполняющихся серверных процессов, таких как Tomcat).

Для обеспечения обратной совместимости установка файлов политики, как описано в следующем разделе, также будет работать.

Перед Java 8 (обновление 151)

Для Java 8 Update 144 и более ранних версий необходимо установить файлы политики юрисдикции неограниченной надежности Java Cryptography Extension (JCE) (доступны по адресу Oracle).

Чтобы установить эти файлы (из README.txt в загрузке):

  1. Загрузите файлы политик JCE неограниченной силы.

  2. Распакуйте и извлеките загруженный файл.

    Это создаст подкаталог с именем jce. Этот каталог содержит следующие файлы:

    README.txt                   This file
    local_policy.jar             Unlimited strength local policy file
    US_export_policy.jar         Unlimited strength US export policy file
    
  3. Установите файлы JAR политики неограниченной стойкости.

    Если позже вы решите вернуться к исходным «сильным», но ограниченным версиям политики, сначала сделайте копию исходных файлов политики JCE (US_export_policy.jar и local_policy.jar). Затем замените файлы строгой политики версиями с неограниченной надежностью, извлеченными на предыдущем шаге.

    Стандартное место для файлов JAR политики юрисдикции JCE:

    <java-home>/lib/security           [Unix]
    <java-home>\lib\security           [Windows]
    

Обратите внимание, что для JDK он находится в jre / lib / security.

Новый файл политики вступает в силу только после перезапуска JVM (это особенно важно для длительно выполняющихся серверных процессов, таких как Tomcat).

person Mark Rotteveel    schedule 05.10.2010
comment
Я не устанавливал JCE USJ специально на свой ящик для разработки, но он там работает. - person Vladimir; 05.10.2010
comment
Как вы думаете, он может быть установлен там по умолчанию, а не установлен на сервере? - person Vladimir; 05.10.2010
comment
@Vladimir: Я не могу найти, объединяет ли Apple файлы политик неограниченной мощности или нет, но они не включены в JVM, предоставленные Oracle (или ранее Sun). Если ваш TeamCity работает в Linux / Windows, вам необходимо самостоятельно установить неограниченное количество файлов политики надежности на свой сервер сборки. - person Peter Štibraný; 05.10.2010
comment
Подключил Phonics, у меня сработало! Я имею в виду файлы политики USJ. - person stannius; 20.12.2013
comment
Обратите внимание, что после установки новых файлов политики вам может потребоваться перезапустить все, что выполняется через JVM. Мне пришлось перезапустить Tomcat, например, до того, как мое веб-приложение воспримет изменения. - person user; 21.03.2016
comment
Поздно, но: эта проблема применима и относится к интерфейсу JCE в пакетах Java от Sun-now-Oracle. Большинство дистрибутивов Linux, которые я видел, собирают свои собственные пакеты из исходного кода OpenJDK, и эти пакеты openjdk обычно не имеют политики максимум 128 бит. - person dave_thompson_085; 24.09.2016

У меня была аналогичная проблема, но в моем случае произошла ошибка пути.

JAVA_HOME был jdk1.6.0_18, поэтому я поместил две банки в jdk1.6.0_18/lib/security, но внутри jdk1.6.0_18 находится каталог jre. Оба файла должны были быть помещены в jdk1.6.0_18/jre/lib/security.

person oopexpert    schedule 29.05.2013

В дополнение к установке файлов политики убедитесь, что CUSTOMLONGSECRETKEY...getBytes() действительно создает массив размером 32 байта. Я бы использовал CUSTOMLONGSECRETKEY.getBytes(some encoding) и получил бы первые 32 байта от этого. Еще лучше использовать весь секретный ключ, чтобы получить ключи для AES нужного вам размера.

person Peter Štibraný    schedule 05.10.2010
comment
CUSTOMLONGSECRETKEY является константой = 3C7C6086-CF22-4972-9616-F294DAF77092 для обоих прогонов. Интересно, как это может повлиять на TeamCity. - person Vladimir; 05.10.2010
comment
@Vladimir: Я пытался указать, что вы должны использовать getBytes с явной кодировкой, но это не похоже на проблему с вашим ключом. Я бы попытался установить эти файлы политики. Если вы этого не сделаете, вы ограничены 128-битными ключами для AES. - person Peter Štibraný; 05.10.2010

Убедитесь, что вы знаете путь к JAVA_HOME, который использует ваша IDE. Чтобы скопировать по правильному пути.

В моем случае я использую IntelliJ: /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre/lib/security

Вместо того, чтобы показывать $ JAVA_HOME в консоли. /Users/myuser/.sdkman/candidates/java/current/jre/lib/security

person Juan Carlos Alafita    schedule 05.10.2017

Я столкнулся с той же проблемой для jdk 1.8.0_151-

Для этой и более поздних версий вам не нужно загружать файлы jar, связанные с безопасностью, потому что local_policy.jar и US_export_policy.jar уже включены в эти версии по пути- \ jre \ lib \ security \ policy (JAVA_HOME относится к текущая папка установки java) Единственное изменение, которое вам нужно сделать, это файл java.security, который находится в / jre / lib / security - раскомментируйте строку - crypto.policy = unlimited

person vikash singh    schedule 05.04.2018