Windows 8 64位在Windows上，NSS符合FIPS 140标准

时间：2013-12-11 14:04:12

标签： windows 64-bit java-8 fips nss

根据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

我下载了Java 8 for Windows 64 build 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

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

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

根据Alex Pakka评论更新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位。

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

3 个答案:

答案 0 :(得分：1)

  

考虑到这一点，我使用这些说明下载并构建了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的Network Security Services (NSS) Cryptographic Module Version 3.12.4 FIPS 140-2 Security Policy文件。 （我可能有错误的版本，因为我不使用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。否则，您使用验证加密 不。

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

答案 1 :(得分：0)

我会附上源代码，例如来自http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/pkcs11/Secmod.java?av=f 并在第210行放置一个断点来检查platformPath变量（在o​​penjdk 7代码中它是第203行）。它看起来像一个PATH问题。 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位路径。

答案 2 :(得分：0)

re：＆＃34;我不相信NSS是以OpenSSL等源代码形式验证的FIPS 140-2。 NSS是一种比Crypto ++，Certicom等更传统的验证。对于NSS，您必须从Mozilla获取预先构建的二进制文件。＆＃34;

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

以下是“FIPS PUB 140-2实施指南和加密模块验证程序”的主要引用

“CMVP允许供应商移植和重新编译经过验证的软件，固件或混合软件 加密模块从验证证书上指定的操作环境到 操作环境，只要移植，就不包括在验证测试中 遵循规则。加密模块的验证状态保持不使用 加密模块在新的操作环境中重新测试。但是，CMVP没有 关于模块的正确操作或生成的密钥的安全强度的陈述 如果特定操作环境未在验证证书上列出，则移植。

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

相关问题
最新问题