Mecanismos de certificação e a criptografia

Os mecanismos de certificação são responsáveis em atestar a validade de um documento.

Certificação Digital

A Certificação Digital pode ser vista como um conjunto de técnicas, processos e normas estabelecidas ou adotadas, que visam propiciar mais segurança às comunicações e transações eletrônicas, proporcionando a autenticidade e integridade das informações que tramitam de forma eletrônica.

Logo, pode-se dizer que ela é necessária ou recomendada sempre que se deseje aumentar o nível de segurança nos serviços de autenticação de usuários, servidores, aplicações, pois garante as propriedades de confidencialidade, autenticidade, integridade e não repúdio.

A Certificação digital aplica os conceitos de criptografia e assinatura digital. A sua implantação depende do uso de certificados digitais, sendo que a validade e autenticidade dos certificados devem ser garantidas por uma infraestrutura de chaves públicas (ICP). (FEGHHI e WILLIAM, 1999).

Certificados Digitais

Os certificados de chave pública ou digitais, como são normalmente chamados, consistem em documentos eletrônicos no formato de arquivo, com um conjunto de informações que têm como objetivo associar o nome de uma entidade/pessoa com sua correspondente chave pública (FEGHHI e WILLIAM, 1999). Logo, pode- se dizer que um certificado digital é uma forma de credencial de segurança. Com funcionalidades semelhantes à de um certificado físico, ele inclui chave pública de uma pessoa, que possibilita a verificação por outros usuários se a mesma pertence, ou não, ao seu certificado. Os certificados digitais são usados para evitar as tentativas de substituição da chave pública de uma pessoa por outra. Um certificado digital é composto por três elementos:

1. a chave pública do dono do certificado;

2. as informações de identidade do usuário, como nome, ID do usuário, entre outros;

3. dados referentes à autoridade certificadora, como a assinatura digital desta, que tem como propósito declarar que a informação do certificado foi atestada por uma autoridade certificadora.

Vale a pena ressaltar que a assinatura digital não atesta a autenticidade do certificado como um todo; só atesta que a informação da identidade assinada está relacionada com sua chave pública.

Ao se falar de certificados, é importante você conhecer um número de diferentes certificados existentes, como:

• X.509 (certificado de chave pública) talvez o mais conhecido; • Certificados SPKI (Simple Public Key Infrastructure); • Certificados PGP (Pretty Good Privace); e, • Certificados de atributos.

Certificado X.509

Embora o X.509 defina certas necessidades associadas com os campos padrões e extensões de certificados, certo número de suas características ainda devem posteriormente ser abordadas, a fim de solucionar problemas referentes à interoperabilidade entre sistemas heterogêneos. Para tanto, o IETF (Internet Engineering Task Force) introduziu a RFC2459 (conhecida como PKIX – Public key infrastructure parte I), um grande número de recomendações úteis, que podem ser aplicadas não só à Internet, mas em ambientes empresariais, mantendo sempre a consistência enquanto possível. O certificado X509 possui os seguintes campos (RFC 2459, 1999):

Version: Indica a versão do certificado (presente tanto na versão 1, 2 ou 3).

Serial Number: Identificador único deste certificado em relação ao emissor de certificados;

Signature: Indica o identificador de algoritmo (isto é, o identificador do objeto mais algum parâmetro associado) usado para calcular a assinatura digital no certificado (Ex.: o objeto identificador do SHA-1 com o RSA pode estar presente, indicando que a assinatura digital é uma estrutura hash SHA-1 criptografada pelo RSA);

Issuer: É o DN (Distinguished Name – nome único) do emissor de certificados. Deve estar sempre presente;

Validity: período de tempo em que o certificado é válido. Este campoconsiste em datas/tempo que compreendem NÃO VÁLIDO ANTES E NÃO VÁLIDO APÓS;

Subject: É o DN do proprietário de certificado. Não fica em branco, a não ser que um nome alternativo seja usado (campo de extensão – Ex.: IP);

Subject Public Key Info: A chave pública (e o identificador do algoritmo) associada com o dono do certificado. Deve sempre estar presente;

Issuer Unique Identifier: Um identificador único, opcional, do emissor de certificados, presente somente nas versões 2 e 3. Este campo raramente é usado na prática;

Subject Unique Identifier: Um identificador único, opcional, do dono do certificado, presente somente nas versões 2 e 3. Este campo raramente é usado na prática;

Extensions: Padrões opcionais e extensões privadas, presentes somente na versão 3:

Authority Key Identifier: Identificador único da chave que poderia ser usada para verificar a assinatura digital calculada sobre o certificado. Usada para se distinguir entre múltiplas chaves que se aplicam ao mesmo emissor de certificados.

Subject Key Identifier: Identificador único associado com a chave pública contida nesse certificado. Utilizado para distinguir entre múltiplas chaves que se aplicam a um mesmo certificado.

Key Usage: Uma string de bits usada para identificar as funções ou serviços que podem ser suportados usando a chave pública nesse certificado. Pode ser usado para indicar suporte a assinatura digital, não repúdio, cifrar chaves, cifrar dados, concordância de chaves, etc.

Extended Key Usage: É a sequência de um ou mais identificadores de objetos (OIDs) que identificam uso específico da chave pública no certificado.

LRC Distribution Point: Indica a localização da partição da lista de revogação de certificados (LRC), onde residem as informações de revogação associadas com o certificado.

Private Key Usage Period: Indica a janela de tempo em que a chave privada associada à chave pública desse certificado pode ser usada. Direcionada para o uso com as chaves de assinatura digital/ certificados.

Certificates Police: Indica a sequência de uma ou mais políticas de identificação de objetos e qualificadores opcionais associados com a garantia e o uso subsequente do certificado.

Policy Mappings: Indica uma ou mais políticas de identificadores de objeto equivalentes entre duas ou mais ACs – Autoridade Certificadora.

Subject Alternative Name: Indica formas alternativas de nomes, associadas com o dono do certificado (por exemplo, endereço de e-mail, endereço IP, URL etc.). Essas formas alternativas de nome só são validas quando associadas ao DN (Distinguish Name do proprietário do certificado).

Issuer Alternative Name: Indica formas alternativas de nomes, associadas com o emissor do certificado, e especifica as mesmas regras de processamento associadas ao Subject Alternative Name.

Subject Directory Attributes: Indica a sequência de atributos associados com o proprietário do certificado. A não ser que esta extensão não esteja correntemente em uso, todas as aplicações conhecidas existem onde essa extensão é usada para fornecer controle de acesso à informações.

Distribuição do certificado

A distribuição de certificados pode ser realizada de algumas formas. No caso de grupos pequenos de usuários, o certificado pode ser trocado através de mídias como pen-drives ou e-mail contendo a chave pública de cada dono, conhecida como distribuição manual das chaves públicas. Entretanto os certificados também podem ser armazenados sob a forma de repositórios em sistemas estruturados quanto à sua administração, conhecidos como Infraestruturas de chaves públicas (ICPs).

Infraestruturas das chaves públicas (ICP)

Segundo Feghhi e Williams (1999), Adams e Steve (1999), Housley, Ford, Polk e Solo (1999) e Chokhani e Ford (1999), uma ICP pode ser definida como um conjunto de serviços de segurança (técnicas, práticas e procedimentos) que permitem o uso e a administração da criptografia de chave pública e certificados. Logo, fornece suporte à implementação e à operação de sistemas de certificação digital baseados em chave pública. A ICP tem como objetivo disponibilizar soluções para as necessidades de identificação automática, autenticação, controle de acesso e funções de autorização. Esses diversos serviços justificam os muitos atributos existentes no certificado, bem como a realização de um controle efetivo.

A figura 1 apresenta um modelo de arquitetura de ICP, com uma AC raiz, ACs intermediárias e suas respectivas ARs.

Modelo de ICP

Modelo de ICP

Componentes da arquitetura de uma ICP

a. AC (Autoridade certificadora)

As ACs são autoridades confiáveis para um segmento de negócio, que têm como função ligar o par de chaves públicas a uma identidade fornecida, isto é, elas certificam a identidade, associando, por meio de uma sinalização digital, uma estrutura que contém uma representação da identidade e uma chave pública (certificado digital).

A autoridade certificadora (AC) é responsável pelos aspectos referentes à emissão e gerenciamento de certificados digitais (revogação de certificados; renovação de certificados; publicação de certificados em diretórios; emissão da lista de revogação de certificados – LRC; gerência de chaves criptográficas).

b. Repositório de certificados

O usuário pode localizar os certificados de que necessita para realizar uma comunicação segura por meio de um local seguro, chamado repositório de interfaces, que deve estar disponível para atualização da LRC e de novos certificados.

c. Revogação de certificados

A autoridade certificadora assina um certificado associando um par de chaves públicas a uma identidade de usuário. Porém existem situações nas quais se torna necessária a quebra dessas associações. Por exemplo, uma troca de identidade, ou comprometimento de uma chave privada, a qual pode ter sido descoberta por um hacker.

A revogação de certificados é o mecanismo de alerta usado pela ICP para avisar o restante da população de usuários de que tal chave pública não se aplica mais àquela identidade. Todos os certificados possuem um tempo de vida e são revogados ao término desse tempo. Os certificados emitidos para serem utilizados uma única vez não se aplicam a uma ICP, pois causariam problemas de alto volume de tráfego.

d. Autoridade de registro

Apesar de a função de registro poder ser realizada diretamente pela AC, em algumas vezes é de bom costume que o registro seja realizado por uma entidade, chamada de Autoridade de Registro (AR). A AR normalmente estabelece e confirma a identidade do indivíduo como parte inicial do processo; distribui identificadores secretos para os usuários finais, a fim de possibilitar, posteriormente, a autenticação durante o processo de identificação on-line; inicia o processo de certificação com a AC; e realiza algumas funções de gerência, como iniciar a solicitação de revogação de certificados ou a operação de recuperação de chaves.

Obtenção de Certificado

A figura 2 apresenta um processo de geração de certificados por um usuário, onde o usuário conecta-se (normalmente utilizando um browser) ao site de uma certificadora digital, preenche um formulário on-line com os seus dados pessoais. Paralelamente, o browser envia a chave pública para a certificadora, mantendo-a privada, em segredo na máquina do usuário. O candidato ao certificado digital deverá comprovar sua identidade perante uma AR, que pode ser um cartório, departamento de RH, etc. Feito isto, a AC emitirá o certificado digital, e o usuário fará o seu download e instalação por meio do seu browser.

Processo de obtenção de certificados

Processo de obtenção de certificados

Mecanismos de criptografia

Segurança na camada IP – IPSEC

O IP Security Protocol (IPSEC) é um conjunto de protocolos de propósito geral com o objetivo de proteger as comunicações TCP/IP. Logo, protege, na prática, o tráfego entre máquinas, e não entre usuários em uma dada máquina. Ele é projetado para possibilitar privacidade, detecção de intrusos ou ambos em pacotes IP, conforme apresentado na figura 3.

Dinâmica do IPSec

Dinâmica do IPSec

Algumas questões devem ser levadas em consideração na utilização do IPSEC:

• a segurança deve ser independente do sistema e transparente para os provedores de serviço;

• a criptologia aplicada no pacote IP é realizada somente na parte que não é utilizada no roteamento do mesmo;

• a garantia de autenticação site a site.

O IPSEC possui três pilares básicos: privacidade, integridade e autenticidade. Com o uso do IPSEC, os dados podem ser transmitidos via redes públicas, sem riscos de observação, modificação ou spoofing: os únicos que conhecem a criptografia são as pontas. O protocolo pode ser usado para proteger um ou mais fluxos de dados entre um par de máquinas, ou entre um par de security gateways, ou, ainda, entre uma máquina e um security gateway.

O IPSEC é construído, utilizando uma série de padrões de criptografia:

• Diffie-Hellman – para a troca de chaves secretas;

• DES e Triple-DES – para a criptografia de dados;

• Protocolo HMAC (Hash-based Message Authentication Code) acoplado com MD5 ou SHA1 – para a autenticação de pacotes;

• Criptografia de chaves públicas – quando uma segurança maior é necessária para a criptografia de pacotes;

• Certificados digitais – validação de chaves públicas.

Arquitetura do IPSEC

Os componentes principais do IPSEC são o cabeçalho de autenticação (AH), o protocolo de segurança (ESP) e o gerenciamento de chaves. O projeto do AH e do ESP são modulares, o que possibilita o uso de novos algoritmos, à medida que forem surgindo. Para padronizar os parâmetros de uma associação segura (AS), o IPSEC utiliza o conceito de domínio de interpretação (DI), onde os algoritmos criptográficos, tamanho de chaves, formato de chaves, etc., são definidos quando no estabelecimento da AS.

O IPSEC define dois tipos de cabeçalhos opcionais, um para cada tipo de proteção. Ambos os cabeçalhos contêm um valor numérico chamado de security parameter index (SPI). Toda vez que uma máquina processa o cabeçalho do IPSEC, ele usa o SPI para identificar as chaves criptográficas e os procedimentos para utilizá-las. O pacote do IPSEC pode conter um cabeçalho ou dois, dependendo do tipo de serviço em que ele for empregado. Seguindo Smith (1997) e Kent (1995), essescabeçalhos são os seguintes:

Authentication header (AH) – possibilita a verificação da integridade do pacote (se foi alterado ou falsificado). Utiliza a técnica de cryptographic checksum – técnica que utiliza um algoritmo hash para criptografar parte do texto da mensagem. Ao chegar ao destino, é aplicada a mesma técnica para comparar ambos os textos e verificar se houve alguma alteração no conteúdo da mensagem. Caso o cheksum falhe, o pacote não está idêntico à origem.

Encapsulating Security Payload (ESP) – criptografa o restante dos dados do pacote IP. O formato do ESP varia de acordo com o tipo e o modo de criptografia utilizado. Em todos os casos, a chave associada é prescrita no SPI.

Quando duas máquinas desejam comunicar-se de forma segura utilizando o IPSEC, estabelece-se uma associação segura (AS) entre elas (como se fosse um contrato entre elas). A AS determina o que e como será a proteção a ser realizada pelo IPSEC, o que, por suas vez, compreende as respostas para as seguintes perguntas:

• Quais tipos de proteção serão aplicados? • Como será realizada a criptografia ou autenticação? • Quais chaves necessitam ser utilizadas?

A AS aplicada a um determinado cabeçalho IPSEC (AH ou ESP) é determinada pelo endereço de destino do pacote IP e do SPI dentro do pacote.

Importante
Cada fase de comunicação segura necessita de uma AS, uma para autenticação e outra para a criptografia, mesmo que os algoritmos sejam idênticos (chaves diferentes).

A desvantagem de uma AS é que a mesma só pode ser utilizada num único sentido, isto é, torna-se necessário o uso de duas AS para a transferência de dados de forma bidirecional. O software IPSEC deve manter a seguinte informação para cada SPI:

• especificação dos métodos de criptografia a serem utilizados pelo SPI;

• chaves a serem usadas pelos métodos de criptografia durante o tráfego das mensagens; e,

• máquinas ou entidades envolvidas no tráfego das mensagens. Quando uma máquina aplica a proteção IPSEC a um pacote que está saindo, ela usa a associação segura pertencente ao destino do pacote. A máquina aplica o método criptográfico da associação e a chave para criptografar os dados, e insere o SPI da associação no cabeçalho do IPSEC. Este processo é repetido, se o segundo cabeçalho IPSEC for aplicado.

Quando a máquina processa o primeiro cabeçalho do IPSEC num pacote que chega, o SPI é usado para identificar a associação de segurança correta. Logo, a máquina aplica o método de criptografia indicado pelo cabeçalho, junto com a sua chave. Desde que exista uma separação do AH e do ESP, o processo é repetido no próximo cabeçalho IPSEC, utilizando o SPI posicionado no local apropriado. Caso o SPI não exista ou o pacote for inválido após o seu processamento (foi alterado, por exemplo), ele é descartado.

Autenticação do IPSEC

O AH é um cabeçalho no pacote IP que contém o cryptographic checksum. Este cabeçalho é simplesmente inserido no interior do pacote, entre o cabeçalho do pacote IP e os dados que se seguem. Nenhuma mudança é necessária no conteúdo do pacote, a segurança está inteiramente posta no conteúdo do AH (SMITH, 1997 e KENT, 1995).

• Next header (8 bits) – Identifica o tipo e a localização do próximo cabeçalho;

• Payload Lenght (8 bits) – Comprimento do cabeçalho;

• Número sequencial (16 bits);

• SPI – qual grupo de protocolos está sendo utilizado;

• Dados de autenticação – obtidos via a Aplicação do algoritmo de criptografia.

O método cryptographic checksum é calculado sobre os dados do cabeçalho do pacote IP combinado com os cabeçalhos seguintes ao AH. Incluindo os dados do cabeçalho IP no cálculo, o AH pode detectar qualquer mudança na informação do endereçamento do pacote (todos os campos do cabeçalho IP que podem ser alterados durante o trânsito do pacote são marcados para 0).

• Por default, o AH faz uso do algoritmo hash MD5 com chave de 128 bits, produzindo um valor de hash de 128 bits.

• Pode também ser utilizado o algoritmo SHA1, produzindo um checksum de 160 bits.

A situação apresentada nos dois últimos parágrafos é bem reproduzida na figura a seguir.

Pacote com AH

Pacote com AH

ESP – Encapsulating Security Payload

O IPSEC ESP também define um novo cabeçalho a ser inserido no pacote IP, criptografando os dados do pacote. O ESP simplesmente contém o SPI para a associação segura da máquina de destino. (SMITH, 1997 e KENT, 1995).

Sobre circunstâncias normais, o ESP estará inserido no AH. A máquina que gera o pacote criptografará os dados, utilizando o procedimento, e a chave escolhida na associação e colocará o SPI no ESP. A autenticação é realizada sobre o conteúdo do pacote criptografado.

Todas as implementações IPSEC que suportam o ESP utilizam o DES no modo CBC (Cipher Block Chaining).

Modos de funcionamento

O IPSEC possui dois modos de funcionamento: o modo de transporte e o modo de túnel.

a. Modo de transporte

Somente a parte de dados é criptografada (alguns bytes são adicionados ao tamanho do pacote), assim o cabeçalho IP não é modificado.

Com o cabeçalho intacto, é permitido que atacantes conheçam a origem e o destino dos pacotes, mesmo que eles não possam determinar o conteúdo existente.

O AH ou o ESP (ou ambos) é inserido após o cabeçalho IP, e antes de qualquer outro cabeçalho.

Modo de transporte

Modo de transporte

b. Modo de túnel

A autenticação e criptografia são executadas em todo o pacote.

Pega-se o pacote IP original e criptografa-se por inteiro, colocando o resultado em outro datagrama IP.

Em seguida, é inserido um cabeçalho IPSEC, pode ser AH ou ESP. Depois, é criado um novo cabeçalho IP.

Este modo de operação é mais seguro, tendo em vista que a criptografia é aplicada em todo o pacote.

Modo túnel

Modo túnel

No modo túnel, a conexão é iniciada pelo servidor de acesso remoto, logo o cliente não precisa possuir o software IPSEC. A grande vantagem deste modo é que sistemas fim não precisam ser modificados para trabalharem com os benefícios de segurança IP. O modo túnel também protege os dados da análise de tráfego, e o atacante pode somente identificar os pontos finais do túnel, e não mais os endereços de origem e destino do pacote.

c. Modo combinado

Faz uso do modo túnel e transporte. Através desse modo:

• o IPSEC suporta a implementação combinada dos dois modos de operação;

• pode-se utilizar o modo túnel para autenticar ou criptografar o pacote e seu cabeçalho;

• posteriormente, aplica-se o AH e depois o ESP ou ambos.

SSL (Secure Socket Layer)/Transport Layer Security (TLS)

O SSL, normalmente utilizado com o http (https), é um protocolo de comunicação que implementa um túnel seguro para comunicação de aplicações na internet, de forma transparente e independente da plataforma de comunicação. Foi desenvolvido pela Netscape Communications junto com a RSA Data Security. Segundo Smith (1997), o SSL implementa as três capacidades (autenticação, criptografia e gerenciamento de chaves) de forma encapsulada, diferente do IPSec, que as implementa de forma separada.

O TLS v1 (ou SSL v3) possui várias melhorias em relação ao SSL v2. O TLS aceita conexões em três modos: servidor e cliente autenticados; só o servidor autenticado e nenhum dos dois autenticados.

Objetivos do SSL

O SSL tem como objetivos permitir a autenticação de servidores, criptografar dados, garantir a integridade de mensagens e, como opção, a autenticação do cliente, operando nas comunicações entre aplicativos de forma interoperável. (SMITH, 1997).

Ele garante:

• a segurança criptográfica para o estabelecimento de uma ligação segura entre duas máquinas/aplicativos, garantindo a privacidade na conexão, com a utilização de algoritmos simétricos (como o DES ou RC4) que negociam uma chave secreta na primeira fase do handshaking (usando chaves públicas – assimétricas);

• a autenticação do servidor (e, opcionalmente do Cliente) por meio de algoritmos assimétricos como o RSA ou o DSS;

• a confiabilidade na conexão, conseguida com o uso de códigos de autenticação de mensagens (MAC).

As suas implementações estão embutidas com aplicações que fazem uso do SSL para tramitar os seus dados de forma segura. Apesar de amplamente empregado em conexões HTTP, ele também pode ser utilizado com os protocolos SMTP e POP3. Observe a figura 7 que apresenta como o SSL atua em uma transação na Internet.

Atuação do SSL

Atuação do SSL

O protocolo SSL está posicionado na camada de aplicação, conforme apresentado na figura 6, onde recebe os dados provenientes da camada de aplicação, protege esses dados e os envia para a camada de transporte. A figura a seguir apresenta a estrutura do pacote proveniente da camada de aplicação a ser enviada pela pilha de protocolos.

Estrutura da camada de aplicação do SSL

Estrutura da camada de aplicação do SSL

A arquitetura do protocolo SSL é composta por dois protocolos. Veja-os em detalhe.

• O Record Protocol – é responsável pela transferência de dados, via utilização do conjunto de algoritmos, chaves, negociados em tempo de conexão, que serão utilizados para a autenticação e criptografia dos dados.

• O Handshaking Protocols – os protocolos de handshaking possuem três subprotocolos que permitem às partes chegarem a um acordo sobre os parâmetros de segurança que serão utilizados na camada de registro para: autenticação, comunicação (Protocolo de handshake); sinalizar mudanças nas estratégias de criptografia que estavam sendo utilizadas (Protocolo Change Cipher Spec); e reportar condições de erro entre as partes (Protocolo de Alerta).

Arquitetura do SSL

Arquitetura do SSL

Referências

CELEPAR INFORMÁTICA DO PARANÁ. Tutorial Básico sobre certificação digital. Disponível em: <http://www.frameworkpinhao.pr.gov.br>. Acesso em: 2000.

KENT S. Security architecture for the internet protocol, IETF RFC2401. ……1995. SMITH, Richard E. Internet cryptography. Local: ? Ed. Addison Wesley, 1997.

FEGHHI, J e WILLIAMS. P. digital certificates: applied internet security. Reading. MA, Ed.Addison Wesley, 1999.

Housley, Ford, Polk e Solo (1999)???

ADAMS, Carlisle e LOYD, Steve. Understanding public-key infraestrucuture: concepts, standards, and deployment considerations. Indianapolis: Macmillan, 1999.

S. Chokhani, W. Ford, R. Sabett, C. Merrill, and S. Wu. Internet X.509 Public Key Infrastructure Certi ?cate Policy and Certi ?cation Practices Framework. RFC 3647 (Informational), November 2003.

Autor: Ms. Luiz Otávio Botelho Lento

 

One Response to “Mecanismos de certificação e a criptografia”

Deixe um comentário

O seu endereço de e-mail não será publicado.