Согласно JEP 131, Java 8 должен предоставить провайдер Crypto PKCS # 11 для 64-битной Windows: https://blogs.oracle.com/mullan/entry/jep_131_pkcs_11_crypto.Java 8 64 бит в Windows с NSS для соответствия FIPS 140
Имея это в виду, я скачал и построил 32 и 64-битные версии NSS с НДПР, используя следующие инструкции: https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing
Я скачал Java 8 для Windows 64 сборки B118, сконфигурированный файл java.security и создал nss.cfg файл:
Отрывок из java.security файла:
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.pkcs11.SunPKCS11 /devel/nss.cfg
nss.cfg:
# Use NSS as a FIPS-140 compliant cryptographic token
# SunPKCS11-NSS
name = NSS
#32 bit
nssLibraryDirectory = C:\devel\nss\nss-3.15.3.1\dist\WINNT6.1_DBG.OBJ\lib
#64 bit
#nssLibraryDirectory = C:\devel\nss\nss-3.15.3.1\dist\WINNT6.1_64_DBG.OBJ\lib
#non FIPS
#nssDbMode = noDb
#attributes = compatibility
#FIPS
nssSecmodDirectory = c:\devel\fipsdb
nssModule = fips
Я запустил набор тестов, который поставляется с NSS, и он выглядит как все пройденные тесты шифрования/дешифрования (имели некоторые проблемы с тестами, которые требовали имя хоста/имя домена, но это связано с средой Windows).
Итак, вот в чем проблема. Я запускаю свое тестовое приложение для шифрования на Java 7 32 бит с 32-разрядной версией NSS, и все отлично работает. При попытке запуска Java-64 бит с 64-битным НССОМ я получаю следующее сообщение об ошибке:
java.security.ProviderException: Could not initialize NSS
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:212)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:103)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getIndex(Unknown Source)
at sun.security.jca.ProviderList.getProviderConfig(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at java.security.Security.getProvider(Unknown Source)
at sun.security.ssl.SunJSSE.<init>(Unknown Source)
at sun.security.ssl.SunJSSE.<init>(Unknown Source)
at com.sun.net.ssl.internal.ssl.Provider.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at sun.security.jca.ProviderList$ServiceList.tryGet(Unknown Source)
at sun.security.jca.ProviderList$ServiceList.access$200(Unknown Source)
at sun.security.jca.ProviderList$ServiceList$1.hasNext(Unknown Source)
at javax.crypto.KeyGenerator.nextSpi(KeyGenerator.java:323)
at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:158)
at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:208)
at STSAESEncryption.generateKeyWithGenerator(STSAESEncryption.java:74)
at Main.main(Main.java:24)
Caused by: java.io.IOException: %1 is not a valid Win32 application.
at sun.security.pkcs11.Secmod.nssLoadLibrary(Native Method)
at sun.security.pkcs11.Secmod.initialize(Secmod.java:210)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:207)
... 36 more
я отправить сообщение блог Шона Маллана в (связанном выше) и отправил ответ на вопрос: все работает 64 бит, и я не могу заставить его работать в режиме без FIPS (такая же ошибка), но мой ответ еще не появился в блоге (требуется утверждение).
Кто-нибудь еще пытался заставить NSS работать с Java 8 64 бит в Windows 64 бит?
Update 1 на основе Alex Pakka комментарий:
Спасибо за ответ. Я использую 64-битную библиотеку NSS, когда я использую бит Java 8 64. Переключался взад и вперед, когда я тестировал вещи как на 32, так и на 64 бит.
Я прикрепил код и переступил, но когда я пытаюсь просмотреть переменную platformPath, я получаю, что «platformPath не может быть разрешен переменной». Я не очень хорошо знаком с Eclipse, поэтому мне интересно, что я делаю что-то неправильно.
Я попытался отредактировать пути, которые я вставляю, чтобы увидеть, какие ошибки я получу, и когда я изменяю nssLibraryPath в другой каталог (без библиотеки nss), я получаю другую ошибку, а затем win32.
Я знаю, что nss работает с Java 8 64-разрядной версией для Linux (и, возможно, с другими платформами), но действительно ли это было проверено для Windows 64 бит. Я знаю, что это новая функция с Java 8 и Windows 64 бит с Java 7, поддерживающая только бит Windows 43.
Еще раз спасибо за ответ, это помогло, и я все еще пытаюсь понять это.
Обновленный вопрос на основе предложений Алекса –