AWS CloudHSM: FIPS モードから非 FIPS モードへの 3DES キー移行ガイド

本ブログは 2024 年 9 月 26 日に公開された Blog “How to migrate 3DES keys from a FIPS to a non-FIPS AWS CloudHSM cluster” を翻訳したものです。

2024 年 8 月 20 日、AWS は AWS CloudHSM の新しいハードウェアセキュリティモジュール (HSM) インスタンスタイプ hsm2m.medium (本記事では hsm2 と呼びます) の一般提供を発表しました。この新しいタイプには、以前の CloudHSM インスタンスタイプ hsm1.medium (hsm1) と比較して、以下の追加機能が含まれています:

連邦情報処理標準 (FIPS) 140-3 レベル 3 のサポート
CloudHSM クラスターを非 FIPS モードで実行する機能
増加した合計 16,666 キーのストレージ容量
CloudHSM クライアント SDK と CloudHSM クラスター間の相互TLS認証 (mTLS) のサポート

このブログ記事では、バックアップを使用せずに、CloudHSM hsm1 クラスターから非 FIPS モードで実行されている新しい hsm2 クラスターに、トリプル DES (Triple DES または 3DES) キーを安全に移行する手順を説明します。

CloudHSM と 3DES キー

2024 年 1 月 1 日、米国国立標準技術研究所 (NIST) はSP 800-67 Rev. 2 を撤回しました。これは、3DES が暗号化保護の適用 (つまり、暗号化、キーラッピング、メッセージ認証コード (MAC) の生成) のための FIPS 準拠のブロック暗号ではなくなったことを意味します。

3DES を使用していないお客様は、hsm1 バックアップから FIPS モードで実行されている hsm2 クラスターを作成することで、キーを hsm2 クラスターに移行できます。詳細については、バックアップからの AWS CloudHSM クラスターの作成を参照してください。

ワークロードで暗号化処理のために 3DES キーを使用しているお客様には、AWS は以下を推奨しています:

3DES ワークロードを FIPS 承認の最新の対称ブロック暗号である Advanced Encryption Standard (AES) に移行する
決済処理に 3DES を使用している場合は、AWS Payment Cryptography サービスへのワークロードの移行を検討する

ただし、別の暗号化アルゴリズムや暗号化サービスへの移行が実現不可能で、3DES の使用を継続する予定がある場合は、非 FIPS モードで実行されている hsm2 クラスターを使用して 3DES キーを管理し、hsm2 の新しい利点を活用することができます。

非 FIPS CloudHSM クラスターへの移行は、コンプライアンス状況が変更される可能性があることに注意してください。規制基準や認証が FIPS 準拠の暗号化モジュールの実行を要求している場合、この移行は影響を与える可能性があります。非 FIPS クラスターを作成すると、基盤となる FIPS 認証 HSM は非 FIPS モードで実行されるように構成されます。非 FIPS CloudHSM クラスターへの移行を検討する前に、これらの問題を慎重に検討する必要があります。hsm1 と hsm2 に適用される認証とコンプライアンス要件の詳細については、AWS CloudHSM クラスターモードと HSM タイプを参照してください。

通常、既存のバックアップから新しいクラスターを作成することで、既存の CloudHSM クラスターから新しいクラスターにキーを移行できます。ただし、hsm1 クラスターバックアップを使用して非 FIPS hsm2 クラスターにキーを移行することはできません。これは、CloudHSM がコンプライアンスモードを FIPS から非 FIPS に変更することを許可していないためです。しかし、バックアップを使用せずに CloudHSM クラスター間でキーを移行する別の方法があります。以下のソリューションガイダンスでは、RSA-AES ラップメカニズムを使用して、CloudHSM の境界外でキーマテリアルをプレーンテキストで公開することなくキーを移行する方法を示します。RSA-AES メカニズムは、非対称 RSA キーペアに通常関連するペイロードサイズの制限を回避しながら、大きなサイズのキーを移行する利点を提供します。

ソリューション概要

このソリューションでは、CloudHSM CLI を使用して、ソースおよびターゲットの CloudHSM クラスターに対してキー移行コマンドを実行します。図 1 は、ソリューションの概要を示しています。

図 1: ソリューション概要

ワークフローは次のとおりです:

CloudHSM hsm2 で RSA ラッピングキーペアを生成します。
RSA 公開キーを hsm2 CloudHSM クライアントインスタンスにエクスポートします。
RSA 公開キーを CloudHSM hsm1 クライアントインスタンスに移動します。
RSA 公開キーを CloudHSM hsm1 にインポートします。
インポートした RSA 公開キーを使用して指定されたキーをラップします。
ラップされたキーを CloudHSM hsm2 クライアントインスタンスに移動します。
RSA 秘密キーを使用して CloudHSM hsm2 にキーをアンラップします。

この記事の手順は CloudHSM CLI に特化していますが、同じ手順は Java Cryptographic Extension (JCE) や PKCS #11 ライブラリなどの他の CloudHSM SDK でも使用できます。JCE では、RSAWrappingRunner サンプルコードが RSA-AES メカニズムを使用してキーをラップおよびアンラップする方法を示しています。同様に、PKCS #11 では、rsa_wrapping.c サンプルコードが RSA-AES を使用してキーをラップおよびアンラップする方法を示しています。

重要な考慮事項

暗号化キーを移行する際に念頭に置くべき重要な点がいくつかあります:

エクスポート可能なキー – このソリューションはエクスポート可能なキー（属性 extractable が「true」に設定されているキー）でのみ機能します。エクスポート不可のキーを移行する必要がある場合は、それらをローテーションする必要があります：CloudHSM hsm2 クラスターで新しいキーを生成し、hsm1 の古いキーを使用してデータを復号し、hsm2 の新しいキーを使用してデータを再暗号化します。可能であれば、再暗号化には AES などの高度なキーを使用してください。
キーの所有権 – キーが新しいクラスターに移行されると、キーをアンラップする暗号ユーザー (Crypto User, CU) がキーの所有者になります。適切な暗号ユーザーがキーを移行し、それらのキーに依存するアプリケーションが適切な暗号ユーザー認証情報で更新されるようにするための計画が必要です。また、移行後にアンラップされたキーを適切な暗号ユーザーと共有することもできます。これにより、キー移行によるアプリケーションの可用性への影響を防ぐことができます。移行中のキー所有権を管理するには、次のいずれかの戦略を使用できます：
- 推奨される戦略は、まず CloudHSM CLI を使用して hsm2 クラスターに必要な暗号ユーザーを作成し、各ユーザーが hsm1 で現在所有している必要なキーを移行するために使用することです。暗号ユーザーごとに個別のラッピングキーペアを作成するか、必要な暗号ユーザーと共有される 1 つのラッピングキーペアを持つことができます。
- もう一つの戦略は、1 人の暗号ユーザーを採用して必要なキーを移行し、移行後に移行されたキーを適切な暗号ユーザーと共有することです。共有キーには、受信者の暗号ユーザーがキーを変更または共有できないなどの制限があることに注意してください。
キー属性 – キーが移行されると、アンラップ操作中に指定された属性のみがキーに設定されます。hsm1 からキー属性を特定し、hsm2 にアンラップするときにキーに設定するようにしてください。extractable などの一部の属性は、キーの作成時またはアンラップ時にのみ設定できますが、他の属性は key set-attribute を使用して作成後に設定できることに注意してください。属性のリストとそれらを設定できるタイミングについては、CloudHSM CLI のキー属性を参照してください。CloudHSM CLI の key list コマンドを verbose 引数と共に使用して、暗号ユーザーが所有するキーとそれらのキーの属性を一覧表示できます。さらに、アンラップテンプレートを使用して、アンラップ時に設定する必要がある属性を指定できます。この機能は PKCS #11 SDK でのみサポートされていることに注意してください。
HSM バックアップ – 必要なすべてのキーが hsm2 に移行されたことを確認するまで、hsm1 のバックアップを保持することをお勧めします。CloudHSM バックアップ保持ポリシーを設定してバックアップを管理できます。CloudHSM はクラスターの最後のバックアップを削除しないことに注意してください。詳細については、AWS CloudHSM バックアップ保持ポリシーの設定を参照してください。また、共有バックアップの操作で説明されているように、CloudHSM バックアップを他の AWS アカウントと共有することもできます。

前提条件

このソリューションを実装するには、次の前提条件が必要です：

少なくとも 1 つのアクティブな HSM を持つアクティブな CloudHSM hsm1 クラスター
移行する必要があるキーの所有者である hsm1 の暗号ユーザーの認証情報
CloudHSM CLI がインストールされ、CloudHSM クラスターに接続するように設定された Amazon Elastic Compute Cloud (Amazon EC2) インスタンス。クライアントインスタンスの設定と接続方法については、AWS CloudHSM の開始方法を参照してください。
少なくとも 1 つのアクティブな HSM と有効な暗号ユーザーを持つアクティブな CloudHSM hsm2 クラスター。キーの所有権の注意事項で述べたように、移行されたキーを所有する hsm2 に暗号ユーザーを作成してください。
CloudHSM CLI がインストールされ、hsm2 クラスターに接続するように設定された 2 番目の EC2 インスタンス。クライアントインスタンスの設定と接続方法については、AWS CloudHSM の開始方法を参照してください。
hsm1 から移行したいエクスポート可能なキーとその属性のリスト。key list コマンドを verbose 引数と共に使用して、暗号ユーザーが所有するキーを一覧表示できます。出力には、label、extractable、key-type などのキー属性が含まれます。また、コマンドに filter 引数を渡して、label や key-type（3des など）に基づいて特定のキーを一覧表示することもできます。3DES キーとその属性を一覧表示する CloudHSM CLI コマンドは次のとおりです：
```
key list --filter attr.key-type=3des --verbose
```
キー属性の注意事項で述べたように、extractable などの一部の属性はキーの作成時またはアンラップ時にのみ設定できますが、他の属性は key set-attribute コマンドを使用して作成後に設定できます。

以下の点に注意してください：

CloudHSM CLI を設定して複数のクラスターに接続することができます。クライアントインスタンスから両方のクラスターへのネットワークパスを設定できれば、CloudHSM CLI を使用して単一の EC2 インスタンスで、あるクラスターから別のクラスターへキーを移行できます。
CloudHSM CLI コマンドは、インタラクティブモードでコマンドを実行することで、bash スクリプトなどを使用して実行できます。

ステップ 1: hsm2 で RSA ラッピングキーペアを生成する

ソリューションの最初のステップは、CloudHSM CLI を使用して新しい CloudHSM hsm2 クラスターにラッピングキーペアを作成することです。キーペアの公開キーはラッピング（暗号化）に使用され、秘密キーはアンラッピング（復号）に使用されます。キーペアに適切なラベルを付け、そのラベルをメモしておきます。

注意: キーの所有権の注意事項で述べたように、キーを移行するための適切な戦略を選択してください。このステップでラッピングキーペアを生成する暗号ユーザー、またはこのキーペアが共有されている暗号ユーザーは、最終ステップでキーをアンラップする必要があります。

RSA ラッピングキーペアを生成するには:

CloudHSM CLI がインストールされている hsm2 クライアントインスタンスにサインインします。CloudHSM コマンドラインインターフェイス (CLI) の使用開始で説明されているように、インタラクティブモードで CloudHSM CLI を使用するために次のコマンドを実行します:
```
/opt/cloudhsm/bin/cloudhsm-cli interactive 
```
暗号ユーザーの認証情報でサインインします。<CryptoUserName> を自分の情報に置き換え、プロンプトが表示されたらパスワードを入力してください。
```
login --username <CryptoUserName> --role crypto-user
```
次の key generate-asymmetric-pair rsa コマンドを実行して RSA キーペアを作成します。<rsa_wrapping_key_label> と <rsa_unwrapping_key_label> を、生成される公開キーと秘密キーに付ける独自のラベルに置き換えてください。次のステップで必要になるため、公開キーと秘密キーのラベルをメモしておいてください。
```
key generate-asymmetric-pair rsa \
--public-label <rsa_wrapping_key_label> \
--private-label <rsa_unwrapping_key_label> \
--modulus-size-bits 2048 \
--public-exponent 65537 \
--public-attributes wrap=true \
--private-attributes unwrap=true
```
(オプション) CloudHSM CLI を使用したキーのフィルタリングで説明されているように、ラベルを使用してフィルタリングすることでキーを一覧表示できます:
```
key list --filter attr.label=<rsa_unwrapping_key>
```

ステップ 2: RSA 公開キーを hsm2 クライアントインスタンスにエクスポートする

このステップでは、hsm2 から RSA 公開キーを EC2 インスタンスのファイルシステムにエクスポートします。

RSA 公開キーを hsm2 クライアントインスタンスにエクスポートします

次の key generate-file コマンドを実行して、前のステップで作成した RSA 公開キーをエクスポートします。<file_path> と <rsa_wrapping_key_label> を自分のデータに置き換えてください。前のステップで公開キーのラベルをメモしました。エクスポートされた RSA 公開キーのバイトは、指定した <file_path> に PEM 形式で書き込まれます。
```
key generate-file \
--encoding pem \
--path <file_path> \
--filter attr.label=<rsa_wrapping_key_label>
```

ステップ 3: RSA 公開キーを hsm1 クライアントインスタンスに移動する

ここで、エクスポートした公開キー PEM ファイルを hsm2 クライアントインスタンスから hsm1 クライアントインスタンスにコピーする必要があります。企業のファイル転送ソリューションやセキュアコピープロトコル (SCP) を使用できます。ただし、複数のクラスターに接続機能を使用して CloudHSM CLI を hsm1 と hsm2 の両方のクラスターに接続するように設定している場合は、このステップをスキップできます。

ステップ 4: RSA 公開キーを hsm1 にインポートする

このステップでは、hsm1 クライアントインスタンスにコピーした RSA 公開キーを hsm1 クラスターにインポートします。

hsm1 クライアントインスタンスで、暗号ユーザーとして CloudHSM CLI にサインインします。次の key import pem コマンドを実行して公開キーをインポートします。<file_path> と <rsa_wrapping_key_label> を、公開キー PEM ファイルのパスとラベルの値にそれぞれ置き換えてください。

key import pem \
--path <file_path> \
--label <rsa_wrapping_key_label> \
--key-type-class rsa-public
--attributes wrap=true

ステップ 5: インポートした RSA 公開キーを使用してキーをラップする

このステップでは、前提条件の一部として特定した hsm1 のキーをラップします。キーを所有している暗号ユーザーのみがキーをラップアウトできることに注意してください。したがって、その暗号ユーザーとして hsm1 の CloudHSM CLI にサインインする必要があります。

次の key wrap rsa-aes コマンドを実行してキーをラップアウトします。<exportable_key_label> と <rsa_wrapping_key_label> を、ラップアウトするキーのラベルとラッピング RSA 公開キーのそれぞれの値に置き換えてください。

key wrap rsa-aes \
--payload-filter attr.label=<exportable_key_label> \
--wrapping-filter attr.label=<rsa_wrapping_key_label>
--hash-function sha256 \
--mgf mgf1-sha256 \
--path <path_to_the_wrapped_binary_file>

ラップされたキーデータはバイナリ形式で、--path 引数で指定されたファイルパスのファイルシステムに保存されます。ラップされたキーのキータイプをメモしておいてください。この値はステップ 7 のアンラップ時に必要になります。

ステップ 6: ラップされたキーを hsm2 クライアントインスタンスに移動する

ステップ 3 で使用したのと同じ方法を使用して、ラップされたバイナリキーを hsm1 クライアントインスタンスから hsm2 クライアントインスタンスにコピーします。コピーされたファイルのファイルパスをメモしておいてください。

ステップ 7: RSA 秘密キーを使用してラップされたキーを hsm2 クラスターにアンラップする

このステップでは、キーのラップに使用された RSA 公開キーに関連付けられた RSA 秘密キーを使用して、ラップされたキーを hsm2 にアンラップします。ステップ 1 で RSA 秘密キーのラベルをメモし、ステップ 5 でキータイプをメモしました。アンラップする前に覚えておくべき重要なポイントがいくつかあります：

ステップ 1 でラッピングキーペアを作成した暗号ユーザー、またはラッピングキーペアが共有されている暗号ユーザーが、アンラップコマンドを実行するために CloudHSM CLI にサインインする必要があります。
前提条件セクションで述べたように、一部のキー属性は作成時にのみ設定できます。キーに設定したい属性のリストを必ず用意してください。

次の key unwrap rsa-aes コマンドを実行して、キーを hsm2 にアンラップします。これらのコマンド引数を自分の値に置き換えてください：

<key_type_of_wrapped_key>: ラップされたキーのキータイプ（例：AES、3DES）。

<label_of_unwrapped_key>: 新しくアンラップされたキーのラベル。キーを識別するための適切なラベルを選択してください。

<rsa_unwrapping_key_label>: ステップ 1 の RSA 秘密キーラベル。

<path_to_the_wrapped_binary_file>: ステップ 6 からのラップされたキーバイナリファイルへのパス。

<list_of_attributes_for_unwrapped>: アンラップされたキーの KEY_ATTRIBUTE_NAME=KEY_ATTRIBUTE_VALUE 形式のキー属性のスペース区切りリスト。これはオプションです。

key unwrap rsa-aes \
--key-type-class <key_type_of_wrapped_key> \
--label <label_of_unwrapped_key>\
--filter attr.label=<rsa_unwrapping_key_label> \
--hash-function sha256 \
--mgf mgf1-sha256 \
--data-path <path_to_the_wrapped_binary_file> \
--attributes <list_of_attributes_for_unwrapped>

(オプション) ステップ 8: アンラップされたキーの属性を更新する

キーをアンラップする際に必要なすべての属性を設定しなかった場合は、key set-attribute コマンドを使用して、キー属性を今すぐ更新できます。

3DES キーが正常に移行されたかテストする

対称暗号では、暗号化と復号に同じキーが使用されます。3DES は対称キーアルゴリズムです。移行した 3DES キーが hsm2 で同じように機能することを確認するには、次のテストを行うことができます

hsm1 で 3DES キーを使用して単純なメッセージを暗号化し、暗号文を作成する
hsm2 で移行した 3DES キーを使用して暗号文を復号し、平文を取得する

復号された平文は元のメッセージと一致するはずです。

CloudHSM の JCE または PKCS #11 の SDK を使ってテストができます。JCE の DESedeECBEncryptDecryptRunner サンプルコードは、3DES キーを使って暗号化と復号を行う方法を示しています。PKCS #11 の des_ecb.c サンプルコードも、同様に 3DES キーを使って暗号化と復号を行う方法を示しています。

まとめ

このブログ記事では、CloudHSM CLI を使用して CloudHSM hsm1 クラスターから hsm2 クラスターに暗号化キーを移行する方法について学びました。可能な限りバックアップを使用してキーを移行することをお勧めしますが、バックアップの使用が不可能な場合は、この記事で説明したアプローチを使用できます。

この記事では CloudHSM hsm1 と hsm2 間のキーの移行に焦点を当てましたが、同じ方法論を多くの AWS CloudHSM クラスターペア間でのキーの移行にも使用できます。この方法論は、JCE や PKCS #11 などの他の CloudHSM SDK にも拡張して、移行プロセスを自動化することができます。

オンプレミスや他の非 AWS HSM から AWS CloudHSM にキーを移行するには、同じラップとアンラップの原則を適用することもできます。

このポストに関する質問がある場合は、AWS サポートにお問い合わせください。

Amazon Web Services ブログ