Introdução

Relatório do trabalho da disciplina de Fundamentos de Redes de Computadores da Universidade de Brasília - Faculdade Gama, do curso de graduação Engenharia de software.

Alunos:

Artur Bersan de Faria

Marcelo Herton Pereira Ferreira

23 de Novembro de 2016

Objetivo

O objetivo deste documento é apresentar as informações necessárias para a criação e registro de uma infra estrutura de autoridades certificadoras.

Glossário

PKI: infraestrutura de chave pública.
RSA: algoritmo criptográfico assimétrico.
CA: autoridade certificadora.
Autenticação: processo de estabelecimento para de pessoas, serviços ou organizações de quem ou o que elas dizem ser.
Algorítmo assimétrico: algorítmo criptográfico baseado no uso de chaves, onde são necessárias chaves diferentes para encriptar e decifrar a mesma mensagem.
Chave pública e privada: são as chaves utilizadas pelos algorítmos criptográficos assimétricos, no qual a chave privada é de conhecimento apenas do dono e a pública é de conhecimento de todos.
OCSP: sigla para _Online Certificate Status Protocol_.

Referências

[RFC 5280] D. Cooper, S.Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008. In: The internet Society.

[RFC 2527] S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. November 2003. In: The internet Society.

[RFC 3279] W. Polk, R. Housley, L. Bassham. Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. April 2002. In: The internet Society.

[x.509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition.

Microsoft A. Protegendo a PKI: Planejando uma hierarquia de CA. Acessado em: 23 de Novembro de 2016. Disponível em: https://msdn.microsoft.com/pt-br/library/dn786436(v=ws.11).aspx

Microsoft B. Define Certificate Policies and Certification Authority Practices. Acessado em: 23 de Novembro de 2016. Disponível em: https://technet.microsoft.com/en-us/library/cc977811.aspx

GlobalSign. Certification Practice Statement: template. Acessado em: 23 de November de 2016. Disponível em: https://www.globalsign.com/en/repository/TrustedRoot%20Template%20CPS.pdf

ITI-Brasil. Como funciona. Acessado em: 23 de Novembro de 2016. Disponível em: http://www.iti.gov.br/icp-brasil/como-funciona.

EJBCA. Acessado em: 23 de Novembro de 2016. Disponível em: https://www.ejbca.org/

Autoridade certificadora

Uma autoridade certificadora é uma entidade capaz de gerar certificados digitais. Uma CA é utilizada para afirmar que o certificado apresentado por um usuário final é dele mesmo, usado comumente para garantir canais de comunicação segura na internet entre cliente-servidor ou servidor-servidor.

Para fazer uso dos certificados, os browsers adicionam um conjunto de autoridades confiáveis dos certificados.

Hierarquia

Para impedir que as informações da chave privada de uma CA seja 'vazada', e para que uma organização não tenha sobrecarga, na consulta, geração e revogação de certificados, é possível definir uma estrutura hierárquica entre CA [Microsoft A].

Imagem da representação da hierarquia

Uma CA raiz é auto assinada, ou seja, ela assina seu próprio certificado digital. A partir deste, ela é capaz de gerar novos para as autoridades certificadoras intermediárias. Uma CA intermediária realiza a assinatura para as entidades certificadoras, e estas por sua vez que realizarão todas as operações de relacionadas ao mapeamento entre chave pública e usuário final.

Nesta estrutura, quando o certificado de uma entidade estiver comprometido, a CA intermediária poderá gerar um novo certificado para ela, sem prejuízos a todos os outros usuários que possuem registro nas demais certificadoras. Isto evita com que a CA raiz faça auto assinatura com grande frequência, diminuindo o trabalho de reassinar todos os certificados já existentes [Microsoft A].

Operações realizadas por uma CA com certificados

A CA tem responsabilidade de gerenciar os certificados por ela emitidos verificando se o titular do certificado é detentor da chave privada que corresponde a chave pública do mesmo. De acordo com a ICP-Brasil [ITI-Brasil].

Emissão

Na emissão do certificado digital, a CA cria e assina digitalmente o certificado do assinante, onde o certificado emitido pela CA representa a declaração da identidade do titular, que possui um par único de chaves (pública/privada).

Distribuição

Na distribuição do certificado digital, a CA verifica se quem pediu o certificado, é realmente quem diz ser, e o encaminha.

Renovação

Todo certificado tem seu prazo de validade, e cabe a CA renovar o certificado.

Revogação

Há vários motivos para que um certificado seja revogado. O padrão seria o tempo de atuação do certificado expirar. Mas ele também pode revogar por outros motivos, como o comprometimento da autoridade certificadora ou da chave pública, a desistência do certificado e entre outros. Cabe a CA gerar a revogação do certificado por qualquer motivo válido.

Documentos necessários

Para que uma entidade se torne uma CA, é preciso que ela estabeleça um conjunto de especificações sobre como irá atuar sobre as operações realizadas por ela, e como irá realizar a auditoria das ações.

Políticas de certificação

O padrão x.509 de certificados definidos pela RFC 5280 define como sendo um conjunto de regras que indicam os possíveis usos de um certificado digital para aplicações ou comunidades de aplicações com requisitos de segurança comuns.

Basicamente, devem ser contidas as informações sobre [Microsoft B]: quais usuários serão autenticados pela CA; para quais propósitos o certificado pode ser usado; quais os requisitos que o usuário final precisa cumprir; se a chave privada pode ser exportada; os requisitos para renovação e requisição de certificados; algoritmos criptográficos a serem usados; tamanho mínimo da chave.

Em um certificado, a política de certificação é identificada por um número único chamado de Object Identifier, o registro de uma política deve seguir os procedimentos especificados pelas entidades ISO/IEC e ITU.

Declaração de práticas de certificação

Trata-se do estabelecimento de práticas que as CA devem executar ao gerar certificados, a CA deve detalhar o quão confiável são seus sistemas, as operações executadas, podendo variar o nível de detalhamento.

Quando o grau de detalhamento deste documento é elevado, pode ser utilizado ele ou as políticas de certificação. A CA GlobalSign, define um template a ser seguido para que organizações possam se tornar uma CA na sua hierarquia.

Neste documento é necessária realizar a descrição destes tópicos, no qual cada um deles dá o detalhamento como a CA irá atuar sobre cada um deles [GlobalSign].

Certificate types	[Server] Certificates	[Client] Certificates
Registration Procedures	Certificate Request	Certificate Generation
Certificate Acceptance	Certificate Renewal
Issuing Procedure	Relevant [COMPANY] Documents
[COMPANY] Certification Authority	Subscribers
Prohibited Certificate Usage	Certificate Extensions
Identification and Authentication	Certificate Life-Cycle Operational Requirements
Qualifications, Experience, Clearances	Audit Logging Procedures

Certificados

Um certificado digital é uma forma de associar o nome de uma pessoa, entidade, serviço a uma chave pública [RFC 5280].

Campos básicos

Para a geração de um certificado, é necessário ter campos mínimos sobre a inforção da CA que produziu o certificado e sobre o próprio utilizador [RFC 5280].

Certificate

tbsCertificate: o nome da pessoa, entidade ou serviço ao qual se quer associar ao par de chaves.

signatureAlgorithm: contém a assinatura do algoritmo criptográfico usado pela CA. Pode ser os algorítmos que dão suporte a assinatura https://tools.ietf.org/html/rfc3279.

signatureValue: contém a assinatura digital utilizada para realizar a verificação dele pela CA.

TBSCertificate

version: define a versão usada no protocolo.

serial number: um número positivo e inteiro assinado pela CA, único para cada certificado.

signature: algoritmo usado pela CA para assinar o certificado.

issuer: campo que identifica a entidade que assinou o certificado. o qual pode conter informações sobre:

país
organização
unidade organizacional
nome qualificador distinto
nome do estado ou província
nome comum
número serial

validity: especifica o período que o certificado será válido

subject: identifica a entidade na qual a chave pública será armazenada.

subject public key info: armazena a chave pública e o algoritmo assimétrico utilizado.

extension: possibilita na x.509 v3 prover métodos para associar atributos adicionais aos usuários ou chaves públicas para gerenciar os relacionamentos entres CA.

Softwares open source que implementam uma CA

OpenSSL
EJBCA
gnoMINT
OpenCA
DogTag

EJBCA PKI CA

O EJBCA® é um software open source de autoridade certificadoras, construido na linguagem Java (JEE), pode ser integrado com outras ferramentas ou utilizado no seu modo padrão.

Ele foi projetado para fornecer uma suite completa, necessária a criação de uma infraestrutura de chaves públicas para qualquer tipo de organização. Ele prove os serviços de implementação de uma Autoridade Certificadora, Autoridade validadora e um _OCSP responder_.

A seguir será mostrado como foi realizada a criação de uma infraestrutura de autoridades certificadoras utilizando este software. Foi utilizada uma máquina virtual com 1.5 Gb de memória ram, 1 core de cpu, espaço em disco de 32 GB, 1 interface de rede em modo bridge, sistema operacional Ubuntu 14.04 server.

Instalando as dependências

Foram executados os comandos abaixo para instalar as dependências OpenJDK versão 7, ant e o descompactador de arquivos unzip. Em seguida, foram baixados e descompactados os softwares no diretório /home/Predefinição:User name. Nesta instalação o usuário utilizado foi **user**.

   cd /home/user
   sudo apt-get install openjdk-7-jdk ant ant-optional unzip ntp
   wget http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.1.Final.zip
   wget http://downloads.sourceforge.net/project/ejbca/ejbca6/ejbca_6_3_1_1/ejbca_ce_6_3_1_1.zip
   unzip jboss-as-7.1.1.Final.zip
   unzip ejbca_6_3_1_1.zip

Após o download e a extração dos arquivos, é preciso indicar ao EJBCA qual o servidor onde o software funcionará. O servidor é executado para que seja feita a construção e instalação do EJBCA. A instalação consiste em construir as estruturas básicas para a criação de Autoridades certificadoras. **Obs.: foi utilizada a configuração padrão para instalação, então as perguntas de requisição de password entre outros foram deixadas em branco.**

   cd /home/user
   echo "appserver.home=/home/user/jboss-as-7.1.1.Final" >> ejbca_ce_6_3_1_1/conf/ejbca.properties

   ## the line above is just to host access the JBoss in guest environment
   sed -i "s/127.0.0.1/0.0.0.0/g" jboss-as-7.1.1.Final/standalone/configuration/standalone.xml

   ./jboss-as-7.1.1.Final/bin/standalone.sh &> /dev/null &
   cd /home/user/ejbca_ce_6_3_1_1/
   ant deploy
   ## Após o servidor JBoss reiniciar, é executada a instalação
   ant install

Será criado um certificado inicial, que será usado para inicar toda a estrutura. Para isto, copie o arquivo /home/user/ejbca\_ce\_6\_3\_1\_1/p12/superadmin.p12 para a máquina local, e importe no browser. **Obs.: neste tutorial será utilizado o browser firefox.**

Foi seleciona a opção menu > preferências > avançado > certificados > ver certificados.
Clicou-se na aba de 'seus certificados' e importou o certificado superadmin.p12. A senha padrão utilizada é ejbca.

Configurando a hierarquia

Trata de criar toda estrutura de autoridades certificadoras em 3 níveis

RootCA - Autoridade raiz
- Outras CA intermediárias
- IntermediaryCA - Autoridade intermediária para gerênciar todos os geradores de certificado
  - ServerCA - Entidade certificadora que irá atender as requisições de usuários comuns
  - Outras CA como entidades certificadoras.

Para isto, execute os passos abaixo para tal configuração.

Acessar a URL: http://Predefinição:Server ip/ejbca
Clicar em 'Administration' e depois em 'Certification Authorities'
Adicionar o nome da 'RootCA' e clicar em "Create..."
- Type CA: x509
- Escolher algoritmo de assinatura "sha512withRSA"
- Adicionar em "Validity" o valor 10y
- Deixar as demais informações no padrão e clicar em create
Adicionar o nome da 'IntermediaryCA' e clicar em "Create..."
- Selecionar Crypto Token: RootCA
- Signed by: RootCA
- Em validity: colocar o valor 5y
- Approval Settings selecionar: "Add/Edit End Entity", "Key Recovery", "Revogation"
- Deixar as demais informações no padrão e clicar em create
Adicionar o nome 'ServerCA' e clicar em "Create..."
- Selecionar Crypto Token: RootCA
- Signed by: IntermediaryCA
- Em validity: colocar o valor 2y
- Approval Settings selecionar: "Add/Edit End Entity", "Key Recovery", "Revogation"
- Deixar as demais informações no padrão e clicar em create

Criando usuários

Para poder criar os usuários que farão uso dos certificados gerados pela aplicação, é preciso antes criar 2 perfis de usuário: User e Server. No perfil de Server serão registrados os usuários administradores, capazes de realizar as operações de certificação. e o perfil User será para os usuários finais da aplicação.

Clicar em 'End Entity Profiles'
Adicionar 'User' e clicar em 'create' em seguida selecionar o 'User' e pedir para editar
- Definir o tamanho mínimo da password como 6 caracteres
- Adicionar os campos "Organization Unit", "Organization", "Locality", "State or province", "country" ao Subject DN Attributes. Se desejar, é possível adicionar outros atributos como "postal code" ou "Ip address".
- Default ca: Selecione ServerCA
- Avaliable ca: Select ServerCA
- Salve
Adicionar 'Server' e clicar em 'create' em seguida selecionar o 'User' e pedir para editar
- Execute os passos anteriores para adicionar 'User'
- Adicione o domínio de email da organização: aluno.unb.br
- Adicione os valores padrões:
  - Organization: UnB
  - Organization Unit: FGA
  - State: DF
  - Country: Brasil
  - Locality: BR
- Altere Avaliable ca: AnyCA

Agora é possível criar os usuários responsáveis pelo gerenciamento do sistema.

Clicar em 'Add entity'
- Selecionar Profile: Server
- Username: root
- Password: root
- Email: rootmail
- CommonName: User Root
- CA: ManagementCA
Clicar em 'Add Entity'
- Selecionar Profile: User
- Username: tester
- Password: tester
- Email: testermail @ domain
- CommonName: Tester
- CA: ServerCA

Adicionar administrador

Para que o servidor root tenha acesso ao painel de administração, é preciso adicioná-lo à ao grupo de administradores.

Clicar em 'Administrator roles'
Administrators e fazer a seguinte busca:
- CA: "ManagementCA", "X509:CN, Common name", "Equal, case sens.", "User Root"

Ao adicionar um User pedindo autenticação na CA ServerCA, será necessário a aceitação de outro administrador aceitando o cadastro. Assim, deve-se pedir o certificado para o usuário servidor root, acessar o site com ele a criação do _end user entity_ 'tester'.

Clicar em 'Public web'
Clicar em 'Create Browser Certificate'
- username: root, password: root
- key lenght: 2048, certificate profile: ENDUSER.
Reiniciar o browser e realizar o mesmo procedimento para adicionar o certificado root.p12
Clicar em 'Administration'
Approve Action > Add End Entity > Approve

Criando, consultando e revogando certificados

Para criar o certificado, é preciso realizar a mesma etapa que os passos anteriores. até a etapa de criar o certificado. Para checar se ele está válido, deve-se seguir os seguintes procedimentos:

Clicar em 'List User's certificates'
Adicionar 'CN=Tester,O=UnB,C=DF'
Clicar em 'Check if is revoked'

Depois para revogar o certificado:

Clique em 'Administration' e 'Search End entitites'
Procure pelo username: 'tester'
Clique em 'View\_certificates' e na janela que clique no botão 'Revoke'

Aprove a revogação com outro usuário adminstrador, e refaça a consulta. O resultado será algo como o a seguir:

   Certificate Status

   Issuer: CN=ServerCA

   Serial number: 73A3AD7A51D7E4E
   The certificate has been REVOKED!

   The revocation date is Wed Nov 23 21:25:22 BRST 2016.
   The reason for revocation was "certificate hold" (6).

Conclusão

Com o uso do EJBCA é possível construir uma hierarquia de autoridades certificadoras para uma organização que seja extremamente grande e necessite de autenticar seus funcionários por exemplo. Para ele registrar sua própria CA, ele precisará descrever todos os procedimentos, etapas de auditorias, política do ciclo de vida dos certificados entre outros.

Este trabalho, realizou um exemplo de criação, revogação e consulta de certificados apenas pela própria interface disponibilizada pelo EJBCA. Para trabalhos futuros, seria possível a construção de um serviço simples que utilizasse as assinaturas digitais para estabelecimento de conexões seguras entre cliente-servidor.