Autoridade de Registo

A Autoridade de Registo (RA) é o componente responsável por assegurar que a ligação entre os pares de chaves e as identidades é realizada segundo determinadas políticas. Normalmente este componente consiste numa aplicação que um operador humano manipula para verificar as identidades dos subscritores, no entanto algumas funções podem ser automatizadas. Nem sempre este componente se encontra distinguido, por vezes é incluído na Autoridade de Certificação.

5.2.1 Verificar a identidade do subscritor

Esta função pode ou não ser automática dependendo da política de implementação. Tendo em conta que o certificado serve para associar uma identidade a um par de chaves, a RA tem de efectuar os testes de identidade necessários para que esta associação seja credível tendo em conta os objectivos do uso do certificado.

Em termo práticos podem ser usadas muitas estratégias de verificação de identidade. Por exemplo a validação automática de endereços de e-mail, ou requerer informação exaustiva acerca do subscritor, como por exemplo (certidão de nascimento, passaporte, BI, etc....). Para aplicações em intranets, os testes de verificação de identidade podem ser semelhantes à emissão do cartão do funcionário da organização.

5.2.2 Aprovar ou modificar o conteúdo do certificado

O pedido de certificado é analisado, por um humano ou pelo software da RA. É verificado o conteúdo de cada campo. Alguns campos poderão ser modificados para respeitar determinadas políticas pré-definidas. A RA poderá aprovar ou reprovar os pedidos de certificados em função de critérios pré-estabelecidos.

Em algumas implementações, o subscritor pode pedir certos campos como por exemplo o nome comum. No entanto, a RA deve poder sobrepor esses pedidos para que seja cumprida uma determinada política local de funcionamento. Esta política estabelece quais os campos serão preenchidos pelo subscritor e quais os que serão preenchidos pela RA e ainda que campos serão definidos pela política de funcionamento.

Em Java já vimos anteriormente como podem ser manipulados os pedidos de certificados utilizando uma implementação do protocolo PKCS#10 (por exemplo a classe PKCS10CertificationRequest do JCSI em 5.1.3)

O campo attributes do PKCS#10

Este campo pode ser usado para adicionar ao pedido, informação acerca do certificado ou do subscritor. Os campos estão descritos no PKCS#6. O campo attributes está na notação ASN.1 logo é necessário implementar classes da Java que implementem esta notação para criar estes campos adicionais.

5.2.3 Gerar pares de chaves

Esta função é opcional, isto é, a RA pode opcionalmente gerar o par de chaves para o subscritor, o que implica ter implementado o mesmo tipo de aplicações descritas em 5.1.2.

Aparentemente a geração do par de chaves pela RA, é mais insegura do que a geração local, no entanto o software usado para gerar as chaves que existe no subscritor pode ser mais vulnerável a diversos tipos de ataques durante o processo de geração das chaves, tendo em conta que os PC são geralmente inseguros. As RAs podem empregar mecanismos muito seguros de hardware para gerar os pares de chaves. As chaves são depois enviadas de forma segura ao subscritor. Esta técnica tem no entanto a desvantagem de reduzir a credibilidade da assinatura digital. O subscritor pode afirmar que a RA autorizou a outra pessoa o acesso à sua chave privada. A adesão ou não adesão a este sistema é uma questão de política de implementação da RA.

5.2.4 Guardar pares de chaves

Esta função não é obrigatória e implica que a RA tenha gerado o par de chaves do subscritor ou conheça a sua chave secreta. Se estiver implementado um serviço de recuperação de chaves, a RA tem de manter armazenados os pares de chaves dos subscritores. A forma como as chaves são armazenadas tem de ser o mais segura possível para não comprometer todo o sistema.

O mais comum é manter um arquivo das chaves de cifragem em vez de chaves de assinatura, o que implica a existência de dois pares de chaves. No caso das chaves de cifragem, a perda da chave privada implica que a informação se torne ilegível para o subscritor. Neste caso a chave pode ser recuperada e a informação pode tornar-se novamente legível. No caso das chaves de assinatura, é vital que apenas o subscritor tenha controlo sobre a chave, porque o que está em causa é a sua credibilidade.

No desenvolvimento deste componente, caso seja usado o Java, têm de ser consideradas todas a precauções de segurança para que a base de dados onde estão guardados os pares de chaves dos subscritores, seja inviolável. O acesso à base de dados pode ser feito por JDBC. É conveniente que o SGBD seja o mais seguro possível.

5.2.5 Distribuição de tokens

No caso das chaves serem geradas pela RA, a chave privada poderá ser entregue ao subscritor num suporte físico (smartcard, disquete, etc...). Para que isto seja possível a chave privada terá de ser instalada num token. A norma que é utilizada para interface com funções de PKI existentes num smartcard é o PKCS#11.

5.2.6 Testes de posse de chave privada

Antes da RA aprovar um certificado que associe uma chave pública a uma identidade, é necessário saber se o subscritor possui a chave privada correspondente. Para isso a RA pode por exemplo enviar uma determinada informação aleatória ao subscritor e pedir que a assine com a sua chave privada e a envie de novo à RA. Se a RA confirmar a assinatura da mensagem, quer dizer que o subscritor é realmente detentor da chave privada.

RA pode-se obter a chave pública do subscritor invocando o método getPublicKey(). Para verificar se a assinatura é autentica pode fazer-se:

Obter chave pública

PublicKey chavePublica= pedidoDeCertificado.getPublicKey();

Iniciar objecto de assinatura

Inicia-se uma instância do objecto de assinatura para verificação com o algoritmo pré-definido para o certificado do subscritor.

Signature assinatura = Signature.getInstance(algoritmo);

assinatura.initVerify(chavePublica);

Assinar a mensagem

Obtém-se a mensagem sob a forma de array de bytes e passa-se a mensagem ao objecto de assinatura.

byte[] mensagem = "Mensagem".getBytes();

assinatura.update(mensagem);

Verificar a assinatura

Compara-se a assinatura obtida com a assinatura que a mensagem transporta.

if (assinatura.verify(assinatura_da_mensagem)) {

// assinatura válida }

else {

// assinatura inválida }

5.2.7 Atribuição de DN e modificação do conteúdo do certificado

A RA deve poder editar o Distinghished Name (DN) dos certificados e outro tipo de conteúdos para corresponder a determinadas políticas. Se existir uma verificação automática de verificações de pedidos, é comum por exemplo que haja um formato normalizado para o DN, ou numeração sequencial para os certificados.