wake-up-neo.com

JCE kann den Provider BC nicht in einer Java-Swing-Anwendung authentifizieren

Ich erstelle eine Swing-basierte Anwendung in Java, die eine Verschlüsselungstechnik verwendet. Aber Javax.crypto.KeyGenerator.getInstance ("AES", "BC") gibt Ausnahme:

Java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
        at javax.crypto.SunJCE_b.a(DashoA13*..)
        at javax.crypto.KeyGenerator.getInstance(DashoA13*..)

Was ist also das Problem?

javaencryption
26
user1041858

Um den Kommentar von GregS zu erweitern, müssen alle JCE-Provider-JARs signiert sein, bevor sie von Ihrer Java-Laufzeitumgebung als vertrauenswürdig eingestuft werden.

BouncyCastle liefert pflichtbewusst signierte JARs, die problemlos funktionieren werden. Wenn Sie jedoch Klassendateien aus dieser JAR extrahieren oder die Quelle erneut kompilieren, wird die Signatur entfernt und Java veranlasst, den Code abzulehnen.

Siehe diese verwandte SO - Frage: So signieren Sie einen benutzerdefinierten JCE-Sicherheitsanbieter

26
Duncan Jones

1 . Bearbeiten Sie jre\lib\security\Java.security

add security.provider.10 = org.bouncycastle.jce.provider.BouncyCastleProvider

2 . Kopiere bc * .jar nach jre\lib\ext

32
jiangzx

Für diejenigen, die dieses Problem finden, aber SpongyCastle verwenden, kann es interessant sein zu wissen, dass es unter Android keinen solchen Signaturtest gibt. Für Ihre Tests können Sie SpongyCastle über das openJDK-8 verwenden, da sich Signaturen nicht interessieren.

Als Referenz bei SpongyCastle lautet der Fehler:

Java.lang.SecurityException: JCE cannot authenticate the provider SC

Weitere Informationen in dieser Ausgabe

4
Giszmo

Wir leiden seit einigen Wochen unter dem gleichen Problem und hatten viele der vorgeschlagenen Schritte erfolglos ausprobiert. Weiter unten finden Sie unsere Lösung, damit andere nicht so leiden müssen wie wir!

Wir haben versucht, bcprov-ext-jdk15on-162.jar zu verwenden, das zu classpath hinzugefügt wurde, in JBoss-lib-Verzeichnissen enthalten ist, mit WAR gebündelt ist, als bereitgestellt markiert und zu JBoss/lib-Verzeichnissen hinzugefügt wurde, aber kein Glück.

Am Ende haben wir verschiedene Versionen von Bouncycastle ausprobiert und eine weniger aktuelle Version gefunden, deren Signatur mit unserem speziellen Java version's jarsigner (1.5X) überprüft werden konnte.

Obwohl die Signatur des JARs von unserer Java) -Version überprüft werden kann, wurde die Signatur von JBoss in irgendeiner Weise ungültig, wenn die .jar-Datei in eine WAR-Datei gepackt wird.

Am Ende war die Lösung für uns:

1. Add bouncycastle jar to JBoss classpath
2. Add 'org.bouncycastle.jce.provider.BouncyCastleProvider' to 'Java.security' providers
3. Mark bouncycastle in your WAR as a 'provided' dependency

Sobald wir eine Version der .jar auf unserem Klassenpfad hatten und sicher waren, dass unser WAR sie nicht verpackte, waren wir golden.

Das Problem scheint eng mit der von Ihnen verwendeten Java/JBoss-Version verbunden zu sein. Also, wenn diese Lösung für Sie nicht funktioniert, würde ich vorschlagen, verschiedene Versionen von Hüpfburg mit zu testen

jarsigner -verify <bouncycastle.jar>
1
robcob

Für mich war das Problem bcprov-ext-jdk16.jar wurde von sbt Assembly verworfen.

[warn] Merging 'META-INF/license/LICENSE.bouncycastle.txt' with strategy 'discard'
..
[warn] Merging 'META-INF/maven/org.jasypt/jasypt/pom.properties' with strategy 'discard'
[warn] Merging 'META-INF/maven/org.jasypt/jasypt/pom.xml' with strategy 'discard'
..

So endete ich mit dem bouncycastle.jarvon -classpath wie folgt: 

Java -Denvironment=dev -cp chat-server.jar:/Users/prayagupd/.ivy2/cache/org.bouncycastle/bcprov-ext-jdk16/jars/bcprov-ext-jdk16-1.46.jar com.chat.server.ChatServer

Was auch funktioniert, setzt die bouncycastle.jar auf $Java_HOME/jre/lib/ext,

cp /Users/prayagupd/.ivy2/cache/org.bouncycastle/bcprov-ext-jdk16/jars/bcprov-ext-jdk16-1.46.jar $Java_HOME/jre/lib/ext/

$ ls -l $Java_HOME/jre/lib/ext/
total 55208
-rw-r--r--  1 root  wheel   1887089 May  7 21:22 bcprov-ext-jdk16-1.46.jar
-rw-rw-r--  1 root  wheel   3860502 Sep  5  2017 cldrdata.jar
-rw-rw-r--  1 root  wheel      8286 Sep  5  2017 dnsns.jar
-rw-rw-r--  1 root  wheel     44516 Sep  5  2017 jaccess.jar
-rwxrwxr-x  1 root  wheel  18610276 Sep  5  2017 jfxrt.jar
-rw-rw-r--  1 root  wheel   1179093 Sep  5  2017 localedata.jar
-rw-rw-r--  1 root  wheel      1269 Sep  5  2017 meta-index
-rw-rw-r--  1 root  wheel   2022735 Sep  5  2017 nashorn.jar
-rw-rw-r--  1 root  wheel     41672 Sep  5  2017 sunec.jar
-rw-rw-r--  1 root  wheel    274148 Sep  5  2017 sunjce_provider.jar
-rw-rw-r--  1 root  wheel    248726 Sep  5  2017 sunpkcs11.jar
-rw-rw-r--  1 root  wheel     68924 Sep  5  2017 zipfs.jar
0
prayagupd

Zu Ihrer Information: Anstatt Java.security zu ändern und jar nach\jre\lib\ext zu kopieren, wurde das Problem durch folgende Schritte behoben. 

  1. füge Security.addProvider (neuer org.bouncycastle.jce.provider.BouncyCastleProvider ()) in deiner Klasse hinzu.
  2. fügen Sie den bereitgestellten Gültigkeitsbereich der Abhängigkeit von bcprov. *. jar in pom.xml hinzu.
  3. legen Sie bcprov. *. jar in Ihrem Ordner ab (z. B.\lib) und verweisen Sie es, wenn Sie das Projekt ausführen.
0
imsimm