在带有NSS的Windows上Java8 64位，以符合FIPS 140

Question

根据JEP 131，Java8应该为64位Windows提供PKCS#11加密提供程序：https://blogs.oracle.com/mullan/entry/jep_131_pkcs_11_crypto.

考虑到这一点，我使用以下说明下载并构建了带有NSPR的32位和64位版本的NSS：https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing

我为Windows 64 build b118下载了Java8，配置了java.security文件并创建了一个nss.cfg文件：

摘自java。安全文件：

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在Java7 32位上运行我的测试加密应用程序，一切都很好。当我尝试使用64位NSS运行Java8 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

我确实在Sean Mullan的博客上发布了一条消息（链接如上），并对这个问题发表了回复：所有内容都运行64位，我无法使其在非FIPS模式下工作（相同错误），但我的回复尚未显示在博客上（需要批准）。

是否有其他人尝试让NSS在Windows 64位上使用Java 8 64位？

根据Alex Pakka的评论更新1：

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

我附加了代码并逐步执行，但当我尝试查看platformPath变量时，我得到了“platformPath无法解析为变量”。我对Eclipse不是很熟悉，所以我想知道我是否做错了什么。

我尝试编辑我输入的路径以查看我得到了什么错误，当我将nssLibraryPath更改为另一个目录（没有nss库）时，我得到了与win32不同的错误。

我知道nss适用于Linux（可能还有其他平台）的Java8 64位，但它是否已经过Windows 64位的验证。我知道这是Java8和Windows 64位的新功能，Java7仅支持Windows 43位。

再次感谢您的回复，这很有帮助，我仍在努力解决这个问题。

Answer 1

回复：“我不认为NSS是以OpenSSL等源代码形式验证的FIPS 140-2。NSS是一种更传统的验证，就像加密、Certicom和其他验证一样。就NSS而言，您必须从Mozilla获取预构建的二进制文件。”

“FIPS PUB 140-2和加密模块验证程序的实施指南”说您可以从源代码重新编译...我认为我们可以将NSS重新编译为经过认证并在NIST网站上列出的版本。最新的是RedHat的#1837（v3.12.4）。

以下是“FIPS PUB 140-2和加密模块验证程序实施指南”中的关键引述

“CMVP允许供应商将已验证的软件、固件或混合加密模块从验证证书上指定的操作环境移植和重新编译到未作为验证测试一部分的操作环境，只要遵循移植规则。加密模块的验证状态在没有cr的情况下保持正在新的操作环境中重新测试加密模块。然而，如果验证证书上没有列出具体的操作环境，CMVP不会说明模块的正确操作或所生成密钥在如此移植时的安全强度”。

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

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适用于Java8 64位。

html" target="_blank">消息“%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

考虑到这一点，我使用以下说明下载并构建了带有NSPR的32位和64位版本的NSS：https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing ...

我可能有点跑题了......

我不相信NSS是以OpenSSL等源代码形式验证的FIPS 140-2。NSS是一种更为传统的验证，与Crypto、Certicom等类似。对于NSS，您必须从Mozilla获取预构建的二进制文件。

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

最简单的方法可能是通过NIST文件中的网络安全服务（NSS）密码模块版本3.12.4 FIPS 140-2安全策略。（我可能版本错误，因为我不使用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

从上表中，您需要使用风河Linux安全1.0。如果您使用的是风河，那么您还必须拥有至强5500或Core2 Duo。否则，您没有使用经过验证的密码学。

同样，加密在视窗上有三个FIPS 140-2验证（证书343、562和819）。但是，您需要从加密网站下载预构建的二进制文件，并且需要根据提交给NIST的加密安全策略使用它们。这些限制包括操作系统版本，甚至C运行时服务包级别。