根据 JEP 131，Java 8 应该为 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 的 Java 8，配置了 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

我确实向 Sean Mullan 的博客(上面链接)发布了一条消息并发布了对问题的回复:一切都在 64 位上运行，我无法让它在非 FIPS 模式下工作(同样的错误)但我的回复有尚未显示在博客上(需要批准)。

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

更新 1 基于 Alex Pakka 评论:

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

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

我知道 nss 适用于 Linux(可能还有其他平台)的 Java 8 64 位，但它是否已针对 Windows 64 位进行了验证。我知道这是 Java 8 和 Windows 64 位的新功能，而 Java 7 仅支持 Windows 43 位。

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

最佳答案

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 ...

我这里可能跑题了....

我不认为 N​​SS 是 FIPS 140-2 以源形式验证的，例如 OpenSSL。 NSS 是一种更传统的验证，如 Crypto++、Certicom 等。对于 NSS，您必须从 Mozilla 获取预构建的二进制文件。

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

最简单的判断方法可能是通过 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

根据上表，您需要使用 Wind River Linux Secure 1.0。如果您使用的是 Wind River，那么您还必须拥有 Xeon 5500 或 Core2 Duo。否则，您没有使用Validated Cryptography。

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

关于windows - Windows 上的 Java 8 64 位，带有符合 FIPS 140 的 NSS，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20521209/