Código 5.12–Exemplo de criação de nova CA
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
certificados e CRLs na internet, eles devem ser codificado em DER, segundo a seção 4 da RFC 2585 (57). Para isso, pode-se utilizar a opção x509 e o parâmetro -outform der, como mostrado no Código 3.9
Código 3.9 – Codificação DER
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