Problemas conhecidos do SDK do JCE em relação ao AWS CloudHSM

• Impacto: esse problema pode fazer com que o espaço de chaves dos HSMs se esgote inesperadamente e ocorra quando o 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 aumentam enquanto o aplicativo está em execução e podem fazer com que o espaço livre de chaves dos HSMs se esgote, congelando seu 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: você pode usar o keystore do AWS CloudHSM para armazenar certificados.

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 requer que o vetor de inicialização (IV) para AES-GCM seja gerado no HSM, o IV de cada parte dos dados criptografados por AES-GCM 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 classe KeyAgreement para derivar uma SecretKey, ela fica disponível primeiro no cliente e, em seguida, é importada para o HSM. Um identificador de chave é retornado à aplicação.

• Solução alternativa: se você estiver implementando o descarregamento SSL/TLS no AWS CloudHSM, essa limitação pode não ser um problema. Se a aplicação 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: o SDK 5.16 agora suporta ECDH com derivação de chave, que é executada inteiramente dentro do HSM.

• Impacto: as versões Client SDK 5.4.0 a 5.4.2 esperam incorretamente que o tamanho da chave seja fornecido às APIs especificadas como bytes.

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

• Status da resolução: atualize a versão do Client SDK para 5.5.0 ou posterior, o que inclui uma correção para esperar corretamente os tamanhos das chaves em bits ao usar a classe KeyGenerator ou a enumeração KeyAttribute 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.