Suns PKCS11 JCE-Sicherheitsprovider benötigt einige Funktionen, die wir brauchen.
Also habe ich eine verbesserte Version davon mit den Originalquellen geschrieben.
Leider lehnt die JCE-Infrastruktur den neuen Provider ab. "JCE kann den Provider nicht authentifizieren"
weil es nicht richtig signiert ist.
javax.crypto.JceSecurity.verifyProviderJar(...) wirft.
(es ruft javax.crypto.JarVerifier.verify() auf)
Vorschläge, wie Sie den neuen Anbieter unterschreiben können Arbeit mit JCE?
Der Vorgang ist im Dokument "Vorgehensweise" beschrieben Implementieren Sie einen Provider. "
Sie müssen Sun Oracle einige Informationen per E-Mail senden (einschließlich der CSR, die Sie für Ihren Signaturschlüssel generiert haben) und dann ein Bestätigungsdokument faxen. Wenn Sie Ihr signiertes Zertifikat zurückerhalten, kann dies eine Woche oder länger dauern. Planen Sie also voraus.
Sie müssen Ihren Anbieter nur dann unterschreiben, wenn er Dienste anbietet, die von einigen (repressiven) Regierungen eingeschränkt werden. Beispielsweise ist eine Cipher -Implementierung ein eingeschränkter "Dienst", während MessageDigest ein uneingeschränkter Dienst ist. Ich gehe davon aus, dass Sie mit der Nachricht, die Sie erhalten, einen eingeschränkten Service bereitstellen möchten.
Wenn Sie einen dieser Dienste bereitstellen, gibt es keine andere Möglichkeit: Sie benötigen ein von Sun ausgestelltes Zertifikat zur Codesignatur. (Eine von IBM könnte auch funktionieren; wenn ich mich recht erinnere, wird ihre Code-Signing-CA unterstützt, aber ich weiß nichts über ihren Ausgabeprozess.)
Alternativ können Sie Ihren benutzerdefinierten Anbieter mit OpenJDK entwerfen. Dies ist das Open-Source-Projekt, das von Sun / Oracle gesponsert wird, und bietet die Code-Basis für ihre offizielle Veröffentlichung. OpenJDK erfordert keine Signierung von Providern. OpenJDK ist (standardmäßig, jetzt) auf mehreren Linux-Distributionen verfügbar. Leider scheint es unter Windows oder Macintosh nicht ohne weiteres verfügbar zu sein. Wenn Sie Windows oder Macintosh verwenden, empfehle ich die Installation von Linux in einer VM.
Wenn Sie jedoch unter Windows oder Mac entwickeln müssen, können Sie die Datei jce.jar von einer OpenJDK-Installation über jce.jar (in Ihrem Java-lib-Verzeichnis) einer offiziellen Installation kopieren. Dies wird den Jar-Authentifizierungsprozess effektiv umgehen. Stellen Sie jedoch sicher, dass Sie die ursprüngliche jce.jar-Datei zurückgeben, wenn Sie mit der Entwicklung fertig sind.
Sie müssen das JAR mit "JCE Code Signing CA" signieren. In allen aktuellen Java-Distributionen sind nur 2 CAs (Sun und IBM) integriert (fest codiert) und es gibt keine Möglichkeit, eigene hinzuzufügen. Wir haben versucht, mit Sun zu arbeiten, um unseren Provider zu unterschreiben, und das ist fast unmöglich. Sie würden kein mittleres CA-Zertifikat ausgeben, was bedeutet, dass Sie jedes Mal, wenn Sie eine Änderung vornehmen, den Fehler machen müssen.
Warum nimmst du nicht einfach deine eigene Bibliothek? Sie verwenden die Standard-API für die Interoperabilität zwischen verschiedenen JCEs. Aber das ist jetzt für CryptoKi / SmartCard-Sachen nicht realistisch. Sie müssen fast immer einen benutzerdefinierten Code schreiben, um mit der herstellerspezifischen API zu interagieren. Sie können Ihren Code sogar dazu bringen, die JCE-API nachzuahmen, um Codeänderungen zu minimieren.
Nur für zusätzliche Informationen habe ich dieselbe Ausnahme, wenn ich ein JAR (Eclipse Juno) mit der Option "Extrahiere benötigte Bibliotheken in generiertes JAR" anstelle der korrekten "Paket benötigten Bibliotheken in generiertes JAR"
Tags und Links java security digital-signature jce