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

Question

根據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 8（以及可能的其他平台）的Java 8 64位，但確實已經驗證了Windows 64位。 我知道這是Java 8和Windows 64位的新功能，Java 7僅支持Windows 43位。

再次感謝您的回復，它有所幫助，我仍在努力解決這個問題。

Answer 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提交的網絡安全服務（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

從上表中，您需要使用Wind River Linux Secure 1.0。 如果您使用的是Wind River，那么您還必須擁有Xeon 5500或Core2 Duo。 否則，您沒有使用Validated Cryptography 。

類似地，Crypto ++在Windows上有三個FIPS 140-2驗證（證書343,562和819）。 但是，您需要從Crypto ++網站下載預構建的二進制文件，並且需要根據向NIST提交的加密++安全策略來使用它們。 這些限制包括操作系統版本甚至C運行時Service Pack級別。

Answer 2

我會附上源代碼，例如來自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位路徑。

Answer 3

re：“我不相信NSS是像OpenSSL那樣以源代碼形式驗證的FIPS 140-2.NSS是一種比Crypto ++，Certicom等更傳統的驗證。在NSS的情況下，你必須獲得預建來自Mozilla的二進制文件。“

“FIPS PUB 140-2實施指南和加密模塊驗證程序”說您可以從源代碼重新編譯。我認為我們可以將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