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

問題: 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_INCONSISTENTCKA_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 にありますが、キーの取得手順は複数のステップで実行されます。その結果、各ステップの中間結果がクライアントに存在します。

• 影響: Client 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 Client SDK 5 バージョン 5.0.0 から 5.4.0 では、 ヘッダーファイルは Windows オペレーティングシステムとのみ互換性/opt/cloudhsm/include/pkcs11/cryptoki.hがあります。

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

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