it-swarm.com.de

InvalidKeyException Ungültige Schlüsselgröße

Ich habe einen Test, der auf meinem Entwicklungs-MacBook Pro gut läuft, aber nicht in einem TeamCity-Server mit kontinuierlicher Integration ausgeführt werden kann.

Der Fehler ist folgender:

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

Sowohl die Entwicklungsbox als auch TeamCity verwenden Java 1.6, und ich benutze die BouncyCastle-Bibliothek, um spezielle AES-Verschlüsselung zu benötigen.

Der Code lautet wie folgt:

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

UPDATE

Nach der ausgewählten Antwort muss an meiner TeamCity-Installation etwas geändert werden, was möglicherweise Auswirkungen auf einige Benutzerinstallationen hat. Daher ist es keine gute Wahl. Ich muss zu einer anderen Kryptobibliothek wechseln, um dies ohne Einschränkungen zu tun. Also wird wahrscheinlich Hüpfburg helfen.

UPDATE 2

Ich habe tatsächlich auf BouncyCastle umgestellt, um diese Einschränkung zu vermeiden. Beachten Sie, dass dies nur funktioniert, wenn Sie eigene BC-Klassen direkt verwenden, nicht den BC-Provider.

52
Vladimir

Dieser Fehler bedeutet, dass Ihre Java Virtual Machine eine Richtlinie verwendet, die aufgrund der US-Exportgesetze nur eingeschränkte Schlüsselgrößen für die Verschlüsselung zulässt.

Java 9 und höher

Die Richtliniendateien für die unbegrenzte Gültigkeitsdauer sind in Java 9 enthalten und werden standardmäßig verwendet (siehe Sicherheitsaktualisierungen im Java 9-Migrationshandbuch ).

Wenn Sie diesen Fehler mit Java 9 erhalten, kann dies bedeuten, dass die Richtlinienkonfiguration in eine restriktivere Richtlinie (limited) geändert wurde. Lesen Sie dazu die Anweisungen im Migrationshandbuch:

JCE Jurisdiction Policy-Standardeinstellung ist unbegrenzt

Wenn Ihre Anwendung zuvor die Java-Verschlüsselung benötigt Erweiterungs-JCE-Dateien (Unlimited Strength Jurisdiction Policy Files), dann Sie müssen sie nicht mehr herunterladen oder installieren. Sie sind in der .__ enthalten. JDK und sind standardmäßig aktiviert.

Wenn für Ihr Land oder Ihre Verwendung eine restriktivere Richtlinie erforderlich ist, wird der Es sind noch einige eingeschränkte Java-Verschlüsselungsrichtliniendateien verfügbar.

Wenn Sie Anforderungen haben, die von keiner der Richtlinien erfüllt werden Standardmäßig zur Verfügung gestellte Dateien, können Sie diese Richtliniendateien anpassen. um Ihre Bedürfnisse zu erfüllen.

Siehe die crypto.policy Security-Eigenschaft in <Java-home>/conf/security/Java.security-Datei oder Konfiguration der kryptografischen Stärke in der Java-Plattform, Sicherheitshandbuch für die Standard Edition.

Java 8 und früher

Java 8 Update 161 und höher

Beginnend mit Java 8 Update 161 verwendet Java 8 standardmäßig die Richtlinie zur Beschränkung der unbegrenzten Gültigkeit. Wenn Sie diesen Fehler erhalten, kann dies bedeuten, dass die Konfiguration in limited geändert wurde. Anweisungen dazu finden Sie im nächsten Abschnitt zu Java 8 Update 151 oder im vorherigen Abschnitt zu Java 9, um dies wieder in unlimited zu ändern.

Java 8 Update 151 und höher

Ab Java 8 Update 151 ist die Richtlinie zur Beschränkung der unbegrenzten Gültigkeit in Java 8 enthalten, wird jedoch standardmäßig nicht verwendet. Um es zu aktivieren, müssen Sie die Java.security-Datei in <Java_home>/jre/lib/security (für JDK) oder <Java_home>/lib/security (für JRE) bearbeiten. Kommentieren Sie die Zeile (oder schließen Sie sie ein)

crypto.policy=unlimited

Stellen Sie sicher, dass Sie die Datei mit einem Editor bearbeiten, der als Administrator ausgeführt wird.

Die Richtlinienänderung wird erst nach einem Neustart der JVM wirksam (dies ist besonders wichtig für lang laufende Serverprozesse wie Tomcat).

Aus Gründen der Abwärtskompatibilität funktioniert das Installieren der Richtliniendateien, wie im nächsten Abschnitt beschrieben, ebenfalls.

Vor Java 8 Update 151

Für Java 8 Update 144 und frühere Versionen müssen Sie die Richtliniendateien der Java Cryptography Extension (JCE) für unbegrenzte Gültigkeitsrechte (verfügbar unter Oracle ) installieren.

So installieren Sie diese Dateien (vom README.txt im Download):

  1. Laden Sie die JCE-Richtliniendateien mit unbegrenzter Stärke herunter.

  2. Dekomprimieren und extrahieren Sie die heruntergeladene Datei.

    Dadurch wird ein Unterverzeichnis mit dem Namen jce ..__ erstellt. Dieses Verzeichnis enthält die folgenden Dateien:

    README.txt                   This file
    local_policy.jar             Unlimited strength local policy file
    US_export_policy.jar         Unlimited strength US export policy file
    
  3. Installieren Sie die JAR-Dateien mit unbegrenzter Stärke.

    Falls Sie sich später dafür entscheiden, auf das ursprüngliche "strong" zurückzugreifen, aber Bei eingeschränkten Richtlinienversionen müssen Sie zunächst eine Kopie der ursprünglichen JCE-Datei erstellen Richtliniendateien (US_export_policy.jar und local_policy.jar). Dann Ersetzen Sie die starken Richtliniendateien durch die unbegrenzte Stärke Versionen, die im vorherigen Schritt extrahiert wurden.

    Der Standardort für JAR-Dateien für JCE-Gerichtsbarkeitsrichtlinien ist:

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

Hinweis für das JDK ist in jre/lib/security.

Die neue Richtliniendatei wird erst nach einem Neustart der JVM wirksam (dies ist besonders wichtig für lang laufende Serverprozesse wie Tomcat).

121
Mark Rotteveel

Ich hatte ein ähnliches Problem, aber in meinem Fall trat ein Pfadfehler auf.

Java_HOME war jdk1.6.0_18, also habe ich die beiden Gläser in jdk1.6.0_18/lib/security gestellt, aber innerhalb von jdk1.6.0_18 befindet sich das Verzeichnis jre. Beide Dateien sollten in jdk1.6.0_18/jre/lib/security abgelegt worden sein.

8
oopexpert

Stellen Sie zusätzlich zum Installieren von Richtliniendateien sicher, dass CUSTOMLONGSECRETKEY...getBytes() tatsächlich ein 32-Byte-Array erzeugt. Ich würde CUSTOMLONGSECRETKEY.getBytes(some encoding) verwenden und davon zunächst 32 Bytes erhalten. Besser noch, verwenden Sie den gesamten geheimen Schlüssel, um Schlüssel für AES mit der von Ihnen benötigten Größe abzuleiten.

1

Stellen Sie sicher, dass Sie den Pfad zu Java_HOME kennen, den Ihre IDE verwendet ., Um in den richtigen Pfad zu kopieren.

In meinem Fall verwende ich IntelliJ: /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre/lib/security

Anstatt, wenn ich das $ Java_HOME in der Konsole zeige

0

Ich stand vor dem gleichen Problem für jdk 1.8.0_151-

Für diese und die vorige Version müssen Sie keine JAR-Dateien herunterladen, die sich auf security beziehen. Weil local_policy.jar und US_export_policy.jar bereits in diesen Versionen unter dem Pfad -\Jre\lib\security\policy enthalten sind ( Java_HOME bezieht sich auf Ihren aktuellen Java-Installationsordner) Die einzige Änderung, die Sie vornehmen müssen, ist in der Java.security-Datei, die sich in/jre/lib/security - Befindet und die Zeile -crypto als Kommentar enthält. Politik = unbegrenzt

0
vikash singh