Processamento dinâmico de caminhos de certificação em ambientes distribuídos de grande porte

Alexandre Reis e Silva <alexandre@planalto.gov.br>
Michael A. Stanton <michael@ic.uff.br>

Instituto de Computação
Instituto Nacional de Tecnologia da Informação
Universidade Federal Fluminense

Resumo
1. Introdução
2. Diretórios distribuídos como repositórios
2.1 X.500
2.2 LDAP
3. Infra-estruturas de chaves públicas
3.1 X.509
3.1.1 Certificados
3.1.2 Caminhos de certificação
3.2 PKIX
3.2.1 Certificados
3.2.2 Repositórios LDAP
3.2.3 Caminhos de certificação
4. Processamento de caminhos de certificação
4.1 Cadeias de certificados com AC-Raízes isoladas
4.2 Grafos de hierarquias de CAs
4.3 Serviço de validação de caminhos de certificação
4.4 Servidor LDAP modificado
5. Processamento dinâmico - um novo método proposto
5.1 Política de certificação adotada
5.2 Descrição do método proposto
5.3 Implementação
6. Conclusões
Referências bibliográficas

Resumo

Embora a relevância das Infra-estruturas de Chave Pública (ICP) em comunicações seguras seja amplamente reconhecida, a falta de implementações disponíveis no domínio público tem limitado severamente a utilização de criptografia de chaves públicas a um pequeno número de aplicações específicas, com soluções restritas. Este trabalho propõe um método de processamento dinâmico de caminhos de certificação, baseado na integração de implementações de componentes distintos e disponíveis publicamente, que visa difundir o emprego das ICP em ambientes distribuídos de larga escala.

^

1. Introdução

A maneira mais eficiente de se fornecer segurança a uma rede de comunicações é a utilização de criptografia. No entanto, para que esse mecanismo mantenha a informação segura, deve haver meios seguros de se distribuir chaves criptográficas. Basicamente, dois tipos de criptografia são empregados: simétrica e assimétrica. O último deles apresenta melhor adequação a sistemas distribuídos, por necessitar apenas de um par de chaves para cada usuário, independente da quantidade de usuários com que ele se comunica.

Apesar das vantagens de se utilizar chaves assimétricas, a correspondência entre uma chave pública e seu respectivo usuário não pode ser garantida. Por outro lado, uma entidade de confiança, chamada Autoridade Certificadora (AC), pode ser empregada para assinar digitalmente chaves públicas, assegurando essa correspondência. O documento contendo tal correspondência é conhecido como certificado digital, ou, simplesmente, certificado.

Para se verificar a validade da chave pública de um parceiro de comunicações, o usuário checa a assinatura da AC no certificado com a própria chave pública da AC que o emitiu. Se tal usuário não confia na AC, então ele deverá checar uma cadeia de certificados, incluindo as assinaturas a eles associadas, que provê um caminho de certificação entre a AC de confiança e o parceiro da comunicação.

As Infra-estruturas de Chave Pública (ICP) - responsáveis por gerenciar o processo acima descrito, bem como criação, publicação e revogação de certificados, dentre outras funções - têm sua eficiência reconhecida e vêm sendo largamente utilizadas para o provimento de comunicações seguras, principalmente por possuir escalabilidade e facilidade de imposição de políticas de segurança no gerenciamento de suas chaves criptográficas. As ICP encontram-se atualmente em fase de adoção oficial por governos de vários países para o provimento de autenticação para assinaturas digitais, dentre outros serviços. Entretanto, a falta de implementações disponíveis no domínio público limita o uso das ICP a um pequeno número de aplicações específicas e limitadas, já que os produtos comerciais são de alto custo.

Este trabalho trata o problema da utilização de ICP em sistemas distribuídos de grande porte, tais como órgãos e empresas, geograficamente distribuídos e com grande número de funcionários, que podem comunicar-se também com pessoas ou entidades de outras organizações. Inicialmente, discute-se o emprego de diretórios distribuídos como repositórios para o armazenamento de certificados. Em seguida, são descritas as padronizações de ICP, dando-se ênfase à discussão sobre os métodos de processamento de caminhos de certificação. O principal resultado desse estudo é a proposta de um novo método e a implementação de um protótipo para demonstrar sua viabilidade. Essa ferramenta experimental é baseada na integração de implementações de servidores de reconhecida relevância, disponíveis publicamente, e um programa cliente desenvolvido, capaz de recuperar certificados de repositórios distribuídos para construir dinamicamente caminhos de certificação e validá-los de maneira automática.

^

2. Diretórios distribuídos como repositórios

Para se tirar proveito dos certificados em grandes sistemas distribuídos, deve haver meios eficientes de torná-los disponíveis a todos os usuários. Uma solução de reconhecida eficiência é a utilização de serviços de diretórios como repositórios, para armazenar informações sobre usuários e entidades do sistema e permitir fácil acesso a essa informação por aplicações distintas (X.500, 1993).

Normalmente, serviços de diretórios seguem a série de recomendações ITU-T X.500. Um resumo da Recomendação X.500 será apresentado e, posteriormente, será discutida a utilização do Protocolo de Acesso "Leve" a Diretórios - Lightweight Directory Access Protocol (LDAP), baseado na X.500, para acesso a repositórios de ICP.

^

2.1 X.500

A Recomendação ITU-T X.500 (X500, 1993) inclui em sua estrutura básica: um conjunto de funções de diretório referentes a operações de leitura e busca em dados armazenados; aspectos de segurança relacionados ao controle de acesso e à modificação da base de dados; e protocolos que definem a interação de diretórios e seus usuários, como também entre diretórios distribuídos.

Um diretório é composto por um ou mais processos de aplicação chamados Directory System Agents (DSA). Se um diretório possui múltiplos DSA, diz-se que é um diretório distribuído. Um DSA pode fornecer zero ou mais pontos de acesso, que os usuários podem empregar para interagir com o diretório. O processo utilizado pelo usuário para acessar o diretório é chamado de Directory User Agent (DUA). O protocolo que governa a interação de uma DSA com um DUA é conhecido como Directory Access Protocol (DAP) e, entre DSA, Directory System Protocol (DSP). Tais componentes são ilustrados na Figura 1.

Um DUA necessita acessar diretamente apenas um DSA para submeter uma requisição de serviço. Se o DSA contatado for incapaz de responder tal pedido, então ele pode repassá-lo a outro DSA que contenha a informação desejada (chaining), ou informar ao usuário onde encontrá-la (referral).

O conjunto completo de informações às quais o diretório provê acesso é conhecido como Directory Information Base (DIB). As entradas em uma DIB são hierarquicamente estruturadas como uma árvore, denominada Directory Information Tree (DIT).

Figura 1 - Modelo de acesso a diretórios X.500

O modelo de serviços de diretórios é baseado em entradas, que correspondem a informações sobre objetos. Uma entrada é um conjunto de atributos e possui um nome característico chamado Distinguished Name (DN), que provê identificação singular. Cada atributo possui um tipo e um ou mais valores. Cada entrada deve incluir um atributo chamado classe de objeto, o qual controla outros atributos, identificando-os como obrigatórios ou opcionais.

^

2.2 LDAP

O Lightweight Directory Access Protocol (LDAP), baseado no mesmo modelo de informação da X.500, foi definido com o intuito de remover algumas das restrições daquela Recomendação, permitindo que os serviços de diretório fossem disponibilizados a uma maior variedade de máquinas e aplicações (Yeong et al., 1995). Uma dessas restrições é a exigência, pela X.500, da utilização de toda a pilha de protocolos OSI, o que torna sua implementação excessivamente complexa, enquanto o LDAP é projetado para ser empregado diretamente sobre TCP/IP.

O acesso a diretórios via LDAP pode ser realizado de duas maneiras: utilizando-se um front-end para acessar servidores X.500, por meio do ldapd (LDAP Daemon), ou fazendo-se uso de um slapd (Stand-alone LDAP Daemon) para acesso a DSAs. Na primeira configuração, chaining e referral permitem aos usuários acesso transparente a diretórios distribuídos. Quando a segunda configuração é utilizada, os usuários devem ser capazes de manipular referrals, de modo que possam acessar diretórios distribuídos, já que não há chaining no diretório.

Atualmente, há duas versões do LDAP: versão2, definida em (Yeong et al., 1995), e versão 3 (Wahl, et al., 1997). Esta última foi desenvolvida para solucionar uma série de limitações existentes na anterior, incluindo aspectos de segurança, passando a suportar protocolos de autenticação forte como o Simple Authentication Security Layer (SASL) e o Transport Layer Security (TLS) enquanto a versão 2 oferece apenas autenticação forte com Kerberos v4.

São várias as implementações do LDAP em ambas as versões. Entretanto, poucas estão disponíveis publicamente (Innosoft, 1997), incluindo-se código fonte aberto e documentação da API. Além disso, a grande maioria delas são compatíveis com a versão 2 do LDAP e baseiam-se na primeira implementação, desenvolvida na Universidade de Michigan (U. Michigan, 1997). Dentre tais aplicações, o OpenLDAP foi escolhido à época para ser utilizado com o protótipo desenvolvido neste trabalho, discutido mais adiante, como provedor de acesso a repositórios distribuídos. O OpenLDAP é o resultado de um esforço conjunto de desenvolvedores de vários países, após a criação da Fundação OpenLDAP (OpenLDAP, 2001). Suas características incluem, atualmente: portabilidade para Linux e outras plataformas; operações multi-threaded; suporte a novas bases de dados como back-end; suporte aTCP Wrapper; incorporação de várias correções de bugs existentes na versão original da Universidadede Michigan; e compatibilidade com a versão 3 do LDAP.

^

3. Infra-estruturas de chaves públicas

As Infra-estruturas de chaves públicas (Public Key Infrastructures - ICP) são definidas em (Arsenault, 2000) como o conjunto de hardware, software, pessoas, políticas e procedimentos necessários a criação, gerência, armazenamento, distribuição e revogação de certificados, baseado sem criptografia de chaves públicas. O papel principal de uma ICP é a gerência de chaves e certificados de modo confiável e eficiente para seus usuários.

O objetivo da padronização de ICP é fornecer interoperabilidade, permitindo portanto seu uso em ambientes distribuídos e heterogêneos. Atualmente, há dois padrões abertos de ICP: Recomendação ITU-T X.509 e Especificações PKIX, da IETF. Um padrão é dito aberto se não for restrito a aplicações ou plataformas específicas.

^

3.1 X.509

A Recomendação ITU-T X.509 define uma estrutura para certificados de chave pública, formando uma base para estabelecer ICP, e outra estrutura, para certificados de atributos, destinados à fundamentação de infra-estruturas de Gerenciamento de Privilégios (IGP, ou Privilege Management Infrastructures - PMI). As IGP complementam as ICP oferecendo a possibilidade de utilização de autenticação multi-nível, baseada em regras de acesso e nas funções de seus usuários (1), utilizando-se dos certificados de atributos. Elimina-se assim a necessidade alteração e aumento da quantidade de informações nos certificados de chave pública (X.509, 2000). As IGP não são tratadas neste trabalho.

Essa recomendação fornece um meio para parceiros de comunicações recuperar em informações mútuas de autenticação, de acordo com suas necessidades. Dois níveis de autenticação são descritos: simples e forte. Esta última, mais segura, utiliza criptografia assimétrica. Sua principal vantagem é o emprego de certificados, emitidos por Autoridades Certificadoras (AC, ou Certification Authorities - CA), os quais podem ser armazenados como valores de atributos em diretórios e disponibilizados ao público.

Embora as AC sejam definidas de modo não-ambíguo por DN em uma DIT, não existe necessariamente uma relação direta entre um conjunto de AC e a DIT. As AC podem possuir sua própria hierarquia, constituída pela relação imposta pelos certificados armazenados em suas entradas no diretório, conforme visto na Figura 2. Da mesma figura, constata-se que tal hierarquia é formada pela emissão dos certificados das AC 2, 3e 4 pela CA1 e do certificado da CA5 pela CA3.

Figura 2 - Comparação entre estruturas hierárquicas de diretórios e de AC.

1 - Tanto aplicações, quanto serviços, podem ser também considerados usuários.

^

3.1.1 Certificados

O certificado definido pela X.509 é composto por campos básicos - versão do certificado; período de validade; número de série; DN de seu proprietário (2); DN do emissor; algoritmo de assinatura; chave pública com respectivo algoritmo; e extensões. A principal atribuição dessas extensões é permitir a inclusão de novos campos aos certificados, sem necessidade de modificação de sua estrutura de codificação, que utiliza a Distinguished Encoding Rules (DER), um subconjunto da codificação Abstract Syntax Notation #1 (ASN.1). Tal característica facilita o projeto e a implementação de políticas de segurança em ambientes distribuídos de grande porte.

A Recomendação X.509 define extensões para executar as seguintes funções:

• fornecer informações sobre chaves públicas e políticas de certificação;
• oferecer nomes alternativos a emissores e proprietários;
• restringir caminhos de certificação;
• permitir a inclusão de códigos de motivos de revogação e números de seqüência a Listas de Revogação de Certificados (LCR, ou Certificate Revocation Lists - CRL);
• dividir informações de revogação em várias LCR ou as informações de várias LCR em apenas uma.

Para se descrever a notação definida pela X.509 para a representação de certificados, as seguintes relações entre as AC X, Y e Z são inicialmente supostas:

• Y é diretamente subordinada a X na hierarquia;
• Z é diretamente subordinada a X na mesma hierarquia;
• Y e Z não são diretamente subordinadas entre si.

Portanto, a notação utilizada é:

• X<<Y>> - certificado de Y, emitido por X (certificado direto);
• Y<<X>> - certificado de X, emitido por Y(certificado reverso);
• Y<<Z>>, Z<<Y>> - certificado de Z, emitido por Y, e de Y, emitido por Z (par de certificados cruzados).

2 - Detentor da chave pública contida no certificado emitido pela AC.

^

3.1.2 Caminhos de certificação

Caminhos de certificação são conjuntos de certificados que constituem uma cadeia de confiança entre duas entidades, uma delas necessitando autenticar a outra, de forma que a primeira seja capaz de validar a chave pública da última. O método de determinação de um caminho pode variar. Uma maneira fácil de se fazer isso é disponibilizando-se uma hierarquia de AC, de modo que os usuários dessa hierarquia possam estabelecer caminhos de certificação apenas por meio de acesso a diretórios, sem nenhuma informação prévia. A Figura 3 ilustra um exemplo de hierarquia de CAs.

No exemplo abaixo, para A estabelecer umcaminho de certificação com B, os seguintes certificados são recuperados do diretório:

Figura 3 - Exemplo de hierarquia de AC.

Usualmente, o número de certificados a serem recuperados pode ser reduzido de várias maneiras (X.509, 2000):

1. se dois parceiros, A e C, possuem certificados emitidos pela mesma AC, D, então o caminho entre A e C é dado por: D<<C>> ;
2. se um usuário armazena todos os certificados localmente, da AC emissora de seu certificado à sua AC raiz, e seu parceiro pertence à mesma hierarquia, com um ancestral em comum, J, o caminho de A a B pode ser: J<<H>>, H<<F>>, F<<B>>;
3. se um" usuário A comunica-se freqüentemente com usuários que possuam certificados emitidos por uma AC específica, por exemplo, F, ele pode "aprender" o caminho até essa AC (por exemplo: D<<G>>, G<<J>>, J<<H>>, H<<F>> ) e recuperar apenas o certificado do parceiro, F<<B>> ;
4. é possível também a emissão de certificados cruzados, em conformidade com acordos bilaterais, para encurtar caminhos, de tal maneira que se usuários certificados pelasCAs D e F comunicam-se com freqüência, então o caminho entre A e B pode ser: D<<F>>, F<<B>> ;
5. se usuários estabeleceram comunicação previamente, eles podem armazenar localmente seus caminhos de certificação e não necessitam, portanto, recuperar nenhum certificado do diretório novamente.

^

3.2 PKIX

A Internet X.509 Public Key Infrastructure (PKIX) é um esforço do grupo de trabalho PKIX (pkix, 2001) da Internet Engineering Task-Force (IETF) para prover funções de identificação, autenticação, controle de acesso e autorização de modo determinístico e automático na Internet. Seu desenvolvimento foi motivado pelo fato de que a X.509 define uma estrutura muito abrangente, o que permite a coexistência de várias implementações compatíveis com a X.509, mas incompatíveis entre si.

Esta proposta de padronização define perfis e protocolos de certificados e LCR, bem como impõe um número de restrições, projetadas para melhorara gerência e a interoperabilidade de aplicações de ICP, sem grande demanda de banda de comunicação, conectividade IP em tempo real, ou alta disponibilidade de conexões (Housley, 1999). Embora a PKIX seja baseada na RecomendaçãoX.509, ela não requer o uso de sistemas de diretórios X.500, nem tampouco o proíbe. Portanto, outros métodos de distribuição de certificados e LCR, podem ser utilizados.

^

3.2.1 Certificados

A PKIX define o formato e a semântica de certificados e LCR para uso na Internet, determinando uma base comum para aplicações que necessitem de interoperabilidade e outros requisitos para propósitos específicos, tais como correio eletrônico, WWW e IPSec. Os campos básicos dos certificados são os mesmos definidos na X.509, como também suas extensões, incluindo-se a extensão Authority Information Access, destinada a guiar aplicações para serviços de validação online.

^

3.2.2 Repositórios LDAP

Para a utilização do LDAP em repositórios de certificados e LCR, a PKIX define um protocolo operacional, descrevendo as operações de acesso a repositórios via LDAPv2 (Boyen et al., abril de1999) e LDAPv3 (Chadwick, 2000), além de um esquema de armazenamento desse tipo de informação, descrevendo atributos e classes de objetos a serem utilizados por servidores LDAP, de ambas as versões, que atuem como repositórios PKIX (Boyen et al., junho de 1999).

^

3.2.3 Caminhos de certificação

Nenhum método para recuperar certificados que constituam um caminho de certificação é especificado pela PKIX, embora um algoritmo para validar tal caminho seja descrito em (Housley,1999). Uma implementação compatível com a PKIX não necessita adotar esse algoritmo em particular, mas qualquer alternativa deve ser funcionalmente equivalente a seu comportamento externo.

O algoritmo básico de validação definido supõe que todos os caminhos válidos iniciam-se com certificados emitidos por apenas uma AC, chamada AC de maior confiança, definida pela política adotada em cada caso. Essa AC pode ser a AC-Raiz em uma hierarquia de ICP (certificado auto-assinado), a AC emissora do certificado do usuário que realiza a verificação, ou qualquer outra escolha que se julgue adequada. O procedimento de validação de caminhos é o mesmo, independente da escolha da AC de maior confiança.

^

4. Processamento de caminhos de certificação

O processamento de um caminho de certificação para que sua validade seja verificada é composto de duas etapas: determinação, quando os certificados são recuperados de um repositório e o caminho é construído, e validação, quando cada certificado desse caminho tem sua integridade, seu período de validade e informações relacionadas a sua semântica verificados, de modo a validar o caminho determinado.

Examinando-se os aspectos dos caminhos de certificação nas definições da X.509 e da PKIX, pode-se concluir que na primeira a abordagem é muito generalizada e nenhum método específico para determinar ou validar caminhos é especificado. A abordagem da segunda define em detalhes apenas um algoritmo básico de validação de caminhos e a determinação desses caminhos não está sujeita a padronização.

A seguir, serão apresentadas quatro métodos de processamento existentes ou anteriormente propostos, e sua aplicabilidade a grandes ambientes distribuídos é discutida. Na próxima seção, um novo método é proposto e a implementação de um protótipo desse método é descrita.

^

4.1 Cadeias de certificados com AC-Raízes isoladas

Este método é implementado em larga escala por AC comerciais e web browsers mais utilizados para autenticação via Secure Sockets Layer (SSL)(SSL,1998), bem como em clientes de correio eletrônico que utilizem o protocolo Secure Multipurpose Internet Mail Extensions (S/MIME)(Ramsdell, 1998).

A cadeia de certificados é uma estrutura composta por um conjunto de certificados, da AC imediatamente abaixo da AC raiz até o usuário, assinada digitalmente e envelopada pela AC raiz da hierarquia. Para que seja possível autenticarem-se usuários ou entidades de hierarquias distintas, o cliente deve armazenar todos os certificados auto-assinados de AC-Raízes necessários, conforme sugerido pela especificação da PKIX (Housley,1999) e descrita anteriormente. Alguns dos métodos empregados na publicação ou recuperação de certificados são: mensagens de correio eletrônico S/MIME e acesso a repositórios distribuídos via LDAP, dentre outros.

O processamento de caminhos com cadeias de certificados e múltiplos certificados auto-assinados é de simples e fácil implementação, já que apenas o mecanismo de validação é necessário, pois o processo de determinação é realizado no momento em que a cadeia de certificados é assinada e envelopada. No entanto, em grandes ambientes intra e intercorporativos, a manutenção e a gerência de listas locais de certificados de AC-Raízes feitas por cada um dos usuários, de acordo com a política de segurança da empresa, tornam-se extremamente árduas. Tais usuários devem ser freqüentemente atualizados sobre determinações de inclusão e exclusão de certificados auto-assinados emitidas pelo gerente do sistema. Se um desses usuários não estiver presente, por ocasião do recebimento de tais solicitações, ou simplesmente não acatar tais solicitações, a pessoa arrisca-se a utilizar certificados de AC-Raízes não autorizadas e causar sérios prejuízos financeiros ou outros tipos de perda.

A implementação de um servidor adicional para gerenciar automaticamente a lista local de cada usuário poderia eliminar o problema citado acima, mas quanto mais servidores um sistema empregar, mais ele estará sujeito à indisponibilidade causada por falha acidental ou ataques de negação de serviço. Além disso, um ataque de personificação realizado diretamente no servidor em questão pode comprometer todos os clientes do sistema.

^

4.2 Grafos de hierarquias de CAs

Proposto em (Medina, 1996), neste método o programa cliente checa previamente e armazena todos os certificados de CAs da hierarquia do usuário que liguem seu certificado de usuário à sua AC-Raiz. Esta hierarquia é tratada como um grafo direcionado, onde os nós representam as AC e os arcos, os certificados que as interrelacionam. De acordo com o algoritmo proposto, chamado HI, são inseridos nós a um novo grafo, iniciando com a AC emissora do certificado do usuário sujeito a verificação, até que uma interseção com o grafo da hierarquia local seja encontrada. Cada certificado tem sua integridade verificada à medida que é inserido nesse novo grafo. Após a determinação do caminho de certificação completo, sua validação é realizada.

Como não há restrição imposta a este método por meio de políticas de certificação, pode haver múltiplos caminhos alternativos. Portanto, o algoritmo proposto é projetado para determinar o menor deles, pois quanto menor a cadeia de confiança formada pelo caminho de certificação, menos sujeita a falhas ela será.

Esta abordagem de grafos provê um modo único, geral e flexível para determinação de caminhos de certificação, independente dos formatos das árvores hierárquicas. Além disso, há apenas um certificado auto-assinado para se confiar, tornando tal abordagem menos vulnerável a ataques de personificação diretamente aos usuários. A confiança em certificados de outras ICP é estabelecida por meio de certificação mútua (cruzada) entre AC da hierarquia local com AC de outras hierarquias.

Por outro lado, à medida que o número de hierarquias aumenta, as tarefas de recuperação de certificados, construção de grafos e determinação do menor caminho tornam-se extremamente onerosas. Em casos onde vários grafos são interligados por um grande número de nós, direta ou indiretamente, pode ser necessário recuperarem-se praticamente todos os certificados dessas hierarquias. Por conseguinte, uma implementação de cliente que utilize o método de hierarquia de grafos pode consumir mais recursos computacionais que suas funções principais.

Uma solução para viabilizar este método em grandes sistemas distribuídos é a redução de tráfego e demanda de recursos de processamento por meio do armazenamento das ICP previamente utilizadas em uma cache local. No entanto, o esforço necessário para gerenciar e manter atualizada essa cache também compromete a praticidade de tal implementação.

Outra alternativa seria a utilização de uma cache em conjunto a um servidor de informações de ICP, de maneira a manter os clientes atualizados automaticamente. A desvantagem desta abordagem seria o aumento na probabilidade de indisponibilidade devido a falhas acidentais ou ataques de negação de serviço, bem como o aumento da vulnerabilidade a ataques de personificação contra o servidor, comprometendo todos os seus usuários, como já descrito no método anterior.

^

4.3 Serviço de validação de caminhos de certificação

Trata-se de um serviço que realiza todas as etapas do processamento de caminhos de certificação, proposto em (Housley, 1999), utilizando-se um Servidor de Validação e Certificação de Dados (Data Validation and Certification Server - DVCS) - entidade de confiança definida em (Adams, 2001), cujas funções principais são: validação de assinaturas e fornecimento de informações atualizadas de situação de certificados.

Para autenticar um usuário de ICP, o cliente envia uma requisição ao DVCS, anexando o certificado daquele usuário. O DVCS recupera todos os certificados necessários de repositórios distribuídos, determina e valida o caminho e então envia o resultado ao cliente com um token que permite várias transações durante um intervalo de tempo, sem a necessidade de se repetir a autenticação.

A implementação do cliente é extremamente simples, já que não realiza praticamente nenhuma etapa do processamento dos caminhos. Em contrapartida, em caso de falha, ataques de negação de serviço, ou personificação, todos os usuários e entidades são comprometidos. De maneira a proteger esse servidor, devem-se fornecer meios adicionais e mais rígidos de segurança. Também, para que um DVCS ofereça esse serviço, há um sensível aumento no custo e na complexidade da implementação de um servidor de alto desempenho e de uma infra-estrutura de rede de alta disponibilidade para comportá-lo.

^

4.4 Servidor LDAP modificado

A determinação de caminhos de certificação, como proposto e discutido em (Mensagens PKIX, 1998), é feita pelo servidor de acesso a repositórios. Após receber uma solicitação, tal servidor determina o caminho e envia ao usuário solicitante todos os certificados que compõem esse caminho. Ao cliente ainda cabe a responsabilidade de validar o caminho encontrado. O protocolo empregado para operações de acesso a repositórios é o LDAP.

Em grandes ambientes corporativos, a implementação deste método em um servidor LDAP poderia gerar uma sobrecarga de processamento e sua atividade principal - o acesso a diretórios - poderia ser comprometida. Além do acima exposto, a modificação de um protocolo já consolidado e largamente empregado como o LDAP poderia comprometer suas características de portabilidade, escalabilidade e interoperabilidade, embora nenhuma vulnerabilidade de segurança seja acrescentada, pois a validação é realizada pelo cliente e nenhum servidor adicional é incluído.

^

5. Processamento dinâmico - um novo método proposto

O método apresentado abaixo visa fornecer uma solução para ambientes corporativos, podendo ser implementado de maneira simples, sem a necessidade de servidores adicionais. Uma implementação experimental deste método também é descrita.

^

5.1 Política de certificação adotada

Antes de se definir o método, um passo essencial é o delineamento de uma política de certificação e o ambiente em que ela será empregada - grandes organizações com filiais geograficamente distribuídas, necessitando comunicarem-se com outras empresas ou órgãos similares, cada qual com sua própria hierarquia de AC. A política definida para esse tipo de ambiente é:

• uma AC pode apenas emitir certificados para AC ou usuários a ela diretamente subordinados;
• apenas a AC-Raiz pode emitir certificados cruzados para AC-Raízes de outras hierarquias;
• não é permitida a certificação cruzada no âmbito da mesma hierarquia, seja verticalmente - entre AC do mesmo ramo da hierarquia, seja horizontalmente - entre AC do mesmo nível hierárquico;
• não há transitividade de confiança entre AC-Raízes, ou seja, se X, raiz de uma hierarquia, confia em Y, pertencente a uma segunda hierarquia, e Y confia em Z, de uma terceira hierarquia, então X não deve confiar em Z utilizando Y como intermediário e, conseqüentemente, X deve confiar em Z diretamente por meio de certificação cruzada.

^

5.2 Descrição do método proposto

O método de processamento dinâmico de caminhos de certificação constrói um caminho à medida que cada certificado é recuperado de um repositório via LDAP, sem a utilização de algoritmos para manipulação de grafos ou determinação de menor caminho. A simplicidade deste método reside no fato de que existe apenas um caminho de certificação possível, pois apenas AC-Raízes são autorizadas pela política a realizar certificação cruzada com AC-Raízes de outras hierarquias e não há transitividade de confiança entre tais AC, como descrito anteriormente.

O processamento de caminhos de certificação necessita do armazenamento de uma lista local pelo programa cliente, contendo todos os certificados que constituem o caminho entre a AC emissora do certificado do usuário até a AC raiz da sua hierarquia, inclusive. Essa lista local é chamada de cadeia local de confiança. Aplica-se o algoritmo de validação definido pela PKIX após a determinação do caminho, esta última definida a seguir:

1. recupera-se do repositório o certificado do usuário que se deseja autenticar;
2. determina-se o DN de sua AC emissora;
3. recupera-se o certificado da AC emissora;
4. se o certificado for auto-assinado e não fizer parte da cadeia local de confiança, ou seja, pertencente a uma AC raiz de outra hierarquia, então:
   
   
   • se for encontrado um certificado cruzado para a AC raiz de outra hierarquia emitido pela AC raiz local, ele é incluído no caminho e a determinação é concluída com sucesso;
   • caso contrário, o processo termina sem um caminho encontrado;
   
   
5. inclui-se o certificado no caminho;
6. repetem-se os passos b, c, d e e até que:
   
   
   • o DN de uma AC emissora, constante em um certificado encontrado, seja o DN de um certificado que faça parte da cadeia local de confiança, quando o processo termina com sucesso; ou
   • não seja possível se recuperar um certificado e o processo termine sem um caminho encontrado.

O caminho de certificação resultante que será validado é iniciado por um dos certificados da cadeia local de confiança e termina com o certificado do usuário a ser verificado.

Como apenas a cadeia local de confiança é armazenada pelo cliente, não há necessidade de servidores adicionais para gerência de informações locais de ICP em cada cliente, reduzindo-se, portanto, o custo de implementação. A interoperabilidade também é melhorada, pois não é necessária a definição de uma nova padronização de servidor ou a modificação dos padrões utilizados. Para que se possa reduzir o tráfego gerado pelo método de processamento proposto, uma cache local poderia ser utilizada para armazenar os caminhos de certificação válidos, verificados mais recentemente ou os mais utilizados.

Sistemas corporativos distribuídos podem tirar proveito deste método, pois a demanda de uma grande quantidade de operações de acesso a repositórios pode ser compensada pela eliminação da necessidade de servidores adicionais, simplificando sobremaneira a gerência da ICP e tornando o sistema menos vulnerável a falhas não-intencionais, ataques de negação de serviço ou de personificação, que venham a prejudicar todos os usuários em função do comprometimento de apenas um servidor.

^

5.3 Implementação

Um protótipo, chamado Pequi (3) , foi implementado nas linguagens C e C++ para ambientes Linux Red Hat 5.1, com o intuito de demonstrar a viabilidade do método de determinação dinâmica proposto. Esse protótipo realiza todo o processamento automaticamente, acessando repositórios distribuídos via LDAP e fazendo uso de referrals. A autenticação forte para controlar o acesso ao repositório é fornecida pelo Kerberos e as funções de manipulação de certificado e parte da validação de caminhos de certificação, pelo Open Secure Certificate ARchitecture (Oscar). As bibliotecas empregadas pelo Pequi são descritas a seguir.

A Interface de Programa de Aplicação (Application Program Interface - API) do KTH-Krb (Danielsson, 1997), compatível com o Kerberos versão 4 e desenvolvida em linguagem C pelo Real Instituto de Tecnologia, Suécia, permite a implementação de diversos clientes e servidores autenticados, como por exemplo: telnet, ftp, popper, rsh, login, etc. Esta API é utilizada diretamente pelo LDAP para autenticação forte no acesso ao diretório.

A API do LDAP, implementada em C, define interfaces síncronas e assíncronas para acesso a diretórios, além de ferramentas para manipulação de atributos e valores de entradas, de acordo com (Howes, 1995). O OpenLDAP 1.0.2 (OpenLDAP, 2001) foi a implementação utilizada, por sua maior portabilidade e por possuir um grande número de bugs corrigidos, em relação à implementação da Universidade de Michigan (LDAP, 1997).

A versão 3.0b6 do Oscar (Oscar, 1998), implementado em C++ no Centro de Tecnologia de Sistemas Distribuídos (Distributed Systems Technology Centre - DSTC) da Universidade de Tecnologia de Queensland (Queensland University of Technology - QUT), Austrália, oferecia uma vasta gama de funções da PKIX necessárias a gerência de ICP: manipulação e validação de certificados, bem como a validação de caminhos de certificação. O Oscar fazia uso de outras bibliotecas, tais como SNACC (para codificação e decodificação de estruturas ASN.1), criptografia assimétrica RSA e o algoritmo de criptografia simétrica DES contido no SSLeay (Young, 1998) que, posteriormente, foi descontinuado e transformado em OpenSSL (OpenSSL, 2001), mantido por um consórcio internacional de desenvolvedores de código aberto. Alguns dos protocolos da série PKCS (Kaliski, 1993) também são implementados.

O Pequi utiliza interface síncrona, orientada a conexão, com os diretórios que atuam como repositórios de ICP. Se um referral é recebido de um servidor LDAP, o cliente repete a operação de leitura em todos os servidores indicados na mensagem de referral, até que a entrada desejada seja encontrada.

Uma limitação da função de validação de caminhos do Oscar restringia os caminhos validados àqueles que iniciavam com certificados auto-assinados. Portanto, a cadeia local de confiança descrita anteriormente não foi implementada. Experimentalmente, apenas o certificado da AC raiz local foi utilizado como início de caminhos de certificação.

Cabe ressaltar que cada acesso a repositório realizado pelo Pequi recupera todos os certificados e pares de certificados cruzados contidos na entrada encontrada. Tal característica reduz o tráfego na rede, por não exigir um acesso ao repositório para recuperar cada certificado, como também permite a utilização de múltiplos certificados pelos usuários, cada um para uma finalidade distinta, fazendo-se uso da extensão keyUsage.

O protótipo não implementa consultas a LCR para verificar a situação de certificados, mas essa função pode ser facilmente inserida no futuro. As funções de gerência de ICP, tais como publicação de certificados, geração de pares de chaves, requisições de certificação, emissão de certificados e manutenção de entradas dos repositórios são fornecidas por ferramentas executadas via janela de comandos, implementadas pelo OpenLDAP e pelo Oscar, utilizando-se autenticação forte via Kerberos. Vale a pena ressaltar que os certificados são recuperados por meio de operações de consulta ao repositório LDAP sem autenticação, por não haver tal necessidade, já que um certificado não pode ser adulterado sem que tal ato seja detectado.

3 - Nome dado devido a sua semelhança com a pronúncia da sigla PKIX em inglês [pikix], com o intuito de facilitar uma divulgação externa da ferramenta.

^

6. Conclusões

Este artigo discutiu aspectos relacionados ao estabelecimento de cadeias de confiança entre parceiros de comunicação, por meio de caminhos de certificação. Como as padronizações existentes, X.509 e PKIX, não abrangem por completo tais aspectos, a X.509 permitindo que implementações compatíveis com tais especificações, sejam incompatíveis entre si, e a PKIX apenas impondo restrições à validação de caminhos, foi identificada a necessidade de se estudarem os métodos de processamento de caminhos de certificação e, em especial, o processo de determinação de caminhos.

Quatro métodos de processamento foram descritos e discutidos: cadeias de certificados com AC-Raízes isoladas, grafos de hierarquia de AC, serviço de validação de caminhos de certificação e servidor LDAP modificado. O método proposto, determinação dinâmica de caminhos, teve suas vantagens ressaltadas, em relação aos outros métodos discutidos, em sistemas corporativos distribuídos de grande porte. São elas:

• simplicidade de implementação, pois:
  
  
  • programa cliente não necessita exercer funções implementadas para gerência de informações de ICP armazenadas localmente, a não ser para a manutenção da cadeia local de confiança;
  • não é necessária a implementação nem a modificação de servidores, já que utilizam-se os disponíveis no domínio público;
  
  
  
• maior imunidade a ataques de personificação que possam prejudicar todos os usuários de uma ICP, em função do comprometimento de apenas um servidor, por não necessitar de servidores adicionais;
• baixo índice de indisponibilidade do sistema por falha ou ataques de negação de serviço, por necessitar de menor número de servidores;
• interoperabilidade, por:
  
  
  • basear-se em padronizações já existentes;
  • possuir uma política de certificação predeterminada, ou seja, todas as implementações de ICP que seguirem essa política utilizarão o mesmo formato de árvore hierárquica, possibilitando assim a aplicação do método processamento de caminhos proposto em ambientes distribuídos contendo várias hierarquias independentes umas das outras;
  
  
  
• o menor custo de implementação, pois:
  
  
  • não requer o desenvolvimento de servidores que, para atender a aplicações em ambientes distribuídos de grande porte, devem possuir: alto desempenho, baixo índice de indisponibilidade e alto custo de implementação;
  • o programa cliente não necessita ter funções de gerência de informações locais de ICP;
  • não necessita adotar mecanismos de segurança na comunicação entre cliente e servidor de repositório, para operações de consulta.

Duas limitações também foram identificadas e suas respectivas soluções, sugeridas:

• alta demanda de tráfego entre o cliente e o servidor de repositório durante a fase de construção do caminho - a utilização de uma cache local poderia minimizar essa demanda;
• o número total de certificações cruzadas realizadas por uma AC-Raiz é limitado à capacidade de armazenamento de informações de ICP em uma entrada de repositório - a inclusão de uma AC-Raiz de nível hierárquico superior, transformando várias árvores hierárquicas independentes em uma única árvore de maior altura, poderia compensar tal limitação.

Algumas características ainda necessitam ser implementadas, de modo que este protótipo possa ser efetivamente útil a aplicações de larga escala: uma cadeia local de confiança para armazenar os certificados da hierarquia local; uma cache para armazenar os caminhos recentemente ou freqüentemente verificados; um Ambiente Pessoal Seguro (Personal Secure Environment - PSE), para o armazenamento seguro da chave privada do usuário, da cadeia local de confiança e da cache de caminhos válidos; e, finalmente, da inclusão de listas de certificados revogados, CRLs, armazenadas em repositórios e utilizadas para fornecer informações sobre situação de certificados.

^

Referências bibliográficas

[1] ADAMS, C. et al. Internet X.509 Public Key Infrastructure - Data Validation and Certification Server Protocols. IETF Draft, PKIX Working Group, RFC 3029, February 2001.

[2] ARSENAULT, A. and Turner, S. Internet X.509 Public Key Infrastructure - PKIX Roadmap. IETF Draft, PKIX Working Group, <draft-ietf-pkix-roadmap-06.txt>, November 2000.

[3] BOEYEN, S. et al. Internet X.509 Public key Infrastructure - LDAPv2 Schema. RFC 2587, PKIX Working Group, June 1999.

[4] BOEYEN, S. et al. Internet X.509 Public key Infrastructure - Operational Protocols - LDAPv2. RFC 2559, PKIX Working Group, April 1999.

[5] CHADWICK, D.W. Internet X.509 Public Key Infrastructure - Operational Protocols - LDAPv3, IETF Draft, PKIX Working Group, <draft-ietf-pkix-ldap-v3-03.txt>, September, 2000.

[6] DANIELSSON, J., Westerlund, A. KTH-KRB Edition 1.0 for version 0.9.8. KTH (Kungliga Tekniska Högskolan - Real Instituto de Tecnologia, Estocolmo, Suécia), December 1997.
http://www.pdc.kth.se/kth-krb

[7] HOUSLEY, R., et al. Internet Public key Infrastructure - X.509 Certificate and CRL Profile. IETF Draft, PKIX Working Group, RFC 2459, January 1999.

[8] HOWES, T.and Smith, M. LDAP Application Program Interface. RFC1823, IETF, August 1995.

[9] HOWES, T.and Smith, M. Programming Directory-Enabled Applications with Lightweight Directory Access Protocol. Macmillan Technology Publishing, 1997.

[10] Innosoft's LDAP World Implementation Survey. 1997, http://www.innosoft.com/ldap_survey/liav.html.

[11] KALISKI Jr., B. An Overview of the PKCS Standards. November 1993, http://www.rsa.com/rsalabs/pubs/PKCS.

[12] LDAP. Lightweight Directory Access Protocol. 1997, http://www.umich.edu/~dirsvcs/ldap.

[13] MEDINA, M. Segurança em Correio Eletrônico - Distribuição de Chaves Públicas e Caminhos de Certificação. Rio de Janeiro: PUC-Rio, 1996. Dissertação de Mestrado

[14] Mensagens PKIX. Mensagens postadas na lista do grupo de discussão do PKIX, ietf-pkix@imc.org, sob o título de assunto "certificate path services", entre 15 e 16 de outubro de 1998.

[15] OpenLDAP - the Open Source for LDAP software and information. 2001, http://www.OpenLDAP.org.

[16] OpenSSL: The Open Source Toolkit for SSL/TLS. 2001, http://www.openssl.org.

[17] Oscar - DSTC's Public key Infrastructure Project, December 1998, http://oscar.dstc.qut.edu.au.

[18] PKIX - Intenet X.509 Public Key Infrastructure. 2001, http://www.ietf.org/html.charters/pkix-charter.html.

[19] RAMSDELL, B. S/MIME Version 3 Certificate Handling. IETF Draft, <draft-ietf-smime-cert-06.txt>, December 1998.

[20] S/MIME and PGP/MIME. 1998, http://www.imc.org/smime-pgpmime.html.

[21] SSL. Secure Sockets Layer. 1998, http://home.netscape.com/products/security/ssl.

[22] WAHL, M. et al. Lightweight Directory Access Protocol (v3). RFC 2251, IETF, December 1997.

[23] X.500. The Directory: Overview of Concepts, Models and Services. ITU-T Recommendation X.500, Geneva: November 1993.

[24] X.509. Information Technology - Open Systems Interconnection - The Directory Public-key and Attribute Certificate Frameworks. ITU-T Recommendation X.509, 4th Edition. Geneva. March, 2000.

[25] YEONG, W. et al. Lightweight Directory Access Protocol. RFC 1777, IETF, March 1995.

[26] YOUNG, E. and Hudson, T., SSLeay and SSLapps FAQ. September 1998, http://www.psy.uq.oz.au/~ftp/Crypto/.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004