PKCS #11 ライブラリの既知の問題

影響： PKCS #11 ライブラリのバージョン 3.0.0 で 8 バイト未満の IV を指定すると、キーをアンラップできない場合があります。

回避方法:

解決ステータス： この問題はPKCS、#11 ライブラリのバージョン 3.0.1 で解決されています。キーラップを使用してAESキーをラップするには、 NULLまたは 8 バイト長の IV を指定します。

影響:

回避方法:

解決ステータス： NULL IV を渡すようにラップコードとアンラップコードを修正するか、デフォルトの IV を に指定することを強くお勧めします0xA6A6A6A6A6A6A6A6。

解決策のステータス: FALSE が設定されている場合は、CKA_DERIVE を受け付けるように修正を実装し ます。 AWS CloudHSMにキー取得関数サポートが追加されるまで、TRUE に設定された CKA_DERIVE はサポートされません。修正を利用するには、クライアントと SDK(s) をバージョン 1.1.1 以降に更新する必要があります。

解決策のステータス: CKA_SENSITIVE 属性を受け入れ、適切に遵守するように修正を実装しました。修正を利用するには、クライアントと SDK(s) をバージョン 1.1.1 以降に更新する必要があります。

影響: C_DigestUpdate および C_DigestFinal は実装されません。C_SignFinal も実装されていないため、NULL 以外のバッファでは CKR_ARGUMENTS_BAD でエラーが発生します。

回避策: アプリケーション内でデータをハッシュし、ハッシュの署名 AWS CloudHSM にのみ使用します。

解決ステータス: マルチパートハッシュを正しく実装SDKsするために、クライアントと を修正しています。更新は AWS CloudHSM フォーラムとバージョン履歴ページで告知されます。

影響: プライベートテンプレートに または C_GenerateKeyPair が含まれている場合、CKA_TEMPLATE_INCONSISTENTCKA_MODULUS_BITS は CKA_PUBLIC_EXPONENT を返します。代わりに、すべてのフィールドが FALSE に設定されているプライベートキーを生成します。キーは使用できません。

解決策: アプリケーションによって、エラーコードに加えて使用状況フィールドの値をチェックすることをお勧めします。

解決策のステータス: 修正を実装し、間違ったプライベートキーテンプレートが使用されている場合に適切なエラーメッセージを返すようにします。更新された PKCS #11 ライブラリは、バージョン履歴ページで発表されます。

影響: CKM_AES_GCM メカニズムを使用して 16 KB を超えるデータを暗号化することができません。

回避策: CKM_AES_CBC、CKM_AES_CBC_PAD などの代替メカニズムを使用するか、データを複数部分に分割し、AES_GCM を使用して各部分を個別に暗号化できます。を使用している場合はAES_GCM、データの分割とその後の暗号化を管理する必要があります。 AWS CloudHSM はマルチパート AES-GCM 暗号化を実行しません。FIPS では、 の初期化ベクトル (IV) を で生成AES-GCMする必要があることに注意してくださいHSM。したがって、 AESGCMで暗号化されたデータの各部分の IV は異なります。

解決ステータス: データバッファが大きすぎる場合、 が明示的に失敗SDKするように修正されています。C_EncryptUpdate および C_DecryptUpdateAPIオペレーションCKR_MECHANISM_INVALIDに対して を返します。マルチパート暗号化を使用しなくても大きいバッファをサポートできる代替方法を評価しています。更新は、 AWS CloudHSM フォーラムとバージョン履歴ページで発表されます。

影響: クライアント SDK3 では、 CKM_ECDH1_DERIVEメカニズムを使用して派生したキーが最初にクライアントで使用でき、次に にインポートされますHSM。その後、キーのハンドルがアプリケーションに返されます。

回避策: で SSL/TLS オフロードを実装している場合 AWS CloudHSM、この制限は問題にならない可能性があります。アプリケーションが常に FIPS境界内にキーを保持する必要がある場合は、ECDHキー取得に依存しない代替プロトコルを使用することを検討してください。

解決ステータス: 内でECDHキー取得を完全に実行するオプションを開発していますHSM。更新の実装は、利用可能になり次第バージョン履歴ページで告知されます。

影響: EL6プラットフォームでは Secp256k1 署名の検証が失敗します。検証呼び出しは、CKR_HOST_MEMORY エラーで失敗します。

回避策: PKCS#11 アプリケーションが secp256k1 署名を検証する必要がある場合は、Amazon Linux 1 または任意のEL7プラットフォームを使用することをお勧めします。または、secp256k1 曲線をサポートする OpenSSL パッケージのバージョンにアップグレードします。

解決ステータス: HSMローカル曲線検証が利用できない場合に にフォールバックする修正を実装しています。更新された PKCS#11 ライブラリは、バージョン履歴ページで発表されます。

影響 : 誤った一連の関数を呼び出すと、個々の関数呼び出しの返しが成功しても、最終的な結果は正しくありません。例えば、復号化されたデータが元のプレーンテキストと一致しない場合や、署名が検証できない場合があります。この問題は、シングルパートとマルチパートの両方のオペレーションに影響します。

誤った関数シーケンスの例 :

回避策 : アプリケーションは、PKCS#11 仕様に準拠して、単一およびマルチパートオペレーションの両方に適切な一連の関数呼び出しを使用する必要があります。この状況では、アプリケーションは CloudHSM PKCS #11 ライブラリに依存してエラーを返さないでください。

問題: SDK 5 は、 での読み取り専用セッションのオープンをサポートしていませんC_OpenSession。

影響: C_OpenSession 未対応で CKF_RW_SESSION を呼び出ししようとした場合、呼び出しは失敗し、エラー CKR_FUNCTION_FAILED が返されます。

防止策: セッションを開く際、CKF_SERIAL_SESSION | CKF_RW_SESSION 関数呼び出しに C_OpenSession フラグを渡す必要があります。

問題: Linux SDKの AWS CloudHSM クライアント 5 バージョン 5.0.0 から 5.4.0 では、 ヘッダーファイルは Windows オペレーティングシステムとのみ互換性/opt/cloudhsm/include/pkcs11/cryptoki.hがあります。

影響: Linux ベースのオペレーティングシステム上のアプリケーションにこのヘッダーファイルを含めようとすると、問題が発生する可能性があります。

解決ステータス: このヘッダーファイルの Linux SDK 互換バージョンを含む AWS CloudHSM クライアント 5 バージョン 5.4.1 以降にアップグレードします。