Thiago Augusto Ventura Lima
µPKI: uma infraestrutura de chave pública de
baixo custo
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2014
Thiago Augusto Ventura Lima
µPKI: uma infraestrutura de chave pública de baixo custo
ORIENTADOR: Prof. Djamel Sadok
RECIFE 2014
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Catalogação na fonte
Bibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758
L732p Lima, Thiago Augusto Ventura.
μPKI : uma infraestrutura de chave pública de baixo custo / Thiago Augusto Ventura Lima . – 2014.
94 f.: fig., tab.
Orientador: Djamel Fawzi Hadj Sadok.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, Recife, 2014.
Inclui referências e apêndices.
1. Segurança da informação. 2. Criptografia. 3. Autenticação. I. Sadok, Djamel Fawzi Hadj. (Orientador). II. Titulo.
Thiago Augusto Ventura Lima
uPKI: uma infraestrutura de chave-pública de baixo custo
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação.
Aprovado em: 10/09/2014
BANCA EXAMINADORA
__________________________________________
Prof. Dr. Djamel Fawzi Hadj Sadok (Orientador)
Centro de Informática / UFPE
__________________________________________ Prof. Ramide Augusto Sales Dantas
Instituto Federal de Pernambuco
___________________________________________ Prof. Dr. Edson Barbosa Lisboa
A criptografia de chave pública desempenha um importante papel na autenticação e privacidade na internet tal qual a conhecemos. Suas aplicações incluem, por exemplo, e-commerce, internet banking, VPNs corporativas, escrituração eletrônica, identidade digital, entre outras. Todavia, a adoção de uma PKI como plataforma fundamental de segurança requer habilidades técnicas específicas, processos operacionais complexos e considerações legais importantes. Esse tipo de solução requer a construção e manutenção constante da entidade responsável por gerenciar as chaves e assinar os certificados digitais. Esta dissertação examina os desafios de construir uma estrutura de PKI de baixo custo que possua as principais funções das PKIs convencionais, sem incorrer, contanto, nos extensos requisitos técnicos e simplificando, à medida do possível, os processos operacionais necessários para gerir tal solução. Um protótipo foi construído como prova de conceito, de forma a demonstrar a exequibilidade de tal proposta. Tal protótipo faz uso da pla-taforma embarcada Raspberry Pi e de uma aplicação cliente-servidor para simplificar a operacionalização da mPKI.
The public-key cryptography plays an important role in the authentication and data privacy of the internet as we know it. Its applications include, but are not limited to, e-commerce, internet banking, corporate VPN connectivity, electronic bookeeping, digital identity among others. Nonetheless, adopting PKI as the underlying security platform requires special technical skills, intricate operational processes as well as important legal considerations. Such solution requires building and constant maintaining of the entity responsible for key management and digital certificates signing. This dissertation examines the challenges for building a low cost PKI structure that provides the main functions of existing conventional ones, without incurring, though, in the extense technical requirements and simplifying, as much as possible, the operational processes needed to manage such solution. A proof of concept prototype has been built to demonstrate the feasibility of such endeavor. This prototype makes use of the embedded platform known as Raspberry Pi, as well as a client-server application custom built to simplify the operation of the mPKI. Keywords: Security. Authentication. Secure element. Cryptography.
Figura 1 – SecFuNet - Arquitetura conceitual . . . 25
Figura 2 – Diagrama da ICP Brasil . . . 26
Figura 3 – Arquitetura da mPKI . . . 47
Figura 4 – Protótipo da mPKI: instanciação da arquitetura . . . 55
Figura 5 – Plataforma de hardware . . . 56
Figura 6 – Protótipo da mPKI . . . 56
Figura 7 – Login . . . 70
Figura 8 – Certificados válidos . . . 71
Figura 9 – Certificado e cadeia de certificação . . . 72
Figura 10 – Certificate Revogation List (CRL) . . . 72
Figura 11 – Assinatura de certificado . . . 73
Figura 12 – Revogação de certificado . . . 74
Figura 13 – Criação de uma nova CA . . . 74
Figura 14 – Topologia da rede utilizada nos testes . . . 76
Código 2.1 – Certificado X.509v3 . . . 21
Código 3.1 – Estrutura de diretórios de uma CA . . . 35
Código 3.2 – Exemplo de um arquivo de configuração do OpenSSL . . . 37
Código 3.3 – Requisição de assinatura de certificado (CSR) . . . 40
Código 3.4 – Assinatura de um certificado . . . 41
Código 3.5 – Cadeia de certificação . . . 41
Código 3.6 – Revogação de certificado . . . 42
Código 3.7 – Lista de certificados revogados (CRL) . . . 42
Código 3.8 – Credencial no padrão PKCS#12 . . . 42
Código 3.9 – Codificação DER . . . 43
Código 5.1 – Exemplo de login . . . 57
Código 5.2 – Exemplo de lista de perfis . . . 58
Código 5.3 – Exemplo de certificados válidos . . . 59
Código 5.4 – Exemplo de certificados revogados . . . 60
Código 5.5 – Exemplo de detalhes do certificado . . . 60
Código 5.6 – Exemplo de revogação de certificado . . . 62
Código 5.7 – Exemplo de dados do certificado . . . 64
Código 5.8 – Exemplo de CRL . . . 65
Código 5.9 – Exemplo de cadeia de certificação. . . 66
Código 5.10–Exemplo de certificados descendentes . . . 67
Código 5.11–Exemplo de assinatura de certificado . . . 68
Tabela 1 – Descrição dos campos do certificado X.509v3. . . 22
Tabela 2 – Geração de chaves assimétricas . . . 29
Tabela 3 – Combinações de algoritmos de assinatura . . . 29
Tabela 4 – Extensões obrigatórias . . . 30
Tabela 5 – Subject Alternative Name . . . 31
Tabela 6 – Descrição dos diretórios . . . 36
Tabela 7 – openssl.cnf: seções obrigatórias . . . 39
Tabela 8 – openssl.cnf: parâmetros . . . 40
Tabela 9 – openssl.cnf: extensões . . . 40
AA Attribute Authority
ACT Autoridade Certificadora do Tempo AIK Attestation Identity Key
AR Autoridade de Registro
ASN.1 Abstract Syntax Notation One BER Basic Encoding Rules
CA Certification Authority CBC Cipher Block Chaining
CN Commmon Name
CRTM Core Root of Trust for Measurement CP Certification Policy
CRL Certificate Revogation List CSP Certification Service Provider CSR Certificate Signing Request CPS Certification Practice Statement DER Distinguished Encoding Rule DN Distinguished Name
DPC Declaração de Práticas de Certificação EK Endorsement Key
GCM Galois/Counter Mode HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICP ver PKI
LDAP Lightweight Directory Access Protocol OCSP Online Certificate Status Protocol OID Object Identifier
PCR Platform Configuration Register PEM Privacy Enhanced Email
PER Packet Encoding Rule
PKCS Public-key Cryptography Standard PKI Public-Key Infrastructure
RADIUS Remote Authentication Dial In User Service REST Representational State Transfer
RFC Request for Comments SSL Secure Sockets Layer TCG Trusted Computing Group TIS TPM Interface Specification TLS Transport Layer Security TPM Trusted Platform Module VPN Virtual Private Network
1 INTRODUÇÃO . . . 16 1.1 Motivação . . . 16 1.1.1 Appliances . . . 16 1.2 Objetivos . . . 17 1.2.1 Objetivos Gerais . . . 17 1.2.2 Objetivos Específicos . . . 17 1.3 Estrutura da dissertação . . . 17 2 CONTEXTUALIZAÇÃO. . . 19
2.1 Criptografia de chave pública . . . 19
2.2 Certificados . . . 20
2.3 PKI . . . 21
2.4 Online Certificate Status Protocol (OCSP) . . . 23
2.5 SecFuNet . . . 24 2.6 ICP-Brasil . . . 25 2.6.1 Entidades componentes . . . 26 2.6.2 Tipos de certificados . . . 27 2.6.3 Custo . . . 28 2.6.4 Padrões e algoritmos . . . 29
2.6.4.1 Geração de chaves e assinatura . . . 29
2.6.4.2 Criptografia simétrica . . . 29
2.6.5 Especificação dos certificados . . . 30
2.7 TPM . . . 32
2.8 Resumo do capítulo . . . 33
3 TRABALHOS E FERRAMENTAS RELACIONADAS . . . 34
3.1 Trabalhos relacionados . . . 34 3.2 OpenSSL. . . 35 3.2.1 Estrutura de diretórios . . . 35 3.2.2 Arquivos de configuração . . . 36 3.2.3 CSR . . . 40 3.2.4 Assinatura de certificados. . . 41 3.2.5 Cadeia de certificação . . . 41 3.2.6 Revogação de certificados . . . 41 3.2.7 Operações adicionais . . . 42 3.3 Outra ferramentas . . . 43
4.2 Especificação da mPKI . . . 47 4.2.1 Arquitetura . . . 47 4.2.2 Custo . . . 48 4.2.3 Usabilidade . . . 48 4.2.4 Segurança . . . 49 4.2.5 Outros requisitos . . . 50 5 DESIGN E IMPLEMENTAÇÃO . . . 51 5.1 Design . . . 51 5.1.1 Raspberry Pi . . . 51 5.1.2 Dispositivo seguro . . . 52 5.1.3 Segurança da comunicação . . . 53 5.2 Implementação . . . 54
5.2.1 Visão geral do produto . . . 54
5.2.2 Instanciação da arquitetura . . . 54 5.2.3 Servidor . . . 55 5.2.4 API de comunicação . . . 56 5.2.4.1 Login . . . 57 5.2.4.2 Profiles . . . 58 5.2.4.3 Certificados válidos. . . 59 5.2.4.4 Certificados revogados . . . 59 5.2.4.5 Detalhes do certificado . . . 60 5.2.4.6 Revogação de certificado . . . 62
5.2.4.7 Dados do certificado (raw) . . . 64
5.2.4.8 Certificate Revogation List (CRL) . . . 65
5.2.4.9 Cadeia de certificação . . . 66 5.2.4.10 Certificados descendentes . . . 67 5.2.4.11 Assinatura de certificado . . . 68 5.2.4.12 Criação de nova CA . . . 69 5.2.5 Ferramenta administrativa . . . 70 5.2.5.1 Login . . . 70 5.2.5.2 Base de certificados . . . 71
5.2.5.3 Salvar certificado, cadeia de certificação e CRL . . . 71
5.2.5.4 Assinar certificado . . . 73
5.2.5.5 Revogar certificado. . . 73
5.2.5.6 Criar nova CA . . . 73
5.2.6 Detalhes da implementação . . . 73
5.3 Teste de penetração . . . 75 5.3.1 Aquisição de informações . . . 76 5.3.2 Ataques personalizados . . . 77 5.3.3 Resultados e soluções . . . 77 5.4 Resumo . . . 77 6 CONCLUSÃO . . . 79 6.1 Problemas encontrados . . . 79 6.2 Trabalhos futuros . . . 80
6.2.1 Suporte ao protocolo OCSP . . . 80
6.2.2 Permissões e controle de acesso . . . 80
6.2.3 Auxílio à utilização de smartcards . . . 81
6.2.4 Suporte à criação de CSRs . . . 81
6.2.5 Concorrência e análise de desempenho . . . 81
6.2.6 Avaliar outras combinações de plataformas de hardware . . . 81
REFERÊNCIAS . . . 82
APÊNDICE A – TESTE DE PENETRAÇÃO - AQUISIÇÃO DE IN-FORMAÇÕES GERAIS . . . 88
APÊNDICE B – TESTE DE PENETRAÇÃO - AQUISIÇÃO DE IN-FORMAÇÕES SOBRE SERVIÇOS WEB . . . 90
1 INTRODUÇÃO
1.1 Motivação
A Infraestrutura de Chave Pública (ICP), também conhecida por Public-Key
Infrastucture (PKI), foi definida pela RFC 2828 (1) como um conjunto de hardware, software, pessoas, políticas e procedimentos necessários para criar, gerenciar, armazenar, distribuir e revogar certificados digitais baseados em criptografia assimétrica. O principal objetivo de desenvolver uma PKI é prover um meio seguro, conveniente e eficiente de distribuir chaves públicas.
Baseado nestas características de segurança e eficiência, o grupo de trabalho PKIX do Internet Engineering Task Force (IETF) (2) criou um modelo formal e genérico, baseado no X.509 (3), que possibilitou o desenvolvimento de uma arquitetura baseada em certificado para a Internet.
A arquitetura baseada em certificados é amplamente utilizada hoje em dia em atividades onde é necessário o estabelecimento de uma relação de confiança entre as entidades envolvidas no processo. Este processo de autenticação é utilizado, por exemplo, para o estabelecimento de conexões seguras (SSL/TLS) (4), assinatura digital e autenticação em servidores, entre outras atividades que necessitem da autenticação das partes envolvidas. O uso de certificados digitais é amplamente difundido em ambientes virtualizados uma vez que as instâncias das máquinas virtuais podem migrar de um servidor para outro. Este processo de migração deve ocorrer em um canal seguro de comunicação, seja através de uma Rede Privada Virtual (VPN), seja por um canal SSL/TLS. O projeto SecFuNet (Security for Future Networks) (5), onde esta dissertação está inserida, é um exemplo da utilização de certificados digitais em infraestruturas virtualizadas. Os objetivos e características do SecFuNet serão apresentados na Seção 2.5.
1.1.1 Appliances
É comum, no mercado de equipamentos para redes corporativas, a oferta de dispositivos conhecidos como appliances. Estes equipamentos são vendidos pré-configurados e com todos os componentes necessários ao seu funcionamento, simplificando a sua instalação e reduzindo o tempo necessário até que estejam, de fato, operantes. Existem diversos tipos de appliances, como servidores web, proxies, firewalls, sistemas de detecção de intrusão, filtros de spam, VPNs, etc.
A única solução de PKI completa encontrada, oferecida como um appliance, é a PrimeKey PKI Appliance (6), da empresa sueca PrimeKey. A ausência de outros
fornecedores, as características de alto desempenho da solução da PrimeKey e alguns valores encontrados na internet1 sugerem a existência de uma oportunidade comercial no
segmento das organizações de pequeno e médio porte, que pode ser atendida por soluções de custo reduzido. Um appliance de baixo custo poderia ser utilizado por estas organizações, interessadas em agregar a segurança proporcionada pela criptografia de chave pública, sem, contudo, incorrer nos elevados custos de aquisição de múltiplos certificados ou da operação e manutenção de uma PKI convencional.
1.2 Objetivos
1.2.1 Objetivos Gerais
Como objetivo geral, pretende-se diminuir os custos de aquisição, implantação, manutenção e operação de uma PKI, através do uso de plataformas de hardware de baixa potência e elementos seguros, sem por em risco a segurança da solução. Reduzindo os custos, diminui-se a barreira de entrada para que organizações de pequeno e médio porte utilizem criptografia de chave pública em suas operações diárias, contribuindo com a popularização destas práticas e processos de segurança.
1.2.2 Objetivos Específicos
1. Especificar e construir um protótipo de uma PKI de baixo custo, de implantação, manutenção e gerenciamento simples e intuitivo;
2. Utilizar softwares de baixo custo, preferencialmente de código-aberto;
3. Criar uma interface amigável, para a administração da mPKI, reduzindo a curva de aprendizado para utilização da solução e os custos com treinamentos de seus operadores;
1.3 Estrutura da dissertação
Os capítulos seguintes desta dissertação estão estruturados da forma que se segue. No Capítulo 2 introduzimos alguns dos principais conceitos utilizados nesta dis-sertação, como criptografia de chave pública, certificação digital e TPMs. Também são discutidas as principais características do SecFuNet e da ICP-Brasil, série de legislações e normas técnicas criadas pelo governo brasileiro para regulamentar o uso de certificados digital no âmbito dos serviços públicos.
1 Foram encontrados algumas propostas de serviço (7, 8) envolvendo equipamentos e serviços da
No Capítulo 3, revisamos o estado da arte, no contexto deste trabalho e do projeto de pesquisa no qual está inserido, o SecFuNet. Também descrevemos algumas das ferramentas existentes para a gestão e operação de PKIs.
No Capítulo 4 apresentamos 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. De forma resumida, 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. Tendo isto em mente, 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. O Capítulo 5, por sua vez, trata da implementação de um protótipo da mPKI, onde também argumentamos que a Rasberry Pi (9), associada a um TPM (10), constituem uma boa opção de plataforma de hardware para a implantação, operação e manutenção da mPKI.
Por fim, o Capítulo 6 traz as conclusões desta dissertação, problemas encontrados e sugestões de trabalhos futuros.
2 CONTEXTUALIZAÇÃO
Neste capítulo são introduzidos alguns dos principais conceitos utilizados nesta dissertação, como criptografia de chave pública, certificação digital e TPMs. Também são discutidas as principais características da ICP-Brasil, série de legislações e normas técnicas criadas pelo governo brasileiro para regulamentar o uso de certificados digitais no âmbito dos serviços públicos. Podemos listar, assim, as principais contribuições deste capítulo:
• Conceituamos a criptografia de chave pública, revendo seus principais conceitos (Seção 2.1);
• Discorremos sobre alguns dos pontos mais relevantes do conceito de certificação digital (Seção 2.2);
• Explicamos o que é uma infraestrutura de chaves públicas (PKI), resaltando suas principais características (Seção 2.3);
• Resumimos algumas das normas e requisitos técnicos da ICP-Brasil (Seção 2.6) e • Conceituamos o TPM, com suas características e aplicações (Seção2.7).
2.1 Criptografia de chave pública
A teoria por trás da criptografia de chave pública foi concebida em 1976, por Diffie e Hellman (11), porém só foi implementada com sucesso no ano seguinte, pelo sistema de criptografia RSA, criado por Rivest, Shamir e Adleman (12). Outros sistemas de criptografia sugiram, ao longo dos anos, como o Paillier (13), ElGamal (14), Cramer-Shoup (15) e o Merkle–Hellman (16).
Apesar de particularidades individuais, todos os sistemas de criptografia tem uma característica comum: dada uma chave de criptografia, é impraticável, do ponto de vista computacional, encontrar a sua chave de decriptografia correspondente. O mesmo é fato para a operação inversa (obter a chave de criptografia, a partir da sua chave de decriptografia) (17).
Esta propriedade possibilita que um usuário compartilhe sua chave de criptografia, de forma que outros possam utilizá-la para encriptar mensagens. As mensagens encriptadas por esta chave compartilhada só podem ser decriptografadas pela chave de decriptografia, que deve ser mantida protegida.
A utilização da criptografia de chave pública possibilita, ainda, a assinatura digital, provendo meios de atestar a autoria de documentos digitais. Para isto, é necessário que
uma mensagem conhecida por ambas as partes seja encriptada pela chave de criptografia, só podendo ser decriptografada pelo seu par. Neste caso, a abordagem é o inverso da situação discutida anteriormente: é necessário compartilhar a chave de decriptografia e manter secreta a chave de criptografia. Isto garante que o documento foi assinado pelo portador da chave de criptografia. Alguns sistemas de criptografia, como o RSA, permitem que ambas as chaves sejam utilizadas tanto para encriptar quanto para decriptar, o que simplifica o processo.
Do ponto de vista prático, a criptografia de chave pública é significativamente mais lenta que a criptografia de chave simétrica, o que levou a abordagens mais rápidas, como utilizar este tipo de criptografia apenas para proteger uma chave simétrica, que é, por sua vez, utilizada para encriptar a mensagem que se deseja, de fato, transmitir. Também é comum utilizar uma chave de criptografia simétrica para proteger a chave de decriptografia, dificultando a obtenção da chave de decriptografia, propriamente dita, mesmo no caso de comprometimento do dispositivo de armazenamento, por exemplo.
Pela natureza compartilhada/pública da chave de criptografia e protegida/privada da chave de decriptografia, é comum se referir às chaves como chaves pública e privada, respectivamente, termos que serão utilizados no decorrer de toda esta dissertação.
2.2 Certificados
De acordo com a RFC 2828 (1), um certificado é “A document that attests to
the truth of something or the ownership of something.” ou, numa tradução livre, “um
documento que atesta que algo é verdadeiro ou o proprietário de algo”. Originalmente, o termo era utilizado para identificar um registro, contento um nome e uma chave pública, assinado digitalmente. Assim, este certificado atestava a relação de posse entre uma entidade qualquer (pessoa, dispositivo, etc) e uma chave pública. Estes certificados são conhecidos como certificados de chave pública.
O certificado de chave pública é apenas um dos tipos de certificado digital descritos na RFC 2828, mais especificamente um certificado que “associa a identidade de uma entidade de sistema a um valor de chave pública e, possivelmente, à outras informações”. Isto é resumido por (18) como uma estrutura de dados assinada digitalmente que atesta a posse de uma chave pública.
Quanto à classificação dos certificados de chave pública, existem várias formas de fazê-lo, mais comumente dizendo respeito à qualidade do processo de registro, ao tipo de mídia utilizada para a geração e o armazenamento do certificado/chaves e às possíveis utilizações do certificado (19).
O certificado de chave pública pode, ainda, atestar a validade de atributos associados ao dono do certificado. Este tipo de certificado é chamado de certificado de atributos e
também é descrito na mesma RFC. Basicamente, a diferença entre o certificado de chave pública e o de atributos é que, enquanto o primeiro associa o nome de uma entidade à uma chave pública, o último associa uma entidade a um conjunto genérico de atributos.
Qualquer que seja o tipo de certificado, ele é emitido (e possivelmente revogado) por entidades/autoridades reconhecidas e confiadas por alguma comunidade de usuários. No caso dos certificados de chave pública, essas entidades são conhecidas como autoridades certificadoras (ou CAs, do inglês certification authorities), ou autoridades de atributos (ou AAs, do inglês attribute authorities). Existe ainda o termo CSP (do inglês certification
service provider), utilizado para se referir a qualquer entidade provedora de serviços de
certificação.
2.3 PKI
De uma forma geral, pode-se entender uma PKI (do inglês Public-Key Infrastructure) como uma ou mais CAs. Segundo a RFC 2828 (1), uma PKI é “um sistema de CAs que desempenham um conjunto de funções de gerenciamento de certificados, chaves e
tokens, além do armazenamento destes, para uma determinada comunidade de usuários”,
utilizando criptografia de chave pública. Uma outra forma de entender uma PKI é como uma infraestrutura que pode ser utilizada para emitir, validar e revogar tanto chaves públicas quanto certificados de chave pública. Por fim, uma PKI é um conjunto de padrões acordados entre as partes, CAs, métodos para descobrir e validar certificados, procolos de operação e gerenciamento, ferramentas e legislações que fundamentem tudo isso. Uma PKI e o serviço de certificação por ela provido devem ser especificados em uma política de certificação (CP, do inglês Certification Policy) e em um atestado de práticas de certificação (CSP, do inglês Certification Practice Statement) (20).
Muitas entidades trabalham no campo de certificados e PKI. De forma mais relevante, temos o trabalho do ITU-T (21), que publicou e atualiza periodicamente uma recomendação comumente conhecida como ITU-T X.509 (3), ou simplesmente X.509, atualmente em sua terceira versão. Estas recomendações foram adotadas por várias outras entidades, como a ISO/IEC JTC1. O Código 2.1 e a Tabela 1detalham a sintaxe de um certificado X.509v3, em notação ASN.1 (22).
Código 2.1 – Certificado X.509v3
Certificate ::=
SIGNED { SEQUENCE {
version [0] Version DEFAULT v1 , serialNumber CertificateSerialNumber , signature AlgorithmIdentifier , issuer Name , validity Validity , subject Name , subjectPublicKeyInfo SubjectPublicKeyInfo ,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL , - if present , version shall be v2 or v3 subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL ,
- if present , version shall be v2 or v3 extensions [3] Extensions OPTIONAL
- If present , version shall be v3 } }
Tabela 1 – Descrição dos campos do certificado X.509v3
Campo Descrição
version Um número de versão (identificando a versão 1, 2 ou 3 do certificado)
serialNumber Um número de série único, atribuído pelo emissor
signature Um identificador de objeto (OID, do inglês Object Identifier) que especifica qual algoritmo de assinatura foi utilizado para assinar o certificado de chave pública
issuer O Nome Distinto (DN, do inglês Distinguished Name) do emis-sor (CA) que assinou o certificado
validity O período que especifica o intervalo durante o qual o certificado é válido
subject O DN do indivíduo (o dono do certificado)
subjectPublicKeyInfo Informações relacionadas à chave pública do indivíduo (a chave e o OID do algoritmo)
issuerUniqueIdentifier Informação adicional e opcional, utilizada para identificar uni-camente um emissor, em caso de colisão de nomes (previsto apenas nas versões 2 e 3)
subjectUniqueIdentifier Informação adicional e opcional, utilizada para identificar uni-camente um indivíduo, em caso de colisão de nomes (previsto apenas nas versões 2 e 3)
extensions O campo de extensões permite a adição de novos campos à estrutura sem ser necessário modificar a estrutura definida em ASN.1. Uma extensão inclui um identificador de extensão, um indicador de criticidade e os dados associados, codificados em ASN.1. Este campo é compatível apenas com a versão 3 do X.509.
No que diz respeito ao atributo de criticidade das extensões, um sistema que faça uso de certificados X.509 deve rejeitar todo certificado que possua um extensão desconhecida, se esta for marcada como crítica. Extensões “não-críticas” podem ser ignoradas se não forem reconhecidas, mas, devem ser processadas, se reconhecidas (23). As entidades que decidirem definir novas extensões devem tomar cuidado ao criar novas extensões críticas, pois isto pode comprometer o intercâmbio destes certificados com outras entidades.
A serialização dos certificados X.509 pode ser feita de três formas padronizadas, através das regras de codificação conhecidas como BER (do inglês Basic Encoding Rules), DER (do inglês Distinguished Encoding Rule) e da PER (do inglês Packet Encoding Rule).
Esta padronização é necessária para que o certificado possa ser transmitido e interpretado corretamente.
O padrão X.509 utiliza um modelo de confiança hierárquico, muitas vezes chamado de árvore de confiança. Isto envolve a criação de algumas CAs raíz e seus respectivos certificados, que são ditos confiáveis por padrão. A partir destes certificados raíz, as árvores podem se ramificar, estendendo a seus filhos sua propriedades de confiabilidade. Os certificados raíz costumam ser auto-assinados, possuindo o mesmo DN1 como indivíduo e
emissor. Estes certificados, por si só, não dizem muito sobre a credibilidade das entidades, pois qualquer um pode criar e assinar seu próprio certificado. Seu valor reside, sobretudo, na comunidade em seu entorno, que confia em sua legitimidade. Após formar uma base de CAs raíz e seus respectivos certificados, um usuário pode tentar encontrar um caminho de certificação (ou cadeia de certificação, como também é conhecido), que leva de um certificado raíz confiável até o certificado apresentado pelo serviço ou usuário. Se um caminho existir, o certificado apresentado é dito confiável.
Formalmente, um caminho ou cadeia de certificação é definido dentro de uma árvore ou floresta de CAs (CAs raíz e intermediárias) e compreende uma sequência de um ou mais certificados que levam de um certificado raíz até um certificado folha. Cada certificado certifica a chave pública do seu sucessor, de forma que um caminho ou cadeia de certificação só pode ser verificado se todas as CAs contidas nele forem de confiança. Apesar de serem folhas destas árvores de confiança, o caminho de um certificado folha, normalmente associado a um usuário ou sistema, até sua CA raíz costuma ser pequeno (24).
Por ser uma especificação muito abrangente, os certificados X.509 possibilitam diversos usos. Esta flexibilidade, contudo, tem seu preço. A maioria dos grupos de usuário que se propõe a utilizá-lo costuma precisar de um novo perfil, onde define quais combinações de campos e valores são permitidas. Enquanto o padrão/especificação apenas define quais campos podem existir e como devem ser codificados, os perfis formalizam quais campos são obrigatórios, opcionais, excludentes, etc, bem como as relações entre seus valores. Várias entidades trabalham na criação de perfis do X.509 para aplicações específicas, como o grupo de trabalho PKI X.509 (PKIX) (2) da IETF (do inglês Internet Engineering Task
Force).
2.4 Online Certificate Status Protocol (OCSP)
Tradicionalmente, os participantes de uma comunicação segura validam os certifi-cados apresentados pelas partes através de consultas às suas listas de revogação locais, antes de estabelecer a comunicação. Estas listas precisam ser mantidas sincronizadas com
as listas específicas das diversas CAs da infraestrutura, o que impõe um trade-off entre a frequência de atualização destas e o consumo de banda, uma vez que estas listas nunca diminuem e apenas crescem com o tempo.
O OCSP é um protocolo utilizado para obter justamente o status de revogação de um determinado certificado digital. Definido na RFC 6960 (25), este protocolo foi concebido como uma alternativa a este modelo padrão de lista de revogação (CRL), focando especialmente nos problemas associados à distribuição destas listas.
Utilizando o OCSP, os participantes da comunicação solicitam a uma terceira parte, neste caso o servidor OCSP (ou OCSP Responder, como também é conhecido), informações sobre a situação do certificado apresentado pelo outro participante. O servidor OCSP, então, realiza uma busca em sua base local de certificados, verificando se o certificado ainda é válido, e retorna uma resposta apropriada, devidamente assinada com sua chave pública2.
2.5 SecFuNet
O objetivo do projeto SecFuNet é definir uma arquitetura segura que possa ser utilizada por provedores de infraestrutura virtual, na internet do futuro. Por provedores de infraestrutura virtual, entenda-se provedores capazes de oferecer a seus clientes a habilidade de instanciar elementos computacionais virtuais (redes e/ou sistemas) que compartilham recursos físicos. Estes clientes, por sua vez, podem oferecer serviços/aplicações (armaze-namento de arquivos, jogos, etc) para usuários finais interessados apenas em utilizar tais aplicações. Por questões se segurança e confiabilidade, estes ambientes devem garantir a integridade e confidencialidade dos dados de cada usuário. Além disso, a arquitetura deve prover serviços de autenticação com alta disponibilidade. Finalmente, considerando que os recursos físicos são compartilhados por vários usuários, a arquitetura deve garantir o isolamento dos elementos virtuais de seus usuários, de forma a não interferir com os outros usuários que compartilham o mesmo substrato físico. A Figura 1 ilustra a arquitetura conceitual do SecFuNet, onde podem ser vistos alguns de seus componentes e sua relação com as redes (e infraestruturas) físicas/virtuais.
O framework proposto pelo SecFuNet introduz os principais elementos necessário para prover as funcionalidades de segurança esperadas da internet do futuro. Este fra-mework comporta tanto serviços providos pelo provedor de infraestrutura quanto pelo seu cliente (provedor de serviços). Os serviços suportados pelo SecFuNet para o provedor de infraestrutura incluem o gerenciamento das redes virtuais, com suporte a criação, migração e remoção de nós virtuais/links. Os provedores de serviço podem utilizar ferramentas de gerenciamento para criar redes virtuais de acordo com suas necessidades.
2 Servidores OCSP devem possuir seus próprios certificados, com a presença obrigatória de algumas
Figura 1 – SecFuNet - Arquitetura conceitual
Os serviços oferecidos pelo SecFuNet para os provedores de serviço incluem o controle de acesso às redes virtuais, onde o provedor de serviço especifica as políticas e permissões de acesso dos seus usuários finais, que são postas em prática pelo SecFuNet.
O SecFuNet utiliza o XEN e o OpenFlow para criar redes virtuais independentes, de forma a isolar os dados de diferentes usuários. Acesso aos serviços é feito através de autenticação forte, utilizando elementos seguros e credenciais gerenciadas por um serviço de Sigle-Sign-On federado. O servidor de identidades federadas utilizado é o OpenID, que se apresenta como uma das soluções existentes mais adequadas para este propósito.
Para a autenticação forte, exigida pelo projeto, é necessária a utilização de cripto-grafia assimétrica e certificados digitais, armazenados nos dispositivos seguros dos usuários. Para criar, armazenar e distribuir tais certificados e chaves, faz necessária uma PKI, pois a complexidade de gerenciar estas chaves e certificados cresce rapidamente com o número de usuários e serviços agregados. Após avaliar várias alternativas de ferramentas auxiliares ao gerenciamento e manutenção de PKIs, a mPKI foi concebida como uma alternativa viável, propondo a utilização de hardwares e softwares com baixo custo de aquisição, manutenção e baixo consumo de energia, reduzindo os custos de implantar e operar a PKI do SecFuNet.
2.6 ICP-Brasil
Criada em 2001 pela MP 2.200-2 (26), a Infraestrutura de Chaves Públicas Brasileira, também conhecida como ICP-Brasil, consiste em uma série de especificações, critérios e normas para a emissão de certificados digitais, no âmbito dos serviços eletrônicos oferecidos pelas diversas instâncias do governo brasileiro. Através desta MP e de várias leis e decretos
sub-seguintes, foi também criado um Comitê Gestor, responsável por definir, avaliar e revisar as especificações e procedimentos da ICP-Brasil, que compreende toda a cadeia de certificação, desde sua raiz até os certificados finais, emitidos para usuários, servidores e entidades. Tecnicamente, a ICP-Brasil é uma PKI hierárquica de raiz única, administrada pelo Instituto Nacional de Tecnologia da Informação (ITI) 3.
2.6.1 Entidades componentes
A Figura 2 resume as entidades que compõem a ICP-Brasil e seus respectivos papéis.
Figura 2 – Diagrama da ICP Brasil
A Autoridade Certificadora Raiz da ICP-Brasil (AC-Raiz) é a primeira autoridade da cadeia de certificação. Sua política de certificados, normas técnicas e operacionais são definidas e aprovadas pelo Comitê Gestor da ICP-Brasil, de forma que é responsa-bilidade da AC-Raiz emitir, expedir, distribuir, revogar e gerenciar os certificados das autoridades certificadoras de nível imediatamente subsequente ao seu. A AC-Raiz também
3 Ao longo do trabalho, as siglas relacionadas à PKI, como CA, quando grafadas em português (AC,
por exemplo), fazem referência às entidades como identificadas nos documentos da ICP-Brasil. Os termos em inglês serão sempre utilizados para se referir ao conceito genérico.
é responsável por emitir a lista de certificados revogados (CRL) e de fiscalizar/auditar as CAs intermediárias, Autoridades de Registro (ARs) e outros prestadores de serviço habilitados na ICP-Brasil. Também é papel da AC-Raiz verificar se as CAs intermediárias estão atuando em conformidade com as diretrizes e normas técnicas estabelecidas pelo Comitê Gestor da ICP-Brasil.
Uma CA intermediária (AC Nível 1 ou 2) é uma entidade, pública ou privada, subordinada à hierarquia da ICP-Brasil, responsável por emitir, distribuir, renovar, revogar e gerenciar certificados digitais. É de responsabilidade das CAs intermediárias verificar se o titular do certificado possui a chave privada que corresponde à chave pública que faz parte do certificado, além de criar e assinar os certificados dos assinantes. Cabe também à CA intermediária emitir CRLs e manter registros de suas operações, sempre obedecendo às práticas definidas na sua declaração de práticas de certificação (DPC). Também é responsável por estabelecer e exigir o cumprimento, pelas Autoridades de Registro (ARs) a ela vinculadas, as políticas de segurança necessárias para garantir a autenticidade da identificação realizada.
As Autoridades de Registros (ARs) são responsáveis pela interação entre os usuários e as CAs intermediárias. Sempre vinculadas a uma CA, as ARs têm por objetivo o recebimento, validação, encaminhamento de solicitações de emissão ou revogação de certificados digitais e identificação, de forma presencial, de seus solicitantes. As ARs podem se localizar, fisicamente, na sua CA correspondente ou podem ser entidades remotas. Também devem manter registros de todas suas operações.
Uma Autoridade Certificadora do Tempo (ACT) é uma entidade na qual os usuários de serviços de carimbo do tempo (timestamping) confiam para emitir carimbos do tempo. A ACT tem a responsabilidade geral pelo fornecimento do carimbo do tempo, conjunto de atributos fornecidos pela parte confiável do tempo que, associado a uma assinatura digital, confere provar a sua validade em um determinado período, evitando a repudiação de documentos assinados anteriormente à data de comprometimento de um par de chaves, por exemplo. Na prática, um documento é produzido e seu conteúdo é criptografado. Em seguida, ele recebe os atributos ano, mês, dia, hora, minuto e segundo, atestado na forma da assinatura realizada com certificado digital servindo assim para comprovar sua autenticidade. A ACT atesta não apenas a questão temporal de uma transação, mas também seu conteúdo. Os certificados digitais das ACTs são emitidos pelas CAs intermediárias.
2.6.2 Tipos de certificados
A ICP-Brasil define vários tipos de certificado, classificados de acordo com o seu propósito e nível de segurança. Em relação ao propósito, os certificados da ICP-Brasil podem ser de dois tipos: assinatura digital e sigilo/encriptação. Os certificados de assinatura
digital se dividem em dois outros, do tipo A e tipo T, que dizem respeito a usuários finais e entidades de timestamping, respectivamente. Todos os certificados de encriptação são do tipo S. Quanto à segurança, os certificados são classificados em uma escala de 1 a 4, sendo o nível 1 o menos seguro e o nível 4 o mais seguro. Da combinação destes fatores surgem os 10 tipos de certificados previstos, atualmente, pela ICP-Brasil, a saber, A1, A2, A3, A4, S1, S2, S3, S4, T3 e T4. Cada um destes tipos possui um OID4 próprio, que pode ser
encontrado em (27).
A classificação de segurança está associada ao processo de geração e armazenamento das chaves, o que tem implicação direta sobre o tempo de validade dos certificados. As chaves para certificados do nível 1 podem ser geradas em software e precisam ser armazenadas, encriptadas, em um repositório protegido por senha e/ou identificação biométrica. Estes certificados têm validade de 1 ano.
As chaves de nível 2 também podem ser geradas em software, porém precisam ser armazenadas em um cartão inteligente ou token criptográfico, mesmo que estes não sejam capazes de gerar as chaves. Estes dispositivos também precisam ser protegidos por senha e/ou identificação biométrica, resultando em certificados válidos por até 2 anos.
As chaves de nível 3 precisam ser geradas e armazenadas em hardwares criptográficos homologados pela ICP-Brasil. No caso das chaves para certificados A3 e S3, estas também podem ser armazenadas em cartões inteligentes ou tokens criptográficos, desde que capazes de gerar as chaves e protegidos por senha e/ou identificação biométrica. Todos os certificados de nível 3 são válidos por até 5 anos.
Por fim, as chaves de nível 4 só podem ser geradas e armazenadas em hardwares criptográficos homologados pela ICP-Brasil e produzem certificados com validade de até 6 anos (ou 11 anos, caso toda a hierarquia de certificação seja composta por chaves criadas a partir de algoritmos em curvas elípticas).
2.6.3 Custo
O custo5 do credenciamento inicial de uma nova AC-1 (Autoridade Certificadora
de Nível 1), se esta não for um ente público, é de R$ 500.000,00 (quinhentos mil reais). Já para a emissão de novos certificados, após o credenciamento inicial, o custo para emissão de novos certificados é de R$ 100.000,00. Por fim, é necessária uma auditoria pré-operacional, antes da emissão de certificados para ACTs (Autoridades de Carimbo do Tempo), auditoria esta que custa R$ 50.000,00 (28).
A emissão dos demais certificados (AC-2, AR e os de usuário final) é feita pelas
4 do inglês, Object Identifier, como descrito na especificação do ASN.1
5 Os custos apresentados aqui foram obtidos do documento DOC-ICP-06, versão 3.0, vigente desde 1 de
entidades AC-1. Os preços praticados para a emissão de certificados para o usuário final6
variam de R$ 100,00 a R$ 405,00, para pessoas física, e R$ 140,00 a R$ 1.330,00 para pessoas jurídicas.
2.6.4 Padrões e algoritmos
Vários documentos tratam dos padrões e algoritmos criptográficos aceitos pela ICP-Brasil. As exigências variam em função do propósito (CA raiz, CA intermediária ou usuário final) e do tipo de certificado. Para mais detalhes, ver o DOC ICP-01.01 (29).
2.6.4.1 Geração de chaves e assinatura
Os algoritmos de geração e tamanhos das chaves variam de acordo com o propósito e tipo de certificado, conforme a Tabela2. Para a assinatura de certificados, CRLs, respostas do protocolo OCSP e pedidos/respostas de carimbo do tempo, a ICP-Brasil possibilita o uso de diversas combinações de algoritmos de hash e assinatura, como mostra a Tabela 3. Cada um dos algoritmos tem características próprias de tempo de processamento, espaço para armazenamento e segurança, trade-offs que devem ser equilibrados pelas CAs, a depender de seus processos internos e aplicação dos certificados, desde que respeitados os requisitos especificados nos documentos.
Tabela 2 – Geração de chaves assimétricas
Tipo de certificado Algoritmos Tamanho da chave
A1, A2, A3, S1, S2, S3, T3 RSA, ECC-Brainpool RSA 2048, brainpoolP256r1 AC, A4, S4, T4 RSA, ECC-Brainpool RSA 4096, brainpollP512r1
Tabela 3 – Combinações de algoritmos de assinatura Propósito
Combinação de algoritmos CA Usuário CRL OCSP Timestamp
sha1WithRSAEncryption X X X X X sha256WithRSAEncryption X X X X sha256WithECDSAEncryption X X X X sha512WithRSAEncryption X X X X X sha512WithECDSAEncryption X X X X X 2.6.4.2 Criptografia simétrica
A proteção das chaves privadas é feita através de algoritmos de criptografia simétrica, bem mais rápidos que os de criptografia assimétrica. A ICP-Brasil permite o uso dos algoritmos 3DES (30) de 112 bits ou do AES (31), com 128 ou 256 bits. Pode-se utilizar tanto o modo de operação CBC quanto o GCM (32).
6 Não foi possível localizar informações sobre os preços praticados para emissão de certificados para
2.6.5 Especificação dos certificados
Os documentos DOC-ICP-01 (33) e DOC-ICP-04 (27) especificam os campos, atributos e propriedades que devem (ou podem) estar presentes nos certificados X.509 que compõem a ICP-Brasil. Algumas das extensões obrigatórias para certificados de usuário são mostradas na Tabela 4.
Tabela 4 – Extensões obrigatórias
Extensão Crítica? Descrição
Authority Key Identifier Não O campo keyIdentifier deve conter o hashSHA-1 da chave pública da CA. Key Usage Sim Em certificados de assinatura digital,
somente os bits digitalSignature, nonRepudiation e keyEncipherment podem estar ativados. Em certificados de sigilo, somente os bits keyEncipherment e dataEncipherment podem estar ativados. Certificate Policies Não Deve conter o OID da DPC correspondente
e o endereço web onde pode ser obtida. CRL Distribution Points Não Deve conter o endereço na Web onde se
obtém o CRL correspondente.
Authority Information Access Não A primeira entrada deve conter o mé-todo de acesso id-ad-caIssuer, utilizando um dos seguintes protocolos de acesso: HTTP, HTTPS ou LDAP, para a recu-peração da cadeia de certificação. A se-gunda entrada pode conter o método de acesso id-ad-ocsp, com o respectivo ende-reço do respondedor OCSP, utilizando um dos seguintes protocolos de acesso: HTTP, HTTPS ou LDAP. Esta extensão somente é aplicável para certificado de usuário final. Extended Key Usage Sim Deve conter somente o sub-campo KeyPurposeID contendo o valor id-kp-timeStamping com OID 1.3.6.1.5.5.7.3.8, nos certificados de equipamentos de carimbo do tempo de ACT credenciada na ICP-Brasil. Esse OID não deve ser empregado em qualquer outro tipo de certificado.
Ainda para certificados de usuário, a ICP-Brasil define como obrigatória a extensão
Subject Alternative Name, não crítica, e com formatos específicos, dependendo da natureza
do titular do certificado. As definições de cada um dos campos otherName desta extensão são descritos na Tabela 5. As colunas “PF”, “PJ” e “APP” se referem, respectivamente, a aplicabilidade destes OIDs em certificados de pessoa física, jurídica7 e aplicações/equipa-7 Algumas das informações exigidas são referentes à pessoa física responsável pelo certificado.
mentos8. O documento DOC-ICP-04 especifica, em sua seção 7.1.2.4, restrições e regras
adicionais para os campos otherName, como o uso da codificação ASN.1 (34), na forma OCTET, STRING, ou PRINTABLE STRING. Outros usos da extensão Subject Alternative Name, previstos na RFC 5280 (23), também são permitidos pela ICP-Brasil.
Tabela 5 – “Subject Alternative Name” - OIDs, aplicabilidade, obrigatoriedade e descrições
OID PF PJ APP Obrigatório? Conteúdo
2.16.76.1.3.1 X Sim Data de nascimento, CPF, NIS e RG.
2.16.76.1.3.2 X X Sim Nome do responsável pelo certifi-cado.
2.16.76.1.3.3 X X Sim CNPJ da pessoa jurídica titular do certificado.
2.16.76.1.3.4 X X Sim Data de nascimento, CPF, NIS e RG.
2.16.76.1.3.5 X Sim Informações eleitorais.
2.16.76.1.3.6 X Sim Cadastro Especifico do INSS (CEI). 2.16.76.1.3.7 X Sim Cadastro Especifico do INSS (CEI)
da PJ.
2.16.76.1.3.8 X Sim Nome empresarial, se certificado de PJ.
2.16.76.1.3.9 X Sim Registro de Identidade Civil (RIC), se vinculados ao documento. 2.16.76.1.4.n X Não Número de habilitação ou
identifi-cação profissional, se existir.
O nome do titular do certificado, constante do campo Subject, deve adotar o
Distinguished Name (DN) segundo o padrão ITU X.500/ISO 9594 (35). A ICP-Brasil define os campos Country (C) e Organization (O) com valores fixos em BR e ICP-Brasil, respectivamente. Para certificados de usuário, o Organization Unit (OU) deve ser o nome da CA emitente, enquanto que o Common Name (CN) pode se enquadrar em uma das seguintes situações: a) nome do titular, caso seja um certificado de pessoa física; b) nome empresarial, como consta no CNPJ, caso seja um certificado de pessoa jurídica ou c) URL ou nome da aplicação, caso se trate de um certificado de aplicação/equipamento. No caso de um certificado de ACT, o OU utilizado deve ser o nome da ACT, enquanto que o CN deve representar o nome do servidor de carimbo de tempo, incluindo seu número de série. Com relação aos nomes, a ICP-Brasil, ainda através do DOC-ICP-04 (seção 7.1.5.2), restringe o uso de alguns caracteres, como sinais de acentuação e cedilha.
Para a emissão dos CRLs, a ICP-Brasil exige a presença de 3 extensões. A Authority
Key Identifier (não crítica) deve conter o hash SHA-1 da chave pública da CA que assina
o CSR. O CRL Number (não crítico) deve conter um número sequencial para cada CRL
8 Constam tanto informações sobre a pessoa jurídica associada ao certificado quanto informações sobre
emitido. Por fim, o Authority Information Access (não crítico) deve conter somente o método de acesso id-ad-caIssuer, utilizando um dos protocolos de acesso permitidos (HTTP, HTTPS e LDAP), para a recuperação da cadeia de certificação (não deve ser
utilizado nenhum outro método de acesso diferente de id-ad-caIssuer).
2.7 TPM
O TPM é uma especificação de segurança definida pelo Trusted Computing Group (10). A implementação mais comum desta especificação é um circuito integrado, conectado à placa-mãe da plataforma e controlado por um software, através de comandos específicos (36). Este dispositivo provê operações criptográficas como geração de chaves assimétricas,
encriptação, decriptação, assinatura digital, geração de números aleatórios, hashing, etc. Também é possível armazenar pequenas quantidades de dados neste dispositivo, utilizando sua memória segura. Além de ser acessível apenas pelo processador seguro, interno ao TPM, todos os dados armazenados nesta memória são encriptados. Esta memória também é protegida fisicamente, dificultando a utilização de osciloscópios ou outros dispositivos eletrônicos que pudessem realizar uma leitura “externa” dos seus dados. Por ser imple-mentado como um hardware dedicado de interface cuidadosamente pensada, o TPM é resistente a ataques de software (37).
Cada TPM pode ser identificado unicamente por uma chave embutida, a EK (do inglês Endorsement Key), para a qual o fabricante do dispositivo deve prover um certificado. Esta chave atesta a validade do TPM (38). Além da EK, várias chaves podem estar associadas ao TPM, como a AIK (do inglês Attestation Identity Keys) e todas as chaves geradas pelo usuário.
Um dos mecanismos mais importantes do TPM são os PCRs (do inglês Platform
Configuration Registers). Estes registradores são inicializados ao ligar a plataforma e só
podem ser modificados de duas formas: via reset ou extensão. A operação de extensão é definida como a hash SHA1 (39) da concatenação dos bytes do valor atual do PCR e um novo valor. As propriedades criptográficas desta operação são tais que é impraticável obter o mesmo valor para um PCR através de duas sequências distintas de extensões.
Durante a inicialização do sistema, a BIOS realiza a medição da raíz de confiança principal (CRTM, do inglês Core Root of Trust for Measurement) (40), que consiste em mensurar, através do cálculo de hashes, o código ou configurações do sistema. A cada novo componente mensurado, o valor original do PCR é estendido, de forma que o valor final de um PCR representa uma sequência de medições específicas, executadas em uma ordem definida, e estendidas, uma a uma. Este valor final pode, portanto, ser utilizado para verificar a integridade do sistema, considerando que o valor esperado de um sistema íntegro seja conhecido. Um modelo de confiança transitivo pode ser implementado garantindo que a
etapa seguinte do processo (BIOS, bootloader, sistema operacional, aplicações, etc) só sejam executadas se todas as etapas anteriores forem verificadas com sucesso. Procedimentos tem sido desenvolvidos para permitir que sistemas operacionais mensurem aplicações executadas, scripts e arquivos de configurações (41).
Outra aplicação importante do TPM é na operação de selar dados. Nesta operação, um conjunto de dados é encriptado com base no estado atual do TPM, que é representado por um conjunto específico de PCRs e seus respectivos valores. Se algum dos valores dos registradores PCR mudar, torna-se impossível decriptar os dados, protegendo as informações seladas de possíveis comprometimentos do sistema.
2.8 Resumo do capítulo
Neste capítulo, revimos os principais conceitos de criptografia assimétrica, chave pública e privada. Explicamos, também, os conceitos mais relevantes sobre certificação digital e infraestrutura de chaves públicas, nos quais se baseia esta dissertação. Apresenta-mos também o SecFuNet, contexto de projeto no qual se insere este trabalho. MostraApresenta-mos alguns dos requisitos da ICP-Brasil, com toda a sorte de especificações e nuances. Por fim, conceituamos o TPM, dispositivo seguro utilizado na construção do protótipo. Todos estes conceitos são fundamentais para o entendimento dos capítulos por vir.
3 TRABALHOS E
FERRAMEN-TAS RELACIONADAS
Neste capítulo apresentaremos alguns trabalhos e ferramentas relacionadas. As próximas seções se apresentam da seguinte forma:
• Enumeramos alguns trabalhos relacionados (Seção 3.1);
• Apresentamos o OpenSSL como ferramenta tradicionamente utilizada para a criação, operação e manutenção de PKIs (Seção 3.2) e
• Introduzimos algumas ferramentas alternativas ao OpenSSL, existentes no mercado (Seção 3.3).
3.1 Trabalhos relacionados
O criação da criptografia de chaves públicas possibilitou a troca de chaves simétricas de forma segura entre as entidades, mesmo através de um meio de comunicação inseguro. A proposta inicial de Diffie-Hellman evoluiu para o que ficou conhecido como Diffie-Hellman não-anônimo, onde há a presença de uma terceira entidade, confiável, responsável por atestar a autenticidade e integridade dos certificados apresentados pelas outras duas entidades participantes. Há vários modelos que tentam diminuir os custos e a complexidade de uma PKI, como, por exemplo:
• sem certificado (certificateless) (42);
• baseado em certificado (certificate-based) (43); • baseado em identidade (identity-based) (44) e
• chave pública autocertificada (self-certified public-key) (45).
Embora seja considerado custoso, o modelo de PKI padrão continua sendo bastante utilizado, nos mais diversos ambientes e aplicações. Para autenticação em grids, por exemplo, os trabalhos (46), (47), (48) e (49) mostraram que é possível fazer uso de certificados e chaves públicas para esta autenticação. No contexto de comunicações
peer-to-peer, (50) propõe um esquema de segurança para distribuição de informação em redes P2P.
A popularização de dispositivos criptográficos portáteis, como os smartcards, tem tornado cada vez mais comum a publicação de trabalhos onde dispositivos como estes são
utilizados para a autenticação dos usuários. Em (51), os autores propõem um sistema de pagamento móvel baseado nos princípios de uma PKI, utilizando smartcards. Já em (52), os autores propõem um esquema de autenticação no qual o servidor RADIUS armazena suas credenciais em diversos smartcards, de forma que possa responder à múltiplas requisições simultaneamente. Em (53), os autores propõem modificações no smartcard para que este se torne autônomo, no processo de autenticação, modificações que acabam por limitar a aplicação dos dispositivo modificados apenas à autenticação no RADIUS. Por fim, no que diz respeito a computação nas núvens, os autores de (48) propõem um esquema de autenticação de máquinas virtuais, usando um grid de smartcards.
3.2 OpenSSL
Nesta seção, abordamos a implementação e gestão de uma PKI utilizando apenas comandos da ferramenta OpenSSL. A documentação completa de todos os comandos e configurações pode ser encontrada em (54).
3.2.1 Estrutura de diretórios
É prática comum a criação de diretórios individuais para cada CA, facilitando a organização dos arquivos. Uma das estrutura comumente adotadas pode ser vista no Código 3.1. Neste exemplo, ’ca-one’ e ’ca-two’ representam identificadores utilizados pelo administrador para identificar as CAs, como, por exemplo, ’ca-root’, ’ca-servers’ ou ’ca-users’. Cada um dos diretórios tem um propósito específico, descrito na Tabela 6.
Código 3.1 – Estrutura de diretórios de uma CA
pki - root / etc/ ca -one. conf ca -two. conf ... ca/ ca -one/ db/ ca -one.db ca -one.db. attr ca -one.crt.srl ca -one.crl.srl private / ca -one.key 01. pem 02. pem ... ca -two/ db/ ca -two.db ca -two.db. attr ca -two.crt.srl
ca -two.crl.srl private / ca -two.key 01. pem 02. pem ... ca -one.csr ca -one.crt ca -one.cer
ca -one - chain .pem ca -two.csr
ca -two.crt ca -two.cer
ca -two - chain .pem ... crl/ ca -one.crl ca -two.crl ... cert / john .csr john .crt john .p12 server -a.csr server -a.crt ...
Tabela 6 – Descrição dos diretórios
Diretório Descrição
etc Armazena as configurações de cada CA.
ca Reune as requisições de certificados de CA e seus respectivos cer-tificados. Também agrupa os sub-diretórios específicos de cada CA
ca/<ca-id> Diretório específico de cada CA. Aqui são armazenados todos os cer-tificados assinados pela CA, nomeados de acordo com seus números de série.
ca/<ca-id>/db Armazena a base de dados de certificados da CA e os arquivos de série.
ca/<ca-id>/private Armazena a chave privada da CA.
crl Contém as bases de certificados revogados de todas as CAs. certs Repositório das requisições de certificados e certificados assinados
(em vários formatos) por todas as CAs, sem nomenclatura específica. É comum nomear os certificados de acordo com a entidade titular e o propósito ao qual são destinados.
3.2.2 Arquivos de configuração
Como indicado no Código3.1, é comum a utilização de um arquivo de configuração para cada CA da PKI, devido às especificidades que cada CA pode ter, quer sejam
restrições aos dados do titular do certificado, atributos ou mesmo usos específicos para os certificados por esta assinados. A criação e manutenção destes arquivos de configuração é uma das atividas mais críticas na administração de uma PKI. Um simples parâmetro incorreto pode levar a falhas críticas de segurança, como à assinatura indiscriminada de certificados de entidades com propriedades de CA. O Código 3.2mostra um exemplo de arquivo de configuração1, enquanto que as Tabela 7, 8e 9 descrevem, respectivamente, as
seções, atributos e extensões mais importantes.
Código 3.2 – Exemplo de um arquivo de configuração do OpenSSL
# Blue Component CA [ default ]
ca = component -ca # CA name dir = . # Top dir base_url = http :// pki. blue .se # CA base URL
aia_url = $base_url /$ca.cer # CA certificate URL crl_url = $base_url /$ca.crl # CRL distribution point ocsp_url = http :// ocsp . blue .se # OCSP responder URL
name_opt = multiline ,- esc_msb , utf8 # Display UTF -8 characters openssl_conf = openssl_init # Library config section # CA certificate request
[ req ]
default_bits = 2048 # RSA key size
encrypt_key = yes # Protect private key default_md = sha1 # MD to use
utf8 = yes # Input is UTF -8 string_mask = utf8only # Emit UTF -8 strings prompt = no # Don ’t prompt for DN distinguished_name = ca_dn # DN section
req_extensions = ca_reqext # Desired extensions [ ca_dn ]
countryName = "SE" organizationName = " Blue AB"
organizationalUnitName = " Blue Component CA" commonName = " Blue Component CA" [ ca_reqext ]
keyUsage = critical , keyCertSign , cRLSign basicConstraints = critical ,CA:true , pathlen :0 subjectKeyIdentifier = hash
# CA operational settings [ ca ]
default_ca = component_ca # The default CA section [ component_ca ]
certificate = $dir /ca/$ca.crt # The CA cert
private_key = $dir /ca/$ca/ private /$ca.key # CA private key
new_certs_dir = $dir /ca/$ca # Certificate archive serial = $dir /ca/$ca/db/$ca.crt.srl # Serial number file crlnumber = $dir /ca/$ca/db/$ca.crl.srl # CRL number file database = $dir /ca/$ca/db/$ca.db # Index file
unique_subject = no # Require unique subject default_days = 730 # How long to certify for default_md = sha1 # MD to use
policy = match_pol # Default naming policy email_in_dn = no # Add email to cert DN preserve = no # Keep passed DN ordering name_opt = $name_opt # Subject DN display options cert_opt = ca_default # Certificate display options copy_extensions = copy # Copy extensions from CSR x509_extensions = server_ext # Default cert extensions default_crl_days = 1 # How long before next CRL crl_extensions = crl_ext # CRL extensions
[ match_pol ] countryName = match stateOrProvinceName = optional localityName = optional organizationName = match organizationalUnitName = optional commonName = supplied [ any_pol ] domainComponent = optional countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = optional emailAddress = optional # Extensions [ server_ext ]
keyUsage = critical , digitalSignature , keyEncipherment basicConstraints = CA: false
extendedKeyUsage = serverAuth , clientAuth subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid : always authorityInfoAccess = @ocsp_info crlDistributionPoints = @crl_info
certificatePolicies = blueMediumDevice [ client_ext ]
keyUsage = critical , digitalSignature basicConstraints = CA: false
extendedKeyUsage = clientAuth subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid : always authorityInfoAccess = @ocsp_info crlDistributionPoints = @crl_info
[ timestamp_ext ]
keyUsage = critical , digitalSignature basicConstraints = CA: false
extendedKeyUsage = critical , timeStamping subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid : always authorityInfoAccess = @issuer_info crlDistributionPoints = @crl_info
certificatePolicies = blueMediumDevice [ ocspsign_ext ]
keyUsage = critical , digitalSignature basicConstraints = CA: false
extendedKeyUsage = critical , OCSPSigning subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid : always authorityInfoAccess = @issuer_info noCheck = null
certificatePolicies = blueMediumDevice [ crl_ext ]
authorityKeyIdentifier = keyid : always authorityInfoAccess = @issuer_info [ ocsp_info ]
caIssuers ;URI .0 = $aia_url OCSP ;URI .0 = $ocsp_url [ issuer_info ]
caIssuers ;URI .0 = $aia_url [ crl_info ] URI .0 = $crl_url # Policy OIDs [ openssl_init ] oid_section = additional_oids [ additional_oids ]
blueMediumDevice = Blue Medium Device Assurance , 1.3.6.1.4.1.0.1.7.9
Tabela 7 – openssl.cnf: seções obrigatórias
Seções Descrição
[default] Configurações gerais e valores padrão para atributos não defi-nidos nas subseções.
[req] Configurações aplicadas no processo de criação dos CSRs. [ca] Configurações aplicadas no processo de assinatura de
certi-ficados, incluindo o caminho para arquivos da CA, como o certificado, a chave privada, os arquivos com os números de série, as bases de certificados (válidos e revogados), etc. Pode referenciar outras seções, se necessário.
Tabela 8 – openssl.cnf: parâmetros
Parâmetros Descrição
default_bits Tamanho padrão da chave gerada durante a criação do CSR, se o usuário não optar por fornecer uma chave já existente. default_md Algoritmo de hash utilizado por padrão, na assinatura de
certificados ou CSRs.
distinguished_name Indica a seção onde estão especificadas as regras para o DN utilizado nos CSRs.
x509_extensions Indica a seção onde estão especificadas as extensões aplicadas a certificados auto-assinados.
req_extensions Indica a seção onde estão especificadas as extensões solicitadas nos CSRs. Quando presente em CSRs, estas extensões são validados pelas CAs, antes da assinatura dos certificados. unique_subject Define se é possível, ou não, assinar múltiplos certificados com
o mesmo DN.
default_days Tempo padrão pelo qual os certificados assinados serão válidos policy Indica a seção onde estão especificadas os requisitos para
assi-natura dos certificados, no que diz respeito aos DNs.
copy Define se/como as extensões especificadas em um CSR serão incorporadas ao certificado assinado.
Tabela 9 – openssl.cnf: extensões
Extensões Descrição
keyUsage Define a quais propósitos o certificado e sua chave pública vão servir.
basicConstraints Define se o certificado é uma CA ou não.
extendedKeyUsage Define usos adicionais do certificado e de sua chave pública.
3.2.3 CSR
A criação de CSRs é feita utilizando a opção req da ferramenta openssl. As propriedades do certificado solicitado geralmente são carregadas de um arquivo de configu-ração, que pode ser o padrão do OpenSSL ou especificado na linha de comando. Qualquer propriedade presente no arquivo de configuração pode, contanto, ser redefinida através de opções específicas, quando da invocação do openssl. Por fim, o par de chaves utilizado para assinar o certificado pode ser indicado ou, se o operador desejar, as chaves podem ser criadas juntamente com o CSR. O Código 3.3 mostra um exemplo da utilização do comando openssl req.
Código 3.3 – Requisição de assinatura de certificado (CSR)
openssl req -new \
-config etc/ca -two. conf \ -out certs /fred -id.csr \ -keyout certs /fred -id.key
3.2.4 Assinatura de certificados
A assinatura de certificados é feita através da opção ca do openssl. Como no caso dos CSRs, as propriedades podem ser carregadas de algum arquivo de configuração ou (re)definidas, na linha de comando. É necessário, contudo, especificar o CSR que se deseja assinar. Caso existam múltiplas definições de extensões no arquivo de configuração utilizado, é preciso indicar qual destas deve ser utilizada. O Código 3.4 exemplifica a assinatura de um certificado utilizando algumas destas opções. Antes de assinar, propriamente, o certificado, é necessário que o operador confirme os dados do certificado que está sendo assinado e sua adição à base de certificados, sendo esta sua última chance de cancelar a operação.
Código 3.4 – Assinatura de um certificado
openssl ca \
-config etc/ identity -ca. conf \ -in certs /fred -id.csr \
-out certs /fred -id.crt \ -extensions identity_ext
3.2.5 Cadeia de certificação
A geração da cadeia de certificação é obtida a partir da concatenação, em ordem apropriada, de todos os certificados que compõem a cadeia. O primeiro certificado da cadeia deve ser o da CA que emitiu o certificado da entidade a qual se destina a cadeia gerada, até a CA raíz, por último. O Código 3.5 ilustra essa operação.
Código 3.5 – Cadeia de certificação
cat ca/ component -ca.crt \
ca/ network -ca - chain .pem > \ ca/ component -ca - chain .pem
3.2.6 Revogação de certificados
O processo de revogação de certificados é dividido em duas etapas: a revogação do certificado, em si, e a geração de uma nova lista de certificados revogados (CRL), atualizada. Somente após a atualização da CRL é que o certificado estará revogado de fato, ainda dependendo, contudo, que as outras entidades interessadas em verificar a validade do certificado sincronizem suas CRLs com uma frequência adequada. Supondo que a ca-one revogue o certificado de um usuário e atualize sua CRL, ainda é possível que este usuário acesse um serviço seguro com este certificado revogado, caso a entidade responsável pelo serviço não tenha atualizado, ainda, sua CRL.
A revogação dos certificados é feita também através da opção ca, porém com alguns parâmetros diferentes, com destaque para os parâmetros -revoke e -crl_reason.
Estes indicam, respectivamente, qual certificado deve ser revogado e o motivo pelo qual ele o está sendo. Como os outros comandos já discutidos, também é possível carregar as propriedades dos arquivos de configuração ou redefiní-las, na linha de comando. O Código 3.6 exemplifica o uso de algumas destas opções.
Código 3.6 – Revogação de certificado
openssl ca \
-config etc/ identity -ca. conf \ -revoke ca/ identity -ca /02. pem \ -crl_reason superseded
A geração da CRL, por sua vez, é mostrada no Código 3.7. Esta operação também utiliza a opção ca, porém com o parâmetro -gencrl, que varre a base de certificados e gera uma lista com os certificados revogados existentes.
Código 3.7 – Lista de certificados revogados (CRL)
openssl ca -gencrl \
-config etc/ identity -ca. conf \ -out crl/ identity -ca.crl
3.2.7 Operações adicionais
Duas outras operações, também importantes, porém secundárias, são a criação de credenciais no formato PKCS#12 e a exportação de certificados na codificação DER.
O formato PKCS#12 (56) é um dos padrões de criptografia de chave pública concebidos e publicados pela RSA Security. É um formato bastante comum, utilizado para armazenar certificados e chaves, facilitando sua inserção em navegadores web e aplicações. Uma de suas principais características é armazenar, em um mesmo container, o certificado, a chave pública associada a este e também a chave privada. Por segurança, estas informações costumam ser protegidas através de uma criptografia simétrica, com chave definida pelo usuário. O Código 3.8mostra como a opção pkcs12 do openssl pode ser utilizada para gerar tal tipo de credencial.
Código 3.8 – Credencial no padrão PKCS#12
openssl pkcs12 -export \
-name " Fred Flintstone ( Blue Encryption )" \ -caname " Blue Identity CA" \
-caname " Blue Network CA" \ -caname " Blue Root CA" \ -inkey certs /fred -enc.key \ -in certs /fred -enc.crt \
-certfile ca/ identity -ca - chain .pem \ -out certs /fred -enc.p12
O DER, como mencionado na Seção2.3, é uma das regras de codificação utilizadas para serializar os certificados X.509. Se o administrador da PKI desejar publicar os
