Problemas conhecidos do JCE SDK para AWS CloudHSM

• Impacto: esse problema pode fazer HSMs com que você fique sem espaço de chave inesperadamente e ocorre quando seu aplicativo usa um objeto de chave JCE padrão para operações de criptografia em vez de um objeto. CaviumKey Quando você usa um objeto de chave JCE padrão, o CaviumProvider importa implicitamente essa chave para o HSM como uma chave de sessão e não exclui essa chave até que o aplicativo seja encerrado. Como resultado, as chaves se acumulam enquanto o aplicativo está em execução e podem fazer HSMs com que você fique sem espaço livre na chave, congelando o aplicativo.

• Solução alternativa: ao usar a classe CaviumSignature, a classe CaviumCipher, a classe CaviumMac ou a classe CaviumKeyAgreement, você deverá fornecer a chave um CaviumKey em vez de um objeto de chave JCE padrão.

  É possível converter manualmente uma chave normal em um CaviumKey usando a classe ImportKey e depois excluir manualmente a chave após a conclusão da operação.

• Status da resolução: estamos atualizando o CaviumProvider para gerenciar corretamente as importações implícitas. A correção será anunciada na página de histórico de versões quando estiver disponível.

• Impacto: não é possível armazenar um tipo de objeto que não seja compatível com o HSM no repositório de chaves do JCE. Sobretudo, você não pode armazenar certificados no repositório de chaves. Isso impede a interoperabilidade com ferramentas como jarsigner, que espera encontrar o certificado no repositório de chaves.

• Solução alternativa: você pode reprocessar seu código para carregar certificados de arquivos locais ou de um local do bucket do S3 em vez de carregá-los do repositório de chaves.

• Status da resolução: estamos adicionando suporte ao armazenamento de certificados no repositório de chaves. Esse recurso será anunciado na página de histórico de versões, quando estiver disponível.

Além disso, não há suporte para a criptografia AES-GCM em várias partes.

• Impacto: não é possível usar o AES-GCM para criptografar dados maiores que 16.000 bytes.

• Solução alternativa: use um mecanismo alternativo como o AES-CBC ou divida os dados em partes e criptografe cada parte individualmente. Se você dividir os dados, gerencie o texto cifrado dividido e sua descriptografia. Como o FIPS exige que o vetor de inicialização (IV) do AES-GCM seja gerado no HSM, o IV para cada AES-GCM-encrypted dado será diferente.

• Status da resolução: vamos corrigir o SDK para falhar explicitamente se o buffer de dados for muito grande. Estamos avaliando alternativas para oferecer suporte a buffers maiores sem depender da criptografia em várias partes. As atualizações serão anunciadas no fórum do AWS CloudHSM e na página de histórico de versões.

• Impacto: o Client SDK 3 adiciona a funcionalidade ECDH ao JCE. Quando você usa a KeyAgreement classe para derivar uma SecretKey, ela fica disponível primeiro no cliente e depois é importada para o HSM. Um identificador de chave é retornado ao aplicativo.

• Solução alternativa: se você estiver implementando o SSL/TLS Offload in AWS CloudHSM, essa limitação pode não ser um problema. Se o aplicativo precisar da sua chave para permanecer continuamente em um limite FIPS, é recomendável o uso de um protocolo alternativo que não dependa da derivação de chaves ECDH.

• Status da resolução: estamos desenvolvendo a opção para executar inteiramente a derivação de chaves ECDH no HSM. Quando disponível, anunciaremos a implementação atualizada na página de histórico de versões.

• Impacto: as versões 5.4.0 a 5.4.2 do SDK do cliente esperam incorretamente que o tamanho da chave seja fornecido ao especificado em bytes. APIs

• Solução alternativa: converta o tamanho da chave de bits em bytes antes de usar a KeyGenerator classe ou KeyAttribute enum para gerar chaves usando o provedor AWS CloudHSM JCE se estiver usando as versões 5.4.0 a 5.4.2 do SDK do Cliente.

• Status da resolução: atualize a versão do SDK do cliente para 5.5.0 ou posterior, o que inclui uma correção para esperar corretamente os tamanhos das chaves em bits ao usar a KeyGenerator classe ou o KeyAttribute enum para gerar chaves.

• Reinicie seu aplicativo JCE se você estiver enfrentando um impacto.

• Ao realizar uma operação, talvez seja necessário concluir a operação JCE antes de perder a referência à operação.

  nota

  Dependendo da operação, pode ser necessário um método de preenchimento.

  Operação	Método(s) de preenchimento
  Cifra	doFinal() no modo criptografar ou descriptografar wrap() no modo encapsular unwrap() no modo desencapsular
  KeyAgreement	generateSecret() ou generateSecret(String)
  KeyPairGenerator	generateKeyPair(), genKeyPair() ou reset()
  KeyStore	Nenhum método é necessário
  Mac	doFinal() ou reset()
  MessageDigest	digest() ou reset()
  SecretKeyFactory	Nenhum método é necessário
  SecureRandom	Nenhum método é necessário
  Assinatura	sign() no modo de sinal verify() no modo de verificação

• Impacto: a operação da API getKey tem um vazamento de memória no JCE nas versões 5.10.0 e anteriores do Client SDK. Se você estiver usando a API getKey várias vezes em sua aplicação, isso aumentará o crescimento da memória e, consequentemente, aumentará o espaço ocupado pela memória em sua aplicação. Com o tempo, isso pode causar erros de controle de utilização ou exigir que a aplicação seja reiniciada.

• Solução alternativa: recomendamos a atualização para o Client SDK 5.11.0. Se isso não puder ser feito, recomendamos não chamar a API getKey várias vezes em sua aplicação. Em vez disso, reutilize a chave retornada anteriormente da operação getKey anterior, tanto quanto possível.

• Status da resolução: atualize a versão do Client SDK para 5.11.0 ou posterior, o que inclui uma correção para esse problema.