JCE SDK의 알려진 문제

문제: 비동기 키 페어로 작업할 때 키를 명시적으로 생성하거나 가져오지 않더라도 점유된 키 용량이 보입니다.

• 영향: 이 문제로 인해 HSM에서 예기치 않게 키 공간이 부족해질 수 있으며 이 문제는 애플리케이션이 CaviumKey 객체 대신 표준 JCE 키 객체를 암호화 작업에 사용할 때 발생합니다. 표준 JCE 키 객체를 사용할 때는 애플리케이션이 종료될 때까지 세션 키가 이 키를 삭제하지 않으므로 CaviumProvider가 해당 키를 HSM으로 묵시적으로 가져옵니다. 결과적으로 애플리케이션이 실행되는 동안 키가 증가하여 HSM에서 사용 가능한 키 공간이 부족하게 되고 따라서 애플리케이션이 중단됩니다.

• 해결 방법: CaviumSignature 클래스, CaviumCipher 클래스, CaviumMac 클래스 또는 CaviumKeyAgreement 클래스를 사용할 때는 표준 JCE 키 객체 대신 CaviumKey로 키를 제공해야 합니다.

  ImportKey 클래스를 사용하여 일반 키를 CaviumKey로 수동으로 변환한 다음 작업이 완료된 후 수동으로 키를 삭제할 수 있습니다.

• 해결 상태: 묵시적 가져오기를 적절하게 관리할 수 있도록 CaviumProvider를 업데이트하고 있습니다. 수정 사항이 제공되면 버전 기록 페이지에 발표됩니다.

문제: JCE는 읽기 전용입니다. KeyStore

• 영향: 현재 HSM에서 지원하지 않는 객체 유형을 JCE 키 스토어에 저장할 수 없습니다. 특히 인증서를 키 스토어에 저장할 수 없습니다. 따라서 키 스토어에서 인증서를 찾으려는 jarsigner와 같은 도구와의 상호 운용성이 방해를 받습니다.

• 해결 방법: 키 스토어가 아닌 로컬 파일이나 S3 버킷 위치에서 인증서를 로드하도록 코드를 고칠 수 있습니다.

• 해결 상태: 키 스토어에 인증서 스토리지 지원을 추가하고 있습니다. 기능이 제공되면 버전 기록 페이지에 발표됩니다.

문제: AES-GCM 암호화를 위한 버퍼가 16,000바이트를 초과할 수 없습니다.

또한 멀티파트 AES-GCM 암호화가 지원되지 않습니다.

• 영향: AES-GCM을 사용하여 16,000바이트보다 큰 데이터를 암호화할 수 없습니다.

• 해결 방법: AES-CBC와 같은 대체 메커니즘을 사용하거나, 데이터를 여러 개로 분리하고 각 부분을 개별적으로 암호화할 수 있습니다. 데이터를 나누는 경우 분할된 암호문과 암호 해독을 관리해야 합니다. FIPS에서는 AES-GCM의 IV(초기화 벡터)를 HSM에서 생성해야 하므로 AES-GCM으로 암호화된 각 데이터의 IV가 다릅니다.

• 해결 상태: 데이터 버퍼가 너무 큰 경우 명시적으로 실패하도록 SDK를 수정하고 있습니다. 멀티파트 암호화에 의존하지 않고 더 큰 버퍼를 지원하기 위한 대체 방법을 평가하고 있습니다. AWS CloudHSM 포럼 및 버전 기록 페이지에 업데이트가 발표됩니다.

문제: ECDH(Elliptic-curve Diffie-Hellman) 키 파생은 HSM 내에서 부분적으로 실행됩니다.

EC 프라이빗 키는 항상 HSM 내에 있지만 키 추출 프로세스는 여러 단계로 수행됩니다. 결과적으로 각 단계의 중간 결과를 클라이언트에서 사용할 수 있습니다. ECDH 키 파생 샘플은 Java 코드 샘플에서 사용 가능합니다.

• 영향: 클라이언트 SDK 3이 JCE에 ECDH 기능을 추가합니다. KeyAgreement클래스를 사용하여 SecretKey a를 파생하면 먼저 클라이언트에서 클래스를 사용할 수 있게 되고 HSM으로 가져옵니다. 그러면 키 핸들이 애플리케이션에 반환됩니다.

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

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

문제: 키 크기 KeyGenerator 매개 KeyAttribute 변수를 비트 대신 바이트 수로 잘못 해석합니다.

KeyGenerator 클래스의 init 함수나 AWS CloudHSM KeyAttribute 열거형의 SIZE 속성을 사용하여 키를 생성할 때 API는 인수가 키 바이트 수가 아니라 키 비트 수가 되어야 한다고 잘못 예상합니다.

• 영향: Client SDK 버전 5.4.0~5.4.2에서는 지정된 API에 키 크기가 바이트로 제공될 것으로 잘못 예상합니다.

• 해결 방법: 클라이언트 SDK 버전 5.4.0~5.4.2를 사용하는 경우 AWS CloudHSM JCE 공급자를 사용하여 KeyGenerator 클래스 또는 KeyAttribute 열거형을 사용하여 키를 생성하기 전에 키 크기를 비트에서 바이트로 변환하십시오.

• 해결 상태: 클라이언트 SDK 버전을 5.5.0 이상으로 업그레이드합니다. 여기에는 클래스 또는 열거형을 사용하여 키를 생성할 때 키 크기 (비트) 를 올바르게 예상하도록 수정된 사항이 포함됩니다. KeyGenerator KeyAttribute

문제: Client SDK 5에서 "불법적인 반사 액세스 작업이 발생했습니다"라는 경고가 표시됩니다.

Java 11과 함께 Client SDK 5를 사용하는 경우 CloudHSM은 다음 Java 경고를 표시합니다:

```
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore (file:/opt/cloudhsm/java/cloudhsm-jce-5.6.0.jar) to field java.security .KeyStore.keyStoreSpi
WARNING: Please consider reporting this to the maintainers of com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
```

이러한 경고는 영향을 주지 않습니다. 우리는 이 문제를 인지하고 있으며 해결하기 위해 노력하고 있습니다. 해결 방법이나 해결 방법이 필요하지 않습니다.

문제: JCE 세션 풀이 소진되었습니다.

영향: 다음 메시지가 표시된 후 JCE에서 작업을 수행하지 못할 수도 있습니다.

com.amazonaws.cloudhsm.jce.jni.exception.InternalException: There are too many operations 
happening at the same time: Reached max number of sessions in session pool: 1000

해결 방법:

• 영향을 받은 경우 JCE 애플리케이션을 다시 시작하십시오.

• 작업을 수행할 때 작업에 대한 참조를 잃기 전에 JCE 작업을 완료해야 할 수도 있습니다.

  참고

  작업에 따라 완료 메서드가 필요할 수 있습니다.

  Operation	완료 메서드(들)
  암호	암호화 또는 복호화 모드에서 doFinal() 랩 모드에서 wrap() 언랩 모드에서 unwrap()
  KeyAgreement	generateSecret() 또는 generateSecret(String)
  KeyPairGenerator	generateKeyPair(),genKeyPair() 또는 reset()
  KeyStore	메서드가 필요 없음
  Mac	doFinal() 또는 reset()
  MessageDigest	digest() 또는 reset()
  SecretKeyFactory	메서드가 필요 없음
  SecureRandom	메서드가 필요 없음
  Signature	서명 모드에서 sign() 검증 모드에서 verify()

해결 상태: Client SDK 5.9.0 이상에서 이 문제를 해결했습니다. 이 문제를 해결하려면 Client SDK를 다음 버전 중 하나로 업그레이드하십시오.

문제: GetKey 작업 시 클라이언트 SDK 5 메모리 누수

• 영향: 클라이언트 SDK 버전 5.10.0 및 이전 버전의 JCE에서 API getKey 작업의 메모리 누수가 발생했습니다. 애플리케이션에서 getKey API를 여러 번 사용하면 메모리 증가가 증가하여 결과적으로 애플리케이션의 메모리 사용량이 증가합니다. 시간이 지남에 따라 병목 오류가 발생하거나 애플리케이션을 다시 시작해야 할 수 있습니다.

• 해결 방법: 클라이언트 SDK 5.11.0으로 업그레이드하는 것이 좋습니다. 이렇게 할 수 없는 경우 애플리케이션에서 getKey API를 여러 번 호출하지 않는 것이 좋습니다. 그보다는 이전 getKey 작업에서 이전에 반환된 키를 가능한 한 많이 재사용하십시오.

• 해결 상태: 클라이언트 SDK 버전을 5.11.0 이상으로 업그레이드하십시오. 이 버전에는 이 문제에 대한 수정이 포함됩니다.