Implementação

A CSP Dinamo é referenciada pelo JCA\JCE através do identificador ND.

As classes da CSP não são clonáveis.

O arquivo de keystore guarda as relações das chaves armazenadas no HSM com a CSP. Essa relação é feita das seguintes formas:

1. Na criação de uma chave a partir da APIs JCA/JCE. Nesta forma a chave é criada no HSM mas é removida ao final do programa ou quando o objeto da chave é removido pelo garbage collector do Java. Para esta chave ser mantida no HSM é necessário incluí-la no keystore, desta maneira é garantido que ela não será removida ao término do programa.

2. No momento do carregamento de um keystore a lista de chaves é carregada diretamente do HSM. Não há uma representação em arquivo físico do keystore, portanto na chamada ao método load() passa-se null nos parâmetros de arquivo e senha. As chaves serão reconhecidas de acordo com o descrito nos itens 3 e 4. As senhas das chaves são uma string vazia.

   Info

   O nome da chave no HSM é uma sequência de 16 caracteres aleatórios mais 3 caracteres JCA que são colocados no final do nome da chave, totalizando 19 caracteres.

   Atenção

   Caso o programa termine com uma falha não esperada a chave pode não ser removida do HSM.

Nomenclatura

A seguinte nomenclatura de chaves deve ser seguida para a correta interpretação da chave privada, com seu respectivo certificado (.cer) e cadeia de certificados da CA (p7b).

Objeto	Regra de formação do nome
Chave privada	<id_chave>
Certificado	<id_chave>_cert
Cadeia de certificados	<id_chave>_chain

Info

A cadeia de certificados quando carregada no KeyStore é ordenada de acordo com o definido a RFC-5246.

Após o carregamento das chaves no keystore, o certificado e a cadeia de certificados poderão ser acessados através dos respectivos métodos de recuperação disponíveis sob o alias da chave privada.

keystoreinstance.GetCertificate(id_chave)
keystoreinstance.GetCertificateChain(id_chave)

Cadeias

São aceitas cadeias de certificados com ou sem o head certificate (certificado relacionado à própria chave).

Além da forma descrita no item acima é permitido o relacionamento de chave/cadeia utilizando MAPs (objetos do HSM que permitem relacionar outros dois objetos). Utilizando MAPs se permite o relacionamento entre uma chave privada e uma cadeia de certificados com nomes que não sigam a nomenclatura descrita no item (3) e que o nome do Alias no KeyStore seja definido de uma maneira mais flexível.

Este relacionamento se dá da seguinte forma:

1. O nome do objeto MAP dentro do HSM será o nome do Alias no KeyStore;
2. O nome do objeto do primeiro Slot do MAP será o nome da chave privada dentro do HSM;
3. O nome do objeto do segundo Slot do MAP será o nome da cadeia de certificados dentro do HSM;

São aceitas cadeias de certificados com ou sem o head certificate (certificado relacionado a própria chave).

Keystores

Há três tipos de keystore disponíveis na JCA/JCE Dinamo, descritos a seguir.

TAC

Tem todas as permissões sobre as chaves no HSM, incluindo remoção e adição de chaves no HSM.

keystoreintance.getInstance("TAC", "ND")

TACV

TAC Virtual, semelhante ao tipo TAC mas a remoção de chaves é apenas virtual, ou seja, as chaves são excluídas apenas do keystore e não do HSM.

keystoreintance.getInstance("TACV", "ND")`

TACCON

Tem o mesmo comportamento que o tipo TAC com a diferença que o id de usuário, a senha e o endereço IP do HSM devem ser informados nos seguintes formatos usuário:senha@IP ou accessToken@IP.

Quando for utilizar usuário e senha, os campos de id de usuário e senha são obrigatórios.

Quando for utilizar Access Tokens o campo accessToken é obrigatório. O Access Token é a estrutura DN_A_TOKEN no formato Base64; por exemplo: o AToken retornado pelo HSMCON ou pelo método TacAccessToken.getAToken() e transformado em Base64.

O endereço IP do HSM pode ser omitido apenas quando o balanceamento de carga está ativo.

Atenção

Quando se utilizar usuário e senha os dois separadores : e @ devem ser usados sempre, mesmo que o endereço IP do HSM não seja informado. No caso de Access Tokens o @ deverá ser sempre utilizado.

Ex:

keystoreintance.getInstance("TACCON", "ND")
keyStore.load(null, ("usr:12345678@10.0.62.10").toCharArray())
keyStore.load(null, ("usr:12345678@").toCharArray())
keyStore.load(null, ("bHVhbgAAAAAAAAAAAAAAAGIwx1mtzLLQ9OkapMIzRrTNxAssvFeUvDh1mO7I4x5xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=?@10.0.62.10").toCharArray())

ECCDHwithSHA256KDF

Para utilizar o KeyAgreement ECCDHwithSHA256KDF com a JCA DINAMO deve-se utilizar para geração de SecretKey o parameter spec DNECDHX963ParameterSpec.

Construtor 1

Para inicializar DNECDHX963ParameterSpec os seguintes parâmetros poderão ser utilizados.

Gera uma chave persistente e exportável.

• kdfData KDF utilizado para a geração da chave.
• keyLen Tamanho da chave, em bits, que será gerada em KeyAgreement.generateSecret(). O tamanho de chave deverá ser compatível com o algoritmo passado em KeyAgreement.generateSecret().

    public DNECDHX963ParameterSpec(byte[] kdfData, int keyLen );

Construtor 2

Inicializa os parâmetros de algoritmo ECDH X9.63, para ser utilizado na classe KeyAgreement.

• kdfData KDF utilizado para a geração da chave.
• keyLen Tamanho da chave, em bits, que será gerada em KeyAgreement.generateSecret(). O tamanho de chave deverá ser compatível com o algoritmo passado em KeyAgreement.generateSecret().
• exportable Informa se a chave gerada será exportável ou não. Informar true para exportável e false para não exportável.
• temporary Informa se a chave gerada será temporária ou não. Informar true para temporária e false para persistente.

java public DNECDHX963ParameterSpec(byte[] kdfData, int keyLen, boolean exportable, boolean temporary);