Windows上Java 8 64位与NSS兼容，以满足FIPS 140要求

Question

根据JEP 131，Java 8应该为64位Windows：加密提供一个加密密码提供程序。

考虑到这一点，我使用以下说明下载并构建了具有NSPR的NSS 32和64位版本：测试。

我下载了Java8forWindows64Build 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环境有关)。

这就是问题所在。我使用32位版本的NSS在Java 7 32位上运行我的测试加密应用程序，一切都很好。当我试图使用64位NSS运行Java 8 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在Windows 64位上使用Java 8 64位？

基于Alex评论的更新1：

谢谢你的答复。当我使用Java 8 64位时，我使用的是64位NSS库。当我测试32位和64位时，一直在来回切换。

我附加了代码并逐步完成，但是当我试图查看platformPath变量时，我得到了"platformPath不能解析为变量“。我对Eclipse并不太熟悉，所以我想知道我是否做错了什么。

我已经尝试编辑我要输入的路径，以查看我得到了哪些错误，当我将nssLibraryPath更改为另一个目录(没有nss库)时，我得到了一个与win32不同的错误。

我知道nss适用于Linux的Java 8 64位(可能还有其他平台)，但它是否在Windows 64位上得到了验证。我知道这是Java 8和Windows 64位的一个新特性，Java 7只支持Windows 43位。

再次感谢你的回复，它帮助了我，我仍在努力解决这个问题。

Answer 1

考虑到这一点，我使用以下说明下载并构建了32位和64位版本的NSPR：测试 .

我可能不在这里.

我不相信NSS是FIPS 140-2以像OpenSSL这样的源形式被验证的.NSS是一种更传统的验证，如Crypto++、Certicom和其他的验证。对于NSS，您必须从Mozilla获得预构建的二进制文件。

如果Mozilla没有为Windows提供FIPS 140-2验证的二进制文件，或者没有为您需要的Windows平台提供FIPS 140-2验证的二进制文件，那么我认为您运气不佳。

最简单的判断方法可能是使用NIST在文件上遍历网络安全服务(NSS)加密模块版本3.12.4 FIPS 140-2安全策略。(我可能有错误的版本，因为我不使用NSS；一定要检查这是最新的安全策略)。

根据在1上提到的安全策略，似乎只有两个平台vlaidated，也没有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

从上表中可以看出，您需要使用风力河Linux安全1.0。如果您使用的是风河，那么您也必须有一个Xeon 5500或Core2二重奏。否则，您是而不是使用已验证的密码的。

类似地，Crypto++在Windows上有三个FIPS 140-2验证(证书343、562和819).但是，您需要从Crypto++网站下载预构建的二进制文件，并且需要根据Crypto++安全策略与NIST一起使用它们。这些限制包括操作系统版本，甚至C运行时服务包级别。

Answer 2

我会附加源代码，例如来自http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/pkcs11/Secmod.java?av=f的源代码，并在第210行放置一个断点来检查platformPath变量(在openjdk 7代码中，它是第203行)。这看起来确实是个路径问题。NSS与Java 8 64位一起工作。

消息"%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进程中，因此这个路径需要注释，32位路径应该被注释掉。

Answer 3

re：“我不认为NSS是FIPS 140-2，它是以像OpenSSL这样的源代码形式验证的。NSS是一种更传统的验证，就像Crypto++、Certicom和其他方面的验证一样。在NSS的例子中，您必须从Mozilla获得预构建的二进制文件。”

“FIPS发布140-2和密码模块验证程序的实现指南”说，您可以从源代码重新编译。我认为我们可以将NSS重新编译成经过认证的版本，并在NIST网站上列出。最近一次是RedHat的#1837 (v3.12.4)。

以下是“FIPS发布140-2和密码模块验证程序的实现指南”中的关键引号

“CMVP允许供应商将经过验证的软件、固件或混合密码模块从验证证书上指定的操作环境移植和重新编译到不作为验证测试的一部分的操作环境，只要遵循移植规则。不需要在新的操作环境中重新测试加密模块，就可以维护加密模块的验证状态。但是，如果验证证书中没有列出特定的操作环境，则CMVP不会声明模块的正确操作或在移植时生成的密钥的安全强度“。

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