すべてのブログ投稿を表示
25.0.0.12 で独自の AES-256 キーの持ち込みと、IBM Semeru Runtimes による FIPS 140-3 のサポート
このリリースでは、独自の Base64 エンコードされた AES-256 キーを提供するサポートが導入され、起動時に Liberty がキーを導出する必要がなくなり、より高速で効率的なパスワード暗号化が実現されます。また、サポートされている IBM Semeru Runtime バージョン（11.0.29、17.0.17、21.0.9、25.0.1 以降）で Liberty を実行する際の FIPS 140-3 準拠が追加されます。
In Open Liberty 25.0.0.12:
25.0.0.12 で修正されたバグのリストは こちら です。
以前の Open Liberty GA リリースのブログ投稿 もチェックして下さい。
25.0.0.12 でアプリを開発して実行する
もし Maven を使用しているなら、pom.xml に以下を含めます。
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.11.5</version>
</plugin>Gradle を使用している場合は、build.gradle ファイルに以下を含めます。
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.6'
}
}
apply plugin: 'liberty'コンテナ・イメージ を使用する場合は以下です。
FROM icr.io/appcafe/open-libertyもしくは ダウンロード・ページ をご覧下さい。
IntelliJ IDEA、Visual Studio Code または Eclipse IDE を使用している場合、これらの IDE で効率的な開発・テスト・デバッグとアプリケーション管理のすべてを実行するために、オープンソースの Liberty Tools を利用することができます。
独自の AES-256 キーの持ち込み
Liberty では、パスワード暗号化のために Base64 エンコードされた 256 ビット AES キーを提供できるようになりました。
新機能
以前、Liberty は wlp.password.encryption.key プロパティをサポートしており、パスワードを受け取り、計算集約的なプロセスを通じて AES キーを導出していました。この導出には、ソルトを使用した繰り返しハッシュが多数の反復にわたって含まれており、サーバー起動時にオーバーヘッドが追加されていました。
現在では、事前に生成された AES キーを直接提供できるようになりました。これにより導出ステップが不要になり、起動時間が短縮され、パスワードの暗号化と復号化時のランタイム・パフォーマンスが向上します。
有効化の方法
-
256 ビット AES キーの取得
セキュリティ・インフラストラクチャから 256 ビット AES キーを取得するか、
securityUtility generateAESKeyコマンドを使用して生成できます。securityUtilityを使用して 256 ビット AES キーを生成するには、新しいsecurityUtility generateAESKeyタスクを実行します：-
ランダムな AES キーを生成する：
./securityUtility generateAESKey -
オプションで、ランダムな AES キーを XML ファイルに保存する：
securityUtility generateAESKey --createConfigFile=myAesConfig.xml -
または、パスフレーズから非ランダムな AES キーを生成する：
./securityUtility generateAESKey --key=<password> -
オプションで、パスフレーズから非ランダムな AES キーを生成し、XML ファイルに保存する：
securityUtility generateAESKey --key=<password> --createConfigFile=myAesConfig.xml
-
-
Liberty でキーを設定する
server.xmlファイルで AES キーを直接設定するには、以下の変数定義を追加します：<variable name="wlp.aes.encryption.key" value="<your_aes_key>" />または、外部設定ファイル（
generateAESKey --createConfigFileで生成されたファイルなど）から AES キーをロードするには、以下の設定を使用してファイルをインクルードします。注意： インクルードされるファイルには、前述のように
wlp.aes.encryption.keyの変数定義が含まれている必要があります。<include location="/path/to/myAesConfig.xml" /> -
パスワードを暗号化する
securityUtility encodeコマンドを実行して、AES-256 キーを使用するパスワードを暗号化できます：-
キーを直接提供する：
securityUtility encode --encoding=aes --base64Key=<your_base64_key> <password> -
AES キー変数を含む XML または Java プロパティ・ファイルを使用するには、
--aesConfigFileオプションを指定します：securityUtility encode --encoding=aes --aesConfigFile=<xml_or_properties_file_path> <password>
-
-
設定を更新する
結果として得られた暗号化された値を Liberty 設定にコピーします。
パフォーマンスのヒント： 最高のパフォーマンスを得るには、新しい AES-256 キーを使用してすべてのパスワードを再暗号化してください。Open Liberty は古いパスワード形式をサポートしていますが、完全な移行により一貫した起動パフォーマンスが提供されます。
AES 暗号化をサポートする Liberty コマンドは、以下のオプションを受け入れます：
-
--base64Keyまたは--passwordBase64Key：Base64 エンコードされた AES-256 キーを直接提供します。 -
--aesConfigFile：wlp.aes.encryption.keyまたはwlp.password.encryption.keyを定義する設定ファイルを提供します。
その他のコマンドライン・タスクも、同様の方法で Base64 キーと AES 設定ファイルを受け入れるように更新されています：
-
securityUtility-
createSSLCertificate -
createLTPAKeys -
encode
-
-
configUtility-
install
-
-
collective-
create -
join -
replicate
-
IBM Semeru Runtimes による FIPS 140-3 のサポート
FIPS 140-3 は FIPS 140 標準の最新バージョンであり、暗号化モジュールのセキュリティと整合性を確保するための一連のガイドラインを提供します。FIPS 140-3 のサポートは、バージョン 25.0.0.3 で IBM JDK 8 を使用した Liberty で初めて導入されました。このリリースでは、Open Liberty は IBM Semeru Runtimes バージョン 11.0.29、17.0.17、21.0.9、25.0.1 以降を使用する際に FIPS 140-3 標準をサポートします。
FIPS 140-3 の有効化
securityUtility には、FIPS 140-3 を有効にするための configureFIPS という新しいタスクがあります。この新しいタスクは、IBM Semeru Runtimes と IBM SDK 8 の両方に適用されます。
configureFIPS タスクは 3 つのレベルで動作します：
-
Install
-
Server
-
Client
すべてのサーバー、クライアント、およびツール全体で有効にするには、以下を実行して Install レベルで FIPS 140-3 を有効にできます：
securityUtility configureFIPS特定のサーバーを有効化または設定するには、以下を実行します：
securityUtility configureFIPS --server=<server name>特定のクライアントを有効化または設定するには、以下を実行します：
securityUtility configureFIPS --client=<client name>IBM Semeru Runtimes の場合、これらのコマンドは FIPS 有効化要件を設定し、アプリケーションの必要な制約を設定するために編集できる Java セキュリティ・プロパティ・ファイルを作成します。 制約の設定の詳細については、プロファイルの拡張の作成 に関するドキュメントを参照してください。
特定の場所または特定の名前でプロファイルを作成するには、--customProfileFile=<file path (or paths) separated by the OS-specific path separator> 引数を指定でき、編集可能なファイルが作成されます。ファイルの名前がプロファイルの名前として使用されます。設定は、提供されたファイルを指すように設定されます。
プロパティには複数のファイルを指定できます。すべてのファイルが作成され、前のファイルを拡張し、指定された最後のファイルがチェーンの最後になります。
securityUtility configureFIPS コマンドの一部として --customProfileFile を指定しない場合、ファイルは以下の場所に作成されます。場所は、サーバーまたはクライアントを指定したかどうかによって異なります。
-
サーバーもクライアントも指定されていない場合
<Liberty install location>/wlp/etc/FIPS140-3-Liberty-Application.properties -
サーバーが指定されている場合
<server root>/resources/security/FIPS140-3-Liberty-Application.properties -
クライアントが指定されている場合
<client root>/resources/security/FIPS140-3-Liberty-Application.properties
有効化されている必要なレベルで FIPS 140-3 を無効にするには、コマンドに以下のオプションを追加します。
--disableLTPA
FIPS 140-3 が有効になっている場合、サーバーは FIPS 140-3 承認の暗号化アルゴリズムを使用して生成された LTPA キーのみをロードできます。LTPA シングル・サインオン（SSO）を機能させるには、ユーザーはすべてのサーバーで FIPS 140-3 を使用するように設定する必要があります。設定の詳細については、ドキュメント を参照してください。
FIPS 140-3 が有効化された後にサーバーが再起動されると、FIPS 承認アルゴリズムで生成された新しい ltpa.keys ファイルが自動的に作成されます。FIPS 140-3 が有効化される前に作成された既存の ltpa.keys ファイルは、ltpa.keys.nofips にバックアップされます。
お客様は、FIPS 140-3 が有効化される前に作成された検証キー・ファイルを再作成するために、securityUtility createLTPAKeys コマンドを使用する必要があります。
securityUtility を使用した新しい FIPS 承認 LTPA キーの作成：
securityUtility コマンドの createLTPAKeys オプションを使用して LTPA キーを作成することもできます。FIPS 140-3 承認アルゴリズムで LTPA キーを生成するには、インストール・レベルで FIPS 140-3 を設定します。
securityUtility createLTPAKeys --password=mypassword --passwordEncoding=aesSAML
Liberty SAML Web Browser SSO 暗号化は、IBM Semeru FIPS 140-3 認定の ECDH-ES キー交換をサポートするようになりました。
Liberty は、SHA256、SHA384、SHA512、および ECDSAwithSHA256、ECDSAwith384、ECDSAwith512 を含む、SAML のより強力な署名アルゴリズムをサポートするようになりました。
FIPS 140-3 モードが有効な場合にサポートされる署名メソッド・アルゴリズム・オプション
サポート対象：
-
SHA256
-
SHA384（25.0.0.12 以降）
-
SHA512（25.0.0.12 以降）
-
ECDSAwithSHA256（25.0.0.12 以降）
-
ECDSAwithSHA384（25.0.0.12 以降）
-
ECDSAwithSHA512（25.0.0.12 以降）
サポート対象外：
-
SHA1
使用例
<samlWebSso20 id="defaultSP" signatureMethodAlgorithm="SHA256" />FIPS 140-3 モードが有効な場合にサポートされる暗号化アルゴリズム
サポート対象：
-
ECDH-ES
サポート対象外：
-
SAML 暗号化が有効な場合の RSA-OAEP 暗号化キー転送。
注意： IBM Semeru ランタイムで使用されている FIPS モジュールは、将来のリリースで RSA-OAEP 操作を認定する予定です。
wsSecurity-1.1
wsSecurity-1.1 フィーチャーは、ECDH-ES アルゴリズムを活用して、署名と暗号化のための楕円曲線キーの使用をサポートするようになりました。
アプリケーションの制約の定義
FIPS 140-3 が設定されている場合、Semeru ランタイムは、FIPS140-3-Strongly-Enforced 制限付きセキュリティ・モード・プロファイル が有効になっているときに、サーバー全体で FIPS 140-3 承認アルゴリズムの使用を強制します。Semeru FIPS 140-3 の暗号化アルゴリズムの強制は、アルゴリズムの使用を区別しません。たとえば、メッセージ・ダイジェスト・ハッシュ（通常は 2 つの値を比較するために使用される）での SHA1 の使用は FIPS 140-3 仕様で許可されていますが、SHA1 の使用に区別がないため、Semeru FIPS 140-3 は依然として例外をスローします。例外が発生した場合は常に、原因を調査し、必要に応じてアルゴリズムを更新してください（この場合、たとえば SHA-256 または SHA-512 に）。問題が暗号化に関連しておらず、その使用が FIPS 140-3 仕様で許可されている場合は、許可された制約としてカスタム・プロファイルの例外リストに追加してください。
IBM Semeru は、プロファイルを使用して制約を適用し、Java セキュリティ・プロバイダーとアルゴリズムへのアクセスを許可して、FIPS 140-3 準拠を確保します。Strongly-enforced または Strict プロファイルがベースとして使用される場合、SHA-1 などのアルゴリズムは、制約が追加されて許可されるまで、どのアプリケーション・クラスでも使用できません。
SHA-1 などの非 FIPS 140-3 メッセージ・ダイジェストを使用している場合、次のような例外が表示される場合があります：
java.security.NoSuchAlgorithmException: SHA1 MessageDigest not available
at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
at java.base/java.security.MessageDigest.getInstance(MessageDigest.java:185)
at io.openliberty.fips.test.application.ObjectComparator.compareObjects(ObjectComparator.java:463)アプリケーションがオブジェクトを比較しているため、SHA-1 を使用できます。
FIPS を有効にする一環として作成されたプロパティ・ファイルで、アルゴリズムを提供するプロバイダーの下に制約を追加できます。
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-Liberty-Application.jce.provider.1 = com.ibm.crypto.plus.provider.OpenJCEPlusFIPS [+ \
{MessageDigest, SHA-1, *, FullClassName:io.openliberty.fips.test.application.ObjectComparator}]注意： 例外では SHA1 が欠落していると述べられていますが、アルゴリズムの名前は SHA-1 であり、SHA1 はそのエイリアスです。
アプリケーションに Java セキュリティ・プロバイダーが含まれている場合、または FIPS140-3-Liberty または FIPS140-3-Strongly-Enforced プロファイルにまだ登録されていない新しいプロバイダーを追加する必要がある場合は、FIPS セキュリティ・プロパティ・ファイルにも含める必要があります。
次のようにプロバイダーを追加できます：
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-Liberty-Application.jce.provider.51 = io.openliberty.fips.test.custom.SecurityProviderプロバイダーの定義内に制約を指定しない場合、そのプロバイダーが提供するすべてのアルゴリズムがランタイム内のすべてのクラスで使用可能になります。さらに、追加する新しいプロバイダーは、プロバイダー位置 51 から配置する必要があります。
FIPS 140-3 サポート および SAML Web Browser SSO の詳細については、ドキュメントを参照してください。
また、いくつかの異なるシナリオで追加する必要がある制約の例については、トラブルシューティング セクションを参照してください。
このリリースでのセキュリティ脆弱性（CVE）の修正
| CVE | CVSS スコア | 脆弱性評価 | 影響を受けるバージョン | 備考 |
|---|---|---|---|---|
7.5 |
SMTP インジェクション |
17.0.0.3-25.0.0.11 |
|
過去のセキュリティ脆弱性修正のリストについては、セキュリティ脆弱性（CVE）リスト を参照してください。
