InvalidKeyException taille de clé illégale
j'ai un test qui fonctionne très bien sur mon MacBook Pro de développement, mais qui ne fonctionne pas dans TeamCity server intégration continue.
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 utilise Java 1.6 et J'utilise la bibliothèque BouncyCastle pour le besoin de 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"));
}
mise à JOUR
semble que selon la réponse choisie, je dois modifier quelque chose sur mon installation TeamCity et cela affectera peut - être certaines installations de l'utilisateur-donc ce n'est pas un bon choix je dois passer à une autre bibliothèque crypto pour le faire sans limites. Donc probablement le château gonflable aidera.
UPDATE 2
j'ai changé pour utiliser BouncyCastle pour éviter cette limitation. Notez que cela ne fonctionne que si vous utilisez votre propre BC les classes directement, pas le fournisseur de la Colombie-Britannique.
5 réponses
cette erreur signifie que votre machine virtuelle Java utilise une politique qui ne permet que les tailles de clés de cryptographie restreintes en raison des lois américaines d'exportation.
Java 9 et plus
les fichiers de la Politique de compétence illimitée sont inclus avec Java 9 et utilisés par défaut (voir mises à jour de sécurité dans le guide de migration Java 9 ).
si vous obtenez cette erreur avec Java 9, cela pourrait signifier la Politique la configuration a été changée pour une politique plus restrictive ( limited ), voir les instructions du guide de migration:
entreprise criminelle commune, la Compétence de la Politique de Fichier par Défaut est Illimité
si votre application nécessitait auparavant la cryptographie Java Extension (JCE) les fichiers de politique de compétence de force illimitée, puis vous plus besoin de télécharger ou d'installer. Ils sont inclus dans le JDK et sont activés par défaut.
si votre pays ou votre usage nécessite une politique plus restrictive, la des fichiers limités de la Politique cryptographique Java sont encore disponibles.
Si vous avez des exigences qui ne sont pas satisfaits de la politique les fichiers fournis par défaut, vous pouvez personnaliser ces fichiers pour répondre à vos besoins.
voir la rubrique
crypto.policy.<java-home>/conf/security/java.security, ou la robustesse Cryptographique de Configuration dans la Plate-forme Java, L'Édition Standard de Sécurité Guide du Développeur.
Java 8 et versions antérieures
Java 8 Update 161 et plus
à partir de Java 8 Update 161, Java 8 par défaut à la Politique de juridiction de puissance illimitée. Si vous recevez cette erreur, cela pourrait indiquer que la configuration a été changée en limited . Voir les instructions dans la section suivante sur la mise à jour de Java 8 151, ou la section précédente sur Java 9, pour revenir à unlimited .
Java 8 Update 151 and higher
à partir de Java 8 Update 151, la Politique de juridiction de force illimitée est incluse avec 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 d'éditer le fichier en utilisant un éditeur exécuter en tant qu'administrateur.
le changement de politique ne prend effet qu'après redémarrage de la JVM (ceci est particulièrement important pour les processus de serveur de longue durée comme Tomcat).
pour la rétrocompatibilité, l'installation des fichiers de la Politique, tel que décrit dans la section suivante, fonctionne toujours.
Avant Java 8 Update 151
Pour La Mise À Jour De Java 8 144 et plus tôt, vous devez installer le Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (disponible à Oracle ).
pour installer ces fichiers (à partir du README.txt dans le téléchargement):
Télécharger les fichiers illimités de la Politique de force JCE.
Décompresser et extraire 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 fileinstallez les fichiers JAR de la Politique de résistance illimitée.
Dans le cas où vous décidez de revenir à l'original "fort" mais versions limitées de la police, d'abord faire une copie de L'original JCE la politique de fichiers (US_export_policy.jar et local_policy.pot.) Puis remplacer la forte fichiers de polices d'assurance avec la force illimitée versions extraites à l'étape précédente.
La norme de place pour la JCE de la compétence de la politique de fichiers JAR est:
<java-home>/lib/security [Unix] <java-home>\lib\security [Windows]
Note pour le JDK, il est dans la jre/lib/security.
le nouveau fichier de politique ne prend effet qu'après redémarrage de la JVM (ceci est particulièrement important pour les processus de serveur de longue durée comme 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, donc j'ai mis les deux pots dans jdk1.6.0_18/lib/security , mais dans jdk1.6.0_18 est le répertoire jre . Les deux fichiers auraient dû être mis dans jdk1.6.0_18/jre/lib/security .
en plus d'installer des fichiers de politique, assurez-vous également que CUSTOMLONGSECRETKEY...getBytes() produit effectivement un tableau de 32 octets. J'utiliserais CUSTOMLONGSECRETKEY.getBytes(some encoding) et j'obtiendrais les 32 premiers octets à partir de ça. Mieux encore, utilisez la clé secrète entière pour dériver des clés pour AES avec la taille dont vous avez besoin.
assurez-vous de connaître le chemin vers JAVA_HOME que votre IDE utilise . Afin de copier sur le chemin correct.
dans mon cas, J'utilise IntelliJ: / Library/Java/JavaVirtualMachines / jdk1.8.0_112.jdk / Contents/Home/jre/lib / security
au lieu de quand je montre le $JAVA_HOME dans la console. /Utilisateurs/myuser/.sdkman/candidats/java/actuel/jre/lib/security
j'ai été confronté à la même question pour jdk 1.8.0_151-
pour cette version et les précédentes, vous n'avez pas besoin de télécharger les fichiers jar relatifs à la sécurité.Parce que, local_policy.jar et US_export_policy.le pot est déjà inclus dans ces versions sous le chemin- \jre\lib\security\policy (JAVA_HOME se réfère à votre dossier d'installation java actuel) Le seul chng que vous devez faire est en java.fichier de sécurité qui est présent dans /jre/lib/security - décommentez la ligne - cryptographique.Politique = illimitée