Artigos Java Autenticação de Usuários com Certificados Digitais

Atualmente todos estão preocupados com a segurança e autenticidade de documentos e relacionamentos eletrônicos, uma vez que muitos usuários utilizam a internet para enviar documentos, consultar processos e realizar transações.

No Brasil foi lançado o programa ICP-Brasil (Infra-estrutura de Chaves Publicas) juntamente com seus agregados de identificação, o e-CPF e o e-CNPJ, que respectivamente identificam uma pessoa física e uma jurídica.

A aceitação deste método de autenticação e segurança ainda é baixa, em primeiro lugar porque o custo é relativamente alto iniciando com o modelo A1 em R$ 100,00 e chegando ao kit do modelo A3 em R$ 700,00. Outro problema é que os usuários em geral ainda não se deram conta do risco que existe no uso da internet sem o certificado nas duas pontas e as empresas ainda podem se esquivar de responsabilidades por utilizar múltiplos métodos de segurança.

Em primeiro lugar abordemos a questão do custo e tipo dos certificados. O certificado do modelo A1 é um arquivo de pouco mais de 1 Kb (isto mesmo, em geral não ultrapassa 2 Kb), e nada mais é do que uma mídia com o arquivo que contem as duas chaves, a pública e a privada. Já o modelo A3 é o conhecido “smartcard”, que agora bancos como Itaú e Bradesco passaram a distribuir a seus clientes. A utilização dos cartões A3 tem seu custo mais elevado em razão do leitor que é necessário adquirir. Algumas empresas vendem o kit A3, como a Itautec, contendo o cartão, a mídia com o arquivo, o leitor de smartcard que é conectado na USB e uma visita técnica para instalação. Como o A1 é apenas distribuído com uma mídia simples, pode-se encontrá-lo ao preço de R$ 100,00 no site do SERASA, CertSign e outros. O A3 também pode ser comprado nos mesmos lugares ao preço médio de R$ 300,00. Mas neste caso a leitora não está incluída. Como em qualquer negociação é possível procurar a “concorrência”, já que os certificados são vendidos por diversas empresas alem destas citadas.

O segundo problema da baixa utilização é que nós, usuários, ainda não nos demos conta do real perigo oferecido pela certificação como é utilizada atualmente. Para entendermos este risco veja a Figura 1. Podemos notar que o modelo tradicional apenas o servidor da empresa possui a chave de autenticação, portanto ela é quem diz ser. Mas quem garante que “você” realmente é quem diz ser? A única garantia que um banco ou uma empresa tem é pela utilização de sua agencia e conta no caso dos bancos ou o seu email em outros casos. Viu-se com o tempo que este método é facilmente burlado, alguém utiliza um trojan e descobria o que você digitou. Então começaram nos bancos os irritantes métodos físicos, cartão com códigos, letras que mudam de posição, teclado que se movimenta na tela, número de confirmação grafado no cartão e outros que muitas vezes nos fazem desistir da transação.

Utilizações padrão de certificados
Figura 1. Utilizações padrão de certificados

Já considerado o risco de utilizarmos os métodos convencionais de autenticação e a vantagem do modelo PKI (o termo original que foi traduzido para ICP), como ele funciona? A Figura 2 demonstra como ele funciona e suas vantagens em uma aplicação corporativa. Claro que aqui estamos apenas alistando um exemplo de aplicação, sendo que os certificados são emitidos pela própria empresa e não utilizando o modelo e-CPF/e-CNPJ.

Modelo básico com acesso utilizando certificados
Figura 2. Modelo básico com acesso utilizando certificados

Detalhando melhor os principais componentes PKI, podemos destacar quatro componentes principais:

  • CA (Autorizada de Certificação) que emite os certificados. As certificadoras são bem conhecidas empresas que mantém um banco de dados com os certificados emitidos, bem como o CRL atualizado. Nem sempre se utiliza a CA para emissão de certificados e sim um subordinado.
  • Subordinate CA (Autoridade de Certificação Subordinada) que também emite os certificados, mas utilizando uma “corrente” ligada a CA raiz. Este modelo é utilizado pela maior parte das certificadoras conhecidas, como a VeriSign, CertSign e outras. No Brasil, como exemplo, o SERASA emite certificados SSL que são subordinados a GlobalSign. O motivo é muito simples, as “certificadoras confiáveis” já estão pré-configuradas nos sistemas operacionais, como pode ser visto na Figura 3. Esta lista é uma parte na encontrada no Internet Explorer ao entrar em “Opções-Conteudo-Certificados” e o SERASA não consta na lista, obviamente porque é uma empresa que não é conhecida fora do Brasil para ser incluída. Algumas semanas atrás foi noticiado que o IE7 trará embutido na sua lista de certificadoras confiáveis o ICP, o que permitirá que as empresas brasileiras deixem de ser subordinadas a uma CA internacional.
  • CRL (Certificate Revogation List) é um servidor mantido pela CA ou subordinada e que mantém uma lista dos certificados que foram revogados ou cancelados. Esta lista nos protege contra o mau uso ou desvio do certificado para outros fins. A Verisign à alguns anos atrás teve que noticiar que havia emitido dois certificados para a Microsoft quando na verdade os solicitantes utilizaram documentos falsos. A solução neste caso é revogar os certificados e publicá-lo na CRL.
  • Certificado Digital, arquivo que contem as chaves pública e privada. A chave privada só é conhecida do proprietário e da CA que a emitiu. A chave pública é conhecida por todos os que se comunicam com o proprietário da chave. O modelo de criptografia utilizado é assimétrico, o proprietário utiliza a chave privada para criptografar suas mensagens e a chave pública contém o algoritmo para descriptografar. O inverso na comunicação ocorre quando o destinatário envia para o proprietário utilizando a chave pública para criptografar, garantindo que apenas o proprietário conseguirá descriptografar, uma vez que ele é o único que tem a chave inversa, neste caso a privada. O certificado contem um importante dado dentro dele chamado de “subject”, onde consta os dados de quem é o proprietário da chave e outros dados que a certificadora queira incluir como mostra a Figura 4.
Internet Explorer
Figura 3. Internet Explorer
Subject do certificado
Figura 4. Subject do certificado

Agora que já temos um bom panorama do porque os certificados são importantes e como sua infra-estrutura foi planejada vamos configurar o IIS para utilizar os certificados. Utilizaremos uma certificadora baseada no Windows 2003 para a emissão, já que para podermos fazer o processo de autenticação por certificados precisamos que o servidor IIS esteja com SSL habilitado. O meu servidor já está certificado e abordaremos como este processo foi feito em um artigo próximo. Utilizarei neste exemplo um certificado próprio emitido pelo Windows 2003, mas o processo é o mesmo para o e-CPF/e-CNPF, apenas ao invés de utilizar um servidor próprio utilizaria um do ICP Brasil.

Veja na Figura 5 que para utilizar a opção “Require client certificate” é necessário também ter o servidor certificado. Caso não possua o seu servidor com SSL poderá utilizar a opção “Accept client certificate” que não exige, apenas permite o uso de certificados pelo cliente, não garantindo assim um bom método de autenticação.

aucertdigfig04.JPG
Figura 5. Habilitando o uso de certificados no IIS

A Figura 6 demonstra o que acontece ao tentar acessar um servidor certificado e com obrigatoriedade de certificado pelo cliente. O erro “403.7” obviamente pode ser redirecionado para uma página de erro customizada que informe ao usuário que ele precisa comprar um certificado e a lista de onde isto pode ser feito, por exemplo. Não tente fazer este processo por try-catch, pois a exigência do certificado é tratada no IIS e não na página.

Acesso proibido por falta de um certificado
Figura 6. Acesso proibido por falta de um certificado

Após instalar o certificado para o meu usuário a Figura 7 mostra uma lista dos certificados que eu possuo na maquina e permite que eu escolha qual utilizar. Esta lista só aparece caso o usuário solicite ou se existirem múltiplos certificados.

Certificado sendo solicitado ao usuário
Figura 7. Certificado sendo solicitado ao usuário

O próximo passo é ler os dados do certificado para validar o usuário, e isto aconteceu na Figura 8, onde está listado o conteúdo do “subject”, com os dados utilizados quando comprei o certificado. Para extrair estes dados foi utilizado o código da Listagem 1, que é extremamente simples.

Acesso permitido e os dados do certificado exibidos
Figura 8. Acesso permitido e os dados do certificado exibidos

<HTML>
  <BODY>
   <H1>Bem-vindo </H1>
   <%=Request.ClientCertificate.Subject%><
 </BODY>
</HTML>
Listagem 1. Código para extrair o subject com os dados do proprietário

Neste artigo abordamos o que são os certificados digitais, como funcionam, a estrutura que existe para funcionamento e sua utilização no servidor web. Vale a pena lembrar novamente que o e-CPF/e-CNPJ são certificados e que o ICP-Brasil nada mais é do que uma certificadora, portanto todos os exemplos aqui são válidos.