J'ai un test qui fonctionne très bien sur mon développement MacBook Pro, mais ne parvient pas à fonctionner en intégration continue sur le serveur TeamCity.
L'erreur est la suivante:
Java.security.InvalidKeyException: Illegal key size
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
La boîte de développement et TeamCity utilisent Java 1.6 et j'utilise la bibliothèque BouncyCastle pour le besoin d'un cryptage AES spécial.
Le code est le suivant:
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"));
}
METTRE À JOUR
En fonction de la réponse choisie, je dois modifier quelque chose sur mon installation TeamCity et cela affectera peut-être certaines installations. Ce n'est donc pas un choix judicieux. Je dois passer à une autre bibliothèque de chiffrement pour le faire sans limitation. Donc, probablement château gonflable aidera.
MISE À JOUR 2
En fait, je suis passé à BouncyCastle pour éviter cette limitation. Notez que cela ne fonctionne que si vous utilisez directement vos propres classes BC, pas le fournisseur BC.
Cette erreur signifie que votre machine virtuelle Java utilise une stratégie autorisant uniquement les tailles de clé de cryptographie limitées en raison des lois d'exportation des États-Unis.
Les fichiers de stratégie de juridiction de force illimitée sont inclus avec Java 9 et utilisés par défaut (voir Mises à jour de sécurité dans le Guide de migration de Java 9 ).
Si vous obtenez cette erreur avec Java 9, cela peut signifier que la configuration de la stratégie a été modifiée pour une stratégie plus restrictive (limited
). Consultez les instructions du guide de migration:
Le fichier de règles de juridiction JCE est illimité par défaut
Si votre application nécessitait auparavant la cryptographie Java Extension (JCE) de fichiers de stratégie juridictionnelle à portée illimitée, puis vous plus besoin de les télécharger ou de les installer. Ils sont inclus dans le JDK et sont activés par défaut.
Si votre pays ou votre utilisation nécessite une stratégie plus restrictive, le des fichiers de règles cryptographiques Java limités sont toujours disponibles.
Si vous avez des exigences qui ne sont pas satisfaites par l’une des règles fichiers fournis par défaut, vous pouvez personnaliser ces fichiers de stratégie pour répondre à vos besoins.
Voir la propriété
crypto.policy
Security dans le fichier<Java-home>/conf/security/Java.security
fichier, ou Configuration de la force cryptographique sur la plate-forme Java, Guide du développeur de sécurité Standard Edition.
À partir de Java 8 Update 161, Java 8 utilise par défaut la stratégie de juridiction à force illimitée. Si vous recevez cette erreur, cela peut indiquer que la configuration a été changée en limited
. Reportez-vous aux instructions de la section suivante sur Java 8 Update 151 ou de la section précédente de Java 9 pour revenir à unlimited
.
À partir de Java 8 Update 151, la stratégie de pays à compétence illimitée est incluse dans Java 8 mais n'est pas utilisée par défaut. Pour l'activer, vous devez éditer le fichier Java.security
dans <Java_home>/jre/lib/security
(pour JDK) ou <Java_home>/lib/security
(pour JRE). Décommentez (ou incluez) la ligne
crypto.policy=unlimited
Assurez-vous de modifier le fichier à l'aide d'un éditeur exécuté en tant qu'administrateur.
La modification de stratégie ne prend effet qu'après le redémarrage de la machine virtuelle (cela est particulièrement important pour les processus serveur de longue durée tels que Tomcat).
Pour assurer la compatibilité avec les versions antérieures, l’installation des fichiers de stratégie décrite dans la section suivante fonctionnera également.
Pour Java 8 Update 144 et les versions antérieures, vous devez installer les fichiers de stratégie juridictionnelle de force illimitée JCE (Java Cryptography Extension) (disponibles à l'adresse Oracle ).
Pour installer ces fichiers (à partir du README.txt
dans le téléchargement):
Téléchargez les fichiers de règles JCE de force illimitée.
Décompressez et extrayez le fichier téléchargé.
Cela créera un sous-répertoire appelé jce . Ce répertoire contient les fichiers suivants:
README.txt This file local_policy.jar Unlimited strength local policy file US_export_policy.jar Unlimited strength US export policy file
Installez les fichiers JAR de stratégie de force illimitée.
Si vous décidez plus tard de revenir à l'original "fort" mais versions de politique limitées, faites d’abord une copie du JCE original fichiers de règles (US_export_policy.jar et local_policy.jar). Ensuite remplacez les fichiers de stratégie forts par la force illimitée versions extraites à l'étape précédente.
L'emplacement standard pour les fichiers JAR de règles de compétence JCE est le suivant:
<Java-home>/lib/security [Unix] <Java-home>\lib\security [Windows]
Remarque pour le JDK, il se trouve dans jre/lib/security.
Le nouveau fichier de stratégie ne prend effet qu'après le redémarrage de la machine virtuelle (cela est particulièrement important pour les processus serveur de longue durée tels que Tomcat).
J'ai eu un problème similaire, mais dans mon cas, il y avait une erreur de chemin.
Java_HOME était jdk1.6.0_18, j'ai donc placé les deux fichiers jar dans jdk1.6.0_18/lib/security
, mais jdk1.6.0_18 contient le répertoire jre
. Les deux fichiers auraient dû être mis dans jdk1.6.0_18/jre/lib/security
.
En plus de l'installation des fichiers de stratégie, assurez-vous également que CUSTOMLONGSECRETKEY...getBytes()
produit effectivement un tableau de 32 octets. Je voudrais utiliser CUSTOMLONGSECRETKEY.getBytes(some encoding)
et obtenir les 32 premiers octets de cela. Mieux encore, utilisez la clé secrète entière pour obtenir les clés pour AES avec la taille dont vous avez besoin.
Assurez-vous de connaître le chemin d'accès à Java_HOME utilisé par votre IDE - . Afin de le copier dans le chemin correct.
Dans mon cas, j'utilise IntelliJ: /Bibliothèque/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Sommaire/Accueil/jre/lib/security
Au lieu de quand je montre le $ Java_HOME dans la console ./Utilisateurs/monutilisateur/.sdkman/candidats/Java/actuel/jre/lib/security
Je faisais face au même problème pour jdk 1.8.0_151-
Pour cette version et les suivantes, vous n'avez pas besoin de télécharger les fichiers jar liés à security.Because, local_policy.jar et US_export_policy.jar est déjà inclus dans ces versions sous le chemin -\Jre\lib\security\policy ( Java_HOME fait référence à votre dossier d'installation Java actuel) Le seul chng que vous devez créer est dans le fichier Java.security présent dans/jre/lib/security - Décommentez la ligne - crypto. politique = illimité