Utilizando Certificados Digitais

O problema e a “solução”

por Marcelo Sincic

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 financeiras, fiscais e, recentemente, legais. Cada vez mais notamos que pedir o nome do usuário e uma senha não é a forma ideal de garantirmos a autenticidade, e intuições como bancos utilizam quatro ou cinco métodos de validações adicionais alem do clássico “user-pass”.

Neste ponto é que surgem as chaves criptográficas, armazenadas em certificados digitais, que garantem a identidade de uma empresa, pessoa física ou um site na internet. Para termos uma idéia da importância e necessidade desta tecnologia, desde o ano passado algumas transações no site da Receita Federal só podem ser feitas por quem tem um certificado, bem como o FINEP para universitários que queiram financiamento.

O certificado é um arquivo de pouco mais de 1Kb que contem uma chave criptográfica e dados de seu proprietário. No caso do programa ICP-Brasil, os dados gravados são CPF, RG, etc.

O programa ICP-Brasil (Infra-estrutura de Chaves Publicas, sigla em português para a tecnologia PKI, ou, Public Key Infrastructure) 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. Uma observação importante: a tecnologia real se chama PKI, o ICP-Brasil é uma série de medidas legais, técnicas e normas que possibilitaram o surgimento de versões virtuais de nossos CPFs e CNPJs.

A aceitação deste método de autenticação e segurança ainda é baixa, em primeiro lugar porque o custo é relativamente alto para o usuário final, que pode variar entre o modelo A1 que custa em torno de 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.

Neste artigo veremos agora como se deve utilizar certificados digitais, sejam os emitidos pelo ICP-Brasil ou utilizando o modelo PKI já disponível no Windows 2000/2003. Também abordaremos como emitir certificados para nossos usuários sem que eles tenham o custo de comprar um.

 

Argumentos para utilizarmos certificados

Para entender os tipos de certificados e o que está por trás de toda esta tecnologia PKI devemos, em primeiro lugar, abordar a questão do custo e tipo dos certificados. Quando falamos em tipos de certificados na verdade nos referimos a como chegaram até o cliente e como o cliente o usa fisicamente, e não o certificado em sí mesmo.

O certificado do modelo A1 consiste em um arquivo que contem duas chaves, uma pública e outra privada Já o modelo A3 é o conhecido “smartcard”, que agora bancos como Itaú e Bradesco passaram a distribuir aos 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$ 150,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$ 400,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 argumento para utilização dos certificados pessoais é 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 (vide Nota 1), portanto ele é quem diz ser. Fazemos isto por utilizar uma chave criptográfica para montar um servidor SSL (https), que nada mais é do que ter certeza de que não somos um fishing. Mas quem garante que “você” realmente é quem diz ser?

 

Nota 1 – Chaves Públicas e Privadas

A chave pública (Public Key) é aquela que apenas o emissor possui, enquanto a chave privada (Private Key) é trocada com todos os que acessam o site. Esse modelo é chamado de assimétrico, já que a utilização da chave pública para criptografar o faz com o algoritmo que apenas a privada consegue abrir, e vice-versa. Ou seja, com a chave publica lemos o que foi criptografado com a chave privada, mas não conseguimos alterar, uma vez que apenas a privada consegue abrir o que a pública criptografou, garantindo que o dono do certificado é ele mesmo, pois uma chave “falsificada” não conseguiria abrir a assinatura digital no documento ou no site.

 

No segundo desenho notamos que com o certificado do usuário a recíproca é verdadeira, tanto o usuário quando o servidor são confiáveis e autênticos. Esse conceito é chamado de assinatura digital (Digital Signature).

Anteriormente a única garantia que um banco ou uma empresa tem em relação à quem está logando em uma página privada ocorre através de identificadores, como por exemplo um número de agência e conta, para os sites de banco, ou então um endereço de email para demais sites.

Esses métodos eram facilmente burlados, por exemplo, alguém utilizando um trojan descobria o que você digitou e poderia utilizar esses dados para acessa a sua conta. 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.

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

Como funciona a estrutura PKI

Então agora que já entendemos que certificados digitais só nos ajudam, como funciona a tecnologia PKI?

A Figura 2 demonstra como ele funciona e suas vantagens em uma aplicação corporativa, onde apenas quem possui um certificado emitido pela empresa consegue o acesso. Este processo é chamado de “não repúdio”.

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 que são emitidos pelo SERPRO ou outra credenciada.

Figura 2 – Modelo básico com acesso utilizando certificados

 

Detalhando melhor os principais componentes PKI, podemos destacar 4 serviços 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

 

Figura 3 - Internet Explorer

·         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 a 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 contém 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.

 

Figura 4 - Subject do certificado

Configurando um servidor para utilizar certificados

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 adiante. 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.

Talvez você se pergunte porque utilizar uma certificdora própria se o ICP-Brasil já existe para isso, mas lembre-se de que no inicio do artigo foi comentado que os certificados e-CPF/e-CNPJ são pagos, e com preços bastante elevados por sinal.

Outra questão é como fazer o mesmo processo em servidores, como o Apache, por exemplo. Qualquer servidor web permite o uso de certificados para SSL, mas obviamente não é tão simples quanto no IIS. Quanto a emissão de certificados, tocamos no calcanhar de aquiles, já que emissão de certificados no Linux é bem mais complexo do que no Windows 2003, mas também pode ser feito. Contudo, não vamos abordar esse tema nesse artigo.

Voltando ao IIS, 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.

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.

Figura 6 - Acesso proibido por falta de um certificado

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

Figura 7 - Certificado sendo solicitado ao usuário

Utilizando os dados do certificado

O próximo passo é ler os dados do certificado para validar o usuário, e isto é mostrado 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.

 

Figura 8 - Acesso permitido e os dados do certificado exibidos

Listagem 1. Código ASP para ler os dados do certificado

  <HTML>

       <BODY>

             <H1>Bem-vindo </H1>

             <%=Request.ClientCertificate.Subject%>

       </BODY>

</HTML>

 

Vale lembrar que neste certificado o subject é o email do cliente, mas isto é configurável, portanto o subject de um e-CPF será o numero do documento.

Emitindo e certificando o IIS

A grande sacada é que o Windows 2000 e o Windows 2003 já possuem certificadoras !!!!

Portanto, esqueça o custo e a dificuldade, você mesmo pode criar a certificadora, certificar o seu site e seus usuários, precisando para isso ter apenas um servidor e o CD de instalação na mão.

Para instalar o serviço de certificação no seu Windows utilize o método normal de instalação de componentes: Painel de Controle -> Adicionar/Remover Programas -> Componentes do Windows.  Escolha na lista a opção “Certificate Authority”. Na tela de configuração do componente selecione “Standalone Certification Authoriry” e informe os dados de sua empresa, mas note que existe a opção para validade dos certificados. Se escolher a validade muito baixa seus usuários estarão sempre tendo que renová-lo. Por outro lado, certificados com tempo muito longo podem ter problemas de “vazamento” por parte do usuário. Utilize um período como 1 ou 2 anos que é o padrão utilizado hoje nos certificados comerciais.

Para certificar o IIS utilizando os seus próprios certificados o processo é o mesmo que utilizar um certificador comercial. Abra o gerenciador do IIS, abra propriedades do seu site e clique na aba “Security”, como mostra a Figura 9. Clique no botão “Server Security” e preencha com os dados do seu site. (Importante: Na opção “Issued to” coloque o nome do seu domínio na internet, *.seudominio.com.br, pois se fizer diferente disto no momento em que seu site for aberto ocorrerá um erro informando que o certificado não pertence ao seu site). Ao final terá um resumo dos dados como o da Figura 10.

Figura 9 – Configurando a segurança

 

Figura 10 – Resumo dos dados do certificado

Durante o processo foi gerado um arquivo texto, normalmente no raiz do disco de sistema com o nome “certreq.txt”. O conteúdo deste arquivo será a sua chave privada, como mostra a Listagem 2.

 

Listagem 2. Arquivo certreq.txt

-----BEGIN NEW CERTIFICATE REQUEST-----

MIIDUDCCArkCAQAwdTELMAkGA1UEBhMCQlIxCzAJBgNVBAgTAlNQMRIwEAYDVQQH

EwlHdWFydWxob3MxEDAOBgNVBAoTB0V4ZW1wbG8xEDAOBgNVBAsTB0V4ZW1wbG8x

ITAfBgNVBAMeGABtAHMAaQBuAGMAaQBjAF8AdwAyAGsAMzCBnzANBgkqhkiG9w0B

AQEFAAOBjQAwgYkCgYEAwcRAXg3lIfpu9NbN0vpgPw9eR1P3scccq79fwO2Xkc/X

rpZmxPzdsLnN0jwFfLLe7GotTnBotlLrsgipCevCs6wEM8gY0EJmdqxYqLuk783J

IXRoTuB5RbvdMUtBj/6wAVOaVAUJTeAvK9OMdqNzS9iCRr25XWpECjbWXor8IoUC

AwEAAaCCAZkwGgYKKwYBBAGCNw0CAzEMFgo1LjIuMzc5MC4yMHsGCisGAQQBgjcC

AQ4xbTBrMA4GA1UdDwEB/wQEAwIE8DBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3

DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwEwYD

VR0lBAwwCgYIKwYBBQUHAwEwgf0GCisGAQQBgjcNAgIxge4wgesCAQEeWgBNAGkA

YwByAG8AcwBvAGYAdAAgAFIAUwBBACAAUwBDAGgAYQBuAG4AZQBsACAAQwByAHkA

cAB0AG8AZwByAGEAcABoAGkAYwAgAFAAcgBvAHYAaQBkAGUAcgOBiQAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMA0GCSqGSIb3DQEBBQUA

A4GBAG3b+qC3ta8nYl6tD2Ens4El/qsvlMvn5QaI88w4zhSXmK4gnj3coIzAbUl8

MC0s4C/H9x1fJYhOfnore8FyUkTTv8SlobP7k3Y+eHI994OqUbeZuxTFme1j0O0A

EiCOmyFyuz9kUSCU/4lQ5I8ZhWbcW9ZSkyYWDiCjcpF+Gw/y

-----END NEW CERTIFICATE REQUEST----

 

Por mais incrível que pareça neste emaranhado de letras e números estão gravados os dados que foram informados no IIS na tela de configuração. O próximo passo é utilizar a página da certificadora para emitir o certificado para servidor. Utilize a url http://localhost/certsrv para acessar a certificadora como na figura 11. Escolha a opção “Request a certificate” -> “Advanced certificate request” -> “Submit a certificate request by using a base-64-encoded …”. Na caixa de texto cole o conteúdo do arquivo texto ou então use o link para encontrar o arquivo certreq. No final receberá uma tela de confirmação de pedido encaminhado e avisa que é necessário o administrador liberar o seu certificado.

 

Figura 11 – Certificadora Windows 2003 baseada em web

 

Esta liberação é feita na ferramenta “Certification Authority” nas ferramentas administrativas do certificador. Ao abrir vá à árvore “Pending Requests” e o certificado estará listado como na figura 12, clique no item e com o botão direito escolha “All Taks” -> “Issue”, disponibilizando o certificado.

Figura 12 – Liberando os certificados na ferramenta de administração da certificadora

 

Agora volte na página onde o certificado foi solicitado e escolha a opção “View status of pending request”.Seu certificado já está aguardando para ser copiado, como mostra a figura 13. Basta clicar e salvá-lo em um local apropriado, lembrando que este certificado nunca pode cair em mãos erradas, sua segurança está baseada nos dados nele contidos.

Figura 13 – Recebendo o certificado após a liberação

 

Com o arquivo do certificado em mãos, vamos terminar o processo no IIS. Volte no seu web site, abra as propriedades e navegue até a guia segurança e em seguida clique no botão “Server certificate”. A tela seguinte permite terminar o processo iniciado anteriormente quando criamos a chave, como mostra a figura 14. Para finalizar clique no botão “Edit...” da guia segurança do web site e force o uso de certificados para acesso ao site, bem como a opção “Require client certificates” mostrado na figura 15.

Figura 14 – Instalando o certificado emitido no servidor IIS

 

Figura 15 – Configurando o uso dos certificados

Pronto!!!  Seu IIS já está com SSL habilitado e permitindo acesso apenas ao usuários possuidores de certificados digitais. Um processo adicional que pode ser feito ainda é gerar a lista das certificadoras permitidas, restringindo certificados de outros domínios que não estejam sobre seu controle. Para fazer isso clique em “Enable certificate trust list” e escolha as certificadoras que seus usuários poderão utilizar, como mostra a figura 16. Não esqueça de colocar na lista as certificadoras do ICP Brasil caso vá utilizá-las.

Figura 16 – Gerando a lista de certificadoras aceitas

Emitindo e certificando o usuário

Terminada a certificação do servidor precisamos certificar os usuários. Como a configuração do servidor exige certificados para acesso ao site o processo de certificação do usuário se tornou imprescindível e não apenas recomendado como anteriormente.

Para emissão instrua o usuário a acessar a certificadora pelo mesmo link utilizado para emitir o certificado do IIS. Processa com a opção de solicitação e no tipo de certificado escolha novamente “Advanced certificate request” e na tela seguinte a opção para submit de formulário, onde o usuário irá preencher os dados e receberá a informação para aguardar a liberação.

Vá à ferramenta “Certificate Authority” como descrito anteriormente e libere o certificado. Instrua o usuário a retornar ao site da certificadora e escolher a segunda opção para receber o certificado como mostra a figura 17. Ao clicar em “Install Certificate” o certificado é automaticamente instalado na máquina do usuário, diferente do processo quando para o servidor que o certificado é apenas copiado.

Figura 17 – Instalação do certificado do usuário

 

Concluído este processo o usuário já irá conseguir acessar o seu site de forma autenticada e será possível suas páginas com o código apresentado anteriormente identificar o usuário e ler os dados que foram preenchidos no formulário da certificadora, que pode ser acessada localmente ou mesmo pela internet se o seu servidor estiver publicado.

Como último conselho, caso sua certificadora esteja na internet, lembre-se de fazer backup do “System State” periodicamente, já que a única forma de copiar os certificados da certificadora e dos usuários é essa. Isso é importante porque perder a certificadora causa a perda também da CRL (Certificate Revogation List) que irá impedir os certificados de serem utilizados.

Conclusões

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. Inclusive o modo como administramos a solicitação, a liberação e a instalação dos certificados é a mesma utilizada pelas certificadoras comercias, apenas com interfaces mais elaboradas.

A utilização dos certificados digitais é simples mas poderosa permitindo autenticação segura do usuário.

Vemos que a segurança ganha com o processo é muito maior que o custo envolvido, principalmente quando lembramos que uma fraude utilizando o nome de outra pessoa é responsabilidade do site e não do cliente que foi fraudado segundo o Código do Consumidor.

 

Links e Referências Interessantes

http://www.icpbrasil.gov.br/

Site oficial do ICP Brasil (Infra-estrutura Chaves Públicas).

 

http://www.certisign.com.br/home/default.jsp

Uma das mais importantes certificadoras mundiais, que vende o e-CPF e o e-CNPJ.

 

http://www.rhbr.com.br/modules.php?name=News&file=article&sid=366

Passo a passo de instalação do SSL para o Apache

 

 

 

 

 

 

 

Marcelo Sincic (ms@avancoinformatica.com.br) é certificado Microsoft como MCITP, MCTS, MCPD, MCSA, MCDBA, MCSD, MCAD e MCT pela IBM como CLP do Domino 6.5 e pela SUN como Java Trainer. Atualmente como consultor e instrutor ministrando treinamentos em .NET e plataforma Microsoft, mas é desenvolvedor desde 1989 com Clipper S’87 e Dbase III rodando Novell 2.1. Bons tempos aqueles...