1. Introdução

Um PKI facilita a administração dos problemas associados à privacidade das chaves existentes em soluções baseadas em criptografia simétrica. Utilizando algoritmos com chaves assimétricas, esta tecnologia oferece privacidade, integridade dos dados e a autenticação da origem e da mensagem. Aplicações que necessitam serviços seguros baseados em padrões como o WWW, correio eletrônico, IPSec e transações comerciais estão sendo continuamente desenvolvidas para usufruir as vantagens desta tecnologia.

Um certificado digital é um conjunto de dados imune a fraudes, que atesta a ligação existente entre uma chave pública, um nome único e outros atributos de um usuário ou entidade. O formato de certificado mais aceito mundialmente segue as determinações da recomendação X.509, versão 3, da União Internacional de Telecomunicações.

A segurança está relacionada com a confiabilidade do algoritmo de criptografia  utilizado na implementação da aplicação do PKI e no controle da chave privada usada para assinar o certificado pelo seu emitente e pelo usuário.

2. Mecanismos de Segurança

2.1 Confidencialidade

Confidencialidade é definida como a proteção da privacidade da informação em relação a um acesso não autorizado. A confidencialidade é determinada pela origem que cria uma chave secreta para criptografar os dados enviados ao destino, usando por compromissos com a performance, um algoritmo simétrico (DES ou RC4).

A chave simétrica empregada para criptografar os dados é criptografada com a chave pública do destino e transmitida junto com a mensagem. O receptor decripta a chave simétrica com a sua chave privada e decripta o texto da mensagem utilizando a chave simétrica.

2.2 Integridade dos Dados

A integridade dos dados fornece a garantia de que a mensagem original não foi alterada. Esta característica é obtida calculando uma amostra da mensagem utilizando uma função de hash (SHA-1 ou MD5) e criptografando este valor com a chave privada da origem (assinatura digital). As propriedades das funções de hash garantem que qualquer alteração realizada no teor original da mensagem, por menor que seja, produz um resultado diferente. A assinatura digital é o resultado da criptografia deste hash com a chave privada do remetente. A assinatura digital não é reutilizável, mas não protege de ataques tipo Replay.

2.3 Autenticação de Origem e Mensagem

A autenticação da origem é baseada no nível de confiança que o destino tem em relação à capacidade do remetente em proteger a sua chave privada e na validade do seu certificado. Até recentemente a maioria dos procedimentos de autenticação e controle de acesso eram baseados na relação entre um nome de usuário e uma password (algo que o usuário conhece ou um segredo compartilhado). Certificados permitem a autenticação utilizando o conceito de chave privada (algo que o usuário tem) e processos de autenticação mais elaborados podem usar procedimentos adicionais como smartcards ou biometria.

A autenticação da mensagem e a integridade dos dados não são mutuamente exclusivas e a autenticação da origem da mensagem é realizada pelo procedimento de garantia da integridade dos dados. A integridade da mensagem não tem valor se a origem não pode ser autenticada.

3. Componentes do PKI

A arquitetura de um PKI pode ser descrita conforme a figura abaixo:

Figura 1 – Componentes do PKI

Os servidores PKI são a Autoridade Certificadora, os diretórios e sistemas de recuperação de chaves. Os clientes PKI são o servidor WEB, browser, email e aplicações de arquivos.

3.1 Servidor de Certificados

Um servidor de certificados ou autoridade certificadora (CA) emite, administra e revoga certificados. O certificado da CA (a chave pública) tem credibilidade e é conhecido por todas as entidades participantes. A CA pode delegar a sua credibilidade para uma autoridade subordinada assinando o seu certificado e criando uma hierarquia de certificação. Isto pode ser feito para facilitar a administração (por exemplo: políticas diferenciadas de emissão), para melhorar a performance (evitar congestionamento de redes) ou por razões de segurança (evitar que a falha de um único ponto comprometa todo o sistema). A seqüência de certificados entre a última CA subordinada e a CA Root é chamada de cadeia de certificação. Cada certificado contém a identificação e a assinatura da CA emitente. A CA Root assina o seu certificado com a sua própria chave privada (ou seja, no X.509 v3 a entidade emitente e a entidade certificada são iguais).

3.2 Servidor de Diretórios

O servidor de diretórios fornece um único ponto de administração para as informações pessoais e corporativas. Os registros nos diretórios podem incluir os recursos da rede tais como servidores de arquivos, impressoras, URLs ou pessoas. As informações dos usuários como email, endereço, telefone, privilégios e certificados podem ficar disponíveis para múltiplas aplicações de acordo com uma política de segurança definida. Os clientes de diretórios podem localizar registros e atributos utilizando protocolos de acesso como,  por exemplo, o LDAP.

O LDAP (Lightweight Directory Access Protocol) foi originalmente definido para possibilitar que aplicações rodando em plataformas distintas pudessem ter acesso a diretórios X.500. O LDAP é definido pelas RFCs 1777 e 1778 e é um protocolo orientado a bit, semelhante ao HTTP, que roda em ambientes TCP/IP. Ele cria um modo padronizado para as aplicações solicitarem e administrarem informações de diretórios. Os registros nos diretórios são organizados em uma estrutura hierárquica que reflete as condições políticas e geográficas da corporação.

3.3 Servidor para Recuperação de Chaves

O servidor para recuperação de chaves permite que clientes armazenem e recuperem chaves de criptografia. Esta função é necessária para ter acesso a arquivos criptografados caso a chave privada seja danificada. Este servidor também pode ser utilizado como um tipo de procurador do usuário para permitir, na ausência deste, o acesso a informações de propriedade da empresa. Todos os textos que transitam em um ambiente profissional são, em tese, propriedade da corporação, que deve ter acesso a sua chave de criptografia. Entretanto, para garantir o não repúdio da origem, os funcionários devem ter o controle exclusivo da sua chave privada. Para garantir tanto o acesso como a origem da informação, o funcionário usa uma chave exclusivamente sua para assinar digitalmente os documentos transmitidos e usa uma chave privada diferente para criptografia. Esta segunda chave privada é mantida armazenada em um servidor para garantir o acesso às informações caso o funcionário seja desligado. 

3.4 Aplicações PKI

Aplicação PKI é toda e qualquer aplicação que utilize a tecnologia de chave pública. Na maioria dos casos a aplicação também fornece funções criptográficas complementares como geração de chaves pública/privada, assinaturas digitais, criptografia e administração de certificados.  As funções de administração de certificados incluem a geração de solicitações de certificados, revogação e armazenamento seguro de chave(s) privada(s). Exemplos de aplicações PKI incluem o servidor/browser Netscape SSL 3.0 e o GlobeSet Secure Eletronic Transaction (SET) Wallet.

4. Segurança do PKI

Os componentes de um PKI compartilham um conjunto de necessidades de segurança, tais como:

q       Software Confiável – Um nível confortável de segurança que o software implementa corretamente os controles de criptografia;

q       Comunicação segura e confiável entre os componentes (usando, por exemplo, IPSec ou SSL 3.0);

q       Políticas de segurança específicas para o PKI que sejam consistentes com o conjunto de políticas de segurança da corporação.

A maioria do hardware/software de PKI é construída com ferramentas criptográficas como os Toolkits Baltimore ou o B-Safe da RSA, que são exaustivamente testados e bastante estáveis, porém aplicações que acionam as funções disponíveis no software pré-programado ainda estão sujeitas a erros humanos. Continuamente a Microsoft, Netscape e outros fabricantes liberam correções para seus produtos. Como a guerra entre fabricantes continua, pode-se prever que os ciclos entre lançamentos de produtos sejam cada vez menores e, por conseqüência, a qualidade do software tende a decrescer.

Os componentes do PKI exigem comunicação privada e autenticada para prevenir fraudes decorrentes de ataques ativos ou passivos. A maior parte dos componentes PKI existentes implementa o SSL 3.0.

Cada componente tem um critério de segurança que deve ser consistente com os objetivos do PKI. Este critério é baseado no nível de proteção necessário para executar os objetivos comerciais das aplicações com um nível de risco aceitável. A premissa básica do PKI, como em todas as aplicações em geral, é que o custo da proteção não deve ser maior que o valor da informação protegida. Os mecanismos de segurança utilizados para compatibilizar com estes critérios normalmente implicam na segurança de instalações físicas, plataformas, sistemas operacionais, rede e aplicações.  Estes mecanismos podem não estar presentes em todas as aplicações e, provavelmente, devem ser suplementados com a utilização de firewalls, controles de acesso e procedimentos do administrador.

4.1 CA

As necessidades operacionais da CA ou Servidor de Certificados são:

q       Geração, emissão, investigação, revogação, renovação e políticas de armazenamento de certificados;

q       Declaração de Práticas de Certificação;

q       Políticas de atributos e extensões de certificados;

q       Administração de certificados, relatórios para auditorias e procedimentos para recuperação/ciclo de vida dos dados;

q       Armazenamento seguro da(s) chave(s) privada(s);

q       Acordos para certificação cruzada.

A aplicabilidade e/ou utilização dos certificados que a CA administra são definidos pela política de certificação. Uma política de segurança deve existir para cada função da CA (por exemplo: geração, emissão, tempo entre atualizações das listas de revogação, etc.). Estas políticas definem as bases onde todas as atividades de segurança da CA estão apoiadas.

Políticas de certificação para atender as necessidades de segurança interna de corporações normalmente são mais rigorosas que as relacionadas com o comércio eletrônico.

A Declaração de Práticas de Certificação é um documento público que detalha procedimentos e compromissos assumidos pela CA. Todas as entidades e usuários certificados devem estar cientes e de acordo com estas práticas antes de confiar na CA. A DPC também identifica qual o nível de comprometimento da CA em suas relações comerciais.

Um dos maiores aprimoramentos da versão 3 do X.509 é a habilidade de administrar extensões na estrutura dos certificados. Estas extensões incluem informações adicionais sobre chaves e políticas de segurança, atributos da CA e dos usuários e limitações do caminho de certificação. A CA deve documentar, através de um procedimento definido em sua política de certificação, quais as extensões que aceita. Para permitir a interoperabilidade fora dos limites da corporação, a CA deve também registrar os identificadores de finalidade das extensões (OID – extension object identifiers) junto ao American National Standards Institute (ANSI).

A CA deve manter um relatório para auditoria de todas as operações relacionadas com certificados e a administração de chaves que são executadas. Todo o gerenciamento das funções referentes a certificados (por exemplo: emissão, revogação, etc.) deve ser documentada para efeitos de comprovação em disputas judiciais. Em conjunto com estas funções de auditoria, devem existir procedimentos para recuperação de dados e administração do ciclo de vida dos certificados. A interface de administração da CA deve ser muito criteriosa em relação aos privilégios concedidos aos operadores.

O CA deve prover um nível adequado de segurança para a chave privada que assina os certificados dos usuários. O hardware onde o CA roda deve estar protegido contra ataques físicos e eletrônicos. Opcionalmente, a chave privada do CA pode ser mantida em um módulo de segurança por hardware (HSM) definido de acordo com o padrão FIPS PUB 140-1 nível 3.

A certificação cruzada é emitida por CAs para formar uma cadeia de certificação não hierárquica. Dois certificados, definidos por um acordo entre as CAs, são necessários para habilitar uma relação mútua de credibilidade. O acordo de certificação cruzada detalha as responsabilidades e obrigações de cada CA caso um certificado falso seja aceito.

4.2 Diretórios

Os requisitos de segurança de um servidor de diretórios são os seguintes:

q       Aceitar a autenticação de rede por endereço IP ou DNS e a autenticação do usuário por nome e password LDAP ou certificado X.509 versão 3;

q       Controlar a habilidade do usuário em executar comandos de leitura, gravação, busca ou comparação no nível de atributos;

q       Prover privacidade (SSL) e integridade de mensagens para todas as comunicações.

O servidor de diretórios contém atributos e informações corporativas e pessoais dos usuários, e o acesso a estas informações deve ser controlado da melhor maneira possível. O administrador deve estar habilitado a restringir a execução de operações específicas de diretório por usuários ou operadores não credenciados.  Toda a comunicação entre os diretórios e componentes do PKI deve ser segura.

4.3 Recuperação de Chaves

As necessidades do servidor para recuperação de chaves são:

q       Autenticação confiável para o administrador e usuários;

q       Privacidade (SSL) e integridade de mensagens;

q       Armazenamento seguro das chaves.

Este componente deve ter o mais alto índice de proteção e segurança de todo o PKI. As chaves de criptografia devem ser particionadas e seus componentes devem ser criptografados e armazenados em ambientes distintos.

Uma única chave mestre para decriptografar todas as outras chaves não é um procedimento aceitável. Apenas uma parte da chave privada deve ser armazenada no servidor, o restante deve ser mantido pela entidade final ou por uma terceira parte confiável. Se o servidor de recuperação de chaves é comprometido, não deve expor todas as chaves da corporação.

4.4 Clientes PKI

Todos os clientes PKI devem, no mínimo, estarem aptos a gerar assinaturas digitais e administrar certificados. Os requisitos das aplicações PKI são:

q       Gerar pares de chaves pública/privada;

q       Criar uma solicitação de certificados (PKCS#10);

q       Apresentar um certificado;

q       Verificar um certificado;

q       Excluir um certificado;

q       Habilitar e desabilitar múltiplos certificados;

q       Solicitar uma revogação de certificado;

q       Armazenar certificados com critérios de segurança (exemplo: proteção por password);

q       Exportar certificados com segurança (PKCS#12);

q       Selecionar algoritmos, resistência de chaves e controles de passwords;

q       Configurar opções de segurança (por exemplo: assinar e criptografar sempre que possível).

O processo inicia quando um cliente PKI gera localmente um par de chaves pública/privada utilizando um software com um algoritmorandômico, preferencialmente não determinístico. Depois do par de chaves ser criado, a chave pública deve ser incluída na estrutura do certificado. O cliente gera uma requisição com a sintaxe definida pelo PKCS#10 e envia esta solicitação para a CA. A CA analisa esta solicitação segundo a sua politica definida e, se concorda em emitir o certificado, envia a resposta ao cliente no formato PKCS#7 (envelope assinado). Todo o tráfego é mantido privado entre o cliente PKI e a CA. O cliente PKI deve ter a habilidade de administrar múltiplos certificados e esta característica inclui a capacidade de analisar a estrutura (pessoa ou entidade, emitente, assinatura digital do emitente, número serial e período de validade), excluir se necessário, optar por um entre vários ou solicitar a CA a revogação de um certificado.

Uma grande parcela da eficácia da criptografia por chave pública é baseada na proteção da chave privada. O cliente PKI deve proteger a sua chave privada de acordo com os riscos relacionados com o seu negócio e este processo pode incluir a criptografia das chaves, o controle por passwords ou procedimentos que utilizem smartcards ou outros sistemas de armazenamento externo.

Os certificados recebidos são armazenados na estação do cliente PKI. Um padrão da criptografia de chave pública, chamado Padrão de Sintaxe para a Troca de Informações Pessoais (PKCS#12), detalha o formato utilizado para a transmissão de informações de identificação pessoal como chaves privadas, certificados, informações sigilosas e extensões. Este padrão permite que clientes PKI exportem e importem informações de identificação pessoal através de múltiplas aplicações e plataformas. O método mais seguro inclui um modo de privacidade e integridade que exige que as plataformas de origem e destino tenham chaves públicas e privadas confiáveis para criptografia e assinatura digital. O método menos seguro protege a informação em transito por um controle de acesso baseado em passwords.

Clientes PKI devem estar habilitados a controlar diversos algoritmos criptográficos, algoritmos de hash e tamanhos de chave para a proteção das informações em transito. Toda a administração de passwords, se houver, deve ser executada de acordo com os procedimentos especificados nas políticas de segurança da corporação.

5. Certificados X.509 v3

5.1 Tipos de Certificados

Clientes PKI administram seus próprios tipos de certificados (para navegação, email, etc). Alguns tipos de certificados possíveis estão listados na Tabela 1. Antes de solicitar um certificado para a CA, a aplicação PKI deve ter acesso ao certificado da CA.

Tabela 1 – Tipos de Certificados

5.2 Extensões de Certificados X.509 v3

A especificação X.509 v3 permite que vários atributos sejam incluídos como extensões nos certificados e esta flexibilidade complica a interoperabilidade entre componentes do PKI. O ITU (União Internacional de Telecomunicações) relaciona um conjunto de extensões para certificados nas normas ISO (Organização Internacional de Padrões).  O ANSI padroniza extensões para a comunidade financeira. As especificações SET (Secure Electronic Transaction) definem um conjunto de extensões direcionado para aplicações específicas.

As extensões podem complementar informações sobre chaves e políticas de segurança, atributos da pessoa/entidade certificada, CA emissora ou definir limitações da cadeia de certificação.

O formato do certificado definido pela recomendação X.509, versão 3, do ITU está descrito na Tabela 2.

Tabela 2 – Formato do Certificado X.509 v3

 6. Relação de Certificados Revogados

A relação de certificados revogados (CRL – Certificate Revogation List) é uma lista de certificados emitidos pela CA que não são mais válidos. Os certificados expirados não são incluídos nesta relação. A lista contém os números seriais dos certificados associados com um indicador do motivo da revogação. Estes valores são datados e assinados pela CA. O período de latência da CRL é o tempo decorrido entre as atualizações, e este valor é definido pela política de segurança da CA.

7. Cadeia de Certificação

A cadeia de certificação é uma seqüência ordenada de certificados entre o cliente e a maior hierarquia de credibilidade do PKI (CA Root). Os dois modelos mais comuns de cadeias são o hierárquico e a teia de credibilidade (utilizada, por exemplo, PGP). Um modelo estritamente hierárquico é adequado para uma empresa, mas muito restritivo quando a necessidade é a interconexão de múltiplas corporações. A flexibilidade é importante quando a abrangência do PKI é ampla e cadeias de certificação hierárquica não funcionam quando não há uma autoridade central bem definida. A teia de hierarquias, que é uma combinação entre o modelo hierárquico e a teia de credibilidade, parece ser mais adequada nestes ambientes.

8. Estudo de Caso

Este estudo abrange a implementação de um PKI com CA, diretórios e servidores corporativos. Os clientes PKI utilizam browsers (Internet Explorer ou Netscape Navigator) e clientes e-mail (Outlook Express ou Netscape Messenger). O objetivo da implementação é criar um ambiente PKI com uma CA auto-assinada para obter autenticação de usuários e e-mail seguro. Antes de qualquer software ser instalado a documentação de segurança, que inclui as políticas de PKI apropriadas, foi desenvolvida de acordo com a política de segurança da corporação. Esta implementação abrange exclusivamente os problemas de segurança corporativa.

8.1 Padrões

Para ter interoperabilidade e não estar vinculado a soluções proprietárias, o PKI é consistente com os seguintes padrões:

q       Certificados X.509 v3 (ISSO 9504-8)

q       Especificação CRL v2 para relação de certificados revogados

q       RSA PKCS#10 para solicitação de certificados

q       RSA PKCS#7 para empacotamento de certificados para transporte

q       RSA PKCS#1 para formato das chaves pública e privada

q       RSA PKCS#12 para troca de informações pessoais

q       Interface LDAP v3 para diretórios X.500

q       TCP/IP: Interfaces HTTP, HTTP/S e SMTP para certificação de emails

q       S/MIME: Certificados de email para clientes Netscape Messenger e Microsoft Outlook

8.2 Autenticação de Clientes

Tradicionalmente o acesso a páginas web seguras utiliza um sistema de autenticação não criptografado, não codificado e baseado em nomes de usuários e passwords. Com o advento dos Sniffers, as passwords em Intranets são uma solução inadequada. Para este caso o SSL 3.0 (Secure Socket Layer), que implementa criptografia de dados, autenticação de servidores, integridade de mensagens e autenticação de usuários em conexões TCP/IP, foi selecionado.

Na autenticação mútua de clientes e servidores, ambos fornecem o seu certificado como parte do procedimento de conexão. Se os certificados contém uma assinatura confiável(da CA que os emitiu) e as datas de validade não estão expiradas, então o cliente e o servidor são autênticos. A autenticação é realizada pela conferência das assinaturas digitais que ambos recebem. A chave pública contida no certificado é usada para decriptar a mensagem que foi assinada com a chave privada da entidade de origem.

Certificados são estruturas de dados públicas (sem informações confidenciais), portanto os ataques convencionais como espionagem, modificação e mensagens forjadas são facilmente detectados e evitados.

O procedimento de autenticação de um cliente ou servidor pode ter etapas adicionais como;

·         Verificação de revogação de certificados;

·         Verificação de toda a cadeia de credibilidade, até a CA Root;

·         Verificação das extensões dos certificados.

Os diretórios são o componente central desta arquitetura. Todos os certificados que são emitidos ou revogados na CA são replicados na hierarquia dos diretórios, que espelha o organograma da corporação (divisões, departamentos e grupos). Cada usuário é pré-alocado em um diretório da hierarquia. Todas as comunicações entre a CA e os diretórios trafegam por canais seguros (SSL 3.0). 

8.3 E-mail Seguro (S/MIME)

O objetivo do S/MIME é a interoperabilidade de mensagens seguras, obtida pela criptografia e assinatura digital. A segurança é fornecida apenas no cliente S/MIME, o servidor de mail não precisa ser modificado. O S/MIME é o resultado da integração de três padrões já estabelecidos:

q       MIME - Multi-purpose Internet Mail Extension, especificado na RFC 1521;

q       Criptographic Message Syntax Standard (PKCS#7);

q       Certification Request Syntax Standard (PKCS#10).

O S/MIME aceita os tipos de conteúdo PKCS#7 listados na Tabela 3.

Nota: Todas as funções de criptografia exigem que o cliente/servidor tenham, pelo menos, um certificado válido. 

Tabela 3 – Tipos de Conteúdo S/MIME

O S/MIME aceita os seguintes algoritmos de criptografia, modos e tamanhos de chave:

q       Triple DES, modo CBC com chave de 168 bits;

q       RC2, modo CBC com chave de 128 bits;

q       DES, modo CBC com chave de 56 bits;

q       RC2, modo CBC com chave de 64 bits;

q       RC2, modo CBC com chave de 40 bits.

O S/MIME também é compatível com os seguintes algoritmos de hash (amostra da mensagem):

q       MD5

q       SHA-1

Os retardos introduzidos pelos processos de segurança não são significativos. Enviar um e-mail assinado requer apenas que a entidade de origem tenha um certificado válido. A entidade de destino recebe o certificado da origem como parte da mensagem e, se implementar o S/MIME, utiliza a chave pública para reconhecer a assinatura. O certificado é armazenado no receptor para possibilitar a privacidade (criptografia) das próximas mensagens. O processo de privacidade e integridade de mensagens obedece aos seguintes passos na entidade de origem:

1.      Calcular uma amostra (hash) do conteúdo da mensagem

2.      Criptografar o hash com a sua chave privada para criar uma assinatura digital

3.      Criptografar o conteúdo da mensagem e a assinatura digital com uma chave simétrica randômica

4.      Criptografar a chave simétrica com a chave pública da entidade de destino

5.      Remeter o resultado dos passos 3 e 4 usando um meio de trasnporte tradicional (SMTP)

A entidade receptora deve executar os seguintes procedimentos:

1.      Receber o mail utilizando um meio de transporte tradicional (SMTP)

2.      Decriptar a chave simétrica com a sua chave privada

3.      Decriptar, com a chave simétrica, o conteúdo da mensagem e a assinatura digital

4.      Decriptar o hash recebido usando a chave pública do remetente

5.      Validar a assinatura digital calculando o hash da mensagem e comparando com recebido

6.      Validar o certificado do remetente

Se a entidade de origem utilizou um certificado incorreto, a mensagem não pode ser recuperada pelo destino.

9. Arquitetura do Projeto PKI

A Figura 2 mostra uma visão espacial de um projeto PKI. O eixo Z lista a abrangência do PKI. Descendo o eixo Z as dificuldades são crescentes com, por exemplo, certificação cruzada, especificações estaduais, federais e internacionais.

O eixo dos Y relaciona a segurança dos níveis de aplicações associados com as implementações. Estes valores variam desde software desconhecidos até aplicações extremamente seguras com o emprego de hardware criptográfico.

O eixo X contém os valores (nível de custo ou perda efetiva) associados com as transações, desde a criptografia de um arquivo pessoais locais até as transferências eletrônicas de fundos. Descendo o eixo Y os custos são gradativamente menores. Esta é uma regra geral, quanto maior a segurança necessária, maior os custos envolvidos

O nível do PKI corporativo está representado pela caixa cinza.

Figura 2 – Arquitetura de um Projeto de PKI