Autoridade de Certificação

A Autoridade de Certificação (CA) é o componente da PKI responsável pela gestão dos certificados. Inicialmente a CA cria os certificados e adiciona-lhes a “assinatura CA” que garante a integridade do certificado. Não pode ser modificado sem invalidar a assinatura, por isso, qualquer certificado com uma “assinatura CA” válida é garantido ter os mesmos conteúdos desde a sua geração. A CA é também responsável por revogar (anular) os certificados que por qualquer motivo deixam de ser válidos.

As políticas de funcionamento da CA pode necessitar de administração humana para aprovar a criação, a revogação de certificados. O funcionamento da CA pode também ser automatizado. A função que normalmente é executada por um operador humano é a de verificação da identidade do subscritor. Como já foi visto anteriormente, esta função pode ser, caso exista, incorporada numa RA, e a CA só deve emitir os certificados se forem anteriormente aprovados pela RA sem a necessidade intervenção humana.

5.3.1 Responder a pedidos de renovação de certificados

A CA pode, de acordo com uma determinada política, aprovar pedidos dos subscritores para renovação de certificados (5.1.4 e 5.1.11), quer relativamente ao prazo de validade das chaves, quer a renovação das chaves.

Partindo do principio que a identidade do subscritor foi provada quando o certificado original foi emitido, estas funções não exigem o envolvimento da RA. De qualquer forma, se houver políticas que o exijam, pode ser revalidada a identidade do subscritor..

A implementação desta função em Java deve receber o pedido de renovação, desempacotar o pedido e estabelecer o novo período de validade e reenviar o certificado ao subscritor, isto se o pedido for de prolongamento da validade do certificado. Caso o pedido seja de renovação das chaves terá de ser exigida uma prova de posse da chave privada para garantir que a chave pública corresponde à chave privada do subscritor.

5.3.2 Modificar ou aprovar modificações do conteúdo do certificado

De forma similar RA, também a CA pode implementar a funcionalidade de responder a pedidos de modificação do conteúdo ou modificar ela mesma o conteúdo de um certificado. Esta função pode ser desempenhada por um operador humano. As modificações podem incluir extensões de certificados, por exemplo, extensões Netscape ou Microsoft.

A implementação em Java desta funcionalidade deve seguir os seguintes passos: Caso seja um pedido de um subscritor, esse pedido deve ser desempacotado, a CA deve depois aceitar ou reprovar o pedido, caso o pedido seja aprovado o certificado deve ser alterado e reenviado ao subscritor.

Caso seja uma alteração do conteúdo pela CA, o certificado deve ser alterado e reenviado ao subscritor.

5.3.3 Iniciar e aprovar revogação

A CA terá de aprovar pedidos de revogação de certificados provenientes da RA ou do subscritor. A CA também poderá iniciar o processo de revogação de certificados de acordo com uma determinada política (por exemplo: prazo de validade das chaves). No caso de serem envidados pedidos de revogação pela RA e pelo subscritor é porque as chaves foram perdidas ou de alguma forma encontram-se comprometidas no que diz respeito a segurança.

5.3.4 Criar certificado raiz auto assinado

A CA deve poder criar e assinar certificados CA para ela própria e para as CAs subordinadas.

Opcionalmente, o certificado CA poderá ser gerado por uma outra entidade que mantenha uma relação de confiança.

O certificado de nível de topo ou certificado raiz é sempre auto assinado. O simples facto do certificado conter uma chave pública não se lhe deve atribuir confiança, porque qualquer um pode criar um certificado auto assinado com o distinguished name de uma CA bem conhecida. A confiança deve advir do facto de a chave pública desse certificado ser uma chave pública bem conhecida para essa CA que pode ser verificada a partir de outras fontes como por exemplo anúncios. A única razão pela chave pública ser guardada no certificado raiz é porque é exigido o seu preenchimento no formato de certificados na maior parte das ferramentas. Neste caso, o certificado é usado para que transporte a chave pública da CA para que possa ser verificada através de outras fontes.

Gerar um certificado a partir de um par de chaves

O comando genkey do utilitário keytool pode ser usado para criar um par de chaves e para empacotar a chave pública num certificado auto assinado. Neste caso, é necessário atribuir uma palavra chave para o armazém de chaves que irá conter a chave secreta e essa palavra chave.

Também será necessário providenciar informação relativa à entidade que irá possuir o certificado.

Também é possível criar um novo certificado usando um par de chaves associado a um certificado gerado anteriormente.

Gerar um certificado CA auto assinado com o JCSI

Para gerar um certificado CA auto assinado pode usar-se o seguinte construtor da classe X509CertGen :

X509CertGen(String issName, Signature sig)

5.3.5 Emissão de certificados

A CA tem de poder emitir e assinar certificados. A assinatura garante aos receptores que o certificado foi emitido de acordo com a política de publicação da CA. A chave privada para efectuar

disponibiliza classes para manipulação e geração de certificados. Outra alternativa é programar as classes para geração e manipulação de certificados a partir das normas X500 e X509.

Os certificados X509 são constituidos pela seguinte informação:

Versão

Número de Série

Identificador de algoritmo para assinatura

X500 (nome da entidade geradora, conhecido como distinguished name) Período de validade

Nome da entidade identificada com a chave pública (subject name)

Informação relativa à chave publica dessa entidade (chave pública, algoritmo, parâmetros)

Os X500 Distinguished Names são constituídos por : Nome comum

Nome do departamento Nome da organização Nome da localidade

Nome do estado ou província Código do país

Vejamos como poderia ser criado um certificado para um determinado subscritor:

X509CertGen cg = new X509CertGen(caSignature, caCert);

cg.setPublicKey(userPublicKey);

cg.setSerialNumber(BigInteger.valueOf((long)12345678 ));

cg.setSubjectDN("CN = John Smith, OU=Security, O=DSTC, C=AU");

cg.setValidity(365);

cg.setSubjectEmail("[email protected]");

X509Certificate userCert = cg.getCertificate();

5.3.6 Disponibilizar os certificados aos subscritores

A CA deve ter a capacidade de entregar os certificados aos subscritores. Isto pode não ser obrigatório, isto é, caso exista um Repositório de Certificados, a solução de PKI pode requerer ao

O formato usado para a entrega de certificados é o PKCS#7. O JDK não disponibiliza ferramentas para criar ou manipular este formato. Existem duas alternativas, ou se desenvolvem classes para implementar este protocolo, ou utiliza-se um framework que o implemente. Por exemplo o IAIK, implementa uma classe chamada PKCS7CertList que manipula correntes de certificados compatíveis com o Netscape Navigator e Microsoft Explorer. Esta classe disponibiliza vários métodos e construtores para criar um objecto assinado que contém uma lista de certificados. Essa lista pode ser escrita ou lida de um ficheiro (com a extenção .p7c). Vejamos um exemplo para escrever a lista:

X509Certificate[] certs = ...;

PKCS7CertList pkcs7 = new PKCS7CertList();

pkcs7.setCertificateList(certs);

pkcs7.writeTo(new FileOutputStream(pkcs7File));

Para ler a lista:

PKCS7CertList pkcs7 = new PKCS7CertList(new FileInputStream("certs.p7c"));

X509Certificate[] certs = pkcs7.getCertificateList();

5.3.7 Publicação dos certificados

A CA deve possuir a capacidade de enviar os certificados ao Repositório de Certificados, onde serão disponibilizados a quem necessitar um cópia.

Relativamente à implementação desta funcionalidade em Java, o que pode ser feito é, por exemplo, uma aplicação cliente servidor, em que o cliente (implementado na CA) envie o certificado, depois da sua emissão, ao servidor (Repositório de certificados) para que seja publicado.

5.3.8 Revogar certificados (Adicionar à CRL)

A CA deve poder revogar certificados. Para isso será necessário adicionar o certificado à Lista de Certificados Revogados (CRL) e tornar o estado do certificado para certificado revogado no repositório.

No JDK não existem classes para criar, ou manipular CRLs. As classe que existem apenas permitem obter informação (ler) o conteúdo das CRLs. Mais uma vez, existem duas alternativas, ou criamos classes que permitam manipular CRLs a partir da notação ASN.1, ou então usamos um framework que já as implemente. Por exemplo no JCSI, existe uma classe chamada X509CRLGen que permite criar uma CRL. Vejamos como é que isso pode ser feito:

X509CRLGen crlGen = new X509CRLGen(caSignature, caCert);

cg.setThisUpdate(new Date());

Calendar c = Calendar.getInstance();

c.set(2002,5,21);

cg.setNextUpdate(c.getTime());

cg.setCRLNumber(BigInteger.valueOf((long)635));

Agora vejamos como podem ser adicionados certificados à lista. Para isso basta invocar o método addRevokedCert com o número de série do certificado revogado:

Para obtermos um objecto com a lista basta fazer:

X509CRL crl = crlGen.getCRL();

5.3.9 Publicar CRL

A CA deve enviar a CRL para o Repositório de certificados para que seja disponibilizada a quem necessitar uma cópia. A CA assina a CRL para que os receptores saibam que se trata de uma CRL válida. Dependendo de uma determinada política, as CRLs podem ser enviadas periodicamente ou quando acontece uma revogação.

Se optar-mos pelo envio das CRLs cada vez que um certificado seja revogado o procedimento poderá ser semelhante à publicação de certificados, isto é, basta construir uma aplicação do tipo cliente servidor, em que o servidor corre no Repositório de certificados e o cliente na CA. Depois de um certificado ser revogado, a CRL é enviada ao servidor para que seja publicada.

5.3.10 Pedido de Certificação Cruzada

A CA deve poder enviar pedidos a outras CAs pedindo os seus certificados, para que por exemplo, pedidos assinados pela CA possam ser aceites por outra CA remota. Ainda não existem normas para este tipo de funcionalidades. As implementações limitam-se a fazer certificação cruzada dentro de uma solução PKI..

Como ainda não existem normas também não existem implementações desta funcionalidade em frameworks de Java.

5.3.11 Aceitar Certificação Cruzada

A CA deve poder responder a pedidos de certificação cruzada, isto é, deve responder a pedidos de certificação de outras CAs indicando que irão aceitar os seus certificados.

Da mesma forma que os pedidos de certificação cruzada não existem ainda normas para esta funcionalidade, consequentemente a forma de implementação é distinta para cada solução.