3

JEP 131 によると、Java 8 は 64 ビット Windows 用の PKCS#11 Crypto プロバイダーを提供する必要があります: https://blogs.oracle.com/mullan/entry/jep_131_pkcs_11_crypto

それを念頭に置いて、次の手順を使用して、NSPR を使用して 32 ビット バージョンと 64 ビット バージョンの両方の NSS をダウンロードしてビルドしました

Windows 64 ビルド 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 のブログ (上記のリンク) にメッセージを投稿し、質問への返信を投稿しました。ブログにはまだありません (承認が必要です)。

Windows 64 ビットで Java 8 64 ビットで NSS を動作させようとした人はいますか?

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 ビットのみをサポートしています。

返信ありがとうございます。それは役に立ちました。私はまだこれを理解しようとしています。

4

3 に答える 3

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) 暗号化モジュール バージョン 3.12.4 FIPS 140-2 セキュリティ ポリシーを確認することです。(NSS を使用していないため、バージョンが間違っている可能性があります。最新のセキュリティ ポリシーであることを確認してください)。

1で述べたセキュリティ ポリシーによると、検証済みのプラットフォームは2 つだけで、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 での 3 つの FIPS 140-2 検証 (証明書 343、562、および 819) があります。ただし、Crypto++ Web サイトからビルド済みのバイナリをダウンロードする必要があり、NIST に提出された Crypto++ セキュリティ ポリシーに従ってそれらを使用する必要があります。制限には、OS のバージョンや C ランタイム サービス パックのレベルも含まれます。

于 2014-01-31T19:47:11.057 に答える
0

re:「NSS が、OpenSSL のようなソース形式で検証された FIPS 140-2 であるとは思いません。NSS は、Crypto++、Certicom などのような、より伝統的な検証です。NSS の場合、事前に構築されたものを取得する必要があります。 Mozilla からのバイナリ。」

「FIPS PUB 140-2 および暗号化モジュール検証プログラムの実装ガイダンス」には、ソースから再コンパイルできると書かれています。NSS を再コンパイルして、認定されて NIST Web サイトにリストされているバージョンにすることができるというのが私の意見です。最新は RedHat (v3.12.4) による #1837 です。

以下は、「FIPS PUB 140-2 および暗号モジュール検証プログラムの実装ガイダンス」からの重要な引用です。</p>

「CMVP は、検証証明書で指定された運用環境から検証テストの一部として含まれていない運用環境への、検証済みのソフトウェア、ファームウェア、またはハイブリッド暗号モジュールのベンダーの移植と再コンパイルを可能にします。続いた。暗号モジュールの検証ステータスは、暗号モジュールが新しい運用環境で再テストされることなく維持されます。ただし、CMVP は、特定の動作環境が検証証明書に記載されていない場合、モジュールの正しい動作や、そのように移植されたときに生成されたキーのセキュリティ強度については何も述べていません。」

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

于 2015-01-19T21:37:07.773 に答える
0

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/pkcs11/Secmod.java?av=f などからソース コードを添付します。変数をチェックするためのブレークポイントをplatformPath210 行目に配置します (openjdk 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 ビット パスをコメント アウトする必要があります。

于 2013-12-12T20:28:49.473 に答える