<< Codificando .Net e-magazine edição 09 | Silverlight 3.0 - Mas já? >>

Introdução ao desenvolvimento utilizando certificados digitais - Parte 2

by SrECosta abril 12, 2009 17:14

Previously on Mutamblog Galactica... Ops!

Entendendo o uso de chaves pública e privada

Um certificado digital é basicamente um arquivo de dados. É necessário um mecanismo que proteja o seu conteúdo de maneira que seus dados não possam ser alterados. Para confiar nos dados é necessário que se possa confiar no seu emissor. O mecanismo que possibilita a proteção dos dados do certificado é a criptografia assimétrica de chaves pública e privada.

É mais fácil entender a criptografia de chaves assimétricas por comparação com a criptografia de chave simétrica. Nesta última, a chave utilizada para criptografar (cifrar seria um termo melhor) um dado é a mesma chave utilizada para descriptografá-lo (descifrá-lo). Já no caso da criptografia de chaves pública e privada é utilizada uma chave para criptografar o dado (a chave pública) e é utilizada outra (a chave privada) para descriptografá-lo.

O grande senão da criptografia simétrica é que, por motivo de somente existir uma chave, ela deve ser conhecida tanto por quem está criptografando algum dado quanto por quem irá descriptografá-lo. Por exemplo, se você utilizar esta criptografia para proteger um arquivo antes de enviá-lo para um amigo, este amigo somente poderá descriptografá-lo se também conhecer a chave.

Já no modelo assimétrico a chave pública pode ser amplamente divulgada mantendo-se segredo somente da chave privada. No exemplo que citei, você poderia criptografar o arquivo utilizando a chave pública do seu amigo e, uma vez que somente ele conhece a chave privada correspondente, somente ele poderia descriptografá-lo. Você pode criptografar quantos arquivos (ou mensagens) quiser que somente ele teria condições de utilizá-los. Nem mesmo você que criptografou os arquivos será capaz de descriptografá-los.

Voltando aos certificados, de maneira geral o fluxo de utilização das chaves inicialmente é este:

O primeiro passo para a geração de um certificado é a geração do par de chaves.
Uma vez que o par de chaves tenha sido gerado, é criada a requisição com os dados do indivíduo.
Esta requisição é assinada utilizando a chave privada.
A requisição é enviada para a CA junto com uma cópia da chave pública (observe que, normalmente, a CA não precisa conhecer a chave privada do certificado).
A CA, ao receber a requisição, valida sua assinatura utilizando a chave pública associada.
Se a CA confiar na assinatura e nos dados do indivíduo ela procede gerando o certificado.
Em seguida a CA utiliza a sua própria chave privada (também chamada de raiz) para assinar o certificado.
Finalmente, a CA devolve o certificado gerado junto com uma cópia da sua chave pública.
Se quem realizou a requisição confiar na CA pode ou não proceder com a instalação do certificado.

A assinatura de um certificado é o que permite confiar seus dados. Sempre que é necessário apresentar um certificado é necessário apresentar a sua assinatura. E a sua assinatura é validada contra o seu par de chaves.

A maior fraqueza de um sistema baseada em par de chaves é a proteção das chaves privadas. Se uma CA tem a sua chave privada desprotegida e roubada todos os certificados gerados por ela estarão comprometidos. Num nível abaixo, se a chave privada de um certificado é conhecida, o mesmo certificado também estará comprometido.

O algoritmo criptográfico utilizado para gerar o par de chaves é o RSA¹. A partir daqui podemos falar dos famosos padrões de criptografia de chave pública.

Padrões de criptografia de chave pública (PKCS)

A melhor parte dos padrões de criptografia de chave pública é que eles não são realmente um padrão oficial da indústria mas o são de facto. Explico: depois de inventarem o algoritmo de chave pública os caras da RSA publicaram uma série de artigos, os tais padrões, para promover diversos usos para o algoritmo. A indústria como um todo adotou a maioria destes padrões e, embora eles não tenham sido publicados por autoridades técnicas (ANSI, ISO, IETF, você diz qual), eles têm este super-status.

Chamados de PKCS ou public-key cryptography standards, há cerca de quinze padrões (você pode acessar a documentação original completa no site da RSA). Cada um destes padrões corresponde a um propósito de uso para uma chave pública, por exemplo, assinar ou encriptar mensagens, como armazenar chaves privadas e por aí vai.

Para nossa pequena introdução os padrões relevantes são: PKCS #7, PKCS #10 e PKCS#12. Tem também o PKCS #11 mas eu falarei dele somente quando comentar sobre CSPs (esse, como diria um amigo meu, é "nervoso"). :)

PKCS #7 e PKCS #10

O padrão PKCS #7 e PKCS #10 são, normalmente, utilizados em conjunto. Lembra-se quando eu comentei um pouco mais acima sobre o fluxo inicial de utilização do par de chaves? Eu omiti alguns detalhes na esperança de que eles ficassem mais claros agora. :)

Quando a requisição de um certificado é criada para ser enviada para uma CA ela é formatada utilizando o padrão PKCS #10 (seu nome de batismo é Certification Request Standard), ou seja, a CA recebe a requisição neste formato. Este formato é binário mas pode ser convertido para texto (em base 64). Veja um exemplo (que eu peguei lá na Wikipedia):

Quando a CA envia de volta o certificado gerado ele é formatado utilizando o padrão PKCS #7 (cujo nome de pia é Cryptographic Message Syntax Standard), ou seja, o processo que gerou a requisição recebe de volta um certificado neste formato. Este formato também é binário e também pode ser convertido para um texto em base 64. Sem exemplo agora, depois eu edito o post e coloco um...

Update (em 27/04/2009): meu amigo Badaró me mandou um link com um certificado em base 64. Superinteressante porque você pode baixá-lo e ter como checar seu conteúdo. Para quem não quiser baixá-lo, ele está logo abaixo (copie-o e cole num arquivo .CER que você conseguirá abri-lo e visualizar os detalhes do indivíduo e da CA associada):

PKCS #12

Normalmente um certificado digital não é transmitido ou mantido junto de sua chave privada. Porquê? Bem simples: seria o equivalente a trancar uma gaveta e manter a chave presa na fechadura. Contudo, há situações em que isto é necessário. Por exemplo, quando se precisa fazer backup de uma CA. Neste caso é feito um backup do certificado raiz da CA junto com sua chave privada para que, em caso de perda da CA (HDs fritam, servidores pegam fogo, principalmente os da Telefonica...) a CA possa ser reinstalada utilizando o mesmo certificado raiz.

Neste caso, o certificado digital é salvo num arquivo (extensão .p12 ou .pfx) junto com seu par de chaves. O formato deste arquivo obedece o padrão PKCS #12 (ou Personal Information Exchange Syntax Standard para os puros de coração). É importante ressaltar que o certificado digital é salvo protegido por um algoritmo simétrico ou seja, para gerar o arquivo você informa uma senha e para utilizá-lo depois também terá de informar a senha novamente.

Ok, agora que falamos um pouco sobre as chaves pública e privada podemos prosseguir para o conceito de PKI.

Infra-estrutura de chave pública (PKI)

Uma infra-estrutura de chave pública ou public-key infraestructure ou PKI (para simplificar) é toda estrutura voltada para gerenciar certificados digitais e suas chaves públicas.

É mais ou menos assim: ao conjunto de processos responsável por associar numa CA, de maneira indubitável, um indivíduo com uma chave pública é dado o nome de PKI. Sendo assim, a PKI não é uma tecnologia mas sim um conjunto de processos. Somando tudo que se requer para gerenciar indivíduos e suas chaves públicas é que se denomina PKI. (Vale lembrar que por indivíduo deve-se entender uma pessoa ou um hardware ou um serviço.)

No mundo MS, o componente mais importante de uma PKI é a CA ou Certificate Authority. Este é um componente que pode ser instalado a partir dos sistemas operacionais de servidor (Windows 2000 / 2003 / 2008) e é encontrado lá no Adicionar / Remover Programas.

Há basicamente dois tipos de CA, na visão MS: Enterprise e Standard.

Enterprise: é a CA instalada em conjunto com o Active Directory (AD). É a CA mais poderosa e cheia de recursos que a MS oferece pois você tem numa solução integrada tanto a base de usuários quanto os certificados digitais. Exclua um usuário e o seu certificado digital será revogado, por exemplo.
Standard: é a CA instalada num ambiente sem o Active Directory (ou pelo menos sem integração). Permite gerar certificados normalmente, porém, não conta com uma série de facilidades e recursos disponíveis na versão Enterprise. Isto fica claro porque a CA não conhece a base de usuários. Exclua um usuário e você terá de possuir um processo / procedimento para revogar o certificado digital correspondente, por exemplo.

Não vou entrar no mérito de instalação da CA pois existem ótimos tutoriais de como proceder. Veja este aqui da IT Central para ter uma idéia.

No próximo post...

Ok, falta pouco para o final desta série introdutória (mentira!) . :) Eu preciso comentar sobre cryptostore, snap-ins do Windows, CSPs e outras coisas mais. Aí entraremos no .NET Framework, ActiveX e código (at last!). Fique comigo e mande ver nos comentários!

Abraços.

¹ Trivia: RSA vem de Ron Rivest, Adi Shamir e Leonard Adleman, seus inventores. Eles também fundaram a empresa RSA para poder divulgar seu trabalho e poder ganhar um dinheirinho. :)

5.0 ponto(s). Avaliado por 3 pessoas

Currently 5/5 Stars.
1
2
3
4
5

Tags:

Segurança Digital | Treinamento e Aprendizado

Posts relacionados

Introdução ao desenvolvimento utilizando certificados digitais O básico: certificados digitais são utilizados para identificar indivíduos, r...LINQ Dinâmico (Parte 1: Utilizando a Biblioteca Dynamic Query da LINQ) [Post do Scott Guthrie traduzido para o português] LINQ (language integrat...Série sobre certificados digitais Oi. Estou pensando seriamente em escrever uma série de posts sobre certificados digita...