openssl x509 \
-in ca/root -ca.crt \ -out ca/root -ca.cer \ -outform der
3.3 Outra ferramentas
Além do OpenSSL, existem algumas outras ferramentas para a criação, manutenção e operação de PKIs. Em virtude do carater predominantemente corporativo, a maioria destas ferramentas é paga ou interna às empresas, dificultando sua avaliação. Esta seção trata de algumas das ferramentas consideradas mais relevantes, dentre as encontradas.
O OpenCA PKI Research Labs (58) possui o projeto OpenCA PKI, que tem, segundo a entidade, o objetivo de desenvolver uma autoridade certificadora robusta, de código aberto e com todas as funcionalidades necessárias. O projeto é baseado em vários outros projetos open source, incluindo o OpenLDAP, Apache Web Server, Apache mod_ssl e o próprio OpenSSL. A OpenCA PKI é implementada majoritariamente em Perl e seu site foi atualizado pela última vez em agosto de 2013. Não foi possível avaliar a ferramenta de forma mais profunda, pois houveram problemas na sua instalação. Ao que indica sua documentação, existe apenas uma interface administrativa via linha de comando, onde devem ser realizadas todas as operações.
A Symantec, uma das maiores empresas do setor de tecnologias de segurança, tem em seu portfólio um produto chamado Symantec Managed PKI Service (59). O serviço utiliza a própria infraestrutura de cloud da Symantec para armazenar os certificados e chaves dos clientes, mitigando a necessidade de servidores locais. Com interface web e ferramentas auxiliares, o produto promete simplificar a implantação e operação de uma PKI, facilitando, inclusive, a instalação dos certificados nos mais diversos dispositivos, como celulares e tablets. A integração com outros serviços típicos de redes corporativas, como LDAP e Active Directory, também é possível. Foi solicitada a avaliação gratuita por 90 dias, como informa o site do serviço, mas nenhuma resposta foi recebida, o que impossibilitou uma avaliação da usabilidade da ferramenta. Também não foi possível encontrar maiores informações sobre o custo da solução.
Duas outras empresas oferecem serviços semelhantes: a Comodo, através do Comodo Certificate Manager (60), e a Certified Security Solutions (CSS), com seu Certificate Management System (CMS) (61). Ambas são ferramentas online e também prometem integração com os serviços corporativos existentes. Como foi o caso com o Symantec
Managed PKI Service, aqui também não foi possível avaliar as interfaces com o usuário ou obter maiores informações sobre os custos das soluções.
Embora ciente da existência de soluções como a OpenCA PKI e os serviços online apresentados anteriormente, a utilização de um destes pouco agregaria, em termos de conhecimento, ao projeto de cooperação internacional SecFuNet, no qual esta dissertação está inserida, além de terem custos, no caso dos serviços, possivelmente impeditivos para o projeto. Por fim, o conhecimento adquirido pelo grupo durante o desenvolvimento deste trabalho é deveras importante para a disseminação da área no Brasil.
4 mPKI
Neste capítulo apresentaremos a proposta da mPKI, discutindo os requisitos da ICP-Brasil, quais são mais relevantes para este trabalho e a especificação dos requisitos da mPKI. Este capítulo procederá da seguinte forma:
• Discutimos alguns dos requisitos da ICP-Brasil que não são de natureza técnica e seu impacto sobre os custos de implantação e operação de uma PKI (Seção 4.1) e • Especificamos os requisitos da mPKI, de forma a reduzir muitos destes custos,
mantendo um nível de segurança adequado à maior parte dos cenários propostos (Seção 4.2).
4.1 Normas da ICP-Brasil
As normas da ICP-Brasil versam sobre requisitos técnicos e processuais para emissão e utilização de certificados digitais, válidos e aceitos no âmbito dos serviços eletrônicos oferecidos pelas diversas instâncias e entidades do governo brasileiro. Muitos dos requisitos técnicos foram discutidos na Seção 2.6, ficando a cargo desta seção expor alguns dos requisitos que não são de natureza técnica, mas sim processuais.
O DOC-ICP-05 (62) detalha como deve ser estruturada uma Declaração de Práticas de Certificação (DPC), documento este que deve ser elaborado pela CA que deseja integrar a ICP-Brasil e submetido à avaliação do ITI, quando do credenciamento desta. As normas permitem alguma flexibilidade, por parte das CAs, para que estruturem suas instalações físicas e procedimentos da forma que desejarem, desde que respeitados vários critérios de segurança física, procedimental e de pessoal. Um dos capítulos do DOC- ICP-05 define, por exemplo, quais são as formas de identificação e autenticação aceitas para emissão de certificados, tanto para pessoas físicas quanto para pessoas jurídicas e equipamentos/aplicações.
Nas questões relacionadas à operação lógica e física das CAs, o DOC-ICP-05 é bastante específico, exigindo, por exemplo, um mínimo de 6 níveis de segurança física, incluindo salas-cofre e proteção eletromagnética. São exigidos também segurança armada e monitoramento por câmeras, 24/7, retenção por um período mínimo de 1 ano, das gravações das câmeras, sensores de presença, controle de acesso biométrico, entre outros. Também é necessária a disponibilidade de geradores de emergência redundantes, nobreaks, sistemas de proteção contra incêndio, ar-condicionado redundante, trituração de documen- tos sensíveis, antes do descarte, etc. Além disso, quaisquer instalações de backup devem
atender rigorosamente aos mesmos critérios e estar aptas a, em caso de impossibilidade operacional da instalação principal, assumir totalmente as operações em até 48 horas.
Os documentos e requisitos da ICP-Brasil dizem respeito, portanto, não somente às plataformas e técnicas utilizadas na confecção, armazenamento e manutenção das chaves e certificados, mas também aos processos adotados pela autoridade certificadora, de forma a garantir a segurança da plataforma, a autenticidade dos documentos apresentados pelo requerente do certificado e sua legitimidade.
Nos moldes da ICP-Brasil, as únicas entidades capazes de emitir certificados são a AC-Raiz, as AC-1 e as AC-2. O credenciamento de qualquer uma destas entidades pressupõe toda sorte de requisitos e exigências técnicas e operacionais discutidas anteriormente, incorrendo em elevado custo.
Se uma empresa deseja emitir certificados digitais para seus funcionários, só pode fazê-lo, dentro da estrutura da ICP-Brasil, se credenciar-se como AC-2 ou mesmo AC-1. Pelos elevados custos de credenciamento e operacionalização, isto só se mostra economica- mente viável se esta pretender atuar como autoridade certificadora para fins comerciais. Para o propósito de identificar digitalmente seus funcionários e parceiros comerciais, pos- sibilitando a troca segura e confiável de documentos e mensagens, inclusive utilizando assinaturas digitais, basta que esta disponha de uma PKI e que as partes envolvidas nas comunicações confiem nesta entidade.
Por fim, a mesma Medida Provisória que criou a ICP-Brasil diz, no parágrafo 2o
do artigo 10:
§2o O disposto nesta Medida Provisória não obsta a utilização de outro meio
de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento.
Desta forma, é dispensada a necessidade de utilização de certificados da ICP-Brasil para que documentos assinados digitalmente sejam juridicamente válidos. Ainda se faz necessário, contudo, que toda a operação da PKI seja segura e confiável, desde a técnica e plataforma de geração das chaves criptográficas até os processos e operações, como, por exemplo, a verificação da autenticidade e legitimidade do usuário que solicita um certificado. Foge, porém, ao escopo deste trabalho especificar processos operacionais não-técnicos, ficando a cargo de cada entidade que deseje implantar a infraestrutura de chaves públicas proposta neste trabalho a definição dos requisitos que esta e seus parceiros julgarem suficientes para que a mPKI possa ser dita confiável e segura.
4.2 Especificação da mPKI
4.2.1 Arquitetura
A arquitetura da mPKI é composta por um servidor seguro e seus clientes, como mostra a Figura 3. Os clientes podem ser, basicamente, de dois tipos: clientes administra- tivos e serviços de terceiros. Os administrativos interagem com o servidor através de uma ferramenta administrativa, enquanto que os serviços de terceiros utilizam URLs públicas para obter as informações que desejam.
Para prover a segurança do servidor, é proposta a utilização de um dispositivo seguro, capaz de armazenar dados de forma segura. Da necessidade de trafegar dados de forma segura, sobre uma infraestrutura de rede insegura, advêm os canais seguros de comunicação indicados, na figura, por “1” e “2”, sendo somente o primeiro um canal autenticado. Esta autenticação deve ser, preferencialmente, forte, utilizando múltiplos fatores de autenticação.
Canal Seguro e Autenticado
Dispositivo Seguro Servidor da uPKI
Servidores/Serviços Externos Administradores da uPKI 1 2
Figura 3 – Arquitetura da mPKI
Adicionalmente, a interface de comunicação entre o servidor e a ferramenta de administração deve ser bem modelada e documentada, de forma a facilitar a construção e integração de novas ferramentas administrativas, ou mesmo a evolução das já existentes,
reduzindo o custo de operação destas PKIs através de interfaces mais intuitivas e adaptadas às necessidades das entidades que se proponham a opera uma mPKI.
4.2.2 Custo
A mPKI deve ter, também, um baixo custo de implantação e manutenção, tanto do ponto de vista do(s) hardware(s) quanto do(s) software(s) utilizado(s). Deve-se evitar servidores com alto custo de aquisição, operação ou manutenção. No custo de manutenção também deve ser considerado o custo energético, tendo em vista que a PKI deve estar sempre disponível e operacional.
Os procedimentos de segurança e proteção física do equipamento, tão específicos e custosos, dentro do contexto da ICP-Brasil, devem ser considerados pelas entidades, de forma a balancear os custos e o nível de segurança desejado/necessário. É recomendável a elaboração de um documento similar à Declaração de Práticas de Certificação, porém menos exaustivo, de forma a comunicar, às entidades parceiras, quais práticas são adotadas pela operadora da mPKI. É deixado à cargo das entidades parceiras a decisão sobre a adequação (ou não) dos procedimentos às suas realidades, culminando na decisão se as CAs credenciadas pela operadora da mPKI podem ser adicionadas às suas próprias árvores de confiança ou não.
4.2.3 Usabilidade
Como visto na Seção 3.2, é necessário dominar e conhecer uma diversidade de comandos, parâmetros e configurações, para criar e administrar uma PKI, se deseja-se utilizar apenas as ferramentas do OpenSSL. As ferramentas vistas na Seção3.3simplificam algumas destas operações e procedimentos, porém ainda exigem um conhecimento aprofun- dado sobre muitos dos aspectos envolvidos, por parte do administrador, para que possam ser utilizadas de forma apropriada. Além disso, o processo de instalação de algumas destas ferramentas se mostra complexo, o que dificulta sua adoção. Tendo em vista que o foco deste trabalho é a criação de uma PKI de baixo custo, onde aí está incluso o custo de manutenção e operação, usabilidade1 é um dos seus principais requisitos.
A mPKI deve ser de fácil administração, através de uma interface intuitiva, de forma a abstrair, sempre que possível, detalhes de configuração, opções e parâmetros. É fundamental, contanto, assumir valores seguros, sempre que uma opção ou configuração for omitida do usuário. Para facilitar a operação, a ferramenta deve prover configurações pré-estabelecidas para os perfis de certificado e assinatura mais comuns, como autoridades certificadoras, certificados de usuário (de assinatura ou encriptação), listas de revogação,
1 Por usabilidade entenda-se, aqui, facilidade de utilização, mas no contexto de um usuário avançado,
uma vez que muitas das operações e atividades exigem um conhecimento adequado dos conceitos envolvidos.
etc. Adicionalmente, deve ser possível criar novos perfis, facilitando a reutilização de configurações comuns e diminuindo as chances de erro.
É desejável que a ferramenta auxilie na criação dos CSRs, inclusive na seleção de seus atributos. Também é desejável o suporte ao uso de smartcards, preferencialmente automatizando (mesmo que parcialmente) o processo de instalação dos applets, geração das chaves e armazenamento dos certificados assinados dentro da memória segura do dispositivo.
Ao enfatizar a usabilidade da solução, temos aqui, obviamente, um trade-off entre facilidade de uso e expressividade/flexibilidade. Esta troca, contudo, nos parece aceitável, principalmente se considerarmos o contexto de aplicação desta solução e seu objetivo maior, que é o de disseminar e popularizar a utilização da criptografia de chave pública.
4.2.4 Segurança
Como mencionado na descrição da arquitetura da mPKI, propomos um único servidor, responsável tanto pelo armazenamento dos certificados assinados (repositório de certificados), quanto pela assinatura destes certificados. Este servidor é responsável, também, por armazenar as chaves privadas e certificados de todas as CAs intermediárias, criadas a partir da CA raiz da mPKI.
Um problema imediato de uma PKI centralizada é a possibilidade de que estas chaves sejam comprometidas, caso o sistema seja invadido. Uma possibilidade seria criptografar, com uma chave simétrica, todas as chaves privadas armazenadas. Neste caso, seria necessário entrar com estas chaves na inicialização do servidor. Se este processo for feito manualmente, será preciso intervenção de um administrador, a cada boot, para introduzir a chave, aumentando os custos de manutenção da mPKI. Se esta chave for armazenada localmente no servidor, por outro lado, não haveria ganho de segurança algum, pois esta também poderia ser comprometida, em caso de ataque. Desta forma, sugerimos que estas chaves sejam armazenadas em um dispositivo com memória protegida, ou, alternativamente, que apenas a chave decriptográfica (simétrica) seja armazenada nesta memória protegida, enquanto que as chaves privadas podem residir em um armazenamento convencional, desde que encriptadas 2.
No caso de um ataque físico, mesmo considerando que o atacante não consiga obter as chaves a partir da memória protegida, ainda seria possível utilizar uma técnica como o ataque ’evil-maid’ (64), modificando o bootloader ou sistema operacional da mPKI para
2 O nível de proteção necessário precisaria ser analisado mais aprofundadamente, em trabalhos futuros.
Impedir que um grupo de hackers ataque remotamente o sistema, ou que um ladrão comum e seus comparsas, com um pouco mais de conhecimento técnico, consigam extrair as chaves do sistema parece ser um objetivo realista. Contudo, proteger o sistema de um atacante com acesso a equipamentos e ferramentas especialistas não é algo realizável, considerando as restrições do projeto. Segundo a taxonomia de (63), apenas a proteção contra atacantes Class I nos parece realista, no contexto deste trabalho.
obter as chaves, após o boot do sistema. Dado que os sistemas operacionais não possuem proteção contra ataques deste tipo, isto é perfeitamente realizável. O comprometimento do sistema, neste caso, teria sérias implicações, pois, considerando que fosse detectado, exigiria que todos os certificados já emitidos pela mPKI fossem revogados.
Existem, basicamente, três formas de se proteger contra este tipo de ataque. A opção inicial seria fabricar a mPKI como um dispositivo único e inviolável, porém isto vai de encontro a um dos objetivos deste trabalho, que é o de desenvolver uma solução de baixo custo. A segunda opção seria armazenar todo o sistema operacional, incluindo suas dependências, em uma memória protegida, o que também aumenta o custo da solução. Por último, e significativamente mais simples, existe a opção de implementar um mecanismo similar ao boot seguro (do inglês, trusted boot), onde o dispositivo de segurança que armazena as chaves em memória protegida é responsável, também, por verificar se os componentes do sistema em execução (bootloader, sistema operacional, arquivos de configuração, aplicações, etc) estão íntegros, antes de permitir acesso às chaves armazenadas.
Por fim, a proposta da mPKI considera que, para impedir o vazamento das chaves privadas das CAs (raíz e intermediárias), todas devem ser armazenadas única e exclusi- vamente na memória protegida do dispositivo seguro, não sendo aceita a importação de chaves privadas geradas externamente.
4.2.5 Outros requisitos
O proposto baixo custo da mPKI não deve comprometer em nada sua operação, mantendo-a capaz de realizar todas as funções tipicamente associadas a PKIs, como assinatura de certificados, revogação, distribuição das listas de certificados revogados, etc. Por motivos óbvios de segurança, faz-se necessário proteger as operações que modificam a base de certificados, i.e. assinar e revogar certificados. O mecanismo empregado para proteger estas operações deve balancear segurança e usabilidade, pois uma boa usabilidade também é um dos requisitos desta PKI.
Ainda sobre usabilidade, é fundamental que a mPKI ofereça funcionalidades adicio- nais que facilitem o desenvolvimento e integração de ferramentas administrativas, como formas de listar os certificados existentes, revogados, etc. Para reduzir a necessidade de um armazenamento específico para os certificados gerados, a mPKI deve, ela mesma, armazenar e distribuir os certificados, atuando como um repositório centralizado de certificados e chaves públicas. Com a popularização do protocolo OCSP como meio de validação de certificados, é desejável que a mPKI implemente o protocolo, funcionando como um OCSP
Responder. Por fim, um gerador de números aleatórios seguro é recomendado, para que
5 DESIGN E IMPLEMENTAÇÃO
Neste capítulo, descrevemos nosso trabalho em implementar um protótipo da mPKI, de onde podemos extrair as seguintes contribuições:• Argumentamos que a Rasberry Pi, associada a um TPM, constituem uma boa opção de plataforma de hardware para a implantação, operação e manutenção da mPKI (Seção 5.1).
• Descrevemos a implementação de um protótipo da mPKI nesta plataforma (Seção 5.2).
• Apresentamos alguns testes de segurança realizados e os resultados obtidos (Seção 5.3).
5.1 Design
Nesta seção, discutimos os motivos das principais decisões de projeto desta im- plementação, a saber, a utilização da Raspberry Pi, como plataforma de hardware, de um TPM, como dispositivo seguro, e do protocolo SSL/TLS como meio de proteger a comunicação entre as diversas entidades e o servidor.
5.1.1 Raspberry Pi
A escolha da Raspberry Pi se deu por 5 fatores principais: baixo custo, baixo consumo de energia, capacidade de processamento, existência de uma distribuição Linux compatível e disponibilidade de periféricos/drivers.
Sendo uma das principais características deste trabalho, o baixo custo e consumo de energia da Raspberry Pi foram fatores preponderantes. Com um custo de aproximadamente U$ 40,00, dimensões mínimas1 e potência de aproximadamente 6 watts (9), este micro-
computador se adequou bem à proposta deste trabalho.
Além do baixo custo, outro fator considerado foi sua capacidade de processa- mento, dados os custos computacionais das operações de criptografia. Seu SoC2 Broadcom
BCM2835 (65) inclui um ARM11(66) com unidade de ponto flutuante, com clock de 700 MHz (9). Apesar de ser mais lento que os processadores encontrados nos desktops disponíveis atualmente3, os testes iniciais indicaram tempos aceitáveis para as operações 1 85.60mm x 56mm x 21mm
2 do inglês, System on Chip
criptográficas, utilizando a biblioteca OpenSSL. O processo de geração de chaves, con- tudo, foi bastante afetado, chegando a levar 10 vezes mais tempo4 que em um desktop
convencional.
Não menos importante, a existência de uma distribuição Linux compatível sinalizou positivamente para a escolha do Raspberry Pi como plataforma alvo deste trabalho. O Raspbian (67) é um port do Debian para a plataforma ARM do Raspberry Pi. Com um vasto repositório de módulos, bibliotecas e ferramentas também portadas para o Raspberry Pi, utilizar esta distribuição simplificou bastante o desenvolvimento do protótipo. Ferramentas fundamentais como GCC, Python e OpenSSL são facilmente instaláveis através do gerenciador de pacotes incluído no Raspbian.
Por fim, a variedade de interfaces da Raspberry Pi facilitam sua integração em infra-estruturas e dispositivos auxiliares. É possível conectá-lo em uma rede através de sua placa de rede on-board ou utilizando um dos vários dongles Wi-Fi USB compatíveis, permitindo que este dispositivo se integre facilmente a qualquer infra-estrutura de rede. Em caso de problemas no acesso remoto ao dispositivo, ainda é possível conectá-lo a um monitor, através de sua interface HDMI e operá-lo localmente, com mouse/teclado USB. A interface USB pode ser utilizada, ainda, para conectar um leitor de smartcards ou biométrico e aumentar ainda mais a segurança local da solução. Finalmente, sua interface I2C permite a comunicação com os mais diversos dispositivos para sistemas embarcados, entre eles o TPM SLB-9645 da Infineon (68), que foi utilizado neste protótipo.
5.1.2 Dispositivo seguro
O requisito crítico de qualquer PKI é a segurança e proteção das chaves privadas utilizadas pelas CAs para assinar os certificados. Para proteger verdadeiramente estas chaves, é necessário termos um dispositivo seguro que suporte um processo de boot seguro5
e um nível razoável de proteção contra violações físicas. Se esta plataforma for, ela mesma, responsável por gerar os pares de chave das CAs, ela também deve ser capaz de gerar números aleatórios criptograficamente seguros.
Existem vários dispositivos que satisfazem estes requisitos, como o SAMA5D3 (At-