Sistema de Gerenciamento de Certificados Digitais ICPEDU

Transcrição

1 Sistema de Gerenciamento de Certificados Digitais ICPEDU Jonathan Gehard Kohler 1, Rogério Bodemuller Júnior 1 1 Laboratório de Segurança em Computação (LabSEC) Departamento de Informática e Estatística (INE) Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil jonathan@inf.ufsc.br rbj@inf.ufsc.br Abstract. This meta-paper describes the style to be used in articles and short papers for SBC conferences. For papers in English, you should add just an abstract while for the papers in Portuguese, we also ask for an abstract in Portuguese ( resumo ). In both cases, abstracts should not have more than 10 lines and must be in the first page of the paper. Resumo. Este meta-artigo descreve o estilo a ser usado na confecção de artigos e resumos de artigos para publicação nos anais das conferências organizadas pela SBC. É solicitada a escrita de resumo e abstract apenas para os artigos escritos em português. Artigos em inglês deverão apresentar apenas abstract. Nos dois casos, o autor deve tomar cuidado para que o resumo (e o abstract) não ultrapassem 10 linhas cada, sendo que ambos devem estar na primeira página do artigo. 1. Introdução Atualmente a segurança das informações é algo muito importante, principalmente com o surgimento da internet. Informações transmitidas entre 2 pessoas, pela internet, podem ser interceptadas. Estas informações poderão ter o seu conteúdo alterado, ou caso serem confidenciais, serem lidas (e talvez até divulgada) por terceiros desautorizados. Para evitar este tipo de problema no mundo virtual, foram criados os certificados digitais. Uma espécie de um documento eletrônico que prova que uma pessoa é ela mesma. A utilização de certificados digitais necessita de uma estrutura chamada de Infra- Estrutura de Chaves Públicas (ICP). É como se o certificado digital fosse o seu cartão de Cadastro de Pessoa Física (CPF), e a ICP fosse a Receita Federal Brasileira (órgão brasileiro responsável pelos cartões de CPFs). Para administrar estas estruturas, ICPs, existe uma classe de programas chamada de Sistemas de Gerenciamento de Certificados (SGC). Sistemas complexos que provêem funcionalidades para facilitar a administração de Infra-Estruturas de Chaves Públicas. O desenvolvimento de programas deste tipo parece muito simples, porém existem requisitos importantes que devem ser satisfeitos por esta classe de programas. Os requisitos demonstrados neste artigo foram detectados a partir da experiência do desenvolvimento e manutenção de outro software SGC existente. Na apresentação dos requisitos serão detalhados os benefícios e alguns problemas causados pelo mesmo.

2 2. Certificado Digital, ICP e SGC. O que é isto tudo? Um SGC é basicamente um programa que gerencia uma ICP e seus certificados. A seguir, será brevemente explicado o funcionamento de um Certificado Digital, de uma ICP e suas respectivas funcionalidades. Um certificado digital é um objeto digital que garante que uma chave pública é de uma certa pessoa. Este certificado é considerado válido através da confiança em uma terceira entidade. Na Figura 1 pode-se ver um exemplo da utilização do certificado digital. Figura 1. Exemplo da utilização de um Certificado Digital Beto pede um certificado para Carlos. Carlos confere os dados de Beto, e verifica que Beto é mesmo Beto, e que a chave pública apresentada é de Beto. Carlos emite um certificado assinado por ele, afirmando que Beto é o dono daquela chave. Agora, Beto possui um certificado assinado por uma terceira parte. Alice quer enviar uma mensagem para Beto, e Alice confia em Carlos. Alice pega o certificado de Beto e verifica se o certificado é genuíno e se os dados não foram alterados. Alice verifica também quem assinou aquele certificado. Ela vê que foi Carlos. Alice confia em Carlos, consequentemente Alice confia que o certificado é válido. Alice pergunta a Carlos se o certificado ainda é válido. Carlos confirma que o certificado ainda está válido. Agora Alice sabe que a chave pública que está no certificado, é mesmo a chave pública de Beto. Então ela pode enviar uma mensagem para Beto com segurança. E surge um problema, e se roubarem o certificado de Beto? Alice enviará mensagens para o ladrão, achando que está enviando mensagens para Beto? Isto não acontece, pois quando for roubado, ele avisará Carlos. E a próxima vez que Alice for enviar uma mensagem à Beto, Carlos irá avisar que aquele certificado foi roubado. Nessa pequena história, temos vários conceitos. Vamos identificá-los um a um. Alice e Beto, são indivíduos (pessoas, computadores, etc) querendo transmitir uma mensagem.

3 Carlos é na verdade uma entidade emissora de certificados (que normalmente é uma empresa ou um órgão governamental). Quando Beto pede a Carlos que seja emitido um certificado para ele, Beto está fazendo uma requisição à entidade emissora de certificados. Este é o primeiro passo para a emissão de um certificado digital. Após Beto fazer a requisição, Carlos confere vários dados de Beto. Esta verificação é feita no mundo real pela entidade emissora de certificados. Este é o segundo passo para a emissão de um certificado digital. Com os dados conferidos, a entidade emissora de certificados (ou Carlos) emite um certificado para Beto. Esta etapa é a terceira e última etapa executada para a emissão de um certificado digital. Alice confia em Carlos. Numa ICP chamamos isto de relação de confiança. Alice possui uma relação de confiança com Carlos, quer dizer que se Carlos assina algo, Alice acredita que aquilo é verdade. Alice pega o certificado de Beto, verifica se os dados não foram alterados, verifica se o certificado é genuíno e verifica quem assinou. Se todas as verificações obtiveram sucesso e quem assinou o certificado possui uma relação de confiança com Alice, então Alice confia nesse certificado. Alice pergunta a Carlos se o certificado ainda é válido. Os certificados digitais podem ter o seu uso indevido, podem ser perdidos, ou outros problemas que inutilizem o certificado. Para saber quais certificados estão válidos, e quais não estão, a entidade emissora de certificados possui um Lista de Certificados Revogados (LCR). Toda vez que Alice for assinar uma mensagem, ela verifica se este certificado está na LCR. Se estiver Alice sabe que este certificado não é mais válido, e o detentor da chave privada pode não ser Beto. Para facilitar a divisão de trabalhos, e aumentar a segurança, as entidades emissoras de certificados são divididas em duas autoridades: 1. Autoridades de Registro (AR) - Quando é feita uma requisição, esta é a autoridade que verifica se os dados são verdadeiros. Esta autoridade somente faz as verificações, ela não consegue emitir certificados. 2. Autoridade Certificadora (AC) - Esta autoridade é quem emite o certificado. Uma AC somente pode emitir um certificado após a requisição de emissão de um certificado ser aprovado por alguma AR confiável. Uma AR confiável é uma AR que possui uma relação de confiança com alguma outra entidade. Uma relação de confiança igual a que existe entre Alice e Carlos. Com isto, percebemos que uma ICP é baseada totalmente em relações de confiança. Um programa SGC basicamente terá que ter as seguintes características: Deve permitir que sejam gerenciados os certificados (emitir e revogar certificados) Deve armazenar de forma segura as informações referentes aos certificados (válidos ou não), e as LCRs Deve possuir a capacidade de publicar os certificados válidos e as LCRs. Deve impedir o acesso à chave privada da entidade aonde o programa está instalado. Este programa muito provavelmente será o único que terá acesso ao local aonde está armazenada a chave privada da entidade.

4 3. Construindo um SGC A tarefa de construir um SGC pode parecer muito simples, porém alguns requisitos são necessários para ter-se um bom SGC. A seguir será apresentado um SGC já existente, com alguns problemas. Após será feita uma proposta de mudanças para aumentar alguns aspectos como segurança, manutenibilidade, etc O Primeiro SGCi Nesta seção será feito um estudo de caso sobre um SGC, o Sistema de Gerenciamento de Certificados Digitais ICPEDU(SGCi). Este SGC foi desenvolvido através de uma parceria ente as equipes do Laboratório de Segurança em Computação(LabSEC) da Universidade Federal de Santa Catarina(UFSC), Laboratório de Criptografia Aplicada (LCA) da Unicamp e o Laboratório de Computação Científica(LCC) da Universidade Federal de Minas Gerais(UFMG). Este sistema foi desenvolvido para ser o mais flexível possível na implantação e no gerenciamento de uma ICP. Este sistema pode gerenciar uma ICP aonde todas as entidades (ACs e ARs) estejam no mesmo computador, ou em computadores separados. No segundo caso, cada computador deverá ter uma cópia do SGCi rodando, e cada computador irá gerenciar a sua entidade somente. Este requisito de projeto é algo muito interessante, pois poderíamos ter uma AC em cada universidade do país, e uma AC-Raiz que seria de confiança de todas essas ACs. Assim um certificado emitido para um aluno da universidade A, seria considerado confiável para um aluno da universidade B. Outro requisito deste projeto, é a disponibilização do programa para livre utilização no meio acadêmico. Para isto o SGCi foi todo desenvolvido com softwares livres, e o seu código-fonte é público. O SGCi está dividido em 3 módulos-componentes: Módulo Público - Neste módulo os usuários geram as requisições e estas são enviadas ao módulo gestor. Módulo Gestor - Este módulo gerencia toda a administração das ACs e ARs. Diretório Público - É uma espécie de banco de dados especializado em buscas, aonde são armazenados os certificados emitidos e as LCRs. Este artigo irá se focar no módulo gestor, pois este é o módulo que realiza a gestão das entidades. A Figura 2 representa o funcionamento do SGCi. A operação de emissão de um certificado seria realizada pela seguinte seqüência: 1. O usuário entra com seus dados no módulo público 2. O módulo público gera uma requisição e envia para a AR que o usuário selecionou. 3. O operador da AR verifica se os dados da requisição estão corretos. Se os dados estiverem corretos, a requisição é aprovada, assinada e enviada para a AC. Se houver algum problema, a requisição é rejeitada. 4. A AC então recebe a requisição assinada pela AR, emite o certificado, e o publica no Diretório Público. Já para revogar um certificados, os seguintes passos são feitos: 1. O operador da AR escolhe o certificado a ser revogado, e envia uma requisição assinada para a AC.

5 Figura 2. Exemplo da utilização de um Certificado Digital XXXXXXXXXXXXX FALTA REFERENCIAR O MANUAL DO SGCi 2. A AC recebe a requisição assinada pela AR, revoga o certificado e o adiciona na LCR. Esta será publicada (na maioria dos casos em datas pré-definidas) e armazenada no Diretório Público Análise do SGCi Durante alguns meses este programa foi avaliado e testado. O primeiro item a ser analisado, é a instalação do SGCi. A instalação não é automática, mas existe um manual com uma receita-de-bolo muito simples. Seguindo-se esta receita, a instalação ocorre facilmente! Porém, isto as vezes pode não ser tão simples para um usuário leigo. O projeto possui requisitos de flexibilidade muito interessantes, descritos anteriormente, e o SGCi tentou fazê-los de forma automática. Isto muito facilmente pode se tornar um problema, imagine a situação da Figura 3. Uma AR está configurada num SGCi rodando no computador A, enquanto uma AC está configurada em outro SGCi, que está rodando no computador B. A máquina B está protegida por um firewall (software que controla os dados que entram e saem do computador através da rede) que bloqueia qualquer tentativa de conexão remota (esta é uma configuração típica de um firewall). Figura 3. Funcionamento do SGCi em máquinas diferentes Em algum determinado momento uma requisição é enviada para o computador

6 A. Este verifica os dados, e aprova a requisição. O passo seguinte é enviar a requisição assinada para a AC. O SGCi tenta automatizar este procedimento fazendo uma conexão remota ao computador B, e adicionado a requisição no computador B. Porém, como o computador está protegido por um firewall, esta conexão irá ser bloqueada, acabando com a tentativa do SGCi em automatizar essa operação, além de gerar um erro. Uma possível solução para este problema, seria reconfigurar o firewall para aceitar conexões remotas a partir do endereço IP do computador A (um endereço IP é um número que identifica aquela máquina, no mundo real seria como o endereço da casa de alguém). Isto resolveria o problema, agora o computador B aceita as requisições enviadas pelo computador A. Porém criaria uma outra grande falha de segurança! Um atacante poderia se passar pela máquina A (mudando o seu IP, para ser igual ao do computador A), e efetuar conexões remotas ao computador B. Outro problema causado por essa automatização é explorando-se uma falha no firewall, poderia ser enviada qualquer requisição ao sistema (e o mesmo iria aceitar). Inclusive, poderiam ser enviadas requisições inválidas que causariam comportamentos indesejáveis ao SGCi. A única forma de automatizar com segurança este processo seria tendo as entidades (ACs e ARs) no mesmo computador, algo que está perfeitamente implementado no SGCi. Só que esta situação acontece muito raramente nas ICPs! Ao serem realizados os testes das funções básicas do sistema (com ARs e ACs no mesmo computador) ele se comportou muito bem. Com os testes básicos realizados, foi criado um plano de testes com mais de 90 testes que deveriam ser realizados para testar exaustivamente as funções do programa, afim de encontrar o maior número de erros possíveis. Dos 90 testes, o SGCi passou em pouco mais do que 30 testes, sendo encontrado mais de 80 erros! Como o SGCi é um software de código-fonte aberto, foi verificado o seu código para encontrar os erros, na tentativa de solucioná-los. Mais detalhes sobre os erros encontrados podem ser vistos em: br/sgci/query?status=new&status=assigned&status=reopened&status= closed&version=1.3.0&type=erro&order=priority Todos os problemas citados acima (assim como os que não foram citados) foram resolvidos com sucesso, analisando e alterando o código-fonte do programa. Porém, uma grande dificuldade surgiu quando foram encontrados trechos de código duplicados. Esses trechos eram praticamente iguais, exceto que um tinha uma linha escrito AC e outro escrito AR, por exemplo. Esta é uma prática comum em programas estruturados, e seria facilmente resolvida se fosse utilizado como paradigma de programação a Orientação a Objetos (OO). Outra falha foi descoberta, esta sendo extremamente grande na questão de segurança. Manter a chave privada segura! No SGCi, para fazer o download da chave privada de alguma entidade basta saber qual o código da entidade no banco de dados (se não souber pode ir por tentativa e erro). Isto acontece devido aos diretórios aonde são gravadas as chaves, os certificados e outros dados da entidade estarem em subdiretórios que podem ser acessados pela internet. Imagine que uma certa AC, foi cadastrada no banco

7 de dados com o código 5. E o IP da máquina aonde está este sistema é Para pegar a chave privada desta AC bastaria ser digitado o seguinte endereço em algum navegador: A Figura 4 mostra ao lado esquerdo a estrutura de diretórios utilizada pelo SGCi, e ao lado direito o conteúdo do diretório chave. Qualquer dos diretórios mostrados na Figura 4 pode ser acessados através de um navegador de internet. Figura 4. Estrutura de diretórios do SGCI e o conteúdo da pasta chave Partindo-se para a análise do Bando de Dados, foi verificado que a estrutura do banco estava muito boa. Mas, se fosse adicionado qualquer funcionalidade ao sistema, muito provavelmente o banco teria que sofrer muitas modificações SGCi 2.0 Com o intuito de resolver todos os problemas apresentados anteriormente, e adicionar algumas funcionalidades ao SGCi, resolveu-se criar uma nova versão. Uma versão que não seria necessariamente compatível com a versão anterior. Algo como se fosse começar um software do início, porém utilizando as experiências boas que a versão anterior deixou. Para isto, foram definidos vários requisitos, que serão apresentados neste momento. Documentação Total Um dos requisitos mais simples para quem programa, é documentar o código. Todos os programadores sabem que a documentação de um programa é muito importante. Mas, nem sempre isso acontece no dia-a-dia. Então, foi determinado que a nova versão do SGCi terá o planejamento, desenvolvimento e os testes completamente documentados. Modularização e facilidade de manutenção do programa Acredita-se que este sistema seja um sistema que irá crescer muito nos próximos anos, tornando-se um programa reconhecido nacionalmente. Como todos os outros programas que cresceram sofreram várias modificações, com o SGCi deverá acontecer o mesmo. Para cumprir este requisito o SGCi será dividido em vários pequenos módulos. Estes módulos terão um comportamento padrão em relação à comunicação com os outros módulos. Se algum dos módulos for ruim ou tiver problemas, ele poderá ser facilmente

8 subtituído por outro módulo, bastando apenas que o novo módulo apresente o mesmo padrão de comunicação que o módulo anterior. Atualmente é utilizado o banco de dados PostgreSQL. Se por algum motivo no futuro este banco deixar se ser utilizado, e passar a ser utilizado o MySQL, bastará criar um novo módulo para o SGCi que converse com o MySQL, e trocá-lo pelo módulo que oferecia suporte ao PostgreSQL. O resto do sistema irá funcionar perfeitamente sem necessitar de nenhuma mudança. O mesmo vai acontecer com a interface gráfica, com o módulo público, com o diretório público, e outras partes. Este requisito irá ser muito útil tanto para a manutenção do programa (correção de erros), como para adicionar novas funcionalidades ao SGCi no futuro. Para se ter garantia que no futuro o sistema comporte novas funcionalidades, deverá ser dada bastante atenção ao banco de dados. Afinal, é aonde os dados são armazenados, e se o banco de dados não tiver uma certa flexibilidade, muitas novas funcionalidades não poderão ser implementadas. Suporte a vários modos de operação Uma ICP pode se comportar de dois diferentes modos de operação. A Figura 5 mostra estes modos. Figura 5. Modos de operação de um ICP No primeiro modo, um usuário envia uma requisição à AR. A AR verifica os dados, assina a requisição e envia para a AC. A AC emite o certificado, devolve para a AR, e a AR envia o certificado ao usuário. No segundo modo, um usuário envia uma requisição à AC. A AC envia a requisição para a AR, a AR verifica os dados, assina a requisição e envia para a AC. A AC emite o certificado, e o envia ao usuário. No primeiro modo o certificado é gerado na AC, e enviado à AR. No segundo modo o certificado é gerado na AC, mas não é enviado à AR. Cada modo de operação possui as suas vantagens e desvantagens. Quem vai implementar a ICP deverá escolher qual será o modo como o SGCi vai se comportar. Para incorporar estes 2 modos de operação, a automatização da comunicação feita entre as entidades, deverá ser totalmente nula. Fazendo esta comunicação manual-

9 mente, além de poder utilizar o mesmo sistema para operar de 2 modos distintos, ganha-se em segurança, pois não haverá a necessidade de fazer acessos remotos (conforme descrito anteriormente). Maior segurança possível A nova estrutura de diretórios será a estrutura que é apresentada na Figura 6. Podemos notar que os diretórios aonde ficam salvos os arquivos (chaves, certificados, etc) não são visíveis ao servidor web (apache), pois a única pasta visível é a public html. Sendo assim, o acesso a esses arquivos utilizando apenas um navegador de internet torna-se praticamente impossível. Esta é a forma mais simples de resolver o maior problema de segurança existente no SGCi anterior. Figura 6. Nova Estrutura de diretórios do SGCi Facilidade de instalação, configuração e utilização A instalação do sistema será a mais simples possível, não sendo necessário digitar vários comando manualmente, como era feito no SGCi anterior. A configuração das opções do SGCi também poderão ser feitas através de um programa muito simples de utilizar. Quando o sistema for instalado será necessário escolher uma senha para poder executar o utilitário de configuração do sistema. Além da senha, este utilitário de configuração somente poderá ser acessado na máquina aonde está instalado o SGCi. Esta medida foi tomada para impedir o acesso deste utilitário através da rede, mantendo o SGCi o mais seguro possível. Atualmente o sistema é muito fácil de utilizar, então este aspecto será mantido o mais parecido possível ao SGCi anterior. Inclusive se possível a interface gráfica será mantida a mesma.

10 Internacionalização do programa Como este projeto é acadêmico, as fronteiras interculturais devem ser removidas, forçando o SGCi a oferecer suporte a várias línguas. Para isto, basta criar um arquivo com as mensagens traduzidas, mudar algumas configurações e o sistema estará totalmente traduzido. Inicialmente o SGCi será disponibilizado em Inglês e Português. Programação Orientada a Objetos Como o paradigma de programação escolhido para a nova versão do SGCi foi Orientação a Objetos, todos os benefícios deste paradigma são adicionados ao programa, como herança, polimorfismo, padrões de projeto, etc. Isto irá facilitar a correção de erros que o sistema terá, e irá facilitar a manutenibilidade do SGCi. 4. Conclusão Os requisitos apresentados não são requisitos específicos ao SGCi. São requisitos de fundamental importância para todo e qualquer sistema de gerenciamento de certificados digitais. A idéia do SGCi é fazer um programa de gerenciamento de certificados com a maior qualidade possível. Sendo assim, toda a modelagem do programa será feita pensando nos requisitos citados anteriormente. Alguns requisitos demonstrados no decorrer deste artigo foram exemplificados utilizado as soluções encontradas pela equipe que irá desenvolver o SGCi Agradecimentos Referências Housley, R. and Polk, T. (2001). Planning for PKI - Best Practices Guide for Deploying Public Key Infrastructure. Wiley Computer Publishing, New York. ICPEDU (2005). GT - ICP-EDU Manual de Sistemas de Infra-Estrutura de Chave Públicas Educacional. Schneier, B. (1996). Applied cryptography: protocols, algorithms, and source code in C. Wiley Computer Publishing, New York, 2nd edition. Stallings, W. (2003). Cryptography and Network Security: Principles and Practice. Pearson Education, Upper Saddle River, NJ, USA, 3rd. edition.