AWS CloudHSM용 PKCS#11 SDK의 알려진 문제 - AWS CloudHSM
문제: PKCS #11 라이브러리 버전 3.0.0의 AES 키 래핑은 사용 전에 IV의 유효성을 검사하지 않습니다.문제: PKCS#11 SDK 2.0.4 및 이전 버전에서는 AES 키 래핑 및 래핑 해제에 항상 기본 IV인 0xA6A6A6A6A6A6A6A6를 사용했습니다.문제: CKA_DERIVE 속성이 지원 및 처리되지 않았습니다.문제: CKA_SENSITIVE 속성이 지원 및 처리되지 않았습니다.문제: 멀티파트 해시 및 서명이 지원되지 않습니다.문제: C_GenerateKeyPair는 표준을 준수하는 방식으로 개인 템플릿의 CKA_MODULUS_BITS 또는 CKA_PUBLIC_EXPONENT를 처리하지 않습니다.문제: CKM_AES_GCM 메커니즘을 사용할 때 C_Encrypt 및 C_Decrypt API 작업에 대한 버퍼는 16KB를 초과할 수 없습니다.문제: ECDH(Elliptic-curve Diffie-Hellman) 키 파생은 HSM 내에서 부분적으로 실행됩니다.문제: secp256k1 서명 확인이 CentOS6 및 RHEL 6 등의 EL6 플랫폼에서 실패합니다.문제: 잘못된 함수 호출 순서로 인해 실패하는 대신 정의되지 않은 결과가 발생합니다.문제: SDK 5에서는 읽기 전용 세션이 지원되지 않습니다.문제: cryptoki.h 헤더 파일이 Windows 전용입니다.

AWS CloudHSM용 PKCS#11 SDK의 알려진 문제

다음 문제는 AWS CloudHSM용 PKCS #11 라이브러리에 영향을 미칩니다.

문제: PKCS #11 라이브러리 버전 3.0.0의 AES 키 래핑은 사용 전에 IV의 유효성을 검사하지 않습니다.

길이가 8바이트보다 짧은 IV를 지정하면 사용하기 전에 예측할 수 없는 바이트로 패딩됩니다.

참고

이는 CKM_AES_KEY_WRAP 메커니즘을 사용하는 C_WrapKey에만 영향을 미칩니다.

  • 영향: PKCS #11 SDK 3.0.0에서 8바이트보다 짧은 IV를 제공하는 경우 키를 언래핑할 수 있습니다.

  • 해결 방법:

    • AES 키 래핑 중에 IV 길이를 올바르게 적용하는 PKCS #11 라이브러리 3.0.1 버전 이상으로 업그레이드하는 것이 좋습니다. NULL IV를 전달하도록 래핑 코드를 수정하거나 0xA6A6A6A6A6A6A6A6의 기본 IV를 지정하십시오. 자세한 내용은 AES 키 래핑에 대한 규정 미준수 길이의 사용자 지정 IV를 참조하십시오.

    • 8바이트보다 짧은 IV를 사용하여 PKCS #11 라이브러리 3.0.0 버전으로 키를 래핑한 경우 지원을 요청하십시오.

  • 해결 상태: 이 문제는 PKCS #11 라이브러리 3.0.1 버전에서 해결되었습니다. AES 키 래핑을 사용하여 키를 래핑하려면 NULL 또는 8바이트 길이의 IV를 지정합니다.

문제: PKCS#11 SDK 2.0.4 및 이전 버전에서는 AES 키 래핑 및 래핑 해제에 항상 기본 IV인 0xA6A6A6A6A6A6A6A6를 사용했습니다.

사용자 제공 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에 추가하기 전에는 CKA_DERIVE를 TRUE로 설정할 수 없습니다. 수정의 이점을 누리기 위해서는 클라이언트 및 SDK를 버전 1.1.1 이상으로 업데이트해야 합니다.

문제: CKA_SENSITIVE 속성이 지원 및 처리되지 않았습니다.

  • Resolution status(해결 상태): 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를 처리하지 않습니다.

  • 영향: 프라이빗 템플릿에 or C_GenerateKeyPair가 포함되는 경우 CKA_TEMPLATE_INCONSISTENTCKA_MODULUS_BITS는 CKA_PUBLIC_EXPONENT를 반환해야 합니다. 그 대신 모든 사용 필드가 FALSE로 설정된 프라이빗 키를 생성합니다. 이 키는 사용할 수 없습니다.

  • 해결 방법: 애플리케이션에서 오류 코드 외에도 사용 필드 값을 확인하는 것이 좋습니다.

  • 해결 상태: 잘못된 프라이빗 키 템플릿이 사용되는 경우 적절한 오류 메시지를 반환하도록 수정을 구현하고 있습니다. 업데이트된 PKCS#11 라이브러리가 버전 기록 페이지에 발표됩니다.

문제: CKM_AES_GCM 메커니즘을 사용할 때 C_Encrypt 및 C_Decrypt API 작업에 대한 버퍼는 16KB를 초과할 수 없습니다.

AWS CloudHSM은 다중 부분 AES-GCM 암호화를 지원하지 않습니다.

  • 영향: CKM_AES_GCM 메커니즘을 사용하여 16KB보다 큰 데이터를 암호화할 수 없습니다.

  • 해결 방법: 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(Elliptic-curve Diffie-Hellman) 키 파생은 HSM 내에서 부분적으로 실행됩니다.

EC 프라이빗 키는 항상 HSM 내에 있지만 키 추출 프로세스는 여러 단계로 수행됩니다. 결과적으로 각 단계의 중간 결과를 클라이언트에서 사용할 수 있습니다.

  • 영향: 클라이언트 SDK 3에서 CKM_ECDH1_DERIVE 메커니즘을 사용하는 키 파생은 클라이언트에서 먼저 사용한 다음 HSM에 가져옵니다. 그러면 키 핸들이 애플리케이션에 반환됩니다.

  • 해결 방법: AWS CloudHSM에서 SSL/TLS 오프로드를 구현하는 경우 이 제한 사항은 문제가 되지 않습니다. 애플리케이션에서 항상 키가 FIPS 경계 내에 있어야 하는 경우 ECDH 키 파생에 독립적인 대체 프로토콜을 사용하는 것이 좋습니다.

  • 해결 상태: HSM 내에서 ECDH 키 파생을 완전히 수행할 수 있는 옵션을 개발하고 있습니다. 업데이트가 구현되면 버전 기록 페이지에 발표됩니다.

문제: secp256k1 서명 확인이 CentOS6 및 RHEL 6 등의 EL6 플랫폼에서 실패합니다.

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을 사용하여 읽기 전용 세션을 여는 것을 지원하지 않습니다.

  • 영향: CKF_RW_SESSION을 제공하지 않고 C_OpenSession을 호출하려고 하면 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을 사용하는 경우 헤더 파일 /opt/cloudhsm/include/pkcs11/cryptoki.h는 Windows 운영 체제와만 호환됩니다.

  • 영향: Linux 기반 운영 체제에서 애플리케이션에 이 헤더 파일을 포함하려고 하면 문제가 발생할 수 있습니다.

  • 해결 상태: 이 헤더 파일의 Linux 호환 버전을 포함하는 AWS CloudHSM Client SDK 5 버전 5.4.1 이상으로 업그레이드하십시오.