Introducao a Infraestrutura de Chaves Publicas e Aplicacoes

Projetos especiais

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

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

Escola Superior de Redes RNP

Copyright © 2010, Escola Superior de Redes RNP

Produção Editorial Autores Marcelo Carlomagno Carlos Jeandré Monteiro Sutil Cristian Thiago Moecke Coordenação acadêmica

Jonathan Gehard Kohler

Derlinéa P. M. Miranda Design Revisão final

Tecnodesign

Pedro Sangirardi

Coordenação geral Luiz Coelho

Versão 1.0.1

Telefone/fax: (61) 3243.4340 E-mail: [email protected] Na Internet: esr.rnp.br

Esta obra é distribuída sob a licença Creative Commons: Atribuição e Uso Não-Comercial 2.5 Brasil

Grupos de Trabalho RNP (GT-RNP) O programa de Grupos de Trabalho (GTs) da RNP vem promovendo, desde 2002, a formação de parcerias entre a organização e grupos de pesquisa para o desenvolvimento e introdução de aplicações e serviços inovadores na rede operada pela RNP. A cada ano, a formação de novos GTs é iniciada com uma chamada de propostas à comunidade de pesquisa. As propostas recebidas são analisadas por uma comissão composta por representantes da RNP e da comunidade acadêmica, que seleciona os grupos a serem contratados. Os GTs selecionados desenvolvem seus projetos em etapas, implementando, inicialmente, um protótipo para a validação da aplicação ou serviço proposto. Numa segunda etapa, é implantado um serviço piloto, com vistas à sua possível disponibilização à comunidade de usuários. Desde a criação do programa de GTs, foram desenvolvidos diversos projetos de inovação envolvendo temas ligados a aplicações, middleware e redes. Alguns dos serviços atualmente disponibilizados pela RNP para a sua comunidade de usuários, como o fone@rnp, video@rnp e a federação CAFe resultam de trabalhos desenvolvidos por GTs e são exemplos de sucesso desse programa. Também resultado de projetos desenvolvidos no contexto do programa de Grupos de Trabalho, a Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEDU) tem como objetivo implantar um serviço de geração de certificados digitais, visando o seu uso para autenticação, assinatura digital e sigilo. Na implantação desta infraestrutura são aplicadas soluções técnicas, ferramentas e equipamentos desenvolvidos pelos Grupos de Trabalho GT-ICPEDU, do período 2003 a 2004, GT-ICPEDU2, do período 2004 a 2005, e GT-ICPEDU3, do período 2005 a 2006.


Introdução a Infraestrutura de Chaves Públicas e Aplicações Apresentação A Escola Superior de Redes da Rede Nacional de Ensino e Pesquisa (RNP) oferece cursos em tecnologia da informação e da comunicação para quem busca formação essencialmente prática. As atividades são situações-problema semelhantes às que são encontradas na prática do profissional de TI. Estas atividades exigem análise, síntese e construção de hipóteses para a superação do problema. A aprendizagem torna-se mais efetiva se contextualizada à realidade profissional. Os cursos propostos possuem 40 (quarenta) horas de duração divididas em 10 (dez) sessões de aprendizagem. Os participantes trabalham em grupo ou em duplas e cada um pode dispor de sua própria estação de trabalho. O material de ensino é composto de apostilas contendo slides comentados e roteiro de atividades práticas em laboratório.

Conhecimentos prévios \\Conhecimento

básico em informática;

\\Conhecimento

básico dos sistemas operacionais Windows e Linux.

Objetivos \\Adquirir

conhecimentos fundamentais de segurança em computação, tais como criptografia simétrica, assimétrica e funções de resumo criptográfico.

\\Adquirir

visão geral sobre o funcionamento de uma ICP e entidades envolvidas.

Ao final do curso o aluno terá aprendido a \\Utilizar

aplicações práticas que envolvem os conceitos aprendidos, como assinatura digital e servidor web seguro, entre outros.

\\Utilizar módulos criptográficos seguros, além de conhecer seu

funcionamento interno. \\Conhecer

as demandas de credenciamento e do dia-a-dia de uma Autoridade Certificadora.


Sumário Sessão de aprendizagem 1 Fundamentos de criptografia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Sessão de aprendizagem 2 Assinatura digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Sessão de aprendizagem 3 Infraestrutura de Chaves Públicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Sessão de aprendizagem 4 Servidor Web Seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Sessão de aprendizagem 5 SGCI – Conceitos e visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Sessão de aprendizagem 6 SGCI – Gerenciamento de Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Sessão de aprendizagem 7 Gerenciando o ciclo de vida de chaves criptográficas. . . . . . . . . . . . . . . . . . . 135 Sessão de aprendizagem 8 Utilizando o ASI-HSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Sessão de aprendizagem 9 Simulação de Credenciamento – etapa 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Sessão de aprendizagem 10 Simulação de Credenciamento – etapa 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Bibliografia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215


1 Sessão de aprendizagem 1 Fundamentos de criptografia Sumário da sessão Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Definições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Criptografia clássica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Criptografia moderna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Criptografia simétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Criptografia assimétrica I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Funções resumo (hash) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Assinatura digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Criptografia assimétrica II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Certificados digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Lista de Certificados Revogados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Formatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Atividade 1 – Cifrar o próprio nome utilizando o cifrador de César . . . . . . . . . . 24 Atividade 2 – Cifrar texto com o cifrador de Vigenere. . . . . . . . . . . . . . . . . . . . 24 Atividade 3 – Trocar mensagens sigilosas com a pessoa no computador ao lado. . 25 Atividade 4 – Criação e visualização de Certificados e LCRs. . . . . . . . . . . . . . . 25 Atividade 5 – Conversão de formatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10


Introdução

Introdução Criptologia Criptografia (kryptós: “escondido”; gráphein: “escrita”) Ocultar informação dos outros Legível apenas para o destinatário

Criptoanálise

Decodificar mensagens sem conhecer a chave secreta

Esteganografia Ocultar mensagens dentro de outras

Nesta primeira sessão de aprendizagem faremos uma revisão dos conceitos básicos da criptografia. Iniciaremos descrevendo o que é criptografia, passando pelos métodos clássicos e modernos, criptografia assimétrica, funções resumo e finalmente assinatura digital. Existem duas formas básicas de proteger informações de forma que pessoas não autorizadas não tenham acesso ao seu conteúdo.

A primeira delas é chamada de criptologia, que visa codificar e decodificar informações de forma que apenas as partes interessadas possam compreendêlas. A criptologia pode ser subvidida em criptografia e criptoanálise. O termo criptografia deriva das palavras kryptós, que significa “escondido”, e gráphein, que significa “escrita”. Portanto, a criptografia consiste de princípios e técnicas para transformar a informação de sua forma original para outra ilegível, de forma a proteger seu conteúdo do acesso de pessoas não autorizadas. A segunda é a esteganografia (do grego “escrita escondida”), que consiste na ocultação de mensagens dentro de outras. O princípio da esteganografia é ocultar a presença da mensagem, de forma que pessoas não autorizadas não detectem a existência desta mensagem. Um exemplo bastante comum é a utilização de imagens para a ocultação de textos. É importante destacar a diferença entre a criptografia e a esteganografia. A primeira oculta o conteúdo da mensagem, enquanto a segunda oculta a existência da mensagem. Pode-se também utilizar as duas técnicas simultaneamente, cifrando uma mensagem e depois ocultando a mensagem cifrada.

Definições Texto claro Texto cifrado Cifrar Decifrar Chave

Definições Antes de iniciar, devemos conhecer o significado de alguns termos que serão utilizados ao longo deste curso: \\Texto

claro – Texto original, não cifrado;

\\Texto

cifrado – Texto ilegível, não compreensível (exceto para o destinatário);

\\Cifrar

– Transformar texto plano em texto cifrado;

\\Decifrar

– Transformar texto cifrado em texto plano;

\\Chave

– Conjunto de dados utilizados para cifrar e decifrar.

Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 1

Criptografia 11

Criptografia

Uma forma bastante comum de utilização de criptografia é 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. Após isso, ele cifra sua mensagem utilizando esta chave compartilhada, e envia o texto cifrado 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 o conteúdo da mensagem. Quando Alice recebe a mensagem, ela utiliza a chave para decifrar o conteúdo e obter a mensagem original novamente.

Criptografia clássica

Criptografia clássica Transposição Original: help Cifrado: HLEP Substituição Original: help 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: Citale espartano (século V a.c.)

1. Escrever a mensagem de forma que as letras alternadas fiquem separadas nas linhas de cima e de baixo. 2. Escrever a mensagem cifrada colocando primeiro as letras da linha superior e depois as da linha inferior.

Seguindo estes 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 desta forma decodificar a mensagem, obtendo a mensagem original. Já a cifra de substituição é um método de criptografia que opera de acordo com um sistema pré-definido de substituição. Para definir de que forma são feitas as substituições, temos dois alfabetos: o original e o cifrado, que contém as letras em posições diferentes do original. Para realizar a cifragem a partir destes dois Fundamentos de criptografia

12

Escola Superior de Redes RNP alfabetos, simplesmente obtemos a posição da letra que desejamos cifrar no alfabeto original e substituímos pela letra que se encontra na mesma posição no alfabeto cifrado.

Criptografia clássica Cifradores monoalfabéticos Re-arranjo do alfabeto original 400.000.000.000.000.000.000.000.000 possibilidades

Alfabeto original abcdefghijklmnopqrstuvwxyz

Alfabeto cifrado JOFPZIDKTMAEGQCSLUVWYXHNBR

Texto original cifrar

Texto cifrado FTIUJU

Criptografia clássica Cifrador de César Texto original: escola superior de redes Texto cifrado: HVFROD VXSHULRU GH UHGHV Alfabeto original

abcdefghijklmnopqrstuvwxyz

Alfabeto cifrado

Por exemplo, utilizando os alfabetos original e cifrados do slide, para cifrar a palavra “cifrar”, obtemos inicialmente a posição da letra “c”, no alfabeto original, e substituímos pela letra localizada na mesa posição no alfabeto cifrado, no caso, a letra “F”. Depois fazemos o mesmo para o “i”, que é substituído por “T” e assim por diante. Os cifradores monoalfabéticos se caracterizam por utilizarem apenas um alfabeto cifrado; porém, é possível utilizar mais de um alfabeto cifrado, dando origem aos cifradores polialfabéticos. 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, basta realizar o procedimento oposto, obtendo a letra que estivesse três casas atrás.

Criptografia clássica

DEFGHIJKLMNOPQRSTUVWXYZABC

Cifrar E(x) = (x+3) mod 26 exemplo: E(0) = 3 mod 26 = 3 Decifrar D(x) = (x-3) mod 26 exemplo: D(3) = 0 mod 26 = 0

Cifrador de César

Cifrador de César


13

Embora não tenha resistido até a nossa época, uma vez que é facilmente quebrado hoje em dia, em sua época o cifrador de César se mostrou eficiente, apresentando vantagens bastante interessantes: \\É

simples de ser utilizado, mesmo manualmente, possibilitando rapidamente cifrar e decifrar uma mensagem;

\\Permite

utilizar diferentes chaves (deslocamentos, nesse caso), alterando o número de casas a serem deslocadas no alfabeto cifrado.

Contudo, este tipo de cifragem pode ser facilmente quebrado, uma vez que existem apenas 25 possíveis alfabetos cifrados. Uma simples variação deste método de cifragem, que ao invés de fazer deslocamentos, embaralhe o alfabeto cifrado, pode aumentar o número possível de alfabetos para 400.000.000.000.00 0.000.000.000.000 possibilidades.

Criptografia clássica Ataques Surgimento da criptoanálise Decifrar a mensagem sem conhecer a chave Origem árabe (século IX) Método para quebrar a cifra de substituição monoalfabética Análise de frequência

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 nesta área, a apenas séculos depois a Europa passou a utilizar criptoanálise, no século XV.

Os árabes criaram ataques sobre os cifradores monoalfabéticos utilizando o conceito de análise de Contar a frequência dos caracteres no texto frequência. Basicamente, a análise de frequência Digramas Trigramas consiste em contar o número de ocorrências de Origem na Europa apenas no século XV cada letra no texto cifrado, e comparar este 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 este método é a contagem de digramas e trigramas, que são sequências de dois e três caracteres que aparecem com mais frequência no texto cifrado e substituir pelos que aparecem com maior frequência em um texto claro comum. Apenas no Século XVI surgiram os principais criptoanalistas europeus, como Giovanni Soro, Philibert Babou e François Viete.

Fundamentos de criptografia

14


Tabela de frequências

Criptografia clássica Cifradores polialfabéticos Mais de um alfabeto cifrado Alfabeto original: abcdefghijklmnopqrstuvwxyz Alfabeto cifrado 1: JCHFZOTXRSLDWBPIVEAYGNMQUK

Alfabeto cifrado 2:

Com o intuito de eliminar ou ao menos dificultar os ataques por análise de frequência, surgiram os cifradores polialfabéticos, que utilizam mais de um alfabeto para cifrar um texto. Desta 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”.

PKBFLRIJEQTMYOAVHDCUXGSNZW

Texto original: hello Texto cifrado: XKDMP

a b c d ... z

Exemplo:

a A B C D ... Z

Quadrado de Vigenere

b B C D E ... A

Texto original: bazar

c C D E F ... B

Palavra-chave: chave

. . . . . ... .

Texto cifrado:

DHZVV

z Z A B C ... Y Um dos cifradores polialfabéticos mais famosos foi o de Vigenere, pelo fato de ser de fácil entendimento e implementação. A cifra de Vigenere utiliza 26 alfabetos para cifrar a mensagem.


15

O quadrado de vigenere trata-se de 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 utilizando esta técnica, vamos cifrar a palavra “bazar” e para isso utilizar 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”, que por sua vez define uma linha do quadrado que deve ser utilizada. Deve-se olhar para a linha que se inicia com a letra “c” e pegar o caractere desta 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, resultado no texto cifrado “DHZVV”. Note que a letra “a”, repetida no texto claro, é cifrada em dois caracteres diferentes, “H” e “V”.

ca

Enigma é uma máquina de criptografia com rotores, utilizada tanto para cifrar como para decifrar mensagens. Criada pelos alemães em 1918, tem fama de ter sido um equipamento que produzia cifras quase impossíveis de serem decifradas.

a azistas da

O código foi, no entanto, quebrado, e a informação contida nas mensagens produzidas por esta máquina é geralmente tida como responsável pelo fim da Segunda Guerra Mundial, pelo menos um ano antes da previsão de término. Um vídeo que demonstra o funcionamento desta máquina pode ser encontrado em: http://www. youtube.com/watch?v=DnBsndE1IkA

nBsndE1IkA

Máquina Enigma: 1918 – Alemanha. Utilizada pelos nazistas durante a Segunda Guerra Mundial, possuia três rotores


Cifradores de blocos 16 Escola Superior de Redes RNPDividem a mensagem em blocos de tamanho fixo (ex: 128 bits) Criptografia DES, moderna AES

Cifradores de blocos: Dividem a mensagem em blocos de tamanho fixo (ex: 128 bits). DES, AES A era da criptografia moderna começa realmente em 1949, com Claude Shannon. Neste 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 criptografia e criptoanálise. Em 1976 foi publicado, pelo governo americano, o algoritmo DES (Data Encryption Standard), aberto de criptografia simétrica, selecionado pelo NIST em um concurso. O DES foi o primeiro algoritmo de criptografia disponibilizado abertamente ao mercado. Vale lembrar que todos os algoritmos apresentados até agora, desde os clássicos, têm características simétricas, ou seja, para decifrar um texto, basta utilizar o procedimento oposto ao que foi realizado durante a cifragem dos dados. Entre os modernos algoritmos de criptografia simétrica, podemos agrupar duas principais categorias: \\Cifradores

de blocos – Dividem a mensagem em blocos de tamanho fixo durante a cifragem dos dados; entre os cifradores de blocos, podemos citar o DES e o AES.

\\Cifradores

Criptografia moderna Cifradores de fluxo Cifram cada dígito do texto plano por vez Utilizados com maior frequência quando é díficil conhecer o tamanho do texto plano RC4

de fluxo – Cifram cada dígito do texto plano por vez.

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


17

Criptografia simétrica

Criptografia simétrica Como distribuir as chaves de maneira segura? Como verificar se a mensagem não foi modificada? Como ter certeza de que a mensagem foi realmente enviada por quem diz tê-la enviado?

Ao finalizar este breve estudo sobre criptografia simétrica, podemos notar que, embora estes algoritmos sejam bastante eficientes, surgem algumas questões que não são tratadas por esta sub-área da criptografia. São elas: Como distribuir as chaves de maneira segura?

- Aprendemos até agora que para que uma comunicação entre duas ou mais partes seja realizada de forma segura, é necessário que ambas as partes conheçam previamente a chave. Porém, como fazer isso de maneira segura? Como garantir que apenas quem eu desejo vai conhecer esta chave? Como verificar se a mensagem não foi modificada? - Como podemos detectar se alguém não autorizado conseguiu ter acesso à mensagem e não a modificou antes que ela fosse entregue?

Criptografia assimétrica

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

Pública e Privada Confidencialidade

Criptografia assimétrica I

Par de chaves (pública e privada); Confidencialidade Com o intuito de responder as questões levantadas, além de outras questões, surgiu a Criptografia Assimétrica. A sua principal diferença em relação à Criptografia Simétrica é que utiliza 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.




18

Utilizando este 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 Par de chaves (de domínio público), e enviar para ela o texto cifrado. Alice, por sua vez, ao Pública e Privada receber a mensagem cifrada, utiliza sua chave privada para decifrar o conteúdo. Desta forma, podemos garantir que apenas Alice conseguirá decifrar o conteúdo Autenticidade da mensagem enviada por Beto.

Par de chaves (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 é o seguinte: Beto cifra o conteúdo da mensagem utilizando sua chave privada, e 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 utilizando a chave pública de Beto, podese 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 foi Beto quem criou a mensagem.

Criptografia assimétrica Diffie Hellman, 1976 Principais algoritmos RSA DSA

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.


19

Funções resumo (hash)

Funções resumo (hash) Procedimento ou função matemática para transformar um conjunto de dados em outro conjunto de tamanho fixo (resumo criptográfico) Impossível obter a mensagem original a partir do resumo criptográfico 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: Autenticidade – Busca garantir que a mensagem é autêntica, o autor da mensagem é realmente quem diz ser. Integridade – Permite verificar se a mensagem enviada é a mesma mensagem que foi recebida ou se sofreu alguma alteração. Irretratabilidade – O emissor não pode negar a autenticidade da mensagem. O processo de assinatura consiste em gerar o resumo criptográfico da mensagem e cifrar este 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.


Criptografia assimétrica II


Até este momento, conseguimos, através dos conhecimentos obtidos, solucionar três problemas com que nos deparamos: \\Distribuir

as chaves de maneira segura, o que foi resolvido através da utilização de criptografia assimétrica.

\\Detectar

se uma mensagem foi modificada, o que foi resolvido através da assinatura digital.

\\Ter

certeza de que a mensagem foi enviada por quem diz tê-la enviado, o que foi resolvido através do 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?

Certificados digitais

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

e a um indivíduo rio a uma chave

a chave privada

plicações

20


Um dos principais problemas da criptografia de chaves públicas é determinar quem possui a chave privada correspondente. Para solucionar este problema, foi proposto o uso de Certificados Digitais de Chaves Públicas, ou simplesmente certificados. Cada certificado 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: a. Ser um objeto puramente digital, para que possamos distribuí-lo e processá-lo automaticamente;

b. Deve conter informações sobre o detentor da chave privada; c. Deve ser fácil de determinar se o certificado foi recentemente emitido; d. Deve ser criado por uma entidade confiável ao invés do próprio usuário que detém a chave privada; e. Uma vez que uma entidade confiável pode criar vários certificados, inclusive para um mesmo usuário, deve ser fácil diferenciá-los; f. Deve ser fácil determinar se o certificado foi forjado ou se é genuíno; g. Deve ser à prova de violação, de modo que ninguém consiga alterá-lo; h. Deve ser possível verificar de forma imediata se alguma informação no certificado não é mais válida; i. Deve-se poder determinar para quais aplicações o certificado é válido. Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 1

21

Os certificados digitais x.509 apresentam em sua estrutura as características listadas nos itens acima; porém, os itens h e j não aparecem diretamente no conteúdo do certificado, pois são apenas apresentadas 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).

Lista de Certificados Revogados


Para que seja possível determinar se as informações contidas em um certificado digital são válidas em um determinado momento no tempo, foram criadas as listas de certificados revogados (LCR), que são listas emitidas periodicamente por uma Autoridade Certificadora ou por uma entidade para a qual foi delegada esta função, que contém a relação dos certificados que não são mais válidos.

Necessidade de tornar um certificado inválido Impossível apagar todas as cópias existentes de um certificado Objeto puramente digital Motivos para revogação Modificação de um certificado Comprometimento da chave privada Encerramento de uso

Uma LCR é um objeto digital, o que permite a distribuição, processamento e 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 data de sua emissão e outro com a data de expiração, a 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: \\A

atualização de dados nele contidos;

\\Comprometimento \\Cancelamento

do uso do certificado;

\\Comprometimento \\Entre

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

ExampleQuestion ::= SEQUENCE { trackingNumber INTEGER, }


da chave privada da Autoridade Certificadora;

outros motivos.

Formatos

Formatos

question

da chave privada;

IA5String

Os certificados digitais e as listas de certificados revogados são armazenados em arquivos, e sua estrutura, ou seja, a forma que seus dados são estruturados são definidos utilizando o Abstract Syntax Notation One (ASN.1). A ASN.1 é uma notação padrão que permite a representação, codificação/decodificação e transmissão de dados. Este formato possui uma

22

Escola Superior de Redes RNP série de regras para a descrição e codificação das estruturas de forma precisa, evitando ambiguidades. O exemplo apresentado no slide demonstra como uma lista de exercícios seria representada no formato ASN.1. ExampleQuestion ::= SEQUENCE { trackingNumber INTEGER,

question

IA5String

}

Formatos Base64 Codifica dados binários tratando-os numericamente em uma representação de base 64. Distinguished Encoding Rules (DER) Representa uma estrutura ASN.1 Privacy Enhanced Mail (PEM) Base64 com cabeçalhos

Formatos Exemplo de arquivo no formato PEM -----BEGIN CERTIFICATE----MIIDtTCCAp2gAwIBAgIJALgslSVdQqJEMA0GCSqGSIb3DQEBBAUAMEUxCzAJBgNV

Base64 é um método para 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 “=” é utilizado como um sufixo especial; a recomendação RFC 989 definiu que o símbolo “*” pode ser utilizado para delimitar dados codificados, mas não cifrados. O Distinguished Encoding Rules (DER) é uma sintaxe para 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, por exemplo. O Privacy Enhanced Mail (PEM) é uma proposta criada para prover segurança em e-mails através da utilização de criptografia de chaves públicas.

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


1 Sessão de aprendizagem 1 Fundamentos da criptografia Roteiro de atividades Tópicos e conceitos \\Cifradores \\Criptografica

Clássica

Competências técnicas desenvolvidas \\Entender

o funcionamento dos cifradores clássicos

Tempo previsto para as atividades \\20

minutos (resolução do exercício proposto)

24


Atividade 1 – Cifrar o próprio nome utilizando o cifrador de César

Escrever em um pedaço de papel o próprio nome e cifrá-lo utilizando o cifrador de César.

Atividade 2 – Cifrar texto com o cifrador de Vigenere

Cifre o texto abaixo utilizando o cifrador de Vigenere:

divert troops to east ridge

Utilize a tabela abaixo para a realização desta atividade, e como chave a palavra WHITE.


25

Atividade 3 – Trocar mensagens sigilosas com a pessoa no computador ao lado

Utilizar a documentação on-line do OpenSSL.

1. Utilizando OpenSSL através de linha de comando, gere uma chave RSA de 1024 bits (comando genrsa): openssl genrsa -aes128 -out private.pem 1024 2. Extraia a chave pública correspondente à chave gerada no passo 1: openssl rsa -in private.pem -pubout -out publica.pem 3. Envie a chave pública para a pessoa no computador ao lado; 4. Crie um arquivo texto contendo a mensagem; 5. Obtenha a chave pública da pessoa ao lado; 6. Cifre a mensagem de texto utilizando a chave pública da pessoa ao lado (comando rsautl): openssl rsautl -encrypt -inkey publica.pem -pubin -in file.txt -out file.cifrado 7. Envie para a pessoa ao lado; 8. Decifre a mensagem recebida, utilizando sua chave privada (comando rsautl): openssl rsautl -decrypt -inkey private.pem -in file. cifrado -out decrypted.txt

Atividade 4 – Criação e visualização de Certificados e LCRs

Utilize a documentação on-line do OpenSSL para consulta.

1. Utilizando OpenSSL através de linha de comando, gere um certificado auto-assinado: openssl req -new -x509 -newkey rsa:2048 -out autoassinado.pem -keyout chaveprivada.pem



26

2. Exiba o conteúdo do certificado na tela (comando x509): openssl x509 -in auto-assinado.pem -text –noout 3. Obtenha uma LCR de uma AC Comercial (http://crl.verisign.com); 4. Exiba o conteúdo da LCR na tela (comando crl); openssl crl -in Class3Commercial.crl -text -noout -inform DER

Atividade 5 – Conversão de formatos

Utilize a documentação on-line do OpenSSL.

1. Converta o certificado gerado na atividade 1 para o formato DER (comando x509): openssl x509 –in certificado.crt –inform PEM –out certificado_der.crt –outform DER 2. Converta a LCR obtida na atividade 1 para o formato PEM (comando crl): openssl crl –in lcr.crl –inform DER –out lcr_pem.crl –outform PEM


2 Sessão de aprendizagem 2 Assinatura digital Sumário da sessão Assinatura digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Colisão de hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Assinatura de longo prazo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Formatos de armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Legislação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Assinatura digital na ICP-Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 OpenDocument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 OpenXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Atividade 1 – Assinatura Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Atividade 2 – Assinatura digital de documento PDF. . . . . . . . . . . . . . . . . . . . . . 48 Atividade 3 – Assinatura Digital no OpenOffice . . . . . . . . . . . . . . . . . . . . . . . . . 49

28


Assinatura digital

Assinatura digital

Autenticidade/Não repúdio; Integridade Nesta sessão, exploraremos mais a fundo o tema “Assinatura Digital”. Uma vez Autenticidade/Não repúdio 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. Integridade A assinatura digital lembra, em muitos aspectos, a assinatura “de próprio punho”. Ela traz algumas propriedades importantes para os documentos eletrônicos: \\Integridade

– Permite verificar se o documento não foi alterado após a aplicação da assinatura;

\\Autenticidade

– Permite verificar se um documento realmente foi gerado e aprovado pelo signatário;

\\Não

repúdio – Impede que o signatário recuse a autoria/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 uma 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: \\Uma

pública, disponibilizada livremente, normalmente associada a dados pessoais do signatário através de um certificado digital;

\\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: 1. O assinante gera um resumo criptográfico da mensagem; 2. O assinante cifra o resumo com sua chave privada. Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 2

29

Este 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: 1. Tendo em mãos a chave pública, que ele sabe ser do remetente, o destinatário decifra a assinatura, obtendo o resumo. 2. Tendo em mãos a mensagem, gera novamente, de maneira independente, o resumo criptográfico da mensagem. 3. O destinatário compara os resumos obtidos no passo 1 e no passo 2: \\Se

ambos resumos são iguais, a assinatura é válida.

\\Se

os resumos não são iguais, a assinatura é inválida.

A propriedade de autenticidade é verificada no passo 1. Se uma outra chave privada, que não aquela associada à chave pública que o destinatário conhece, tivesse sido utilizada 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 irá 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 a 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á uma mudança sensível. Enquanto a verificação de uma assinatura de próprio punho depende da especialidade do grafoscopista, a verificação da autenticidade da assinatura digital, considerando-se o sigilo da chave privada, é puramente matemática e reside na confiança nos algoritmos utilizados. Outras diferenças tornam-se evidentes em uma análise mais minunciosa, como o fato da assinatura não fazer mais parte do documento, e sim ser algo que pode ser desanexado. Exploraremos algumas destas diferenças com mais atenção durante esta sessão.

Assinatura digital

30


Colisão de hash

Colisão de hash O hash tem tamanho fixo. Então existe um número finito de “hashes” Existem infinitas mensagens, portanto: 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, percebe-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. Eu posso escrever quantas mensagens eu desejar, potencialmente infinitas mensagens. Desta forma, torna-se evidente que necessariamente mais de uma mensagem vai Colisão de hash ter o mesmo hash. Este evento recebe o nome de colisão de hash, e é crítico para a confiança em uma assinatura digital.

A figura 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.


31

Colisão de hash Exemplo de colisão Ok, mas... funciona? Já existem exemplos de: Dois arquivos HTML diferentes, com mesmo hash MD5 Dois arquivos PostScript diferentes, com mesmo hash MD5 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: \\Dois

arquivos HTML – Páginas de duas empresas diferentes, com mesmo resumo MD5;

\\Dois

\\Uma

carta de recomendação;

\\Uma

concessão de acesso a dados sigilosos;

\\Dois

Colisão de hash Sem pânico É possível que duas mensagens tenham a mesma assinatura, mas... ... uma boa função de hash tem as seguintes características: É difícil, tendo h(m), achar m É difícil, tendo m1, encontrar m2 tal que h(m1)=h(m2) E mais difícil que encontrar uma colisão, é encontrar uma colisão “útil” Por quanto tempo você quer que a assinatura continue válida?

arquivos PostScript, com mesmo resumo MD5:

certificados digitais com mesmo resumo MD5.

Se você ficou assustado, o objetivo foi alcançado. Agora, iremos tentar tranquilizá-lo novamente. Como foi dito, ao mesmo tempo que a assinatura guarda semelhanças com a assinatura de próprio punho, ela tem suas particularidades que precisam ser bem compreendidas. Corretamente utilizada, ela dá garantias de segurança que podem ser consideradas 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: \\Boas

funções de hash, em geral, são virtualmente randômicas.

\\Uma

pequena modificação na entrada tem que causar uma enorme modificação na saída (ex: ~50% dos bits).

Com estas 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 digital

Assinatura de longo prazo


32

Toda assinatura digital vai expirar um dia


Toda assinatura digital vai expirar um dia Além da questão do algoritmo de hash, que pode um dia ficar vulnerável e desta 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 um certo intervalo de tempo). Para garantir a confiabilidade destas 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 sessã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 desta 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 estas 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 estes problemas não existiam.



Carimbo de tempo

33

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

Assinatura de longo prazo Utilizar carimbo de tempo para conservar a validade por longo prazo Antes da expiração da assinatura/carimbo anterior Utilizando algoritmos mais avançados

O carimbo de tempo pode ser feito sobre qualquer dado. Mas um dos usos mais comuns é a aplicação do carimbo de tempo apenas à assinatura digital, já que ancorando-a ao tempo, estará sendo ancorado todo o documento junto. Desta forma, o carimbo de tempo permite se ter certeza da existência de um documento em determinada data. Com esta garantia, caso o certificado do signatário venha a expirar, ou o algoritmo/hash da assinatura esteja comprometido, o carimbo garantirá que a assinatura ocorreu antes da existência destes 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 de tempo: \\A

aplicação de carimbo de tempo deve ser feita quando o carimbo de tempo anterior ou a assinatura ainda era 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/válida.

Assinatura digital



34

\\É

necessário que o carimbo de tempo utilize algoritmos melhores que os da própria assinatura, se o objetivo é proteger contra quebra de algoritmos.

\\É

necessário conservar também certificados da cadeia de certificação e listas

Utilizar carimbo de tempo para conservar a validade por longo prazo de certificados revogados válidos na data em que o carimbo de tempo foi emitido, para queda seja possível realizar todasanterior as verificações necessárias Antes da expiração assinatura/carimbo sobre a cadeia de certificação. Estes dados podem não estar mais disponíveis Utilizando algoritmos mais avançados no dia em que a assinatura for verificada, especialmente a longo prazo.

Formatos de armazenamento PKCS#7/CMS/CAdES ASN.1 RFCs:

RFC 3852 - Cryptographic Message Syntax (CMS) RFC 5126 - CMS Advanced Electronic Signatures (CAdES)

XML-DSig/XAdES XML Padrões W3S

Formatos de armazenamento 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 de 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 utilizado para a Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 2

35

representação de informações, pois permite a representação destas em uma sintaxe simples de ser interpretada 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 de tempo: \\CAdES,

baseado no CMS;

\\XAdES,

baseado no XML-DSig.

Legislação

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. Isto é 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 esta 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 ICPBrasil 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 nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento.

Assinatura digital

36


Assinatura digital na ICP-Brasil Conjunto Normativo – DOC-ICP-15: diz exatamente como deve ser a assinatura, para que ela seja válida na ICP-Brasil (eficácia jurídica) Baseado nos padrões XAdES e CAdES Propõe cinco formatos de assinatura digital para cada padrão

Assinatura digital na ICP-Brasil 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. Este conjunto normativo é baseado nos padrões CaDES e XaDES, ou seja, possui recursos que permitem a conservação a longo prazo das assinaturas digitais.

Assinatura digital na ICP-Brasil Formato AD-U

Existem 5 perfis de formatos de assinatura disponíveis, cada um adequado a determinadas situações.

Formato AD-U

Assinatura digital na ICP-Brasil

O AD-U, ou “Assinatura Digital de Uso Restrito” é 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 Formato AD-T tamanho mínimo para a assinatura.

Formato AD-T Na AD-T, a “Assinatura Digital Temporal”, insere-se um carimbo de tempo, ancorando a assinatura a uma data onde ela era válida.


37

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. Formato AD-R

Formato AD-R O AD-R é a “Assinatura Digital com Referências”. Adiciona referências sobre certificados e LCRs utilizados na assinatura, e coloca um carimbo de tempo sobre toda essa informação. Desta 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/LCRs. Permite que sejam validadas assinaturas a longo prazo, mesmo após a expiração/extinção das ACs, desde que AD-Ccom certificados e LCRs disponíveis para consulta. exista oFormato banco de dados

Formato AD-C O AD-C é a “Assinatura Digital Completa”. 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 de tempo, ancoradas ao momento em que os algoritmos envolvidos eram seguros. Desta forma, fica dispensado o banco de dados de certificados e LCRs.

Assinatura digital

Assinatura digital na ICP-Brasil 38


Formato AD-A

Formato AD-A Finalmente, o AD-A é o formato para “Assinatura Digital de Arquivamento”. É colocado um carimbo de tempo sobre todo o conjunto, utilizando 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 de 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 de tempo de arquivamento. Este processo, preferencialmente, deve ser automatizado.

OpenDocument

OpenDocument Formato proposto pela Sun XML Padrão aberto ISO/IEC 26300:2006 Assinatura digital Não existe assinatura digital no padrão v1.1 O software OpenOffice.org gera assinaturas XML-DSig Padrão v1.2 deve incorporar o padrão XadES, e eventualmente o BrOffice trará suporte ao padrão ICPBrasil

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 à XaDES, e o BrOffice trará suporte para a geração de assinaturas digitais no novo padrão da ICP-Brasil. Confira em: http://www.broffice.org/odf_1-2_suportara_assinatura_digital_ compativel_com_ICP-Brasil


39

OpenXML

OpenXML Formato proposto pela Microsoft XML Em fase final para se tornar padrão ISO/IEC DIS 29500 Assinatura digital 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

PDF Formato proposto pela Adobe Subconjunto da linguagem de programação PostScript: layout e gráficos Sistema de incorporação e substituição de fontes Sistema de armazenamento estruturado: com compressão de dados onde é adequado Formado por objetos: Arrays, Strings, Dicionários, Streams etc.

Assinatura digital 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. Iremos 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. Estes 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.

Assinatura digital

40


PDF

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 de PDF assinado

Exemplo de PDF assinado

PDF

Este é 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. Exemplo %PDF-1.7 6 0 obj << /Type /Catalog /Pages 5 0 R >> endobj 1 0 obj << /Type /Page /Parent 5 0 R /Resources 3 0 R /Contents 2 0 R >> endobj 4 0 obj <<

Exemplo

/Type /Font

/Subtype /Type1 /Name /F1 /BaseFont/Helvetica >> endobj 2 0 obj << /Length 53 >> stream BT /F1 24 Tf 1 0 0 1 260 600 Tm (Hello World)Tj ET endstream endobj 5 0 obj

<< /Type /Pages /Kids [ 1 0 R ] /Count 1 /MediaBox [ 0 0 612 792 ] >> endobj 3 0 obj << /ProcSet[/PDF/Text] /Font <> >> endobj xref

0000000228 00000 n 0000000424 00000 n 0000000145 00000 n 0000000333 00000 n 0000000009 00000 n trailer << /Size 7 /Root 6 0 R >> startxref 488 %%EOF

07 0000000000 65535 f 0000000060 00000 n

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


41

F

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.

emplo

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

PDF Exemplo

Localização da assinatura

Localização da assinatura

A assinatura digital de um PDF (PKCS#7) fica no interior do documento, dentro de um objeto do tipo dicionário. Este dicionário possui diversas informações sobre a assinatura, entre as quais se destacam: \\Contents

Assinatura digital

– Contém o conteúdo do PKCS#7, codificado em hexadecimal.


42

\\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.

PDF

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 é setado conforme o documento gerado. O hash é calculado a partir desse valor, de 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.

Múltiplas assinaturas

Múltiplas assinaturas É possível aplicar múltiplas assinaturas sobre um mesmo documento PDF, graças ao sistema de atualizações incrementais. Este sistema permite que se modifique um documento PDF, adicionando novas versões para objetos modificados, mantendo os objetos originais intactos. Isso é feito adicionando novas informações ao final do documento. Desta 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 ddados compreendidos no ByteRange não foram modificados, esta 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


43

assinaturas. O Adobe 9 considera múltiplas assinaturas válidas apenas se não for feita nenhuma outra modificação no documento (inclusão/remoção de dados). Uma assinatura em PDF pode ser de três tipos. Interessam especialmente dois deles:

PDF Tipos de assinaturas Assinatura de Certificação

\\Assinatura

Única Primeira assinatura aplicada ao documento Autor aprova o documento

Assinatura de Documento

Assinaturas simples Podem existir múltiplas assinaturas Podem indicar aprovação do conteúdo, compromisso etc.

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).

\\Assinatura

de documento – É a assinatura simples, podendo existir quantas assinaturas forem necessárias.

Ainda existe a assinatura de direitos de uso, usada para liberar funcionalidades extras no Adobe Reader. É utilizada por exemplo para permitir que o Adobe Reader assine um documento gerado no Adobe Acrobat.

Assinatura digital



44

2 Sessão de aprendizagem 2 Assinatura digital Roteiro de atividades Tópicos e conceitos \\Criptografia \\Assinatura

assimétrica

digital

\\OpenSSL \\Assinatura

digital em PDF e OpenDocument

Competências técnicas desenvolvidas \\Assinatura

digital através do OpenSSL, Adobe Reader e OpenOffice

Tempo previsto para as atividades \\90-120

minutos (resolução dos exercícios propostos e atividades em laboratório)


46

Atividade 1 – Assinatura Digital

Este exercício foi desenvolvido para ser realizado em duplas, que devem compartilhar uma máquina. Cada pessoa deve trocar SEU_NOME e OUTRO_ALUNO pelo seu nome e pelo nome do colega, respectivamente. O aluno deve iniciar a máquina virtual VMware do sistema operacional Linux Ubuntu, e logar utilizando login “icpedu” e senha “icpedu”. A senha para o comando sudo (executar comando como administrador do sistema) também é “icpedu”. Cada computador tem pré-instalada a aplicação OpenSSL. O exercício consiste em gerar e verificar manualmente uma assinatura digital. Note que o próprio OpenSSL tem comandos mais simples e diretos para a realização de assinaturas digitais, embora este exercício tenha como objetivo a fixação de cada etapa do processo de assinatura digital. Todos os comandos estão descritos em linhas deslocadas à direita. Procure entender a função de cada comando, associando o mesmo com o conteúdo visto em aula. Não execute os comandos sem entendê-los, e em caso de dúvida consulte o instrutor.

1. Gerando chaves RSA 1. Inicie o Terminal (Console), disponível na barra superior ou no menu Aplicações/Acessórios. 2. Cada aluno deve criar uma pasta chamada “s5a1_SEU_NOME”, e entrar nela: mkdir s5a1_SEU_NOME cd s5a1_SEU_NOME 3. Cada aluno deve gerar um par de chaves assimétricas RSA de 2048 bits com o comando openssl genrsa: openssl genrsa -out chave_SEU_NOME.key 2048 4. Extraia a chave pública para um arquivo separado chamado “chave.pub”: openssl rsa -in chave_SEU_NOME.key -pubout -out chave_ SEU_NOME.pub 2. Realizando uma assinatura 1. Crie um arquivo de texto simples com alguma mensagem, por exemplo: echo “Alguma mensagem” > mensagem_SEU_NOME.txt


47

2. Gere um resumo criptográfico SHA-1 do arquivo “mensagem_SEU_NOME.txt” com o comando “openssl dgst”, armazenando o mesmo no arquivo “hash.txt”: openssl dgst -sha1 -out hash_SEU_NOME.txt mensagem_SEU_ NOME.txt 3. Você pode visualizar o conteúdo do arquivo “hash_SEU_NOME.txt” com o comando cat: cat hash_SEU_NOME.txt 4. Cifre o hash com a chave privada gerada anteriormente e o comando openssl rsautl: openssl rsautl -sign -in hash_SEU_NOME.txt \-inkey chave_SEU_NOME.key -out assinatura_SEU_NOME.asc 5. Copie os arquivos “mensagem_SEU_NOME.txt”, “assinatura_SEU_NOME.asc” e “chave_SEU_NOME.pub” para a pasta do seu colega: cp mensagem_SEU_NOME.txt ../s5a1_OUTRO_ALUNO/ cp assinatura_SEU_NOME.asc ../s5a1_OUTRO_ALUNO/ cp chave_SEU_NOME.pub ../s5a1_OUTRO_ALUNO/ 3. Verificando a assinatura Cada aluno deve assumir o papel de verificador, na pasta do outro aluno. Lembrese de que ele apenas tem acesso à chave pública, e que exportamos no arquivo “chave_OUTRO_ALUNO.pub”, a mensagem (arquivo “mensagem_ OUTRO_ALUNO. txt”) e a assinatura (arquivo “assinatura_ OUTRO_ALUNO.asc”). 1. Decifre a assinatura com a chave pública e o comando openssl rsautl: openssl rsautl -verify -pubin -inkey chave_OUTRO_ALUNO. pub \ -in assinatura_OUTRO_ALUNO.asc Será exibido na tela o hash SHA-1 decifrado. 2. Utilize mais uma vez o comando “openssl dgst” para gerar o hash SHA-1 e verifique se é o mesmo obtido com o comando do passo anterior: openssl dgst -sha1 mensagem_OUTRO_ALUNO.txt

Assinatura digital


48

Atividade 2 – Assinatura digital de documento PDF

Um documento PDF chamado “ExemploAssinaturaDigitalPDF_distributed. pdf” está disponibilizado no desktop do usuário. Trata-se de um formulário PDF simples. Execute os seguintes passos:

1. Criar Chave Privada e Certificado 1. Acesse o menu Documentos/Configurações de Segurança; 2. Adicione um ID Digital, utilizando a opção “Criar um ID Digital” em “Novo arquivo PKCS#12”. 3. Salve o arquivo “PKCS#12” em um diretório conhecido (anote o local). Você vai precisar dele novamente. 2.

Assinando o arquivo 1. Abra o arquivo “ExemploAssinaturaDigitalPDF_distributed.pdf”; 2. Clique sobre a área de assinatura digital (com uma pequena marca vermelha no canto superior esquerdo); 3. Selecione sua identidade digital e assine o documento, informando sua senha; 4. Salve o arquivo com o nome “ExemploAssinaturaDigitalPDF_assinado.pdf”.

3. Verificando uma Assinatura 1. Abra o painel de assinaturas. Exiba detalhes da assinatura e do certificado buscando visualizar como estão representados os conceitos aprendidos na aula. Note que a assinatura é aceita como válida, pois o certificado que você acabou de criar é considerado confiável. 2. Verifique o arquivo “ExemploAssinaturaDigitalPDF_cristian.pdf” que está disponibilizado. Note que esta assinatura não é reconhecida, pois o signatário não é considerado confiável. Aprenderemos como confiar neste certificado na próxima sessão.


49

Atividade 3 – Assinatura Digital no OpenOffice 1.

Criar Chave Privada e Certificado openssl req -new -key chave_SEU_NOME.key -x509 -out certificado_SEU_NOME.pem openssl pkcs12 -export -in certificado_SEU_NOME.pem -inkey chave_SEU_NOME.key -out p12_MEU_NOME.p12 -name “SEU NOME”

2.

Importar Chave no Repositório NSS (Firefox) 1. Importe no Firefox: Edit/Preferences/YourCertificates/Import. 2. Crie arquivo no OpenOffice, e assine utilizando o menu Arquivo/Assinatura.

Assinatura digital



50

3 Sessão de aprendizagem 3 Infraestrutura de Chaves Públicas Sumário da sessão PGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 x.509 - ICP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Autoridades certificadoras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Autoridades de registro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Repositório. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 ACs Intermediárias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Certificação digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Caminhos de certificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Políticas de Certificação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 ICPEDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 ICP-Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Atividade 1 – Criar chave PGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Atividade 2 – Importar chave da pessoa ao lado. . . . . . . . . . . . . . . . . . . . . . . . 66 Atividade 3 – Trocar mensagens utilizando PGP . . . . . . . . . . . . . . . . . . . . . . . . 67

52


PGP

PGP Utiliza Criptografia de Chaves Públicas (assimétrica) para relacionar nome e e-mail de uma pessoa a uma Chave “Web of trust” Não utiliza o conceito de Autoridades Certificadoras Certificados são criados pelo próprio usuário Outros usuários “atestam” a veracidade do certificado

Na terceira sessão de aprendizagem, aprenderemos o que é a Infraestrutura de Chaves Públicas. Iniciaremos nossas atividades apresentando o PGP, uma alternativa ao formato x.509. Logo após será discutido em detalhes o padrão x.509, bem como todas as entidades, arquiteturas e outros itens que envolvem o conceito ICP. O Pretty Good Privacy (PGP) é um programa de computador que provê privacidade e autenticação através do uso de criptografia. Ele utiliza Criptografia de Chaves Públicas (assimétrica) para relacionar nome e e-mail de uma pessoa a uma chave.

Porém, o PGP não utiliza o conceito de Autoridades Certificadoras (terceira parte confiável que atesta a veracidade das informações contidas no certificado e o emite). Os certificados PGP são criados pelo próprio usuário. Para que seja possível ter certeza de que as informações contidas no certificado PGP são verdadeiras, outros usuários “atestam” a veracidade do certificado, assinando uma confirmação de que as informações são verdadeiras. A este conceito é dado o nome de “web of trust”.

x.509 - ICP

x.509 - ICP Conjunto de: Entidades Políticas Mecanismos criptográficos Técnicas de gestão Facilitar o uso de criptografia de chaves públicas Principais componentes Autoridades Certificadoras Autoridades de Registro 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 esta associação pode ser feita através dos certificados digitais. Aprendemos também que faz-se 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 PGP quem atesta esta relação são os outros usuários; já 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. Este 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 e outros atributos necessários. Este documento é chamado de Certificado Digital x.509 e representa o mais básico elemento de uma Infraestrutura de Chaves Públicas (ICP). Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 3

53

\\Uma

ICP é constituída por um conjunto de:

\\Entidades \\Políticas

– Pessoas, máquinas, servidores etc;

– Conjunto de normas e práticas que regem uma ICP;

\\Mecanismos \\Técnicas

criptográficos;

de gestão.

O objetivo principal de uma ICP é facilitar o uso de criptografia de chaves públicas, tendo como principais componentes: \\Autoridades

Certificadoras;

\\Autoridades

de Registro;

\\Repositório.

Autoridades certificadoras Composição de: Hardware Software Pessoas Responsáveis por: Emissão de certificados digitais Emissão de listas de certificados revogados Gerenciamento das informações dos certificados Verificação dos dados das requisições Delegar tarefas

Autoridades certificadoras

Emissão de certificados digitais

Autoridades certificadoras 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. Ao emitir um certificado, uma AC assegura que a entidade requisitante detém 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.

Emissão de certificados digitais

Infraestrutura de Chaves Públicas

dades certificadoras

são de listaEscola de certificados revogados Superior de Redes RNP

54

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 emisã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). Emissão de lista de certificados revogados

Autoridades de registro Composição de: Hardware Software Pessoas Atua por delegação de uma AC Responsáveis por: Verificar o conteúdo de requisições de certificados Solicitar revogação de certificados Podem atuar em uma ou mais ACs

Autoridades de registro

Aprovação de certificados

Autoridades de registro 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. A existência desta 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.

Aprovação de certificados


55

Repositório

Repositório

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.

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

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.

Relação entre os componentes ACs Intermediárias

Relação entre os componentes 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 isto são: \\Redução

da carga de trabalho sobre uma AC, fazendo com que a AC Raiz tenha que emitir um número menor de certificados, dividindo esta tarefa com outras ACs.

\\Facilitar

o crescimento de toda a estrutura da AC.

\\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.


56


ACs Intermediárias AC pode delegar a responsabilidade de emissão de certificados para uma ou mais ACs Intermediárias Redução da carga de trabalho sobre uma AC Facilita o crescimento Aumenta a abrangência (se necessário) Se a AC Raiz autorizar, uma AC Intermediária pode delegar a tarefa de emissão para outras ACs abaixo dela Se desejar, uma AC pode limitar o número de ACs abaixo dela

Cs Intermediárias

Certificação digital Por que confiar ? Certificado contém informações sobre o detentor da chave privada Emitido por uma entidade confiável Dados são verificados ICPs são auditadas Utilizam mecanismos que agregam: Integridade Autenticidade Não repúdio

\\Melhorar

a capacidade de tolerância a erros, uma vez que se uma AC Intermediária tiver problemas, apenas o que está abaixo desta 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 este fim.

Certificação digital Por que devemos confiar em toda esta 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: \\Os

certificados contêm informações sobre o detentor da chave privada;

\\Os

certificados são emitidos por uma entidade confiável, no caso, uma AC;


57

\\Os

dados apresentados pelo requisitante são verificados, e a forma como são verificados está disponível em documentos;

\\As

ICPs são auditadas.

\\Utilizam

mecanismos que agregam:

\\Integridade; \\Autenticidade; \\Não

repúdio.

Arquiteturas ICP Definem como as entidades de uma ICP estabelecem confiança Diversas possíveis arquiteturas AC Única Listas de confiança

Hierárquica

Arquiteturas ICP

Certificação cruzada Ponte

AC Única

As arquiteturas de ICPs surgiram para definir como as entidades de uma ICP estabelecem confiança entre elas. As arquiteturas mais utilizadas são: \\AC

Única

\\Listas

de confiança

\\Hierárquica \\Certificação

cruzada

\\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. A AC Única trata-se da 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.

AC Única


Neste 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.

as ICP

58


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. Desta forma, as ACs nesta arquitetura são organizadas na forma de árvore com um ponto comum de confiança chamado AC Raiz.

ca

Nesta 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.

Hierárquica

Caminhos de certificação

Caminhos de certificação Caminho entre um Certificado de Entidade Final e o Ponto de Confiança (AC Raiz) 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 Verificar o certificado 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. Este “caminho” são os certificados de ACs percorridas entre um Certificado de Entidade Final e o Ponto de Confiança (AC Raiz). Para considerar um certificado válido, devemos verificar cada certificado do caminho de certificação e todos eles devem ser válidos.

Pode-se 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:


\\Encadeamento

por nome;

\\Encadeamento

por identificador de chave.

Construção por nomes

Construção por nomes


59

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. Este 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 uma 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 AuthorityKeyIdentifier (AKID) e SubjectKeyIdentifier (SKID), identificadores únicos referentes às chaves dos certificados. Nestes identificadores, comumente são utilizados os resumos Construção porpública nomes e identificadores criptográficos da chave do detentor do certificado.de chave


Construção por nomes e identificadores de chave

A montagem do caminho de certificação utilizando o encadeamento por identificador de chave é realizada de forma semelhante a do encadeamento por nome, diferindo pelo fato de que a verificação se dá pelo valor do SubjectKey Identifier (SKID) e do AuthorityKeyIdentifier (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,

AuthorityCertSerialNumber [2] CertificateSerialNumberOPTIONAL } KeyIdentifier::=OCTETSTRING


60

Escola Superior de Redes RNP 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 utilizados 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

Caminhos de certificação Validação/Verificação do Caminho de Certificação Para cada certificado do caminho encontrado, verificar: Assinatura digital Validade Situação (revogado ou não) Extensão BasicConstraints Extensões críticas

Depois de construído o caminho de certificação, deve ser realizada a validação/verificação de todos os certificados do(s) caminho(s) encontrado(s). Para cada certificado do caminho encontrado, deve-se verificar: \\Assinatura

digital – Verificar se a assinatura digital do certificado é válida;

\\Data

de validade – Verificar se os certificados estão dentro do período de validade;

\\Situação

de revogação – Verificar se o certificado está revogado;

\\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, verificar se seu valor está sendo respeitado;

\\Restrições

de políticas – Verificar todas as restrições políticas aplicáveis ao certificado;

\\Restrições

de nomes – Verificar todas as restrições de nomes aplicáveis ao certificado;

\\Extensões

críticas – Reconhecer e processar todas as extensões críticas presentes no certificado;

Caso alguma das verificações acima falhe, o caminho deve ser considerado inválido, caso contrário o caminho pode ser aceito.


61

Políticas de Certificação

Políticas de Certificação Documentos que determinam as políticas e práticas que regem uma ICP Definem as condições em que uma ICP pode operar Declaração de Práticas de Certificação Descreve como a política é implementada dentro de uma AC Específica PC x DPC PC é um documento de mais alto nível 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 estes documentos que definem as condições em que uma ICP pode operar. Existem dois documentos principais dentro das políticas de uma ICP: \\Políticas

de Certificação (PC) – Definem em alto nível como uma política deve ser implementada;

\\Declaração

de Práticas de Certificação (DPC) – Descreve como a política é implementada dentro de uma AC Específica.

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

ICPEDU 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 Uso acadêmico Autenticação Desenvolver cultura em certificação digital Treinamento Pesquisa Aplicações

ICPEDU O projeto ICPEDU é 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 deste projeto: \\Uso

acadêmico – Viabilizar o uso acadêmico de certificação digital;

\\Autenticação

– Permitir o uso de certificação digital para autenticação de pessoas e equipamentos dentro das instituições;

\\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;

\\Treinamento \\Pesquisa

– Capacitar pessoas na área de ICP;

– Desenvolver pesquisa na área;

\\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.


62


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 6 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).

ICPEDU Histórico 2003 / 2004 SGCI

2005

HSM

2006

Piloto AC Raiz

2007

Serviço experimental (6 instituições)

2008 / 2009

Implantação Aprimoramentos

As atividades de gerência da ICPEDU são divididas em grupos para facilitar sua implantação. São eles:

ICPEDU

\\Comitê Gestor

– Responsável por aprovar políticas e a criação de ACs;

Grupos Comitê Gestor

\\Autoridade

Aprovar políticas Aprovar criação de ACs

Autoridade de Gerência de Políticas (AGP) Analisar políticas das instituições

GOPAC

AC Raiz AC Correio

GOPAR

AR Raiz

de Gerência de Políticas (AGP) – Responsável por analisar políticas das instituições em credenciamento;

\\GOPAC

ICPEDU

– Grupo responsável pela operação da AC Raiz;

\\GOPAR

– Grupo responsável pela operação da AR Raiz.


63

ICP-Brasil

ICP-Brasil Conjunto de entidades, padrões técnicos e regulamentos elaborados para suportar um sistema criptográfico com base em certificados digitais Medida Provisória 2.200-2, de 24 de agosto de 2001 Exemplos de ACs credenciadas Caixa Econômica Federal CertiSign Serasa Serpro 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: \\Caixa

Econômica Federal;

\\CertiSign; \\Serasa; \\Serpro; \\Receita

Federal;

\\Presidência

da República.

ICP-Brasil Exemplos de uso Sistema de Pagamentos Brasileiro (SPB) Autenticação Tramitação e assinatura eletrônica de documentos oficiais Assinatura de contratos Assinatura de documentos Internet banking Automação de processos do Poder Judiciário Declaração de Imposto de Renda


Os certificados ICP-Brasil podem ser utilizados para vários fins. Veja alguns exemplos de uso: \\Sistema

de Pagamentos Brasileiro (SPB);

\\Autenticação

em sistemas;

\\Tramitação

e assinatura eletrônica de documentos oficiais;

\\Assinatura

de contratos;

\\Assinatura

de documentos;

\\Internet

banking;

\\Automação

de processos do Poder Judiciário;

\\Declaração

de Imposto de Renda.



64

3 Sessão de aprendizagem 3 Infraestrutura de Chaves Públicas Roteiro de atividades Tópicos e conceitos \\ ICP \\Criptografia

Assimétrica

Competências técnicas desenvolvidas \\Entender

o funcionamento das ICPs


minutos

66


Atividade 1 – Criar chave PGP

Sequência de passos: 1. Abra a máquina virtual Ubuntu (usuário: icpedu; senha: icpedu); 2. Execute o software Seahorse: Menu Applications -> Acessories -> Password and Encryption Keys; 3. Crie a chave PGP: Menu Key -> Create New Key -> PGP Key; 3.1. Entrar com nome e senha -> create; 3.2. Criar senha -> ok; 4. Publique a chave criada, clicando com o botão direito na chave -> Sync and Publish.

Atividade 2 – Importar chave da pessoa ao lado 1. Acesse o menu Remote, opção Find Remote Keys; 2. Digite o nome do colega ao lado; 3. Importe a chave clicando em Import; 4. Confie na chave da pessoa: 4.1. Na tela principal, selecione a aba Other Collected Keys; 4.2. Clique com o botão direito no nome -> Properties; 4.2.1. Clique na aba Trust; 4.2.2. Marque: “I Have checked that keys belongs to NOME DA PESSOA”; 4.2.3. Clique em Sign This Key; fazendo isso, você estará atestando que este certificado é realmente da pessoa que ele indica ser. 5. Visualize as pessoas que confiam nesse certificado: 5.1. Selecione a aba Trusted Keys; 5.2. Clique com o botão direito no nome e selecione a opção Properties; 5.3. Selecione a aba Trust, onde existe uma lista das pessoas que confiam no certificado.


67

Atividade 3 – Trocar mensagens utilizando PGP 1. Crie um documento de texto e envie assinado para o colega ao lado: 1.1. Crie um arquivo de texto; 1.2. Clique com o botão direito do mouse no arquivo e selecione Sign; 1.3. Envie para o colega ao lado (pode ser via e-mail, pendrive etc.); 2. Crie um documento de texto e envie cifrado para o colega ao lado: 2.1. Crie um arquivo de texto; 2.2. Clique com o botão direito do mouse no arquivo e selecione Encrypt; 2.3. Pode-se selecionar também a opção de assinar o conteúdo, marcando uma caixa de seleção na parte inferior da janela; 2.4. Envie para o colega ao lado (pode ser via e-mail ou pendrive, entre outros).




68

4 Sessão de aprendizagem 4 Servidor Web Seguro Sumário da sessão SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Em quem você confia? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Cadeia de certificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 IIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Atividade 1 – Configuração de Servidor Apache SSL. . . . . . . . . . . . . . . . . . . . . 80 Atividade 2 – Configuração de Servidor IIS SSL . . . . . . . . . . . . . . . . . . . . . . . . 83 Atividade 3 – Configuração de Servidor Apache SSL com autenticação do Cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

70


SSL/TLS

SSL/TLS

A sigla SSL vem de Secure Sockets Layer. Traduzindo para o português, algo como “Camada de Sockets Seguros”.

SSL Secure Sockets Layer

Camada de Sockets Seguros

TLS Transport Layer Security

Segurança de Camada de Transporte

TLS é o sucessor do SSL TLS 1.0 ~ SSL 3.0

Versão mais recente: TLS 1.2 RFC 5246

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. SSL e TLS foram desenvolvidos com dois objetivos em especial, que são:

SSL/TLS Objetivos Autenticação

Autenticação

Normalmente unidirecional Mas pode prover autenticação bidirecional

Sigilo

A comunicação entre cliente e servidor não pode ser compreendida por alguém que esteja ouvindo o tráfego de dados

Unidirecional: Cliente 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). Bidirecional: Cliente 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. Iremos analisar com mais detalhes o processo de autenticação unidirecional, que é o mais utilizado atualmente.


Etapa 1

71

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

SSL/TLS Cliente inicia handshake, informando ao servidor RNc (número randômico) sua \\

lista de algoritmos criptográficos suportados; \\Servidor

responde: RNs (outro número randômico), e seus algoritmos

Etapa 2criptográficos escolhidos dentre os informados pelo cliente.

Etapa 2 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.

Servidor Web Seguro

SSL/TLS Escola Superior de Redes RNP

72

Etapa 3

Etapa 3 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 este 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 deste momento, cliente e servidor conhecem PMS, mas um observador que monitore a comunicação não terá como obter este valor, pois não tem a chave privada associada à chave pública utilizada na cifragem dos dados.

SSL/TLS

Cliente e servidor então geram uma chave simétrica Master Secret (MS), utilizando RNc, RNs e PMS. Esta é a chamada chave de sessão.

Etapa 4

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


73

Desta forma, se encerra o processo de handshake, e a comunicação passa a ocorrer de 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). Desta 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. Desta forma, o SSL/TLS utiliza o melhor dos dois modelos de criptografia.

SSL/TLS Aspectos gerais Certificado auto-assinado X ICP Confiança no certicado x Confiança na(s) Autoridade(s)? Cultura do “Cadeado fechado” = “Site seguro” Common Name (CN) deve conter o hostname do servidor Demais dados devem ser definidos de acordo com a política da AC Variações EV-SSL 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 auto-assinados para a identificação de servidores. Isto elimina toda a confiabilidade dada por uma ICP, limitando a confiabilidade na segurança do próprio servidor. O usuário terá que 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: A conexão está cifrada para terceiros que eventualmente estejam “escutando”; 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 da máquina. Este é 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

Servidor Web Seguro

74

Escola Superior de Redes RNP conteúdo”. Por exemplo, um certificado com CN “*.rnp.br” poderia ser utilizado 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. Estes 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?

Em quem você confia? Softwares vem com ACs pré-instaladas: você confia no software, confia nelas! Certificados pré-instalados em software: Microsoft Auditoria WebTrust ou equivalente; Sem custo (auditoria é cobrada pela WebTrust).

Firefox

Conformidade com algumas das políticas aceitas pela Mozilla 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 destes softwares para todos os fins. O Windows e Firefox, por exemplo, tem ACs que fornecem certificados gratuitos, mediante validação apenas do e-mail (AC Correio). Uma AC deste 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 destes softwares como um repositório confiável de ACs para validar assinaturas digitais é uma atitude completamente incorreta.


ertificação

75

Cadeia de certificação É 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 num 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 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.).

Apache Servidor web responsável por 47.73% dos sites da internet Disponível para diversas plataformas, incluindo: Windows Linux *BSD MacOS Software livre

Servidor Web Seguro

Apache 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 detrás de aproximadamente 48% dos sites da internet (outubro de 2007). É um software livre, com licença própria pouco restritiva, disponível para as mais diversas plataformas, inclusive Windows, Linux, BSDs, MacOS.

76


A configuração do Apache é baseada em um ou mais arquivos de configuração.

Apache Configuração

No caso do Ubuntu, a configuração é distribuída entre diversos arquivos, correpondendo a módulos e hosts hospedados na máquina.

Em geral, um arquivo chamado apache.conf ou httpd.conf no diretório /etc, além de arquivos incluídos neste primeiro. No Ubuntu Linux 8.04: /etc/apache2/apache2.conf /etc/apache2/sites-enabled/* /etc/apache2/mods-enabled/* /etc/apache2/ports.conf Existem 1000 maneiras de preparar o Apache; invente uma! Ativar módulo SSL: sudo a2enmod ssl

Na 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.

Um VirtualHost é um domínio hospedado no servidor web Apache. A configuração básica de um VirtualHost foge ao escopo deste curso, e por isso fornecemos um modelo de arquivo de configuração já preenchido para ser utilizado. Estes são os campos de configuração adicionados a um VirtualHost para ativar o uso de SSL: \\SSLEngine

ativa o SSL no VirtualHost;

\\SSLCerfiticateFile

indica o certificado do servidor;

\\SSLCertificateKeyFile

indica o local onde a chave privada está armazenada;

\\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 desta 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.

VirtualHost SSL; Configuração

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


Importante: O gerenciamento de múltiplos hostnames em um mesmo IP (ex: VirtualHosts do Apache) é feito na camada de Aplicação. SSL não “vê” isso.

77

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 utilizar múltiplos hosts SSL num mesmo IP/porta. Possíveis soluções incluem: \\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;

\\Distribuição

dos hosts em portas distintas, diferentes da padrão (443): Compromete usabilidade, o usuário terá que digitar além do endereço a porta de acesso. Por exemplo, http://site2.rnp.br:444;

\\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.

Apache Cuidados com a chave A chave privada deve ser armazenada com sigilo. Somente o root (Administrador) deve ter acesso.

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 chmod -R 600 /etc/apache2/ssl/private/* restrito ao usuário root. A remoção da cifragem da É possível deixar a chave decifrada, ou seja, “sem senha é uma opção adotada por muitos senha”. Mas isso não é recomendável. administradores. Se a chave for mantida cifrada, uma openssl rsa -in chave.key -out chave.pem 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 chown -R root: /etc/apache2/ssl/private

Servidor Web Seguro

78


mau uso. Esta 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 um controle rígido de qualidade da segurança dos scripts e códigos.

IIS Servidor web responsável por 36.63% dos sites de internet Em forte crescimento Disponível para: Windows Server *, Windows XP Pro; Software proprietário

IIS Internet Information Services (IIS) é um software para serviço de páginas web desenvolvido pela Microsoft. Segundo a Netcraft, é responsável por cerca de 37% dos sites da internet, e apresenta forte expansão (outubro de 2007). É um software proprietário e está disponível para diversas versões do sistema operacional Windows. A instalação de SSL no IIS é bastante simples e intuitiva, realizada toda por interface gráfica.

IIS Configuração “Existe uma maneira de preparar o IIS. Não invente!” Windows XP: Painel de Controle, Ferramentas do Sistema, Internet Information Services Windows 2003 Server: Menu Iniciar, Todos os Programas, Ferramentas Administrativas, Gerenciador dos Serviços de Informação da Internet Toda a configuração é feita por ambiente gráfico Para que o servidor disponibilize os certificados da cadeia, eles precisam apenas estar instalados no repositório do Windows

Mas para alcançar a mesma funcionalidade provida pela linha SSLCertificateChainFile da configuração do Apache, o procedimento é um pouco menos claro. Para isso é necessário apenas instalar os certificados apropriadamente no repositório do Windows, o que pode ser feito através da ferramenta mmc (Menu Iniciar/Executar/mcc). O exercício prático a seguir demonstrará esta configuração.


4 Sessão de aprendizagem 4 Servidor Web Seguro Roteiro de atividades Tópicos e conceitos \\ SSL \\ Apache \\ IIS

Competências técnicas desenvolvidas \\Configuração

de Servidor Apache e IIS, com utilização de SSL, no contexto da ICPEDU.


minutos (resolução dos exercícios propostos e atividade em laboratório).


80

Atividade 1 – Configuração de Servidor Apache SSL

O aluno deve iniciar a máquina virtual VMware do sistema operacional Linux Ubuntu, e logar utilizando login icpedu e senha icpedu. A senha para o comando sudo (executar comando como administrador do sistema) também é icpedu. Cada computador tem pré-instalada a aplicação Apache 2. O exercício consiste em configurar o site padrão com SSL, conforme o roteiro abaixo. Todos os comandos estão descritos em linhas com tipologia específica. Procure entender a função de cada comando, associando o mesmo com o conteúdo visto em aula. Não execute os comandos sem entendê-los, e em caso de dúvida consulte o instrutor.

1. Preparar Apache2 para uso do SSL 1. Ativar módulo SSL: sudo a2enmod ssl 2. Gerar chave e requisição de certificado 1. Criar diretório para armazenar chaves e certificados: sudo mkdir /etc/apache2/ssl sudo mkdir /etc/apache2/ssl/cert sudo mkdir /etc/apache2/ssl/private 2. Criar chave privada: openssl genrsa -des3 -out localhost.key Será solicitada uma senha. Utilize preferencialmente a senha icpedu. A senha deve ser anotada, pois será necessária posteriormente. 3. Gerar requisição de certificado: openssl req -new -key localhost.key \ -out localhost.csr Sugerimos os seguintes dados (só não mude os dados marcados como obrigatórios): Country Name: BR (obrigatório – exigência da AC) State or Province Name: DF (obrigatório – exigência da AC) Locality Name: Brasilia (NUNCA use acentos!)


81

Organization Name: RNP (obrigatório – exigência da AC) Organization Unit Name: ICPEDU Common Name: localhost (obrigatório – hostname da máquina) Email adress: Seu e-mail Challenge password: não insira nada (obrigatório) Optional Company Name: não insira nada 4. Mover chave para diretório seguro: sudo mv localhost.key /etc/apache2/ssl/private sudo chmod 600 /etc/apache2/ssl/private/* sudo chown -R root: /etc/apache2/ssl/private 3. Assinar certificado utilizando a AC SSL 1. Uma mini-ICPEDU de treinamento está disponível na pasta /home/icpedu/ ICPEDU_Treinamento da máquina virtual. Esta ICP tem a seguinte estrutura: AC Raiz Treinamento

AC RNP Treinamento

AC SSL Treinamento 2. Vamos assinar um certificado sob a AC SSL Treinamento. Para isso utilize o seguinte comando OpenSSL: cd /home/icpedu/ICPEDU_Treinamento openssl ca -config ACSSL/openssl.cnf \ -out \ ../localhost.cer \ -infiles ../localhost.csr 3. Após verificar os dados, confirme (y) a emissão do certificado. 4. Copie o certificado para a pasta /etc/apache2/ssl/cert/. sudo cp ../localhost.cer /etc/apache2/ssl/cert 5. Você precisará de um arquivo que contém todos os certificados da cadeia da ICP concatenados, em formato PEM. cat ACRAIZ.pem ACRNP.pem ACSSL.pem > ACSSL_cadeia.pem 6. Copie este arquivo para o diretório /etc/apache2/ssl/cert/: sudo cp ACSSL_cadeia.pem /etc/apache2/ssl/cert

Servidor Web Seguro


82

4. Configure VirtualHost no Apache 1. Crie arquivo de configuração (default-ssl) para VirtualHost SSL, baseando-se no arquivo /etc/apache/sites-available/000-default e adicionando os parâmetros de configuração SSL descritos no curso: sudo cp /etc/apache2/sites-available/default\ /etc/apache2/sites-available/default-ssl sudo gedit /etc/apache2/sites-available/default-ssl 2. Adicione as seguintes informações dentro do VirtualHost: SSLEngine On ServerName localhost SSLCertificateFile /etc/apache2/ssl/cert/localhost.cer SSLCertificateKeyFile /etc/apache2/ssl/private/localhost. key SSLCertificateChainFile/etc/apache2/ssl/cert/ACSSL_ cadeia.pem 3. Altere o endereço IP do VirtualHost de * para *:443: NameVirtualHost *:443 4. Crie um link simbólico para o arquivo no diretório /etc/apache2/sites-enabled: sudo ln -s /etc/apache2/sites-available/default-ssl \ / etc/apache2/sites-enabled 5. Reinicie o Apache. Será solicitada a senha da chave privada. sudo apache2ctl restart 5. Testando o resultado 1. Teste no navegador Firefox da máquina virtual o acesso ao site configurado com SSL (https://localhost). O navegador deve exibir uma página de erro, informando que o certificado não é confiável. Veja os detalhes do certificado, e verifique se a cadeia de certificação está corretamente exibida. 2. Instale o certificado da AC-Raiz ICPEDU Treinamento como confiável para fim de autenticação de sites no Firefox. Tente entrar novamente na página. A página SSL deve ter sido carregada corretamente, com o cadeado “fechado”.


83

Atividade 2 – Configuração de Servidor IIS SSL

O exercício consiste em configurar o site padrão do IIS com SSL, conforme o roteiro abaixo. Será utilizado o software IIS, já instalado no Windows, e a ICPEDU Treinamento disponível na máquina virtual Linux.

Todos os comandos estão descritos em itálico, em linhas deslocadas à direita. Procure entender a função de cada comando, associando o mesmo com o conteúdo visto em aula. Não execute os comandos sem entendê-los, e em caso de dúvida consulte o instrutor.

1. Gerar chave e requisição de certificado 1. Selecione o site padrão, clique em Propriedades; 2. Clique na aba Segurança de Diretório, Certificado de Servidor; 3. Selecione a opção Criar um Novo Certificado e proceda com a entrada dos dados. Lembre-se, Nome Comum (Common Name) deve ser o hostname do site (no caso, localhost). 4. Salve a requisição em uma pasta conhecida do computador. Sugestão: “Desktop”. 2. Assinar a requisição na AC SSL 1. Copie a requisição para a máquina virtual. Isso é possível através da seguinte sequência de passos: 1.1. Encontre o arquivo no Windows Explorer. Copie o arquivo para a área de transferência (CTRL+C); 1.2. Na máquina virtual, abra a sua pasta de usuário, e em seguida a pasta “ICPEDU_Treinamento”, através do menu Places/Home Folder; 1.3. Cole o arquivo (CTRL+V). 2. Inicie a máquina virtual VMware do Linux Ubuntu; 3. Utilize novamente a mini-ICPEDU de treinamento que está disponível na pasta “/home/icpedu/ICPEDU_Treinamento” da máquina virtual para assinar o certificado: cd /home/icpedu/ICPEDU_Treinamento openssl ca openssl ca -config ACSSL/openssl.cnf \ -out localhost.cer -infiles localhost.req 4. Você precisará dos arquivos de todos os certificados da cadeia da ICP no Windows. Copie os arquivos ACRAIZ.pem, ACRNP.pem, ACSSL.pem e localhost.cer para a área de transferência (CTRL+C) e cole em alguma pasta do Windows (CTRL+V).

Servidor Web Seguro

84

Escola Superior de Redes RNP 3. Instalar Certificado no IIS a. Selecione o site padrão, clique em Propriedades; b. Clique na aba Segurança de Diretório, Certificado de Servidor; c. S elecione a opção Processar solicitação pendente e instale o certificado localhost.cer;

d. A cesse https://localhost e verifique o resultado. O navegador deve informar que o certificado não é confiável, e permitir o acesso mediante confirmação. 4. Instalar Cadeia de Certificação 1. Instale os certificados utilizando o mmc: 1.1. No menu Iniciar, clique em Executar e execute o comando mmc; 1.2. Clique no menu Arquivo, e selecione a opção Adicionar/Remover Snap-in; 1.3. Utilizando o botão Adicionar, adicione o snap-in de controle de certificados de todo o computador; 1.4. Clique em Fechar para voltar à tela inicial do mmc. Agora você tem à disposição o controle de confiança de todos os certificados, LCRs e outros dados relacionados a certificados, no escopo do seu computador. 1.5. Importe, nas sessões adequadas, cada certificado da ICPEDU experimental: \\AC-Raiz

no repositório de Autoridades de certificação Raiz Confiáveis;

\\AC

RNP e AC SSL nos repositórios de Autoridades de certificação intermediárias.

1.6. A importação é feita através do botão esquerdo do mouse, item Todas as Tarefas/Importar. 2. Acesse https://localhost (através do Firefox do Windows, que não utiliza o repositório de certificados do Windows onde já temos a ICP instalada) e verifique o resultado. O navegador ainda deve informar que o certificado não é confiável e permitir o acesso mediante confirmação. 3. Instale o certificado da AC-Raiz ICPEDU como confiável para fim de autenticação de sites no Firefox. Tente entrar novamente na página. A página SSL deve ter sido carregada corretamente, com o cadeado “fechado”.


85

Atividade 3 – Configuração de Servidor Apache SSL com autenticação do Cliente 1. Gerar PKCS#12 com chave e certificado assinado pela AC RNP para Cliente 1. Gerar chave: openssl genrsa -out minha_chave.key 2048 2. Gerar requisição de certificado: openssl req -new -key minha_chave.key -out minha_ requisicao.csr 3. Assinar requisição de certificado na AC RNP: cd ICPEDU_Treinamento openssl ca -config ACRNP/openssl.cnf -out ../meu_ certificado.cert -infiles ../minha_requisicao.csr cd .. 4. Criar PKCS#12 com chave e certificado: openssl pkcs12 -export -in meu_certificado.cert -inkey minha_chave.key -out meu_p12.p12 -name “Cristian T. Moecke” 5. Copiar certificado da AC RNP para Apache: sudo cp /home/icpedu/ICPEDU_Treinamento/ACRNP.pem /etc/ apache2/ssl/cert/ 6. Configurar SSL para exigir certificados da AC RNP: sudo gedit /etc/apache2/sites-enabled/001-default-ssl 7. Adicionar as seguintes linhas: SSLCACertificateFile /etc/apache2/ssl/cert/ACSSL_ cadeia.pem // exige autenticação do cliente SSLVerifyClient require // profundidade maxima do caminho (número de certificados de CAs) SSLVerifyDepth 3 Servidor Web Seguro

Escola Superior de Redes RNP // Exporta Variáveis do certificado para variavel $_ SESSION (ex: para uso no PHP) SSLOptions +StdEnvVars +ExportCertData ... // No diretório que passará a exigir autenticação SSL SSLRequireSSL ... 8. Reiniciar o Apache: sudo apachectl restart 9. Testar o acesso no Firefox: Deve ser exibida uma mensagem de erro, pois você não se autenticou. 2. Importar PKCS#12 no Firefox e testar acesso novamente O navegador vai solicitar um certificado do usuário, e permitirá acesso ao site. A variável $_SESSION contém agora também as informações do certificado autenticado. Você pode visualizar isso através do seguinte código PHP:


86

5 Sessão de aprendizagem 5 SGCI – Conceitos e visão geral Sumário da sessão SGCI – Visão geral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Árvore de Certificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 SGCI – Instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Perfis de usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Autoridades Certificadoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Criação de AC-Raiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Criação de AR-Vinculada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Políticas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Criação de AC-Raiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Atividade 1 – Instalação do SGCI e criação de uma AC-Raiz. . . . . . . . . . . . . . . 106

88


SGCI – Visão geral

SGCI – Visão geral Principais características do SGCI: Gerenciar o ciclo de vida do certificado digital da entidade: Emissão do Certificado Utilização do Certificado Renovação do Certificado Revogação do Certificado

SGCI é um software de gerenciamento do ciclo de vida de certificados digitais. Um sistema deste tipo deve gerenciar o ciclo de vida de um certificado, que compreende as seguintes fases: 1. Emissão do certificado digital – Este é o início do ciclo de vida, o “nascimento” do certificado.

Gerenciar a chave-privada Gerenciamento através de hardware é mais rigoroso

2. Utilização do certificado – Esta é a principal fase, e a de maior duração, do ciclo de vida de um certificado digital. 3. Renovação do certificado – Nesta etapa o certificado é subtituído por um novo certificado. Esta etapa encerra a vida de um certificado digital, porém não encerra o ciclo de vida da entidade que possui o certificado. 4. Revogação do certificado – Nesta etapa o certificado é adicionado na Lista de Certificados Revogados, que marca-o como revogado. Um certificado revogado não pode ser mais utilizado.

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. Não é possível gerenciar o ciclo de vida de uma chave privada, de forma segura, utilizando apenas software. Para isto, 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.

SGCI – Visão geral Principais características do SGCI: Auditável Código-fonte aberto Logs das operações

Templates

Os certificados emitidos por uma determinada entidade tendem a possuir campos com valores iguais

Flexibilidade

\\O

SGCI foi construído para ser utilizado em ambientes acadêmicos, para disseminar o conhecimento sobre certificação digital. Por causa deste motivo, optou-se em criar o SGCI com o código-fonte aberto, disponível para quem quiser aprender como ele foi implementado. Esta característica também é relevante para processos de homologação, em que o sistema pode ser facilmente inspecionado.

\\Todas

as operações efetuadas pelo SGCI são registradas por logs. Este aspecto é muito importante para processos de auditoria, em que é necessária a verificação de todos os passos realizados por uma entidade.


89

Normalmente os certificados emitidos por uma determinada entidade tendem a possuir campos iguais, padronizados. Para evitar que o operador tenha que digitar (ou selecionar) estes campos toda vez que for criar um certificado, foram criados os templates. Os dados dos templates são mesclados com os dados da requisição dos usuários, e depois o certificado é emitido. 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 estruturas, deve-se mantê-lo simples de utilizar, pois esta é uma das principais dificuldades na implementação do SGCI. Normalmente as soluções flexíveis são mais complexas. O ponto de flexibilidade mais interessante do SGCI é a localização das entidades, que podem estar distribuídas de 3 maneiras: 1. Elas podem estar todas reunidas no mesmo computador, funcionando de modo totalmente automatizado.

Entidades no mesmo computador

Entidades distribuídas

Mista SGCI – Conceitos e visão geral

2. Podem estar separadas, uma em cada computador. Estas, por sua vez funcionam de forma manual no SGCI 1.3.x. Para a versão 2.0.0, estuda-se a possibilidade de automatizar de forma segura esta comunicação. Esta comunicação nem sempre pode ser totalmente automatizada. Um exemplo seria a AC-Raiz da ICPEDU, onde a máquina hospedeira ficará desconectada de qualquer tipo de acesso à internet, desligada e guardada numa sala cofre. Toda vez que for necessário utilizar a AC-Raiz, a máquina terá que ser ligada, e a comunicação com o mundo exterior somente é autorizada através de mídias. 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.

90


Os usuários do SGCI são classificados em 3 perfis:

SGCI – Visão geral

\\Administrador

Usuários Controle de usuários

Administradores – Fazem as “configurações” da entidade Operadores – Operaram a entidade no seu dia-a-dia Criador – Cria novas entidades

Controle político é separado do controle operacional

– Pessoas que controlam as configurações da entidade. Estes controles incluem relações de confiança, templates, políticas etc.

\\Operador

– Pessoas que fazem as operações da entidade, como aprovar requisições, emitir certificados, emitir LCR etc.

\\Criador

– Este usuário é único, responsável por criar entidades e administradores.

re de Certificação

Estes três papéis foram criados pensando-se 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.

ore de certificação que será criada como exemplo

Árvore de Certificação Depois de conhecermos o funcionamento das entidades e os usuários no SGCI, podemos conhecer a estrutura que será criada ao final deste curso. Num primeiro nível teremos a AC-Raiz, e abaixo dela teremos a AC UFSC e a AC Instituição. A AC Instituição representa a instituição do aluno.


91

Parece simples! Mas…

A princípio parece uma estrutura muito pequena e simples, com apenas 3 entidades. Porém, ao olharmos detalhadamente a estrutura 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

SGCI – Instalação Site do SGCI: https://projetos.labsec.ufsc.br/sgci Passos da instalação: Download do SGCI Descompactar SGCI Configurar Banco de Dados Configurar permissões de arquivos Configurar SGCI Instruções passo-a-passo de instalação: https://projetos.labsec.ufsc.br/sgci/wiki/instalacao_130

O SGCI pode ser baixado no site: \\https://projetos.labsec.ufsc.br/sgci

A instalação não é automatizada (requisito previsto para a versão 2.0.0) e existem alguns passos que devem ser feitos. Estes passos estão detalhados no próprio site do SGCI, na página: \\https://projetos.labsec.ufsc.br/sgci/wiki/instalacao_130

Inicialmente faz-se o download do SGCI, depois o mesmo é descompactado e copiado para uma pasta visível pelo servidor web. Depois é necessário criar as tabelas no banco de dados e dar as permissões aos arquivos do SGCI. E, por último, configurar o banco de dados no SGCI. Após a instalação concluída, esta é a página inicial do SGCI. Temos 3 opções para escolher: \\Módulo

de AC – Executada função de AC;

\\Módulo

de AR – Executada função de AR;

\\Modo

SGCI – Conceitos e visão geral

Criador – Executadas as tarefas de criação de entidades.

SGCI – Instalação

92


Ao selecionar um dos módulos, a próxima etapa é selecionar a entidade. Após a entidade selecionada, são exibidos os tipos de usuário. Nos próximos slides vamos conhecer um pouco mais sobre cada tipo de usuário. Após selecionar o perfil do usuário, é necessário digitar o login e a senha do mesmo. Vamos iniciar a exploração do software pelo módulo criador. O usuário padrão é criador, e a senha rnp.

Perfis de usuário Criador Cria entidades Faz backup Configura Módulo de Serviço Criptográfico (MSC) Extrai logs

Perfis de usuário Principais funções do usuário criador: \\Criar \\Fazer

entidades (AC/AR); e restaurar backup;

\\Adicionar \\Extrair

e configurar MSC;

logs.


93

Perfis de usuário Administrador Administrador de AC

Altera políticas da AC Cadastra relações de confiança Cadastra templates de certificados Cadastra operadores

Administrador de AR

Cadastra relações de confiança Cadastra operadores

O Perfil de Administrador tem diferentes funções no módulo de AC e de AR. No módulo de AC o Administrador pode: \\Alterar

políticas da AC;

\\Cadastrar

e excluir relações de confiança com outras entidades; \\Cadastrar

e alterar templates de certificados;

\\Cadastrar

operadores.

Já o papel de Administrador no módulo AR executa as funções de:

Perfis de usuário Operador Operador de AC

Importa requisições (aprovadas pela AR) Aprova/Rejeita requisições de emissão de certificados Aprova/Rejeita requisições de revogação de certificados Emite Listas de Certificados Revogados (LCRs) Gera arquivo LDIF com certificados e LCRs

Operador de AR

Importa requisições de certificado Aprova/Rejeita requisições de certificado Solicita revogação de certificados

\\Cadastrar

relações de confiança com outras

entidades; \\Cadastrar

operadores.

O perfil de Operador tem diferentes funções nos módulo de AC e de AR no SGCI. No módulo de AC o operador pode: \\Importar

requisições que foram aprovadas pela AR;

\\Aprovar

ou rejeitar requisições de emissão de certificado;

\\Aprovar

ou rejeitar requisições de revogação de certificados vindas da AR;

\\Emitir

e exportar listas de certificados revogados.

Já o papel de Operador no módulo AR, executa as funções de: \\Importar

requisições de certificados (assinadas pelo requerente do certificado);

\\Verificar

e aprovar, ou rejeitar, as requisições de certificado;

\\Solicitar

que a AC revogue um certificado, sem a necessidade da intervenção do usuário do certificado.


94


Nesta figura, podemos observar como os diferentes tipos de usuários interagem durante a emissão de um certificado. Inicialmente o usuário se apresenta à AR, e requisita um certificado. O operador da AR verifica os dados do usuários, e da sua requisição. Caso esteja tudo correto, a requisição é aprovada, assinada digitalmente pela AR e enviada para uma AC que seja confiável. Quem determina qual AC é confiável é o administrador da AR. Após a requisição ser enviada para AC, o operador da AC emite o certificado e devolve para AR, que envia o certificado ao usuário. Na hora da emissão do certificado, o administrador da AC configura os templates e as ARs que podem enviar requisição (confiáveis).

Autoridades Certificadoras

Autoridades Certificadoras AC-Raiz Certificado auto-assinado. AC por geração de requisição (AC-Intermediária) Cria-se a requisição, esta é enviada para uma AC superior, que emite o certificado da nova AC. AC por importação de certificado Importação da chave e do certificado de uma AC já existente.

No SGCI, uma AC pode ser de dois tipos: 1. AC-Raiz – Entidade com certificado auto-assinado, que não precisa da aprovação de ninguém, sendo o certificado criado e assinado com a mesma chave. 2. AC-Intermediária – O certificado desta entidade precisa passar por um processo de aprovação, pois é emitido por alguma AC superior. Inicialmente é gerada uma requisição, que deve ser enviada a uma AR, que por sua vez submete a requisição assinada à uma AC, que emite o certificado. Após o certificado emitido, este é importado no SGCI. Somente quando o certificado tiver sido importado, é que a entidade se torna operacional.

O SGCI, além de criar entidades, suporta a importação de entidades, ou seja, uma entidade já existente pode passar a ser “controlada” pelo SGCI a qualquer momento. Vale lembrar que a troca do sistema que gerencia a entidade acarreta a perda dos logs. Vamos iniciar a criação da nossa estrutura de exemplo pela criação da AC-Raiz.


Criação de AC-Raiz

95


Para criar uma AC-Raiz, basta logar no módulo criador, depois ir ao menu Entidades/Cadastrar AC. Será exibida uma tela igual à figura apresentada no slide. No primeiro campo, podemos selecionar o tipo de AC que cadastraremos, neste caso, uma AC-Raiz. Dependendo da opção escolhida neste campo, os campos disponíveis no formulário serão alterados juntamente. Para uma AC-Raiz, os campos disponíveis inicialmente são: \\Nome

Comum – Neste campo deve ser preenchido o nome comum, ou common name do certificado.

\\Organização

– Neste campo deve ser preenchido o nome da organização, ou o organization name do certificado.

\\Unidade

da Organização – Neste campo deve ser preenchida a unidade da organização, ou a organizational unit do certificado.

\\Cidade

– Este campo deve ser preenchido com a cidade.

\\Unidade

Federativa – Neste campo deve ser colocada a unidade federativa do certificado.

\\País

– Este campo deve ser preenchido com a sigla do país e somente pode ter 2 caracteres.


\\E-mail

– Este campo deve ser preenchido com o e-mail.

\\Senha

– Neste campo deve ser digitada a senha do usuário criador.



96

Após o preenchimento dos campos, para criar a AC deve-se clicar no botão Cadastrar. Caso exista a intenção de anular a operação, clique no botão Cancelar. Vale salientar que os certificados da ICPEDU não podem ter caracteres acentuados; sendo assim, a palavra “Brasília” deve ser digitada “Brasilia”, sem acento.

Campos avançados

Campos avançados Clicando sobre a caixa de verificação Campos Avançados, serão exibidas mais opções para o certificado da AC a ser criada. A figura do slide mostra a tela exibida. Inicialmente tem-se o campo Campos Adicionais, e nele pode-se adicionar mais campos ao sujeito do certificado, além dos apresentados nas opções básicas. \\Campo

Path Length – Determina quantos níveis de ACs podem existir abaixo da AC onde está sendo criada a árvore de certificação. Por exemplo, se colocarmos Path Length = 0, quer dizer que a nossa AC somente pode emitir certificados para usuários. Se colocarmos Path Length = 1, significa que a nossa AC pode emitir certificados para outras ACs e para usuários. Neste caso, as “outras ACs” somente podem emitir certificados para usuários.

\\Campo

Período de validade – Determina por quantos dias o certificado da AC é válido. Este 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).

\\Caixa

de seleção Utilizar HSM – Selecionada caso a chave da entidade esteja armazenada em um HSM. No nosso exemplo, vamos gerar as chaves sem utilizar um HSM. 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 HSM.


97

Se optarmos pelo SGCI gerar a chave privada da AC, ao invés de um HSM, ficam disponíveis 2 campos: \\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 utilizam a chave.

\\Algoritmo

– Algoritmo que vai ser utilizado para tirar o hash da chave. Esse hash é utilizado para se identificar a chave da AC.

Se for feita a opção por utilizar uma chave em HSM, será necessário selecionar o HSM que vai ser utilizado e o identificador da chave. \\URL

LCR – Toda AC deve emitir uma Lista de Certificados Revogados (LCR) e disponibilizá-la em algum repositório. Este campo serve para apontar para este repositório. Este campo é útil para os softwares saberem onde encontrar a última versão da LCR. Sem esta informação os softwares não conseguem verificar automaticamente a validade de um certificado.

\\OID

da PC – Toda AC deve possuir uma Política de Certificação (PC), que define como a AC opera, e como são os certificados emitidos. Estas políticas são identificadas através de um Object Identifier (OID) estabelecido por órgão responsável. Normalmente os OIDs são atribuídos pela Internet Assigned Numbers Authority (IANA).

\\URL

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). Este ponteiro é colocado neste campo na forma de um Uniform Resource Identifier (URI).

\\User

Notice – Este campo é um texto colocado nos certificados que possuírem um OID da PC.

\\Subject

Key Identifier – Este campo representa uma extensão, padronizada pela RFC 5280; o usuário somente tem a possibilidade de adicionar esta extensão no certificado ou não. Esta extensão serve para identificar a chave do sujeito do certificado, e normalmente é feita através do hash da chave do sujeito.

\\Key

Usage – Esta extensão 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. Estas funcionalidades possuem algumas regras para serem assinaladas. Estas regras são descritas na seção 4.2.1.3 da RFC 5280.


Criação de AC-Raiz Escola Superior de Redes RNP

98

Tela de confirmação do cadastro da AC-Raiz

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 é demonstrada no slide. Nesta tela é exibido o nome da entidade, o status dessa entidade (ativa/inativa), a data de criação e os campos básicos do certificado. Também é possível fazer o download do certificado da AC. Um dado muito importante mostrado nesta tela é o hash do certificado. Este hash normalmente é publicado para as pessoas poderem verificar se o certificado que elas possuem é realmente o certificado original da AC. Nesta tela também existe a opção de cadastrar uma AR-Vinculada. No SGCI, os certificados devem ser aprovados por uma AR, para depois serem emitidos pela AC. Porém, como é possível emitir o certificado da primeira AR, se não existe uma AR para aprovar? Para solucionar este problema, o SGCI utiliza uma AR-Vinculada. Uma AR-Vinculada é a primeira AR criada para a entidade. Esta AR é a única entidade que possui o certificado emitido sem a aprovação de uma AR.

Criação de AR-Vinculada

Criação de AR-Vinculada

Ao selecionar a opção de cadastrar AR-Vinculada, é exibida a tela mostrada no slide. A tela de cadastro de AR-Vinculada é igual à tela de cadastro de AC-Raiz, embora com menos opções.


Usuários 99

Criação de usuários Usuários

Criação de usuários Após a criação da AC-Raiz e de sua respectiva AR-Vinculada, é necessário criar os usuários que farão a operação dessas entidades. No SGCI um mesmo usuário pode participar de diferentes papéis em diferentes entidades. Por exemplo, o usuário Pedro pode ser Administrador da AC-Raiz e Operador da AR-Vinculada. Para cada papel do usuário Pedro, ele pode utilizar uma senha diferente, porém será utilizado sempre o mesmo login. No exemplo anterior, para o papel de Administrador da AC-Raiz, o usuário Pedro pode usar a senha 12345, e para o papel de Operador da AR-Vinculada, a senha 5678. Dependendo das políticas da entidade, um usuário também pode ter vários logins.

Usuários

A tela de cadastro de usuários é composta por vários campos, onde são Atribuição papel de Administrador preenchidos algunsdo dados dos usuários. Os campos de preenchimento obrigatório são login, nome e e-mail.

Atribuição do papel de Administrador Como um usuário pode ter vários papéis no SGCI, após cadastrar o usuário é necessário atribuir um papel a ele. O usuário criador atribui os papéis de administradores aos usuários, enquanto que os administradores atribuem os papéis de operadores aos usuários. Para atribuir o papel de administrador a um usuário cadastrado, basta logar como criador, ir no menu Administradores e depois selecionar Cadastrar Novo Administrador. Será exibida uma tela igual à do slide. No primeiro campo seleciona-se o usuário, depois o tipo de entidade. Dependendo do tipo de entidade, são mostradas diferentes entidades no terceiro campo. Depois é necessário entrar com a senha do administrador, uma confirmação da senha do administrador, e a senha do usuário criador, para autorizar a operação.


UsuáriosEscola Superior de Redes RNP

100

Note que a senha é definida somente no momento de criar o Administrador, e não

Atribuição do papel de Operador na hora de cadastrar o usuário. Isto permite que um login possua diferentes senhas para cada papel exercido em cada entidade.

Para criar operadores, é necessário logar como Administrador de uma entidade, selecionar o menu Operadores, e a opção Cadastrar Novo Operador. Será exibida uma tela igual à do slide. Seleciona-se o usuário, dentre os já cadastrados, depois digita-se a senha do usuário e a senha do Administrador.

Atribuição do papel de Operador

O Administrador também pode cadastrar usuários através do menu Usuários. A tela de cadastro de usuários é igual à tela de cadastro de usuários no módulo criador.

Políticas

Políticas Editar políticas de AC

Editar políticas de AC Para editar as configurações de operação de uma AC, um dos administradores da mesma deve se logar, e escolher a opção Política no menu. Será listado um resumo das políticas e dos templates existentes. As políticas da AC definem como ela se comportará durante o seu ciclo de vida. \\Para

modificar a política da AC, o administrador deve escolher a opção Editar Política. A tela exibida pode ser visualizada no slide.

\\No

primeiro campo, é escolhido o template padrão para a AC. Quando um operador for emitir um certificado, ele deve escolher um template para emitir o certificado. Como o SGCI suporta vários templates, e geralmente existe um que se destaca (sendo o mais utilizado), é possível definir o template padrão quando o operador for emitir um certificado.


101

\\No

segundo campo, Restringir DNs iguais, pode-se selecionar sim ou não. Se for escolhido sim, o SGCI não permitirá a emissão de certificados com o mesmo Domain Name (DN).

\\Na

opção Revogação de certificados, pode ser selecionado se a revogação de certificados vai ser automática ou manual.

\\A

emissão de LCR podia ser automática em versões anteriores do SGCI. Porém, esta opção foi desabilitada, sendo necessário utilizar emissão manual de LCR.

opção Publicar arquivo de configuração serve para permitir ao SGCI publicar o arquivo de configuração. Um arquivo de configuração é utilizado para estabelecer relações de confiança entre entidades remotas. Veremos mais adiante a utilização destes arquivos de configuração.

\\A

\\A

opção Permitir publicação de certificados permite ao SGCI publicar automaticamente os certificados emitidos em diretórios LDAP.

mplates

\\Os

4 últimos campos servem para configurar o diretório LDAP em que serão publicados os certificados.

\\Após

as devidas configurações serem feitas, basta clicar sobre o botão Atualizar para salvar a nova política da AC.

dastro de templates Templates No SGCI é possível cadastrar templates, que são configurações pré-determinadas para a emissão de certificados. Por exemplo, um certificado SSL tem certas propriedades, e sem os templates, toda vez que o operador fosse emitir um certificado SSL, ele teria que selecionar essas propriedades. O SGCI traz 4 templates pré-configurados: \\Autoridade

Certificadora;

\\Autoridade

de Registro;

\\Servidor; \\E-mail.

Cadastro de templates

Para cadastrar um novo template, o usuário deve se logar com o perfil de administrador em alguma AC, ir ao menu Política e escolher a opção Cadastrar Template. Será exibida uma tela igual à do slide. O cadastro de um novo template pode ser baseado em outros templates já existentes. O template a ser baseado é escolhido no primeiro campo, Templates pré-configurados.



102

No segundo campo é selecionado se o template vai ficar disponível para o operador. Este campo é utilizado para ativar ou desativar a utilização de um determinado template. O terceiro campo é o nome do template. O quarto e quinto campos servem para publicação do template em LDAP. No quinto campo é colocado o período de validade dos certificados que foram emitidos utilizando aquele template. No sexto campo é selecionado o algoritmo utilizado para assinar o certificado. No campo Tamanho da chave, é selecionado o tamanho da chave do certificado. Os próximos campos são todos para configurar as extensões dos certificados, porém uma requisição de certificado pode ser criada utilizando extensões. Assim, pode ocorrer que uma requisição de certificado possua a mesma extensão definida no template. O campo Configuração da seção de extensões configura o que vai ser feito neste caso. Temos as seguintes opções: \\Ignorar

todas as extensões informadas na requisição – Esta opção ignora as extensões presentes na requisição, e aplica somente as extensões do template.

\\Manter

as extensões que não constem no template informadas na requisição – Esta opção mantém as extensões informadas na requisição que não constam no template. Porém, as que constam no template substituem as que constam na requisição.

\\Manter

todas as extensões informadas na requisição – Nesta opção, se existir alguma extensão na requisição, ela substitui o que está especificado no template.

A extensão Basic constraints possui 2 campos: \\Entidade

Final – Neste 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.

\\Path

Length – Caso o certificado seja de AC, este campo limita a profundidade de certificados que podem existir abaixo da AC na árvore de certificação.

O campo Subject Key Identifier configura se esta extensão deve estar presente no certificado ou não. O mesmo ocorre para o campo Authority Key Identifier. Os campos Uso da Chave, Uso Estendido da Chave, URL da LCR, OID da PC, URL da DPC e Texto da DPC possuem a mesma configuração que os campos do cadastro de AC, explicados anteriormente. Após configurado, para salvar o template bastar clicar em Cadastrar Template.


103


Criação de AC-Raiz Criação da chave e do certificado auto-assinado da AC Criação da AR-Vinculada Criação dos usuários Atribuição do papel de Administrador Atribuição do papel de Operador Configuração das políticas da AC Configuração dos templates de certificados (opcional)

Para criar uma AC-Raiz, é necessário executar todos os passos descritos até agora, que são: \\Geração

da chave do certificado auto-assinado da AC – Isto é feito no módulo criador, quando é cadastrada uma entidade.

\\Criação

da AR-Vinculada – Este passo é executado no cadastro da AR-Vinculada.

\\Criação

dos usuários – Efetuada ao cadastrar usuários.

\\Atribuição

dos papéis de Administrador e Operador.

\\Configuração

da AC – Este passo é realizado configurando as políticas da entidade, através do papel de Administrador.

\\Configuração

dos templates – Este passo é opcional, feito como Administrador da AC.




104

5 Sessão de aprendizagem 5 SGCI – Conceitos e visão geral Roteiro de atividades Tópicos e conceitos \\Conceitos

gerais do SGCI:

\\Entidades \\Usuários

(AC-Raiz e AR-Vinculada)

(Criador, Administrador e Operador)

\\Templates

de certificados

Competências técnicas desenvolvidas \\Instalação

do SGCI

\\Criação

de AC-Raiz no SGCI

\\Criação

de Usuário no SGCI


minutos

106


Atividade 1 – Instalação do SGCI e criação de uma AC-Raiz

O exercício foi desenvolvido para ser realizado em duplas, que devem compartilhar uma máquina. Cada aluno deve substituir SUA_INSTITUICAO pelo nome da sua respectiva instituição. O aluno deve iniciar a máquina virtual VMware do sistema operacional Linux Ubuntu, e logar utilizando login icpedu e senha icpedu. A senha para o comando sudo (executar comando como administrador do sistema) também é icpedu. Cada computador tem pré-instalado um servidor Apache, PHP e um banco de dados PostgreSQL. O exercício consiste em executar todos os passos da instalação do SGCI, gerar uma AC-Raiz e configurá-la. Todos os comandos estão descritos em itálico, em linhas deslocadas à direita. Procure entender a função de cada campo a ser digitado no SGCI, associando o mesmo com o conteúdo visto em aula. Não preencha os campos sem entendêlos, e em caso de dúvidas, consulte o instrutor.

Instalação do SGCI

1. Instalar as dependências do SGCI: 1. LibCryptoSec: https://projetos.labsec.ufsc.br/libcryptosec 1.1. Baixar a última versão do pacote DEB da LibCryptoSec; 1.2. Instalar o pacote DEB. 2. Assinador: https://projetos.labsec.ufsc.br/sgci/wiki/assinador 2.1. Baixar a última versão disponível do assinador; 2.2. Descompactar o arquivo .tar.gz executando o seguinte comando no terminal (console): tar –xvzf

assinador-x.x.x.tar.gz

2.3. Compilar e instalar o assinador executando os seguintes comandos no Terminal: make sudo make install


107

2. Faça o download da última versão do SGCI no seguinte site: https:// projetos.labsec.ufsc.br/sgci 3. Siga as instruções de instalação disponíveis no site: https://projetos. labsec.ufsc.br/sgci/wiki/instalacao_130 4. Configure o banco de dados no SGCI. Edite o arquivo “/var/www/sgci/lib/ dblayer.inc.php” e coloque a senha do usuário do banco de dados criada anteriormente na seguinte linha:

$password = `teste`;

Por exemplo, se a senha escolhida foi abc123, esta linha ficará da seguinte maneira:

$password = àbc123`;

Criação da AC-Raiz 1. Abra o navegador e acesse o SGCI (http://localhost). Escolha o módulo de gerenciamento Criador. Entre com o usuário criador e senha padrão rnp. 2. Escolha o menu Entidades e a opção Cadastrar AC. 3. Escolha a Opção de Cadastro AC-Raiz, e preencha os dados da entidade. 4. Digite a senha do criador no campo correspondente, e clique em Cadastrar. 5. Será exibida uma tela de confirmação do cadastro da AC-Raiz. O próximo passo é cadastrar uma AR-Vinculada. 6. Para cadastrar uma AR-Vinculada, basta clicar no botão Cadastrar, em AR-Vinculada. 7. Agora devem ser preenchidos os dados da AR-Vinculada, digitando a senha do usuário criador no respectivo campo, e clicando em Cadastrar. O próximo passo é o cadastro de usuários. 8. Para cadastrar um usuário, é necessário selecionar a opção Usuários no menu, e em seguida a opção Cadastrar Novo Usuário. Os dados do novo usuário são preenchidos, e em seguida basta clicar em Cadastrar. Repita o processo para o usuário que será operador. Repita o processo para os usuários Administrador e Operador da AR-Vinculada. 9. Após cadastrar os usuários, será atribuído a um deles o papel de Administrador. Para isso, seleciona-se a opção Administradores no menu, e a sub-opção Cadastrar Novo Administrador. 10. Na tela de cadastro de administradores, primeiro é necessário selecionar o usuário que se quer vincular ao papel de administrador, depois o tipo de entidade, a entidade, e finalmente colocar a senha deste usuário e a senha do criador. Após todos os dados preenchidos, basta clicar no botão Cadastrar. Efetue este passo para a AC-Raiz e para a AR-Vinculada.



108

11. Agora serão criados os Operadores. Primeiro você deve sair do módulo de gerenciamento Criador, e fazer login no módulo de gerenciamento Autoridade Certificadora, utilizando a função Administrador. Utilize o login e senha cadastrados nos passos anteriores. Depois, selecione o menu Operadores, e a opção Cadastrar Novo Operador. Será exibida a tela de cadastro de operadores. Selecione o usuário que deseja que se torne operador da AC-Raiz, digite a senha deste usuário e a senha do Administrador. Clique em Cadastrar. Efetue este mesmo passo para a AR-Vinculada. 12. Agora vamos editar as configurações da AC-Raiz. Para isto, como Administrador da AC-Raiz, vá até o menu Política, e selecione a opção Editar Política. Selecione corretamente as configurações da AC-Raiz, e clique em Atualizar. 13. Para cadastrar um novo template, o usuário deve se logar com o perfil de Administrador na AC-Raiz, ir ao menu Política, e escolher a opção Cadastrar template. Selecione as opções corretamente, e clique no botão Cadastrar Template.


6 Sessão de aprendizagem 6 SGCI – Gerenciamento de Entidades Sumário da sessão Criação de Autoridades Certificadoras - I. . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Emissão de certificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Criação de Autoridades Certificadoras - II. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Criação de Autoridades de Registro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Vínculo de entidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Relacionamentos de confiança. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Revogação de certificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Lista de Certificados Revogados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 SGCI 2.0.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Atividade 1 – Criação da AC Instituição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Atividade 2 – Criação da AR Instituição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Atividade 3 – Vincular a AR INSTITUICAO à AC INSTITUICAO . . . . . . . . . . . . . . 134

110


Criação de Autoridades Certificadoras - I Problema: criação da AC UFSC Não é um certificado auto-assinado Certificado da AC UFSC é emitido pela AC-Raiz Qual o tipo de certificado da AC UFSC? Certificado de AC Intermediária Qual a opção de cadastro que deve ser escolhida ao cadastrar esta AC no SGCI? AC Intermediária por geração de requisição

Criação de Autoridades Certificadoras - I 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 auto-assinado). O certificado das entidades abaixo da AC-Raiz são assinados pela AC-Raiz. Estes não são certificados auto-assinados.

No SGCI, estas entidades são denominadas ACs Intermediárias. E, para gerar um certificado para estas entidades, o processo é um pouco diferente do processo de geração da AC-Raiz.

Criação de Autoridades Certificadoras - I

Nos próximos slides veremos como criar uma AC Intermediária no SGCI.

Criação de uma AC Intermediária

Criação de uma AC Intermediária Para criar uma AC Intermediária no SGCI, deve-se entrar no módulo criador, selecionar a opção Entidades, Cadastar Nova Autoridade Certificadora, e no campo Opção de Cadastro, selecionar a opção AC Intermediária por geração de Requisição. Será exibida uma tela igual à apresentada no slide. Os campos básicos do certificado são iguais aos campos do cadastro de AC. Porém, existem 2 campos novos: \\Encaminhar

para AC – Neste campo é selecionado o AC que vai emitir o certificado. Caso o usuário queira enviar a requisição para uma AC que não esteja cadastrada no SGCI, basta selecionar a opção AC externa não cadastrada.


111

\\Encaminhar

para AR – Neste campo é selecionada a AR para a qual será enviada a requisição de certificado para aprovação. Caso o usuário queira enviar a requisição para uma AR que não esteja cadastrada no SGCI, basta selecionar a opção AR externa não cadastrada.

Criação de Autoridades Certificadoras - I

No nosso exemplo, a AC UFSC vai enviar a requisição de certificado para a AC-Raiz, e para a AR Vinculada da AC-Raiz.

Criação de uma AC Intermediária – campos avançados

Criação de uma AC Intermediária – campos avançados

Por que só estes campos?

Ao clicar em Campos avançados, pode-se perceber que os campos exibidos são os mesmos do cadastro de AC, porém não são exibidos todos os campos.

A definição dos outros campos é do emissor do certificado Isso acontece porque alguns dos campos de um certificado digital são definidos Criação Autoridades Certificadoras - I que emite pelo sujeito do de certificado, e outros campos são definidos pela entidade o certificado. Os outros campos que aparecem no cadastro de AC, porém, não aparecem no cadastro de ACs Intermediárias, mas são inseridos pela entidade que Criação emite o certificado são configurados dos templates). de uma(estes AC campos Intermediária – tela através de confirmação

Criação de uma AC Intermediária – tela de confirmação Depois de criada a requisição de certificado de AC Intermediária, é exibida a tela de confirmação, que pode ser vista no slide. É interessante notar a diferença desta tela, em relação à tela de cadastro da AC-Raiz. Na tela de cadastro da AC-Raiz, era feito o download do CERTIFICADO, enquanto que nesta tela é feito o download da REQUISIÇÃO. Isto acontece porque SGCI – Gerenciamento de Entidades


112

uma AC-Raiz tem o seu certificado auto-assinado, 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, então é necessário enviar uma requisição para alguma AC superior assinar o seu certificado. O SGCI utiliza o padrão PKCS#10, então qualquer software de AC que utilize esse padrão consegue abrir o arquivo de requisição gerado pelo SGCI. Agora, esta requisição gerada deve ser enviada para a AR (selecionada anteriormente).

Emissão de certificados


Verificação da requisição pela AR

Verificação da requisição pela AR Quando uma AR recebe uma requisição é necessário verificar os dados da requisição. Para isso, o Operador da AR precisa ir ao menu Gerenciamento de Requisições, e clicar na opção Informações da requisição correspondente. Será mostrada uma tela igual à do slide. O operador da AR pode ver as informações básicas da requisição, e se necessário, pode ver opções mais avançadas utilizando o OpenSSL, clicando sobre a opção Ver Requisição com OpenSSL. Após o operador verificar os dados da requisição, ele pode decidir por aprovar a requisição ou rejeitá-la.


113

Para rejeitar uma requisição, o operador deve selecionar a requisição, e clicar sobre a opção Rejeitar Selecionadas. Será necessário o operador digitar a sua senha para confirmar a operação. Se o operador decidir aprovar a requisição, ele deve selecionar a requisição, e cliar sobre Aprovar selecionadas. Será necessário o operador digitar a sua senha para confirmar a operação.


Abaixo são exibidas as telas de seleção de requisições, e de confirmação de operação. Após uma requisição ser aprovada, ela é encaminhada para a AC.

Aprovação da requisição pela AR

Aprovação da requisição pela AR


Após o operador tomar a decisão sobre o que fazer com uma requisição, ele pode consultar o status dessas requisições. Para isso, basta ele ir ao menu Gerenciamento de Requisições, e selecionar as requisições pelo seu estado.

Requisições aprovadas esperando emissão do certificado

As requisições rejeitadas aparecem em Rejeitadas pela AR, e as requisições aprovadas aparecem em Aguardando avaliação da AC.

Requisições aprovadas esperando emissão do certificado

SGCI – Gerenciamento de Entidades


114

O operador da AC recebe a requisição aprovada pela AR, e também deve tomar uma decisão: rejeitar a requisição ou emitir um certificado. Caso o operador da AC decida rejeitar a requisição, esta requisição muda para o estado “Rejeitada pela AC”. Caso o operador da AC decida emitir o certificado, ele deve selecionar a requisição, e clicar em Emitir certificados. Será exibida uma tela de aprovação de requisição de emissão de certificado conforme demonstrado no slide. Nesta tela o operador deve selecionar o template que será aplicado na requisição para emitir o certificado, e deve confirmar a operação digitando a sua senha.

Emissão do certificado da entidade

O operador de AC pode visualizar os certificados emitidos através do menu Gerenciamento de Requisições, selecionando o filtro de “Certificado emitido pela AC”. O slide mostra a tela com os certificados emitidos pela AC-Raiz do nosso exemplo.

Certificados emitidos pela AC


115

Após a emissão do certificado, é necessário que a AR tome conhecimento acerca da emissão do certificado ou seja informada se a AC rejeitou a emissão do certificado. O operador da AR pode visualizar os certificados emitidos através do menu Gerenciamento de Requisições, selecionando o filtro de “Certificado emitido pela AC”. O slide mostra a tela com os certificados emitidos do nosso exemplo.


Após o certificado ser emitido, quem envia este certificado para o sujeito do Verificação do status do certificado na AR certificado é a AR. O operador pode baixar o certificado através da opção Download Certificado.

Verificação do status do certificado na AR

Criação de Autoridades Certificadoras - II Criação de Autoridades Certificadoras - II

Importação do certificado da AC

Importação do certificado da AC Após o certificado ser emitido, a AC Intermediária receberá o seu certificado da AR que o aprovou, e deve importar este certificado no SGCI, para tornar a sua entidade operante. Para isto, deve ser logado no módulo criador, selecionado o menu Entidades, e selecionada a entidade correspondente. Será exibida uma tela igual à do slide. Note que a situação atual da AC é pendente. Nesta tela pode-se importar o certificado da AC através do campo Certificado. Após o certificado ser selecionado, a operação deve ser confirmada com a senha do usuário criador. Se a importação do certificado ocorrer com sucesso, a situação da AC muda para ativa.


116


Criação de Autoridades Certificadoras - II

Agora, para a entidade estar apta a emitir certificados, basta cadastrar uma AR Vinculada, administradores e operadores. Estes passos são os mesmos que foram Criação efetuados da paraAR a AC-Raiz. Vinculada

Criação da AR Vinculada

Criação de Autoridades Certificadoras - II Criação de uma AC Intermediária Criação da chave e da requisição de certificado Aprovação da requisição por uma AR Emissão do certificado pela AC superior Importação do certificado da AC Intermediária Criação da AR-Intermediária-Vinculada Criação dos usuários Atribuição do papel de administrador Atribuição do papel de operador Configuração das políticas da AC Configuração dos templates de certificados (opcional)

Em resumo, os passos para a criação de uma AC Intermediária são os seguintes: \\Criação

da chave e da requisição de certificado da AC Intermediária;

\\Aprovação \\Emissão

da requisição por uma AR;

do certificado por uma AC;

\\Importação

do certificado da AC Intermediária;

\\Criação

da AR-Intermediária-Vinculada;

\\Criação

dos usuários;

\\Atribuição

do papel de administrador;

\\Atribuição

do papel de operador;

\\Configuração

das políticas da AC Intermediária;

\\Configuração

dos templates de certificados emitidos pela AC Intermediária.


117

Criação de Autoridades de Registro No SGCI uma AC pode ter várias ARs. A partir de agora, vamos aprender como cadastrar mais de uma AR para cada AC.

Quando uma AR é criada, ela também deve ter o seu certificado emitido por uma AC. O processo de criação de uma AR é parecido com o processo de criação de uma AC Intermediária. Primeiro é necessário criar uma requisição para a AR, depois a requisição é enviada para uma AR que aprova a requisição e a envia para uma AC que emite o certificado da nossa AR.

Criação de Autoridades de Registro


118


Para cadastrar uma nova AR no SGCI, e gerar a sua requisição, é necessário entrar no módulo de criador, e no menu Entidades selecionar a opção Cadastrar Nova Autoridade de Registro. Será exibida uma tela igual à do slide. No primeiro campo temos duas opções: \\AR

por geração de Requisição – Gera uma requisição, para criação de uma nova AR.

\\AR

por importação de certificado – Importa uma AR já existente para dentro do SGCI.

Se for selecionada a primeira opção, o operador deve escolher para qual AC e AR vai encaminhar a requisição da AC, para a emissão do certificado. Todos os outros campos são iguais aos descritos no cadastro de AC-Raiz. Após entrar com os dados, para gerar a requisição basta que o usuário clique em Cadastrar. Será exibida uma tela igual à de confirmação que aparece quando é gerada uma AC Intermediária.

Vínculo de entidades

Vínculo de entidades Uma AC somente pode emitir certificados aprovados por uma AR confiável. Portanto, é necessário estabelecer algum tipo de vínculo estre estas entidades. A relação de confiança é criada somente após a entidade ter capacidade de entrar em funcionamento (o certificado da entidade já foi emitido).

Uma AC somente emite certificados que foram aprovados por uma AR confiável. Para determinar qual AR é confiável, é necessário estabelecer uma relação de confiança mútua. Esta 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).

Por exemplo, imagine que a AC UFSC deseja ter duas ARs, uma AR Vinculada, que vai aprovar certificados de professores, e uma AR Alunos, que vai ser utilizada para emitir certificados somente para os alunos. A AR Vinculada é sempre confiável para a AC, porém para a AR Alunos ser confiável pela AC UFSC, é necessário estabelecer uma relação de confiança. Esta relação de confiança é criada trocando-se arquivos de configuração. A AC UFSC pega o arquivo de configuração da AR Alunos, e a AR Alunos pega o arquivo de configuração da AC UFSC. No caso das duas entidades estarem em sistemas diferentes, essa “troca” de arquivos tem que ser feita manualmente. Se as duas entidades estiverem no mesmo sistema, o SGCI faz essa “troca” automaticamente.


119

Vínculo de entidades

Quando há um relacionamento de confiança entre uma AC e uma AR, a AC pode emitir qualquer certificado aprovado por esta AR. Não confundir relação de confiança com a relação em que o certificado X foi emitido pela AC Y.

Criação do vínculo entre AC e AR

Criação de vínculo entre AC e AR Para cadastrar um vínculo entre uma AC e uma AR, basta o administrador da AC entrar no sistema, ir ao menu Relações de Confiança, e clicar na opção Cadastrar Novo Relacionamento de Confiança. Será mostrada um tela igual à do slide. Na tela de Cadastro de Relacionamento de Confiança, o usuário poderá escolher entre 3 situações: \\Autoridade

Interna – São as autoridades que foram criadas pelo SGCI, na mesma máquina.

\\Autoridade

Não Cadastrada – São as autoridades que não foram criadas na mesma máquina. Estas autoridades são cadastradas no SGCI através do arquivo de configuração.

\\Autoridade

Externa Cadastrada – São as autoridades que não foram criadas na mesma máquina. Estas autoridades já foram cadastradas no SGCI anteriormente.

Após selecionar a entidade em que o operador deseja criar uma relação de confiança, basta clicar no botão Cadastrar.


120


Relacionamentos de confiança Como vincular uma AR a uma AC remota de forma confiável? Exportar arquivo de configuração da entidade A Exportar arquivo de configuração da entidade B Importar o arquivo de configuração da entidade A, na entidade B, e vice-versa

Relacionamentos de confiança Para criar uma relação de confiança entre duas entidades remotas (em máquinas diferentes), é necessário primeiro exportar o arquivo de configuração delas, depois importar os arquivos de configurações remotos, e estabelecer o vínculo entre elas.

elacionamentos de confiança

Disponibilizar arquivo de configuração de uma AR

Relacionamentos de confiança

Disponibilizar arquivo de configuração de uma AR de ExportarDisponibilizar arquivo arquivo de configuração configuração de uma AR

Exportar arquivo de configuração

O arquivo de configuração somente pode ser exportado com a autorização do administrador, pois este arquivo é disponibilizado publicamente. Para disponibilizar o arquivo de configuração de uma AR, basta o administrador entrar no sistema, selecionar o menu Arquivo de configuração. Será exibida uma tela igual à do slide. Ele deve escolher se vai publicar o arquivo de configuração ou não, e confirmar a ação clicando em Atualizar.

Exportar arquivo de configuração

Os arquivos de configurações são disponibilizados na página inicial (área de login) do SGCI, em uma opção no canto superior esquerdo, chamada Arquivos de configuração. Para exportar um arquivo de configuração, basta selecionar a opção Download de Arquivo de Configuração da entidade correspondente. Para disponibilizar o arquivo de configuração em uma AC, basta o administrador da AC entrar no sistema, selecionar o menu Política, e escolher a opção Editar política. Será exibida a tela de alteração de política da AC, conforme demonstrado no slide. O administrador escolhe a opção Publicar arquivo de configuração, e clica sobre o botão Atualizar, para o SGCI disponibilizar o arquivo de configuração. Este arquivo de configuração é disponibilizado no mesmo local onde são disponibilizados os arquivos de configurações das ARs.


Relacionamentos de confiança 121

Disponibilizar arquivo de configuração de uma AC

Disponibilizar arquivo de configuração de uma AC; Exportar arquivo de configuração de uma AC é igual a exportar arquivo de configuração de uma AR

Exportar arquivo de configuração de uma AC é igual a exportar arquivo de configuração de uma AR importar o Após os arquivos de configurações serem exportados, é necessário arquivo de configuração da AR na AC, e vice-versa. Para importar o arquivo de configuração na AR, o administrador da AR deve se logar no sistema, selecionar o menu Entidades Externas, e a opção Cadastrar Novo Relacionamento de Confiança. O administrador escolhe a opção Autoridade Não cadastrada, seleciona o arquivo de configuração da AC, e clica em Cadastrar.

Relacionamentos de confiança

Agora, a AC é confiável para a AR, ou seja, a AR pode enviar requisições aprovadas para a AC. Porém, isto não significa que a AC vai aceitar essas requisições. Para Importar arquivo deque configuração AR de configuração da AR. isto ser verdade, é necessário a AC importe ona arquivo

Importar arquivo de configuração na AR Para a AC importar o arquivo de configuração da AR, o administrador da AC deve entrar no sistema, selecionar o menu Relações de Confiança e escolher a opção Cadastrar Novo Relacionamento de Confiança. Depois, ele seleciona a opção Autoridade Não Cadastrada, seleciona o arquivo de configuração da AR e clica em Cadastrar. Agora, as requisições que vierem da AR cadastrada anteriormente serão aceitas como válidas. Note que a criação de relação de confiança entre entidades externas deve ser efetuada tanto na AR, quando na AC. Já para autoridades internas, somente a AC pode criar a relação de confiança. Isto acontece porque quando forem entidades internas, o SGCI já faz automaticamente a troca de arquivos de configuração. Então, para autoridades internas, quem escolhe se deseja estabelecer vínculo de confiança ou não é a AC. E, uma vez que o administrador de uma AC escolheu criar um vínculo com a AR, o vínculo da AR com a AC é criado automaticamente nessas entidades. SGCI – Gerenciamento de Entidades

Relacionamentos de confiança 122


Importar arquivo de configuração na AC

Importar arquivo de configuração na AC

Revogação de certificados

Revogação de certificados Passos para a revogação: O usuário do certificado solicita a revogação do seu certificado para a AR A AR efetua o pedido de revogação e o encaminha para a AC A AC recebe o pedido, revoga o certificado, e envia a resposta para a AR 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 acontece em 4 passos: \\O

usuário pede para a AR revogar o seu certificado;

\\A

AR envia uma solicitação de revogação para a AC que emitiu o certificado;

\\A

AC recebe o pedido, revoga o certificado, e envia a confirmação para a AR;

\\A

AR avisa ao usuário que o seu certificado foi revogado.

A comunicação à população é feita através da emissão da Lista de Certificados Revogados (LCR). Após o usuário solicitar a revogação do seu certificado, o operador da AR deve entrar no sistema, ir ao menu Revogação de Certificados, e escolher a opção Solicitar Revogação de Certificados.


Revogação de certificados 123

Solicitação de revogação pela AR

Solicitação de revogação pela AR Será exibida uma tela para o operador selecionar à qual AC ele quer enviar o pedido de revogação. Após selecionada a AC, são exibidos os certificados emitidos por aquela AC e aprovados pela AR. O operador deve selecionar o certificado para o qual deseja fazer o pedido de revogação, e depois digitar uma justificativa para a revogação, digitar a sua senha, e clicar em Solicitar Revogação.


A requisição de revogação é encaminhada para a AC.

Exibir solicitações de revogação aprovadas pela AR e em análise pela AC

Se o operador da AR desejar ver as requisições de revogação que foram enviadas solicitações de revogação aprovadas pela AR ea opção para aExibir AC, e ainda estão em análise pela AC, basta que selecione no menu Revogação de Certificados. Será exibida uma tela semelhante à da figura abaixo. em análise pela AC

Para o operador da AC revogar um certificado, após a AR solicitar a revogação, é necessário que ele entre no sistema, e selecione no menu a opção Revogação de Certificados.


Serão exibidas para o operador as requisições de revogação feitas pela(s) AR(s). Se o operador desejar rejeitar alguma requisição, deve selecionar as requisições Exibir pedidos de revogação pendentes na AC que deseja rejeitar, e escolher a opção Rejeitar pedidos selecionados.

Exibir pedidos de revogação pendentes na AC SGCI – Gerenciamento de Entidades


124

Se o operador desejar revogar algum dos certificados, deve selecionar a requisição do certificado correspondente, e escolher a opção Revogar selecionados. Será exibida uma tela igual à do slide. O operador pode escolher o motivo de revogação dentre os possíveis motivos previstos na RFC 5280.


A diferença entre a justificativa dada pela AR, e o motivo de revogação escolhido pelo operador da AC é que a justificativa da AR é somente para uso interno, enquanto que o motivo escolhido pela AC é publicado na LCR. Revogar certificado

Revogar certificado

Lista de Certificados Revogados Após um certificado ser revogado ou periodicamente (de acordo com a DPC da AC), a AC deve emitir LCRs.


Para emitir uma LCR, o operador da AC deve entrar no sistema, selecionar o menu LCRs, e escolher a opção Gerar Lista de Certificados Revogados. Será apresentada uma tela igual à do slide. O operador deve entrar com o período de Emitir LCR validade da LCR, digitar a sua senha, e clicar sobre o botão Gerar LCR.

Lista de Certificados Revogados Emitir LCR Caso já existam LCRs emitidas, estas serão apresentadas para o operador LCR o menu LCRs, e se o operador desejar, poderá efetuar o quandoSalvar ele selecionar download destas.

Salvar LCR


125

Backup

Backup Criar backup O backup contém as chaves privadas que foram geradas no disco rígido O backup é cifrado a partir da senha do usuário criador

Backup

Um backup do SGCI contém toda a sua estrutura. Se existirem várias entidades no mesmo sistema, o backup será de todas estas 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 é quase uma “imagem” do sistema. Como estes dados são sigilosos, o backup do SGCI é cifrado a partir da derivação da senha do usuário criador.

Criar backup O obackup as chaves privadas foram Para realizar backup, contém basta o usuário criador entrar noque sistema e selecionar o geradas no disco rígido menu backup. Será exibida uma tela igual à mostrada no slide. O usuário criador digita a suaOsenha, clicaé sobre o botão Criar, o backup gerado. Para salvar o backup cifrado a partir daesenha doéusuário criador backup, basta clicar sobre o nome do arquivo de backup.

Criar backup Para restaurar o backup do SGCI, é necessário primeiro instalar uma cópia do SGCI, depois o usuário criador entrar no sistema e selecionar o menu Backup. Será exibida uma tela igual à mostrada no slide. Nesta tela, o usuário criador seleciona o arquivo de backup, digita a senha do backup, a sua senha, e clica sobre o botão Recuperar. Se o backup for concluído com sucesso, será mostrada Restaurar backup uma mensagem ao usuário.

Backup

Restaurar backup



126

Logs

Logs

Como já foi mencionado, o SGCI grava todas as atividades que foram efetuadas. E, para exportar estes logs, o usuário criador deve entrar no sistema e selecionar o menu Exportar Log. Será exibido o arquivo de log, bem como o seu tamanho. Exportar Se o usuário desejar exportar o log, basta clicar em Download. Se desejar excluir o log, basta selecioná-lo e clicar em Excluir selecionados.

Exportar

SGCI 2.0.0 Nas próximas imagens, serão apresentadas algumas telas do SGCI versão 2.0.0, que está em desenvolvimento. A versão apresentada é apenas um protótipo, e provavelmente ainda terá muitas modificações. Atualmente esta versão está apenas disponível para os desenvolvedores.

SGCI 2.0.0

Na primeira tela, vemos a área de login de usuários e uma das novidades da versão 2.0.0, o acesso ao sistema através da autenticação por certificados digitais.


SGCI 2.0.0

127

A versão 2.0.0 vai fazer uso de uma identidade visual mais forte. Um exemplo que pode ser visto nesta tela é que o “status” de uma entidade é diferenciado visualmente. Outra diferença está no canto superior direito, onde é destacado o módulo em que o usuário está trabalhando. Cada módulo possui uma cor diferenciada.

SGCI 2.0.0

Esta é a tela onde são mostradas as requisições de certificado. Agora, com apenas um clique o usuário pode emitir o certificado. Os menus também foram agrupados, para simplificar a utilização do sistema.




128

6 Sessão de aprendizagem 6 SGCI – Gerenciamento de Entidades Roteiro de atividades Tópicos e conceitos \\Conceitos

gerais do SGCI:

\\Entidades \\Usuários

(AC Intermediária e AR Vinculada)

(Criador, Administrador e Operador)

\\Templates

de certificados

\\Entidades

(AR não vinculada)

\\Relações

de confiança

Competências técnicas desenvolvidas \\Criação

de AC Intermediária no SGCI

\\Aprovação \\Emissão

de requisições de certificado

de certificados

\\Importação \\Criação

de certificado de AC Intermediária

de AR por geração de requisição no SGCI

\\Importação

de certificado de AR


minutos


130

Atividade 1 – Criação da AC Instituição

Esta atividade foi desenvolvida para ser realizada em duplas, que devem compartilhar uma máquina. Cada pessoa deve trocar INSTITUICAO pelo nome da sua respectiva instituição. O aluno deve iniciar a máquina virtual VMware do sistema operacional Linux Ubuntu, e logar utilizando login icpedu e senha icpedu. A senha para o comando sudo (executar comando como administrador do sistema) também é icpedu. O exercício consiste em executar todos os passos para a criação de uma AC Intermediária no SGCI. Esta atividade pressupõe que a Atividade 1 da sessão 5 foi executada com sucesso. Procure entender a função de cada campo a ser preenchido no SGCI, associando-o com o conteúdo visto em aula. Não preencha os campos sem entendê-los, e em caso de dúvidas, consulte o instrutor.

1. Criação da AC Intermediária 1. Abra o navegador e acesse o SGCI (http://localhost). Escolha o módulo de gerenciamento Criador. Entre com o usuário criador, e a sua senha padrão, rnp. 2. Escolha o menu Entidades, e a opção Cadastrar AC. 3. Escolha a Opção de Cadastro Intermediária por geração de requisição, e preencha os dados da entidade. O nome da sua entidade deve ser AC INSTITUICAO (sem acentuação). Neste passo é selecionado o local para onde será enviada a requisição. Ela será enviada para alguma AR confiável da AC Raiz. Na atividade 1, foi criada uma AR Vinculada, de confiança da AC Raiz. Após todos os dados preenchidos, digite a senha do criador no campo correspondente, e clique em Cadastrar. 4. Como a requisição de certificado da AC INSTITUICAO foi criada no mesmo computador em que está a AC Raiz, o SGCI vai enviar automaticamente a requisição para a AC e a AR selecionadas. 2. Aprovação da requisição de certificado da AC Intermediária pela AR Vinculada 1. Saia do módulo de gerenciamento Criador. Entre como Operador da AR Vinculada, selecione o menu Gerenciamento de Requisições. Será exibida a requisição de certificado da AC INSTITUICAO. Clique na opção Informações para verificar se os dados estão corretos. Se estiverem corretos, selecione a requisição e clique em Aprovar selecionadas. 2. Na próxima tela, confirme se a entidade selecionada foi a correta, e digite a senha do operador da AR Vinculada.


131

3. Na próxima tela serão exibidas as requisições que já foram aprovadas pela AR Vinculada. 4. Como a AR Vinculada e a AC Raiz estão na mesma máquina, o SGCI envia automaticamente a requisição assinada para a AC Raiz. 3. Emissão do certificado da AC Intermediária pela AC Raiz 1. O próximo passo é emitir o certificado da AC Intermediária. Para isso, é necessário efetuar login como Operador da AC Raiz. Selecionar a opção Gerenciamento de Requisições. Será exibida a requisição da AC INSTITUICAO. 2. Selecione a requisição, e clique em Emitir certificados. 3. Selecione o template a ser aplicado no certificado, e digite a senha do operador da AC Raiz. 4. Serão exibidos os certificados emitidos pela AC Raiz. Faça o download do certificado da AC INSTITUICAO. 5. Como a AC Raiz e a AR Vinculada estão na mesma máquina, o SGCI envia automaticamente a resposta da requisição da AR Vinculada. 4. Importação do certificado da AC INSTITUICAO 1. Agora que o certificado da AC INSTITUICAO foi emitido, é necessário importar este certificado. Para isso, entre no módulo de gerenciamento Criador, escolha o menu Entidades e selecione a AC INSTITUICAO. 2. No campo Certificado, selecione o certificado salvo anteriormente. Digite a senha do criador, e clique em Cadastrar. 3. O próximo passo é cadastrar uma AR, para isso basta clicar no botão Cadastrar, em AR Vinculada. 4. Agora devem ser preenchidos os dados da AR Vinculada, digitando a senha do usuário criador no respectivo campo, e clicando em Cadastrar. O próximo passo é o cadastro de usuários. 5. Para cadastrar um usuário, é necessário selecionar a opção Usuários no menu, e em seguida a opção Cadastrar Novo Usuário. Os dados do novo usuário são preenchidos, e em seguida basta clicar em Cadastrar. Repita o processo para o usuário que será operador. 6. Após cadastrar os usuários, será atribuído a um deles o papel de Administrador. Para isso, seleciona-se no menu a opção Administradores, e a sub-opção Cadastrar Novo Administrador. 7. Na tela de cadastro de administradores, primeiro é necessário selecionar o usuário que se quer vincular ao papel de administrador, depois o tipo de entidade, a entidade, e finalmente colocar a senha deste usuário e a senha do criador. Após todos os dados preenchidos, basta clicar no botão Cadastrar.



132

8. Agora serão criados os Operadores. Primeiro você deve sair do módulo de gerenciamento Criador, e fazer login no módulo de gerenciamento Autoridade Certificadora, utilizando a função Administrador. Utilize o login e senha cadastrados nos passos anteriores. Depois, selecione o menu Operadores, e a opção Cadastrar Novo Operador. Será exibida a tela de cadastro de operadores. Selecione o usuário que deseja que se torne operador da AC INSTITUICAO, digite a senha deste usuário, e a senha do Administrador. Clique em Cadastrar. 9. Agora vamos editar as configurações da AC INSTITUICAO. Para isso, como Administrador, vá até o menu Política, e selecione a opção Editar Política. Selecione corretamente as configurações da AC INSTITUICAO, e clique em Atualizar. 10. Para cadastrar um novo template, o usuário deve se logar com o perfil de Administrador na AC INSTITUICAO, ir ao menu Política, e escolher a opção Cadastrar template. Selecione as opções corretamente, e clique no botão Cadastrar Template.

Atividade 2 – Criação da AR Instituição

Esta atividade foi desenvolvida para ser realizada em duplas, que devem compartilhar uma máquina. Cada pessoa deve trocar INSTITUICAO pelo nome da sua respectiva instituição. O aluno deve iniciar a máquina virtual VMware do sistema operacional Linux Ubuntu, e logar utilizando login icpedu e senha icpedu. A senha para o comando sudo (executar comando como administrador do sistema) também é icpedu. O exercício consiste em executar todos os passos para criação de uma AR Instituição no SGCI. Esta atividade pressupõe que a Atividade 1 da sessão 5 e a Atividade Criação da AR Instituição 1 da sessão 6 já foram executadas com sucesso. Procure entender a função de cada campo a ser preenchido no SGCI, associando-o com o conteúdo visto em aula. Não preencha os campos sem entendê-los, e em caso de dúvidas, consulte o instrutor.

1. Criação da AR INSTITUICAO 1. Abra o navegador e acesse o SGCI (http://localhost). Escolha o módulo de gerenciamento Criador. Entre com o usuário criador e a sua senha padrão, rnp. 2. Escolha o menu Entidades e a opção Cadastrar AR. 3. Escolha a Opção de Cadastro AR por geração de requisição, e preencha os dados da entidade. O nome da sua entidade deve ser AR INSTITUICAO (sem acentuação). Neste passo é selecionado o local para onde será enviada a requisição. Ela será enviada para alguma AR confiável da AC INSTITUICAO. Na atividade 2, foi criada uma AR Vinculada, de confiança da AC INSTITUICAO. Após todos os dados preenchidos, digite a senha do criador no campo correspondente, e clique em Cadastrar. Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 6

133

4. Como a requisição de certificado da AR INSTITUICAO foi criada no mesmo computador em que está a AC INSTITUICAO, o SGCI vai enviar automaticamente a requisição para a AC e AR selecionadas. 2. Aprovação da requisição de certificado da AR INSTITUICAO pela AR Vinculada 1. Saia do módulo de gerenciamento Criador. Entre como Operador da AR Vinculada da AC INSTITUICAO, selecione o menu Gerenciamento de Requisições. Será exibida a requisição de certificado da AR INSTITUICAO. Clique na opção Informações para verificar se os dados estão corretos. Se estiverem corretos, selecione a requisição e clique em Aprovar selecionadas. 2. Na próxima tela, confirme se a entidade selecionada foi a correta, e digite a senha do operador da AR Vinculada. 3. Na próxima tela serão exibidas as requisições que já foram aprovadas pela AR Vinculada. 4. Como a AR Vinculada e a AC INSTITUICAO estão na mesma máquina, o SGCI envia automaticamente a requisição assinada para a AC INSTITUICAO. 3. Emissão do certificado da AR INSTITUICAO pela AC INSTITUICAO 1. O próximo passo é emitir o certificado da AR. Para isso, é necessário efetuar login como Operador da AC INSTITUICAO. Selecione a opção Gerenciamento de Requisições. Será exibida a requisição da AR INSTITUICAO. 2. Selecione a requisição e clique em Emitir certificados. 3. S elecione o template a ser aplicado no certificado, e digite a senha do operador da AC INSTITUICAO. 4. S erão exibidos os certificados emitidos pela AC INSTITUICAO. Faça o download do certificado da AR INSTITUICAO. 5. C omo a AC INSTITUICAO e a AR Vinculada estão na mesma máquina, o SGCI envia automaticamente a resposta da requisição da AR Vinculada. 4. Importação do certificado da AR INSTITUICAO 1. Agora que o certificado da AR INSTITUICAO foi emitido, é necessário importar este certificado. Para isto, entre no módulo de gerenciamento Criador, escolha o menu Entidades e selecione a AR INSTITUICAO. 2. No campo certificado, selecione o certificado salvo anteriormente. Digite a senha do criador, e clique em Cadastrar. 3. O próximo passo é o cadastro de usuários. Para cadastrar um usuário, é necessário selecionar a opção Usuários no menu, e em seguida a opção Cadastrar Novo Usuário. Os dados do novo usuário são preenchidos, e em seguida basta clicar em Cadastrar. Repita o processo para o usuário que será operador.



134

4. Após cadastrar os usuários, será atribuído a um deles o papel de Administrador. Para isso, seleciona-se a opção Administradores no menu, e a sub-opção Cadastrar Novo Administrador. 5. Na tela de cadastro de administradores, primeiro é necessário selecionar o usuário que se quer vincular ao papel de administrador, depois o tipo de entidade, a entidade, e depois colocar a senha deste usuário, e a senha do criador. Após todos os dados preenchidos, basta clicar no botão Cadastrar. 6. Agora serão criados os Operadores. Primeiro você deve sair do módulo de gerenciamento Criador, e fazer login no módulo de gerenciamento Autoridade de Registro, utilizando a função Administrador. Utilize o login e a senha cadastrados nos passos anteriores. Depois, selecione o menu Operadores, e a opção Cadastrar Novo Operador. Será exibida a tela de cadastro de operadores. Selecione o usuário que deseja que se torne Operador da AR INSTITUICAO, digite a senha deste usuário e a senha do Administrador. Clique em Cadastrar.

Atividade 3 – Vincular a AR INSTITUICAO à AC INSTITUICAO 1. Para definir a AR INSTITUICAO como confiável pela AC INSTITUICAO, é necessário entrar no sistema como Administrador da AC INSTITUICAO, selecionar o menu Relações de Confiança, e clicar em Cadastrar Novo Relacionamento de Confiança. 2. Selecione Autoridade Interna, e serão apresentadas as ARs Internas do SGCI. Selecione a AR INSTITUICAO, e clique em Cadastrar.


7 Sessão de aprendizagem 7 Gerenciando o ciclo de vida de chaves criptográficas Sumário da sessão O que é um HSM?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Para que serve?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Ciclo de vida de Chaves Criptográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Características de um HSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Normas e Certificações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Conhecendo e Inicializando o ASI-HSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Por que mais um HSM?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 ASI-HSM – Diferenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 ASI-HSM – Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 ASI-HSM – Características. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 ASI-HSM – Boas práticas de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 ASI-HSM – Perfis de usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Preparando a instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Inicialização. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Preparação do HSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Preparação para uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Atividade 1 – Instalação e configuração do ASI-HSM. . . . . . . . . . . . . . . . . . . . 158

136


O que é um HSM?

O qque é um HSM? Significado Hardware Security Module Sinônimo MSC - Módulo de Segurança g ç Criptográfico p g “Conjunto Conjunto Hardware/Software voltado à proteção e gerência do ciclo de vida de chaves criptográficas”

O qque é um HSM? Hardware Hardware

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. A figura 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.

ASI- HSM AHX2

ASI- HSM AHX2


S ft Software

137

A figura ilustra o software de gerência de um HSM. O software em questão gerencia remotamente o ASI-HSM.

Software

Para qque serve? Proteger P t e gerenciar i o ciclo i l dde vida id dde chaves h criptográficas Por que proteger estas chaves? Algoritmos g ppúblicos Segurança está na chave Base para garantir: Autenticidade Integridade Sigilo Autoria

Precisam ser rigidamente controladas

Gerenciando o ciclo de vida de chaves criptográficas

Para que serve? 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. 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.

IInfraestruturas f t t d de Ch Chaves Públi Públicas “Segurança da ICP baseia-se na segurança de suas Escola Superior de Redes RNP chaves privadas”

138

Ch Chave comprometida tid

Estrutura comprometida

Infraestruturas de Chaves Públicas: “Segurança da ICP baseia-se na segurança de suas chaves privadas”

Em infraestruturas de chaves públicas, as chaves privadas são de vital inportâ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 p g Geração G ã Evitar chaves previsíveis Armazenamento Impedir divulgação e acesso não autorizado Controle sobre uso Nã permitir iti que a chave h j utilizada tili d sem a ddevida id Não seja permissão Manter registro de utilizações

Ciclo de vida de Chaves Criptográficas Para minimizar os riscos anteriormente citados para as chaves criptográficas, o HSM deve gerenciar uma série de aspectos relacionados com o ciclo de vida de chaves criptográficas. São eles: \\Geração

– O HSM deve garantir uma geração confiável, baseada em valores o mais aleatórios possíveis, visando a total imprevisibilidade de suas chaves;

\\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;

\\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.


139

Ciclo de vida de Chaves Criptográficas p g Backup/Recuperação B k /R ã Garantir segurança das cópias de chaves Garantir restauração apenas em ambientes confiáveis Manter rastreabilidade Destruição D t i as chaves h h id Destruir que chegaram ao fifim dda sua vida útil Garantir que essas chaves realmente foram destruídas

\\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. Esta 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.

\\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, este ainda é um problema em aberto, no que diz respeito à gerência de chaves. Isto 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 Hardware H d Sensores (fronteira criptográfica) Proteção física (lacre) Mitigação de ataques Registro completo de atividades T k t ti ã Tokens para autenticação Software Sistema Operacional Provedor de serviços criptográficos Interface de administração remota

Características de um HSM 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.


140

Escola Superior de Redes RNP 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 no mesmo. Conectado a este 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 Norma norte-americana (NIST) Define 4 níveis de segurança incrementais ICP Brasil ICP-Brasil Norma do governo brasileiro (ITI) V lt d para ICP Voltado Define 3 níveis de segurança incrementais Define 2 níveis de segurança física incrementais ISO Common Criteria

Conhecendo e Inicializando o ASI-HSM

Normas e Certificações 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 NIST (National Institute of Standards and Technology). A segunda é uma norma criada pelo governo brasileiro para homologação de soluções aptas a serem 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

Por que mais P i um HSM? ASI-HSM Diferenciais Componentes Características A it t Arquitetura Interna E t Externa

Perfis de Usuário


141

Conhecendo e Inicializando o ASI-HSM IInstalação t l ã Inicialização Conexão Definição de linguagem padrão Atividade P ã (Configuração) (C fi ã ) ddo HSM para uso Preparação

Por que mais um HSM?

Por qque mais um HSM?

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. Dentre tais características, podemos citar:

Problemas P bl d das soluções l õ atuais t i HSMs são caixas-pretas Difícil instalação e manuseio Sequestro de chaves Reserva de mercado?

Soluções importadas

\\HSMs

Alto custo Dificuldade de importação Criptografia forte?

Como confiar no que não se conhece?

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;

\\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;

\\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. Esta reserva de mercado faz com que as chaves estejam, de certa forma, sob a custódia de um fabricante. Desta 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;

\\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.


142


ASI-HSM – Diferenciais

ASI-HSM – Diferenciais Tecnologia T l i 100% nacional i l Parceria RNP + Kryptus + LabSEC Software livre Baixo custo Protocolo aberto A ditá l Auditável Amplamente documentado Artigo EuroPKI 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 uma auditoria precisa. Ainda, como principal diferencial do ASIHSM, 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

ASI-HSM – Componentes p Módulo Mód l C Criptográfico i t áfi Interface de Gestão Remota Cliente gráfico em Java Cliente texto em C Token para autenticação L it dde smartt cards d Leitora Conjunto de smart cards Engine OpenSSL Acesso aos serviços criptográficos

O ASI-HSM conta com os seguintes componentes: \\Modulo

criptográfico – Hardware dedicado à gerência de chaves;

\\Clientes

de Administração Remota – Estando disponíveis em duas versões, uma gráfica e outra em modo texto, que devem ser instaladas em uma máquina conectada ao HSM. Ambos permitem a configuração e manutenção do módulo, através de uma conexão SSL entre HSM e máquina host;

\\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. Este segredo é protegido por smart cards, possuindo assim um duplo fator de autenticação: posse do cartão e conhecimento de um PIN, para desbloqueio do mesmo;

\\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.


143

ASI-HSM – Características


\\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 uma 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:

Hardware Sensores

Luminosidade Variação de tensão Perfuração Violação (lacre) Temperatura

Interferência eletromagnética Gaiola de Faraday

TRNG RTC

\\Um

revestimento de seu perímetro, que evidencia qualquer tentativa de violação, tornando difícil recompor seu perímetro;

\\Um

sensor de temperatura, impedindo que o módulo possa ser submetido a temperaturas que provoquem seu mau funcionamento;

\\Um

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 utilizadas 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.

Arquitetura interna do ASI-HSM

Arquitetura interna do ASI-HSM Gerenciando o ciclo de vida de chaves criptográficas

144


A figura ilustra 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.

ASI-HSM – Características Arquitetura externa Interface de Gestão Remota Sistema Gerenciador de Certificados

SSL

OpenSSL Engine

Engine

Software

ASI-HSM

Host

Gerência de Chaves OpenHSM

BIO

ASI-HSM

Arquitetura externa 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, esta conexão é realizada via interface de rede (Ethernet). Na máquina host, encontram-se instaladas as aplicações cliente que interagirão 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.


145

ASI-HSM – Boas ppráticas de uso Manusear com cuidado M id d Sensores sensíveis a choques mecânicos Desligar somente pelo cliente de gestão remota Não desplugar abruptamente da fonte de energia Bateria interna substituível não-recarregável D ã de d até té 12 meses sem alimentação li t ã Duração Manter conectado a uma fonte de energia

ASI-HSM – Boas práticas de uso Para o bom funcionamento do módulo de segurança criptográfico, alguns pontos devem ser observados. Os pontos ressaltados mostram os cuidados a serem tomados para evitar que o HSM acuse invasão e podem ser conhecidos em detalhes no manual do usuário.

ASI-HSM – Boas ppráticas de uso Temperatura T t para armazenagem (d (desligado) li d ) Entre 0 e 45 graus celsius Temperatura de funcionamento (ligado) De 5 a 35 graus celsius Fonte bivolt automática (110V/220V) M t sobb ttensão ã estável tá l Manter

ASI-HSM – Perfis de usuário Perfil P fil dde Ad Administração i i t ã Criar grupo de administração Criar grupos de auditores Criar grupos de operadores Apagar HSM At li software ft ddo HSM Atualizar Desligar HSM Alterar data/hora do HSM Apagar logs (compartilhada por auditores) Alterar grupo de administradores


ASI-HSM – Perfis de usuário É 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 das mesmas a perfis de operação, que a partir daí controlarão seu uso.

146


ASI-HSM – Perfis de usuário Perfil P fil dde Ad Administração i i t ã Importar chave pública de backup Gerar/recuperar backup Gerar par de chaves assimétricas Delegar custódia de chave a um grupo de operação Alt t di t dde chave h Alterar grupo dde custodiantes Ativar grupos de operadores após backup

ASI-HSM – Perfis de usuário Perfil P fil dde A Auditoria dit i Exportar logs da unidade de gerência Log gerencial (atividades)

Exportar logs da unidade de segurança Log técnico (sensores)

Bloquear HSM q Recuperar backup (c/ administradores) Apagar logs (c/ administradores)

ASI-HSM – Perfis de usuário Perfil P fil dde O Operação ã Liberar chave para uso Definir políticas de utilização Tempo de uso Número de usos

Efetuar autoativação após restauração de backup (c/ 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.

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.


147

ASI-HSM – Perfis de usuário Operações O õ comuns Obter versão do software do HSM Obter data e hora do HSM Listar grupos de auditores Listar grupos de operadores Li t membros b dde grupos dde auditores dit Listar Listar membros de grupos de operadores Descarregar chave da memória Listar chaves

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

ASI-HSM – Perfis de usuário Operações O õ comuns Listar chaves carregadas Listar conteúdo de smart card Inicializar smart card Configurar HSM Alt PIN dde smartt cardd Alterar

Preparando p a instalação ç Material M t i l Módulo criptográfico (ASI-HSM) Fonte de alimentação

Máquina Host Interface de Gestão Remota Engine OpenSSL

Cabo de rede crossover Leitora de smart cards Smart cards


Preparando a instalação 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.

148


Instalação ç Conectar C t leitora l it à porta t USB do d HSM ((apenas AHX1) Colocar cartão na leitora Conectar HSM à máquina host via cabo ethernet Configurar IP da máquina host 192.168.1.5

Conectar fonte de alimentação ao HSM Ligar HSM Ob Observar estado d dda lleitora i

Inicialização ç Objetivo Obj ti Configurar idioma e conectar ao HSM Passos Executar interface de gestão remota

Instalação No caso do ASI-HSM AHX1, a leitora deverá ser conectada ao módulo, visto que trata-se de uma leitora externa. Na versão AHX2, a leitora é interna, podendo-se assim passar à próxima etapa. 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 finalizada, o HSM pode então ser ligado.

Inicialização 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.

ASI-HSM-Client.jar

Definir linguagem: Arquivo Ļ Preferências

Conectar ao HSM IP: 192.168.1.1 Porta: 5000

Verificar validade do Certificado SSL


ização ç 149

uagem

Linguagem

Definição da linguagem O HSM possui internacionalização em português e inglês, sendo que esta opção pode ser selecionada no menu Arquivo -> Preferências (Português) ou File -> Preferences (Inglês). A partir deste ponto, o texto será baseado na interface em inglês, enquanto os slides conterão as ilustrações correspondentes, na versão em português.


ação ç Escola Superior de Redes RNP

gem

Linguagem

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


150

zação ç 151

xão: ã etros

Conexão: parâmetros

Estabelecimento de conexão Inicialmente, pressiona-se o botão Connect to 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.


zação ç Escola Superior de Redes RNP

152

xão ã :

Conexão: SSL

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 desta 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.


zação ç 153

ão elecida

Conexão estabelecida

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

Preparação do HSM

Preparação p ç do HSM

O ASI-HSM pode ser preparado de duas maneiras:

Duas possibilidades D ibilid d Preparação para uso

\\Primeira

– Preparação como unidade operacional, que gerenciará o ciclo de vida de uma ou mais chaves criptográficas.

HSM será uma unidade operacional

Preparação como cópia de segurança HSM servirá como unidade de backup

HSM não

Preparação para uso

HSM Operacional Restauração

configurado Preparação para backup

HSM Backup


\\Segunda

– Preparação como unidade de backup. Neste caso o HSM será utilizado 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 HSM será uma unidade operacional

Preparação Escola Superior de Redes RNP

como cópia de segurança

154

HSM servirá como unidade de backup

HSM não

Preparação para uso

HSM Operacional Restauração

configurado Preparação para backup

Preparação p ç ppara uso Objetivo Obj ti Preparar HSM para gerenciar chaves criptográficas Passos Configurar data e hora Configurar parâmetros internos

HSM Backup

Preparação para uso 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.

Dados certificados internos Algoritmo padrão Tamanhos das chaves Endereço IP e porta de serviço Firewall


uração ç

155

Configuração

e hhora

Data e hora Configuração de data e hora 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.


156


HSM

HSM será reiniciado após a aplicação das configurações

ciado após a aplicação das configurações

Configuração dos parâmetros internos do HSM Nesta 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 auto-testes realizados.


7 Sessão de aprendizagem 7 Gerenciando o ciclo de vida de chaves criptográficas Roteiro de atividades Tópicos e conceitos \\ Preparação \\ Instalação

da instalação

do módulo

\\ Conexão

com o HSM (SSL)

\\ Definição

da linguagem

\\ Configuração

dos parâmetros internos

Competências técnicas desenvolvidas \\Conhecimento

sobre o processo de instalação e configuração inicial do ASI-HSM


minutos

Servidor de sala de aula \\Disponibilizar

arquivo “ASI-HSM GUI vx.x.jar”

158


Atividade 1 – Instalação e configuração do ASI-HSM

Material necessário: \\ Módulo \\ Fonte

criptográfico (ASI-HSM);

de alimentação;

\\ Máquina

host;

\\ Interface

de gestão remota;

\\ Engine \\ Cabo

OpenSSL;

de rede crossover;

\\ Leitora \\ Smart

de smart cards;

cards.

1. Passos para instalação: \\ Conectar \\ Colocar

leitora à porta USB do HSM (apenas modelo AHX1);

cartão na leitora;

\\ Conectar

HSM à máquina host via cabo ethernet;

\\ Configurar \\ Conectar \\ Ligar

IP da máquina host com valor: 192.168.1.5;

fonte de alimentação energizada ao HSM;

HSM;

\\ Observar

estado da leitora.

2. Passos para inicialização: \\ Executar \\ Definir

interface de gestão remota (dois cliques em “ASI-HSM GUI vx.x.jar”).

linguagem:

\\ Arquivo \\Conectar \\ Clicar \\Manter \\ IP:

g Preferências

ao HSM: no botão no centro da tela.

as configurações padrão de IP e porta:

192.168.1.1

\\ Porta: \\Verificar

5000

certificado SSL (túnel seguro).


159

3. Passos para a configuração: \\Configurar \\ Menu

data e hora:

lateral SistemagHoráriogAlterar Horário do HSM

\\ Digitar

hora UTC e clicar em OK;

\\Configurar \\ Dados

parâmetros internos (manter valores padrão): certificados internos

\\ Algoritmo

padrão

\\ Tamanhos

das chaves

\\ Endereço

IP e porta de serviço

\\ Firewall \\ Clique

em Aplicar;

\\ Aguarde \\ Repita

o HSM reiniciar (cerca de 2 minutos);

passo 2 (conexão com HSM em diante);

\\ Acesse

novamente o menu de configuração de parâmetros internos;

\\ Perceba

que está desabilitado (HSM já configurado).

Mais informações Manual técnico do ASI-HSM, disponível em: http://projetos.labsec.ufsc.br/openhsmd




160

8 Sessão de aprendizagem 8 Utilizando o ASI-HSM Sumário da sessão Criação dos perfis de usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Criação de Administradores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Demais perfis (Audit e Oper). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Geração e liberação de chave para uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Geração de chaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Liberação (carga) de chaves para uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Listar chaves carregadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Exportação de logs gerenciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Procedimento de backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Preparação para backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Importação da chave de backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Geração de backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Restauração de backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Ativar perfis de operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Atividade 1 – Criação de perfis de Usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Atividade 2 – Geração de Chave RSA e liberação para uso. . . . . . . . . . . . . . . 196 Atividade 3 – Exportar registros de logs gerenciais. . . . . . . . . . . . . . . . . . . . . 197 Atividade 4 – Procedimento de backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

162


Criação ç dos pperfis de usuário

Criação dos perfis de usuário

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

Criação ç de Administradores Criação de Administradores

Inicialmente deve-se acessar o item “Accounts and Keys” e, em seguida, “Administrators”, ambos localizados no canto superior esquerdo da tela principal. Deve-se então acessar a aba “Create Administrators”. 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 “Create Administrators Group”. Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 8

Criação ç de Administradores 163

É exibido um 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”.

Utilizando o ASI-HSM

Criação ç de Administradores Escola Superior de Redes RNP

164

Nos passos seguintes, deve-se inserir o PIN para proteger o uso do smart card do membro. Este valor deve ser numérico e estar entre a faixa 1000 e 99999999.



Em seguida, é solicitada a entrada de um “Common Name”, que identificará o membro do perfil. Este campo deverá conter apenas caracteres ASCII, sendo proibidos caracteres especiais.




Após efetuar-se tal processo para cada um dos “m” smart cards, um diálogo é exibido, informando o sucesso na criação do grupo de administradores.

Demais pperfis ((Audit e Oper) p ) Processo análogo P ál Diferença Autenticação dos administradores

Sequência q obrigatória g Auditores Operadores

Cardinalidade de perfis ativos no HSM Administradores: 1 Operadores: N A dit Auditores: N

Demais perfis (Audit e Oper) 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 “Accounts and Keys”, “Auditors” e “Create Auditors”. Em seguida, deve-se criar o perfil de Operação, disponível no menu “Accounts and Keys”, “Operators” e “Create Operators”.


167

Geração ç e liberação ç de chave para p uso

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

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

Geração ç de chaves

Geração de chaves

O processo de criação de chaves através da interface gráfica se inicia acessandose o item “Accounts and Keys” e, em seguida, “Keys”, ambos localizados no canto superior esquerdo da tela principal. Em seguida, definem-se um nome para a chave e o identificador do grupo de operadores que será responsável por ela. Logo, pressiona-se o botão “Generate Key”.


Geração ç de chaves Escola Superior de Redes RNP

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


168

Geração ç de chaves 169

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 de 2048 bits, o HSM pode levar cerca de 1 minuto para concluir a geração.


Geração ç de chaves Escola Superior de Redes RNP

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


170

Liberação ç (carga) ( g ) de chaves ppara uso

171

Liberação (carga) de chaves 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 pela custódia da mesma se autentique. Para isto, acessam-se os itens “Accounts and Keys” e “Keys”. Em seguida, a aba “Load Key”. No primeiro campo de texto entra-se 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 abaixo encontra-se a unidade de tempo desejada. No último campo define-se um número limite de usos antes que 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 “Load Key”.


Liberação ç (carga) ( g ) de chaves ppara uso Escola Superior de Redes RNP

É 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.


172

Liberação ç (carga) ( g ) de chaves ppara uso 173

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


Listar chaves carregadas g Escola Superior de Redes RNP

174

Listar chaves carregadas

Para listar chaves liberadas para uso, inicialmente acessam-se os itens “Accounts and Keys” e “Keys” e, em seguida, a aba “List Loaded Keys”. Por último, pressiona-se o botão “List Key” e um diálogo contendo informações a respeito da chave é exibido.


Listar chaves carregadas g 175

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 da mesma, caso tenha sido definido o limite de usos.


176


Exportação p ç de logs g gerenciais g

Exportação de logs gerenciais

Objetivo Obj ti Extrair logs internos do HSM para posterior análise por parte dos auditores Passos Exportar registros de logs para máquina hospedeira

Exportação p ç de logs g ggerenciais

Inicialmente, acessa-se o menu “Accounts and Settings” e, em seguida, o item “Auditors”, na aba “Export MU Logs”. Em seguida entra-se com o período (data de início e fim no formato MM/DD/AAAA) desejado, como forma de filtrar os logs a serem exportados. Caso estes campos não sejam preenchidos, todos os registros serão exportados. Logo, na caixa de seleção abaixo dos campos de data, escolhe-se um dos grupos de auditores disponíveis e pressiona-se o botão “Export MU Logs”.


Exportação p ç de logs g ggerenciais 177

Uma janela será aberta para possibilitar a escolha do arquivo de destino contendo os registros de logs exportados. Este 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. Indica-se a ferramenta “Cryptonit” para tal fim.


Exportação p ç de logs g ggerenciais Escola Superior de Redes RNP

178

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


Exportação p ç de logs g ggerenciais 179

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


180


Procedimento de backupp Objetivo Obj ti Replicar o ambiente operacional de um HSM em um novo HSM, permitindo a continuidade do ciclo de vida de chaves, em caso de indisponibilidade do primeiro Passos Preparar HSM para backup Importar chave de backup em HSM operacional E Exportar t iimagem dde bbackup k Restaurar backup em HSM preparado Ativar perfis de operação

rocedimento de backupp B k di Backup direcionado i d

Procedimento de backup 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 será cifrado com a chave pública de backup do HSM, sendo que se for a do perímetro criptográfico, a cópia da chave sempre estará protegida por criptografia forte.

Backup direcionado


Preparação p ç ppara backupp

181

Preparação para backup

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


Preparação p ç ppara backupp Escola Superior de Redes RNP

O primeiro passo do processo é a escolha do destino da chave pública a ser exportada, em formato PEM, na máquina hospedeira.


182

Preparação p ç ppara backupp 183

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


mportação p ç da chave de backupp Escola Superior de Redes RNP

184

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 “Accounts and Keys” e em seguida “Administrators”, na aba “Import Backup Key”.


Importação p ç da chave de backupp 185

Ao clicar no botão “Import Backup Key”, será solicitada a seleção do arquivo que contém a chave pública de backup.


mportação p ç da chave de backupp Escola Superior de Redes RNP

Em seguida, será solicitada a autenticação dos “n” administradores que recomporão o segredo do perfil, para possibilitar a importação da chave.


186

Importação p ç da chave de backupp 187

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


Geração ç de backupp Escola Superior de Redes RNP

188

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 “Accounts and Keys”, “Administrators,” na aba “Backup”. Em seguida, deve-se clicar no botão “Generate Backup”.


Geração ç de backupp 189

Será exibido então um diálogo de escolha do destino do arquivo de backup, na máquina hospedeira.


Geração ç de backupp Escola Superior de Redes RNP

190

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


Geração ç de backupp 191

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


Restauração ç de backupp Escola Superior de Redes RNP

192

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 isto, deve-se acessar o menu “Accounts and Keys”, “Administrators”, na aba “Restore Backup”. Em seguida, deve-se clicar no botão “Restore Backup”.


Restauração ç de backupp 193

HSM será reiniciado após restauração do 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.


Ativar pperfis de operação p ç Escola Superior de Redes RNP

194

Ativar perfis de operação

Até o momento, somente dois dos três perfis presentes no HSM ficaram necessariamente 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 operacional em execução. Esta tarefa devolverá ao perfil de administração a capacidade de alterar a custódia de uma chave privada e de um perfil de operação para outro.


8 Sessão de aprendizagem 8 Utilizando o ASI-HSM Roteiro de atividades Tópicos e conceitos \\ Criação

de perfis de usuário

\\ Geração

e liberação de chaves para uso

\\ Exportação

de logs gerenciais

\\ Procedimento \\ Ativação

de backup

do Perfil de Operação

Competências técnicas desenvolvidas \\Utilização

do ASI-HSM, conhecimento de suas principais funcionalidades, bem como as responsabilidades de cada um dos perfis presentes no módulo.


minutos

Servidor de sala de aula \\ Disponibilizar

arquivo “ASI-HSM GUI vx.x.jar”

\\ Disponibilizar

máquina virtual

196


Atividade 1 – Criação de perfis de Usuário 1. Conectar ao HSM (executar cliente de gestão remota); 2. Acessar menu lateral Chaves e Contas de UsuáriogAdministradores; 3. Acessar aba Criar Administradores; 4. Entrar com os valores de “n=2” (quantidade mínima de membros do perfil); 5. Entrar com “m=3” (tamanho total do perfil); 6. Clicar no botão Create Administrators Group. Com os valores acima, o Perfil de Administração precisará de dois de seus três membros para recompor o perfil e atuar sobre o HSM. 7. Inserir smart card vazio na leitora (Administrador 1) e clicar em OK; 8. D igite um PIN para proteger o uso do smart card (necessário na autenticação), com valor entre 1000 e 99999999 e clique em OK (Ex: 1234); 9. D igite um nome comum para o Administrador 1 e clique (Ex: Administrador 1); 10. Aguardar a mensagem de sucesso. O procedimento pode levar alguns minutos, dependendo do tamanho de chave escolhido no momento da configuração. Na criação dos demais perfis, o procedimento a ser seguido é análogo. Há apenas um passo a mais, relativo à autenticação dos recém-criados administradores, responsáveis pela criação dos demais perfis. Devem ser criados os auditores e em seguida, os administradores, obrigatoriamente. \\ Auditores:

menu lateral Chaves e Contas de UsuáriogAuditores

\\ Operadores:

menu lateral Chaves e Contas de UsuáriogOperadores

Atividade 2 – Geração de Chave RSA e liberação para uso

Gerar chave 1. Acesse o menu lateral Chaves e Contas de UsuáriogChaves; 2. Acesse a aba Gerar Chave; 3. Entre com um nome para a chave. Exemplo: chave-raiz; 4. Selecione um perfil de Operação para ser responsável pela chave a ser criada (manter opção padrão); 5. Escolha um tamanho para a chave (manter opção padrão); 6. Clique no botão Gerar Chave;


197

7. Autentique os Administradores, inserindo o smart card de 2 dos 3 componentes e digitando seus respectivos PINs; 8. Aguarde a mensagem de sucesso.

Liberar para uso 1. Acesse o menu lateral Chaves e Contas de UsuáriogChaves; 2. Acesse a aba Listar Chaves Carregadas; 3. Selecione a chave a ser carregada pelo nome. Ex: chave-raiz; 4. D efina a política de carga da chave. Esta pode ser por tempo, por número de usos, por ambos ou nenhum deles. No primeiro caso, a chave será automaticamente descarregada quando o limite de tempo for atingido. No segundo, será descarregada quando já tiver sido usado o limite determinado de vezes. Para esta demonstração, contudo, a chave será carregada por tempo infinito, sem limite de usos, devendo-se para isso marcar as respectivas opções, acima do botão Carregar Chave; 5. Clique no botão Carregar Chave; 6. Verifique na janela que se abrirá os atributos da chave carregada.

Atividade 3 – Exportar registros de logs gerenciais 1. Acessar o menu lateral Chaves e Contas de UsuáriogAuditores; 2. Acessar a aba Exportar Logs da UG; 3. D efinir a data de início e de fim no formato MM/DD/AAAA. Para exportar todos os registros, deixe em branco; 4. Selecione um grupo de auditores, que assinará os registros de log; 5. Clique em Exportar os Logs da UG; 6. U ma janela será aberta para possibilitar a escolha de um destino para o arquivo. Escolha um destino e um nome para o arquivo e clique em Salvar. 7. E m seguida, será solicitada a autenticação do grupo de auditores escolhido. Autenticar o mínimo do grupo, entrando com seus smart cards e respectivos PINs quando solicitado; 8. Aguardar a exibição da mensagem de sucesso.



198

Atividade 4 – Procedimento de backup

Preparação de HSM para backup 1. Conectar a um HSM não configurado, que servirá como unidade de backup (desplugar o cabo ethernet do HSM em operação e plugar na unidade de backup); 2. Acessar o menu lateral SistemagPreparar para Backup; 3. Clicar no botão Preparar para backup; 4. S elecionar o destino para a chave de backup, que será exportada com a execução do procedimento; 5. Aguardar a exibição da mensagem de sucesso. A partir deste ponto, a unidade de backup está capacitada a receber qualquer backup que tenha sido cifrado com o uso de sua chave.

Importar chave de backup em Unidade Operacional 1. Conectar ao HSM em operação; 2. Acessar menu lateral Chaves e Contas de UsuáriogAdministradores; 3. Acessar a aba Importar Chave Pública; 4. Clicar no botão Importar Chave Pública; 5. N a janela que se abrirá, selecionar o arquivo a partir do qual a chave será carregada; 6. A utenticar o mínimo do grupo de administradores, entrando com os smart cards e respectivos PINs, quando solicitado; 7. Aguardar a mensagem de sucesso. A partir deste momento, o HSM em operação já se encontra capacitado a gerar cópias de backup, o que será realizado na próxima atividade.

Geração de backup 1. Acessar menu lateral Chaves e Contas de UsuáriogAdministradores; 2. Acessar aba Backup; 3. Clicar no botão Fazer o backup; 4. Selecionar o arquivo de destino da imagem de backup; 5. A utenticar o mínimo de componentes necessários para compor o perfil de administração; 6. Aguardar a exibição da mensagem de sucesso.


199

Restauração de backup 1. Conectar ao HSM preparado para backup; 2. Acesse o menu lateral Chaves e Contas de UsuáriogAdministradores; 3. Acessar aba Recuperar Backup; 4. E ntrar com o nome de um dos grupos de auditoria presentes no HSM em operação. Este grupo deverá se autenticar para liberar a restauração de backup; 5. Selecionar o arquivo contendo a imagem de backup do HSM operacional; 6. Clicar no botão Recuperar o Backup; 7. S erá solicitada a autenticação dos perfis de administração e auditoria, respectivamente; 8. Aguardar exibição da mensagem de sucesso; 9. O HSM será reiniciado após a conclusão do procedimento. Após a restauração do backup, os HSMs possuirão exatamente os mesmos perfis e chaves gerenciadas. Contudo, para que estejam em estados completamente idênticos, é necessário ainda ativar os perfis de operação.

Ativar Perfis de Operação Até o presente momento, somente dois dos três perfis presentes no HSM ficaram, necessariamente cientes (via autenticação) da segunda cópia operacional do HSM. Para que o perfil de Operação possua também esta ciência, é 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 operacional em execução. Esta tarefa devolverá ao perfil de administração a capacidade de alterar a custódia de uma chave privada, de um perfil de operação para outro. 1. Acessar menu lateral Chaves e Contas de UsuáriogOperadores; 2. Acessar aba Ativar Grupo; 3. Selecionar o perfil de operação a ser ativado; 4. Clicar em Ativar Grupo de Operadores; 5. Autenticar o perfil de Operação em questão; 6. Autenticar o perfil de Administração; 7. Aguardar exibição de mensagem de sucesso.

Mais informações Manual técnico do ASI-HSM, disponível em: http://projetos.labsec.ufsc.br/openhsmd




200

9 Sessão de aprendizagem 9 Simulação de Credenciamento – etapa 1 Sumário da sessão Atividade final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Atividade final - Fluxo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Atividade 1 – Preparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Atividade 2 – Criação do par de chaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

202


Atividade final

Atividade final

Nesta N t sessão, ã seráá realizada li d uma simulação i l ã de d credenciamento de uma AC Institucional à ICPEDU Esta atividade tem como pré-requisitos todas as sessões anteriores e envolverá os conceitos de: Infraestrutura de Chaves Públicas Hardware criptográfico Software de Gerenciamento de Certificados Digitais Cerimônias e procedimentos práticos de credenciamento

A realização desta atividade é fundamental para a compreensão p de todo o conteúdo abordado durante o curso

Atividade final Etapa 1 Et Na primeira etapa simularemos o primeiro dia de uma cerimônia de criação da AC Instituição Nesta pprimeira pparte serão realizadas: Configuração do sistema (SGCI + HSM) Geração da requisição da instituição Envio da requisição para a AR (neste caso, o professor)


Atividade final - Fluxo Atividade final - Fluxo

Simulação de Credenciamento – etapa 1

203



204

9 Sessão de aprendizagem 9 Simulação de Credenciamento – etapa 1 Roteiro de atividades Tópicos e conceitos \\Credenciamento

de instituição

\\Cerimônia \\ Integração

de SGCI com HSM

Competências técnicas desenvolvidas \\ Conhecer \\Entender

o processo de credenciamento o funcionamento da integração do SGCI com o HSM RNP


minutos

206


Atividade 1 – Preparação

O objetivo desta atividade é simular o processo de emissão dos certificados de Autoridades Certificadoras das Instituições da ICPEDU. Para esta atividade, recomenda-se que cada participante se reúna com os outros membros da mesma instituição e realizem a tarefa juntos, em apenas um computador. A sequência de itens abaixo representa uma cerimônia simplificada, que deve ser executada por cada grupo. Importante: vários passos de uma cerimônia foram removidos para se adequarem ao ambiente que temos para o curso. É muito importante que alguns deles sejam feitos no dia da cerimônia real, tais como: modificação de senha do usuário criador do SGCI, elaboração de ata, anotar senhas e PINs em envelopes, lacrá-los e armazená-los em cofre etc. 1. Preparação da estação hospedeira: 1.1. Ajustar data e hora. 1.2. Configurar o HSM: 1.2.1. Ajustar data e hora do sistema; 1.2.2. Definir configurações iniciais; 1.2.3. Criar Administradores; 1.2.4. Criar Auditores; 1.2.5. Criar Operadores. 1.3. Configurar o SGCI: 1.3.1. Acessar como criador: \\Cadastrar

o HSM.

\\Comandos:

ADDRESS_CONN=192.168.1.1 (consultar o IP correto com o instrutor) PORT_CONN=5001 (consultar a porta correta com o instrutor)

Atividade 2 – Criação do par de chaves 1. Ligar estação hospedeira. 2. Ligar o HSM. 2.1. Criar o par de chaves da AC; 2.2. Liberar chave para uso. Introdução a Infraestrutura de Chaves Públicas e Aplicações – Sessão de aprendizagem 9

207

3. Acessar como criador do SGCI: 3.1. Criar a requisição para a AC da Instituição. 3.1.1. Valores para os campos: \\ Nome

Comum: AC

\\Organização:

ICPEDU

\\Organização:

RNP

\\ Cidade: \\País:

Cidade da Instituição

BR

3.1.2. Gerar requisição. 4. Exportar a requisição para uma mídia (pendrive, por exemplo). 5. Fazer backup do SGCI. 6. Enviar requisição para o GOPAR. Após a realização do passo 6, leve a requisição aos intrutores que estarão com uma máquina que simulará a AR Raiz e a AC Raiz.




208

10 Sessão de aprendizagem 10 Simulação de Credenciamento – etapa 2 Sumário da sessão Atividade final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Atividade final - Fluxo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Roteiro de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Atividade 1 – Importar o certificado emitido . . . . . . . . . . . . . . . . . . . . . . . . . 214 Atividade 2 – Emitir um certificado para usuários/ACs credenciadas. . . . . . . . 214

210


Atividade final

Atividade final

Esta E t sessão ã apresenta t a segunda d etapa t ddas atividades ti id d iniciadas na Sessão de Aprendizagem 9 Esta sessão prevê a emissão do Certificado Digital da AC Instituição e o posterior uso do sistema

Atividade final Etapa 2 Et Nesta etapa simularemos o segundo dia de uma cerimônia de criação da AC Instituição Importação do certificado emitido pela AC Raiz Emissão de certificados e LCRs para simulação do dia-a-dia da AC


Atividade final - Fluxo Atividade final - Fluxo


211



212

10 Sessão de aprendizagem 10 Simulação de Credenciamento – etapa 2 Roteiro de atividades Tópicos e conceitos \\ Credenciamento

de instituição

\\ Cerimônia \\ Integração

de SGCI com HSM

Competências técnicas desenvolvidas \\ Conhecer \\ Entender

o processo de credenciamento o funcionamento da integração do SGCI com o HSM RNP


minutos

214


Atividade 1 – Importar o certificado emitido 1. Ligar o HSM. 2. Ligar o SGCI. 2.1. Importar o certificado da AC Instituição; 2.2. Criar a AR Vinculada da Instituição; 2.3. Cadastrar usuário que será o administrador da AC; 2.4. Atribuir ao usuário criado o papel de administrador da AC; 2.5. Cadastrar o usuário que será o administrador da AR Vinculada; 2.6. Atribuir ao usuário criado o papel de administrador da AR Vinculada; 2.7. Acessar como administrador AC: 2.7.1. Cadastrar usuário que será operador de AC. 2.8. Acessar como administrador AR: 2.8.1. Cadastrar usuário que será operador de AR. 2.9. Acessar como operador AC: 2.9.1. Emitir LCR. 3. Fazer backup do SGCI.

Atividade 2 – Emitir um certificado para usuários/ACs credenciadas 1. Ligar o HSM. 2. Ligar o SGCI. 2.1. Acessar como operador da AR Vinculada; 2.1.1. Importar a requisição; 2.1.2. Aprovar requisição. 2.2. Acessar como operador AC: 2.2.1. Emitir certificado. 2.3. Acessar como criador: 2.3.1. Fazer backup.


Bibliografia \\HOUSLEY,

R.; POLK, T. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. John Willey & Sons.

\\HOUSLEY,

R. et all. RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF, 2008.

\\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.

\\MOULDS,

R. Key Management for Dummies. 1 ed. Wiley Publishing, Inc.

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.

\\SOUZA,

\\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).

\\SCHNEIER,

B. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2 ed. John Willey & Sons, 1995.

\\STALLINGS,

W. Cryptography and Network Security: Principles and Practice. 4 ed. Pearson Education, 2005.

\\Manual

técnico do ASI-HSM: http://projetos.labsec.ufsc.br/openhsmd/attachment/wiki/WikiStart/Manual-doUsuario-OpenHSM-v0.9.pdf

\\Site

de projetos SGCI: https://projetos.labsec.ufsc.br/sgci


216

Conheça a Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEDU) e aprenda a implantar Autoridades Certificadoras e de Registro Introdução a Infraestrutura de Chaves Públicas e Aplicações O projeto ICPEDU tem como objetivo 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.

esr.rnp.br

Introducao a Infraestrutura de Chaves Publicas e Aplicacoes

Recommend Documents