Infra-estrutura de Chave Pública

Infra-estrutura de Chave Pública

PKI

Public Key Infrastructure

Abril de 2006 Infra-estrutura de Chave Pública 2

Criptografia de Chave Pública

• A criptografia de chave simétrica (duas pessoas) pode manter seguros seus segredos, mas se precisarmos compartilhar informações secretas com duas ou mais, devemos também compartilhar as chaves.


Distribuição de Chaves

• O problema da distribuição de chaves:

Como duas ou mais pessoas podem, de maneira segura, enviar as chaves por meio de linhas inseguras.

• Como as pessoas podem de maneira segura enviar informações sigilosas por meio de linhas inseguras ?



• Antes de utilizar, deve-se lidar com os problemas tais como:

- gerenciamento de chaves,

- distribuição de chaves.


Gerenciamento de Chaves

• O que é gerenciamento de chaves ?

• É o processo de gerar, proteger, armazenar, e manter histórico para utilização de chaves.


Gerenciamento de Chaves

• Gerar pares de chaves

• Proteger chaves privadas

• Controlar múltiplos pares de chaves

• Atualizar pares de chaves

• Manter um histórico de pares de chaves.



• Oferece criptografia e também uma maneira de identificar e autenticar (através de assinatura) pessoas ou dispositivos.



• Principal questão:

Não somente confidencialidade.

Mas a principal questão é a integridade (uma chave é suscetível à manipulação durante o trânsito) e a posse de uma chave pública.



• Como obter uma chave pública e numa comunicação certificar-se de que essa chave tenha sido recebida da parte intencionada ?

• Resposta: certificados de chave pública


Introdução aos Certificados

• Com Criptografia de Chave Pública e Assinatura Digital:

pessoas podem utilizar a chave pública de uma outra pessoa;

.


Criptografia de Chave Pública e Assinatura Digital

• Para enviar uma mensagem segura a uma pessoa, tomamos a chave pública dessa pessoa e criamos um envelope digital.

• Para verificar a mensagem de uma pessoa, adquire-se a chave pública dessa pessoa e verifica-se a assinatura digital.


Assinatura com Chave Pública

Chave Privada

DA

Chave Pública

EB

Chave Privada

DB

Chave Pública

EB

P

DA(P) DA(P)EB(DA(P))

Computador A Computador B

P

rede

Assume-se que os algoritmos de criptografia e decriptografia têm a propriedade que: EB( DA(P) ) = P e DA( EB(P) ) = P, onde DA(P) é a assinatura do texto plano P com a

chave privada DA e EB(P) é a verificação da assinatura com a chave pública EB . O algoritmo RSA tem esta propriedade.


A quem pertence a chave pública ?

• Mas, como uma pessoa qualquer pode saber se uma chave pública pertence a

uma entidade de destino ?

• Veja dois exemplos.



• Quando se envia uma mensagem a uma entidade de destino, como se pode ter certeza que a chave pública utilizada pertence mesmo a essa entidade ?



• Quando se verifica uma assinatura com uma chave pública, como se pode ter certeza que a chave pública utilizada pertence mesmo a uma determinada entidade de destino ?


Exemplo de Invasão 1

• João tem a chave pública de Tati. A chave funciona. Ele é capaz de criar um envelope digital e se comunicar com Tati que é possuidora da chave privada relacionada à chave pública em poder de João.



• Mas se Camila, de alguma maneira, invade o computador de João e substitui a chave pública de Tati pela chave pública dela, quando João enviar o envelope digital, Camila será capaz de interceptá-lo e lê-lo. Tati não será capaz de abri-lo porque ela não tem a chave privada parceira da chave pública utilizada.



• Na empresa onde João e Daniel trabalham tem um diretório centralizado que armazena as chaves públicas de todas as pessoas.

• Quando Daniel quiser verificar a assinatura de João, ele vai ao diretório e localiza a chave de João.



• Mas se Camila tiver invadido esse diretório e substituído a chave pública de João pela dela, ela poderá enviar uma mensagem fraudulenta ao Daniel com uma assinatura digital válida.

• Daniel pensará que a mensagem veio de João, porque verificará a assinatura contra o que ele pensa ser a chave pública de João.


Certificado Digital

• A maneira mais comum de saber se uma chave pública pertence ou não a uma entidade de destino (uma pessoa ou empresa) é por meio de um certificado digital.

• Um certificado digital associa um nome de entidade a uma chave pública.


Estrutura Básica de um Certificado

Assinatura CA

Assinatura CA

Nome

ChavePública

Mensagem

Certificado


Percepção à Fraude

• Um certificado é produzido de tal maneira que o torna perceptível se um impostor pegou um certificado existente e substituiu a chave pública ou o nome.

• Qualquer pessoa ao examinar esse certificado saberá se está errado.


Fraude

• Talvez o nome ou a chave pública esteja errado;

• Portanto, não se pode confiar nesse certificado, ou seja, o par (nome,chave).


Como tudo funciona

• Tati gera um par de chaves: (chave-privada, chave-pública).

• Protege a chave privada.

• Entra em contato com uma Autoridade de Certificação (CA), solicitando um certificado.


Como tudo funciona

• CA verifica se Tati é a pessoa que diz ser, através de seus documentos pessoais.

• Tati usa sua chave privada para assinar a solicitação do certificado.


Como tudo funciona

• CA sabe, então, que Tati tem acesso à chave privada parceira da chave pública apresentada, assim como sabe que a chave pública não foi substituída.


Como tudo funciona

• CA combina o nome Tati com a chave pública em uma mensagem e assina essa mensagem com sua chave privada (de CA).

• Tati agora tem um certificado e o distribui.Por exemplo, para João.


• Portanto, quando João coletar a chave pública de Tati, o que ele estará coletando será o certificado dela.

• Supondo que Camila tente substituir a chave pública de Tati, pela sua própria chave.


Como tudo funciona

• Ela pode localizar o arquivo da chave pública de Tati no laptop de João e substitui as chaves.

• Mas, João, antes de usar o certificado, utiliza a chave pública de CA para verificar se o certificado é válido.


Como tudo funciona

• Pelo fato da mensagem no certificado ter sido alterada (houve troca da chave pública dentro do certificado), a assinatura não é verificada.

• Portanto, João não criará um envelope digital usando essa chave pública e Camila não será capaz de ler qualquer comunicação privada.


Como tudo funciona

• Esse cenário assume que João tem a chave pública de CA e tem a certeza de que ninguém a substituiu com a chave de um impostor.

• Pelo fato dele poder extrair a chave do certificado da CA, ele sabe que tem a verdadeira chave pública de CA.



• Usuários Finais

• Partes Verificadoras: aquelas que verificam a autenticidade de certificados de usuários finais.



• Para que usuários finais e partes verificadoras utilizem essa tecnologia, chaves públicas devem ser fornecidas uns aos outros.

• Problema: uma chave é suscetível de ataque durante o trânsito.



• Ataque:

Se uma terceira parte desconhecida puder substituir uma chave qualquer por uma chave pública válida, o invasor poderá forjar assinaturas digitais e permitir que mensagens criptografadas sejam expostas a partes mal intencionadas.



• Distribuição manual

• Solução apropriada: - certificados de chave pública

• Fornecem um método para distribuição de chaves públicas.



• Um certificado de chave pública (PKC) é um conjunto de dados à prova de falsificação que atesta a associação de uma chave pública a um usuário final.

• Para fornecer essa associação, uma autoridade certificadora (CA), confiável, confirma a identidade do usuário.



• CAs emitem certificados digitais para usuários finais, contendo nome, chave pública e outras informações que os identifiquem.

• Após serem assinados digitalmente, esses certificados podem ser transferidos e armazenados.



• Tecnologia para utilizar PKI:

(1) Padrão X.509

(2) Componentes de PKI para criar, distribuir, gerenciar e revogar certificados.


Certificados de Chave Pública

• Um meio seguro de distribuir chaves públicas para as partes verificadoras dentro de uma rede.

• Pretty Good Privacy (PGP)• SET• IPSec• X.509 v3 (ITU-1988, 1993, 1995,

IETF-RFC2459-1999)



Estrutura de Certificado X.509



1. Versão

2. Número Serial

3. Identificador do algoritmo de assinatura

4. Nome do Emissor – nome DN da CA que cria e emite.

5. Validade



6. Nome do Sujeito – nome DN da entidade final (usuário ou uma empresa).

7. Informação da Chave Pública do sujeito: (valor da chave, identificador do algoritmo, parâmetros do mesmo)



8. Identificador único do emissor:

(não recomendado pela RFC 2459)

9. Identificador único do sujeito: (não recomendado pela RFC2459)



10. Extensões v3 Identificador de Chave de Autoridade

para qualquer certificado auto-assinado. Identificador de Chave de Sujeito

Utilização de chave



Utilização de Chave Estendida: Para uso de aplicativos e protocolos (TLS, SSL, ...), definindo as utilizações da chave pública para servidores de autenticação, autenticação de cliente, registro de data/hora e outros.



Ponto de distribuição de CRL



Período de uso de chave privada:

(não recomendado pela RFC 2459)

Políticas de certificado:



Mapeamentos de políticas:

Quando o sujeito de certificado for uma CA.

Nome alternativo do sujeito: Permite o suporte dentro de vários aplicativos que empreguem formas próprias de nomes (vários aplicativos de e-mail, EDI, IPSec)



Nome alternativo do emissor (CA): Permite o suporte dentro de vários aplicativos que empreguem formas próprias de nomes (vários aplicativos de e-mail, EDI,IPSec)



Atributos do diretório do sujeito: (não recomendado pela RFC 2459)

Restrições básicas: Se o sujeito pode agir como uma CA. Exemplo: Se a Verisign pode permitir que a RSA Inc. atue como uma CA, mas não permitindo que a RSA Inc. crie novas CAs)



Restrições de nomes: Apenas dentro de CAs. Especifica o espaço de nomes de sujeito.

Restrições de diretiva: Apenas dentro de CAs. Validação de caminho de política.



11. Assinatura da CA


Nomes de Entidades

• Certificados X.509 v3 concedem flexibilidade para nomes de entidades.

• As entidades podem ser identificadas pelas seguintes formas de nomes:

- endereço de e-mail - domínio de Internet - e-mail X.400 - nome de diretório X.500 - nome de EDI - URI da Web: URN, URL - endereço IP


Nomes de Entidades

• Em um certificado de chave pública, os nomes de entidades (emissor e sujeito) devem ser únicos.


Notação e Codificação ASN.1

• Regras de sintaxe e de codificação de dados de certificados X.509.

• ASN.1 (Abstract Sintax Notation 1) - descreve a sintaxe de várias estruturas de dados;

- fornece tipos primitivos bem-definidos, e um meio único para definir as combinações complexas desses tipos primitivos.


Notação e Codificação ASN.1

• Regras de codificação para representar os tipos específicos de ASN.1 em strings de 0s e 1s:

- Basic Encoding Rules (BER)

- Distinguished Encoding Rules (DER)


Componentes PKI

Autoridade Certificadora (CA)

Autoridade Registradora (RA)

DiretórioX.500

Servidor de Recuperação de Chave

Usuários Finais

Usuários Finais

1

2

3

5

4

6

Repositório deCertificados


Componentes de uma PKI

• Autoridade Certificadora (CA)

• Autoridade Registradora (RA)

• Diretório de Certificado (X.500)

• Servidor de Recuperação de Chave

• Protocolos de Gerenciamento

• Protocolos Operacionais


Partes de sistema PKI

• Infra-estrutura PKI

• Usuário Final / Empresa

• Parte Verificadora


Interação das partes em PKI

Infra-estrutura de PKI

Usuário Finalou Empresa

Parte Verificadora

Certificado X.509

Informação de Status de Revogação de Certificado

LDAP, HTTP, FTP, e-mail

LDAP

OCSP / CRL


Autoridade Certificadora


Autoridade Registradora


Diretório

• Um diretório é um arquivo, freqüentemente de um tipo especial, que provê um mapeamento de nomes-texto para identificadores internos de arquivo.


Diretórios

• Diretórios podem incluir nomes de outros diretórios, correspondendo ao esquema familiar hierárquico de nomeação de arquivos e nomes de caminhos (pathnames) para arquivos usados em sistemas operacionais.


Arquitetura de Serviço de Arquivos


File Service Architecture

Client computer Server computer

Applicationprogram

Applicationprogram

Client module

Flat file service

Directory service


Arquitetura de Serviço de Arquivos

• UFID (Unique File IDentifiers) são sequências longas de bits de modo que cada arquivo no Flat File Service tenha uma identificação interna única entre todos os arquivos em um sistema distribuído.


UFIDs

• UFIDs são usados para referenciar arquivos em todas as solicitações (requests) para o Flat File Service.


Flat File Service

• É o módulo da arquitetura de serviço de arquivo que implementa operações sobre arquivos.

• Exemplo: o Flat File Service recebe um pedido para criar um arquivo. Ele gera um novo UFID para esse arquivo e retorna o UFID ao requerente.


Flat File Service Operations


Flat file service operations

Read(FileId, i, n) -> Data — throws BadPosition

If 1 ≤ i ≤ Length(File): Reads a sequence of up to n itemsfrom a file starting at item i and returns it in Data.

Write(FileId, i, Data) — throws BadPosition

If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to afile, starting at item i, extending the file if necessary.

Create() -> FileId Creates a new file of length 0 and delivers a UFID for it.

Delete(FileId) Removes the file from the file store.

GetAttributes(FileId) -> Attr Returns the file attributes for the file.

SetAttributes(FileId, Attr) Sets the file attributes (only those attributes that are notshaded in ).


Directory Service

• É um serviço que armazena coleções de ligações entre nomes e atributos, e que procura entradas (entries) que correspondem a especificação baseada em atributo.

• Também chamado: serviço de nome baseado em atributo.


Directory Service

• É o módulo da arquitetura de serviço de arquivo que provê um mapeamento entre nomes-texto para arquivos e seus UFIDs.

• Provê as funções necessárias para gerar diretórios, adicionar novos nomes de arquivos a diretórios e obter UFIDs de diretórios.


Directory Service

• Diretory Service é cliente do Flat File Service.

• Seus arquivos de diretório são armazenados em arquivos do Flat File Service.

• No esquema hierárquico de nomeação de arquivos, como em UNIX, diretórios podem fazer referência a outros diretórios.


Directory service operations

Lookup(Dir, Name) -> FileId— throws NotFound

Locates the text name in the directory and returns therelevant UFID. If Name is not in the directory, throws an

exception.

AddName(Dir, Name, File) — throws NameDuplicate

If Name is not in the directory, adds (Name, File) to thedirectory and updates the file’s attribute record.If Name is already in the directory: throws an exception.

UnName(Dir, Name) — throws NotFound

If Name is in the directory: the entry containing Name isremoved from the directory.

If Name is not in the directory: throws an exception.

GetNames(Dir, Pattern) -> NameSeq Returns all the text names in the directory that match theregular expression Pattern.



Local and remote file systems accessible on an NFS client

jim jane joeann

usersstudents

usrvmunix

Client Server 2

. . . nfs

Remote

mountstaff

big bobjon

people

Server 1

export

(root)

Remote

mount

. . .

x

(root) (root)

Note: The file system mounted at /usr/students in the client is actually the sub-tree located at /export/people in Server 1; the file system mounted at /usr/staff in the client is actually the sub-tree located at /nfs/users in Server 2.


X.500 Directory Service

• Dados armazenados em servidores X.500 (Directory Service Agent – DSA) são organizados numa estrutura de árvore com nodos nomeados.



• Em X.500, atributos são armazenados em cada nodo na árvore.

• O acesso é por nome, mas também, por busca de entradas com qualquer combinação de atributos.



• A estrutura de diretório inteira incluindo os dados associados com os nodos é chamada Directory Information Base (DIB).

• Um servidor X.500 é um Directory Service Agents (DSA).



• Um cliente X.500 é chamado Directory User Agent (DUA).

• A árvore de nomes X.500 é chamada Diretory Information Tree (DIT).



• Clientes (DUA) e Servidores X.500 (DAS) se comunicam através do LDAP (Lightweight Directory Access Protocol), no qual um DUA acessa um DSA diretamente sobre TCP/IP (RFC 2251).


Certificados no X.500

• Certificados são armazenados em um diretório, cujo objetivo é fornecer uma infra-estrutura para nomear todas as entidades.


Servidor de Recuperação de Chave


Protocolos de Gerenciamento

• Comunicação on-line com os usuários finais e o gerenciamento dentro de uma PKI.

• Entre RA e um usuário final.• Entre duas CAs.• Certificate Management Protocol (CMP)• Certificate Management Message Format

(CMMF)• PKCS #10


Protocolos de Gerenciamento

• Funções - Inicialização (auto-escola) - Registro (solicitação da carteira) - Certificação (emissão da carteira) - Recuperação de chave (segunda via) - Atualização de chave (renovação) - Revogação (suspensão) - Certificação cruzada (informação entre

DETRANs)


Protocolos Operacionais

• Permitem a transferência de certificados e das informações de status de revogação, entre diretórios, usuários finais e parte verificadoras.

• X.509 não especifica nenhum único protocolo operacional para uso dentro de um domínio de PKI.


Protocolos Operacionais

• Protocolos usados: - HTTP, - FTP, - e-mail - LDAP Lightweight Diretory Access Protocol

RFC 1777 e RFC 1778 Projetado para aplicativos acessarem diretórios X.500.

Não é específico de diretório, pode ser adotado em vários ambientes.


Registro de Certificados

• Usuários finais se registram na CA ou na RA, via Internet, utilizando um navegador da Web.

• É nesse ponto que usuário final e CA estabelecem uma relação de confiança.


Revogação de Certificado

• Certificados são criados para serem usados pelo tempo de vida indicado no campo de validade.

• Entretanto, alguns casos, não deverá ser mais utilizado.

• Exemplo: Chave Privada comprometida, CA cometeu um equívoco ou possuidor da chave não mais trabalha numa empresa.


Revogação de Certificado

• CAs precisam de uma maneira de revogar um certificado ainda em vigor e notificar as partes verificadoras sobre a revogação.

• Método comum:

- Certificate Revogation List (CRL) - Estrutura de dados assinada contendo uma lista de data/hora dos certificados revogados.


Estrutura de uma CRL


Protocolo On-Line de Status de CertificadoOCSP

• Dependendo do tamanho da população da PKI, a carga de trabalho associada às CRLs pode tornar-se pesada, utilizando-se as técnicas convencionais de processamento de CRLs e download.


Protocolo On-Line de Status de CertificadoOCSP

• Partes verificadoras devem gastar recursos consideráveis para obter a CRL mais atual.

• Um protocolo mais recente: OCPS,Online Certificate Status Protocol, pode ser utilizado por uma parte verificadora para verificar a validade de um certificado digital, no momento de uma transação (tempo real).


Status de Certificado On-Line

• A CA fornece um servidor de OCSP, que contém as informações atuais de revogação de certificados.

• Esse servidor é diretamente atualizado na CA.



• CA encaminha uma notificação imediata de revogação de um certificado, tornando-o instantaneamente disponível aos usuários.

• Uma parte verificadora pode consultar esse servidor, para determinar o status de um certificado.



• O servidor OCSP fornece uma resposta assinada digitalmente para cada um dos certificados, cujas validades são solicitadas.



• Respostas OCSP consistem em:

- identificador de certificado,

- valor do status (good, revoke, unknown), - intervalo de validade, - tempo de revogação, - razão da revogação.


Gerenciamento de Pares de Chaves

• Gerando pares de chaves

• Protegendo chaves privadas

• Gerenciando múltiplos pares de chaves

• Atualizando pares de chaves

• Mantendo um histórico de pares de chaves.


Gerenciamento de Pares de Chaves

• Políticas pelas quais os pares de chave (privada, pública) são gerados e protegidos.

• Decisões de política dependem dos propósitos das chaves.

• Chaves para não-repúdio, chaves para segurança de email, têm métodos de armazenamento diferentes.


Gerando Pares de Chaves

• Primeira alternativa:

• O usuário final gera um par de chaves (privada e pública) no seu sistema e fornece a chave pública na forma de um padrão de solicitação de assinatura de certificado (certificate-signing request) de PKCS #10.



• Segunda alternativa:

• CA ou RA gera um par de chaves (privada e pública) em favor do usuário final.



• Terceira opção:

• Uso de múltiplos pares de chaves.• Usuários finais podem ter mais de um certificado

para diferentes propósitos.

• O usuário final gera as chaves para fornecer não-repúdio e a CA fornece as chaves de criptografia.


Atualizando Pares de Chaves


Mantendo histórico de Pares de Chaves


Certificados Roaming


Certificado de Atributo


Políticas de Certificado


Prática de Certificação


Produtos PKI

Documents

Infra-estrutura de Chave Pública