As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Problemas conhecidos do JCE SDK para AWS CloudHSM
Os problemas a seguir afetam o SDK do JCE para. AWS CloudHSM
**Topics**
+ [Problema: ao trabalhar com pares de chaves assimétricas, você vê a capacidade de chaves ocupada mesmo quando não está explicitamente criando ou importando chaves](#ki-jce-1)
+ [Problema: O JCE KeyStore é somente para leitura](#ki-jce-3)
+ [Problema: os buffers para criptografia AES-GCM não podem exceder 16.000 bytes.](#ki-jce-4)
+ [Problema: a derivação da chave Diffie-Hellman de curva elíptica (ECDH) é executada parcialmente dentro do HSM.](#ki-jce-5)
+ [Problema: KeyGenerator e interpreta KeyAttribute incorretamente o parâmetro de tamanho da chave como número de bytes em vez de bits](#ki-jce-6)
+ [Problema: o Client SDK 5 emite o aviso “Ocorreu uma operação ilegal de acesso reflexivo”](#ki-jce-7)
+ [Problema: o pool de sessões do JCE está esgotado](#ki-jce-8)
+ [Problema: vazamento de memória do Client SDK 5 com operações getKey](#ki-jce-9)
## Problema: ao trabalhar com pares de chaves assimétricas, você vê a capacidade de chaves ocupada mesmo quando não está explicitamente criando ou importando chaves
+ **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 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 [https://github.com/aws-samples/aws-cloudhsm-jce-examples/blob/master/src/main/java/com/amazonaws/cloudhsm/examples/KeyUtilitiesRunner.java](https://github.com/aws-samples/aws-cloudhsm-jce-examples/blob/master/src/main/java/com/amazonaws/cloudhsm/examples/KeyUtilitiesRunner.java) 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.
## Problema: O JCE KeyStore é somente para leitura
+ **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 AWS CloudHSM keystore para armazenar certificados.
## Problema: os buffers para criptografia AES-GCM não podem exceder 16.000 bytes.
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.
## Problema: a derivação da chave Diffie-Hellman de curva elíptica (ECDH) é executada parcialmente dentro do HSM.
Sua chave privada EC permanece no HSM em todos os momentos, mas o processo de derivação de chaves é realizado em várias etapas. Consequentemente, os resultados intermediários de cada etapa estão disponíveis no cliente. Um exemplo de derivação de chave ECDH está disponível nos [exemplos de código Java](java-samples_3.md).
+ **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 à aplicação.
+ **Solução alternativa:** se você estiver implementando o SSL/TLS Offload in 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: **agora o SDK 5.16 é compatível com ECDH com derivação de chave, que é executada inteiramente dentro do HSM.
## Problema: KeyGenerator e interpreta KeyAttribute incorretamente o parâmetro de tamanho da chave como número de bytes em vez de bits
Ao gerar uma chave usando a `init` função da [KeyGenerator classe](https://docs.oracle.com/javase/8/docs/api/javax/crypto/KeyGenerator.html#init-int-) ou o `SIZE` atributo do [AWS CloudHSM KeyAttribute enum](java-lib-attributes_5.md), a API espera incorretamente que o argumento seja o número de bytes da chave, quando deveria ser o número de bits da chave.
+ **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.
## Problema: o Client SDK 5 emite o aviso “Ocorreu uma operação ilegal de acesso reflexivo”
Ao usar o Client SDK 5 com Java 11, o CloudHSM emite o seguinte aviso de 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
```
Esse problema foi corrigido no Client SDK versão 5.8 e posterior.
## Problema: o pool de sessões do JCE está esgotado
**Impacto:** talvez você não consiga realizar operações no JCE depois de ver a seguinte mensagem:
```
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
```
**Soluções alternativas: **
+ 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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/cloudhsm/latest/userguide/ki-jce-sdk.html)
**Status da resolução:** resolvemos esse problema no Client SDK 5.9.0 e versões posteriores. Para corrigir esse problema, atualize seu Client SDK para uma dessas versões.
## Problema: vazamento de memória do Client SDK 5 com operações getKey
+ **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.