PKI (Public Key Infrastructure) ou ICP (Infraestutura de chave pública) é um conjunto de hardware, software, pessoas, políticas e procedimentos necessários para criar, gerenciar, armazenar, distribuir e revogar certificados digitais[1]. Baseado  no principio da terceira pessoa confiável (TTP – Trusted Third Party), o PKI, ou ICP, oferece uma mediação de credibilidade e confiança em transações entre partes que utilizam certificados digitais[1,2,3].

Embora este método tenha sido adotado há alguns anos com relativo sucesso, há quem questione-o causando certo desconforto as empresas e instituições que de alguma maneira estão envolvidas neste processo, seja usando certificados ou seja registrando-o e mantendo-o.

Descrição do Assunto

O artigo Ten risks of PKI: What you’re not being told about Public Key Infrastructure, ou “Dez riscos do ICP: O que não lhe foi dito sobre a infraestrutura de chaves públicas” (em tradução livre) é assinado por Carl Ellison e Bruce Schneier e foi publicado no Computer Security Journal – volume XVI, nº 1 em 2000[4]. Os autores que possuem larga experiencia na área de segurança de sistema se já tendo escrito vários outros artigos e livros sobre o assunto alertam que o PKI tem sido vendido como a resposta para vários problemas de segurança e que suas intenções com este artigo é discutir os problemas que o PKI não soluciona e que os vendedores não gostam de mencionar.

Apreciação crítica

Os autores começam o artigo fazendo um comentário que nos levar a refletir sobre a infindável busca pelo sistema seguro. Conforme reportam, primeiro foi o firewall, em seguida os sistemas de detecção de intrusão (IDS), depois as VPNs e agora [considerando a data de publicação do artigo] é a vez das autoridades certificadoras (CAs) e infraestrutura de chaves públicas (PKI). Em um tom irônico eles parafraseiam aqueles que vendem estes produtos/serviços como uma solução definitiva para a segurança da sua empresa e alertam que na realidade não tão simples assim.

O trabalho de sete páginas é subdivido em dez partes que correspondem a cada um dos dez riscos os quais eles apontam existir e que são eles:

1. Who do we trust, and for what?
2. Who is using my key?
3. How secure is the verifying computer?
4. Which John Robinson is he?
5. Is the CA an authority?
6. Is the user part of the security design?
7. Was it one CA or a CA plus a Registration Authority?
8. How did the CA identify the certificate holder?
9. How secure are the certificate practices?
10. Why are we using the CA process, anyway?

Estas questões foram discutidas individualmente, de forma que os autores traz a tona assuntos que muitas vezes não são questionadas pelos novos usuários desta tecnologia.

Os autores deixam suas impressões sobre cada questão de forma que muitas vezes as elas se transformam em outras indagações. Como segue:

Em quem nós confiamos e por que?

Uma CA é geralmente definida como “confiável”, mas segundo a literatura, isso só quer dizer que eles cuidam bem de suas próprias chaves privadas.

Quem deu a CA, autoridade para garantir autorizações? Quem a fez confiável? O fato dela ter escrito uma maravilhosa política de práticas de certificação não quer dizer que nós podemos confiar em seus certificados e além do mais qualquer um pode assinar nomes, nós fazemos isso a todo momento.

Quem está usando minhas chaves?

Um dos maiores problemas de um sistema baseado em CA está com própria chave privada de assinatura. Como você a protege?

Vírus e outros tipos de programas maliciosos podem invadir o seu computador, por exemplo. Mesmo que sua chave esteja segura em seu computador e que ele esteja trancado em uma sala com vigilância por vídeo será que apenas você e mais ninguém o utiliza? Sua chave está protegida por senha? O quanto ela é segura? Está em um smartcard? O quão resistente a ataques ele é?

Esta preocupação é devido ao termo “não-repudiação” e isto quer dizer que o algorítimo de assinatura digital é inquebrável e por isso uma terceira pessoa não pode forjar sua assinatura. Ou seja você nunca poderá negar que a assinatura é sua.

Em termos legais, algumas regiões dos EUA possuem legislação (Utah e Washington, por exemplo) que definem que se suas chaves foram certificadas por uma CA aprovada então você torna-se responsável por qualquer problema com elas. Não importa quem estava usando seu computador ou que tenha sido um vírus quem tenha “assinado” algum documento, você será legalmente responsabilizado. O que contrasta com a legislação sobre cartões de crédito e telefonia em que havendo discrepâncias entre o que você consumiu e o que você não reconhece como sendo despesas suas, você tem o direito de repudiar aquela fatura ou ao menos as despesas que estão em xeque, cabendo a operadora a responsabilidade provar o contrário e não o usuário.

O quão seguro é o computador de verificação?

A verificação de certificados não usa chaves secretas, apenas chaves públicas são envolvidas portanto não há segredos para protege-la. Se um atacante puder adicionar sua própria chave pública à esta lista ele poderá validar seu próprio certificado que será tratado com um certificado legitimo.

Que John Robinson é este?

Certificados, geralmente associam as chaves públicas ao nome, mas poucas pessoas comentam sobre o quão útil é esta associação.

Imagine que você tenha recebido um certificado do John Robinson. Você pode conhecer apenas uma pessoa com este nome, mas quantas pessoas com este mesmo nome estão certificadas pela CA? Isso é um problema pois você não terá como saber se o certificado recebido por você é do mesmo John Robinson que você esperava.

A CA é uma autoridade?

Uma CA pode ser autoridade sobre o certificado mas não sobre o seu conteúdo.

O certificado de um servidor SSL possui duas partes de dados potencialmente seguros: O nome do seu possuidor e o nome DNS do servidor. Existe autoridade sobre a assinatura do nome DNS mas não sobre as CAs que assinam o certificado SSL na maiorias dos browsers mais populares.

O usuário é parte do modelo de segurança?

Aplicações usando certificados devem levar o usuário em conta usar apenas criptografia?

Por exemplo, um usuário normal decide comprar em uma loja virtual através uma página baseada em certificados SSL. O certificado SSL não é exibido e nem possui necessariamente qualquer relação com o conteúdo exibido. Além do mais algumas vezes o certificado pertence a empresa onde as páginas estão hospedadas e não a empresa cujo logotipo aparece nas páginas.

Foi uma CA ou uma CA e uma RA?

RAs são a resposta das CAs quanto ao fato de não serem autoridade sobre o conteúdo dos certificados entretanto este modelo é categoricamente mais inseguro visto que este modelo permite algumas entidades não autorizadas à modificar o conteúdo do certificado.

Como a CA identificou o detentor do certificado?

Se um certificado contém apenas um identificador ou alguma autorização específica, a CA precisa identificar o candidato antes de emitir o certificado.

O quão segura são as práticas do Certificado?

Certificados não são como porções mágicas de segurança em que basta adicionar algumas gotas ao seu sistema e ele estará seguro. Eles devem ser usados adequadamente.

As práticas de utilização tem sido baseadas em razões sólidas de segurança ou são puramente rituais e imitações de outras pessoas/instituições.

Como são computados e manipulados o tempo de vida útil de um certificado? E a revogação dos mesmos?

Por que usamos o processo de CA desta maneira?

Um empregado de uma empresa do ramo de PKI relatou ter vendido alguns anos atrás sua solução PKI, mas os clientes ficaram insatisfeitos com os resultados. Após a emissão dos certificados para todos os empregados o sistema de PKI não contribuía para implementação do procedimento de Single-Sign-On, o que é desejável pela maioria das empresas já que autenticação sempre foi uma uma questão problemática.

Considerações Finais

O artigo em pauta foi referenciado por diversos outros autores tal como as apresentações feitas por Carlos Ribeiro[5] e por Paulo Balsinhas[6] entretanto ele também foi alvo de diversas críticas no meio acadêmico. Entre elas o texto Ten Risks of PKI[6] escrito por Aran Perez, que embora diga não se tratar de uma resposta ao artigo de Scheneier e Ellison, ele critica vários pontos de vistas daqueles autores e refutam várias ideias embora reconheça que haja alguns pontos válidos; e ainda o artigo Seven and a half non-risks of PKI: What you shouldn’t told about public Key Infrastructure [8], assinado por Laurie da Apache Foundation que claramente responde e rebate cada um dos pontos apresentados por Bruce e Ellison.

O fato de haver trabalhos tanto a favor quanto contra a obra dos autores alvo desta resenha, não invalida o seu trabalho, mesmo porque todos concordam em um ou outro ponto que há o que se melhorar no processo de PKI e ainda mais que não há e possivelmente nunca haverá um mecanismo 100% seguro para proteger nossos dados, visto que sistemas de segurança são criados por humanos e sempre são passíveis de cometer equívocos em suas análises e algorítimos.

Há uma extensa lista de links para artigos, CAs em diversos países e outros sites relacionados ao assunto PKI em [9]. Lá é um bom ponto de partida para quem desejar tirar suas próprias conclusões a respeito deste mecanismo e também sobre as tecnologias relacionadas a ele tal como criptografia, assinatura digital, SSL/TLS, segurança Web em geral, legislação, RFCs e normas afins e muito mais.

Referências bibliográficas

[1] Wikipédia. Public Key Infrastructure. Junho/2009. Disponível em <http://en.wikipedia.org/wiki/Public_key_infrastructure>. Acessado em 15/Jul/2009.

[2] Wikipédia. ICP. Março/2009. Disponível em <http://pt.wikipedia.org/wiki/PKI>. Acessado em 15/Jul/2009.

[3] Articsoft. Introduction to Public Key Infrastructure. Fev/2003. Disponível em <http://www.articsoft.com/wp_pki_intro.htm>. Acessado em 15/Jul/2009.

[4] ELLISON, Carl; SCHNEIER, Bruce. Ten Risks of PKI: What You’re Not Being Told About Public Key Infrastructure. Computer Security Journal, v 16, n 1, 2000, pp. 1-7. Disponível em <http://www.schneier.com/paper-pki.html>. Acessado em 10/Jul/2009.

[5] RIBEIRO, Carlos. Certificados Digitais. Disponível em <http://web.tagus.ist.utl.pt/~carlos.ribeiro/seminarios/tagus/W7a.pdf>. Acessado em 16/Julho/2009.

[6] BALSINHAS, Paulo. Segurança em sistemas de informações judiciais. Outubro/2007. Disponível em <http://www.itij.mj.pt/sections/sobre/anexos/capitao-paulo-balsinhas/downloadFile/attachedFile_f0/Capitao_Paulo_Balsinhas.pdf?nocache=1193758710.75>. Acessado em 16/Julho/2009.

[7] PEREZ, Aran. Ten risks of PKI. Disponível em <http://homepage.mac.com/aramperez/responsetenrisks.html>. Acessado em 16/Julho/2009.

[8] LAURIE, ben. Seven and a Half Non-risks of PKI: What You Shouldn’t Be Told about Public Key Infrastructure. Disponível em <http://www.apache-ssl.org/7.5things.txt>. Acessado em 16/Julho/2009.

[9] KELM, Stefan. The PKI page. Disponível em <http://www.pki-page.org/>. Acessado em 17/Julho/2009.