ICPEdu Introdução a Infraestrutura de Chaves Públicas e Aplicações

Dayana Spagnuelo é mestre em Ciência da Computação (2013) formada pela Universidade Federal de Santa Catarina. Atuou como bolsista no Laboratório de Segurança em Computação durante sua formação acadêmica, se envolvendo em diversos projetos multidisciplinares. Já lecionou criptografia básica e avançada para cursos de pószgraduação em nível de especialização em Gestão de Tecnologia da Informação e Segurança da Informação. Atualmente trabalha diretamente com pesquisa acadêmica na área de Segurança da Informação.

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

O curso ICPEdu Introdução a Infraestrutura de Chaves Públicas e Aplicações apresenta como implantar um serviço de geração de certificados digitais para a comunidade de ensino e pesquisa, visando o seu uso para autenticação, assinatura digital e sigilo. Este curso capacita os profissionais envolvidos na implantação da Infraestrutura de Chaves Públicas Acadêmica em suas respectivas instituições. Ao final do curso , o aluno conhecerá os fundamentos necessários para o estabelecimento e manutenção dos principais componentes que constituem uma ICP: autoridades certificadoras e de registro.

ICPEdu Introdução a Infraestrutura de Chaves Públicas

LIVRO DE APOIO AO CURSO

Programa Interministerial RNP,

ICPEdu

Introdução a Infraestrutura de Chaves Públicas e Aplicações

que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes

Marcelo Carlomagno Carlos Jeandré Monteiro Sutil Cristian Thiago Moecke Jonathan Gehard Kohler Dayana Pierina Brustolini Spagnuelo

avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação ISBN 978-85-63630-47-6

Ministério da Ciência, Tecnologia e Inovação

9 788563 630476

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP, que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação Ministério da Ciência, Tecnologia e Inovação

ICPEdu

Introdução a Infraestrutura de Chaves Públicas e Aplicações Marcelo Carlomagno Carlos Jeandré Monteiro Sutil Cristian Thiago Moecke Jonathan Gehard Kohler Dayana Pierina Brustolini Spagnuelo

ICPEdu

Introdução a Infraestrutura de Chaves Públicas e Aplicações Marcelo Carlomagno Carlos Jeandré Monteiro Sutil Cristian Thiago Moecke Jonathan Gehard Kohler Dayana Pierina Brustolini Spagnuelo

Rio de Janeiro Escola Superior de Redes 2015

Copyright © 2015 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ

Diretor Geral Nelson Simões Diretor de Serviços e Soluções José Luiz Ribeiro Filho

Escola Superior de Redes Coordenação Luiz Coelho Edição Lincoln da Mata Revisão técnica Jean Martina Equipe ESR (em ordem alfabética) Adriana Pierro, Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato, Renato Duarte e Yve Abel Marcial. Capa, projeto visual e diagramação Tecnodesign Versão 2.0.2 Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br [email protected]

Dados Internacionais de Catalogação na Publicação (CIP) I61 ICPEdu Introdução a Infraestrutura de chaves públicas e aplicações / Marcelo Carlomagno Carlos ... [et. al.]; – Rio de Janeiro: RNP/ESR, 2014. 190 p. : il. ; 27,5 cm.

Bibliografia: p.173-174. ISBN 978-85-63630-47-6

1. Segurança de Computadores. 2. Criptografia. 3. RNP. I. Carlos, Marcelo Carlomagno. II. Título

CDD 005.8

Sumário Escola Superior de Redes A metodologia da ESR ix Sobre o curso x A quem se destina xi Convenções utilizadas neste livro xi Permissões de uso xii Sobre o autor xii

1. Fundamentos de criptografia Introdução 1 Definições 2 Criptografia 2 Criptografia clássica 2 Criptografia moderna 7 Criptografia simétrica 8 Como distribuir as chaves de maneira segura? 8 Como verificar se a mensagem não foi modificada? 8 Como ter certeza de que a mensagem foi realmente enviada por quem diz ter enviado? 8 Criptografia assimétrica 8 Funções-resumo (hash) 10 Assinatura digital 10 Criptografia assimétrica 11 Certificados digitais 11

iii

Lista de Certificados Revogados 12 Formatos 13

2. Assinatura digital Assinatura digital 15 Colisão de hash 17 Assinatura de longo prazo 19 Formatos de armazenamento 22 Legislação 23 Assinatura digital na ICP-Brasil 24 OpenDocument 26 OpenXML 27 PDF 27

3. Infraestrutura de Chaves Públicas X.509: ICP 33 Autoridades certificadoras 34 Autoridades de registro 35 Repositório 36 ACs Intermediárias 37 Certificação digital 37 Arquiteturas ICP 38 Caminhos de certificação 39 Políticas de Certificação 42 ICPEDU 42 ICP-Brasil 44

4. Servidor Web Seguro SSL/TLS 47 Autenticação 48 Sigilo 48 Em quem você confia? 51 Apache 52

iv

5. SGCI – Conceitos e visão geral SGCI – Visão geral 55 Árvore de Certificação 58 SGCI – Instalação 59 Perfis de usuário 61 Autoridades Certificadoras 63 Criação de AC Raiz 64 Campos avançados 65 Usuários 68 Configurações 70 Modelo de Certificado 71 Criação de AC Raiz 72

6. SGCI – Gerenciamento de Entidades Criação de Autoridades Certificadoras Intermediárias 75 Criação de Autoridades de Registro 78 Relacionamentos de Confiança 78 Emissão de certificados 82 Revogação de certificados 84 Lista de Certificados Revogados (LCR) 86 Cópias de Segurança (backups) 87 Registro de atividades (logs) 88

7. Gerenciando o ciclo de vida de chaves criptográficas O que é um HSM? 89 Para que serve? 90 Ciclo de vida de chaves criptográficas 91 Características de um HSM 92 Hardware 92 Software 93 Normas e Certificações 93 Conhecendo e Inicializando o ASI-HSM 93 Por que mais um HSM? 94 ASI-HSM – Diferenciais 94 v

ASI-HSM – Componentes 95 ASI-HSM – Características 95 ASI-HSM – Boas práticas de uso 98 ASI-HSM – Perfis de usuário 99 Perfil de Administração 99 Perfil de auditoria 100 Perfil de Operação 100 Operações comuns 100 Preparando a instalação 101 Instalação 101 Certificado SSL 104 Preparação do HSM 104 Preparação para uso 105 Configuração 106 Configuração dos parâmetros internos do HSM 107

8. Usando o ASI-HSM Criação dos perfis de usuário 109 Criação de administradores 110 Demais perfis (Audit e Oper) 112 Geração e liberação de chave para uso 113 Geração de chaves 113 Importação de chaves 116 Liberação (carga) de chaves para uso 118 Exportação de logs gerenciais 121 Procedimento de backup 124 Importação da chave de backup 127 Geração de backup 129 Restauração de backup 132 Ativar perfis de operação 134 Colocar o HSM em Modo Operacional 134 Atualização de firmware 135 Teste das Funções Criptográficas 139 Apagar as configurações do HSM 141

vi

9. Integração do SGCI com o ASI-HSM Credenciamento de entidade 145 Cerimônia de credenciamento 146

10. Federação CAFe e SAEC Federação 155 Elementos de uma Federação 157 Interação entre componentes 159 Federação CAFe 159 SAEC 160 Instalação e configuração 161 Utilização do SAEC 161 Administração do SAEC 163 Operação de Instituições 170 Modelos 171 Certificados 171

Bibliografia 173

vii

viii

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

ix

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso desenvolve as competências e habilidades necessárias para a administração e operação de entidades participantes da ICPEDU. O curso garante ao aluno o conhecimento necessário para o bom entendimento de uma Infraestrutura de Chves Públicas (ICP) como um todo. O curso é dividido em duas partes, cuja primeira é focada na aprendizagem dos conceitos básicos envolvidos em uma ICP, incluindo fundamentos de criptografia clássica e moderna, abrangendo tanto as técnicas de criptografia simétrica quanto assimétrica. Enquanto a segunda parte é mais prática e foca-se no gerenciamento da ICP, tanto no momento de criação de entidades, quanto nas pequenas tarefas do dia a dia. Durante o desenvolvimento do curso o participante terá a oportunidade de conhecer de perto o processo técnico de emissão de certificados, além de conhecelo também do ponto de vista de um usuário final e de um operador da ICPEDU. O foco está no domínio sobre os conceitos envolvidos em uma ICP e na familiarização do participante com as tecnologias ICPEDU. Tanto as relativas ao gerenciamento do ciclo de vida de certificados digitais, quanto de chave criptográficas. Ao final do curso o participante terá conhecimento sobre a gestão de Autoridades Certificadoras e de Registro, apresentando capacidades técnicoadministrativas para a utilização dos softwares de gestão e emissão de certificados digitais, e o módulo de segurança criptográfica. Tendo assim o conhecimento necessário para a implantar a ICPEDU em sua instituição. Cada participante adquirirá também conhecimento básico para compreensão de políticas de certificações e declarações de práticas de certificação, e base para se aprofundar no assunto. Além disso, os participantes terão aprendido também sobre as utilizações para certificados digitais e criptografia assimétrica, e realizado atividades práticas sobre as principais delas.

x

A quem se destina Especialistas de TI que desejam adquirir conhecimento sobre criptografia básica e Infraestrutura de Chaves Públicas, ou aperfeiçoar os seus conhecimentos sobre a ICPEDU e suas tecnologias. O curso destina-se também à membros de instituições de ensino que desejam implantar nestas a ICPEDU, e à pessoas com interesse de administrar ou operar Autoridades Certificadoras ou de Registro em seu dia a dia.

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide q Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo w Indica referência complementar disponível em site ou página na internet.

Símbolo d Indica um documento como referência complementar.

Símbolo v Indica um vídeo como referência complementar.

Símbolo s Indica um arquivo de aúdio como referência complementar.

Símbolo ! Indica um aviso ou precaução a ser considerada.

Símbolo p Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo l Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

xi

Permissões de uso Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: TORRES, Pedro et al. Administração de Sistemas Linux: Redes e Segurança. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

Sobre o autor Marcelo Carlomagno Carlos, doutor em segurança da informação pelo Information Security Group na Royal Holloway University of London, mestre e bacharel em ciência da computação pela Universidade Federal de Santa Catarina. Atuou como membro do grupo de operação da ICPEDU e também como desenvolvedor do mesmo projeto. Gerenciou a equipe de desenvolvimento e da implantação do projeto João de Barro, e fez parte da equipe responsável pela atualização da plataforma operacional da ICP-Brasil.” Jeandré Monteiro Sutil é mestre em Ciências da Computação pela Universidade Federal de Santa Catarina, em atuação há mais de 10 anos na área de segurança de sistemas computacionais. Dedica-se ao estudo e desenvolvimento de técnicas e protocolos de criptografia, assinatura digital e segurança de transações eletrônicas. Como pesquisador do LabSEC/ UFSC, atuou no projeto ICPEDU da Rede Nacional de Pesquisa, como coordenador da equipe de desenvolvimento do software embarcado no módulo de segurança criptográfica da ICP educacional. Participou ainda do projeto Ywapa, no desenvolvimento de solução nacional em gestão de certificados digitais para o Governo Federal. Assumiu a Diretoria Técnica da empresa BRy Tecnologia S.A., em 2010, dedicando-se atualmente à manutenção e ampliação do portfólio de soluções da empresa, com inovações que promovam a segurança e confiabilidade nos processos digitais. Cristian Thiago Moecke é mestre em ciência da computação pela Universidade Federal de Santa Catarina. Atuou desde sua graduação em projetos acadêmicos relacionados à ICP-Brasil (João de Barro) e ICP-EDU. Hoje atua como líder de projetos na BRy Tecnologia no desenvolvimento de soluções inovadoras para a segurança de documentos eletrônicos. Jonathan Gehard Kohler possui graduação em Ciências da Computação pela Universidade Federal de Santa Catarina (2007) e mestrado em Ciências da Computação pela Universidade Federal de Santa Catarina (2011). Foi pesquisador no Laboratório de Segurança em Computação (LabEC) entre 2006 e 2012, participando ativamente de diversos projetos envolvendo instituições como Rede Nacional de Ensino e Pesquisa (RNP) e Instituto Nacional de Tecnologia da Informação (ITI). Tem experiência na área de Segurança da Computação, com ênfase em Infraestruturas de Chaves Públicas, Gerenciamento de Certificados Digitais, Políticas de Certificação e Engenharia de Software. Atualmente é Analista de Sistemas no Tribunal de Justiça de Santa Catarina, atuando na área de Segurança em Computação.

xii

Dayana Spagnuelo é mestre em Ciência da Computação (2013) formada pela Universidade Federal de Santa Catarina. Atuou como bolsista no Laboratório de Segurança em Computação durante sua formação acadêmica, se envolvendo em diversos projetos multidisciplinares. Já lecionou criptografia básica e avançada para cursos de pósgraduação em nível de especialização em Gestão de Tecnologia da Informação e Segurança da Informação. Atualmente trabalha diretamente com pesquisa acadêmica na área de Segurança da Informação. Jean Everson Martina possui graduação em Ciencias da Computação pela Universidade Federal de Santa Catarina (2001), mestrado em Ciências da Computação pela Universidade Federal de Santa Catarina (2005 ) e doutorado em Ciências da Computação pela Universidade de Cambridge no Reino Unido (2011). É professor do Departamento de Informática e de Estatística da Universidade Federal de Santa Catarina desde 2013 e professor visitante da Universidade de Hertfordshire no Reino Unido desde 2010. Tem experiência na área de Ciência da Computação, com ênfase em Gerenciamento de Certificados Digitais, Protocolos Criptográficos, Sistemas Embarcados, Métodos Formais, e Engenharia de Software voltada a segurança da Informação.

xiii

xiv

1 Conhecer criptografia (Clássica, Moderna e Assimétrica); entender as funções de resumo (hash); aprender assinatura digital.

conceitos

Criptografia (Clássica, Moderna e Assimétrica); Funções de resumo (hash)‫;‏‬ Assinatura digital.

Introdução Criptologia.

q

11 Criptografia (kryptós: escondido; gráphein: escrita). 22 Ocultar informação dos outros. 33 Legível apenas para o destinatário. 11 Criptoanálise. 22 Decodificar mensagens sem conhecer a chave secreta. Esteganografia. 11 Ocultar mensagens dentro de outras. Nesta primeira sessão de aprendizagem, será feita uma revisão dos conceitos básicos da criptografia. Começaremos pela descrição do que é criptografia e passaremos pelos métodos clássicos e modernos, criptografia assimétrica e funções-resumo, até a assinatura digital. Existem duas formas básicas de proteger informações para que pessoas não autorizadas sejam excluídas do acesso ao seu conteúdo. A primeira delas é chamada de criptologia, que visa a codificar e decodificar dados para que apenas as partes interessadas possam compreendê-los. A criptologia é subdividida em criptografia e criptoanálise. O termo criptografia deriva das palavras kryptós (que significa “escondido”) e gráphein (“escrita”). Portanto, consiste em princípios e técnicas para transformar a informação original em um código ilegível, de modo que proteja seu conteúdo.

Capítulo 1 - Fundamentos de criptografia

objetivos

Fundamentos de criptografia

1

A segunda é a esteganografia (do grego, “escrita escondida”), que consiste na ocultação de mensagens dentro de outras. O princípio da esteganografia é camuflar a presença da informação, para que pessoas desautorizadas não detectem sua existência. Um exemplo bastante comum é o uso de imagens para a ocultação de textos. É importante destacar a diferença entre criptografia e esteganografia. A primeira impede a leitura da mensagem, enquanto a segunda oculta a existência da informação. Também é possível usar as duas técnicas simultaneamente, “escondendo” um texto após ter sido cifrado.

Definições

q

11 Texto claro. 11 Texto cifrado. 11 Cifrar. 11 Decifrar. 11 Chave. Antes de iniciar, é preciso conhecer o significado de alguns termos que serão utilizados ao longo deste curso: 11 Texto claro: texto original, não cifrado; 11 Texto cifrado: texto ilegível, não compreensível (exceto para o destinatário); 11 Cifrar: transformar texto plano em texto cifrado; 11 Decifrar: transformar texto cifrado em texto plano; 11 Chave: conjunto de dados utilizados para cifrar e decifrar.

Criptografia

ICPEdu Introdução a Infraestrutura de Chaves Públicas e Aplicações

Texto claro

2

Cifrar

Texto cifrado

Decifrar

Texto claro

Beto

Alice

Chave

Figura 1.1 Criptografia simétrica.

Chave

A criptografia é muito usada durante a troca de mensagens entre duas pessoas. Por exemplo: se Beto deseja enviar uma mensagem cifrada para Alice, ele inicialmente compartilha uma chave secreta com ela. Depois, Beto cifra o texto com essa chave e o envia para Alice. A partir deste momento, qualquer um que interceptar a mensagem não terá acesso ao seu conteúdo, uma vez que apenas Beto e Alice conhecem a chave para decifrá-la. Quando Alice recebe a mensagem, ela utiliza a chave e obtém a mensagem original novamente.

Criptografia clássica Transposição: 11 Original: help. 11 Cifrado: HLEP.

q

Substituição:

q

1 Original: help. 1 Cifrado: KHOS. Na criptografia clássica, uma cifra de transposição se refere à mudança de cada letra no texto claro para outra posição. Ao cifrar a palavra “help”, por exemplo, a transposição pode ser feita (entre outras possíveis formas) da seguinte maneira: 11 Escrever a mensagem de forma que as letras alternadas fiquem separadas nas linhas de cima e de baixo; 11 Escrever a mensagem cifrada, colocando primeiro as letras da linha superior e depois as da linha inferior. Com esses passos, a palavra “help” ficaria cifrada como HLEP. Um exemplo clássico da utilização de cifra de transposição é o citale espartano, que consiste em um bastão de madeira, no qual é enrolada uma tira de couro. O remetente escreve a mensagem ao longo da tira e depois a desenrola, enviando apenas a tira ao destinatário. O destinatário, ao receber a mensagem, precisará de um citale com o mesmo diâmetro para enrolar a tira, e, dessa forma, decodificar o texto e ler a mensagem original. Já a cifra de substituição é um método de criptografia que opera de acordo com um sistema predefinido. Para estabelecer de que forma são feitas as substituições, há dois alfabetos, o original e o cifrado (que contém as letras em posições diferentes). Para realizar a cifragem a partir dos dois alfabetos, é preciso obter a posição da letra que desejamos codificar no alfabeto original e substituí-la pela letra que está na mesma posição no alfabeto cifrado.

Figura 1.2 Citale espartano (século V a.c.).

11 Cifradores monoalfabéticos.

q

22 Rearranjo do alfabeto original. 22 400.000.000.000.000.000.000.000.000 possibilidades. 11 Alfabeto original. 22 abcdefghijklmnopqrstuvwxyz

22 JOFPZIDKTMAEGQCSLUVWYXHNBR 11 Texto original. 22 Cifrar. 11 Texto cifrado. 22 FTIUJU. Por exemplo, utilizando os alfabetos original e cifrado do slide, para cifrar a palavra “cifrar”: obtemos inicialmente a posição da letra “c”, no alfabeto original, e a substituímos pela letra localizada na mesma posição no alfabeto cifrado, no caso, a “F”. Depois, repetimos o processo para o “i”, que é substituído por “T”, e assim por diante.


11 Alfabeto cifrado.

3

Os cifradores monoalfabéticos se caracterizam por utilizar apenas um alfabeto cifrado. Porém, é possível dispor de mais de um alfabeto cifrado, o que origina os cifradores polialfabéticos. Cifrador de César:

q

11 Texto original: escola superior de redes. 22 Texto cifrado: HVFROD VXSHULRU GH UHGHV. 11 Alfabeto original: 22 abcdefghijklmnopqrstuvwxyz 11 Alfabeto cifrado: 22 DEFGHIJKLMNOPQRSTUVWXYZABC Cifrar: 11 E(x) = (x+3) mod 26 exemplo: E(0) = 3 mod 26 = 3 Decifrar: 11 D(x) = (x-3) mod 26 exemplo: D(3) = 0 mod 26 = 0 Júlio César utilizava cifradores de substituição monoalfabéticos com frequência em suas batalhas. O método que ele empregava era simplesmente substituir a letra desejada por outra que estivesse três casas à frente no alfabeto. Para decifrar, bastava realizar o procedimento oposto, obtendo a letra que estivesse três casas atrás.

... X

Y

Z

A

B

C

D

E

F

A

B

C

D

E

F

G

H

I

...

11 Cifrador de César.

q

11 Características:


22 Simples de ser utilizado (manualmente).

4

22 Pode-se utilizar outras chaves (diferente de 3). 11 Desvantagens: 22 Fácil de ser “quebrado” (25 chaves possíveis). Embora não tenha resistido até nossa época, uma vez que é facilmente quebrado, hoje em dia o cifrador de César se mostrou eficiente naquele tempo, apresentando vantagens bem interessantes: 11 É simples de ser usado, mesmo manualmente, possibilitando rapidez ao cifrar e decifrar uma mensagem; 11 Permite utilizar diferentes chaves (deslocamentos, neste caso), alterando o número de casas a serem deslocadas no alfabeto cifrado. Contudo, esse tipo de cifragem pode ser facilmente quebrado, uma vez que existem apenas 25 possíveis alfabetos cifrados. Uma simples variação desse método, que, em vez de fazer deslocamentos, embaralhe o alfabeto cifrado, pode aumentar o número de alfabetos para 400.000.000.000.000.000.000.000.000 possibilidades.

Figura 1.3 Cifrador de César.

q

11 Ataques. 11 Surgimento da criptoanálise. 22 Decifrar a mensagem sem conhecer a chave. 11 Origem árabe (século IX): 22 Método para quebrar a cifra de substituição monoalfabética. 22 Análise de frequência. 33 Contar a frequência dos caracteres no texto. 33 Digramas. 33 Trigramas. 11 Origem na Europa apenas no século XV. Com o advento da criptoanálise, no século IX, surgiram os ataques sobre as cifras existentes. O princípio básico da criptoanálise é decifrar a informação sem que se conheça a

chave. Os árabes foram os pioneiros nessa área. A Europa adotou a criptoanálise somente no século XV. Os árabes criaram ataques sobre os cifradores monoalfabéticos usando o conceito de análise de frequência. Basicamente, consiste em contar o número de ocorrências de cada letra no texto cifrado e comparar o resultado com a frequência dos caracteres em um texto claro no idioma de origem. Por exemplo, em inglês, o caractere mais comum é o “e”. Se no texto cifrado a letra de maior frequência for o “R”, pode-se imaginar que o “e” foi substituído pelo “R” durante o processo de cifragem, e assim por diante. Um adicional importante a esse método é a contagem de digramas e trigramas, sequências de dois e três caracteres que aparecem com mais frequência no texto cifrado, e substituí-los pelos que

10

8

6

4

2

Tabela 1.4 Tabela de frequências.

e t a o i n s h r d l c u m w f g y p b v k j x q z

Letter


Apenas no século XVI surgiram os principais criptoanalistas europeus, como Giovanni Soro, Philibert Babou e François Viete.

12,7 12

Relative Frequency (in percent)

l

aparecem com maior frequência em um texto claro comum.

5

Cifradores polialfabéticos.

q

11 Mais de um alfabeto cifrado. Alfabeto original: 11 abcdefghijklmnopqrstuvwxyz 11 Alfabeto cifrado 1: 22 JCHFZOTXRSLDWBPIVEAYGNMQUK 11 Alfabeto cifrado 2: 22 PKBFLRIJEQTMYOAVHDCUXGSNZW Texto original: hello. Texto cifrado: XLDMP. Com o intuito de eliminar ou ao menos dificultar os ataques por análise de frequência, surgiram os cifradores polialfabéticos, que usam mais de um alfabeto para cifrar um texto. Dessa forma, uma mesma letra pode ser substituída no texto cifrado por 2 ou mais caracteres. No exemplo dado, a letra “l”, que em um cifrador monoalfabético seria substituída apenas por uma letra, foi substituída por “D” e “M”.

a b c d ... z a A B C D ... Z b B C D E ... A c C D E F ... B . . . . . ... . z Z A B C ... Y


Exemplo: 11 Texto original: bazar; 11 Palavra-chave: chave; 11 Texto cifrado: DHZVV. Um dos cifradores polialfabéticos mais famosos foi o de Vigenere, por ser de fácil entendimento e implementação. A cifra de Vigenere utiliza 26 alfabetos para cifrar a mensagem. O quadrado de Vigenere é um alfabeto normal, seguido de 26 alfabetos cifrados, cada um deslocando uma letra em relação ao anterior. Para ilustrar como se realiza o processo de cifragem a partir dessa técnica, vamos cifrar a palavra “bazar” e, para isso, usar a palavra-chave “chave” para realizar a cifragem do texto. Vale lembrar que, caso a palavra-chave seja menor que o texto a ser cifrado, esta deve ser repetida até que, para cada letra do texto a ser cifrado, exista uma letra da palavra-chave correspondente. Para cifrar a letra “b”, inicialmente identificamos a letra correspondente na palavra-chave, que nesse caso é “c”, e por sua vez define uma linha do quadrado a ser usada. Deve-se olhar para a linha que se inicia com a letra “c” e pegar o caractere dessa linha que cruza com a coluna iniciada com o caractere “b”, e obtemos a letra “D”. O processo deve ser repetido para cada letra da mensagem a ser cifrada, resultando no texto cifrado “DHZVV”. Note que a letra “a”, repetida no texto claro, é cifrada em dois caracteres diferentes, “H” e “V”. 6

Figura 1.5 Quadrado de Vigenere.

Máquina Enigma.

q

11 1918 – Alemanha. 11 Usada pelos nazistas durante a Segunda Guerra Mundial. 11 Três rotores. Enigma é uma máquina de criptografia com rotores, utilizada tanto para cifrar como para decifrar mensagens. Criada pelos alemães em 1918, leva a fama de ter sido um equipamento que produzia cifras quase impossíveis de serem decifradas. O código foi, no entanto, quebrado, e a informação contida nas mensagens produzidas por essa máquina é geralmente tida como responsável pelo fim da Segunda Guerra Mundial,

w

pelo menos um ano antes da previsão de término.

Um vídeo que demonstra o funcionamento da máquina Enigma pode ser encontrado em: http://goo.gl/9GyPB5 (em inglês).

Figura 1.6 Máquina Enigma.

Criptografia moderna Cifradores de blocos. 11 Dividem a mensagem em blocos de tamanho fixo (exemplo: 128 bits). 11 DES ou AES.

A era da criptografia moderna começa realmente com Claude Shannon, em 1949. Nesse ano, ele publicou um artigo chamado “Communication Theory of Secrecy Systems com Warren Weaver”, que foi o primeiro passo para o estabelecimento de uma base teórica sólida para a criptografia e a criptoanálise. Em 1976, foi publicado pelo governo americano o algoritmo Data Encryption Standard (DES), aberto de criptografia simétrica, selecionado pelo NIST em um concurso. O DES foi o primeiro algoritmo de criptografia disponibilizado abertamente ao mercado. Entre os modernos algoritmos de criptografia simétrica, podemos agrupar duas principais categorias: 11 Cifradores de blocos: dividem a mensagem em blocos de tamanho fixo durante a cifragem dos dados. Podemos citar o DES e o AES; 11 Cifradores de fluxo: cifram cada dígito do texto plano por vez. Usados com maior frequência quando é díficil conhecer o tamanho do texto plano.


l Todos os algoritmos apresentados até agora, desde os clássicos, têm características simétricas, ou seja, para decifrar um texto, basta usar o procedimento oposto ao que foi realizado durante a cifragem dos dados.

q

7

Já entre os cifradores de fluxo, que são usados com menor frequência que os de bloco, o algoritmo mais conhecido atualmente é o RC4.

Electronic Codebook (ECB) mode encryption Plaintext

Key

Block Cipher Encryption

Plaintext

Key

Ciphertext


Ciphertext

Plaintext

Key


Figura 1.7 Cifradores de blocos.

Ciphertext

Criptografia simétrica Como distribuir as chaves de maneira segura?

q

11 De que forma verificar se a mensagem não foi modificada? 11 Como ter certeza de que a mensagem foi realmente enviada por quem diz tê-la enviado? Ao finalizar esse breve estudo sobre criptografia simétrica, podemos notar que, embora esses algoritmos sejam bastante eficientes, surgem algumas questões que não são tratadas por essa subárea da criptografia. São elas:

Como distribuir as chaves de maneira segura? Aprendemos até agora que, para uma comunicação entre duas ou mais partes ser realizada de forma segura, é necessário que as partes conheçam previamente a chave. Porém, como fazer isso de maneira segura? Como garantir que apenas quem eu desejo conheça essa chave?


Como verificar se a mensagem não foi modificada?

8

Como podemos detectar se alguém não autorizado conseguiu ter acesso à mensagem e a modificou antes que ela fosse entregue?

Como ter certeza de que a mensagem foi realmente enviada por quem diz ter enviado? Como saber se não há uma terceira parte não autorizada que descobriu a chave secreta e está enviando mensagens em nome de outras pessoas?

Criptografia assimétrica Par de chaves.

q

11 Pública e Privada. Confidencialidade. Com o intuito de responder às questões levantadas, além de outras, surgiu a Criptografia Assimétrica. Sua principal diferença em relação à Criptografia Simétrica é que usa o conceito de par de chaves para cifrar e decifrar mensagens.

Dessa forma, foi criado um par de chaves, sendo uma chave considerada pública, que pode ser disponibilizada livremente, e outra privada, que deve ser mantida apenas em posse de seu detentor. Essas chaves são complementares, ou seja, uma mensagem cifrada com uma chave deve ser decifrada por sua chave correspondente. Com esse conceito, se Beto deseja enviar uma mensagem sigilosa para Alice, ele deve cifrar o conteúdo de sua mensagem utilizando a chave pública de Alice (de domínio público) e enviar para ela o texto cifrado. Alice, por sua vez, ao receber a mensagem cifrada, usa sua chave privada para decifrar o conteúdo. Dessa forma, podemos garantir que apenas Alice conseguirá decifrar o texto enviado por Beto. Este processo é esquematizado na figura 1.8.

Texto claro

Cifrar

Texto cifrado

Decifrar

Texto claro

Beto

Alice

Figura 1.8 Envio de mensagem de Beto para Alice.

Chave pública de Alice

Chave privada de Alice

q

Par de chaves: 11 Pública e Privada. Autenticidade. Por outro lado, se desejamos provar que a mensagem recebida foi realmente enviada pela

pessoa que diz tê-la enviado, o procedimento, esquematizado na figura 1.9 é descrito a seguir: Beto cifra o conteúdo da mensagem com sua chave privada e a envia para Alice, que, por sua vez, utiliza a chave pública de Beto para obter o texto claro. Se a mensagem foi corretamente decifrada com a chave pública de Beto, pode-se entender que a mensagem cifrada foi gerada com a chave privada correspondente (a qual somente Beto tem acesso). Com isso, podemos ter certeza de que Beto criou a mensagem.

Texto claro

Cifrar

Texto cifrado

Decifrar

Texto claro

Figura 1.9 Envio de mensagem de Alice para Bob.

Alice

Chave privada de Beto 11 Diffie Hellman, 1976.

Chave pública de Beto

q

11 Principais algoritmos: 22 RSA. 22 DAS. O conceito de criptografia assimétrica foi publicado em 1976 por Diffie Hellman e tem como seus algoritmos mais famosos o RSA, criado em 1977 por Rivest, Shamir and Adlemane, e o DSA, criado pela NSA.


Beto

9

Funções-resumo (hash) 11 Procedimento ou função matemática para transformar um conjunto de dados em

q

outro conjunto de tamanho fixo (resumo criptográfico). 11 Impossível obter a mensagem original a partir do resumo criptográfico. 11 Difícil colisão. Uma função-resumo, também conhecida como função de hash, é uma função matemática para transformar um conjunto de dados em uma pequena sequência de dados de tamanho fixo (resumo criptográfico). Essa sequência busca identificar um arquivo ou informação unicamente. Outra característica importante referente às funções-resumo é que não deve ser possível obter a informação original a partir de um valor de hash. Como a sequência do hash é limitada (128, 256, 512 bits etc.), podem existir colisões (sequências iguais para entradas diferentes). Quanto maior a dificuldade de produzir colisões, mais eficiente é o algoritmo.

Assinatura digital A assinatura digital é um método para prover características, em meio digital, a um documento, de maneira semelhante a assinaturas feitas em papel. A utilização da assinatura digital gera uma prova de quem é o autor, ou emissor, da mensagem. Além disso, provê as seguintes propriedades: 11 Autenticidade: busca garantir que a mensagem é autêntica, que o autor da mensagem é realmente quem diz ser; 11 Integridade: permite verificar se a mensagem enviada é a mesma mensagem que foi recebida ou se sofreu alguma alteração; 11 Irretratabilidade: emissor não pode negar a autenticidade da mensagem.


O processo de assinatura consiste em gerar o resumo criptográfico da mensagem e cifrar

10

esse resumo com a chave privada do assinante. Para a verificação de uma assinatura digital, é necessário decifrar a assinatura gerada com a chave pública do assinante e comparar o resultado dessa operação com o resumo do documento original.

Documento assinado

Texto plano

Texto plano

Assinatura Função Resumo

Cifragem

Resumo

Figura 1.10 Assinatura digital.

Chave privada

Criptografia assimétrica 11 Como distribuir as chaves de maneira segura?

q

11 Como verificar se a mensagem não foi modificada? 11 Como ter certeza de que a mensagem foi realmente enviada por quem diz ter enviado? 11 Como vincular uma chave a informações de seu detentor? Até este momento, conseguimos, por meio dos conhecimentos obtidos, solucionar três problemas com os quais nos deparamos: 11 Distribuir as chaves de maneira segura, o que foi resolvido pela utilização de criptografia assimétrica; 11 Detectar se uma mensagem foi modificada, o que foi resolvido pela assinatura digital; 11 Ter certeza de que a mensagem foi enviada por quem diz tê-la enviado, o que foi resolvido com o uso de assinaturas digitais. Porém, surge uma nova pergunta: já que uma chave é um conjunto de bits, como podemos saber quem é o seu detentor?

11 Necessidade de relacionar uma chave a um indivíduo. 11 Kohnfelder (1978) relaciona um usuário a uma chave. 11 Características importantes: 22 Objeto puramente digital. 22 Contém informações do detentor da chave privada. 22 Criado por uma entidade confiável. 22 Possível delimitar suas possíveis aplicações. 22 Fácil determinar se foi violado. 22 Possível verificar seu estado atual.

q Capítulo 1 - Fundamentos de criptografia

Certificados digitais

11

Um dos principais problemas da criptografia de chaves públicas é determinar quem possui a chave privada correspondente. Para solucionar esse problema, foi proposto o uso de Certificados Digitais de Chaves Públicas ou simplesmente certificados. Cada um contém a chave pública e a identificação da entidade que controla a respectiva chave privada. Segundo R. Housley, um certificado ideal deve conter uma série de características importantes: 11 Ser um objeto puramente digital, para que possamos distribuí-lo e processá-lo automaticamente; 11 Conter informações sobre o detentor da chave privada; 11 Ser fácil de determinar se o certificado foi recentemente emitido; 11 Ser criado por uma entidade confiável, em vez do próprio usuário que detém a chave privada; 11 Uma vez que uma entidade confiável pode criar vários certificados, inclusive para um mesmo usuário, deve ser fácil diferenciá-los; 11 Ser fácil determinar se o certificado foi forjado ou se é genuíno; 11 Ser à prova de violação, de modo que ninguém consiga alterá-lo; 11 Ser possível verificar de forma imediata se alguma informação no certificado não é mais válida; 11 Deve-se poder determinar para quais aplicações o certificado é válido. Os certificados digitais x.509 apresentam em sua estrutura as características listadas nesses itens. Porém, os itens h e j não aparecem diretamente no conteúdo do certificado, pois são apresentadas apenas referências dentro do certificado para onde podemos obter tal informação. Tais características são providas a partir das Listas de Certificados Revogados (item


h) e Políticas de Certificação (item i). Versão Número de série Emissor Validade Sujeito Chave Pública Extensões

Figura 1.11 Campos de um certificado digital X.509.

Assinaturas da AC

Lista de Certificados Revogados 11 Necessidade de tornar um certificado inválido.

q

22 Impossível apagar todas as cópias existentes de um certificado. 11 Objeto puramente digital. 11 Motivos para revogação. 22 Modificação de um certificado. 22 Comprometimento da chave privada. 22 Encerramento de uso. Para que seja possível determinar se as informações contidas em um certificado digital são válidas em um determinado momento, foram criadas as listas de certificados revogados (LCR), que são emitidas periodicamente por uma Autoridade Certificadora ou por uma entidade para a qual foi delegada essa função, que contém a relação dos certificados que não são mais válidos.

12

Uma LCR é um objeto digital, o que permite a distribuição, o processamento e a validação de forma eletrônica, de maneira semelhante a um certificado. A LCR é assinada pela entidade que a emitiu, permitindo a verificação de sua integridade, e possui dois campos de data, um com a de sua emissão e outro com a de expiração, além da lista dos números seriais dos certificados emitidos, a data da revogação do certificado e extensões (opcional). Vários motivos podem gerar a necessidade de revogação de um certificado digital: 11 A atualização de dados nele contidos; 11 Comprometimento da chave privada; 11 Cancelamento do uso do certificado; 11 Comprometimento da chave privada da Autoridade Certificadora; 11 Entre outros.

Formatos

q

Abstract Syntax Notation (ASN.1). 11 Estrutura de dados. 11 Codificar e Decodificar dados. 22 Certificados. 22 LCRs.

ExampleQuestion ::= SEQUENCE { trackingNumber INTEGER,

question

IA5String

} Os certificados digitais e as listas de certificados revogados são armazenados em arquivos e sua estrutura, ou seja, a forma como seus dados são estruturados, é definida ao usar o Abstract Syntax Notation One (ASN.1). A ASN.1 é uma notação padrão que permite a representação, codificação ou decodificação e transmissão de dados. Esse formato contém uma série de regras para a descrição e a codificação das estruturas de forma precisa, evitando ambiguidades.

no formato ASN.1. Base64:

q

11 Codifica dados binários tratando-os numericamente em uma representação de base 64. Distinguished Encoding Rules (DER): 11 Representa uma estrutura ASN.1. Privacy Enhanced Mail (PEM): 11 Base64 com cabeçalhos. Base64 é um método de codificação de dados para transferência. É geralmente utilizado para codificar dados binários, traduzindo-os para uma representação em base 64. O conjunto de caracteres é constituído por 64 caracteres de “a” a “z”, “A” a “Z” e “0” a “9”. O caractere “=” é usado como um sufixo especial; a recomendação RFC 989 definiu que o símbolo “*” pode ser


O exemplo apresentado no slide demonstra como uma lista de exercícios seria representada

adotado para delimitar dados codificados, mas não cifrados. 13

O Distinguished Encoding Rules (DER) é uma sintaxe para a transferência de mensagens especificadas pela ITU dentro do X.690. Trata-se de um método para codificar dados, como um certificado digital x.509. Já o Privacy Enhanced Mail (PEM) é uma proposta criada para prover segurança em e-mails por meio da utilização de criptografia de chaves públicas. Exemplo de arquivo no formato PEM:

-----BEGIN CERTIFICATE----MIIDtTCCAp2gAwIBAgIJALgslSVdQqJEMA0GCSqGSIb3DQEBBAUAMEUxCzAJBgNV BAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBX aWRnaXRzIFB0eSBMdGQwHhcNMDgwOTIyMDMzNTU1WhcNMDgxMDIyMDMzNTU1WjBF skW3EjU1jQpoU5ovuV4UwLHs73mkz1jRoFxPYW1N7x3b1eXIlpqGZmv6nOc3R3Xm pIlkUhZ+8cp8G262od50qudiAA4BNfxoK900VCJMlgkGtJAuCIR32NDmgImgqs6t v3ESAjzOpwafksne2jcnYTt0v8FBli0+MWC9ON709I4JTC+XNvRBZEMF88n+n73h oNVnZ2qECuiPwTHAjIY3v/5VwYu+vn0Rh6jradZmIGqg8Uq5/CH6aWM=


-----END CERTIFICATE-----

14

q

2 objetivos

Assinatura digital Compreender de forma aprofundada o funcionamento de assinaturas digitais e seus formatos de armazenamento no Brasil; Aprender os conceitos básicos sobre carimbo de tempo; Conhecer os documentos eletrônicos compatíveis com assinatura digital.

conceitos

Assinatura digital (colisão de hash, carimbo do tempo e formatos de armazenamento); Assinatura de documentos eletrônicos (OpenDocument, OpenXML e PDF); Softwares de Assinatura Digital.

Assinatura digital

q

11 Autenticidade/Não repúdio. 11 Integridade.

Remetente resumo criptográfico

0101001 0110111 0100011 cifra

1101101 0110011 0100110 Figura 2.1 Assinatura digital.

Olá mundo!

Olá mundo! 1101101 0110011 0100110

resumo criptográfico 0101001 0110111 0100011

=? decifra

1101101 0110011 0100110

1101101 0110011 0100110

Nesta sessão, exploraremos mais a fundo o tema “Assinatura Digital”. Uma vez compreendido o conceito de hash e de criptografia assimétrica, apresentados na sessão anterior, a ideia básica da assinatura digital torna-se relativamente simples. A assinatura digital lembra, em muitos aspectos, a assinatura “de próprio punho”. Ela traz algumas propriedades importantes para os documentos eletrônicos: 11 Integridade: permite verificar se o documento não foi alterado após a aplicação da assinatura; 11 Autenticidade: permite verificar se um documento realmente foi gerado e aprovado

Capítulo 2 - Assinatura digital

Olá mundo!

Receptor

pelo signatário; 15

11 Não repúdio: impede que o signatário recuse a autoria ou conhecimento do documento. Mas a assinatura digital também tem diferenças com relação à assinatura de próprio punho. Algumas mais e outras menos evidentes, mas que merecem atenção do usuário. Nesta sessão, aprofundaremos os conhecimentos no tema, buscando compreensão teórica e prática das principais características do processo de assinatura digital. O processo de assinatura digital faz uso da criptografia assimétrica, ou seja, faz uso de duas chaves: 11 Uma pública, disponibilizada livremente, normalmente associada a dados pessoais do signatário através de um certificado digital; 11 Uma privada, mantida protegida em sigilo pelo signatário. Além disso, o processo ainda usa as funções resumo, ou funções hash. O procedimento de assinatura digital consiste nos seguintes passos: 11 O assinante gera um resumo criptográfico da mensagem; 11 O assinante cifra o resumo com sua chave privada. Esse resumo criptográfico cifrado é uma assinatura digital da mensagem, e deve ser encaminhado ao destinatário anexado à mensagem. Para verificar a assinatura, o destinatário executa os seguintes passos: 11 1: tendo em mão a chave pública, que ele sabe ser do remetente, o destinatário decifra a assinatura, obtendo o resumo; 11 2: com a mensagem em mão, gera novamente, de maneira independente, o resumo criptográfico da mensagem; O destinatário compara os resumos obtidos no passo 1 e no passo 2: 11 Se ambos resumos são iguais, a assinatura é válida; 11 Se os resumos não são iguais, a assinatura é inválida.


A propriedade de autenticidade é verificada no passo 1. Se outra chave privada, que não aquela associada à chave pública que o destinatário conhece, tivesse sido usada para cifrar o resumo criptográfico da assinatura, ao decifrá-lo o hash original não seria obtido. Já a propriedade da integridade é verificada no passo 2. Se a mensagem sofrer uma alteração, após a aplicação da assinatura, o resumo criptográfico calculado pelo destinatário não vai coincidir com aquele obtido pela decifragem da assinatura. É importante notar que, apesar de guardarem semelhanças com as propriedades providas por uma assinatura de próprio punho, as propriedades da assinatura digital mostram-se mais fortes. Quanto à integridade, um documento assinado em papel pode sofrer adulterações. O banco pagará por um cheque o valor que nele consta, sem verificar se o valor foi colocado antes ou depois da assinatura. Um pequeno ponto de tinta que não altere um contrato não invalidará a assinatura. Já no caso de uma assinatura digital, um simples bit modificado na mensagem torna a assinatura inválida. Um “cheque em branco digital”, se existisse, uma vez assinado não poderia receber um valor sem invalidar a assinatura. Já no que diz respeito à autenticidade, também há mudança sensível. Enquanto a verificação de uma assinatura de próprio punho depende da especialidade do grafoscopista, a verifi16

cação da autenticidade da assinatura digital, considerando-se o sigilo da chave privada, é puramente matemática e reside na confiança nos algoritmos usados. Outras diferenças tornam-se evidentes em uma análise mais minuciosa, como o fato de a assinatura não fazer mais parte do documento, e sim ser algo que pode ser desanexado. Exploraremos algumas dessas diferenças com mais atenção durante esta sessão.

Colisão de hash

q

11 O hash tem tamanho fixo. Então existe um número finito de “hashes”. 11 Existem infinitas mensagens, portanto: 22 Mais de uma mensagem tem o mesmo hash. = Colisão de hash Uma das particularidades da assinatura digital é que a confiança estabelecida sobre ela

depende da confiança nos algoritmos envolvidos. E um dos algoritmos utilizados é um algoritmo de resumo criptográfico ou hash. Ao olhar com mais atenção para a função de resumo, percebem-se algumas características importantes. Entre elas, destaca-se o fato de que a função resumo tem tamanho fixo limitado. Por exemplo, o MD5 tem 128 bits, o SHA-1 tem 160 bits. Mas se olharmos para as mensagens, não há limite de tamanho. Podemos escrever quantas mensagens desejarmos, potencialmente infinitas mensagens. Dessa forma, torna-se evidente que necessariamente mais de uma mensagem vai ter o mesmo hash. Esse evento recebe o nome de colisão de hash, e é crítico para a confiança em uma assinatura digital.

Olá mundo!

Atacante

0101001 0110111 0100011 cifra

1101101 0110011 0100110

Figura 2.2 Ataque de colisão de hash.

Doação do meu carro

Olá mundo!

Olá mundo!

1101101 0110011 0100110

1101101 0110011 0100110

Juiz

resumo criptográfico

Olá mundo!

0101001 0110111 0100011

= !!! decifra

1101101 0110011 0100110

0101001 0110111 0100011

A figura 2.2 ilustra um ataque fazendo uso da colisão de hash. Suponha que um atacante obtém um documento que tem o mesmo hash de uma mensagem já assinada, ou então obtém duas mensagens com mesmo hash: uma inocente, que ele convence a vítima a assinar, e outra maliciosa. Uma terceira pessoa, a quem chamamos de “juiz”, ao receber a mensagem maliciosa com a assinatura original anexada aceitará aquela assinatura como válida.


Vítima resumo criptográfico

17

Exemplo de colisão.

q

11 Ok, mas... funciona? Já existem exemplos de: 11 Dois arquivos HTML diferentes, com mesmo hash MD5. 11 Dois arquivos PostScript diferentes, com mesmo hash MD5. 11 Dois Certificados Digitais diferentes, com mesmo hash MD5. A pergunta que pode ocorrer é: “Mas isso funciona na prática?” A resposta é sim. Existem diversos exemplos práticos, disponíveis publicamente, que demonstram a possibilidade de se obter colisões reais de hash com efeitos práticos. Demonstraremos na sessão: 11 Dois arquivos HTML: páginas de duas empresas diferentes, com mesmo resumo MD5; 11 Dois arquivos PostScript, com mesmo resumo MD5: 22 Uma carta de recomendação; 22 Uma concessão de acesso a dados sigilosos; 11 Dois certificados digitais com mesmo resumo MD5. 11 Sem pânico.

q

11 É possível que duas mensagens tenham a mesma assinatura, mas... 11 ...uma boa função de hash tem as seguintes características: 22 É difícil, tendo h(m), achar m 22 É difícil, tendo m1, encontrar m2 tal que h(m1)=h(m2) 11 E, mais difícil que encontrar uma colisão, é encontrar uma colisão “útil”. 11 Por quanto tempo você quer que a assinatura continue válida? Se você ficou assustado, o objetivo foi alcançado. Agora, para tentar tranquilizá-lo novamente. Como foi dito, ao mesmo tempo em que a assinatura guarda semelhanças com a assinatura de próprio punho, ela tem suas particularidades, que precisam ser bem compre-


endidas. Corretamente utilizada, ela dá garantias de segurança que podem ser consideradas

18

muito mais fortes. Voltando para a questão específica das funções hash, cabe relembrar algumas características importantes que dificultam sensivelmente os ataques propostos: 11 Boas funções de hash, em geral, são virtualmente randômicas. 11 Uma pequena modificação na entrada tem de causar enorme modificação na saída (exemplo: ~50% dos bits). Com essas características, mesmo que se encontrem colisões, dificilmente elas serão “úteis”, no sentido de que serão duas mensagens inteligíveis, ao menos enquanto o algoritmo ainda é considerado seguro, o que não é o caso do MD5, no qual já existem diversas fragilidades conhecidas e que não deveria mais ser utilizado em qualquer aplicação crítica. Normalmente, é uma questão de tempo: se sua assinatura não precisa ser validada a longo prazo, apenas amanhã e nunca mais, não há muito com o que se preocupar. Mas, no mundo real, muitas aplicações precisam que a assinatura continue válida por muito tempo. Em alguns casos, até para sempre!

Assinatura de longo prazo

q

Toda assinatura digital vai expirar um dia.

Assinatura Certificado A3 Ac Cert A3 Ac Credenciada Ac Raiz

Tempo Figura 2.3 Validade de assinaturas comuns.

Expedição do Certificado do Signatário

Expedição do Quebra de Certificado Algoritmos de AC

Além da questão do algoritmo de hash, que pode um dia ficar vulnerável e dessa forma limitar a confiança em uma assinatura digital, outros aspectos limitam sua validade. Uma assinatura digital, na prática, faz uso de certificados digitais. O certificado digital é um conjunto de dados que inclui uma chave pública, e informações sobre o detentor da chave privada associada à sua chave pública, além de um período de validade onde o certificado deve ser considerado válido (não antes e não depois de certo intervalo de tempo). Para garantir a confiabilidade dessas informações, o próprio certificado é assinado digitalmente, por uma terceira parte confiável, que também tem seu certificado assinado por outra entidade, formando o que se chama de cadeia de certificação. Estudaremos esse assunto com mais detalhes na seção 3. Quando a chave privada de um certificado digital é comprometida, a autoridade que a emitiu coloca o certificado em uma “Lista de Certificados Revogados”, que está disponível para consulta e é assinada pela autoridade. Acontece que, para evitar o crescimento infinito da lista, os certificados expirados são removidos dessa lista. E aí surge mais um problema: como garantir, após a expiração do certificado, que o certificado não estava revogado quando foi usado? Ou pior ainda, e no futuro, quanto essas ACs nem existirem mais? Por fim, além do algoritmo de hash, outros algoritmos estão envolvidos no processo, como os de geração das chaves e de cifragem. Se ocorrer quebra de algum dos algoritmos criptográficos envolvidos, a assinatura também fica comprometida, sem ser possível verificar se ela foi feita quando esses problemas não existiam. Capítulo 2 - Assinatura digital

Certificado digital Arquivo que possui um conjunto de informações referentes à entidade para a qual o certificado foi emitido (empresa, pessoa física ou computador) mais a chave pública referente à chave privada que se acredita ser de posse unicamente da entidade especificada no certificado.

19

Signatário Olá mundo!

resumo criptográfico

0101001 0110111 0100011 cifra

1101101 0110011 0100110

TSA Ambiente Seguro 0101001 0110111 0100011

1101101 0110011 0100110

Olá mundo! 1101101 0110011 0100110

Olá mundo!

assina (resume e cifra)

1101101 0110011 0100110

1101101 0110011 0100110 1101101 0110011 0100110

Figura 2.4 Assinatura com carimbo de tempo.

Para resolver essas questões, precisamos entender o conceito de Carimbo do tempo ou Time Stamp. Um carimbo do tempo é semelhante a uma assinatura digital, mas contém também uma informação de data ou hora confiável. Dessa forma, um carimbo do tempo cria uma “âncora” entre o conteúdo assinado e uma data, de forma confiável. Para isso é necessário uma Time Stamping Authority (TSA), ou Autoridade de Carimbo do tempo. Trata-se de uma entidade confiável (assim como é uma Autoridade Certificadora) que fornece o serviço de carimbo do tempo. Autoridade de Carimbo de Tempo (Time Stamping Authority – TSA).

q


11 Utiliza fonte confiável de tempo. 11 Carimba somente o hash do documento. 11 Usa chaves e algoritmos mais fortes do que os comuns. Observatório Nacional: 11 Responsável por gerar e distribuir a Hora Legal brasileira. 11 Relógios atômicos. Existem diversas características que devem necessariamente estar presentes em uma TSA para que essa possa ser declarada confiável. A primeira e talvez mais importante de todas é utilizar uma fonte confiável de tempo. No Brasil, o horário oficial é denominado Hora Legal, e é gerado e distribuído pelo Observatório Nacional, de acordo com o Decreto de Lei 4.264, de 10 de junho de 2002. O Observatório Nacional é responsável por manter com a mais alta precisão a Hora Legal brasileira, utilizando para tal relógios atômicos. Outra característica importante é que o conteúdo do documento assinado deve permanecer transparente à TSA. Essa deve conhecer somente o hash do documento em questão. É importante destacar que o processo de geração de um Carimbo de Tempo é bastante complexo, mas aqui estaremos nos limitando a explicá-lo de forma mais superficial, somente apresentando os principais conceitos. 20

Cada vez que uma TSA é requisitada a carimbar temporalmente um documento, o requisitante envia à TSA somente o seu hash. A TSA calcula o hash do resultado da concatenação do timestamp (com informações de data conseguidas através de uma fonte confiável) e do hash do documento. Logo após, a TSA assina digitalmente o hash com sua chave privada. Essa chave e os algoritmos usados na assinatura devem ser considerados fortes no momento em que o carimbo foi gerado. Em geral, as TSAs se utilizam de algoritmos e chaves mais fortes em questões de segurança do que as utilizadas em assinaturas convencionais. Isso é necessário, pois o carimbo de tempo deve ter maior durabilidade do que a própria assinatura, do contrário não terá utilidade. De modo geral, o carimbo do tempo pode ser feito sobre qualquer dado. Mas um dos usos mais comuns é a aplicação do carimbo do tempo apenas na assinatura digital, já que ancorando-a ao tempo, estará sendo ancorado todo o documento junto. Usar carimbo do tempo para conservar a validade por longo prazo.

q

11 Antes da expiração da assinatura ou carimbo anterior. 11 Utilizando algoritmos mais avançados.

Assinatura Certificado A3 Ac Cert A3 Ac Credenciada Ac Raiz

Tempo Expiração do Certificado do Signatário

Expiração do Certificado de AC

Quebra de Algoritmos

Dessa forma, o carimbo do tempo permite se ter certeza da existência de um documento em determinada data. Com essa garantia, caso o certificado do signatário venha a expirar, ou o algoritmo ou hash da assinatura esteja comprometido, o carimbo garantirá que a assinatura ocorreu antes da existência desses problemas, e que portanto a assinatura pode ser validada com base na data do carimbo, e não na data atual. Existem algumas considerações que devem ser feitas quanto a aplicação de um carimbo do tempo: 11 A aplicação de carimbo do tempo deve ser feita quando o carimbo do tempo anterior ou a assinatura ainda for válida. O que o carimbo faz é ancorar a assinatura a uma data onde se sabia que a assinatura era íntegra; de nada adianta aplicar um carimbo em uma assinatura que já não é mais verificável ou válida; 11 É necessário que o carimbo do tempo utilize algoritmos melhores que os da própria assinatura, se o objetivo é proteger contra quebra de algoritmos;


Figura 2.5 Validade de assinaturas com carimbo de tempo.

21

11 É preciso conservar também certificados da cadeia de certificação e listas de certificados revogados válidos na data em que o carimbo do tempo foi emitido, para que seja possível realizar todas as verificações necessárias sobre a cadeia de certificação. Esses dados podem não estar mais disponíveis no dia em que a assinatura for verificada, especialmente a longo prazo.

Formatos de armazenamento PKCS#7 ou CMS ou CAdES:

q

11 ASN.1 11 RFCs: 22 RFC 3852: Cryptographic Message Syntax (CMS). 22 RFC 5126: CMS Advanced Electronic Signatures (CAdES). XML-DSig ou XAdES: 11 XML. 11 Padrões W3S. Uma assinatura digital, na prática, contém muito mais informações do que o resumo criptográfico da mensagem cifrado. Entre outros dados, podem constar data e local onde a assinatura foi realizada, certificado do signatário e sua cadeia de certificação, informações sobre estado de revogação do certificado (LCR, resposta OCSP), carimbo do tempo. Existem duas maneiras principais de representar uma assinatura digital: Binária e XML. A primeira, e mais antiga, é representada pelo PKCS#7, e seu sucessor, o CMS. Atualmente descrito pela RFC 5280, trata-se de um formato binário, codificado em ASN.1. O ASN.1 é um padrão usado para descrição de dados transmitidos em protocolos de telecomunicações, de maneira independente do software e hardware onde foi gerado e onde é interpretado. A segunda forma é representada pela XML-DSig, um formato baseado em XML. Cada vez mais o eXtensible Markup Language (XML) tem sido usado para a representação de infor-


mações, pois permite a representação destas em uma sintaxe simples de ser interpretada

22

tanto por pessoas quanto por computadores, e que também é extensível, possibilitando a utilização nas mais diversas aplicações. Além disso, existem padrões para as chamadas “assinaturas avançadas”, que incorporam características que agregam mais segurança à assinatura, como o carimbo do tempo: 11 CAdES, baseado no CMS; 11 XAdES, baseado no XML-DSig.

Legislação Na ICP-Brasil, a eficácia jurídica é garantida pela MP 2200-2.

A ICP-Brasil foi instituída pela Medida Provisória 2200, de 28 de junho de 2001: a última reedição, em vigor no presente momento, e a MP 2200-2 de 24 de agosto de 2001: com o objetivo de “garantir a autenticidade, a integridade, e a validade jurídica de documentos em forma eletrônica, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras” [1, Art. 1]. Além da MP, ainda existe uma série de decretos referentes a ICP-Brasil. A MP delega ao Instituto de Tecnologia da Informação (ITI) a responsabilidade de gerir e regulamentar a ICP-Brasil. Isso é feito através da publicação de resoluções. Documentos assinados digitalmente utilizando certificados ICP-Brasil presumem-se verdadeiros com relação aos signatários: MP 2200-2: Art. 10. Consideram-se documentos públicos ou particulares, para todos os fins legais, os documentos eletrônicos de que trata essa Medida Provisória. § 1o As declarações constantes dos documentos em forma eletrônica produzidos com a utilização de processo de certificação disponibilizado pela ICP-Brasil presumem-se verdadeiros em relação aos signatários, na forma do art. 131 da Lei no 3.071, de 1o de janeiro de 1916 (Código Civil). § 2o O disposto nessa Medida Provisória não obsta o uso de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento.


Figura 2.6 Medida provisória 2200-2.

q

23

Assinatura digital na ICP-Brasil Conjunto Normativo – DOC-ICP-15: diz exatamente como deve ser a assinatura, para que

q

ela seja válida na ICP-Brasil (eficácia jurídica). 11 Baseado nos padrões XAdES e CAdES. 11 Propõe cinco formatos de assinatura digital para cada padrão. O Comitê Gestor da ICP-Brasil divulga resoluções que regulamentam padrões, políticas e procedimentos que devem ser seguidos na ICP-Brasil. Foi aprovado no início de 2009 o DOC-ICP-15, que regulamenta como deve ser realizada uma assinatura digital na ICP-Brasil. Esse conjunto normativo é baseado nos padrões CaDES e XaDES, ou seja, possui recursos que permitem a conservação a longo prazo das assinaturas digitais. Existem cinco perfis de formatos de assinatura disponíveis, cada um adequado a determinadas situações.

AD-RB

Documento eletrônico

Atributos Assinados

Política de Assinatura Assinatura Digital

Figura 2.7 Formato AD-RB.

O AD-RB, ou “Assinatura Digital com Referência Básica”, é a assinatura simples, que já utilizamos rotineiramente. Não há qualquer preocupação com conservação a longo prazo. Deve ser usada apenas em casos muito específicos, onde não há qualquer interesse em verificar a assinatura em médio ou longo prazo, e se deseja um tamanho mínimo para a assinatura.

AD-RT


AD-RB

24


Atributos Assinados

Política de Assinatura Assinatura Digital

Carimbo de tempo Figura 2.8 Formato AD-RT.

Na AD-RT, a “Assinatura Digital com Referência do Tempo” insere-se um carimbo do tempo, ancorando a assinatura a uma data onde ela era válida. Agrega algum valor à conservação de longo prazo, mas ainda exige cuidados. É necessário conservar os certificados da cadeia de certificação e LCRs externamente. De qualquer forma, é importante, pois dá confiança sobre a data em que o documento foi assinado, além de prolongar um pouco a vida útil de uma assinatura.

AD-RV AD-RT AD-RB


Atributos assinados

Referências sobre certificados e dados de revogação

Política de assinatura Assinatura digital

Figura 2.9 Formato AD-RV.

Carimbo de tempo

Carimbo de tempo

O AD-RV é a “Assinatura Digital com Referências para Validação”. Adiciona referências sobre certificados e LCRs utilizados na assinatura, e coloca um carimbo do tempo sobre toda essa informação. Dessa forma, pode-se consultar um banco de dados externo para obter os dados necessários à validação da assinatura (certificados e LCRs, por exemplo). As referências podem ser o hash dos certificados ou LCRs. Permite que sejam validadas assinaturas a longo prazo, mesmo após a expiração ou extinção das ACs, desde que exista o banco de dados com certificados e LCRs disponíveis para consulta.

AD-RC AD-RV AD-RT AD-RB

Atributos assinados


Figura 2.10 Formato AD-RC.

Carimbo de tempo

Certificados e dados de revogação Carimbo de tempo

O AD-RC é a “Assinatura Digital com Referências Completas”. Acrescenta ainda os valores completos dos certificados, LCRs e outras informações necessárias à validação da assinatura. As referências permanecem, pois elas estão sob o carimbo do tempo, ancoradas ao momento em que os algoritmos envolvidos eram seguros. Dessa forma, fica dispensado o banco de dados de certificados e LCRs. Capítulo 2 - Assinatura digital



25

AD-RA AD-RC AD-RV AD-RT AD-RB


Atributos assinados



Certificados e dados de revogação

Carimbo de tempo

Carimbo de tempo

Finalmente, o AD-RA é o formato para “Assinatura Digital com Referências para Arquivamento”.

Figura 2.11 Formato AD-RA.

É colocado um carimbo do tempo sobre todo o conjunto, usando algoritmos fortes. Toda a estrutura e informações ficam ancoradas no tempo em que eram seguras. Deve ser utilizado para documentos que precisam ser mantidos confiáveis para longos prazos.

Devem ser aplicados novos carimbos do tempo frequentemente, com a finalidade de evitar a perda da eficácia probante por expiração da cadeia de certificação ou quebra dos algoritmos usados no carimbo do tempo de arquivamento. Esse processo, preferencialmente, deve ser automatizado.

OpenDocument Formato proposto pela Sun:

q


11 XML.

26

11 Padrão aberto ISO/IEC 26300:2006. Assinatura digital: 11 Não existe assinatura digital no padrão v1.1. 11 O software OpenOffice.org gera assinaturas XML-DSig. 11 Padrão v1.2 deve incorporar o padrão XadES, e eventualmente o BrOffice trará suporte ao padrão ICP-Brasil. O Open Document Format (ODF) é um padrão de representação de documentos digitais proposto pela Sun. Baseado em XML, é um padrão aberto definido pela norma ISO/IEC 26300:2006. É o padrão utilizado pela suíte de aplicativos de escritório OpenOffice.org, e sua versão brasileira BrOffice.org, ambos softwares livres. O ODF não possui suporte para assinatura digital na versão 1.1 do padrão, mas o OpenOffice.org gera assinaturas no formato XML-DSig. Segundo o website do BrOffice, a versão 1.2 do padrão trará suporte a XaDES, e o BrOffice trará suporte para a geração de assinaturas digitais no novo padrão da ICP-Brasil.

w Confira em: http://www.broffice. org/odf_1-2_suportara_ assinatura_digital_compativel_com_ICP-Brasil

OpenXML Formato proposto pela Microsoft:

q

11 XML. 11 Em fase final para se tornar padrão ISO/IEC DIS 29500. Assinatura digital: 11 XML-DSig. O OpenXML é um formato de documento proposto pela Microsoft, também baseado em XML. Está em processo de se tornar o padrão ISO/IEC DIS 29500. O OpenXML já traz suporte a assinaturas digitais, também em formato XML-DSig.

PDF Formato proposto pela Adobe:

q

11 Subconjunto da linguagem de programação PostScript: layout e gráficos. 11 Sistema de incorporação e substituição de fontes. 11 Sistema de armazenamento estruturado: com compressão de dados onde é adequado. 11 Formado por objetos: 22 Arrays, Strings, Dicionários Streams etc. Assinatura digital: 11 PKCS#7 no interior de um dicionário de assinaturas. O Portable Document Format (PDF) é um formato de representação de documentos eletrônicos proposto pela Adobe. Vamos abordá-lo com mais detalhes por ser um formato que tem sido amplamente utilizado para representação de documentos com assinatura digital. Um documento PDF é um conjunto de objetos que seguem uma determinada sintaxe, de forma a definir o conteúdo de uma página. Esses objetos podem ser arrays, strings, dicionários ou streams. Imagens, por exemplo, podem ser armazenadas em streams, com filtros de compressão e codificação. Uma das diferenças marcantes do PDF é sua abordagem de assinatura digital, interna ao documento, e tem uma representação visual. A assinatura digital em um PDF é armazenada no formato PKCS#7, dentro de um objeto do tipo dicionário, que contém ainda outras informações sobre a assinatura, como seu


aspecto visual.

27

Figura 2.12 Exemplo de PDF assinado.

A imagem ilustra um documento PDF assinado, visualizado no Adobe Reader. Note a representação visual da assinatura na parte inferior da página.


Exemplo:

28

0000000228 00000 n

%PDF-1.7

/Subtype /Type1

<<

6 0 obj

/Name /F1

/Type / Pages

0000000424 00000 n

<<

/BaseFont/ Helve-

/ Kids [ 1 0 R ]

0000000145 00000 n

/Type /Catalog

tica

/Count 1

0000000333 00000 n

/Pages 5 0 R

>>

/MediaBox

0000000009 00000 n

>>

endobj

[ 0 0 612 792 ]

trailer

endobj

2 0 obj

>>

<<

1 0 obj

<<

endobj

/Size 7

<<

/Length 53

3 0 obj

/Root 6 0 R

/Type /Page

>>

<<

>>

/Parent 5 0 R

stream

/ProcSet[/ PDF/

startxref

/Resources 3 0 R

BT

Text]

488

/Contents 2 0 R

/F1 24 Tf

/Font <
%%EOF

>>

1 0 0 1 260 600 Tm

R >>

endobj

(Hello World)Tj

>>

4 0 obj

ET

endobj

<<

endstream

xref

/Type /Font

endobj

0 7

5 0 obj

0000000000 65535 f 0000000060 00000 n

Esse é um documento PDF simples, apresentado para desmistificar um pouco a noção que se tem do PDF. Pode parecer um pouco complicado à primeira vista, mas é mais simples do que parece.

l

Perceba que é um formato editável, apesar do uso mais comum e popularizado do PDF de envio e distribuição de documentos em sua versão final.

Note que é apenas ASCII. O PDF suporta também conteúdo binário codificado em streams, muito utilizado para armazenamento, por exemplo, de imagens.

Figura 2.13 PDF correspondente ao código de exemplo.

Esse é o PDF correspondente ao código anterior, salvo em formato .pdf. 0

Bytes que são assinados

%PDF . . . .CONTEÚDO .

/ByteRange [0,720,840,210] 720

/Contents < 31 ad 41 al e8 1d 99 2e 10 12 8a 31 cd a1 88 d3 Eb

Conteúdo da Assinatura PKCS#7 59 20 d0 a0 20 cc 29 10 10 31 bb ad 19 01 20 10 ab b1 bd aD 12 20 d0 bb 31 3b 10 ad 29 a9 ee 2a a9 1a cd ab 2a 1a a3 1b 15 11 ba d2 18 31 ab 3a cc 10 c4

840

> . % % EOF 1050 A assinatura digital de um PDF (PKCS#7) fica no interior do documento, dentro de um objeto do tipo dicionário. Esse dicionário possui diversas informações sobre a assinatura, entre as quais se destacam: 11 Contents: possui o conteúdo do PKCS#7, codificado em hexadecimal; 11 Byterange: define a região de bytes do documento onde é assinada. É formada por dois pares de valores inteiros, que identificam o início e o tamanho de duas regiões do documento. O ByteRange inclui todo o documento exceto os bytes do valor do campo Contents, conforme ilustra a figura. A geração de um documento assinado ocorre da seguinte forma: o documento é gerado com um espaço em branco para o campo Contents, (suficiente para pior caso), e o ByteRange


Figura 2.14 Localização da assinatura.

aD 12 20 d0 29 a9 ee 2a 99 2e 10 12 8a 31 cd a3 1b

é configurado conforme o documento gerado. O hash é calculado a partir desse valor, de 29

forma que inclui todo o documento, menos a parte correspondente ao Contents. Então é gerada a assinatura PKCS#7, inserida na região destinada ao campo Contents. Note que informações como aparência da assinatura também ficam na parte assinada do documento. Somente o hash cifrado e demais informações do PKCS#7 estão fora do ByteRange. 0

0

ByteRange da Assinatura 1

%PDF . . . .CONTEÚDO ORIGINAL . /ByteRange [0,720,840,210] /Contents <

720 31 ad 41 al e8 1d 99 2e 10 12 8a 31 cd a1 88 d3 Eb

Conteúdo da Assinatura 1 PKCS#7

b1 bd aD 12 20 d0 bb 31 3b 10 ad 29 a9 ee 2a a9 1a cd ab 2a 1a a3 1b 15 11 ba d2 18 31 ab 3a cc 10 c4 59 20 d0 a0 20 cc 29 10 10 31 bb ad 19 01 20 10 ab

840

aD 12 20 d0 29 a9 ee 2a 99 2e 10 12 8a 31 cd a3 1b

> . % % EOF 1050

ByteRange da Assinatura 2 1300

.MUDANÇAS - VERSÃO 2 . /ByteRange [0,1300,1420,210] /Contents < 31 ad 41 al e8 1d 99 2e 10 12 8a 31 cd a1 88 d3 Eb

b1 bd aD 12 20 d0 bbda 31 3bAssinatura 10 ad 29 a9 ee 2a a9 2 1a Conteúdo cd ab 2a 1a a3 1b 15 11 ba d2 18 31 ab 3a cc 10 c4 PKCS#7 59 20 d0 a0 20 cc 29 10 10 31 bb ad 19 01 20 10 ab

1420

1630

aD 12 20 d0 29 a9 ee 2a 99 2e 10 12 8a 31 cd a3 1b

> . % % EOF

Figura 2.15 Múltiplas assinaturas.

É possível aplicar múltiplas assinaturas sobre um mesmo documento PDF, graças ao sistema de atualizações incrementais. Esse sistema permite que se modifique um documento PDF,


adicionando novas versões para objetos modificados, mantendo os objetos originais

30

intactos. Isso é feito adicionando novas informações ao final do documento. Dessa forma, novas assinaturas também podem ser inseridas, sendo aplicadas sempre sobre as demais. As assinaturas anteriores não cobrirão mais todo o documento. Entretanto, como os dados compreendidos no ByteRange não foram modificados, essa assinatura ainda pode ser validada, com a ressalva de que ela é válida apenas para a primeira versão do documento, e não para as modificações subsequentes. Por esse motivo é necessário avaliar com cautela múltiplas assinaturas. O Adobe 9 considera múltiplas assinaturas válidas apenas se não for feita nenhuma outra modificação no documento (inclusão ou remoção de dados). Tipos de assinaturas. 11 Assinatura de Certificação: 22 Única. 22 Primeira assinatura aplicada ao documento. 22 Autor aprova o documento.

q

11 Assinatura de Documento:

q

22 Assinaturas simples. 22 Podem existir múltiplas assinaturas. 22 Podem indicar aprovação do conteúdo, compromisso etc. Uma assinatura em PDF pode ser de três tipos. Interessam especialmente dois deles: 11 Assinatura de certificação: no máximo existe uma por documento, e se existe deve ser a primeira. Indica aprovação do autor ao documento, e define que tipo de modificações podem ser feitas posteriormente (por exemplo, pode ser autorizada a adição de notas ou de novas assinaturas). 11 Assinatura de documento: é a assinatura simples, podendo existir quantas assinaturas forem necessárias. Ainda existe a assinatura de direitos de uso, utilizada para liberar funcionalidades extras no Adobe Reader. É usada por exemplo para permitir que o Adobe Reader assine um docu-


mento gerado no Adobe Acrobat.

31

32


3 Compreender o funcionamento de uma Infraestrutura de Chaves Públicas – X.509; Conhecer os objetivos e histórico da ICPEDU e ICP-Brasil.

conceitos

X.509: Infraestrutura de chaves públicas; AC: Autoridade Certificadora; AR: Autoridade de Registro; Arquiteturas de ICP (AC Única e Hierárquica); Política de Certificação e Declaração de Práticas de Certificação; ICPEDU; ICP-Brasil; Softwares de Assinatura Digital.

X.509: ICP 11 Conjunto de:

q

22 Entidades. 22 Políticas. 22 Mecanismos criptográficos. 22 Técnicas de gestão. 11 Facilitar o uso de criptografia de chaves públicas. 11 Principais componentes: 22 Autoridades Certificadoras. 22 Autoridades de Registro. 22 Repositório. Com a evolução da criptografia de chaves públicas e o conceito da existência de uma chave pública, que pode ser distribuída livremente, surgiram novas necessidades e questões a serem tratadas. Entre elas, merece destaque a questão de como associar uma chave pública a seu responsável. Vimos anteriormente que essa associação pode ser feita através dos certificados digitais. Aprendemos também que se faz necessária uma entidade confiável para atestar a ligação entre o responsável pela chave e sua respectiva chave pública, dando origem aos certificados digitais. No x.509 foi criado o conceito de uma entidade chamada de Autoridade Certificadora (AC), a entidade responsável pela identificação do usuário e por atestar que ele possui a chave privada correspondente à chave pública. Esse processo é realizado através da assinatura de um documento pela AC, que contém dados de identificação do usuário, sua chave pública

Capítulo 3 - Infraestrutura de Chaves Públicas

objetivos

Infraestrutura de Chaves Públicas

e outros atributos necessários. Esse documento é chamado de Certificado Digital x.509 e representa o mais básico elemento de uma Infraestrutura de Chaves Públicas (ICP).

33

Uma ICP é constituída por um conjunto de: 11 Entidades: pessoas, máquinas, servidores etc.; 11 Políticas: conjunto de normas e práticas que regem uma ICP; 11 Mecanismos criptográficos; 11 Técnicas de gestão. O objetivo principal de uma ICP é facilitar o uso de criptografia de chaves públicas, tendo como principais componentes: 11 Autoridades Certificadoras; 11 Autoridades de Registro; 11 Repositório.

Autoridades certificadoras Composição de:

q

11 Hardware. 11 Software. 11 Pessoas. Responsáveis por: 11 Emissão de certificados digitais. 11 Emissão de listas de certificados revogados. 11 Gerenciamento das informações dos certificados. 11 Verificação dos dados das requisições. 11 Delegar tarefas. A Autoridade Certificadora (AC) é composta por hardware, software e pessoas que a operam. É o elemento de uma ICP responsável pela emissão de certificados, emissão de LCRs, gerenciamento e publicação das informações sobre certificados revogados, além de


ser capaz de delegar determinadas funções a outras entidades.

34

Ao emitir um certificado, uma AC assegura que a entidade requisitante detenha a chave privada correspondente à chave pública contida no certificado. Os certificados emitidos podem ser para outras Acs (conhecidas como ACs intermediárias), para entidades finais ou para ambos. Quando emite LCRs, uma AC gera uma lista assinada contendo informações sobre os certificados revogados, como a data e o motivo da revogação. De maneira semelhante ao certificado, quando uma AC assina sua LCR, ela atesta seu conhecimento e a autenticidade do conteúdo da lista. Uma infraestrutura de chaves públicas pode ser constituída por uma única AC; porém, em muitos casos faz-se necessário que determinadas tarefas sejam delegadas a outras entidades a fim de minimizar a carga de tarefas sobre a AC. Por exemplo, uma AC pode delegar a outra AC, denominada AC intermediária, a emissão de certificados em seu nome, ou então delegar a emissão da LCR a outra AC. Outra delegação de tarefa bastante comum em uma AC é a de delegar o processo de identificação dos usuários para uma entidade chamada Autoridade de Registro (AR).

Autoridade Certificadora

Usuário Requisição Certificado

Publica Certificado

Figura 3.1 Emissão de certificados digitais.

Repositório Autoridade Certificadora

Usuário Solicita Revogação

Publica LCR

l A existência dessa entidade em uma ICP faz-se necessária de acordo com a abrangência que uma AC pode ter, seja ela por sua distribuição geográfica ou por um elevado número de usuários.

Repositório

Autoridades de registro 11 Composição de:

q

22 Hardware. 22 Software. 22 Pessoas. 11 Atua por delegação de uma AC. 11 Responsáveis por: 22 Verificar o conteúdo de requisições de certificados. 22 Solicitar revogação de certificados. 11 Podem atuar em uma ou mais ACs. A Autoridade de Registro (AR) é uma entidade composta por software, hardware e operadores para os quais a AC delega a tarefa de verificar o conteúdo de requisições de certificados. Uma AC pode delegar a tarefa de verificação de informações para várias ARs, que podem desempenhar seu papel para várias ACs.


Figura 3.2 Emissão de lista de certificados revogados.

35


Autoridade de Registro Requisição aprovada Certificado

Requisição

Figura 3.3 Aprovação de certificados.

Usuário

Repositório

q

11 Responsável por disponibilizar: 22 Certificados digitais. 22 Listas de Certificados Revogados. 22 Declaração de Práticas de Certificação. 11 On-line. 11 Sempre disponível.

O Repositório de Certificados Digitais também atua por delegação da AC, e é normalmente composto por software e hardware, com o objetivo de publicar os certificados digitais e listas de certificados revogados atuais emitidos por uma ou mais ACs. Os dados disponibilizados e armazenados pelo Repositório de Certificados Digitais são assinados pela AC representada por ele, garantindo sua integridade e sua autenticidade, e tornando-o imune a ataques de substituição e fabricação. O Repositório de Certificados Digitais é uma parte da ICP que precisa estar sempre disponível, e por isso necessita de medidas de segurança.

36

Autoridade de Registro Requisição aprovada

Publica Certificado e LCR

Requisição

Certificado Certificado



Repositório Usuário

Figura 3.4 Relação entre os componentes.

ACs Intermediárias 11 AC pode delegar a responsabilidade de emissão de certificados para uma ou mais

q

ACs Intermediárias. 22 Redução da carga de trabalho sobre uma AC. 22 Facilita o crescimento. 22 Aumenta a abrangência (se necessário). 11 Se a AC Raiz autorizar, uma AC Intermediária pode delegar a tarefa de emissão para outras ACs abaixo dela. 11 Se desejar, uma AC pode limitar o número de ACs abaixo dela. Como já vimos, uma AC pode delegar a responsabilidade de emissão de certificados para uma ou mais ACs Intermediárias. Os motivos pelos quais uma AC pode fazer isso são: 11 Redução da carga de trabalho sobre uma AC, fazendo com que a AC Raiz tenha de emitir um número menor de certificados, dividindo essa tarefa com outras ACs; 11 Facilitar o crescimento de toda a estrutura da AC; 11 Aumentar a abrangência (se necessário), já que com mais ACs é possível distribuir melhor a localização e o escopo das emissões de certificados digitais; 11 Melhorar a capacidade de tolerância a erros, uma vez que se uma AC Intermediária tiver problemas, apenas o que está abaixo dessa AC será comprometido. Se houvesse apenas a AC Raiz, a estrutura toda seria comprometida. Se a AC Raiz autorizar, uma AC Intermediária pode delegar a tarefa de emissão para outras ACs abaixo dela. Além disso, pode limitar o número de ACs abaixo dela através do uso de uma extensão específica para esse fim.

AC Raiz

AC2

Figura 3.5 Cadeia de certificação.

Alice

AC5

João Ana

Beto

José

Carlos

Certificação digital Por que confiar? 11 Certificado contém informações sobre o detentor da chave privada. 11 Emitido por uma entidade confiável. 11 Dados são verificados. 11 ICPs são auditadas.

q


AC4

AC3

37

11 Utilizam mecanismos que agregam:

q

22 Integridade. 22 Autenticidade. 22 Não repúdio. Por que devemos confiar em toda essa estrutura? Um dos grandes objetivos de uma ICP é que ela seja confiável, que seus usuários confiem nela. Para que isso ocorra, uma série de características podem ser encontradas: 11 Os certificados contêm informações sobre o detentor da chave privada; 11 Os certificados são emitidos por uma entidade confiável; no caso, uma AC; 11 Os dados apresentados pelo requisitante são verificados, e a forma como são verificados está disponível em documentos; 11 As ICPs são auditadas. 11 Utilizam mecanismos que agregam: 22 Integridade; 22 Autenticidade; 22 Não repúdio.

Arquiteturas ICP 11 Definem como as entidades de uma ICP estabelecem confiança.

q

11 Diversas possíveis arquiteturas: 22 AC Única: 33 Listas de confiança. 22 Hierárquica: 33 Certificação cruzada.


33 Ponte.

38

As arquiteturas de ICPs surgiram para definir como as entidades de uma ICP estabelecem confiança entre elas. As arquiteturas mais usadas são: 11 AC Única: 22 Listas de confiança. 11 Hierárquica: 22 Certificação cruzada. 22 Ponte. Durante este curso, destacaremos apenas o modelo de AC Única, que representa o modelo mais básico de uma ICP, e o modelo de AC Hierárquica, que é o modelo adotado tanto na ICP-Brasil como na ICPEDU.

AC Raiz Figura 3.6 AC Única.

Ua

Un

A AC Única é a mais simples arquitetura de ICP existente, onde uma única Autoridade Certificadora é implementada, sendo responsável por toda a gerência e controle de uma ICP. Operações como emissão de certificados digitais, emissão de listas de certificados revogados e o controle sobre essas informações são de total responsabilidade da AC Única. Nesse modelo, para que se estabeleça confiança entre os usuários, basta que estes confiem apenas em certificados e LCRs emitidos pela AC que emitiu seu próprio certificado, sem necessidade de estabelecimento de confiança em outras ACs.

AC Raiz

AC2

AC4

Alice

AC5

João Ana

Beto

José

Carlos

A arquitetura hierárquica é a mais utilizada atualmente. Diferentemente do modelo de AC Única, no modelo de ICP Hierárquica existem mais ACs pertencentes à mesma ICP. Dessa forma, as ACs nessa arquitetura são organizadas na forma de árvore com um ponto comum de confiança chamado AC Raiz. Nessa arquitetura, a AC Raiz, além de ser responsável pela emissão do seu próprio certificado, emite também certificados de outras ACs, chamadas AC subordinadas (ou intermediárias), que por sua vez podem emitir certificados para usuários ou outras ACs, e assim por diante.

A AC Raiz normalmente não emite certificados para usuários finais, emitindo apenas certificados para outras ACs.

Caminhos de certificação Caminho entre um Certificado de Entidade Final e o Ponto de Confiança (AC Raiz).

q

11 Todos os certificados de ACs Intermediárias entre um certificado de entidade final e a AC Raiz devem ser incluídos. Para considerar um certificado válido: 11 Verificar o certificado. 11 Verificar todos os certificados do caminho de certificação. Ao utilizarmos a arquitetura hierárquica, surge um novo conceito necessário para a verificação de certificados digitais, o caminho de certificação. Esse “caminho” são os certificados


Figura 3.7 Arquitetura hierárquica.

AC3

de ACs percorridas entre um Certificado de Entidade Final e o Ponto de Confiança (AC Raiz). 39

Para considerar um certificado válido, devemos verificar cada certificado do caminho de certificação e todos eles devem ser válidos. Podemos dividir os critérios de montagem do caminho de certificação de acordo com os parâmetros utilizados para a realização do encadeamento. Com isso, temos dois principais tipos: 11 Encadeamento por nome; 11 Encadeamento por identificador de chave.

Entidade final

AC Intermediária

AC Raiz

Emissor = AC 1

Emissor = AC 0

Emissor = AC 0

Sujeito = Usuário

Sujeito = AC 1

Sujeito = AC 0

. . .

. . .

. . .

Figura 3.8 Construção de caminho de certificação por nomes.

No encadeamento por nomes, partindo do certificado a ser validado para o ponto de confiança, a validação se faz através da comparação do campo emissor do certificado atual com o campo sujeito do próximo certificado da cadeia, e assim por diante, conforme nos mostra a figura. Esse método é satisfatório quando há garantia de que todas as ACs envolvidas na construção do caminho de certificação possuem apenas um par de chaves. Porém, podem ocorrer situações onde existam nomes iguais e chaves diferentes, gerando ambiguidade na escolha do certificado para a construção do caminho. Com isso, faz-se necessária a utilização de um identificador único para a construção do caminho de certificação, e com a terceira versão de certificados X.509, surgiu um par de extensões chamadas Authority Key Identifier (AKID) e Subject Key Identifier (SKID), identificadores únicos referentes às chaves dos certificados. Nesses identificadores, comumente são usados os resumos criptográficos da chave pública do detentor do certificado.


Entidade final

40

AC Intermediária

AC Raiz

Emissor = AC 1

Emissor = AC 0

Emissor = AC 0

Sujeito = Usuário

Sujeito = AC 1

Sujeito = AC 0

AKID = Y

AKID = X

AKID = X

SKID = Z

SKID = Y

SKID = X

A montagem do caminho de certificação utilizando o encadeamento por identificador de chave é realizada de forma semelhante à do encadeamento por nome, diferindo pelo fato de que a verificação se dá pelo valor do Subject Key Identifier (SKID) e do Authority Key Identifier (AKID). Portanto, a construção na forma direta AKID do primeiro certificado deve ser igual ao SKID do próximo, e assim por diante. A estrutura ASN.1 da extensão AKID é definida da seguinte forma:

AuthorityKeyIdentifier::= SEQUENCE{ keyIdentifier [0]KeyIdentifier OPTIONAL, authorityCertIssuer [1]GeneralNames OPTIONAL,

Figura 3.9 Construção do caminho de certificação por nomes e identificadores de chave.

AuthorityCertSerialNumber [2]CertificateSerialNumberOPTIONAL } KeyIdentifier::=OCTETSTRING De acordo com a RFC 5280: “O keyIdentifier pode ser utilizado para selecionar certificados durante a construção do caminho. O par authorityCertIssuer e authoritySerialNumber podem ser usados apenas para prover preferência para um certificado sobre outros durante a construção do caminho de certificação.” O valor do campo authorityCertIssuer deve ser igual ao valor do campo Issuer do certificado do emissor, e o valor do campo authorityCertSerialNumber deve ser igual ao valor do campo serialNumber do certificado do emissor. A estrutura ASN.1 da extensão SKID é definida da seguinte forma:

SubjectKeyIdentifier ::= KeyIdentifier Validação ou Verificação do Caminho de Certificação: 11 Para cada certificado do caminho encontrado, verificar: 22 Assinatura digital; 22 Validade; 22 Situação (revogado ou não); 22 Extensão BasicConstraints; 22 Extensões críticas. Depois de construído o caminho de certificação, deve ser realizada a validação ou verificação de todos os certificados do(s) caminho(s) encontrado(s). Para cada certificado do caminho encontrado, deve-se verificar: 11 Assinatura digital: conferir se a assinatura digital do certificado é válida; 11 Data de validade: verificar se os certificados estão dentro do período de validade; 11 Situação de revogação: conferir se o certificado está revogado; 11 Restrições básicas: todos os certificados intermediários devem ter o campo CA da extensão basicConstraints marcado como true. Se o campo pathLenConstraint existir, 11 Restrições de políticas: verificar todas as restrições políticas aplicáveis ao certificado; 11 Restrições de nomes: conferir todas as restrições de nomes aplicáveis ao certificado; 11 Extensões críticas: reconhecer e processar todas as extensões críticas presentes no certificado. Caso alguma das verificações citadas falhe, o caminho deve ser considerado inválido; caso contrário, o caminho pode ser aceito.


verificar se seu valor está sendo respeitado;

41

Políticas de Certificação 11 Documentos que determinam as políticas e práticas que regem uma ICP.

q

11 Definem as condições em que uma ICP pode operar. 11 Declaração de Práticas de Certificação. 22 Descreve como a política é implementada dentro de uma AC Específica. 11 PC x DPC: 22 PC é um documento de mais alto nível. 22 DPC é mais detalhado. As políticas de certificação são documentos escritos pelos responsáveis de uma Autoridade Certificadora e constituem a base para auditoria, delegação de autoridade ou qualquer outra necessidade da AC. Basicamente, são esses documentos que definem as condições em que uma ICP pode operar. Existem dois documentos principais dentro das políticas de uma ICP: 11 Políticas de Certificação (PC): definem em alto nível como uma política deve ser implementada; 11 Declaração de Práticas de Certificação (DPC): descreve como a política é implementada dentro de uma AC Específica.

ICPEDU 11 Esforço da Rede Nacional de Ensino e Pesquisa (RNP) para viabilizar a implantação de

q

uma infraestrutura de chaves públicas acadêmica. 11 Objetivos: 22 Uso acadêmico. 22 Autenticação. 22 Desenvolver cultura em certificação digital.


22 Treinamento.

42

22 Pesquisa. 22 Aplicações. O projeto ICPEDU é um esforço da Rede Nacional de Ensino e Pesquisa (RNP) para viabilizar a implantação de uma infraestrutura de chaves públicas acadêmica. Objetivos desse projeto: 11 Uso acadêmico: viabilizar o uso acadêmico de certificação digital; 11 Autenticação: permitir o uso de certificação digital para autenticação de pessoas e equipamentos dentro das instituições; 11 Desenvolver cultura em certificação digital: fazer com que a certificação digital se popularize e tenha seu uso difundido dentro das intituições acadêmicas; 11 Treinamento: capacitar pessoas na área de ICP; 11 Pesquisa: desenvolver pesquisa na área; 11 Aplicações: criar e implementar softwares e ferramentas para viabilizar a implantação do projeto e agilizar o dia a dia das instituições envolvidas.

l Basicamente, a diferença entre uma PC e DPC é que uma PC é um documento de mais alto nível, enquanto uma DPC é mais detalhada.

q

Histórico. 11 2003/2004: 22 SGCI. 11 2005: 22 HSM. 11 2006: 22 Piloto AC Raiz. 11 2007: 22 Serviço experimental (seis instituições). 11 2008/2009: 22 Implantação. 22 Aprimoramentos. 11 2010/2013: 22 Operação e Credenciamentos. 22 Proposição de novos modelos de adesão.

O projeto ICP teve início no ano de 2003, com o projeto SGCI. Com o passar dos anos, foram surgindo novas demandas, até que em 2005 surgiu o projeto no módulo criptográfico seguro (HSM). Em 2006, foi criado o projeto piloto para a criação de uma AC Raiz da ICPEDU, com base no SGCI e HSM. Já em 2007 foi criado um serviço experimental, incluindo seis instituições. Por fim, de 2008 até hoje, está em andamento a implantação do projeto em larga escala, envolvendo diversas instituições em todo o Brasil, além de estarem em andamento diversas melhorias nas ferramentas existentes (HSM e SGCI 2.0). No decorrer do período, de 2012 a 2013, o modelo se fixou em algumas instituições de ensino superior e a RNP está propondo novos modelos de integração com a Federação café, para ampliar a abrangência do ICPEDU. Na figura 3.10 podemos ver um exemplo da cadeia de certificação da ICPEDU.

AR UFSC

AC UFSC

AC SSL Figura 3.10 Exemplo de cadeia de certificação da ICPEDU.

offline online

AC Correio

AR Raiz ICPEDU

AC Instituição

AC SSL

AC Correio

AR Instituição Capítulo 3 - Infraestrutura de Chaves Públicas

AC Raiz ICPEDU

43

Grupos

q

11 Comitê Assessor: 22 Aprovar políticas. 22 Aprovar criação de ACs. 11 Autoridade de Gerência de Políticas (AGP): 22 Analisar políticas das instituições. 11 GOPAC: 22 AC Raiz. 11 GOPAR: 22 AR Raiz. As atividades de gerência da ICPEDU são divididas em grupos para facilitar sua implantação. São eles: 11 Comitê Assessor: responsável por aprovar políticas e a criação de ACs; 11 Autoridade de Gerência de Políticas (AGP): tem a responsabilidade de analisar políticas das instituições em credenciamento; 11 GOPAC: grupo responsável pela operação da AC Raiz; 11 GOPAR: grupo responsável pela operação da AR Raiz.

ICP-Brasil 11 Conjunto de entidades, padrões técnicos e regulamentos elaborados para suportar

q

um sistema criptográfico com base em certificados digitais. 11 Medida Provisória 2.200-2, de 24 de agosto de 2001. 11 Exemplos de ACs credenciadas: 22 Caixa Econômica Federal. 22 CertiSign.


22 Serasa.

44

22 Serpro. 22 Receita Federal. No Brasil, a partir da Medida Provisória 2.200-2, de 24 de agosto de 2001, foi instituída a ICP-Brasil, que define um conjunto de entidades, padrões técnicos e regulamentos, elaborados para suportar um sistema criptográfico com base em certificados digitais. A partir da criação da ICP-Brasil, nosso país passou a ter uma AC governamental, cujos certificados podem ser utilizados em várias ferramentas do governo, e as assinaturas realizadas a partir de sua utilização passaram a ter eficácia probante. Diversos órgão emitem certificados ICP-Brasil, sendo todos eles ACs subordinadas à AC Raiz brasileira. Alguns exemplos de ACs credenciadas: 11 Caixa Econômica Federal; 11 CertiSign; 11 Serasa; 11 Serpro;

11 Receita Federal; 11 Presidência da República. Os certificados ICP-Brasil podem ser utilizados para vários fins. Veja alguns exemplos de uso: 11 Sistema de Pagamentos Brasileiro (SPB); 11 Autenticação em sistemas; 11 Tramitação e assinatura eletrônica de documentos oficiais; 11 Assinatura de contratos; 11 Assinatura de documentos; 11 Internet banking; 11 Automação de processos do Poder Judiciário;


11 Declaração de Imposto de Renda.

45

46


4 Compreender o uso do protocolo TLS e sua utilização; Aprender a configuração de um servidor Web Seguro.

SSL e TLS; Servidor Web Seguro.

SSL/TLS SSL:

conceitos

q

11 Secure Sockets Layer. 22 Camada de Sockets Seguros. TLS: 11 Transport Layer Security. 22 Segurança de Camada de Transporte. 11 TLS é o sucessor do SSL. 22 TLS 1.0 ~ SSL 3.0. 11 Versão mais recente: TLS 1.2. 22 RFC 5246. A sigla SSL vem de Secure Sockets Layer. Traduzindo para o português, “Camada de Sockets Seguros”. Apesar de ainda usarmos muito o nome SSL, o sucessor deste é o TLS, que hoje já é bastante utilizado. A versão 1.0 do TLS é equivalente ao SSL 3.0. A sigla TLS vem de Transport Layer Security, que traduzido para o português é algo como “Segurança de Camada de Transporte”. A versão mais recente do TLS é a 1.2, definida pela RFC 5246. Objetivos: 11 Autenticação: 22 Normalmente unidirecional. 22 Mas pode prover autenticação bidirecional. 11 Sigilo: 22 A comunicação entre cliente e servidor não pode ser compreendida por alguém

q

Capítulo 4 - Servidor Web Seguro

objetivos

Servidor Web Seguro

que esteja ouvindo o tráfego de dados. 47

SSL e TLS foram desenvolvidos com dois objetivos em especial, que são:

Autenticação 11 Unidirecional: Cliente g Servidor, ou seja, o cliente pode garantir que está realmente se comunicando com o servidor que deseja, enquanto o cliente permanece “anônimo” (não autenticado). 11 Bidirecional: Cliente 1 Servidor, ou seja, ambos os lados podem ter certeza sobre com quem estão se comunicando, ambos os lados são autenticados.

Sigilo Protege os dados que são trocados pelo cliente e servidor, para que não sejam compreendidos por uma terceira parte não autorizada, que esteja monitorando a comunicação. Vamos analisar com mais detalhes o processo de autenticação unidirecional, que é o mais utilizado atualmente.

Cliente

Servidor Gera RNc algoritmos, RNc

Gera RNs algoritmos, RNs

Figura 4.1 Inicialização do Handshake.

O estabelecimento de uma conexão SSL (handshake) começa com o cliente solicitando a conexão:


11 Cliente inicia handshake, informando ao servidor RNc (número randômico) sua lista de

48

algoritmos criptográficos suportados; 11 Servidor responde: RNs (outro número randômico), e seus algoritmos criptográficos escolhidos entre os informados pelo cliente.

Cliente

Servidor certificado do servidor

Verifica certificado Figura 4.2 Apresentação do certificado digital do servidor ao cliente.

Terminada a primeira etapa, o servidor apresenta ao cliente o seu certificado digital. O cliente, então, verifica as informações do certificado, seu caminho de certificação, estado de revogação etc.

Verificado o certificado, o cliente agora tem o conhecimento da chave pública do servidor, indicada na figura com uma chave verde.

Cliente

Servidor

Gera PMS PMS cifrado com chave pública

Decifra PMS Gera chave sométrica MS utilizando RNc, RNs e PMS

Figura 4.3 Geração da chave de sessão.

O cliente então gera o Pre Master Secret (PMS), um número randômico que servirá de base para a geração da chave. Ele envia esse número ao servidor cifrado com a chave pública do servidor. O servidor utiliza a sua chave privada para decifrar o PMS. A partir desse momento, cliente e servidor conhecem PMS, mas um observador que monitore a comunicação não terá como obter esse valor, pois não tem a chave privada associada à chave pública utilizada na cifragem dos dados. Cliente e servidor então geram uma chave simétrica Master Secret (MS), utilizando RNc, RNs e PMS. Essa é a chamada chave de sessão.

Cliente

Servidor alternar para modo cifrado com MS encerra handshake alternar para modo cifrado com MS encerra handshake

Figura 4.4 Finalização do Handshake.

Por fim, cliente e servidor alternam para o modo cifrado, usando a cifragem simétrica com a chave gerada Master Secret (MS).

modo cifrado, utilizando cifragem simétrica. Deve-se notar o motivo de cada etapa. A cifragem assimétrica é utilizada para combinar uma chave simétrica de sessão. Ela não é utilizada para cifrar toda a conexão, pois a cifragem assimétrica é muito mais cara (custo computacional, velocidade). Dessa forma, ela é utilizada apenas para cifrar um valor pequeno, que é um número randômico. Para a cifragem de todos os dados trocados na sessão SSL, utiliza-se um algoritmo simétrico, muito mais eficiente, mas que exige que uma chave única seja conhecida em comum pelas duas partes. Dessa forma, o SSL/TLS utiliza o melhor dos dois modelos de criptografia.


Dessa forma, se encerra o processo de handshake, e a comunicação passa a ocorrer de

49

11 Aspectos gerais.

q

11 Certificado auto-assinado X ICP. 22 Confiança no certicado x Confiança na(s) Autoridade(s)? 22 Cultura do “Cadeado fechado” = “Site seguro” 11 Common Name (CN) deve conter o hostname do servidor. 11 Demais dados devem ser definidos de acordo com a política da AC. 11 Variações: 22 EV-SSL. 22 Wildcards. Existe uma série de considerações que devem ser feitas a respeito da comunicação segura através de SSL/TLS. Há muita informação incorreta e imprecisa sobre o assunto divulgada em sites, jornais e revistas. O primeiro ponto a se analisar é a questão de que um certificado é assinado, e deve ter sua cadeia de certificação corretamente validada. É prática comum, em alguns pequenos sites e aplicações, a utilização de certificados autoassinados para a identificação de servidores. Isso elimina toda a confiabilidade dada por uma ICP, limitando a confiabilidade na segurança do próprio servidor. O usuário terá de explicitamente confiar no certificado digital do servidor, em vez de poder escolher confiar em uma ICP. E como convencer o usuário de aceitar isso, considerando que os navegadores cada vez utilizam avisos mais chamativos e enfáticos sobre a necessidade de cautela ao se marcar um certificado como confiável? Outro erro comum das cartilhas de segurança é a ideia da cultura de que “cadeado fechado” significa “site seguro”. Note, no entanto, que um “cadeado fechado” significa de fato apenas que: 11 A conexão está cifrada para terceiros que eventualmente estejam “escutando”; 11 Você está se comunicando com o site detentor da chave privada do certificado que você optou em confiar (seja confiando no certificado, seja confiando em uma AC). Se você confiou em quem não devia, o cadeado pode “fechar” mesmo que o site seja falso.


Em um certificado digital para SSL/TLS, o campo Common Name (CN) deve conter o hostname

50

da máquina. Esse é um dos dados verificados no certificado. Para um mesmo certificado ser utilizado com mais de um hostname, é possível utilizar wildcards, que é simplesmente utilizar o símbolo “*” para indicar “qualquer conteúdo”. Por exemplo, um certificado com CN “*.rnp.br” poderia ser usado tanto para uma conexão SSL com “mail.rnp.br” ou “www.rnp.br”. Por fim, ainda existem os certificados EV-SSL. EV vem de Extended Validation. Esses certificados trazem alguns campos extras, mas seu diferencial é um compromisso firmado tanto entre as ACs e os principais navegadores, de que um certificado EV-SSL só é emitido mediante verificação rígida da posse do domínio para o qual ele é emitido. Um website autenticado com certificados EV-SSL é exibido no navegador em destaque, normalmente, com uma barra de endereços verde, enquanto em certificados comuns a barra fica amarela. A iniciativa é polêmica, e encontra como principal crítica a alegação de que se trata apenas de uma jogada de marketing, e que a concorrência entre as ACs acabará levando ao afrouxamento dos critérios de emissão do EV-SSL, e por consequência ele também perderá confiabilidade.

Em quem você confia? 11 Softwares vêm com ACs pré-instaladas: se você confia no software, confia nelas.

q

11 Certificados pré-instalados em software: 22 Microsoft. 33 Auditoria WebTrust ou equivalente; 33 Sem custo (auditoria é cobrada pela WebTrust). 22 Firefox: 33 Conformidade com algumas das políticas aceitas pela Mozilla. 33 Sem custo. Muitos softwares trazem ACs instaladas previamente em seus repositórios. Cada software tem seus critérios próprios de aceitação de ACs. Cada AC é instalada com flags que definem para que fins aquele certificado é considerado confiável, por exemplo: assinatura de e-mail, SSL, assinatura de documentos etc. Note que não é possível confiar cegamente nos certificados desses softwares para todos os fins. O Windows e Firefox, por exemplo, têm ACs que fornecem certificados gratuitos, mediante validação apenas do e-mail (AC Correio). Uma AC desse tipo não deve ser usada para nenhum outro fim, exceto assinatura de e-mails; e, ainda assim, como prova de posse do endereço de e-mail, não como prova de identidade do autor do e-mail. Utilizar os repositórios desses softwares como um repositório confiável de ACs para validar assinaturas digitais é uma atitude completamente incorreta.

AC Raiz ICPEDU

AC UFSC

ACSSL

AC Correio

Figura 4.5 Cadeia de certificação.

offline online

É necessário confiar em algum ponto da cadeia de certificação. Entretanto, confiar na raiz para tudo não é adequado. Note que dizer que a AC raiz é confiável do ponto de vista da emissão de certificados SSL significa dizer que confiamos até mesmo em um certificado SSL que por acaso seja emitido pela AC Correio. O ideal é instalar a AC Raiz sem flags de confiança (apenas para validação de caminho de


Certificado SSL

certificação/raiz confiável), e instalar as ACs que realmente desejamos confiar em cada aplicação (AC SSL no navegador web, AC Correio no cliente de e-mail etc.). 51

Apache 11 Servidor web responsável por 55,46% dos sites da internet.

q

11 Disponível para diversas plataformas, incluindo: 22 Windows. 22 Linux. 22 *BSD. 22 MacOS. 11 Software livre. Analisaremos a configuração do Apache para utilização de SSL. O Apache é um software para prover o serviço de páginas web, que segundo a Netcraft, está por trás de aproximadamente 55% dos sites da internet (julho de 2012). É um software livre, com licença própria pouco restritiva, disponível para as mais diversas plataformas, inclusive Windows, Linux, BSDs e MacOS. 11 Configuração.

q

11 Em geral, um arquivo chamado apache.conf ou httpd.conf no diretório “/etc”, além de arquivos incluídos nesse primeiro. 11 No Ubuntu Linux 12.04: 22 /etc/apache2/apache2.conf 22 /etc/apache2/sites-enabled/* 22 /etc/apache2/mods-enabled/* 22 /etc/apache2/ports.conf 11 Existem mil maneiras de preparar o Apache; invente uma. 11 Ativar módulo SSL: 11 sudo a2enmod ssl A configuração do Apache é baseada em um ou mais arquivos de configuração.


No caso do Ubuntu, a configuração é distribuída entre diversos arquivos, correspondendo a módulos e hosts hospedados na máquina. Em nossa máquina virtual, temos um Apache já configurado com o VirtualHost padrão, (localhost). O módulo SSL já está instalado; basta ativá-lo com o comando a2enmod ssl. VirtualHost SSL 11 Configuração

NameVirtualHost AA.BB.CC.DD:443 SSLEngine on ServerName dominio.instituicao.br SSLCertificateFile SITE.cer SSLCertificateKeyFile CHAVE.pem SSLCertificateChainFile CADEIA.crt ( . . . )

52

q

Um VirtualHost é um domínio hospedado no servidor web Apache. A configuração básica de um VirtualHost foge ao escopo desse curso, e por isso fornecemos um modelo de arquivo de configuração já preenchido para ser utilizado. Esses são os campos de configuração adicionados a um VirtualHost para ativar o uso de SSL: 11 SSLEngine ativa o SSL no VirtualHost; 11 SSLCertificateFile indica o certificado do servidor; 11 SSLCertificateKeyFile indica o local onde a chave privada está armazenada; 11 SSLCertificateChainFile indica um arquivo com os certificados da cadeia de certificação. Merece atenção a diretiva de configuração SSLCertificateChainFile. Com a adição dessa diretiva, o Apache fornecerá ao cliente não apenas o seu certificado, mas sim toda a cadeia de certificação correspondente ao seu certificado. Com isso, o usuário não precisa ter toda a ICP instalada na sua própria máquina para estabelecer a sua confiança, basta a AC Raiz.

Aplicação

HTTP

IMAP

SMTP Camada de Aplicação

(...)

Camada de Apresentação

Camada de Sessão

SSL/TLS

Figura 4.6 Camadas do modelo OSI.

Um aspecto importante sobre o SSL é que ele faz parte da camada de Sessão, e o gerenciamento de VirtualHosts (que permite o gerenciamento de múltiplos hosts em um único IP) do Apache fica na camada de Aplicação. A consequência imediata disso é que não é possível usar múltiplos hosts SSL em um mesmo IP/porta. Possíveis soluções incluem: 11 Uso de certificados com Wildcards (*.rnp.br): permite que vários hosts compartilhem o mesmo IP/porta, desde que todos pertençam ao mesmo domínio. O problema pode estar nas políticas da AC/ICP; 11 Distribuição dos hosts em portas distintas, diferentes da padrão (443): compromete http://site2.rnp.br:444; 11 Distribuição dos hosts em diversos IPs: é possível alocar mais de um IP para a mesma máquina, e até mesmo para a mesma placa de rede. Mas isso pode ser inviável em computadores que hospedam muitas páginas. Cuidados com a chave: 11 A chave privada deve ser armazenada com sigilo. Somente o root (Administrador) deve ter acesso.

chown -R root: /etc/apache2/ssl/private

q


usabilidade; o usuário terá de digitar, além do endereço, a porta de acesso. Por exemplo,

chmod -R 600 /etc/apache2/ssl/private/* 53

11 É possível deixar a chave decifrada, ou seja, “sem senha”. Mas isso não é recomendável.

q

openssl rsa -in chave.key -out chave.pem Um aspecto importante da utilização do SSL, mas que é muitas vezes negligenciado, é o armazenamento da chave privada associada ao certificado. A chave privada deve ser armazenada em local seguro. O ideal é mantê-la cifrada, e com acesso restrito ao usuário root. A remoção da cifragem da senha é uma opção adotada por muitos administradores. Se a chave for mantida cifrada, uma senha vai ser solicitada toda vez que o Apache for inicializado. Isso pode deixar o servidor indisponível se não existir ninguém para digitar a senha, por exemplo, quando ocorre uma queda de energia no meio da madrugada. Por uma questão de “praticidade”, muitos acabam deixando a chave sem proteção alguma no servidor, acrescentando um risco muito grande à confiabilidade do certificado, deixando a chave suscetível a roubo e consequente mau uso. Essa opção é especialmente perigosa em caso de servidores que são acessados por muitos usuários ou hospedam muitas páginas, especialmente páginas sobre as quais não se tem controle rígido


de qualidade da segurança dos scripts e códigos.

54

5 Conhecer as principais características do Sistema de Gerenciamento do Ciclo de Vida de Certificados Digitais da ICPEDU; Entender a arquitetura de ICPs, usando o SGCI; Conhecer os perfis de usuários do SGCI; Aprender a instalar o SGCI.

conceitos

Sistema de Gerenciamento do Ciclo de Vida de Certificados Digitais da ICPEDU; SGCI; Perfis de usuários; Criação de AC Raiz.

SGCI – Visão geral Principais características do SGCI:

q

11 Gerenciar o ciclo de vida do certificado digital da entidade: 22 Emissão do certificado. 22 Utilização do certificado. 22 Renovação do certificado. 22 Revogação do certificado. 11 Gerenciar a chave privada: 22 Software. 22 Hardware. O SGCI é um software de gerenciamento do ciclo de vida de certificados digitais. Um sistema desse tipo deve gerenciar o ciclo de vida de um certificado, que compreende as seguintes fases: 11 1: Emissão do certificado digital – Esse é o início do ciclo de vida, o “nascimento” do certificado; 11 2: Utilização do certificado – Essa é a principal fase, e a de maior duração, do ciclo de vida de um certificado digital; 11 3: Renovação do certificado – Nessa etapa, o certificado é substituído por um novo certificado. Essa etapa encerra a vida de um certificado digital, porém não encerra o ciclo de vida da entidade que possui o certificado; 11 4: Revogação do certificado – Nessa etapa o certificado é adicionado na Lista de Certificados Revogados, que o marca como revogado. Um certificado revogado não pode ser mais utilizado.

Capítulo 5 - SGCI – Conceitos e visão geral

objetivos

SGCI – Conceitos e visão geral

55

Além de gerenciar o ciclo de vida do certificado digital, também é necessário realizar a gerência do ciclo de vida da chave privada. Esse gerenciamento pode ser tanto em hardware quanto em software. Porém, não é possível gerenciar o ciclo de vida de uma chave privada, de forma segura, usando apenas software. Para isso, existem os Módulos de Segurança Criptográfica (MSC), ou Hardware Security Module (HSM). Mais adiante, será detalhada a gerência de chaves através de um MSC e listados os benefícios de sua utilização. Principais características do SGCI: 11 Auditável: 22 Código-fonte aberto; 22 Logs das operações. 11 Modelos de certificados: 22 Os certificados emitidos por uma determinada entidade tendem a possuir campos com valores iguais. 11 Flexibilidade. 11 O SGCI foi construído para ser utilizado em ambientes acadêmicos, para disseminar o conhecimento sobre certificação digital. Por esse motivo, optou-se em criar o SGCI com o código-fonte aberto, disponível para quem quiser aprender como ele foi implementado. Essa característica também é relevante para processos de homologação, em que o sistema pode ser facilmente inspecionado. 11 Todas as operações efetuadas pelo SGCI são registradas por logs. Esse aspecto é muito importante para processos de auditoria, em que é necessária a verificação de todos os passos realizados por uma entidade; 11 Normalmente os certificados emitidos por uma determinada entidade tendem a possuir campos iguais, padronizados. Para evitar que o operador tenha de configurar esses campos toda vez que for criar um certificado, foram criados os modelos de certificados. Os dados desses modelos são mesclados com os dados da requisição dos usuários, e


depois o certificado é emitido;

56

11 O SGCI foi criado tendo como um de seus princípios ser o mais flexível e simples possível. Ao mesmo tempo que deve ser possível utilizá-lo em diferentes ICPs, com diferentes estruturas, deve-se mantê-lo simples de utilizar. Uma das dificuldades da implementação do SGCI é balancear a flexibilidade com a facilidade de uso, uma vez que sistemas mais complexos normalmente trazem como desvantagem maior dificuldade de uso. O ponto de flexibilidade mais interessante do SGCI é a localização das entidades, que podem estar distribuídas de três maneiras:

AR Intermediária

AC Raiz

AR Raiz

AC Intermediária

AR 1 Serviços

Figura 5.1 Entidades no mesmo computador.

AR 2 Serviços AC Serviços

1. Elas podem estar todas reunidas no mesmo computador, funcionando de modo totalmente automatizado.

AR Raiz

Figura 5.2 Entidades em computadores diferentes.

AR Intermediária

AC Raiz

AC Intermediária

2. Podem estar separadas, uma em cada computador, tendo a opção de funcionamento de forma online ou offline, de forma manual ou automática. Mesmo com a possibilidade da total automatização da comunicação, existem casos em que é recomendável que as entidades estejam offline e a comunicação seja feita de forma manual, através da importação e exportação dos arquivos. Um exemplo é a AC Raiz da ICPEDU, onde a máquina hospedeira está desconectada de qualquer tipo de acesso à internet, desligada e guardada dentro de uma sala cofre. Toda vez que é necessário utilizar a AC Raiz, a máquina é ligada, e a comunicação com o mundo exterior somente é autorizada através de mídias.

AR Raiz

AC Intermediária

AC Serviços

AC Raiz

AR 1 Serviços

Figura 5.3 Mista.

AR 2 Serviços


AR Intermediária

57

3. A terceira opção é uma mescla entre a primeira e a segunda, em que podem existir uma ou várias entidades no mesmo computador, e outras entidades remotas.

q

Usuários. 11 Controle de usuários: 22 Administradores: fazem as “configurações” da entidade. 22 Operadores: operam a entidade no seu dia a dia. 22 Criador: cria novas entidades. 11 Controle político é separado do controle operacional. Os usuários do SGCI são classificados em três perfis: 11 Administrador: pessoas que controlam as configurações da entidade. Esses controles incluem relações de confiança, modelos de certificado, políticas etc.; 11 Operador: pessoas que fazem as operações da entidade, como aprovar requisições, emitir certificados, emitir LCR etc.;

11 Criador: esse usuário é único, responsável por criar entidades, administradores e operadores. Esses três papéis foram criados pensando em separar o controle operacional do administrativo, para impedir o “total controle” por um único usuário. O operacional somente faz o que o administrativo libera. Por sua vez, o administrativo configura as ações, porém não consegue executá-las.

Árvore de Certificação


AC Raiz

58

AC UFSC

AC Instituição

Depois de conhecermos o funcionamento das entidades e os usuários no SGCI, podemos conhecer a estrutura que será criada ao final desse curso. Em um primeiro nível teremos a AC Raiz, e a seguir dela teremos a AC UFSC e a AC Instituição. A AC Instituição representa a instituição do aluno.

Figura 5.4 Árvore de certificação que será criada como exemplo.

Administradores

AR Raiz

Operadores AC Raiz AR Instituição

AR UFSC

AC UFSC

AC Instituição

Operadores

Figura 5.5 Estrutura completa.

Operadores

Administradores

Administradores

A princípio, parece uma estrutura muito pequena e simples, com apenas três entidades. Porém, ao olharmos detalhadamente para a figura 5.5, podemos perceber que ela é composta por vários elementos. Para cada AC devem existir usuários operadores, administradores e pelo menos uma AR. Resumidamente, para a estrutura de exemplo, necessitarão ser criados, no mínimo, 12 usuários, 3 ACs e 3 ARs.

SGCI – Instalação Para sistemas Debian, a instalação do SGCI é feita através da ferramenta apt. Basta seguir os passos que estão detalhados no próprio site do SGCI, na página: https:// projetos.labsec.ufsc.br/ sgci/wiki/ version_2_0_0/ instalacao

Site do SGCI:

q

https://projetos.labsec.ufsc.br/sgci Passos da instalação: 11 Configurar repositório do SGCI no apt. 11 Atualizar lista de pacotes do apt. 11 Instalar o SGCI através do comando apt-get install sgci. Instruções passo a passo de instalação: https://projetos.labsec.ufsc.br/sgci/wiki/version_2_0_0/instalacao 11 Inicialmente, deve-se adicionar o repositório do SGCI no arquivo de configuração de repositórios do apt. Depois, é necessário atualizar a lista de pacotes do apt e então instalar o SGCI e suas dependências através do comando apt-get install sgci.


w

59

Figura 5.6 Cadastro criador.

Após a instalação concluída, deve-se criar o usuário criador. O formulário de criação desse


usuário é apresentado na figura 5.6.

60

Figura 5.7 Tela de autenticação.

Com o usuário criado, já é possível fazer login no sistema. A tela de login do SGCI é apresentada na figura 5.7. Nela há três opções para escolher: 11 Modo Operador: executa as tarefas de operar entidades;

11 Modo Administrador: configura entidades; 11 Modo Criador: faz as tarefas de criação de entidades. Ao selecionar um dos modos, a próxima etapa é selecionar a entidade. Nos próximos slides, vamos conhecer um pouco mais sobre cada tipo de usuário. Após a entidade selecionada, é necessário digitar o login e a senha do mesmo.

Perfis de usuário Criador:

q

11 Cria entidades. 11 Faz backup. 11 Configura Módulo de Serviço Criptográfico (MSC). 11 Exporta logs. Administrador: 11 Administrador de AC. 22 Altera configurações da AC. 22 Cadastra relações de confiança. 22 Cadastra modelos de certificados. 22 Cadastra usuários. 22 Exporta logs. 11 Administrador de AR: 22 Altera configurações da AR. 22 Cadastra relações de confiança. 22 Cadastra usuários. 22 Exporta logs. Operador: 11 Operador de AC. 22 Importa requisições de emissão de certificados. 22 Aprova/Rejeita requisições de emissão de certificados. 22 Importa requisições de revogação de certificados. 22 Aprova/Rejeita requisições de revogação de certificados.

22 Emite Listas de Certificados Revogados (LCRs). 11 Operador de AR: 22 Importa requisições de certificado. 22 Aprova/rejeita requisições de certificado. 22 Solicita revogação de certificados. Principais funções do usuário criador: 11 Criar entidades (AC/AR); 11 Gerar e restaurar backup; 11 Adicionar e configurar MSCs;


22 Revoga certificados.

11 Exportar logs. 61

O Perfil de Administrador possui diferentes funções para AC e AR. O administrador de uma AC pode: 11 Alterar as configurações da AC; 11 Cadastrar e excluir relações de confiança com outras entidades; 11 Cadastrar e alterar modelos de certificados; 11 Cadastrar usuários; 11 Exportar os logs da AC. Já o Administrador de AR executa as funções de: 11 Alterar as configurações da AR; 11 Cadastrar relações de confiança com outras entidades; 11 Cadastrar usuários; 11 Exportar os logs da AR. O perfil de Operador possui diferentes funções para AC e AR. O Operador de uma AC pode: 11 Importar requisições de emissão de certificado; 11 Aprovar ou rejeitar requisições de emissão de certificado; 11 Importar requisições de revogação de certificados; 11 Aprovar ou rejeitar requisições de revogação de certificados; 11 Revogar certificados; 11 Emitir e exportar listas de certificados revogados. Já o Operador de AR executa as funções de: 11 Importar requisições de certificados (assinadas pelo requerente do certificado); 11 Verificar e aprovar, ou rejeitar, as requisições de certificado; 11 Solicitar a revogação de certificados. Administrador AR


Operador AR

62

AR Raiz

AC Raiz

Administrador AC Usuário

Operador AC

Figura 5.8 Processo de emissão de certificado.

Na figura 5.8, podemos observar como os diferentes tipos de usuários interagem durante a emissão de um certificado. Inicialmente o usuário apresenta a AR e requisita um certificado. O operador da AR verifica os dados do usuário e da sua requisição. Caso esteja tudo correto, a requisição é aprovada, assinada digitalmente pela AR e enviada para uma AC confiável. Quem determina qual AC é confiável é o administrador da AR. Após a requisição ser enviada para a AC, o operador da AC emite o certificado e devolve para AR. Por fim, a AR envia o certificado ao usuário.

Autoridades Certificadoras AC Raiz:

q

11 Certificado autoassinado. AC Intermediária: 11 Cria-se uma requisição de certificado, que é enviada para uma AC superior, onde é feita a emissão do certificado da nova AC. No SGCI, uma AC pode ser de dois tipos: 11 AC Raiz: entidade com certificado autoassinado. Um certificado autoassinado é assinado com a chave privada correspondente à chave pública que é anexada ao certificado; 11 AC Intermediária: para esse tipo de entidade, é gerada uma requisição de certificado. Essa requisição deve ser enviada para uma AR, para a verificação dos dados. A AR então encaminha a requisição para uma AC superior, que emite o certificado. Após o certificado ser emitido, este é importado no SGCI. Somente quando o certificado tiver sido importado é que a entidade se torna operacional.


Vamos iniciar a criação da nossa estrutura de exemplo pela criação da AC Raiz.

63


Criação de AC Raiz

64

Figura 5.9 Criação de AC Raiz.

Para criar uma AC Raiz, basta logar no módulo criador, depois ir ao menu e clicar em “Entidades” > “Criar AC Raiz”. Será exibida uma tela igual à da figura 5.9. Para uma AC Raiz, os campos disponíveis inicialmente são: 11 Nome Comum: nesse campo deve ser preenchido o nome comum, do inglês “common name”, do sujeito do certificado; 11 Organização: nesse campo deve ser preenchido o nome da organização, do inglês “organization name”, do sujeito do certificado; 11 Unidade da Organização: no campo deve ser preenchida a unidade da organização, do inglês “organizational unit”, do sujeito do certificado; 11 Cidade: esse campo deve ser preenchido com a cidade, do inglês city, do sujeito do certificado;

11 País: deve ser preenchido com a sigla do país, do inglês country, do sujeito do certificado e deve conter somente dois caracteres; 11 E-mail: esse campo deve ser preenchido com o e-mail do sujeito do certificado; 11 Senha: nesse campo deve ser digitada a senha do usuário criador. Após o preenchimento dos campos, para criar a AC deve-se clicar no botão Cadastrar.

Todos esses campos não podem conter caracteres especiais, como acentuação. Sendo assim, a palavra “Brasília”, por exemplo, deve ser digitada “Brasilia”, sem acento.

Campos avançados Além dos campos mencionados, existem mais opções para o certificado da AC a ser criada. Essas opções são identificadas na figura 5.9 e apresentadas a seguir: 11 Advanced Subject: nela pode-se adicionar mais campos ao sujeito do certificado, além dos apresentados nas opções básicas; 11 Issuer Alternative Name: essa extensão permite que sejam fornecidos nomes alternativos ao emissor do certificado. Ela geralmente não é utilizada, uma vez que o que mais importa em um certificado são as informações do sujeito; 11 Subject Alternative Name: essa extensão permite que sejam fornecidos nomes alternativos ao sujeito do certificado. Ela é muito útil para certificados de entidades finais. Com ela é possível, por exemplo, informar o endereço eletrônico do sujeito do certificado; 11 Key Usage: extensão que determina as funções que a chave do sujeito do certificado pode utilizar. Cada uma das caixas de seleções especifica uma funcionalidade que a chave pode ter. Essas funcionalidades possuem algumas regras para serem assinaladas. Essas regras são descritas na seção 4.2.1.3 da RFC 5280; 11 Extended Key Usage: extensão usada para indicar aplicações específicas para chaves públicas. Ela é composta por uma sequência de Object Identifiers (OIDs), onde cada OID identifica um contexto de aplicação particular em que a chave pública pode ser utilizada; 11 Certificate Policies: 22 OID da PC: uma AC pode possuir uma Política de Certificação (PC), que define como a AC opera, e como os certificados são emitidos. Essas políticas são identificadas através de um Object Identifier (OID) estabelecido por órgão responsável. Normalmente os 22 URI da DPC: quando apenas o OID da PC não for suficiente para identificar a política da entidade, pode ser adicionado um ponteiro para a Declaração de Práticas de Certificação (DPC). Esse ponteiro normalmente é um link para o pdf da DPC; 22 User Notice: esse campo é um texto colocado nos certificados que possuírem um OID da PC. Esse texto pode ser uma nota ao usuário, para identificar a política de forma mais amigável. 11 Ponto de distribuição de LCR: 22 URL LCR: uma AC pode emitir Listas de Certificados Revogados (LCRs) e disponibilizá-la em algum repositório. Esse campo contém os links que apontam para a última LCR emitida pela AC e é útil para os softwares baixarem a última LCR, no momento da validação de um certificado.


OIDs são atribuídos pela Internet Assigned Numbers Authority (IANA);

65

11 Basic Constraints: 22 Certificado de AC: nesse campo, é selecionado se um certificado é de AC ou de entidade final. Um certificado de AC pode emitir outros certificados, enquanto que um certificado de entidade final não pode emitir certificados abaixo dele; 22 Path Length: esse campo determina quantos níveis de ACs podem existir abaixo da AC onde está sendo criada a árvore de certificação. Por exemplo, se colocarmos nº = 0, quer dizer que a nossa AC somente pode emitir certificados para usuários. Se colocarmos nº = 1, significa que a nossa AC pode emitir certificados para outras ACs e para usuários. Nesse caso, as “outras ACs” somente podem emitir certificados para usuários. 11 Identificadores da chave: 22 Subject Key Identifier: essa extensão serve para identificar a chave do sujeito do certificado e normalmente é feita através do hash da chave pública do sujeito, contida no certificado; 22 Authority Key Identifier: essa extensão serve para identificar a chave do emissor do certificado e pode conter até três campos: Hash da chave pública do emissor; número serial do certificado do emissor; e o campo issuer, do certificado do emissor. 11 Outras opções: 22 Validade: determina por quantos dias o certificado da AC é válido. Esse não é necessariamente o período de vida de um certificado, pois um certificado pode ser revogado a qualquer momento (desde que não expirado); 22 Algoritmo de hash: algoritmo que será utilizado no momento da assinatura do certificado. 11 Opções da chave: 22 Caixa de seleção “Utilizar MSC”: selecionada caso a chave da entidade esteja armazenada em um MSC. No nosso exemplo, vamos gerar as chaves sem usar um MSC. Ou seja, o SGCI vai gerar a chave da AC. Vale lembrar que o gerenciamento do ciclo de vida de uma chave privada por software é bem menos seguro que o gerenciamento da chave por um MSC. Portanto, a opção por software deve ser utilizada somente em


ambientes de testes.

66

Se optarmos pelo SGCI gerar a chave privada da AC, ficam disponíveis dois campos: 22 Algoritmo: algoritmo do par de chaves da entidade. Há duas opções de algoritmo: RSA e ECDSA. Caso seja escolhida a primeira opção, deverá ser também selecionado o tamanho da chave; já na segunda opção, deverá ser selecionado o tipo da curva; 22 Tamanho da chave: tamanho em bits da chave privada que vai ser gerada pelo SGCI. Quanto maior o tamanho da chave, mais segura a chave. Porém, é gasto mais processamento para realizar as atividades que usam a chave; 22 Tipo da curva: é o tipo de curva elíptica que vai ser gerada pelo SGCI. A principal vantagem do uso do algoritmo ECDSA é que requer chaves de tamanhos menores para proporcionar a mesma segurança que chaves RSA. Se for feita a opção por utilizar uma chave em MSC, será necessário selecionar o MSC que vai ser utilizado e o identificador da chave privada que será usada para assinar o certificado. Esse identificador é o nome que é dado para a chave, no momento de sua criação no MSC.

Figura 5.10 Tela de confirmação do cadastro da AC Raiz.

Após cadastrar a entidade, o SGCI mostra a tela de confirmação do cadastro, que é apresentada na figura 5.10. Nessa tela é exibida uma lista com todas as entidades já criadas, com o nome da entidade, data de criação, data de validade, o status da entidade e as possíveis ações. Ao clicar no ícone

, o usuário será redirecionado para a tela apresentada na figura 5.11 e

poderá visualizar os detalhes da entidade. Um dado muito importante mostrado nessa tela é o hash do certificado. Esse hash normalmente é publicado para as pessoas poderem verificar se o certificado que elas possuem é realmente o certificado original da AC.


Figura 5.11 Detalhes da entidade.

67

Usuários

Figura 5.12 Cadastro de usuários.

Após a criação da AC Raiz, é necessário criar os usuários que farão a operação dessas entidades. A tela de cadastro de usuários é apresentada na figura 5.12, e contém campos de identifi-


cação do usuário. O único campo obrigatório é o nome do usuário.

68

Figura 5.13 Atribuição de papel como Criador.

Após cadastrar o usuário, é necessário atribuir um papel a ele. O usuário criador pode atribuir os papéis de administrador e operador aos usuários. Para atribuir um papel a um usuário cadastrado, basta logar como criador, ir ao menu e clicar em “Usuários” > “Atribuir papel”. O usuário será redirecionado para a página apresentada na figura 5.13. No primeiro campo seleciona-se o usuário, depois a entidade e, em seguida, o papel do usuário. É necessário também informar o login e uma senha para o novo papel, além da confirmação da senha. Para autorizar a operação, o criador deve informar a sua senha. No SGCI, um mesmo usuário pode participar de diferentes papéis em diferentes entidades. Por exemplo, o usuário João pode ser Administrador da AC Raiz e Operador da AR Raiz. Para cada papel do usuário João, ele pode utilizar uma senha e um login diferente.

Figura 5.14 Atribuição de papel como Administrador.

Para criar usuários como Administrador, é necessário logar como Administrador de uma

Seleciona-se o usuário, entre os já cadastrados, o papel que será atribuído, o login e a senha do novo papel. Para autorizar a operação, o Administrador deve informar sua senha. O Administrador também pode cadastrar usuários através do menu “Usuários”. O processo de cadastro de um usuário ocorre da mesma forma como apresentado para o criador.


entidade, ir ao menu e clicar em “Usuários” > “Atribuir papel”. O usuário será redirecionado para a página apresentada na figura 5.14.

69

Configurações

Figura 5.15 Editar configurações de AC.

Para editar as configurações de uma AC, um dos administradores deve se logar e escolher a opção “Configurações” no menu. O usuário será redirecionado para a tela apresentada na figura 5.15. Serão listadas duas opções de configuração (Online e Offline). Caso seja escolhida a opção online, mais duas opções aparecem (“Resposta manual” e “Resposta automática”). Se for selecionada “Resposta automática”, é necessária a escolha de um modelo de certificado padrão. As opções de configuração estão descritas com mais detalhes a seguir: 11 Onlineou offline: a escolha entre online e offline está relacionada à maneira em que é feita a comunicação entre AC e AR. No modo online, as mensagens são trocadas de forma automatizada entre as entidades. Por outro lado, no modo offline é necessário


que as mensagens sejam exportadas e importadas manualmente nas entidades. Por

70

questões de disponibilidade, é comum que ACs finais, isto é, que emitem certificados para entidades finais, sejam configuradas de forma online. Entretanto, ACs não finais, que requerem um nível maior de segurança, normalmente operam de forma offline. Vale ressaltar que essa configuração não está relacionada à comunicação da máquina onde o SGCI está instalado com o mundo externo (internet). Ela diz respeito somente à forma da troca de mensagens entre diferentes entidades no SGCI. Uma AC pode estar configurada de forma offline e ainda assim a máquina ter comunicação com a internet; 11 Resposta automática ou manual: a escolha entre resposta manual e automática está relacionada com a forma como são emitidos os certificados. Na opção de resposta manual é necessária a intervenção de um operador para aprovar e requisição e, consequentemente, emitir o certificado. Já na opção de resposta automática, a emissão é feita sem a intervenção do operador. Assim como no caso de ACs online e offline, ACs finais são normalmente configuradas com a opção de resposta automática, por questões de disponibilidade, enquanto que as demais ACs operam de forma manual, por questões de segurança. O modelo de certificado padrão é utilizado quando a AC está configurada com a opção de resposta automática. Como visto no item anterior, nessa opção a emissão do certificado é feita de forma automática, sem a intervenção de um operador.

Como não há a presença de um operador para escolher o modelo de certificado, deve ser definido um modelo padrão para ser utilizado em todas as emissões.

Figura 5.16 Editar configurações de AR.

Para editar as configurações de uma AR, os passos são os mesmos de uma AC. O administrador da AR deve se logar e escolher a opção “Configurações” no menu. O usuário será redirecionado para a tela apresentada na figura 5.16. A diferença entre configuração de AC e AR é em relação às opções existentes. Na AR só existem as opções Online e Offline.

Figura 5.17 Cadastro de Modelos de Certificado.


Modelo de Certificado

71

No SGCI é possível cadastrar Modelos de Certificado, que são configurações pré-determinadas para a emissão de certificados. Por exemplo, um certificado SSL tem certas propriedades comuns para todos os certificados e, sem os modelos de certificado, toda vez que o operador fosse emitir um certificado SSL, ele teria de selecionar ou configuraras mesmas propriedades. O SGCI traz quatro modelos de certificado pré-configurados: 11 Autoridade Certificadora; 11 Autoridade de Registro; 11 E-mail; 11 Servidor SSL. Para cadastrar um novo modelo de certificado, o usuário deve se logar com o perfil de administrador em alguma AC, ir ao menu “Modelos de Certificado” > “Criar”. Será exibida uma tela igual à figura 5.17. O cadastro de um novo modelo de certificado pode ser baseado em outros modelos já existentes. 11 O modelo de certificado a ser baseado é escolhido no primeiro campo, Modelos de Certificado pré-configurados; 11 O segundo campo é o nome do modelo de certificado; 11 No terceiro campo é selecionado o algoritmo utilizado para assinar o certificado; 11 No quarto campo, é colocado o período de validade dos certificados que forem emitidos utilizando esse modelo de certificado; 11 Os próximos campos são todos para configurar as extensões dos certificados. A extensão Basic Constraints possui dois campos: 11 Certificado de AC: nesse campo é selecionado se um certificado é de AC ou de entidade final. Um certificado de AC pode emitir outros certificados, enquanto um certificado de


entidade final não pode emitir certificados abaixo dele;

72

11 Path Length: caso o certificado seja de AC, esse campo limita a quantidade máxima de certificados que podem existir abaixo da AC na árvore de certificação. O campo Subject Key Identifier configura se essa extensão deve estar presente no certificado ou não. O mesmo ocorre para o campo Authority Key Identifier. Os campos Key Usage, Extended Key Usage, URL da LCR, OID da PC, URI da DPC e User Notice possuem a mesma configuração que os campos do cadastro de AC, explicados anteriormente. Depois de configurado, para salvar o modelo de certificado basta clicar em “Cadastrar”.

Criação de AC Raiz 11 Criação da chave e do certificado autoassinado da AC. 11 Criação dos usuários. 11 Atribuição do papel de Administrador e Operador. 11 Configuração da AC. 11 Configuração dos modelos de certificados (opcional).

q

Para criar uma AC Raiz, é necessário executar todos os passos descritos até agora, que são: 11 Geração da chave do certificado autoassinado da AC: isso é feito no módulo criador, quando é cadastrada uma entidade; 11 Criação dos usuários: efetuada ao cadastrar usuários; 11 Atribuição dos papéis de Administrador e Operador; 11 Configuração da AC: esse passo é realizado através do papel de Administrador. 11 Configuração dos modelos de certificados: esse passo é opcional, feito como


Administrador da AC.

73

74


6 Aprender sobre a criação de Autoridades Certificadoras e de Registro no SGCI; Conhecer a emissão e revogação de certificados no SGCI; Entender a emissão de cópias de segurança e de registros de atividades no SGCI.

conceitos

Criação de Autoridades Certificadoras Intermediárias; Criação de Autoridades de Registro; Relacionamentos de confiança; Emissão de certificados; Revogação de certificados; Lista de certificados revogados (LCR); Cópias de segurança (backups); Registro de atividades (logs).

Criação de Autoridades Certificadoras Intermediárias Problema: criação da AC UFSC:

q

11 Não é um certificado autoassinado. 11 Certificado da AC UFSC é emitido pela AC Raiz. Qual o tipo de certificado da AC UFSC? 11 Certificado de AC Intermediária. Qual a opção de cadastro que deve ser escolhida ao cadastrar essa AC no SGCI? 11 AC Intermediária. Agora que já foi gerado o certificado da AC Raiz, é necessário gerar os certificados das ACs abaixo da AC Raiz. O certificado da AC Raiz é assinado pela própria chave da AC Raiz (por isso recebe o nome de certificado autoassinado). Os certificados das entidades a seguir da AC Raiz são assinados pela AC Raiz. Esses não são certificados autoassinados. No SGCI, essas entidades são denominadas ACs Intermediárias. E, para gerar um certificado para essas entidades, o processo é um pouco diferente do processo de geração da AC Raiz. Para criar uma AC Intermediária no SGCI, deve-se entrar no módulo criador escolhendo a opção do menu “Entidades” > “Criar AC Intermediária”. A figura 6.1 representa o formulário de cadastro de uma AC Intermediária.

Capítulo 6 - SGCI – Gerenciamento de Entidades

objetivos

SGCI – Gerenciamento de Entidades

75

Figura 6.1 Cadastro de uma AC Intermediária.

Os campos básicos do certificado são iguais aos campos do cadastro de AC Raiz. Pode-se perceber que existem bem menos campos no cadastro de uma AC Intermediária em relação ao de uma AC Raiz. Isso acontece porque alguns dos campos de um certificado digital são definidos pelo sujeito do certificado, e outros campos são definidos pela entidade que emite o certificado. Os campos presentes no cadastro da AC Raiz que não estão presentes


no cadastro de AC Intermediária são os campos inseridos pela AC emissora (e configurados

76

através dos modelos de certificados).

Depois de criada a requisição de certificado da AC Intermediária, o usuário será redirecionado para a listagem de entidades, e será exibida uma mensagem de sucesso, conforme apresentado na figura 6.2. É importante salientar a diferença dessa lista em relação à lista de ACs Raiz. Na lista de ACs Raiz, é feito o download do certificado, enquanto que na de ACs Intermediárias é feito o download da requisição. isso acontece porque uma AC Raiz tem o seu certificado autoassinado, então uma vez gerada a chave da entidade, é possível assinar imediatamente o certificado. Já uma AC Intermediária tem o seu certificado assinado por outra AC, sendo necessário enviar uma requisição para alguma AC superior assinar o seu certificado.

Figura 6.2 Lista de ACs Intermediárias: Criação.

O SGCI utiliza o padrão PKCS#10, então qualquer software de AC que use esse padrão consegue abrir o arquivo de requisição gerado pelo SGCI. Agora essa requisição gerada deve ser importada na AC Raiz. Para isso, deve-se entrar como operador da AC Raiz, no menu ir em “Requisições de Certificados” > “Importar”, selecionar a requisição da AC UFSC e clicar em “Submeter”. Após importada a requisição, o usuário é redirecionado para a listagem das requisições pendentes, conforme apresentado na figura 6.3. Para aprovar a requisição o usuário deve clicar no ícone

Figura 6.3 Lista de requisições pendentes.

, localizado na coluna Ações.

Em seguida o usuário será redirecionado para a página apresentada na figura 6.4. Nela conterá algumas informações da requisição de certificado e será necessário escolher um modelo de certificado. Para autorizar a operação, o operador deve informar a sua senha e

Figura 6.4 Emissão do certificado.

Ao aprovar a requisição, o certificado da AC UFSC é emitido, ou seja, foi assinado pela AC Raiz ICPEDU. Agora é necessário fazer o download do certificado. Para isso, o usuário deve escolher a opção do menu “Certificados”. Na lista de certificados ativos, apresentada na figura 6.5, devemos clicar no ícone

Figura 6.5 Lista de certificados ativos.

, localizado na coluna Ações.

O próximo passo é importar o certificado, para tornar a entidade ativa. Para isso, devemos acessar o sistema como criador, selecionar a opção do menu “Entidades” > “Gerir” e clicar na


clicar em Submeter.

aba “ACs Intermediárias”. Na listagem das ACs intermediárias, apresentada na figura 5.6, 77

o usuário deve clicar no ícone

e selecionar o certificado da AC. É necessário que o usuário

insira sua senha para configurar a operação.

Se a importação do certificado ocorrer com sucesso, a situação da AC muda para ativa. Agora, para a entidade estar apta a emitir certificados, basta criar uma AR, vincular a AR com a AC, cadastrar os administradores e operadores e configurar os modelos de certificado da AC. Os passos de criação de usuário são os mesmos que foram efetuados para a AC Raiz. Já os passos para criação e vínculo com AR serão apresentados a seguir. Em resumo, os passos para a criação de uma AC Intermediária são: 11 Criação da chave e da requisição de certificado da AC Intermediária; 11 Emissão do certificado por uma AC; 11 Importação do certificado da AC Intermediária; 11 Criação dos usuários; 11 Atribuição do papel de administrador; 11 Atribuição do papel de operador; 11 Configuração da AC Intermediária; 11 Configuração dos modelos de certificados emitidos pela AC Intermediária.

Criação de Autoridades de Registro Quando uma AR é criada, ela também precisa ter o seu certificado emitido por uma AC. O


processo de criação de uma Autoridade de Registro é similar ao processo de criação de uma

78

AC Intermediária. Para cadastrar uma AR, deve-se entrar no sistema como criador e escolher a opção do menu “Entidades” > “Criar AR”. Após entrar com os dados, para gerar a requisição, basta que o usuário clique em “Cadastrar”. O usuário será redirecionado para a lista de ARs e essa entidade estará com o estado pendente. Para ativar a entidade, é necessário fazer os mesmos passos explicados na criação de AC Intermediária.

Relacionamentos de Confiança 11 A relação de confiança é criada somente após a entidade ter capacidade de entrar em

q

funcionamento (o certificado da entidade já foi emitido). Uma AC pode ser configurada para somente emitir certificados para requisições que foram aprovadas por uma AR confiável. Para determinar qual AR é confiável, é necessário estabelecer uma relação de confiança mútua. Essa relação de confiança somente pode ser estabelecida após a entidade estar pronta para operação (após o seu certificado ser emitido). Uma AC pode ter mais de um relacionamento de confiança, conforme mostrado na figura 6.7.

Figura 6.6 Lista de ACs Intermediárias: Importação.

Quando há um relacionamento de confiança entre uma AC e uma AR, a AC pode emitir certificados para qualquer requisição aprovada por essa AR.

Não confundir relação de confiança com a relação na qual o certificado X foi emitido pela AC Y.

Administradores

AR Raiz

Operadores AC Raiz AR Instituição

AR UFSC

AC UFSC

AC Instituição

Operadores

Administradores

Administradores

Existem três maneiras de cadastrar um relacionamento de confiança: 11 Offline com as entidades na mesma máquina: as autoridades que farão o relacionamento de confiança foram criadas na mesma instalação do SGCI. A troca de arquivos acontece de maneira automática; 11 Offline com as entidades em máquinas distintas: as autoridades que farão o relacionamento de confiança não foram criadas na mesma máquina; 11 Online: as autoridades que farão o relacionamento de confiança devem estar configuradas como online, e a troca dos arquivos é feita de maneira automatizada. O relacionamento de confiança deve ser mútuo, isto é, a AC deve confiar na AR e a AR deve confiar na AC. Isso é feito cadastrando a relação de confiança tanto na AR quanto na AC. Antes de fazer um relacionamento de confiança, é necessário criar os arquivos de relacionamento de confiança. O arquivo de relacionamento de confiança da AR é criado quando a entidade torna-se ativa no sistema e fica disponível para download em uma área pública do SGCI. Para a AC, é necessário que o administrador da AC entre no sistema. Logo na página inicial, haverá uma listagem com as tarefas pendentes, similar à da figura 6.8.


Figura 6.7 Estrutura de certificação.

Operadores

79

Figura 6.8 Tarefas pendentes.

Para criar o arquivo de relacionamento de confiança, o administrador deve clicar na opção “Criar arquivo de relacionamento” e, na página seguinte, informar sua senha para autorizar a operação. Esse arquivo também fica disponível na área pública do SGCI. Como foi explicado anteriormente, existem três maneiras de fazer um relacionamento de confiança, sendo que duas possuem a troca dos arquivos de maneira automática. Para a outra, é necessário fazer o download dos arquivos de relacionamento de confiança. Para fazer o download dos arquivos de relacionamento de confiança, não é necessário estar logado. Os arquivos podem ser acessado através de página principal do SGCI, clicando na opção “Listar arquivos de Relações de Confiança” do menu. Na figura 6.9, podemos ver que os arquivos estão separados em duas listas, arquivos de relacionamento de AC e de AR. Para fazer o download de qualquer arquivo, basta clicar no ícone

.

Para fazer um relacionamento de confiança offline na mesma máquina, é necessário entrar como administrador de AC e, no menu, escolher a opção “Relações de confiança” > “Cadastrar Offline”. O usuário será redirecionado para a página apresentada na figura 6.10. Deve-se


marcar a opção “Entidade registrada” e selecionar a entidade com que se deseja fazer o relacionamento de confiança.

Figura 6.10 Cadastrar relacionamento de confiança offline na mesma máquina.

Para que o relacionamento de confiança seja mútuo, deve ser feitos esses mesmos passos como administrador de AR. Para criar um relacionamento de confiança entre duas entidades remotas (em máquinas diferentes), é necessário primeiro obter o arquivo de relação de confiança da entidade em que se deseja estabelecer o relacionamento e depois importá-lo no SGCI da entidade que está fazendo o relacionamento. Por exemplo, se a AC X deseja estabelecer um relacionamento de confiança com a AR Y, o administrador da AC X precisa obter o arquivo de relação de confiança da AR Y e depois importá-lo na página de cadastro de relacionamento de confiança de sua AC.

80

Figura 6.9 Lista de arquivos de relacionamento de confiança.

Para importar um arquivo de relacionamento de confiança, basta entrar como administrador de AC e escolher a opção do menu “Relações de confiança” > “Criar Offline”. A página será redirecionada e terá um formulário igual ao da figura 6.11. Nesse formulário, devemos deixar a opção “Entidade não registrada” marcada, selecionar o arquivo de relacionamento de confiança e clicar em “Submeter”.

Figura 6.11 Importar o arquivo de relacionamento de confiança.

Para finalizar o processo de criação de relacionamento de confiança, basta fazer os mesmos passos como administrador de AR e selecionar o arquivo de relacionamento de confiança da AC. Para fazer a troca de arquivos online, é necessário que as duas entidades estejam configuradas como online e que o SGCI 2.0.0 esteja configurado em um ambiente com rede. A figura 6.12 ilustra o formulário para fazer um relacionamento de confiança online. Para acessá-lo, devemos entrar como administrador de AC e escolher a opção do menu “Relações de confiança” > “Criar Online”. Nesse formulário, será necessário marcar o protocolo, fornecer o endereço de IP e o número de porta das configurações do SGCI que contém a AR, e depois clicar em “Submeter”.

Figura 6.13 Lista de entidades para fazer relacionamento de confiança.

Após clicar em “Submeter”, se tudo estiver preenchido corretamente, a página será redirecionada e conterá uma listagem de entidades disponíveis para fazer o relacionamento de confiança, conforme mostrado na figura 6.13. Marque uma das entidades para fazer o relacionamento de confiança e clique em “Cadastrar”.


Figura 6.12 Criar relacionamento de confiança online.

81

Para finalizar a criação de um relacionamento de confiança online, é necessário repetir o processo como administrador de AR preenchendo no formulário de criação de relacionamento de confiança online as informações do SGCI em que a AC está.

Emissão de certificados Todo certificado que vai ser gerenciado pelo SGCI deve passar pelo processo de importação da requisição de certificado, sendo ele em uma AR ou em uma AC. O caso de importação na AC foi abordado anteriormente, na criação da AC Intermediária. Agora, vamos abordar o caso da importação em uma AR. Para importar uma requisição de certificado em um AR, ela deve primeiramente ter um relacionamento de confiança com a AC que vai emitir o certificado. Para importar uma requisição na AR, deve-se estar no sistema como operador de AR e, no menu, escolher a opção “Requisições de Certificados” > “Importar Requisição”. O usuário será redirecionado para a página apresentada na figura 6.14. Nela será necessário selecionar o arquivo de requisição, escolher a AC de destino (só estarão disponíveis as ACs que possuem um relacionamento de confiança com essa AR) e clicar em “Submeter”.

Figura 6.14 Importar o arquivo de requisição.

Em seguida, o usuário será redirecionado para a página apresentada na figura 6.15. Essa página contém uma listagem com todas as requisições de certificado com aprovações


pendentes.

82

Essa mesma listagem pode ser acessada através do menu, na opção “Requisições de Certificados” > “Gerir”. Quando uma AR recebe uma requisição, é necessário verificar os dados da requisição. Para isso, o operador da AR deve clicar no ícone

. O usuário será redirecionado para a página

apresentada na figura 6.16. Nela, deve-se marcar a opção “Editar campos avançados”. Aparecerão as informações dos campos avançados do sujeito que devem ser verificados.

Figura 6.15 Lista de aprovações pendentes da AR.

Figura 6.16 Editar requisição.

Para rejeitar a requisição, o operador deve clicar no ícone

, referente à requisição que será

rejeitada. Se o operador optar por aprovar a requisição, deve-se clicar no ícone

. No caso

da aprovação, o operador será redirecionado para uma página mostrando os detalhes da requisição a ser aprovada e deverá inserir sua senha para autorizar a operação. Após o operador tomar a decisão de aceitar ou rejeitar uma requisição, ele pode consultar o estado dessas requisições na listagem “Outras requisições”. Para acessá-la, o operador deve acessar a opção do menu “Requisições de Certificados” > “Gerir”, e clicar sobre a aba “Outras requisições”. Essa listagem é apresentada na figura 6.17.

Caso a AC e AR estejam na mesma máquina ou configuradas para funcionar de modo online, a requisição será enviada para a AC automaticamente. Caso estejam em máquinas distintas e configuradas para funcionar de modo offline, o operador da AR deverá fazer download da requisição aprovada e enviar para a AC. Para fazer o download da requisição, o operador da AR deve clicar no ícone

, na listagem apresentada na figura 6.17. A importação da requi-

sição na AC é semelhante à importação na AR, explicada anteriormente. As requisições pendentes na AC podem ser acessadas pelo operador através da opção “Requisições de Certificado” > “Gerir” do menu. O usuário será redirecionado para a página apresentada na figura 6.18. Nesse ponto, o operador deve tomar a decisão de aprovar ou rejeitar a requisição. Da mesma forma como ocorre na AR, o operador da AC pode visualizar os detalhes da requisição clicando no ícone

.


Figura 6.17 Lista de requisições aprovadas ou rejeitadas pela AR.

83

Caso opte por rejeitar a requisição de certificado, o operador da AC deve clicar no ícone . Para aprovar a requisição de certificado, o operador da AC deve clicar no ícone

. No caso

Figura 6.18 Lista de requisições pendentes na AC.

da aprovação, o operador será redirecionado para uma página mostrando os detalhes da requisição. Para a emissão do certificado, será necessário escolher o modelo do certificado, inserir a senha do usuário operador e clicar em “Enviar”. O operador de AC pode visualizar as requisições aprovadas ou rejeitadas escolhendo a opção do menu “Requisições de Certificado” > “Gerir”, e depois clicar sobre a aba “Requisições aprovadas ou rejeitadas”. Essa listagem é apresentada na figura 6.19.

Após a emissão do certificado, é necessário que a AR tome conhecimento acerca da emissão do certificado, ou seja, ser informada se a AC rejeitou a requisição do certificado. O operador da AR pode visualizar os certificados emitidos através da opção “Certificados”, do menu. Essa lista é apresentada na figura 6.20. Para fazer o download do certificado, o


operador deve clicar no ícone

84

Figura 6.19 Lista de requisições aprovadas ou rejeitadas pela AC.

.

Revogação de certificados Passos para a revogação:

q

11 O usuário do certificado solicita a revogação do seu certificado para a AR. 11 A AR efetua o pedido de revogação e o encaminha para a AC. 11 A AC recebe o pedido, revoga o certificado, e envia a resposta para a AR. 11 O usuário é avisado de que o seu certificado está revogado. A comunicação pública de que um certificado está revogado é feita através da LCR. Se ocorrer algum problema com um certificado (mau uso, perda da chave privada etc.), este pode ser revogado, tornando-se inválido. A revogação de um certificado no SGCI normalmente ocorre de acordo com os passos a seguir: 11 O usuário pede para a AR revogar o seu certificado; 11 A AR envia uma solicitação de revogação para a AC que emitiu o certificado;


11 A AC recebe o pedido, marca o certificado como revogado e envia a confirmação para a AR; 11 A AR avisa ao usuário que o seu certificado foi revogado. Além disso, a AC pode revogar um certificado a qualquer momento, mesmo sem a solicitação do usuário. Os certificados que são revogados são incluídos em um documento chamado de Lista de Certificados Revogados (LCR), que também é emitido pela AC.


Após o usuário solicitar a revogação do seu certificado, o operador da AR deve ir até a listagem de certificados ativos, apresentada na figura 6.21, através da opção “Certificados” do menu. Para solicitar a revogação do certificado, o operador deve clicar no ícone

da linha do

certificado que deseja solicitar a revogação. Em seguida, será apresentada uma tela com os detalhes do certificado escolhido, onde o operador deverá selecionar o motivo de revogação. Os motivos de revogação são valores fixos, definidos na seção 5.3.1 da RFC5280. Para autorizar a operação, o operador deve inserir sua senha. A requisição de revogação é então encaminhada para a AC. Se o operador da AR desejar visualizar as requisições de revogação que foram enviadas para a AC e ainda estão em análise pela AC, basta que selecione no menu a opção “Requisições de Revogação”. Será exibida uma tela semelhante à da figura 6.22.

Caso as entidades estejam configuradas como offline e em máquinas distintas, será necessário fazer o download da requisição de revogação, clicando no único ícone

da coluna Ações.

Para o operador da AC revogar um certificado, após a AR solicitar a revogação, é necessário que ele entre no sistema e clique na opção do menu “Requisições de Revogação” > “Gerir”. Serão exibidas para o operador as requisições de revogação que estão pendentes na AC,

Figura 6.23 Lista de requisições de revogação pendentes na AC.

ilustrado na figura 6.23. Nessa tela, o operador pode aprovar ou rejeitar a requisição de revogação. Se o usuário aprovar o pedido de revogação, o certificado será marcado como revogado e vai constar na próxima LCR emitida pela AC.


Figura 6.22 Lista de requisições de revogação aprovadas pela AR e em análise pela AC.

85

Lista de Certificados Revogados (LCR) Para configurar um modelo de LCR, o administrador da AC deve entrar no sistema e selecionar a opção do menu “Modelos” > “LCR”. Será apresentada uma tela igual à da figura 6.24. Nela, podemos ver os seguintes campos a serem configurados: 11 Emissão automática: caso a AC necessite emitir LCRs de forma automatizada, esse campo deve ser marcado. A emissão de LCRs em ACs online normalmente é feita de forma automática, enquanto que em ACs offline a emissão é feita manualmente, pelo operador; 11 Validade: período de validade da LCR em dias; 11 Algoritmo de assinatura: o algoritmo de hash que será usado para assinar a LCR. 11 Para autorizar a operação, o administrador deve informar sua senha.

Figura 6.24 Formulário de configuração de um modelo de LCR.

A AC deve emitir LCRs periodicamente e/ou após um certificado ser revogado (de acordo com a DPC da AC). Para emitir uma LCR, o operador da AC deve entrar no sistema, selecionar a opção do menu


“LCR” > “Emitir”, inserir a senha e clicar no botão “Submeter”.

86

Figura 6.25 Download de LCRs.

Para fazer o download das LCRs emitidas pela AC existem duas opções: 11 Download da última LCR: essa opção é útil, pois é comum a AC disponibilizar em um repositório a última LCR emitida, para que softwares e usuários possam verificar se os certificados emitidos pela AC foram revogados ou não; 11 Download de LCRs antigas: nessa opção o operador pode buscar e fazer download de LCRs emitidas em um determinado período de tempo. Essa opção é útil quando se deseja validar uma assinatura realizada no passado.

Cópias de Segurança (backups) Criar backup.

q

11 O backup é uma imagem do estado atual do software. O backup contém: 11 Todas as configurações das ACs e ARs cadastrados no sistema. 11 Certificados e LCRs emitidas. 11 Chaves privadas geradas em software das entidades. O backup é cifrado com uma senha informada durante a geração. Um backup do SGCI contém toda a sua estrutura. Se existirem várias entidades no mesmo sistema, o backup será de todas essas entidades. Se as entidades tiverem as suas chaves privadas criadas em software, o backup conterá essas chaves também. Em resumo, um backup do sistema é como uma “imagem” do sistema. Como os dados do backup são sigilosos, o backup do SGCI é cifrado com uma senha, fornecida no momento da sua geração. Para realizar o backup, basta o usuário criador entrar no sistema e selecionar a opção do menu “Backup” > “Gerar”. Será exibida uma tela igual à mostrada na figura 6.26. O usuário deve fornecer a senha para cifrar o backup e, para confirmar a operação, a sua senha.

Figura 6.26 Gerar Backup.

Para restaurar o backup do SGCI, o usuário criador deve entrar no sistema e selecionar a opção do menu “Backup” > “Restaurar”. Será exibida uma tela igual à mostrada na figura 6.27. Nessa tela, o usuário criador deve selecionar o arquivo de backup, informar a senha para decifrá-lo e, para autorizar a operação, a sua senha.


Após a geração do backup, o usuário deve selecionar onde salvá-lo.

87

Figura 6.27 Restaurar Backup.

Registro de atividades (logs) Exportar:

q

11 De todo o software. 11 De uma entidade específica. Excluir: 11 De todo o software. 11 De uma entidade específica. Como já foi mencionado, o SGCI grava todas as atividades que foram efetuadas. Somente o criador e o administrador podem exportar os logs. A diferença é que, quando exportado pelo criador, eles são de todo o software, enquanto o papel de administrador pode somente exportar os logs da sua entidade. Para exportar os logs, o usuário deve escolher a opção do menu “Logs” > “Exportar”, e depois selecionar o local para salvar o arquivo com os logs. Para excluir os logs, deve-se entrar no sistema como criador ou administrador e clicar na


opção do menu “Logs” > “Excluir”. Depois será necessário preencher um campo com a senha

88

do usuário e clicar em “Enviar” para finalizar a ação. Assim como na exportação, quando o administrador de uma entidade deleta os logs, apenas os logs da sua entidade são deletados.

7 objetivos

Gerenciando o ciclo de vida de chaves criptográficas Conhecer o Módulo de Segurança Criptográfico ASI-HSM; Aprender sobre as características físicas e lógicas do ASI-HSM e a arquitetura interna e externa do ASI-HSM; Conhecer os perfis de usuários do ASI-HSM; Entender como funciona a instalação, inicialização e manuseio do ASI-HSM.

conceitos

O que é um HSM? Para que serve um HSM? Características gerais (hardware e software); Normas de certificação.

O que é um HSM? Significado:

q

11 Hardware Security Module. Sinônimo:

“Conjunto hardware/software voltado à proteção e gerência do ciclo de vida de chaves criptográficas.” O nome HSM vem do inglês Hardware Security Module – ou Módulo de Segurança Criptográfico. A solução abrange, no mínimo, um conjunto composto por hardware (o módulo em si) e software (para sua gerência e configuração). A principal finalidade do HSM é a proteção e gerência do ciclo de vida de chaves criptográficas, contando para isso com a implementação de inúmeros algoritmos criptográficos, bem como de proteções físicas contra violação e acesso indevido ao material protegido.

Figura 7.1 ASI-HSM AHX2 (hardware).

Capítulo 7 - Gerenciando o ciclo de vida de chaves criptográficas

11 MSC: Módulo de Segurança Criptográfico.

89

A figura 7.1 ilustra a parte externa de um HSM. No caso, a versão AHX2 do ASI-HSM, produzido pela RNP, LabSEC e Kryptus como parte da iniciativa ICPEDU II.

A figura 7.2 mostra o software de gerência de um HSM. O software em questão gerencia

Figura 7.2 Cliente Java (software).

remotamente o ASI-HSM.

Para que serve? 11 Proteger e gerenciar o ciclo de vida de chaves criptográficas.

q


11 Por que proteger essas chaves?

90

22 Algoritmos públicos. 22 Segurança está na chave. 22 Base para garantir: 33 Autenticidade. 33 Integridade. 33 Sigilo. 33 Autoria. 22 Precisam ser rigidamente controladas. Com a crescente utilização do meio digital para o armazenamento e trânsito de informações, a necessidade de proteção de dados e transações têm se tornado uma preocupação constante. Já com a adoção de algoritmos públicos, padronizados e de eficácia comprovada para a criptografia de dados, as chaves criptográficas são a principal preocupação e devem ser mantidas sob rígido controle. Surgiu daí a necessidade de um dispositivo dedicado à proteção e gerência de tais artefatos.

Atualizado:13/03/2007

AC CEF

AC CERTISIGN

AC CAIXA PF

AC CERTISIGN MÚLTIPLA

AC CAIXA PJ

AC IMESP

AC JUS

AC PR

SERASA ACP

AC SERPRO

AC SRF

AC CAIXA JUS

SERASA AC

AC SERPRO AOP

AC CERTISIGN SRF

AC CERTISIGN SPS

AC CERTISIGN JUS

SERASA OD

AC IMESP SRF

AC CERTISIGN SPS

AC SERASA SPS

AC FENACOR

AC PRODEMGE SRF

AC CERTISIGN IMESP

AC SERPRO JUS

AC SERASA SRF

AC CERTISIGN SENCOR

AC SINCOR JUS

AC SERPRO SRF

AC CERTISIGN PRODEMGE

AC SINCOR SRF

AC CERTISIGN PETROBRAS

AC FENACOM SRF

Em infraestruturas de chaves públicas, as chaves privadas são de vital importância. O custo de perda, roubo ou indisponibilidade de uma chave privada para uma autoridade certificadora cresce de maneira inversamente proporcional ao nível da AC em questão, ou seja, em ACs de último nível, a implicação seria a revogação de todos os certificados emitidos aos usuários finais.

Já em uma AC de nível 0 (Raiz), as consequências seriam catastróficas, visto que toda a infraestrutura estaria comprometida.

Ciclo de vida de chaves criptográficas Geração: 11 Evitar chaves previsíveis. Armazenamento: 11 Impedir divulgação e acesso não autorizado. Controle sobre uso: 11 Não permitir que a chave seja usada sem a devida permissão.

q


Figura 7.3 Segurança da ICP baseia-se na segurança de suas chaves privadas.

Estrutura

11 Manter registro de utilizações. 91

Para minimizar os riscos anteriormente citados para as chaves criptográficas, o HSM deve gerenciar uma série de aspectos relacionados ao ciclo de vida de chaves criptográficas. São eles: 11 Geração: HSM deve garantir uma geração confiável, baseada em valores aleatórios (o máximo possível), visando a total imprevisibilidade de suas chaves; 11 Armazenamento: é papel do HSM controlar o armazenamento e o acesso aos parâmetros críticos de segurança e chaves criptográficas contidas em seu interior. Para tanto, deve impossibilitar o vazamento de tais informações para o exterior do perímetro criptográfico, além de implementar um controle de acesso forte, garantindo disponibilidade para papéis autorizados; 11 Controle sobre o uso da chave: além de restringir o uso de suas chaves criptográficas a pessoal autorizado, o HSM deve ainda manter um registro seguro das operações por ele executadas. Dessa maneira é possível, em caso de mal uso, a recuperação dos registros e avaliação dos prejuízos trazidos por ele; 11 Backup/recuperação: um HSM deve permitir procedimento de backup de seu material sensível para que, em caso de falha, o ambiente possa ser restaurado sem maiores contratempos. O ASI-HSM trabalha com backups direcionados, ou seja, antes de ser gerada uma imagem de backup, já se sabe o destino do arquivo. Essa premissa é garantida através de criptografia simétrica e assimétrica sobre o conteúdo do backup. Com esse direcionamento é também possível traçar um rastro para as N cópias de uma chave privada gerenciada; 11 Destruição de chaves gerenciadas: quando uma chave criptográfica atinge seu objetivo, ela deve ser destruída, ou seja, apagada da memória interna do HSM. Apesar de ser uma tarefa aparentemente trivial, esse ainda é um problema em aberto no que diz respeito à gerência de chaves. Isso porque não é fácil garantir a destruição de todas as cópias e arquivos de backup que contêm determinada chave, podendo levar a uma falsa sensação de segurança por parte do usuário.

Características de um HSM ICPEdu Introdução a Infraestrutura de Chaves Públicas e Aplicações

Hardware:

92

q

11 Sensores (fronteira criptográfica)‫‏‬. 11 Proteção física (lacre)‫‏‬. 11 Mitigação de ataques. 11 Registro completo de atividades. 11 Tokens para autenticação. Software: 11 Sistema Operacional. 11 Provedor de serviços criptográficos. 11 Interface de administração remota.

Hardware Com respeito ao hardware, o HSM é um sistema desenvolvido para inibir todo e qualquer acesso indevido ao material sigiloso contido em seu interior. Tal material é composto geralmente por chaves criptográficas simétricas, assimétricas, configurações internas, chaves secretas internas ao módulo etc.

Para proteger tais componentes, chamados frequentemente de “Parâmetros Críticos de Segurança”, ou PCS, o HSM conta com um perímetro criptográfico, uma área protegida por sensores que monitoram a fronteira, reagindo aos possíveis ataques, bem como registrando toda e qualquer tentativa de violação. Um HSM ainda deve contar com um dispositivo avançado de controle de acesso, como tokens USB, Smart Cards, leitores biométricos, scanner de íris etc.

Software Quanto ao software, o HSM possui um sistema de gerência interno ao módulo, com a função de monitorar a utilização das chaves gerenciadas, bem como qualquer outro serviço presente. Conectado a esse provedor de serviços, deve haver ainda um cliente remoto, para acesso externo às funcionalidades do módulo. Através de tal interface, é possível efetuar os serviços criptográficos disponíveis, bem como monitorar a configuração do HSM e extrair seus registros de utilização.

Normas e Certificações FIPS 140:

q

11 Norma norte-americana (NIST). 11 Define 4 níveis de segurança incrementais. ICP-Brasil: 11 Norma do governo brasileiro (ITI). 11 Voltado para ICP. 11 Define três níveis de segurança incrementais. 11 Define dois níveis de segurança física incrementais. ISO Common Criteria: 11 Há três normas bastante conhecidas e aceitas que avaliam, regulamentam e homologam hardwares criptográficos. A primeira e mais conhecida é a FIPS 140, norma norte-americana mantida por um órgão do governo americano, o National Institute of Standards and Technology (NIST). A segunda utilizadas no âmbito da ICP-Brasil. A terceira é a Common Criteria, norma responsável pela homologação de soluções em geral, como Sistemas Operacionais e dispositivos, como HSMs.

Conhecendo e Inicializando o ASI-HSM 11 Por que mais um HSM? 11 ASI-HSM. 22 Diferenciais. 22 Componentes. 22 Características. 22 Arquitetura. 33 Interna. 33 Externa. 22 Perfis de Usuário.

q


é uma norma criada pelo governo brasileiro para homologação de soluções aptas a serem

93

11 Instalação.

q

11 Inicialização. 22 Conexão. 22 Definição de linguagem padrão. A partir de agora iniciaremos nossos estudos sobre o ASI-HSM. Aqui serão tratados desde os motivos que levaram à criação de um HSM briasileiro, suas características e diferenciais, até sua arquitetura, instalação e inicialização.

Por que mais um HSM? Problemas das soluções atuais:

q

11 HSMs são caixas-pretas. 11 Difícil instalação e manuseio. 11 Sequestro de chaves. 22 Reserva de mercado? 11 Soluções importadas: 22 Alto custo. 22 Dificuldade de importação. 22 Criptografia forte? 11 Como confiar no que não se conhece? Os diversos HSMs atualmente no mercado, apesar de possuírem características bastante específicas, apresentam características comuns, sendo algumas delas indesejáveis no tocante à gerência de chaves criptográficas. Entre tais características, podemos citar: 11 HSMs são caixas-pretas: os fabricantes mantêm em sigilo a implementação e os protocolos que regem as funcionalidades de seus HSMs, como forma de proteger seu produto dos concorrentes;


11 Em geral, HSMs envolvem uma série de procedimentos que dificultam demasiadamente sua operação. Muitas vezes ainda sua operação é mal documentada, deixando os usuários à mercê dos fabricantes; 11 Em muitos dos HSMs de mercado, a opção de exportação de chaves em formato padrão não está disponível, havendo somente um método proprietário, que permite a exportação apenas para outros dispositivos do mesmo fabricante. Essa reserva de mercado faz com que as chaves estejam, de certa forma, sob a custódia de um fabricante. Dessa maneira, se o produto for descontinuado ou se a empresa deixar de existir, os usuários do HSM precisariam gerar um novo par de chaves, procedimento de alto custo para uma ICP, no caso de uma AC-Raiz; 11 Como as soluções existentes são importadas, possuem um valor atrelado à variação cambial, taxas de importação, o que acaba por onerar o valor final do produto.

ASI-HSM – Diferenciais Tecnologia 100% nacional. 11 Parceria RNP + Kryptus + LabSEC. Software livre. 11 Baixo custo.

94

q

Protocolo aberto:

q

11 Auditável. 11 Amplamente documentado. 22 Artigo EuroPKI. 22 Artigo ID Trust (...). Voltado para ICP (auditoria). O ASI-HSM foi projetado como uma alternativa de baixo custo, de forma que pudesse ser adquirido por instituições de ensino. O módulo é totalmente baseado em software livre, desenvolvido com tecnologia nacional e voltado para ICPs, por possuir registro de logs interno, possibilitando auditoria precisa. Ainda como principal diferencial do ASI-HSM pode-se citar o fato de seu protocolo ser totalmente aberto, documentado e publicado nos mais relevantes eventos na área de ICP.

ASI-HSM – Componentes 11 Módulo Criptográfico.

q

11 Interface de Gestão Remota. 22 Cliente gráfico em Java. 22 Cliente texto em C. 11 Token para autenticação: 22 Leitora de smart cards. 22 Conjunto de smart cards. 11 Engine OpenSSL: 22 Acesso aos serviços criptográficos. O ASI-HSM conta com os seguintes componentes: 11 Módulo criptográfico: hardware dedicado a gerência de chaves; 11 Clientes de Administração Remota: estando disponíveis em duas versões, uma gráfica Ambos permitem a configuração e manutenção do módulo, através de uma conexão SSL entre HSM e máquina host; 11 Token para autenticação: o ASI-HSM restringe o acesso a suas funções através de compartilhamento de segredo entre os membros de cada um de seus perfis. Esse segredo é protegido por smart cards, possuindo assim duplo fator de autenticação: posse do cartão e conhecimento de um PIN, para seu desbloqueio; 11 Engine OpenSSL: através da engine OpenSSL, é possível o uso das chaves gerenciadas pelo HSM. Por se tratar de uma engine padrão, qualquer aplicação compatível com OpenSSL pode fazer uso das funcionalidades do módulo, permitindo assim a fácil integração com softwares de terceiros.

ASI-HSM – Características Hardware. 11 Sensores: 22 Luminosidade.

q


e outra em modo texto, que devem ser instaladas em uma máquina conectada ao HSM.

22 Variação de tensão. 95

22 Perfuração.

q

22 Violação (lacre). 22 Temperatura. 11 Interferência eletromagnética: 22 Gaiola de Faraday. 11 TRNG. 11 RTC. Hardware: com relação ao sensores, o ASI-HSM possui seu perímetro criptográfico totalmente isolado do meio externo, por uma caixa opaca e totalmente selada. Caso haja variação de luminosidade, evidenciando uma tentativa de abertura da caixa, os sensores de luminosidade dispararão um alerta de intrusão, destruindo as chaves presentes no módulo. Ainda no caso de abertura ou perfuração, uma malha interna acusará uma variação de sua resistividade, maior do que a tolerada. O HSM conta ainda com: 11 Revestimento de seu perímetro, que evidencia qualquer tentativa de violação, tornando difícil recompor seu perímetro; 11 Um sensor de temperatura, impedindo que o módulo possa ser submetido a temperaturas que provoquem seu mau funcionamento; 11 Sensor de variação de tensão, que evita também que o HSM seja submetido a condições indevidas. Com relação às funcionalidades do módulo, este possui um gerador de números aleatórios de efeito quântico, garantindo a qualidade das sementes usadas no algoritmo de geração de chaves, o que significa chaves imprevisíveis, além de um relógio de tempo real, que é a fonte


de tempo interna do HSM, possibilitando uma sincronização precisa.

96

Engine OpenHSM

Cliente Java

Cliente Texto

HSM

Leitora de Smartcard

Interface de Rede

USB

Perímetro criptografado Unidade Gestora Memória flash OpenHSMd

Ba nco de dados

PCSCd/OpenSC

OpenSSL

Imagem do Sistema

Unidade de segurança Gerador de números aleatórios Relógio

Registro de sensores

Sensores

A figura 7.4 mostra a arquitetura interna de um HSM. Apesar de tratar-se da arquitetura específica do ASI-HSM, há muitas características encontradas na grande maioria dos HSMs de mercado. Envolvendo todos os dados e aplicações contidas no módulo, encontra-se o perímetro criptográfico. Os únicos caminhos de entrada e saída de dados e controle possíveis são as interfaces confiáveis, no caso, interface de rede (via conexão SSL) e interface USB. No interior do perímetro, pode-se ainda observar duas unidades principais. Uma delas (Unidade Gestora – UG) é responsável por abarcar o provedor de serviços criptográficos, sendo assim diretamente envolvida na gerência do ciclo de vida de chaves criptográficas. A segunda (Unidade de Segurança – US) é responsável por monitorar e proteger a primeira. Na US é que estão presentes os sensores que protegem a fronteira criptográfica. Entre as duas unidades, há uma conexão que permite à US informar qualquer tentativa de intrusão ou mau funcionamento do módulo, possibilitando assim que um procedimento de mitigação ao possível ataque seja disparado.


Figura 7.4 Arquitetura interna do ASI-HSM.

97

Interface de Sistema Gerenciador OpenSSL Engine

Engine

Gerência de Chaves

Host

Figura 7.5 Arquitetura externa.

ASI-HSM

A arquitetura externa ou ambiente operacional de um HSM geralmente consiste em uma máquina host (para HSMs off-line) ou um conjunto de máquinas (HSMs on-line), conectados ao módulo por uma interface confiável. No caso do ASI-HSM, essa conexão é realizada via interface de rede (Ethernet). Na máquina host, encontram-se instaladas as aplicações cliente que vão interagir com o módulo. No ASI-HSM, tais interfaces são o Cliente de Gestão Remota, para administração do módulo, e a Engine OpenSSL, para uso de chaves gerenciadas.

ASI-HSM – Boas práticas de uso Manusear com cuidado.

q

11 Sensores sensíveis a choques mecânicos. Desligar somente pelo cliente de gestão remota. 11 Não desplugar abruptamente da fonte de energia. Bateria interna substituível não-recarregável. 11 Duração de até 12 meses sem alimentação. 11 Manter conectado a uma fonte de energia. Temperatura para armazenagem (desligado).


11 Entre 0 e 45 graus celsius. Temperatura de funcionamento (ligado). 11 De 5 a 35 graus celsius. Fonte bivolt automática (110V/220V). 11 Manter sob tensão estável. Para o bom funcionamento do módulo de segurança criptográfico, algumas práticas são recomendadas. Os pontos ressaltados mostram os cuidados a serem tomados para evitar que o HSM acuse invasão. É necessário sempre manter em mente que o HSM possui diversos sensores mecânicos responsáveis por detectar possíveis ataques. Dessa forma, é altamente aconselhável manuseá-lo com cuidado, evitando choques. Também é preciso lembrar-se sempre de usar um dos clientes de gestão remota para realizar o desligamento do HSM com segurança. O HSM utiliza baterias internas não recarregáveis para manter a unidade de segurança ativa mesmo quando não há energia. Dessa forma, é necessário lembrar de trocá-las frequentemente, assim não se corre o risco de o HSM se desligar indevidamente. Mesmo com as baterias internas, é muito importante mantê-lo sempre conectado a uma fonte de energia. As baterias devem ser utilizadas para suprir a falta de energia elétrica, e não o contrário. 98

l

Saiba mais Embora todos sejam tratados aqui, é recomendado consultar o manual do usuário para mais detalhes.

Ainda sobre a energia, o HSM possui uma fonte de voltagem dupla (110V/220V), porém é recomendado que ele seja mantido sob tensão estável. Finalmente, é necessário observar também a temperatura do ambiente em que o HSM é mantido. Desligado, ele tolera temperaturas entre 0 e 45 graus celsius. Já ligado, a temperatura tolerada muda para algo entre 5 e 35 graus celsius.

ASI-HSM – Perfis de usuário 11 Perfil de Administração.

q

11 Perfil de Auditoria. 11 Perfil de Operação. 11 Operações comuns. Existem três perfis responsáveis pela manutenção e funcionamento de um ASI-HSM. São eles: administradores, auditores e operadores. De uma forma geral, os administradores cuidam das configurações do HSM, os auditores garantem que o HSM está sendo utilizado de maneira correta e os operadores são os responsáveis técnicos pelas chaves. Apesar de terem papéis bem específicos e definidos, existem determinadas operações que são comuns a mais de um perfil. As funções específicas de cada perfil serão explicadas em mais detalhes a seguir.

Perfil de Administração 11 Criar grupo de administração.

q

11 Criar grupos de auditores. 11 Criar grupos de operadores. 11 Apagar HSM. 11 Atualizar software do HSM. 11 Colocar o HSM em modo operacional. 11 Desligar HSM. 11 Alterar data ou hora do HSM.

11 Alterar grupo de administradores. 11 Importar chave pública de backup. 11 Gerar ou recuperar backup. 11 Gerar par de chaves assimétricas. 11 Importar par de chaves assimétricas. 11 Delegar custódia de chave a um grupo de operação. 11 Alterar grupo de custodiantes de chave. 11 Ativar grupos de operadores após backup. É o perfil responsável pelas atividades que afetam o módulo como um todo, como criação e alteração dos outros perfis, alteração de data e hora, atualização de firmware etc. O perfil de administração é responsável ainda pela geração de chaves RSA e atribuição de custódia dessas chaves a perfis de operação, que a partir daí controlarão seu uso.


11 Apagar logs (compartilhada por auditores).

99

Perfil de auditoria 11 Exportar logs da unidade de gerência.

q

22 Log gerencial (atividades). 11 Exportar logs da unidade de segurança. 22 Log técnico (sensores). 11 Bloquear HSM. 11 Recuperar backup (com administradores). 11 Apagar logs (com administradores). Ao perfil de auditoria, cabe a monitoração da utilização do módulo, sendo este responsável pela extração e análise dos logs gerenciais e técnicos, contendo, respectivamente, registro de operações efetuadas pelo módulo e logs dos sensores, no caso de alguma invasão ter sido detectada. O perfil de auditoria é responsável ainda por restaurar cópias de segurança, bloquear HSM e remover logs antigos, tarefas que compartilha com o perfil de administração.

Perfil de Operação Liberar chave para uso.

q

11 Definir políticas de utilização: 22 Tempo de uso. 22 Número de usos. Efetuar autoativação após restauração de backup (com administradores). O perfil de operação é responsável por atividades relacionadas a uma ou mais chaves gerenciadas pelo módulo. O perfil possui autonomia apenas sobre chaves cuja custódia lhe foi atribuída. Ao carregar uma chave, o perfil deve se autenticar e pode ainda definir uma política de utilização da chave, através de número de utilizações e/ou tempo de uso.


Operações comuns

100

11 Obter versão do software do HSM. 11 Obter data e hora do HSM. 11 Listar grupos de auditores. 11 Listar grupos de operadores. 11 Listar membros de grupos de auditores. 11 Listar membros de grupos de operadores. 11 Descarregar chave da memória. 11 Listar chaves. 11 Listar chaves carregadas. 11 Listar conteúdo de smart card. 11 Inicializar smart card. 11 Configurar HSM. 11 Alterar PIN de smart card.

q

O HSM possui ainda algumas operações comuns a todos os perfis, que não exigem identificação. Essas operações são somente de leitura, visando a obtenção de informações não sigilosas do módulo, geralmente atreladas à sua operação.

Preparando a instalação Material:

q

11 Módulo criptográfico (ASI-HSM). 22 Fonte de alimentação. 11 Máquina Host. 22 Interface de Gestão Remota. 22 Engine OpenSSL. 11 Cabo de rede crossover. 11 Leitora de smart cards (apenas AHX1). 11 Smart cards. Antes de inicializar o módulo criptográfico, os clientes de gestão remota devem ser instalados na máquina hospedeira a que estará conectado o HSM. Para o cliente gráfico, basta instalar uma máquina virtual Java, versão 1.5 ou posterior. No caso da ferramenta em linha de comando, é necessária uma versão específica para o Sistema Operacional da máquina. A engine OpenSSL deverá também ser instalada e configurada na aplicação a que o HSM será integrado.

Instalação 11 Colocar cartão na leitora.

q

11 Conectar HSM à máquina host via cabo ethernet. 22 Configurar IP da máquina host. 33 192.168.1.5 11 Conectar fonte de alimentação ao HSM.

22 Observar estado da leitora. 11 Objetivo: 22 Configurar idioma e conectar ao HSM. 11 Passos: 22 Executar interface de gestão remota. 33 ASI-HSM-Client.jar 22 Definir linguagem: 33 Arquivo > Preferências. 22 Conectar ao HSM. 33 IP: 192.168.1.1 33 Porta: 5000 22 Verificar validade do Certificado SSL. O HSM vem pré-configurado com o endereço de rede 192.168.1.1; sendo assim, é necessário configurar a interface de rede da máquina host com o IP 192.168.1.5. Com a instalação finali-


11 Ligar HSM.

zada, o HSM pode então ser ligado. 101

Com o HSM ligado e pronto para receber conexões, o cliente de gestão remota deve ser executado. As configurações padrão devem ser mantidas para o estabelecimento da conexão.

Definição da linguagem O HSM possui internacionalização em português e inglês. Essa opção pode ser selecionada

Figura 7.6 Menu de preferências.


no menu “Arquivo” > “Preferências”.

102

Figura 7.7 Definição de linguagem.

Na janela de seleção, pode-se escolher entre as opções de internacionalização.

Figura 7.8 Conexão: parâmetros.

Estabelecimento de conexão Inicialmente, pressiona-se o botão Conectar ao HSM. Ao clicarmos, nos será solicitado informar o endereço IP e a porta para conexão ao ASI-HSM. Os parâmetros de conexão vêm pré-configurados de acordo com a configuração padrão do HSM. Sendo assim, se a instalação do ambiente operacional foi efetuada com sucesso, basta clicar em OK para estabelecer a conexão.


Figura 7.9 Conexão: SSL.

103

Certificado SSL A conexão entre HSM e a máquina Host é feita através de um túnel SSL. Logo, no início da conexão é solicitado ao usuário que confira e aceite o certificado SSL utilizado para estabelecer o caminho seguro. Inicialmente, é exibido apenas o campo Common Name do certificado que o ASI-HSM apresenta na conexão. A partir dessa janela pode-se confirmar a conexão ou pode-se


visualizar de forma completa o certificado usado pelo ASI- HSM para a referida conexão.

104

Após a confirmação do uso do certificado SSL, a conexão com o HSM é finalmente estabelecida.

Preparação do HSM Duas possibilidades: 11 Preparação para uso. 22 HSM será uma unidade operacional. 11 Preparação como cópia de segurança. 22 HSM servirá como unidade de backup. Estados do HSM: 11 Não configurado. 11 Preparado para Backup. 11 Modo Operacional. 11 Modo de Segurança.

q

Figura 7.10 Conexão estabelecida.

HSM não configurado

Preparação para Backup

Preparação para uso Modo de segurança

ção

ura

ta Res

Modo operacional

Modo de Segurança: ao identificar alguma situação incomum, o HSM entra em modo de segurança e nenhuma operação pode ser feita. Exceto retornar ao modo operacional (com autenticação dos administradores).

O ASI-HSM pode ser preparado de duas maneiras: 11 Primeira: preparação como unidade operacional, que gerenciará o ciclo de vida de uma ou mais chaves criptográficas; 11 Segunda: preparação como unidade de backup. Nesse caso, o HSM será usado unicamente para receber cópias de segurança geradas por unidades operacionais. Uma vez inicializado para backup, o HSM só se tornará uma unidade operacional quando um backup for restaurado. O esquema de backup é detalhado adiante.

Preparação para uso Objetivo:

q

11 Preparar HSM para gerenciar chaves criptográficas. Passos: 11 Configurar data e hora. 11 Configurar parâmetros internos. 22 Dados certificados internos. 22 Algoritmo padrão. 22 Tamanhos das chaves. 22 Proteção de chaves por senha. 22 Endereço IP e porta de serviço. 22 Firewall. Os passos a seguir detalharão o processo comum de preparação do HSM para a gerência de chaves criptográficas. A ordem de cada etapa é fundamental para que o objetivo seja alcançado.


Figura 7.11 Diagrama de estados do ASI-HSM.

Preparado para Backup

105

Configuração

O primeiro passo para a correta configuração do HSM é a configuração da data e hora internas do HSM. Como o HSM ainda não possui perfil de administração, tal configuração é realizada sem a necessidade de autenticação. Após a criação do perfil, tal atividade passa a


ser administrativa, exigindo a autenticação do respectivo perfil.

106

Figura 7.12 Configuração de data e hora.

Configuração dos parâmetros internos do HSM Nessa etapa da configuração, é definida uma série de parâmetros necessários ao funcionamento do módulo, como tamanho de chaves, algoritmo criptográfico utilizado internamente, IP e porta em que o HSM atenderá a requisições, bem como máscara de rede, além de uma série de configurações que constarão nos certificados internos do HSM, como, por exemplo, no certificado SSL. O HSM será reiniciado para que as novas configurações de rede sejam aplicadas. O procedimento de reinicialização pode levar até 2 minutos para ser concluído, em virtude dos autotestes realizados.


Figura 7.13 Configuração do ASI-HSM.

107

108


8 Aprender sobre a criação de usuários no ASI-HSM; Entender a geração e uso de chaves criptográficas; Conhecer o processo de backup do ASI-HSM.

Esquema de backup (preparação, importação de chave de backup, geração de cópia do ambiente operacional e restauração de backup); Ativação do(s) Perfil(is) de Operação.

Criação dos perfis de usuário Objetivo:

conceitos

Criação dos perfis de usuário; Geração e uso de chaves; Exportação de logs gerenciais;

q

11 Criar grupos de usuários para cada um dos três papéis responsáveis pelo uso do HSM. Passos: 11 Criar perfil de Administração. 11 Criar perfil de Auditoria. 11 Criar perfil de Operação.

Capítulo 8 - Usando o ASI-HSM

objetivos

Usando o ASI-HSM

109

Criação de administradores

Figura 8.1 Criação de administradores.

Inicialmente deve-se acessar o item “Chaves e Contas de Usuário” e, em seguida, “Administradores”, ambos localizados no canto superior esquerdo da tela principal. Deve-se então acessar a aba “Criar Administradores”. Em seguida, entrar com os valores de “n” (quantidade mínima de membros para recompor o segredo do perfil) e “m” (tamanho do perfil) nos


campos apropriados, e finalmente pressionar o botão Criar Grupo de Administradores.

110

Figura 8.2 Inserindo smartcards dos administradores.

É exibida uma caixa de diálogo, solicitando que o usuário insira o primeiro dos “m” smart cards no leitor. Após a inserção, deve-se pressionar o botão “Ok”.

Figura 8.3 Geração de PIN para cada smartcard.

Nos passos seguintes, deve-se inserir o PIN para proteger o uso do smart card do membro.

Figura 8.4 Inserindo um nome comum para cada usuário.

Em seguida, é solicitada a entrada de um Nome Comum (Common Name), que identificará o membro do perfil. Esse campo deverá conter apenas caracteres ASCII, sendo proibidos


Esse valor deve ser numérico e estar entre a faixa 100000 e 99999999.

caracteres especiais. 111

Após efetuar-se tal processo para cada um dos “m” smart cards, um diálogo é exibido,

Figura 8.5 Tela de sucesso.

informando o sucesso na criação do grupo de administradores.

Demais perfis (Audit e Oper) Processo análogo

q


11 Diferença:

112

22 Autenticação dos administradores. 11 Sequência obrigatória: 22 Auditores. 22 Operadores. Cardinalidade de perfis ativos no HSM: 11 Administradores: 1 11 Operadores: N 11 Auditores: N Para a criação dos outros perfis que atuam sobre o módulo, o processo é análogo, com a única diferença de que o perfil de administração deve se autenticar (apresentando smart cards e informando o PIN dos “n” membros que representarão o perfil), antes do início do processo. Uma ordem deve obrigatoriamente ser seguida. Primeiramente, deve-se criar o perfil de Auditoria, através do menu “Chaves e Contas de Usuário”, “Auditores” e “Criar Auditores”. Em seguida, deve-se criar o perfil de Operação, disponível no menu “Chaves e Contas de Usuário”, “Operadores” e “Criar Operadores”.

Geração e liberação de chave para uso Objetivo:

q

11 Gerar chave criptográfica e liberá-la para uso. Passos: 11 Gerar par de chaves RSA. 11 Carregar chave, disponibilizando-a para acesso via engine OpenSSL. 11 Listar chave carregada para garantir que tudo correu conforme o esperado.

Geração de chaves

O processo de criação de chaves através da interface gráfica se inicia acessando o item “Chaves e Contas de Usuário” e, em seguida, “Chaves”, ambos localizados no canto superior esquerdo da tela principal. Em seguida, definem-se os parâmetros da chave. Então, pressiona-se o botão Gerar Chave. Parâmetros da chave: 1 Nome da chave; 1 Grupo de operadores; 1 Tipo de Algoritmo; 1 Tamanho da chave; 1 Chave exportável.


Figura 8.6 Gerando uma chave.

113

Chave Exportável: esse parâmetro denota de uma chave será ou não incluída nos backups onde foi gerada, nem mesmo por meio de um backup para outro HSM.

Figura 8.7 Autenticação de administradores.

No passo seguinte, é necessário autenticar o mínimo “n” dos administradores.

Figura 8.8 Geração da chave.


gerados pelo HSM em questão. Uma chave que não seja exportável nunca sairá do HSM

114

Após a autenticação, o HSM exibirá uma barra de progresso indicando a geração da chave. O tempo de geração varia com o tamanho da chave e é um processo não determinístico. Para uma chave RSA de 2048 bits, o HSM pode levar cerca de 1 minuto para concluir a geração.

Por fim, é exibido um diálogo informando o sucesso da operação.



115

Importação de chaves

O processo para importação de chaves é feito acessando o item “Chaves e Contas de Usuário” e, em seguida, “Chaves”. A chave a ser importada deve estar nos formatos PKCS#1 (para chaves RSA), X9.62 (para chaves ECDSA) ou PKCS#8, codificadas em arquivos no formato DER ou PEM. É necessário também que a chave esteja cifrada por senha.


Parâmetros da chave importada:

116

11 Nome da chave; 11 Grupo de operadores; 11 Formato; 11 Senha; 11 Chave exportável.

Figura 8.10 Importando uma chave.


No passo seguinte, é aberta uma janela para selecionar o arquivo da chave a ser importada.


Figura 8.11 Seleção do arquivo da chave.

117

É necessário que o grupo de administradores se autentique para fazer a importação, assim como é feito na geração de uma chave.


Por fim, é exibido uma caixa de diálogo informando o sucesso da operação.


Liberação (carga) de chaves para uso

118

Figura 8.14 Liberando uma chave para uso.

Para que uma chave possa ser utilizada via Engine OpenSSL para assinaturas digitais, ela deve ser carregada em memória. Para liberar o uso de uma chave gerenciada, é necessário que o perfil de operação responsável por sua custódia se autentique. Para isso, é preciso acessar os itens “Chaves e Contas de Usuário” e “Chaves”. Em seguida, a aba “Carregar Chave”. No primeiro campo de texto, entramos com o nome da chave assimétrica. No campo abaixo, informa-se o período de tempo em que a chave permanecerá aberta. No campo ao lado está a unidade de tempo desejada. No último campo define-se um número limite de usos antes que a chave seja descarregada. Mais abaixo há opções de se tornarem os limites de uso e de tempo indefinidos. Em seguida, pressiona-se o botão Carregar Chave.

É então solicitada a autenticação de “n” dos “m” operadores. Deve-se inserir o smart card e o PIN de cada um dos “n” operadores.



119


Após a carga, é exibida uma caixa de diálogo contendo uma mensagem de sucesso.

120


Figura 8.17 Listagem de chaves carregadas.

Para listar chaves liberadas para uso, inicialmente é preciso acessar os itens “Chaves e Contas de Usuário” e “Chaves” e, em seguida, a aba “Listar Chaves Carregadas”. Por último, pressiona-se o botão “Listar Chaves Carregadas” e uma caixa de diálogo contendo informações a respeito da chave é exibido.

Entre as informações, a hora em que a chave foi aberta, quando ela será fechada (caso tenha sido definido um limite de tempo), bem como o número de usos que ainda podem ser feitos desta, caso tenha sido definido o limite de usos.

Exportação de logs gerenciais Objetivo:

q

11 Extrair logs internos do HSM para posterior análise por parte dos auditores. Passos: 11 Exportar registros de logs para máquina hospedeira.


Figura 8.18 Informações sobre as chaves carregadas.

121

Inicialmente, acessamos o menu “Chaves e Contas de Usuário” e, em seguida, o item “Auditores”, na aba “Exportar Logs da UG”. Em seguida, entramod com o período (data de

Figura 8.19 Exportando logs.

início e fim no formato MM/DD/AAAA) desejado, como forma de filtrar os logs a serem exportados. Caso esses campos não sejam preenchidos, todos os registros serão exportados. Logo, na caixa de seleção abaixo dos campos de data, escolhemos um dos grupos de


auditores disponíveis e pressionamos o botão Exportar os Logs da UG.

122

Figura 8.20 Escolha do destino dos logs.

Uma janela será aberta para possibilitar a escolha do arquivo de destino contendo os registros de logs exportados. Esse arquivo será exportado no formato PKCS#7, assinado pelo certificado interno do perfil de auditoria, sendo necessária uma ferramenta externa para sua extração e visualização. Indicamos a ferramenta “Cryptonit” para tal fim.

Após a confirmação do destino do log, autenticamos “n” dos “m” componentes do grupo selecionado de auditores.


Figura 8.21 Autenticação de auditores.

123


Por fim, uma mensagem de sucesso é exibida na tela.

Procedimento de backup Objetivo:

q

11 Replicar o ambiente operacional de um HSM em um novo HSM, permitindo a continui-


dade do ciclo de vida de chaves, em caso de indisponibilidade do primeiro.

124

Passos: 11 Preparar HSM para backup. 11 Importar chave de backup em HSM operacional. 11 Exportar imagem de backup. 11 Restaurar backup em HSM preparado. 11 Ativar perfis de operação. Como exposto anteriormente, o esquema de backup do ASI-HSM é direcionado, ou seja, antes de gerar uma imagem do ambiente operacional, o HSM já tem conhecimento do destino da cópia, permitindo assim um rastreamento das cópias da chave privada. Quando um HSM é preparado para backup (passo 1), é gerado em seu interior um par de chaves de backup, cuja chave pública deve ser exportada para uma máquina hospedeira e posteriormente importada em um HSM Operacional (passos 2 e 3). A partir daí, todo o backup gerado pelo HSM Operacional (passo 4) será cifrado com a chave pública de backup do HSM preparado, e pode ser restaurado no HSM de backup (passo 5).

HSM de Backup

1

Máquina hospedeira

2 5 4 3

Figura 8.24 Preparando HSM para backup.

HSM Operacional

Para preparar o ASI-HSM para backup, este não poderá estar configurado para uso. Uma vez não inicializado, devemos acessar o menu “Sistema” e “Preparar para Backup”. Em seguida, deve-se clicar no botão Preparar para Backup.


Figura 8.23 Backup direcionado.

1. Preparar para Backup 2. Extrair chave pública de Backup 3. Importar chave de Backup 4. Extrair Backup 5. Restaurar Backup

125

O primeiro passo do processo é a escolha do destino da chave pública a ser exportada, em


formato PEM, na máquina hospedeira.

Após a exportação da chave pública, uma mensagem de sucesso é exibida. A partir desse ponto, o HSM de backup aguardará a importação de uma imagem de um HSM em operação cifrada com sua chave privada.

126

Figura 8.25 Exportando a chave pública.


Figura 8.28 Selecionando o arquivo da chave.

Importação da chave de backup

De posse da chave de backup, pode-se agora importá-la em um HSM em operação. Para tanto, basta acessar o menu “Chaves e Contas de Usuário” e, em seguida, “Administradores”, na aba “Importar Chave Pública”.


Figura 8.27 Importando a chave pública no HSM em operação.

127

Ao clicar no botão Importar a Chave Pública, será solicitada a seleção do arquivo que contém a chave pública de backup.

Em seguida, será solicitada a autenticação dos “n” administradores que vão recompor o


segredo do perfil, para possibilitar a importação da chave.

Com a importação da chave de backup, uma mensagem de sucesso será exibida. 128



Geração de backup

Com a chave de backup importada no HSM em operação, é possível agora gerar cópias do ambiente operacional, direcionadas àquele HSM que possui a chave privada de backup correspondente à primeira. Para gerar o backup, deve-se acessar o menu “Chaves e Contas de Usuário”, “Administradores”, na aba “Backup”. Em seguida, deve-se clicar no botão Fazer o Backup.


Figura 8.31 Gerando backup.

129

Será exibido então uma caixa de diálogo de escolha do destino do arquivo de backup, na


máquina hospedeira.

130

Figura 8.32 Escolha do destino do arquivo de backup.


Será solicitada a autenticação do perfil de administração para autorizar a geração e exportação da imagem do ambiente operacional.

Ao fim da operação, será exibida uma mensagem de sucesso.



131

Restauração de backup

Para a restauração da imagem operacional no HSM de backup: com o arquivo de backup gerado e exportado, podemos agora importá-lo para o HSM de backup, caso algum problema ocorra com o HSM operacional. Para isso, deve-se acessar o menu “Chaves e Contas de Usuário”, “Administradores”, na aba “Recuperar Backup”. Em seguida, deve-se clicar no


botão Recuperar o Backup.

132

Figura 8.35 Restaurando o backup.

Será então solicitada a seleção do arquivo contendo a imagem do ambiente operacional que se deseja importar e, em seguida, uma confirmação para prosseguir com a operação. Após a restauração, o HSM será reiniciado para que o processo seja finalizado e o HSM então reiniciará como uma cópia idêntica à do HSM operacional.


Figura 8.36 Seleção do arquivo de backup.

133

Ativar perfis de operação

Até o momento, somente dois dos três perfis presentes no HSM ficaram necessariamente

Figura 8.37 Ativando o perfil de operação.

cientes (via autenticação) da segunda cópia operacional do HSM. Para que o perfil de Operação esteja também ciente, é necessária sua autenticação no procedimento de Ativação do Perfil de Operação, onde fica evidente para este que há uma nova cópia do ambiente opera-


cional em execução. Essa tarefa devolverá ao perfil de administração a capacidade de alterar a

134

custódia de uma chave privada e de um perfil de operação para outro.

Colocar o HSM em Modo Operacional Modo de Segurança: 11 Estado no qual o ASI-HSM entra caso ocorra alguma situação incomum. 22 Desligar abruptamente da tomada. 22 Falha na execução do software. Modo Operacional: 22 Para retornar as funções normais, o HSM deve ser retornado ao modo operacional.

q

Em alguns casos específicos de mal-uso do HSM, este entra em Modo de Segurança. Por exemplo, ao ser desligado abruptamente ou caso ocorra alguma falha no sistema. No Modo de Segurança, o HSM não conseguirá executar nenhuma função crítica, apenas funcionalidades informacionais e tentar retornar ao Modo Operacional. Para colocar o ASI-HSM em Modo Operacional, devemos acessar o menu “Sistema” e “Manutenção”, e a aba “Modo de Segurança”. Em seguida, deve-se clicar no botão “Modo Operacional”. Será requerida a autenticação do grupo de administradores.

Atualização de firmware Objetivo:

q

11 Colocar em funcionamento uma nova versão do HSM. 11 Manter os dados atuais. Passos: 1 Obter arquivo de atualização em formato PKCS#7. 11 Fazer upload do arquivo para o HSM. 11 Verificar o hash do arquivo. 11 O HSM será reiniciado ao final do procedimento. Para fazer o procedimento de atualização do ASI-HSM, é necessário ter um arquivo de atualização no formato PKCS#7 autêntico. A atualização é feita por meio da autenticação do grupo de administradores.


Figura 8.38 Colocando o HSM em modo operacional.

135

Para realizar a atualização do ASI-HSM, devemos acessar o menu “Sistema” e “Manutenção”,


e a aba “Modo Operacional”. Em seguida, deve-se clicar no botão Atualizar Firmware.

136

Em seguida, deve ser selecionado no arquivo PKCS#7, onde se encontra a atualização.

Figura 8.39 Atualizando o firmware.

Figura 8.40 Seleção do arquivo que contém a atualização.

Figura 8.42 Exibição do hash da atualização para verificação.

Após, será requerida a autenticação de “n” dos “m” administradores.



137

É então exibido o hash SHA-1 do arquivo em questão. Este deve ser conferido, para garantir que a atualização ocorrerá corretamente.

Figura 8.43 Confirmação de atualização.

Após a aceitação do hash SHA-1, é feita mais uma confirmação da atualização. Nesse ponto, o usuário ainda pode cancelar o procedimento de atualização, clicando em “Não”. Ou então


continuar, clicando em “Sim”.

138


Por fim, é exibida uma janela confirmando a operação.

Teste das Funções Criptográficas Dois tipos:

q

11 Funções de Segurança (teste lógico). 22 Testa os algoritmos de cifragem e geração de números aleatórios usados no HSM, a fim de garantir que estes não estejam corrompidos ou adulterados. 11 Unidade de Segurança (teste físico). 22 Testa a unidade de segurança, para verificar se os sensores estão em pleno funcionamento.

Para realizar os testes do ASI-HSM, devemos acessar o menu “Sistema” e “Manutenção”, e a aba “Testes”.


Figura 8.45 Testando funções criptográficas.

139

Para fazer o teste das funções de segurança, deve-se clicar no botão “Funções de Segurança”.


O teste é feito e então é exibida uma janela com os resultados.

140

Figura 8.46 Resultado dos testes de funções criptográficas.

Figura 8.47 Resultado de testes da unidade de segurança.

Para realizar os testes da US, deve-se clicar no botão “Unidade de Segurança”. O teste então é feito e então exibida uma janela com os resultados.

Apagar as configurações do HSM É possível apagar todas as configurações do HSM. Esse procedimento é realizado sob o perfil de administração.

Para realizar o processo de apagar o HSM, devemos ir em “Sistema” e “Manutenção”, na aba “Modo Operacional”. Deve-se então clicar no botão Apagar Tudo.


Figura 8.48 Apagando as configurações do HSM.

141


Será requerida a autenticação do grupo de administradores.

142


Figura 8.50 Confirmação da operação.

É exibido um diálogo pedindo por uma confirmação do procedimento. Nesse ponto, o usuário pode cancelar a operação clicando em “Não” ou continuar, clicando em “Sim”.

No final, é exibida uma mensagem confirmando a operação. O HSM é então reinicializado.



143

144


9 Conhecer os passos de um credenciamento de entidade na ICP-EDU; Simular o credenciamento de entidade na ICP-EDU; Aprender sobre cerimônias de credenciamento.

conceitos

Credenciamento de entidade; Cerimônias.

Credenciamento de entidade 11 Nesta sessão, será realizada a integração do SGCI com o ASI-HSM, através da criação

q

de uma ICP simples dentro do SGCI. 11 Essa atividade tem como pré-requisitos todas as sessões anteriores e envolverá os conceitos de: 22 Infraestrutura de Chaves Públicas. 22 Hardware criptográfico. 22 Software de Gerenciamento de Certificados Digitais. 22 Cerimônias e procedimentos práticos de credenciamento. 11 A realização dessa atividade é fundamental para a compreensão de todo o conteúdo abordado durante o curso. Esta sessão tem por objetivo a simulação de um credenciamento de uma entidade na ICPEDU. Em um credenciamento real, há diversos passos que devem ser realizados de forma a produzir evidências para futuras auditorias. Embora o SGCI e o ASI-HSM produzam logs com essa finalidade, há diversas práticas definidas nas Declarações de Práticas de Certificação que definem passos realizados fora desses dois softwares para a garantia da segurança do ambiente em um nível externo. Por exemplo, na ICP-EDU, uma das práticas define que é necessário o armazenamento das credenciais dos usuários do SGCI em um cofre localizado em um ambiente com barreiras de segurança física. O conjunto de todos os passos realizados tanto fora quanto dentro dos softwares de gerenciamento da ICP é denominado cerimônia. As cerimônias estão presentes em diversas tarefas de uma ICP, desde o credenciamento de novas entidades até a emissão de LCRs. Na atividade prática desta sessão, trataremos das cerimônias em nível mais superficial, dando mais enfoque aos passos realizados nos softwares. Porém, alguns dos outros passos serão

Capítulo 9 - Integração do SGCI com o ASI-HSM

objetivos

Integração do SGCI com o ASI-HSM

descritos mais adiante. É importante lembrar que as cerimônias aqui descritas são simplificadas, pois nosso objetivo é didático. 145

Cerimônia de credenciamento Para realizar nossa simulação, vamos criar uma ICP nova para que possamos conhecer bem os passos envolvidos na cerimônia de credenciamento. A estrutura da ICP que vamos criar é demonstrada na figura 9.1.

AC Raiz

AR

AC SSL Figura 9.1 ICP gerada durante a atividade.

Relacionamento de confiança Certificado emitido

q

Simulação de credenciamento: 11 Nesta etapa criaremos a AC Raiz e a AR. 11 Serão realizadas: 22 Configuração do sistema (SGCI+HSM). 22 Geração da AC Raiz e da AR. 22 Atribuição de papéis e configuração de modelos de certificados.

Inicialmente vamos tratar da criação da AC Raiz e da AR a ela vinculada. A criação da AC SSL


será tratada em uma segunda etapa, pois como já visto anteriormente, se assemelha muito

146

com a criação de uma AR. O primeiro passo do credenciamento é a configuração do sistema. Nesse passo é necessário configurar o ambiente para receber o SGCI, e para operar com o HSM, além de configurar o relógio e os dados dos certificados internos do HSM. Assim que o ambiente é corretamente configurado, é possível iniciar a cerimônia de criação da AC Raiz e da AR. Essa cerimônia pode ser vista com mais detalhes a seguir.

Etapa 1: Preparação Título

Atividade

Endereço da LCR e DPC/PC.

Declaração de Práticas de Certificação (DPC). Deverá o responsável ter acesso à conta da máquina onde serão colocados os arquivos LCR e DPC.

Observação

Tabela 9.1 Cerimônia de preparação de ambiente.

Etapa 1: Preparação Atividade

Instalação da máquina hospedeira e HSM.

Selecionar um local para a instalação da máquina hospedeira e do HSM. Verificar a existência de alimentação de energia elétrica (verificação da tensão correta dos equipamentos em relação a 110v/220v) com garantia de fornecimento (no-break/ gerador), cabos e outros requisitos para a correta operação dos dois sistemas.

Instalação da Máquina Hospedeira.

Instalar Sistema Operacional, SGCI e OpenHSMd-Client (linha de comando e Java) na máquina hospedeira. Configurar rede.

Configurar o HSM.

Antes de iniciar o processo de configuração, usando o comando adequado do OpenHSMd-Client.

Acertar relógio do HSM.

Utilizar a interface remota do HSM para verificar o horário do HSM e se necessário corrigir. Atenção: UTC!

Acertar relógio da máquina hospedeira.

Verificar, e se necessário, acertar o relógio da máquina hospedeira.

Criar os administradores do HSM.

Usar a interface de gestão remota de gestão do HSM (OpenHSM-Client-Java) para criar o grupo de administradores. Para cada um dos administradores do grupo, selecionar um smartcard, nomeando-o (colar uma etiqueta com o nome do administrador) e atribuindo um PIN. Cada um dos PINs deve ser registrado em dois pedaços de papel e colocado em dois envelopes separados com a identificação do membro. Um dos conjuntos de envelopes deve ser lacrado, datado, assinado e armazenado em local seguro, preferencialmente em um cofre. O outro conjunto e os smartcards serão usados nos passos adiante. O nome do grupo deverá ser “adm-ac-raiz”.

Criar os auditores do HSM.

Usar OpenHSM-Client-Java para criar o grupo de auditores. Será necessário autenticar-se como administrador primeiro. Para cada um dos auditores do grupo, selecionar um smartcard, nomeando-o (colar uma etiqueta com o nome do auditor no suporte plástico do smartcard) e atribuindo um PIN. Cada um dos PINs deve ser registrado em dois pedaços de papel e colocado em dois envelopes separados com identificação do auditor. Um dos conjuntos deve ser lacrado, datado, assinado e armazenado em local seguro, preferencialmente em um cofre. O outro conjunto e os smartcards serão usados no passo seguinte. O nome do grupo deverá ser “aud-ac-raiz”.

Observação

Instalar apache, postgres, php5, java e pkcs7tool.


Título

147


Etapa 1: Preparação

148

Título

Atividade

Criar os operadores do HSM.

Utilizar a interface de gestão remota do HSM para criar o grupo de operadores. Para cada um dos operadores, selecionar um smartcard, nomeando-o (colar uma etiqueta com o nome do operador) e atribuindo um PIN. Cada um dos PINs deve ser registrado em dois pedaços de papel e colocado em dois envelopes separados com identificação do operador. Um dos conjuntos de envelopes deve ser lacrado, datado, assinado e armazenado em local seguro, preferencialmente em um cofre. No outro conjunto, além dos PINs, serão inseridos os smartcards. O nome do grupo deverá ser “oper-ac-raiz”.

Gerar arquivo de log do HSM.

Auditores geram, através da interface de gerenciamento do HSM, o arquivo contendo o registro de todas as operações do HSM desde sua configuração inicial até o passo anterior a este. O arquivo de registro (log) deverá ser analisado e o parecer dessa análise fazer parte do relatório final do cerimonial.

Definir senha do criador e criar usuários para administração e operação de entidades.

Executar o SGCI, definir nova senha do criador e criar os usuários dos grupos Administrador e Operador (adm-ac-raiz, oper-ac-raiz, adm-ar-vinculada, oper-ar-vinculada). A senha do criador deve ser registrada em dois pedaços de papel e colocadas em dois envelopes separados com identificação do criador. Os envelopes devem então ser lacrados, datados, assinados, identificados e armazenados em local seguro, preferencialmente em um cofre.

Configurar o SGCI.

Configurar o SGCI. Deixar o SGCI preparado para emitir o certificado digital da AC Raiz e a respectiva LCR. Cadastrar o HSM no SGCI. Fazer backup.

Gerar arquivo de log do SGCI.

O criador deve, através da interface SGCI, gerar o arquivo contendo o registro de todas as operações do SGCI desde sua configuração inicial até o passo anterior a este. O arquivo de registro (log) deverá ser analisado e o parecer dessa análise fazer parte do relatório final do cerimonial.

Preparar novo HSM para backup.

Configurar um novo HSM para backup. Exportar o certificado do HSM de backup para a estação hospedeira.

Importar Certificado de Backup.

Importar o certificado do HSM de backup para o HSM operacional.

Guardar Envelopes com smartcards.

Colocar no respectivo envelope com o registro do seu PIN o smartcard dos membros dos grupos. Todos os envelopes devem ser lacrados, datados, assinados e armazenados local seguro, preferencialmente em um cofre.

Observação

engine deve ser compilado para o Sistema Operacional da máquina hospedeira

Etapa 1: Preparação Atividade

Registro de presença.

Preparar uma folha com a lista dos participantes e testemunhas convidadas para a cerimônia. Essa lista será assinada pelas pessoas presentes à etapa 2.

Preparar a apresentação do cerimonial.

Preparar slides para a apresentação do cerimonial. Esses slides deverão adicionalmente fazer parte posteriormente do registro da cerimônia.

Ata da etapa 1 do cerimonial.

Preparar e imprimir uma cópia da Ata da etapa 1 do cerimonial. Solicitar que todos os participantes assinem a ata.

Observação

Etapa 2: Criação da AC Raiz Título

Atividade

Abertura.

Falar do Grupo de Trabalho ICPEDU, piloto ICPEDU e do serviço experimental.

Identificação dos participantes e testemunhas.

Nesse momento, o gerente da Gopac, em nome do Comitê Gestor, dá boas-vindas aos participantes e convidados. Todos os presentes deverão ser devidamente identificados e devem assinar o registro de presença.

Explicação da Cerimônia.

Explicar todos os procedimentos e passos do cerimonial. Usar uma apresentação com slides.

Colocar a estação hospedeira e o HSM em operação.

Os equipamentos com a AC Raiz e o HSM devem ser ligados e disponibilizados aos operadores e administradores.

Acertar relógio do HSM.

Utilizar a interface remota do HSM para verificar o horário do HSM e, se necessário, corrigi-lo.

Acertar relógio da máquina hospedeira.

Verificar e se necessário, acertar o relógio da máquina hospedeira.

Geração do par de chaves da AC Raiz.

O grupo de administradores deve autenticar-se e gerar, através do software de gestão do HSM, o par de chaves da AC Raiz do piloto da ICPEDU. A chave privada deverá ser denominada “chave-ac-raiz”.

Liberar a Chave privada da AC Raiz para Uso.

Os operadores devem liberar o uso da chave, definindo para esta a seguinte política: número de usos 100 e tempo ilimitado. A chave privada será usada pelo SGCI para assinar o certificado da AC Raiz e gerar a LCR. O relatório final deverá explicar cada uso da chave.

Observação


Tabela 9.2 Cerimônia de criação de AC Raiz.

Título

149


Etapa 2: Criação da AC Raiz

150

Título

Atividade

Gerar o certificado digital da AC Raiz.

Executar o SGCI na máquina hospedeira. Logar-se como criador e executar o comando de geração do certificado autoassinado. Os seguintes parâmetros ou extensões serão usados no certificado: O – RNP O – ICPEDU CN – AC Raiz da ICPEDU C – BR Período de validade: 10.950 dias (30 anos) OID da PC: 1.3.6.1.4.1.15996.1.2.1.1 Ponteiro para LCR: conforme definido na Etapa 1 Ponteiro da DPC: conforme definido na Etapa 1 Algoritmo de Assinatura: SHA-1 com RSA Tamanho da Chave: 2048 bits Uso da Chave: assinatura de certificados digitais e lista de certificados revogados Incluir Subject Key Identifier

Exportar o certificado da AC Raiz.

Exportar o certificado da AC Raiz para um arquivo. Copiar o certificado e colocá-lo em um pendrive ou outra mídia. Calcular o hash do certificado, anotar na ata do cerimonial.

Criar a AR.

Os seguintes parâmetros ou extensões serão usados no certificado: O – RNP O – ICPEDU CN – : AR Vinculada C – BR Período de validade: 10.950 dias (30 anos) OID da PC: 1.3.6.1.4.1.15996.1.2.1.1 Ponteiro para LCR: conforme definido na Etapa 1 Ponteiro da DPC: conforme definido na Etapa 1 Algoritmo de Assinatura: SHA-1 com RSA Tamanho da Chave: 2048 bits Incluir Subject Key Identifier

Exportar o certificado da AR.

Exportar o certificado da AR para um arquivo. Calcular o hash do certificado, anotar na ata do cerimonial.

Cadastrar administradores da AC Raiz e AR.

Cadastrar os administradores da AC Raiz e da AR. As senhas devem ser registradas em dois pedaços de papel (cada uma delas) e colocadas em dois envelopes separados com identificação do criador. Os envelopes devem então ser lacrados, datados, assinados, identificados e armazenados em local seguro, preferencialmente em um cofre.

Cadastrar o operador da AC Raiz.

Entrar como administrador da AC Raiz e cadastrar o operador da AC Raiz. A senha deve ser registrada em dois pedaços de papel e colocada em dois envelopes separados com identificação do criador. Os envelopes devem então ser lacrados, datados, assinados, identificados e armazenados em local seguro, preferencialmente em um cofre.

Observação

Etapa 2: Criação da AC Raiz Atividade

Cadastrar o operador da AR Vinculada.

Entrar como administrador da AR e cadastrar o operador da AR. A senha deve ser registrada em dois pedaços de papel e colocada em dois envelopes separados com identificação do criador. Os envelopes devem então ser lacrados, datados, assinados, identificados e armazenados em local seguro, preferencialmente em um cofre.

Emitir a LCR.

Entrar como operador da AC Raiz. Emitir a LCR. Verificar que tal lista não deve conter qualquer referência a certificados digitais. Usar como período de validade da LCR 84 dias. (Como serão 12 semanas, deixar agendado toda sexta-feira múltipla desse período para que o Gopac gere nova LCR através de cerimônia específica e enviar para o GT para publicação.)

Exportar a LCR.

Exportar a LCR para um arquivo com o nome ac-raiz-icpedu.crl. Copiar a LCR e colocá-la em um pendrive ou outra mídia.

Criar templates de políticas.

Autenticar-se no SGCI como administrador da AC e criar templates de certificados para AC credenciada. Template AC Credenciada: Nome do Template: Autoridade Certificadora Credenciada Validade: 7.300 dias (20 anos) Configuração: Manter as que não constem no template Entidade: AC Path Length: não definido SKID: Sim AKID: Sim Uso da Chave: KeyCertSign, CRLSign URL da LCR: igual a AC Raiz OID da PC: igual a AC Raiz URL da DPC: igual a AC Raiz Texto da DPC: Os certificados da ICPEDU sao para uso exclusivo por organizacoes brasileiras de ensino e pesquisa, e nao tem eficacia juridica Template AR: Nome do Template: Autoridade de Registro Validade: 7300 dias (20 anos) Configuração: Manter as que não constem no template Entidade: AC Path Length: 0 SKID: Sim AKID: Sim Uso da Chave: digital Signature, keyEncipherment URL da LCR: igual a AC Raiz OID da PC: igual a AC Raiz URL da DPC: igual a AC Raiz Texto da DPC: Os certificados da ICPEDU sao para uso exclusivo por organizacoes brasileiras de ensino e pesquisa, e nao tem eficacia juridica

Observação


Título

151


Etapa 2: Criação da AC Raiz

152

Título

Atividade

Criar templates de políticas.

Template AC Serviço: Nome do Template: Autoridade Certificadora de Serviço Validade: 7300 dias (20 anos) Configuração: Manter as que não constem no template Entidade: AC Path Length: 0 SKID: Sim AKID: Sim Uso da Chave: KeyCertSign, CRLSign URL da LCR: igual a AC Raiz OID da PC: igual a AC Raiz URL da DPC: igual a AC Raiz Texto da DPC: Os certificados da ICPEDU sao para uso exclusivo por organizacoes brasileiras de ensino e pesquisa, e nao tem eficacia juridica

Exportar arquivo de confiança.

Exportar o arquivo para uma mídia móvel. Esse arquivo será usado pela AR Raiz para criar vínculo de confiança.

Desabilitar a chave da AC Raiz no HSM.

Descarregar a chave privada da AC Raiz. Após essa operação, a chave estará bloqueada para uso.


Autenticar o grupo de auditores e gerar, através da interface de gerenciamento do HSM, o arquivo contendo o registro de todas as operações do HSM, desde sua configuração inicial até o passo anterior a este. O arquivo de registro (log) deverá ser analisado e comparado com o arquivo de log emitido na etapa 1 do cerimonial, e o parecer dessa análise fazer parte do relatório final.

Gerar arquivo de log do SGCI.

Gerar, através da interface do SGCI, o arquivo contendo o registro de todas as operações do SGCI desde sua configuração inicial até o passo anterior a este. O arquivo de registro (log) deverá ser analisado e comparado com o arquivo de log emitido na etapa 1 do cerimonial, e o parecer dessa análise fazer parte do relatório final.

Devolver os smartcards.

Todos os membros de todos os grupos devem colocar os smartcards em envelopes, lacrá-los, datá-los e assiná-los. Os envelopes com os smartcards deverão ser armazenados em local seguro, preferencialmente em um cofre.

Apresentar o certificado da AC Raiz.

Mostrar o certificado digital (seu conteúdo) para o público presente ao cerimonial.

Apresentar a LCR.

Mostrar a LCR (seu conteúdo) para o público presente ao cerimonial.

Ata da etapa 2 do cerimonial.

Preparar e imprimir uma cópia da Ata da etapa 2 do cerimonial. Solicitar que todos os presentes assinem a ata.

Observação

Etapa 2: Criação da AC Raiz Título

Atividade

Fim da etapa 2 da cerimônia.

Falar de como será mantido o sistema e do trabalho que será realizado, como novas cerimônias para emitir os certificados das AC credenciadas e LCR. Falar do serviço experimental.

Observação

Etapa 3: Finalização Atividade

Fazer backup do HSM.

Importar o certificado de backup para o HSM original. Realizar a cópia de backup.


Autenticar o grupo de auditores e gerar, através da interface de gerenciamento do HSM, o arquivo contendo o registro de todas as operações do HSM, desde sua configuração inicial até o passo anterior a este. O arquivo de registro (log) deverá ser analisado e o parecer dessa análise fazer parte do relatório final do cerimonial.

Relatório Final do cerimonial.

Preparar o relatório final do cerimonial, contendo as seguintes informações: a) atas das etapas 1 e 2; b) arquivos de log gerados; c) análise dos arquivos de log; d) arquivos com os certificados da AC Raiz e da LCR; e) hash do certificado digital da AC Raiz; f) cópia impressa do certificado da AC Raiz em formato PEM e em ASN.1 Parser. g) cópia impressa da LCR em formato PEM e em ASN.1 Parser; h) fotos do cerimonial; i) filmagens do cerimonial; j) cópia desse documento (cerimônia); k) apresentação do cerimonial; l) lista de presença da etapa 2. (Enviar uma cópia desse relatório para o GT e para o Comitê Gestor.)

Analisar e aprovar o cerimonial.

Convocar uma reunião do CG para a análise do cerimonial. Se aprovado, autorizar o GT a publicar o certificado digital da AC Raiz, a LCR e o relatório final do cerimonial no site do ICPEDU.

Publicar o certificado da AC Raiz no site do ICPEDU.

Publicar o certificado digital da AC Raiz no site do ICPEDU. Incluir instruções para a instalação deste para os principais Sistemas Operacionais e aplicativos.

Publicar a LCR.

Publicar a LCR no endereço contido na extensão do certificado da AC Raiz.

Publicar o relatório final do cerimonial.

Publicar o relatório final do cerimonial no site do ICPEDU.

Observação


Tabela 9.3 Cerimônia de finalização do credenciamento da AC Raiz.

Título

153

Note que é muito importante seguir os passos da cerimônia na ordem em que esses foram apresentados. Somente assim a cerimônia poderá ser concluída com sucesso, uma vez que um dos últimos passos é a análise de todo o processo por parte do Comitê Gestor. Caso o Comitê não aprove, toda a cerimônia terá sido em vão, e deve se dar início ao processo novamente. Outro ponto importante é que cada um dos passos apresentados é de responsabilidade de uma determinada pessoa ou de mais, quando necessário, podendo ser executada somente por estas. Essas informações foram removidas com o intuito de facilitar a compreensão. Finalmente, é necessário realizar a etapa final da cerimônia, que inclui a criação do vínculo de confiança entre a AC Raiz e a AR.


Etapa 4: Vínculo de Confiança com ARs credenciadas

154

Título

Atividade

Identificação dos participantes e testemunhas.

Nesse momento, o gerente da Gopac dá boas-vindas aos participantes e convidados. Todos os presentes deverão ser devidamente identificados e devem assinar o registro de presença.

Explicação da Cerimônia.

Explicar todos os procedimentos e passos do cerimonial.

Apresentação dos membros do grupo de administração da AC Raiz (SGCI).

Apresentar o administrador da AC Raiz no SGCI.

Colocar a estação hospedeira em operação.

A máquina hospedeira com a AC Raiz deve ser ligada e disponibilizada ao administrador.

Estabelecer confiança com a AR.

O administrador da AC Raiz deve importar o arquivo de configuração da AR.

Gerar log SGCI.

Como usuário criador, gerar log do SGCI.

Armazenar senha do administrador.

Guardar a senha do administrador da AC Raiz no envelope. Lacrar e Assinar.

Ata.

Preparar e imprimir uma cópia da Ata da etapa 1 do cerimonial. Solicitar que todos os participantes assinem a ata.

Observação

Nesse ponto, se tudo ocorreu com sucesso, a cerimônia de criação da AC Raiz e AR está finalizada. A cerimônia de criação da AC Intermediária não será apresentada, pois se assemelha muito com as anteriores. Cerimônias como essas são muito importantes, pois, como já mencionado, produzem evidências para auditoria. Essas auditorias são realizadas com o intuito de garantir que as entidades estão seguindo as suas Declarações de Práticas de Cerificação e, consequentemente, que essas entidades podem ser confiáveis. Como a DPC é um documento público que pode ser acessado por qualquer usuário final, cada pessoa pode conhecer em detalhes as práticas de determinada entidade e optar por confiar ou não nela para emitir seu certificado digital.

Tabela 9.4 Cerimônia de vínculo de confiança.

10 Conhecer os conceitos de Federação; Aprender sobre a instalação e configuração do Sistema Automatizado de Emissão de Certificados (SAEC); Conhecer as tarefas administrativas do SAEC.

conceitos

Federação (Elementos e Interação entre componentes); Federação CAFe; SAEC (instalação e configuração, utilização do SAEC, administração do SAEC e operação de instituições.)

Federação Principais características de uma Federação:

q

11 Uniformização das formas de acesso a serviços. 11 Minimizar as demandas tanto dos usuários quanto dos provedores de serviços. 22 Usuários têm seus dados mantidos por uma única base de dados. 22 Serviços compartilham bases de dados de usuários em vez de replicar todos os dados em cada serviço diferente. Antes de iniciarmos nossos estudos sobre a Federação CAFe e o SAEC, é necessário que tenhamos bem definidos os conceitos e objetivos de uma Federação e seus componentes e sua arquitetura básica. A crescente demanda de sistemas informatizados para serviços voltados a usuários finais criou uma necessidade de uniformizar as formas de acesso a esses serviços. Do ponto de vista do usuário, é muito mais interessante que seus dados sejam mantidos por uma única base de dados, e que cada serviço tenha acesso a esta, definindo apenas o nível de privilégio que o usuário possui naquele determinado serviço. Dessa forma, cada usuário não necessita manter diversas credenciais (e contas) para diversos serviços. Da mesma forma, do ponto de vista dos provedores de cada serviço, é muito mais seguro e confiável compartilhar bases de dados de usuários do que replicar todos os dados em cada serviço diferente. O conceito de Federação visa minimizar as demandas tanto dos usuários quanto dos provedores de serviços. A ideia é simples: a Federação é uma união de instituições que compartilham serviços entre si. Cada usuário envolvido é associado a somente uma instituição que mantém a guarda de seus dados. Cada provedor de serviço da Federação terceiriza a tarefa

Capítulo 10 - Federação CAFe e SAEC

objetivos

Federação CAFe e SAEC

de autenticação do usuário para sua instituição de filiação, cabendo a esses somente tarefas relacionadas ao serviço provido. 155

Vale ressaltar que cada instituição da Federação define seu modelo de gestão de identidades, ou seja, a forma com que os dados dos usuários são mantidos, atualizados e a forma de autenticação destes. No modelo de Federação, é necessário que cada provedor de serviço confie no modelo de gestão das entidades das instituições envolvidas. Dessa forma, é possível disponibilizar seus serviços para os usuários de outras instituições. É dessa forma que o conceito de identidade federada é criado. Nas figuras 10.1 e 10.2, podemos ver uma ilustração de serviços sendo providos em um esquema usual, com informações sobre o usuário mantidas pelos serviços, e outro com Federação, onde as informações são centralizadas nas instituições. No primeiro modelo, o usuário é forçado a se autenticar (apresentar as suas credenciais) toda vez que deseja utilizar um serviço, seja ele da sua instituição ou de outras. Cada serviço precisa manter uma base de dados de todos os seus usuários, incluindo os de outras instituições, e cuidar das permissões de acesso de cada um destes. Nesse modelo é fácil perceber a quantidade de dados replicados. De certa forma, todas as bases de dados contêm dados iguais, eles apenas são geridos e mantidos de diferentes formas. No segundo modelo, cada usuário possui apenas um conjunto de credenciais que são apresentadas e validadas apenas na sua instituição de filiação. Cada serviço fica apenas com a tarefa de verificar as permissões de acesso de cada usuário. Como a tarefa de autenticação dos usuários é realizada pela própria instituição, não é necessário replicar nenhum dado. Se um usuário da Instituição A precisar acessar um serviço da Instituição B, ele será requisitado a se autenticar através da Instituição A, que ficará responsável por repassar ao serviço da Instituição B somente o resultado do processo, ou seja, se a autenticação foi realizada com sucesso ou se falhou.

Instituição A Correio eletrônico

Credenciais

EaD


Biblioteca Central

156

Periódicos

Credenciais Credenciais

Biblioteca digital

Credenciais

Credenciais EaD Repositórios Credenciais

Instituição B

Figura 10.1 Modelo com informação de usuários mantidos pelos serviços.

Instituição A Correio eletrônico

Credenciais

EaD Periódicos

Biblioteca Central Biblioteca digital

EaD

Credenciais

Repositórios

Instituição B

Elementos de uma Federação 11 Provedor de serviço (SP).

q

11 Provedor de identidade (IdP). 11 Where Are You From (WAYF). 11 Usuário. 11 Instituição. 11 Provedor de recurso. Uma Federação é composta por dois principais componentes: 11 Provedor de serviço (SP); 11 Provedor de identidade (IdP). E mais um componente adicional que auxilia no funcionamento da Federação: 11 Where Are You From (WAYF). Além disso, é possível identificar três principais papéis ativos na Federação: 11 Usuário; 11 Instituição; 11 Provedor de recurso. Um esquema simplificado que mostra a forma com que cada um desses interage entre si pode ser visto na figura 10.3.


Figura 10.2 Modelo com informação de usuários mantidos pelas instituições (Federação).

157

WAYF

Instituição IdP

Provedor de serviço Provedor de recurso

Primeiramente, o usuário interage com o provedor de serviços (SP) desejado, que é responsável por oferecer serviços restritos para determinados grupos de usuários. O provedor de serviços possui acoplado um provedor de recursos, que é a aplicação (software) que provê o serviço ou recurso de fato. Para conseguir usufruir do serviço provido, o usuário precisa autenticar-se. Como a autenticação em uma Federação é realizada pelas instituições, primeiro é necessário identificar a qual instituição o usuário pertence. Nesse momento, o componente Where Are You From (WAYF) é acionado. O WAYF é responsável por prover uma lista sempre atualizada de instituições pertencentes à Federação. Assim, o usuário é solicitado a selecionar a sua instituição dentro dessa lista. Logo após isso, o usuário é encaminhado para a página de acesso em sua instituição. Isso é possível, uma vez que o WAYF conhece todos os provedores de identidade da Federação e possui seus respectivos endereços eletrônicos armazenados. O passo seguinte envolve a autenticação do usuário. Essa etapa é de responsabilidade da instituição à qual o usuário pertence. Cada instituição mantém um provedor de identidades (IdP) que é o componente da Federação responsável por guardar os dados de cada usuário. Tanto dados referentes ao usuário digital, como login, informações a respeito de senha, identificado único etc. quanto dados pessoais, como CPF, endereço, cargo de ocupação, entre outros. A forma com que os usuários se autenticam fica a critério de cada instituição. Por fim, o provedor de identidades (IdP) se comunica com o provedor de serviços (SP) para


informar o resultado da autenticação, cabendo ao segundo decidir sobre o controle de

158

acesso. Sendo assim, se o SP precisar de mais informações sobre o usuário para decidir se esse tem ou não privilégios para acessar o serviço, ele ainda se comunicar novamente com o IdP para solicitá-las.

Figura 10.3 Componentes e papéis de uma Federação.

Interação entre componentes WAYF

3 4

2

5 Instituição

1

6

IdP

7 8

Provedor de serviço Provedor de recurso

A figura 10.4 demonstra a comunicação completa que acontece no momento que um usuário deseja acessar um serviço. 1. O usuário solicita acesso a um serviço no provedor de serviços (SP); 2. O SP apresenta as escolhas oferecidas pelo repositório central WAYF para o usuário; 3. O usuário seleciona sua instituição de origem; 4. O usuário é redirecionado para a página do seu provedor de identidades (IdP); 5. O IdP solicita que o usuário se autentique com o método que a instituição escolher; 6. O usuário se autentica; 7. O IdP envia o resultado da autenticação para o SP; 8. Eventualmente, SP e IdP se comunicam caso mais informações do usuário sejam necessárias.

Federação CAFe Comunidade Acadêmica Federada:

q

11 Federação brasileira constituída somente por instituições de ensino e pesquisa. 11 Instituições podem fazer o papel de Provedor de Identidade e de Provedor de Serviço. 11 WAYF é mantido pela RNP. 11 Baseada no software aberto de web single sign-on Shibboleth. Números (até o início de 2014): 11 Mais de 55 Provedores de Identidade. 11 Mais de 15 Provedores de Serviço. 11 Mais de 90 instituições em processo de adesão. Agora que nós já conhecemos bem os conceitos de Federação e seus componentes, nós podemos falar sobre a Federação CAFe. A Comunidade Acadêmica Federada, mais conhecida como Federação CAFe, é uma Federação brasileira constituída somente de instituições de ensino e pesquisa. Na Federação


Figura 10.4 Comunicação completa entre componentes de uma Federação.

CAFe, cada instituição pode fazer o papel de um Provedor de Identidade, de um Provedor 159

de Serviço ou de ambos, enquanto o componente WAYF é mantido pela Rede Nacional de Ensino e Pesquisa (RNP). Não há nenhum custo atrelado à adesão da Federação CAFe, pois o seu objetivo não é financeiro, mas sim congregar todas as instituições acadêmicas brasileiras. Até o início de 2014, a Federação CAFe já possuía mais de 55 Provedores de Identidade e mais de 15 Provedores de Serviço cadastrados, além de mais de 90 instituições em processo de adesão. Entre os principais serviços disponíveis pela Federação CAFe estão: o portal de periódicos da CAPES, uma biblioteca digital com o melhor da produção científica internacional, o DreamSpark, que é um programa da Microsoft que oferece software gratuito para estudantes, e o Journal and Event Management System (JEMS), que é um sistema gerenciamento de

w

submissão e revisão de artigos. A Federação CAFe se baseia no software aberto de web single sign-on Shibboleth para auxiliar no gerenciamento de Provedores de Identidade e de Serviços. O Shibboleth é uma tecnologia baseada em Security Assertion Markup Language (SAML), que vem se firmando como um padrão para a troca de informações de autenticação e autorização entre Provedores de Identidade e de Serviço em Federações mundo a fora.

SAEC Sistema Automatizado de Emissão de Certificados.

q

11 Objetiva a emissão de certificados sem a interferência de operadores. 11 Provedor de Serviço de Federações. 11 Confia às instituições da Federação o papel de fazer a verificação dos dados de cada usuário. O SAEC, Sistema Automatizado de Emissão de Certificados, como o próprio nome diz, é um sistema cujo objetivo é a emissão automatizada de certificados, ou seja, sem a interferência de operadores no processo. Isso é possível pois o SAEC combina uma Autoridade Certificadora similar ao que seria uma AC online e de emissão automática no SGCI com uma Autoridade de Registro automática. Relembrando os conceitos, isso significa que a comunicação


entre AC e AR é feita pela internet e que a AC emite automaticamente qualquer certificado cuja requisição foi verificada (assinada) pela AR. Quanto à AR, o SAEC introduz novos conceitos, uma AR automática seria uma autoridade que verifica os dados do requisitante de forma automática. Mas como isso é possível? Hoje em dia, para conseguir um certificado válido na maioria dos navegadores web, ou seja, emitido por uma Autoridade Certificadora confiável, o usuário precisa apresentar seus documentos de identificação na Autoridade de Registro para provar a autenticidade dos dados contidos na requisição do certificado. Às vezes o processo de apresentação de documentos requer um nível maior de segurança, exigindo inclusive que o usuário se apresente pessoalmente. Não é necessário muito para percebemos como esse processo pode ser custoso para todos os envolvidos. Tanto para os usuários que precisam se locomover até a autoridade para se apresentar pessoalmente, quanto para as autoridades que precisam manter instalações físicas em locais estratégicos espalhados para atender o máximo de usuários possível. Como uma alternativa a esse processo custoso o SAEC surgiu, e atua como um Provedor de Recursos da Federação CAFe. Em vez de manter uma Autoridade de Registro fisicamente instalada para fazer a verificação das requisições de certificado, o SAEC confia às instituições da Federação o papel de fazer a verificação dos dados de cada usuário. 160

Para mais informações acesse a página da Federação CAFe: http://portal.rnp.br/ web/servicos/cafe

Assim o Provedor de Identidade faz o papel da AR. E, de fato, se pensarmos nas universidades Brasil afora, percebemos que as informações cruciais de cada usuário é verificada pelos departamentos a elas vinculados no momento de sua matrícula. A partir daí o usuário só consegue alterar os seus dados básicos, como endereço e telefone, sem verificação. Com o SAEC sendo um Provedor de Recursos online na Federação CAFe, a emissão de certificados passa a ser muito simples, uma vez que os usuários não precisam se locomover até uma AR e nem prover seus dados.

Todo o processo é realizado automaticamente, através da internet e totalmente transparente ao usuário.

Embora aqui somente seja citada a Federação CAFe, o SAEC foi projetado e desenvolvido para funcionar em qualquer Federação, desde que seja provido seu XML de configuração no momento em que o SAEC estiver sendo instalado e que esta seja compatível com o software livre Shibboleth.

Instalação e configuração Detalhes técnicos:

q

11 O SAEC é suportado no Sistema Operacional Ubuntu. 11 Fortemente indicada a sua instalação em versões LTS do Ubuntu. 11 Instalado através de um pacote apt. Atualmente, o SAEC é suportado no Sistema Operacional Ubuntu, recomendando-se forte-

Saiba mais

l

Para mais detalhes, consulte o manual de instalação e configuração do SAEC.

mente o uso de versões LTS. A sua instalação é bastante simples e similar à do SGCI: basta configurar o repositório e baixar o pacote apt. O restante será feito automaticamente. A configuração do SAEC é realizada somente na primeira vez em que o sistema é executado. Nessa etapa são realizados, entre outros, o cadastro do usuário responsável pela administração do sistema, o cadastro da(s) federação(ões) vinculada(s) e o setup da Autoridade Certificadora. Sendo este último bastante parecido com o setup de uma AC no SGCI, incluindo o download da requisição de certificado, a emissão de seu certificado por outra AC, a configuração do template de certificado utilizado, entre outros.

Utilização do SAEC Do ponto de visto do usuário, o SAEC é um sistema muito simples. Para solicitar um certificado, é necessário acessar a página principal do SAEC, clicar em “Certificado” e depois em

Figura 10.5 Tela inicial do SAEC.

Logo após aparecerá uma janela onde o usuário vai selecionar sua instituição (WAYF). Essa janela é similar à da figura 10.6.


“Emitir”, conforme visto na figura 10.5.

161

Depois de selecionar a instituição, o usuário será redirecionado para a página do seu Provedor de Identidade, onde deverá se autenticar. Logo após, o usuário é redirecionado novamente para a página do SAEC, onde o seu nome comum e e-mail já vem automaticamente preen-

Figura 10.6 Where Are You From.

chido, sendo necessário somente o preenchimento do tamanho da chave para a emissão do


seu certificado, conforme a figura 10.7.

162

Figura 10.7 Solicitação de certificado.

Após clicar em “Submeter”, o navegador instalará o certificado em seu repositório e a seguinte mensagem de sucesso aparecerá.

Figura 10.8 Mensagem de sucesso.

Administração do SAEC 11 Logs.

q

11 Operadores. 11 HSM. 11 Requisição. 11 Modelos. 11 LCR. 11 Certificados. 11 Backup. 11 Estatísticas. Assim como todo provedor de serviço, o SAEC também possui uma área administrativa, onde são feitas as suas configurações de forma geral. A figura 1.09 apresenta a tela inicial da área administrativa do SAEC.

Figura 10.9 Tela inicial da área de Administração do SAEC.

Nas próximas páginas, vamos conhecer um pouco mais sobre cada tipo de configuração que pode ser feita na área administrativa do SAEC. Em ordem serão apresentadas as seguintes áreas:

Logs Similarmente ao SGCI, toda operação realizada no SAEC é gravada em um log. Desde a operação mais simples, como um login, até as mais complexas, como backup, são registradas seguir é possível ver as operações disponíveis no menu de Logs.

Figura 10.10 Menu de Logs.


juntamente com o usuário que a realizou, e a data e hora em que a operação foi realizada. A

163

Ambas as opções são similares às do SGCI. A primeira exporta os logs em um arquivo legível similar ao mostrado na figura 10.11, e a segunda remove todos os registros do sistema.

Figura 10.11 Logs do SAEC.

Operadores No SAEC, os operadores têm um papel um pouco diferente dos operadores do SGCI. Aqui, cada operador é responsável por administrar tarefas relacionadas à instituição a qual ele pertence. Futuramente será apresentada a área de Operação de Instituições, onde cada


tarefa dos operadores será melhor detalhada.

164

No menu “Operadores”, visto na figura 10.12, é possível listar todos os operadores já registrados e registrar novos operadores.

Figura 10.12 Menu Operadores.

A listagem é simples e apresenta os principais dados de cada operador, conforme visto na figura 10.13.

Figura 10.13 Listagem de operadores.

O registro de operadores é feito através de um formulário simples, diferente do SGCI, onde é necessário criar o usuário e depois atribuir o seu papel. No momento do registro, é necessário informar a instituição que esse operador vai operar, seu username (Nome de usuário) e senha, além de algumas informações pessoais simples, como nome e e-mail. O formulário de registro de um operador pode ser visto na figura 10.14.


Figura 10.14 Registro de operador.

165

HSM Esse menu também guarda muitas semelhanças com o SGCI. Aqui é possível registrar um HSM, onde ficam armazenadas as chaves da Autoridade Certificadora. O formulário de registro de HSMs pode ser visto na figura 10.15.

Figura 10.15 Registro de HSM.

Para registrar um HSM, é necessário informar o ID da engine. Como já visto no nosso caso, esse ID é “openhsmd”, o arquivo da engine, o nome da chave da AC no HSM, o IP onde o HSM se encontra e a sua porta. Nesse exemplo, a porta não foi provida. Quando isso acontece, a


porta padrão (5000) é utilizada.

166

Requisição Esse menu é útil somente enquanto o certificado da AC do SAEC não é emitido. Clicando nele, o administrador consegue baixar a requisição de certificado da AC gerada no momento de instalação do SAEC.

Modelos O menu de modelos permite que o administrador configure modelos (templates) para a emissão de LCRs e Certificados, conforme visto na figura 10.16.

Figura 10.16 Menu de Modelos.

Para a configuração de um modelo de emissão de LCRs, é necessário informar se a emissão é automática ou não, a validade em dias de cada LCR emitida e o algoritmo de hash usado em sua assinatura. O formulário de configuração de modelo de LCR pode ser visto na figura 10.17.

Figura 10.17 Configuração de modelo de LCR.

Para a configuração de um modelo de emissão de certificados, são necessários ainda menos dados – somente a validade em dias de cada certificado emitido e o algoritmo de hash usado na sua assinatura digital, como pode ser visto na figura 10.18.

Figura 10.18 Configuração de modelo de Certificado.

LCR O menu de LCR permite a operação de duas ações: emissão de LCRs e o Download. O menu

Figura 10.19 Menu de LCR.


de LCR pode ser conferido na figura 10.19.

167

A emissão é uma operação simples, que só exige a autenticação do usuário administrador. O download de LCRs pode ser feito de duas maneiras diferentes: 11 O administrador pode escolher fazer o download da última LCR emitida, não necessitando informar nenhum dado; 11 Na segunda maneira, o administrador pode escolher procurar por LCRs emitidas em um determinado período de tempo; assim, ele é requisitado a selecionar a data inicial e final do período de tempo desejado. A tela de downloads de LCRs pode ser vista na figura 10.20.

Figura 10.20 Menu de LCR.

Certificados O menu de Certificados permite que o administrador visualize todos os certificados emitidos


por aquele SAEC. A lista de certificados pode ser vista na figura 10.21.

168

Para cada certificado emitido, o administrador pode realizar a operação (ação) de download, representado pelo ícone da seta para baixo, e a de revogação, representada pelo ícone do x. A operação de download simplesmente inicia a transferência do arquivo do certificado. A operação de revogação encaminha o administrador para outra tela, visível na figura 10.22, onde o ele precisa informar o motivo da revogação e autenticar-se novamente.

Figura 10.21 Listagem de Certificados emitidos.

Figura 10.22 Tela de revogação de certificados.

Backup O menu de Backup, como o próprio nome sugere, é a área do sistema onde o administrador consegue gerar e recuperar backups. Similarmente ao SGCI, um backup no SAEC é uma imagem do sistema como um todo. A figura 10.23 mostra o menu em mais detalhes.


Para a geração de backups, é necessário informar uma senha que cifrará o arquivo contendo

Figura 10.24 Tela de geração de Backup.

Da mesma forma, quando o administrador deseja restaurar um backup no SAEC, ele também precisa informar a senha, dessa vez para decifrar o arquivo, conforme visto na figura 10.25.


o estado atual do SAEC. A tela de geração de backup pode ser vista na figura 10.24.

169


Estatísticas Finalmente, o menu de Estatísticas provê dados informativos sobre o funcionamento do SAEC. Nele, é possível visualizar os números do sistema desde o momento em que ele foi instalado (Total) e em um determinado período de tempo, conforme visto na figura 10.26.

Figura 10.26 Menu de Estatísticas.

Ambas as operações apresentam uma tela similar à vista na figura 10.27. Nela é possível identificar a quantidade de certificados emitidos, a quantidade de certificados revogados, e


a quantidade de certificados que continuam ativos.

Figura 10.27 Menu de Estatísticas.

Operação de Instituições Similar à área administrativa do SAEC, a área de Operação de Instituições também é destinada a configurações; porém, nessa área somente são feitas configurações relativas à Instituição. Ou seja, que afetam somente os usuários vinculados à ela. Quem realiza todas as operações nessa área é o usuário que foi registrado na área de administração. Porque o usuário operador de instituição tem menos autoridade que o administrador do SAEC, a tela inicial dessa área é bem mais simples, conforme visto na figura 10.28.

170

Figura 10.28 Tela inicial da área de Operação de Instituições.

Aqui podem ser realizadas operações relativas somente a dois campos do SAEC: 11 Modelos; 11 Certificados.

Modelos Nesse menu, o usuário consegue alterar o modelo de certificados a serem emitidos para usuários de sua instituição. A tela de configuração de modelos é mais complexa do que a apresentada na área administrativa, uma vez que lá somente são feitas as configurações básicas, como a validade, que não pode ser maior do que a validade do certificado da AC do SAEC. A configuração de modelos de certificados na área de Operação de Instituição é bastante

Figura 10.29 Configuração de modelo de certificados.

Certificados Esse menu é idêntico ao da área administrativa. Nele o usuário operador consegue listar todos os certificados emitidos para usuários de sua instituição, bem com fazer o download desses e realizar a sua revogação. Para mais informações, consulte as figuras 10.21 e 10.22,


similar à já vista no SGCI, como pode ser observado na figura 10.29.

na seção de Certificados da área Administrativa. 171

172


Bibliografia 11 HOUSLEY, R.; POLK, T. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. John Willey & Sons. 11 HOUSLEY, R. et all. RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF, 2008. 11 IDALINO, T. B.; SILVÉRIO, A. L. Automating certificate issuance through federations. Não publicado, 2013. 11 MARTINA, J. E. Projeto de um Provedor de Serviços Criptográficos Embarcado para Infraestrutura de Chaves Públicas e suas Aplicações. Dissertação de Mestrado: Universidade Federal de Santa Catarina, 2005. 11 MOREIRA, E. Q.; FOSCARINI, E. D.; DA SILVA JUNIOR, G. C.; ALIXANDRINA, L. A. de O.; VIERA NETO, L. P. Federação CAFe: Implantação do Provedor de Identidade. Versão 1.0.0. Escola Superior de Redes (ESR), RNP, 2009. 11 MOULDS, R. Key Management for Dummies. 1 ed. Wiley Publishing, Inc. 11 RFC 3161 – Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). 11 SOUZA, T. C. S.; MARTINA, J. E.; CUSTÓDIO, R. F. Audit and backup procedures for Hardware Security Modules. In: I trust 8: Proceedings of the 7th symposium on Identity and trust on the Internet. 11 SOUZA, T. C. S.; MARTINA, J. E.; CUSTÓDIO, R. F. OpenHSM: An Open Key Life Cycle Protocol for Public Key Infrastructure’s Hardware Security Modules. In: Fourth European PKI Workshop: Theory and Practice (EuroPKI’07). 11 SCHNEIER, B. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2 ed. John Willey & Sons, 1995. 11 STALLINGS, W. Cryptography and Network Security: Principles and Practice. 4 ed. Pearson Education, 2005.

11 Página de projetos ASI-HSM: http://projetos.labsec.ufsc.br/openhsmd

Bibliografia

11 Página da Federação CAFe: http://portal.rnp.br/web/servicos/cafe

173

11 Página de projetos SAEC: https://projetos.labsec.ufsc.br/saec


11 Página de projetos SGCI: https://projetos.labsec.ufsc.br/sgci

174

Marcelo Carlomagno Carlos, Doutor pela Royal Holloway University of London. Jeandré Monteiro Sutil, Mestre pela Universidade Federal de Santa Catarina. Cristian Thiago Moecke, Mestre pela Universidade Federal de Santa Catarina. Jonathan Gehard Kohler, Mestre pela Universidade Federal de Santa Catarina. Dayana Pierina Brustolini Spagnuelo, Doutoranda da Univesité du Luxembourg. Revisor: Jean Everson Martina, Doutor pela Universidade de Cambridge. Sobre o LabSEC: LabSEC é o Laboratório de Segurança em Computação da Universidade Federal de Santa Catarina (UFSC). O LabSEC foi fundado em abril 2000 e faz parte do Departamento de Informática e de Estatística (INE) da UFSC. O laboratório tem por objetivo estudar, pesquisar, avaliar e implementar soluções na área de segurança em computação, e em particular: criptografia; assinatura digital; segurança em sistemas computacionais; infraestrutura de chaves públicas; e protocolos criptográficos.

LIVRO DE APOIO AO CURSO

O curso ICPEdu Introdução a Infraestrutura de Chaves Públicas e Aplicações apresenta como implantar um nidade de ensino e pesquisa, visando o seu uso para autenticação, assinatura digital e sigilo. Este curso capacita tura de Chaves Públicas Acadêmica em suas respectivas damentos necessários para o estabelecimento e manutenção dos principais componentes que constituem uma

ISBN 978-85-63630-47-6

9 788563 630476

ICPEdu Introdução a Infraestrutura de Chaves Públicas e Aplicações

Recommend Documents