AWS CloudHSM 用の PKCS#11 ライブラリの既知の問題
以下の問題は、AWS CloudHSM 用の PKCS #11 ライブラリに影響します。
トピック
- 問題: PKCS #11 ライブラリのバージョン 3.0.0 での AES キーラップが、使用前に IV を検証しません
- 問題: PKCS #11 SDK 2.0.4 以前のバージョンでは、AES キーのラップとラップ解除に常に 0xA6A6A6A6A6A6A6A6 のデフォルトの IV が使用されていました。
- 問題: CKA_DERIVE 属性はサポート外だったため、処理されませんでした
- 問題: CKA_SENSITIVE 属性はサポート外だったため、処理されませんでした
- 問題: マルチパートのハッシュおよび署名がサポートされていません
- 問題: C_GenerateKeyPair は、プライベートテンプレートで標準に従った方法で は、CKA_MODULUS_BITS や CKA_PUBLIC_EXPONENT を処理しません
- 問題: C_Encrypt メカニズムを使用している場合、 C_Decrypt および CKM_AES_GCM API オペレーションのバッファが 16 KB を超えることができません
- 問題: 楕円曲線ディフィーヘルマン (ECDH) キーの導出が、HSM 内で部分的に実行されます
- 問題: CentOS6 や RHEL 6 などの EL6 プラットフォームで secp256k1 署名の検証が失敗します
- 問題 : 関数呼び出しの順序が正しくないと、失敗する代わりに未定義の結果が得られる。
- 問題 : SDK 5 では読み取り専用セッションは対応していません
- 問題: cryptoki.hヘッダーファイルは Windows 専用です
問題: PKCS #11 ライブラリのバージョン 3.0.0 での AES キーラップが、使用前に IV を検証しません
長さが 8 バイトより短い IV を指定すると、使用前に予測不可能なバイトが埋め込まれます。
注記
これは CKM_AES_KEY_WRAP
メカニズムがある C_WrapKey
にのみ影響します。
影響: PKCS #11 バージョン 3.0.0 で 8 バイトより短い IV を指定した場合、キーをラップ解除できない可能性があります。
回避方法:
PKCS #11 バージョン 3.0.1 以降にアップグレードすることを強くお勧めします。これにより、AES キーラップ時に IV の長さが適切に適用されます。ラップコードを修正して NULL IV を渡すか、
0xA6A6A6A6A6A6A6A6
のデフォルトの IV を指定します。詳細情報は、「トラブルシューティングガイド : AESキーラップ用非対応長さのCustom IV」を参照してください。8 バイトより短い IV を使用して PKCS #11 ba-jon 3.0.0 でキーをラップした場合は、弊社 サポートデスク
へご連絡ください。
解決策のステータス: この問題は PKCS #11 SDK バージョン 3.0.1 で解決されています。AES キーラップを使用してキーをラップするには、NULL または 8 バイトの長さの IV を指定します。
問題: PKCS #11 SDK 2.0.4 以前のバージョンでは、AES キーのラップとラップ解除に常に 0xA6A6A6A6A6A6A6A6
のデフォルトの IV が使用されていました。
ユーザーが指定した IV はそのまま無視されていました。
注記
これは CKM_AES_KEY_WRAP
メカニズムがある C_WrapKey
にのみ影響します。
影響:
PKCS #11 SDK 2.0.4 以前のバージョンとユーザーが指定した IV を使用した場合、キーは
0xA6A6A6A6A6A6A6A6
のデフォルトの IV でラップされます。PKCS #11 SDK 3.0.0 以降とユーザーが指定した IV を使用した場合、キーはユーザーが指定した IV でラップされます。
回避方法:
PKCS #11 SDK 2.0.4 以前でラップされたキーをラップ解除するには、
0xA6A6A6A6A6A6A6A6
のデフォルトの IV を使用します。PKCS #11 SDK 3.0.0 以降でラップされたキーをラップ解除するには、ユーザーが指定した IV を使用します。
解決策のステータス: ラップおよびラップ解除コードを修正して NULL IV を渡すか、
0xA6A6A6A6A6A6A6A6
のデフォルトの IV を指定することを強くお勧めします。
問題: CKA_DERIVE
属性はサポート外だったため、処理されませんでした
-
解決策のステータス:
FALSE
が設定されている場合は、CKA_DERIVE
を受け付けるように修正を実装し ます。AWS CloudHSM にキー取得関数サポートが追加されるまで、TRUE
に設定されたCKA_DERIVE
はサポートされません。この修正を適用するには、クライアントと SDK をバージョン 1.1.1 以上に更新する必要があります。
問題: CKA_SENSITIVE
属性はサポート外だったため、処理されませんでした
-
解決策のステータス:
CKA_SENSITIVE
属性を受け入れ、適切に遵守するように修正を実装しました。この修正を適用するには、クライアントと SDK をバージョン 1.1.1 以上に更新する必要があります。
問題: マルチパートのハッシュおよび署名がサポートされていません
-
影響:
C_DigestUpdate
およびC_DigestFinal
は実装されません。C_SignFinal
も実装されていないため、NULL
以外のバッファではCKR_ARGUMENTS_BAD
でエラーが発生します。 -
解決策: アプリケーション内でデータをハッシュし、AWS CloudHSM はハッシュの署名にだけ使用します。
-
解決策のステータス: クライアントと SDK を修正し、マルチパートハッシュを正しく実装する予定です。更新は AWS CloudHSM フォーラムとバージョン履歴ページで告知されます。
問題: C_GenerateKeyPair
は、プライベートテンプレートで標準に従った方法で は、CKA_MODULUS_BITS
や CKA_PUBLIC_EXPONENT
を処理しません
-
影響: プライベートテンプレートに または
C_GenerateKeyPair
が含まれている場合、CKA_TEMPLATE_INCONSISTENT
CKA_MODULUS_BITS
はCKA_PUBLIC_EXPONENT
を返します。代わりに、すべてのフィールドがFALSE
に設定されているプライベートキーを生成します。キーは使用できません。 -
解決策: アプリケーションによって、エラーコードに加えて使用状況フィールドの値をチェックすることをお勧めします。
-
解決策のステータス: 修正を実装し、間違ったプライベートキーテンプレートが使用されている場合に適切なエラーメッセージを返すようにします。更新された PKCS#11 ライブラリは、バージョン履歴ページで告知されます。
問題: C_Encrypt
メカニズムを使用している場合、 C_Decrypt
および CKM_AES_GCM
API オペレーションのバッファが 16 KB を超えることができません
AWS CloudHSM はマルチパート AES-GCM 暗号化に対応していません。
-
影響:
CKM_AES_GCM
メカニズムを使用して 16 KB を超えるデータを暗号化することができません。 -
回避策:
CKM_AES_CBC
、CKM_AES_CBC_PAD
などの代替メカニズムを使用するか、データを複数部分に分割し、AES_GCM
を使用して各部分を個別に暗号化できます。AES_GCM
を使用する場合、データの分割とその後の暗号化はユーザーが行う必要があります。AWS CloudHSM では、マルチパート AES-GCM 暗号化を自動的に実行しません。FIPS では、AES-GCM
の初期化ベクター (IV) を HSM で生成する必要があります。したがって、AES-GCM 暗号化データの各部分の IV は異なります。 -
解決策のステータス: SDK を修正し、データバッファが大きすぎる場合は明示的に失敗するようにします。
C_EncryptUpdate
およびC_DecryptUpdate
API オペレーションにCKR_MECHANISM_INVALID
を返します。マルチパート暗号化を使用しなくても大きいバッファをサポートできる代替方法を評価しています。更新は AWS CloudHSM フォーラムとバージョン履歴ページで告知されます。
問題: 楕円曲線ディフィーヘルマン (ECDH) キーの導出が、HSM 内で部分的に実行されます
EC プライベートキーは常に HSM にありますが、キーの取得手順は複数のステップで実行されます。その結果、各ステップの中間結果がクライアントに存在します。
-
影響: クライアント SDK 3 では、
CKM_ECDH1_DERIVE
メカニズムを使用して得られたキーは、まずクライアントで使用可能になり、その後 HSM 内にインポートされます。その後、キーのハンドルがアプリケーションに返されます。 -
回避策: AWS CloudHSM に SSL/TLS のオフロードを実装すると、この制限が問題とはならない場合があります。アプリケーションでキーが常に FIPS 境界内に留まる必要がある場合、ECDH キー取得に依存しない代替プロトコルの使用を検討してください。
-
解決策のステータス: ECDH キー取得を完全に HSM 内部で実行するオプションを開発中です。更新の実装は、利用可能になり次第バージョン履歴ページで告知されます。
問題: CentOS6 や RHEL 6 などの EL6 プラットフォームで secp256k1 署名の検証が失敗します
これは、CloudHSM PKCS#11 ライブラリが、OpenSSL を使用して EC 曲線データを検証することにより、検証操作の初期化中にネットワークの呼び出しを回避するために発生します。Secp256k1 は EL6 プラットフォームのデフォルトの OpenSSL パッケージでサポートされていないため、初期化は失敗します。
-
影響: Secp256k1 署名検証が EL6 プラットフォームで失敗します。検証呼び出しは、
CKR_HOST_MEMORY
エラーで失敗します。 -
回避策: PKCS#11 アプリケーションで secp256k1 の署名を検証する必要がある場合は、Amazon Linux 1 または任意の EL7 プラットフォームを使用することをお勧めします。または、secp256k1 曲線 をサポートする OpenSSL パッケージのバージョンにアップグレードすることもできます。
-
解決策のステータス: ローカル曲線検証が利用できない場合に HSM にフォールバックするための修正を実装中です。更新された PKCS#11 ライブラリは、バージョン履歴ページで告知されます。
問題 : 関数呼び出しの順序が正しくないと、失敗する代わりに未定義の結果が得られる。
-
影響 : 誤った一連の関数を呼び出すと、個々の関数呼び出しの返しが成功しても、最終的な結果は正しくありません。例えば、復号化されたデータが元のプレーンテキストと一致しない場合や、署名が検証できない場合があります。この問題は、シングルパートとマルチパートの両方のオペレーションに影響します。
誤った関数シーケンスの例 :
C_EncryptInit
/C_EncryptUpdate
の後にC_Encrypt
が続きますC_DecryptInit
/C_DecryptUpdate
の後にC_Decrypt
が続きますC_SignInit
/C_SignUpdate
の後にC_Sign
が続きますC_VerifyInit
/C_VerifyUpdate
の後にC_Verify
が続きますC_FindObjectsInit
はC_FindObjectsInit
の後に続きます
防止策: アプリケーションを PKCS #11 仕様に準拠して、シングルパートとマルチパートの両方のオペレーションに適切な関数呼び出しを使用する必要があります。この状況では、アプリケーションが CloudHSM PKCS #11 ライブラリに依存してエラーを返す必要はありません。
問題 : SDK 5 では読み取り専用セッションは対応していません
-
問題: SDK 5 では、
C_OpenSession
で読み取り専用セッションを開くことはできません。 -
影響:
C_OpenSession
未対応でCKF_RW_SESSION
を呼び出ししようとした場合、呼び出しは失敗し、エラーCKR_FUNCTION_FAILED
が返されます。 -
防止策: セッションを開く際、
CKF_SERIAL_SESSION | CKF_RW_SESSION
関数呼び出しにC_OpenSession
フラグを渡す必要があります。
問題: cryptoki.h
ヘッダーファイルは Windows 専用です
-
問題: Linux AWS CloudHSM 上のクライアント SDK 5 バージョン 5.0.0~5.4.0 では、ヘッダーファイル
/opt/cloudhsm/include/pkcs11/cryptoki.h
は Windows オペレーティングシステムとのみ互換性があります。 -
影響: Linux ベースのオペレーティングシステム上のアプリケーションにこのヘッダーファイルを含めようとすると、問題が発生する可能性があります。
-
解決策のステータス: このヘッダーファイルの Linux 互換バージョンを含む AWS CloudHSM クライアント SDK 5 バージョン 5.4.1 以降にアップグレードしてください。