Análise e implementação de um protocolo de gerenciamento de certificados

Transcrição

1 Análise e implementação de um protocolo de gerenciamento de certificados Anderson Luiz Silvério 1, Jonathan Gehard Kohler 1, Ricardo Felipe Custódio 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 {anderson.luiz, jonathan, custodio}@inf.ufsc.br Abstract. Public Key Infrastructures (PKIs) have constantly been used to solve problems in several kinds of applications. To enable interoperability between different components of PKIs, protocols that describe how the communication between these components should be made are used. The main contribution of this work is to propose improvements to the Certificate Management Protocol (CMP) and to implement these improvements in the Certificate Management System of the Educational Public Key Infrastructure (SGCI). Resumo. Infraestruturas de Chaves Públicas (ICPs) têm sido constantemente utilizadas para solucionar problemas em diversos tipos de aplicações. Para possibilitar a interoperabilidade entre os componentes das ICPs existem protocolos que descrevem como deve ser feita a comunicação entre tais componentes. Este trabalho tem como objetivo estudar e propor melhorias no Certificate Management Protocol (CMP) e implantar tais melhorias no Sistema de Gerenciamento de Certificados Digitais da Infraestrutura de Chaves Públicas para Ensino e Pesquisa (SGCI). 1. Introdução Certificados digitais, em conjunto com chaves criptográficas assimétricas, têm sido utilizados para identificar pessoas e equipamentos desde que foram propostos por Konfelder, em O certificado digital associa uma pessoa ou equipamento a um par de chaves. A chave privada é mantida sob controle da entidade identificada pelo certificado e a chave pública é distribuída através do próprio certificado. A gestão do ciclo de vida de certificados digitais é feita por uma infraestrutura de chaves públicas (ICP). Uma ICP é formada por vários componentes, cada um provendo algum serviço relacionado ao ciclo de vida de certificados digitais. Um exemplo de componente de uma ICP é a Autoridade Certificadora (AC), responsável pela emissão de certificados digitais. Para gerir os certificados digitais adequadamente os diferentes componentes de uma ICP necessitam se comunicar. Existem protocolos que descrevem como deve ser feita esta comunicação, como o CMP [Adams et al. 2005] e o CMC [Schaad and Myers 2008]. Estes protocolos descrevem quais as mensagens que devem ser trocadas entre os diferentes componentes da ICP em diferentes operações como, por exemplo, emissão de certificados digitais.

2 Para garantir a integridade e autenticidade destas mensagens, é necessário algum mecanismo de proteção para as mensagens. A assinatura digital é normalmente utilizada para suprir tais necessidades. Porém, no caso das autoridades certificadoras, o uso da chave privada é muito restrito e deve-se limitar apenas a assinar certificados digitais e listas de certificados revogados (LCRs). Além disso, o uso da mesma chave para dois propósitos distintos pode enfraquecer a segurança da chave ou dos serviços providos por ela [Barker et al. 2011]. Neste artigo é proposto a criação de um novo par de chaves, para ser utilizado para assinar as mensagens produzidas por ACs, eliminando o uso em demasia da chave privada da AC. Para a distribuição da chave pública deste novo par de chaves, são propostas alterações no protocolo CMP. Esta distribuição é chamada de relacionamento de confiança, um conceito utilizado pelo Sistema de Gerenciamento de Certificados Digitais ICPEDU (SGCI), para uma AC informar em quais Autoridades de Registro (ARs) ela confia e aceita receber requisições. Da mesma forma, uma AR informa para quais ACs ela pode enviar requisições e receber respostas. Na seção 2 é apresentada uma breve revisão bibliográfica sobre o SGCI e o Certificate Management Protocol (CMP). A seção 3 apresenta o conceito de chave de transporte, proposto por este trabalho para resolver o problema do uso da chave privada de Autoridades Certificadoras. Nas seções 4 e 5 são apresentadas as alterações propostas para o CMP, para suportar a distribuição da chave de transporte, e sua implementação, respectivamente. Na seção 6 são apresentadas as contribuições deste trabalho ao SGCI e, por fim, na seção 7 são apresentadas as considerações finais e propostas de trabalhos futuros. 2. Fundamentos Teóricos 2.1. Sistema de Gerenciamento de Certificados Digitais ICPEDU O Sistema de Gerenciamento de Certificados Digitais da Infraestrutura de Chaves Públicas para Ensino e Pesquisa (SGCI) é um software desenvolvido para o âmbito acadêmico, fazendo parte do projeto da Infraestrutura de Chaves Públicas para Ensino e Pesquisa (IC- PEDU), em uso em diversas universidades e centros de pesquisa brasileiros, provendo as funcionalidades necessárias para o gerenciamento de ICPs. Atualmente o Laboratório de Segurança em Computação (LabSEC) é responsável pelo desenvolvimento do SGCI. A Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEDU) consiste na implantação de uma infraestrutura de criação de certificados digitais e chaves de segurança dentro do ambiente das Instituições Federais de Ensino Superior (Ifes), Unidades de Pesquisa (UPs) e demais instituições de ensino. A utilização de certificados digitais confere credibilidade aos serviços e processos administrativos das instituições. Além disso, permite que processos sejam executados com maior eficiência e agilidade. [RNP 2011] 2.2. Certificate Management Protocol O Certificate Management Protocol (CMP) [Adams et al. 2005] é um protocolo utilizado para criação e gerenciamento de certificados digitais X.509v3 [Cooper et al. 2008] e define mensagens que permitem a interação de diferentes componentes de uma ICP. Toda mensagem definida pelo CMP possui uma estrutura básica, contendo os seguintes campos:

3 cabeçalho: Apresenta informações comuns a várias mensagens, utilizadas para identificar o emissor e destinatário, por exemplo; corpo: Apresenta informações específicas para cada requisição; proteção: Contém bits que protegem a mensagem. Por exemplo, a assinatura dos campos citados acima. Este campo é opcional; certificados extras: Pode ser usado para carregar certificados necessários por uma das partes. Este campo é opcional. O documento HTTP Transport for CMP [Kause and Peylo 2011] define como é feito o transporte das mensagens do CMP sobre o protocolo HTTP. 3. Geração do novo par de chaves Dos softwares pesquisados neste trabalho foi encontrado apenas um que suporta o CMP, o EJBCA [PrimeKey 2011]. Este utiliza a chave privada da AC para assinar as mensagens. Porém notou-se que o uso da chave privada da AC é muito restrito, idealmente limitandose apenas a assinar certificados e LCRs [ITI 2011]. Além disso, aumentando o uso da chave privada, sua segurança é enfraquecida [Barker et al. 2011]. Durante o processo de auditoria de uma AC, espera-se que a sua chave privada seja utilizada apenas uma vez durante cada operação. Por exemplo na emissão de certificado, para assinar o certificado emitido. E se a chave da entidade estiver sob algum mecanismo que controle o uso da mesma, como um módulo criptográfico, é provável que a chave será liberada para apenas um uso, tornando impraticável o uso da chave da entidade para também assinar as mensagens do CMP. Propõe-se então o uso de uma nova chave, chamada neste trabalho de chave de transporte. Neste trabalho é gerado um novo par de chaves para as ACs, cujo uso é exclusivo para assinar/verificar as mensagens do CMP. Dessa forma elimina-se o problema de utilizar a chave privada da AC duas vezes numa mesma operação (por exemplo, um uso para assinar um certificado digital e outro para assinar a resposta que será enviada à AR ou ao requerente do certificado). Como esta chave é utilizada apenas para assinar as mensagens enviadas pela AC, ela possui requisitos de segurança menores que os da chave privada da AC. E o seu comprometimento não implica no comprometimento da AC, não sendo necessário revogar o certificado da AC. Um atacante de posse da chave de transporte da AC não conseguirá emitir certificados em nome da AC, apenas irá gerar mensagens em nome da AC com conteúdo inválido que pode ser detectado pelo destinatário da mensagem. Por exemplo, um atacante pode gerar uma resposta para uma requisição de certificado, com um certificado inválido, não emitido pela AC ou com um certificado anteriormente emitido pela AC para outra entidade. Em ambos os casos o destinatário da mensagem pode verificar o certificado recebido e informar a AC que o mesmo não corresponde à requisição solicitada. 4. Melhorias no CMP Com o intuito de facilitar a distribuição da chave pública de transporte e tornar o CMP mais flexível, foram propostas algumas alterações no protocolo, descritas nas seções seguintes.

4 4.1. Relacionamento de confiança Com a adição do novo par de chaves para assinar as mensagens do CMP, foi também necessário alterar o CMP para que a chave pública deste novo par de chaves possa ser distribuída de forma segura e confiável. Esta alteração consiste em adicionar novas mensagens ao CMP, adicionando novos valores à estrutura PKIBody, descrita na RFC4210 [Adams et al. 2005, seção 5.1.2, p ]. Para o estabelecimento de relação de confiança, são propostos dois modelos: um assíncrono e outro síncrono. A seguir serão detalhados cada um destes modelos Modelo Síncrono No modelo síncrono há um par de mensagens: uma requisição e uma resposta. Uma entidade faz uma requisição de estabelecimento de relação de confiança e recebe a resposta para esta requisição. A requisição de relacionamento de confiança contém a estrutura TrustedRelReq, apresentada na figura 1. Ela contém o certificado da entidade requisitante e a chave de transporte. TrustedRelReq : : = SEQUENCE { c e r t i f i c a t e C e r t i f i c a t e, t r a n s p o r t P u b PublicKey } Figura 1. Estrutura TrustedRelReq em ASN.1 A resposta para a requisição de relacionamento de confiança contém a estrutura TrustedRelRep, apresentada na figura 2. Ela contém o status do pedido, descrito pela estrutura PKIStatusInfo do CMP [Adams et al. 2005], o certificado da entidade e a chave de transporte. Os dois últimos campos são opcionais e só deverão estar presentes caso a relação de confiança seja aprovada. TrustedRelRep : : = SEQUENCE { s t a t u s P K I S t a t u s I n f o c e r t i f i c a t e [ 0 ] C e r t i f i c a t e OPTIONAL, t r a n s p o r t P u b [ 1 ] PublicKey OPTIONAL } Figura 2. Estrutura TrustedRelRep em ASN.1 Com a requisição aprovada e a resposta recebida pela entidade requisitante, ambas as entidades possuirão a chave pública de transporte uma da outra e considera-se que a relação de confiança entre elas está estabelecida. É importante ressaltar que para garantir que a chave de transporte efetivamente pertence à entidade, é necessário que a mensagem seja assinada com a sua chave privada. Após o estabelecimento da relação de confiança, o restante das mensagens definidas pelo CMP podem ser assinadas com a chave de transporte Modelo Assíncrono Para o modelo assíncrono, apenas uma nova estrutura foi criada, apresentada na estrutura ASN.1 da figura 3.

5 TrustedRelAnn : : = SEQUENCE { c e r t i f i c a t e C e r t i f i c a t e, t r a n s p o r t P u b [ 1 ] PublicKey OPTIONAL pop [ 2 ] P r o o f O f P o s s e s s i o n OPTIONAL } P r o o f O f P o s s e s s i o n : : = CHOICE { only one p o s s i b i l i t y f o r now s i g n a t u r e [ 0 ] POPOSigningKey } Figura 3. Estrutura TrustedRelAnn em ASN.1 Ela contém o certificado da entidade, a chave de transporte e um campo para a assinatura. A assinatura é calculada a partir dos campos certificate e transportpub e serve para a entidade informar, de forma segura, a sua chave de transporte. A figura 4 apresenta a estrutura que contém a assinatura. Na proposta deste trabalho apenas os campos algorithmidentifier e signature são utilizados, contendo o algoritmo usado na assinatura e os bytes da assinatura, respectivamente. POPOSigningKey : : = SEQUENCE { p o p o s k I n p u t [ 0 ] POPOSigningKeyInput OPTIONAL, a l g o r i t h m I d e n t i f i e r A l g o r i t h m I d e n t i f i e r, s i g n a t u r e BIT STRING } Figura 4. Estrutura POPOSigningKey em ASN.1[Schaad 2005] Modelo Síncrono vs Modelo Assíncrono No modelo síncrono observou-se dois problemas: É necessário gerar uma nova mensagem a cada pedido de relacionamento de confiança e, consequentemente, utilizar a chave privada da entidade para assinar a mensagem várias vezes; Um atacante pode realizar pedidos de relação de confiança, com entidades falsas, à uma mesma entidade. Dessa forma, quando um operador da entidade for avaliar os pedidos de relação de confiança pendentes, poderão haver centenas de pedidos falsos e apenas um verdadeiro. O modelo assíncrono resolve estes problemas. O primeiro problema é resolvido com a assinatura sendo feita somente sobre o certificado e a chave de transporte da entidade. Como o certificado e a chave de transporte permanecem os mesmos, a estrutura pode ser assinada somente uma vez e anexada nas várias mensagens que a entidade possa gerar para cadastro de relação de confiança. O segundo problema é resolvido pois, no modelo assíncrono, uma entidade não faz um pedido de relação de confiança a outra entidade, ela cria uma espécie de lista com as entidades que ela confia e aceita receber mensagens. O modelo síncrono pode ser melhorado, utilizando-se a ideia de assinar com a chave privada da entidade somente o seu certificado e a chave pública de transporte e adicionando algum mecanismo de filtro para quais entidades podem realizar pedidos de relacionamento de confiança à uma determinada entidade. Esta última melhoria, no entanto, não faria parte do protocolo e necessitaria ser feita pelo software de gerenciamento de AC/AR. Por exemplo, na configuração da entidade, o usuário poderia informar que só

6 aceita receber requisições de relacionamento de confiança de entidades cujo certificado foi emitido por uma determinada AC. Por fim, a mensagem do modelo assíncrono pode ser utilizada no modelo síncrono para uma entidade divulgar uma nova chave pública de transporte para as entidades com as quais ela já estabeleceu relação de confiança previamente. Tal operação é importante caso a chave seja comprometida Codificação em XML Para tornar o CMP mais flexível, propõe-se o suporte do protocolo a outros tipos de codificação para suas mensagens. Neste trabalho optou-se por utilizar o formato XML, por ser amplamente utilizado atualmente para o compartilhamento de informações, além de ser de código aberto e independente de plataforma. A conversão das estruturas ASN.1 descritas na RFC4210 [Adams et al. 2005] para XML foram feitas utilizando as regras de codificação XML Enconding Rules (XER) [ITU-T 2001]. Também foi feita a conversão das estruturas ASN.1 do CMP para a linguagem XML Schema Definition (XSD) [W3C 2004]. O XSD permite fazer a validação da estrutura de um documento XML com base em determinadas regras. Dessa forma é possível verificar se dado documento XML representa uma mensagem válida do CMP. Como o XML e o XSD são linguagens independentes de plataforma, é possível utilizar as regras XSD criadas em qualquer implementação do CMP. 5. Implementação do protocolo Inicialmente foi feito um levantamento na literatura das bibliotecas já existentes que suportam o CMP. Foram encontradas duas bibliotecas, a cryptlib [Digital Data Security Limited 2011] e a cmpforopenssl [Martin Peylo 2011]. Foi desconsiderado o uso destas bibliotecas para este trabalho pelos seguintes motivos: são escritas na linguagem C. Desta forma seria ainda necessário portar as funcionalidades para o PHP, de modo a utilizar com o SGCI; não possuem suporte a XML. Não existindo nenhuma biblioteca que satisfaça as necessidades deste trabalho, foi criada uma nova biblioteca, orientada a objetos e em PHP. Um dos objetivos desta biblioteca é fornecer uma interface simples e independente, podendo ser utilizada por diferentes softwares. Além disso, ela foi concebida de forma a facilitar a adição de mensagens não tratadas por este trabalho ou fazer implementações customizadas das mensagens. 6. Contribuições ao SGCI Na atual versão do SGCI, 1.3.7, o protocolo de comunicação entre as entidades não é um protocolo padronizado, implementado apenas para satisfazer as necessidades do software no momento em que foi desenvolvido. Nesta implementação, a troca de mensagens entre as entidades é feita de forma offline, e necessita da interação de operadores que precisam primeiramente exportar as mensagens em uma entidade, para depois importar na entidade de destino. A partir deste trabalho, o SGCI passa a utilizar o CMP como protocolo de comunicação entre AC a AR e são adicionados dois novos modelos de comunicação. O

7 primeiro modelo é conhecido como modelo online com AC de resposta manual, cuja única diferença do modelo offline é que o envio das mensagens entre a AR e a AC é feita de forma automática. No segundo modelo, conhecido como modelo online com AC de resposta automática, além do envio das mensagens ser feito de forma automática, o seu processamento também é feito de forma automática. A vantagem do SGCI suportar diferentes modelos de comunicação é a possibilidade de ele poder ser usado por diferentes entidades com diferentes requisitos de segurança. Por exemplo, ACs Raízes normalmente têm requisitos de segurança elevados e funcionam de forma offline. Já ACs intermediárias, que emitem certificados para usuário final, e as ARs podem funcionar de forma online. A versão do SGCI, integrada ao protocolo CMP pode ser encontrada em https: //projetos.labsec.ufsc.br/sgci. 7. Considerações Finais Neste trabalho foi proposto o uso de um novo par de chaves por Autoridades Certificadoras, chamada chave de transporte, para assinar as mensagens do protocolo CMP. A existência desta chave de transporte elimina alguns problemas relacionados à restrição de uso da chave privada das ACs. A criação de um novo par de chaves gerou a necessidade de mecanismos para a sua distribuição. Foram propostos dois modelos para fazer a distribuição da chave pública de transporte: um síncrono e outro assíncrono. No modelo síncrono a chave privada da AC é utilizada sempre que for necessário fazer a distribuição da chave para uma nova entidade. No modelo assíncrono a assinatura é feita somente sobre a chave de transporte e o certificado da entidade, podendo ser gerada uma única vez e anexada a todas as mensagens. Também foi proposto o uso de XML para codificar as mensagens do CMP, pois o XML é uma linguagem amplamente utilizada para a troca de informações entre diferentes sistemas, além de ser simples de implementar e fornecer uma representação textual, legível para humanos. Para facilitar a geração e manipulação das mensagens do CMP, foi implementada uma biblioteca, na linguagem PHP, orientada a objetos, seguindo as práticas de programação de Desenvolvimento Orientado a Testes (TDD, do inglês Test Driven Development) e Clean Code, a fim de garantir uma alta qualidade no código desenvolvido. Por fim, a biblioteca implementada foi integrada ao SGCI, tornando-o compatível com o protocolo CMP e adicionando dois novos modelos de comunicação ao software. Como trabalho futuro, propõe-se um estudo de como fazer a geração da chave de transporte, de forma a associa-la com a chave pública da AC. Sendo possível verificar uma assinatura feita com a chave de transporte utilizando-se da chave pública da AC, tornaria o processo de distribuição da chave de transporte da AC mais simples. Também eliminaria a necessidade do uso da chave privada da AC para assinar a mensagem destinada à distribuição da mesma.

8 Referências Adams, C., Farrell, S., Kause, T., and Mononen, T. (2005). Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). RFC 4210 (Proposed Standard). Barker, E., Barker, W., Burr, W., Polk, W., and Smid, M. (2011). Recommendation for key management - pat1: General (revision 3). NIST Special Publication , National Institute of Standards and Technology. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard). Digital Data Security Limited (2011). Cryptlib security software. ITI (2011). Declaração de práticas de certificação da autoridade certificadora raiz da icp-brasil - v.4.1. DOC-ICP 01, Instituto Nacional de Tecnologia da Informação. ITU-T (2001). Information technology asn.1 encoding rules: Xml encoding rules (xer). Recommendation X.693, International Telecommunication Union. Kause, T. and Peylo, M. (2011). Internet X.509 Public Key Infrastructure HTTP Transport for CMP. Martin Peylo (2011). Cmp for openssl. PrimeKey (2011). Ejbca. RNP (2011). Infraestrutura de chaves públicas para ensino e pesquisa (icpedu). Schaad, J. (2005). Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). RFC 4211 (Proposed Standard). Schaad, J. and Myers, M. (2008). Certificate Management over CMS (CMC). RFC 5272 (Proposed Standard). W3C (2004). Xml schema part 1: Structures second edition. Recommendation, World Wide Web Consortium.