Jeroen van de Graaf <jvdg@lcc.ufmg.br>
Wilton Speziali Caldas
Osvaldo Carvalho
Sérgio Novaes
Laboratório de Computação Científica
Universidade Federal de Minas Gerais
Resumo
1. Introdução
2. Modelos de confiança
2.1 Modelo hierárquico
2.2 Certificados cruzados
2.3 AC-Ponte: um meio-termo
3. Nossa proposta
4. Observações
5. Conclusão
Referências bibliográficas
Neste documento, propomos um projeto para unificar as infra-estruturas de chave pública no âmbito acadêmico brasileiro. O objetivo é facilitar o reconhecimento mútuo de certificados X509 emitidos por universidades ou outras organizações acadêmicas, assim facilitando a autenticação, autenticidade, integridade e não-repúdio nas comunicações.
A tecnologia chamada de Infra-Estrutura de Chave Pública (ICP - em inglês Public Key Infrastructure, ou PKI) objetiva melhorar a segurança digital. Sua adoção é um processo lento por razões diversas:
Hoje, o uso principal da ICP é para garantir o URL de um servidor, principalmente em transações comerciais. Também os sistemas de home banking utilizam certificados digitais, seja de X509, seja de um formato próprio.
No mundo acadêmico, a utilização de ICP está crescendo:
O caso do SINAPAD é um exemplo de um recurso compartilhado nacionalmente. Podemos esperar que num futuro próximo surjam mais exemplos de sistemas cuja autenticação é feita através de certificados X509, um mecanismo mais robusto que uma mera senha. Por isso, achamos o momento oportuno para iniciarmos um projeto de ICP no âmbito acadêmico, estabelecendo algumas diretrizes e, assim, facilitar a convergência para uma solução bem pensada e madura.
O propósito de uma ICP é aumentar a segurança e confiança digital; ela implementa um modelo (ou hierarquia) de confiança, decidindo quem autentica quem e quem confia em quem. A escolha do modelo de confiança pode fazer a diferença entre o sucesso ou o fracasso. Apresentamos aqui um resumo sobre modelos de confiança, para detalhes veja por exemplo [3] [2] [4].
Um certificado digital nada mais é que uma assinatura digital num documento com um formato especial. O certificado cria um vínculo entre uma chave pública e a identidade de uma entidade (pessoa, servidor, URL etc.) que possui a chave privada correspondente. O emissor de certificados digitais é chamado de Autoridade Certificadora (AC). Observe que todo mundo pode atuar como AC e que as exigências para emitir certificados podem variar muito entre ACs. Ou seja, para se avaliar o significado de um certificado deve-se conhecer a política da AC emissora.
Para que um terceiro possa verificar um certificado emitido por uma AC, é necessário que ele possa confiar no certificado da AC. Para resolver isso há duas opções: 1) a AC auto-assina sua chave pública criando um certificado e divulgando-o amplamente. Neste caso, ela está no topo de hierarquia de confiança e é chamada de AC-Raiz. 2) ela procura uma outra AC-Raiz já bem-conhecida que assina seu certificado. Verifique-se que em ambos os casos um terceiro pode verificar o certificado do usuário. Observe que no primeiro caso temos um modelo "flat": existe uma AC que assina todos certificados, enquanto no segundo caso temos um modelo hierárquico: há uma AC-Raiz e uma AC-Intermediária. Na verdade, não há limite no número de ACs-Intermediárias e, assim, pode-se construir hierarquias de confiança mais extensas e complicadas.
Em teoria, uma grande hierarquia resolveria todos os problemas de autenticação no mundo, mas na prática há vários problemas: 1) deve-se começar top-down, com conseqüências catastróficas se errar ? 2) Quem deve assumir o papel de AC-Raiz? A UFMG? A Rede Nacional de Ensino e Pesquisa (RNP)? O governo brasileiro? A Organização das Nações Unidas (ONU)?
Na prática, várias organizações começam a emitir certificados, atuando como AC-Raiz na sua própria hierarquia, criando várias hierarquias isoladas. Por exemplo, a UFSC e a UFMG já estão emitindo certificados separadamente. A questão é: como juntar estas hierarquias?
Se, por exemplo, a UFSC quiser reconhecer os certificados emitidos pela UFMG, ela pode criar um certificado cruzado, isto é, ela assina o certificado raiz da UFMG. Desta forma, um usuário da UFSC confrontado com um certificado da UFMG vai confiar nele, porque o certificado cruzado é testemunha que a AC-Raiz da UFSC confia em todos certificados emitidos pela UFMG. Normalmente, faz-se também o inverso: a UFMG assina o certificado raiz da UFSC, endossando todos os certificados da UFSC.
A grande vantagem deste modelo é que as partes são iguais: entidades autônomas que decidem cooperar. E se a chave raiz privada de uma entidade for comprometida, o estrago fica limitado na hierarquia onde isto aconteceu; a outra tem apenas que revogar o certificado correspondente.
A situação fica mais complicada se houver mais de duas organizações: com N organizações, todas elas têm que criar certificados cruzados entre si, resultando em N(N-1) certificados cruzados. Para resolver isso, existe uma outra topologia: cria-se um AC-Ponte, ou seja, uma AC-Raiz que tem como único objetivo criar certificados cruzados com todas as outras AC-Raiz. Assim, uma AC-Raiz precisa lidar somente com a AC-Ponte. A AC-Ponte tem N clientes. O custo é que o caminho de verificação aumentou em um nó. Para uma discussão mais ampla sobre as vantagens deste modelo, veja [3] seção 8.2.2.
Em essência, a nossa proposta é lançar um projeto para a criação e operação de uma AC-Ponte no âmbito acadêmico. Imaginamos que o próximo passo será a criação de um comitê de especialistas de várias universidades e da RNP. Este comitê deve formular um projeto mais detalhado para solucionar as questões mencionadas neste documento.
Argumentamos que já estão surgindo ICPs isoladas do mundo acadêmico brasileiro, e que unificá-las seria inevitável. A RNP é a entidade "par excellence"' para assumir esta responsabilidade.
[1] AC - AUTORIDADE CERTIFICADORA. Autoridade Certificadora. Disponível em: <http://ac.labsec.ufsc.br>. Acesso em 31 mar. 2003.
[2] ADAMS, C.; LLOYD, S.; KENT, S. Understanding the Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations. New Riders Publishing, 1999. ISBN 157870166X.
[3] IGNACZAK, L. Um novo modelo de Infra-estrutura de Chaves Públicas para uso no Brasil utilizando aplicativos com o código fonte aberto. 2002. 100f. Dissertação (Mestrado em Ciência da Computação)-Universidade Federal de Santa Catarina, Florianópolis, 2002.
[4] NASH, A.; DUANE, B.; BRINK, D.; JOSEPH, C. PKI: Implementing & Managing E-Security. McGraw-Hill Osborne Media, 2001. ISBN 0072131233.