INFRAESTRUTURA DE CHAVE PÚBLICA

Para que se possa criar e validar uma assinatura digital utiliza-se a Infraestrutura de Chave Pública. Utiliza-se criptografia assimétrica e certificados digitais para garantir a integridade e validação de um determinado usuário que esteja solicitando um serviço.

Uma Infraestrutura de Chave Pública é atualmente uma das opções mais utilizadas para manter a integridade e autenticar informações trafegadas e é composta por:

• Entidade Final: Proprietário do certificado ao qual foi emitido, também conhecido como sujeito, podendo ser tanto pessoa física como qualquer entidade que possa utilizar um certificado de chave pública.
• Autoridade Certificadora (AC): Responsável por gerenciar e emitir os certificados. É a principal entidade da ICP. É responsável também pela revogação dos certificados através principalmente da utilização de uma lista chamada Lista de Certificados Revogados (LCR). Outros métodos também podem ser usados.
• Autoridade de Registro (AR): É uma entidade opcional dentro da arquitetura da ICP, usada principalmente para processos administrativos, podendo delegar determinadas funções desde pedidos de registro de um usuário final como também solicitações para revogação de certificados. Apesar de poder executar diversas tarefas, ela não pode emitir certificados, o que é exclusivo das ACs.
• Repositório: Local onde são armazenados os certificados e listas de certificados revogados. Também conhecido como Diretório pode ser implementado utilizando diversos protocolos, dos quais o principal tem sido o LDAP(Lightwigth Directory Access Protocol), que permite o acesso aos dados de forma mais simples que o padrão definido no padrão X.500.

 

GERAÇÃO DE PARES DE CHAVES

Na Infraestrutura de Chave Pública faz-se uso dos pares de chaves (privada e pública), a privada como o nome diz é conhecida apenas pelo usuário e a pública fica disponível para o acceso de todos. É vital para a segurança geral que todas as chaves privadas permaneçam sob o conhecimento apenas do usuário a quem elas pertencem.

Dados da chave são difíceis para um usuário comum lembrar, portanto, um método adequado para armazená-lo de uma maneira conveniente deve ser empregado. Um possível mecanismo seria a utilização de um "Smart Card", que guardaria sua chave privada e opcionalmente suas chaves públicas, o certificado do usuário, e uma cópia da chave pública da AC. O uso deste cartão deveria adicionalmente, ser assegurada por, por exemplo, a utilizaçao de um Número de Identificação Pessoal (PIN), aumentando a segurança do sistema, exigindo que o usuário possua o cartão e saiba como acessá-lo.

Há três maneiras em que um par de chaves de um usuário pode ser produzido:

• O usuário gera o seu próprio par de chaves. Este método tem a vantagem de que a chave privada do usuário nunca é liberada para outra entidade, mas requer certo nível de competência pelo usuário.
• O par de chaves é gerado por um terceiro. O terceiro deve liberar a chave privada para o usuário de uma maneira fisicamente segura, e depois ativamente destruir todas as informações relativas à criação do par de chaves. Medidas adequadas de segurança devem ser empregadas para garantir que as operações de dados estejam livres de adulteração.
• O par de chaves é gerado pela AC. Este é um caso especial da geraçao de chaves por um terceiro, diferindo do anterior, pois a AC já apresenta a funcionalidade de confiança com respeito ao usuário, e estarão sujeitas às medidas de segurança física necessária. Este método tem a vantagem de não necessitar a transferência dos dados para a AC para certificação.

 

CRIAÇÃO DE CERTIFICADOS DE CHAVE PÚBLICA

Um certificado de chave-pública associa a chave pública a um único e distinto nome de usuário. Para isso, a AC deve estar satisfeita com a identidade do usuário antes de criar um certificado para ele. A AC não emite certificados para dois usuários com o mesmo nome, portanto é importante que a transferência de informações para a AC não seja comprometida e adequadas medidas de segurança física devem ser tomadas:

• Seria uma grave violação de segurança se uma AC emitisse um certificado para um usuário com uma chave pública que tenha sido adulterada.
• Se os meios de geração de pares de chaves forem gerados por um terceiro ou pela AC a chave privada do usuário, deve ser transferida a ele de forma segura.
• Se os meios de geração de pares de chaves forem gerados pelo própio usuário ou por um terceiro que não é uma AC, o usuário pode usar diferentes métodos (on-line ou off-line) para comunicar a sua chave pública para a AC de uma maneira segura. Métodos on-line podem fornecer alguma flexibilidade adicional para operações remotas realizadas entre o usuário e a AC.`

Um certificado de chave pública é um pedaço de informação publicamente disponível, e nenhuma medida específica de segurança precisa ser empregada em relação ao seu transporte para o Diretório. Como é produzido por uma AC off-line em nome de um usuário, o qual deve obter uma cópia do mesmo, o usuário só precisa armazenar essas informações em sua entrada de diretório em um acesso posterior ao Diretório. Alternativamente, a AC pode disponibilizar o certificado para o usuário, que nesse caso deve ser dado direito de acesso adequados.

 

CERTIFICADOS DE CHAVE PÚBLICA

O certificado de chave pública definido nas Recomendaçoes X.509 é para uso de aplicativos que tem como requisitos a autenticação, confidencialidade, integridade e o não repúdio.

Sua estrutura é formada por:

• Versão: Indica a versão do certificado. Se o campo de Extensões está presente então a versão deve ser v3.
• Número Serial do Certificado: Número único atribuido pela entidade que emite o certificado.
• Identificador de Algoritmos de Assinatura: Contém o identificador do algoritmo criptográfico para gerar a função hash que foi usado pela AC para assinar o certificado.
• Nome do Emissor: Identifica a entidade que assinou e emitiu o certificado.
• Validade: Intervalo de tempo durante o qual a AC garante que vai manter as informações sobre o estado do certificado.
• Nome do Sujeito: Identifica a entidade associada com a chave pública encontrada no campo de chave pública do certificado. É o nome do proprietário do certificado.
• Informações sobre a chave pública do sujeito: Informações sobre a chave pública e do algoritmo do proprietário.
• Identificador Único do Emissor: Campo utilizado para identificar o nome do emissor em caso que seja necessário reutilizar os nomes.
• Identificador Único do Sujeito: Identifica o nome do sujeito em caso que seja necessário reutilizar os nomes.
• Extensões: Incluem no certificado opções de acrescentar informações adicionais a ele, como por exemplo, informações para identificar de maneira mais segura o sujeito do certificado, sobre período de validade, e principalmente informações sobre autorização.

 

VALIDAÇÃO DE CERTIFICADOS

A autoridade que emite certificados (de chave pública ou atributo) tem a responsabilidade de indicar a validade dos certificados que emite. Geralmente, os certificados estão sujeitas a uma possível revogação posterior. Esta revogação, e notificação da revogação podem ser feita diretamente pela mesma autoridade que emitiu o certificado, ou indiretamente por outra autoridade devidamente autorizada pela autoridade que emitiu o certificado. As autoridades que emitem certificados são obrigadas a indicar, possivelmente através de um comunicado público sobre suas práticas, através dos próprios certificados, ou através de outros meios identificados, quando:

• Os certificados não podem ser revogados, ou;
• Os certificados podem ser revogados pela autoridade de certificação emissora do mesmo diretamente, ou;
• A autoridade certificadora autoriza uma entidade diferente para executar a revogação.

Autoridades que revogam certificados devem declarar, através de meios semelhantes, qual mecanismo(s) pode ser utilizado para obter informações sobre o estado de revogação dos certificados emitidos por essa autoridade. É definido um mecanismo de Lista de Certificados Revogados (LCR - Certificate Revocation List), mas não impede o uso de mecanismos alternativos, como por exemplo, o Online Certificate Status Protocol (OCSP) especificado no IETF RFC 25601. Com este protocolo, uma terceira parte confiável (cliente) solicita o status de revogação de um certificado de um Servidor OCSP. O servidor pode usar LCRs, ou outros mecanismos para verificar o status do certificado e responder ao cliente.

Apenas uma CA que está autorizada a emitir LCRs pode optar por delegar essa autoridade à outra entidade. Se esta delegação é feita, deve ser verificável no momento da verificação do certificado/LCR. A extensão cRLDistributionPoints contida no certificado pode ser usada para esta finalidade. O campo cRLIssuer desta extensão seria preenchido com o nome(s) de quaisquer entidades, que não o emissor do certificado em si, que foram autorizadas a emitir LCRs sobre o status de revogação do certificado em questão.

Apenas uma CA que está autorizada a emitir LCRs pode optar por delegar essa autoridade à outra entidade. Se esta delegação é feita, deve ser verificável no momento da verificação do certificado/LCR. A extensão cRLDistributionPoints contida no certificado pode ser usada para esta finalidade. O campo cRLIssuer desta extensão seria preenchido com o nome(s) de quaisquer entidades, que não o emissor do certificado em si, que foram autorizadas a emitir LCRs sobre o status de revogação do certificado em questão.

Certificados, de chave pública como de atributos, terão um tempo de vida que lhes forem associados, expirando no termino do tempo. A fim de proporcionar a continuidade do serviço, a autoridade deve garantir um período de disponibilidade de certificados de substituição para substituir certificados expirados ou por expirar.

A validade dos certificados pode ser concebida de modo que cada um torna-se válido no momento do término do seu predecessor, ou uma sobreposição também pode ser permitida. Este último impede a autoridade de ter que instalar e distribuir um grande número de certificados que podem acabar na mesma data de vencimento.

Certificados expirados serão normalmente removidos do Diretório. É importante para a política de segurança e responsabilidade da autoridade manter os antigos certificados por um período, caso haja algum problema com o novo certificado.

Os certificados podem ser revogados antes de sua expiração, por exemplo, se a chave privada do usuário é assumida estar comprometida, ou o usuário não é mais certificado pela autoridade, ou se o certificado da autoridade é assumido como comprometido.

A revogação de um certificado de uma entidade final deve ser publicada e o sujeito deve ter conhecimento dessa revogação, se for o caso, um novo certificado deve ser disponibilizado. Uma autoridade que emite, e subsequentemente, revoga certificados:

• Pode ser necessária para manter um registro de auditoria de eventos de sua revogação para todos os tipos de certificado emitido pela autoridade (por exemplo, certificados de chave pública, certificados de atributo emitidos para entidades finais, bem como outras autoridades).
• Deverá fornecer informações sobre o status de revogação de um cliente usando LCRs, OCSP ou algum outro mecanismo para a publicação de informações sobre o estado de revogação.
• Se estiver usando LCRs, deve manter e publicar LCRs mesmo se as listas de certificados revogados são vazias.

 

Assinatura Digital || Infraestrutura de Chave Pública || Infraestrutura de Gerenciamento de Privilégios