2013-12-11 4 views
3

Согласно 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.

Еще раз спасибо за ответ, это помогло, и я все еще пытаюсь понять это.

ответ

0

Я бы приложил исходный код, например. от http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/pkcs11/Secmod.java?av=f и поставить контрольную точку для проверки platformPath переменной в строке 210 (в коде openjdk 7 это строка 203). Это похоже на проблему PATH. NSS работает с Java 8 64bit.

Сообщение «% 1 не является допустимым приложением Win32» вводит в заблуждение и исходит от самой Windows, это может просто означать, что nss3.dll не найден на пути к библиотеке.

Кроме того, в вашем коде, что и вы в nss.cfg

#64 bit 
#nssLibraryDirectory = C:\devel\nss\nss-3.15.3.1\dist\WINNT6.1_64_DBG.OBJ\lib 

можно загрузить только 64-битные библиотеки в 64 разрядном процессе Java, поэтому этот путь должен быть просто не комментируются, и путь 32bit должен быть прокомментированным.

+0

Обновленный вопрос на основе предложений Алекса –

1

With that in mind, I downloaded and built both 32 and 64 bit versions of NSS with NSPR using these instructions: https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing ...

Я мог бы быть от марки здесь ....

Я не верю, что NSS является FIPS 140-2 подтверждено в виде исходного кода, как OpenSSL. NSS является более традиционной проверкой, например, Crypto ++, Certicom и другими. В случае NSS вам необходимо приобрести предварительно созданные двоичные файлы из Mozilla.

Если Mozilla не предоставила проверенные двоичные файлы FIPS 140-2 для Windows или не предоставила проверенные двоичные файлы FIPS 140-2 для платформы Windows, то вам кажется, что вам не повезло.

Самый простой способ рассказать, вероятно, проходит через файл Network Security Services (NSS) Cryptographic Module Version 3.12.4 FIPS 140-2 Security Policy по файлу с NIST. (Возможно, у меня неправильная версия, потому что я не использую NSS, не забудьте проверить ее последнюю политику безопасности).

В соответствии с Политикой безопасности, указанной в 1, появляется только две платформы, и ни одна из них не является Windows. Смотрите Раздел 2.2, платформа (Страница 8):

Model       |Operating System and Version 
------------------------------+---------------------------- 
x86_64 Nehalem Xeon 5500  |Wind River Linux Secure 1.0 
------------------------------+---------------------------- 
x86_64 Pentium core2 duo  |Wind River Linux Secure 1.0 

Из приведенной выше таблицы, вы должны использовать River Wind Linux Secure 1.0. Если вы используете Wind River, то у вас также должен иметь Xeon 5500 или Core2 Duo. В противном случае вы находитесь не с использованием Проверенная криптография.

В аналогичном ключе Crypto ++ имеет три проверки FIPS 140-2 в Windows (сертификаты 343, 562 и 819). Однако вам нужно загрузить предварительно созданные двоичные файлы с сайта Crypto ++, и вам нужно использовать их в соответствии с политикой безопасности Crypto ++, зарегистрированной в NIST. К ограничениям относятся версии ОС и даже C Runtime Service Pack.

+0

Тьфу, получая модуль FIPS апробированы работы с Java, вероятно, худший опыт программирования у меня никогда не было. Спасибо за понимание, однако; Я считаю, что ты прав. Сохраняет боль от использования NSS и понимает это позже. –

0

re: «Я не верю, что NSS является FIPS 140-2, утвержденным в исходной форме, такой как OpenSSL. NSS - это более традиционная проверка, например, Crypto ++, Certicom и др. В случае NSS вам необходимо приобрести предварительно созданные двоичные файлы из Mozilla. "

«Руководство по внедрению для FIPS PUB 140-2 и программа проверки криптографического модуля» говорит, что вы можете перекомпилировать исходный код. По моему мнению, мы можем перекомпилировать NSS для версии, сертифицированной и указанной на веб-сайте NIST. Последний - # 1837 от RedHat (v3.12.4).

Вот ключевые цитаты из «Руководства по осуществлению для FIPS PUB 140-2 и валидации программы Cryptographic Module» в

«CMVP позволяет поставщика портирование и повторно составление проверенного программного обеспечения, встроенного программного обеспечения или гибрида криптографический модуль из операционной среды, указанной в сертификате проверки, в операционную среду , которая не была включена как часть проверки валидации при условии соблюдения правил портирования .Статус проверки криптографического модуля поддерживается без криптографического модуля , который повторно тестируется в новой операционной среде. Тем не менее, CMVP не делает заявление относительно правильной работы модуля или сильных сил безопасности сгенерированных ключей, когда портирован, если конкретная операционная среда не указана в сертификате проверки ».

http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf