Índice

Índice

1. SSL(Secure Sockets Protocol)

1.1. Introdução

1.2. Objetivos

1.2.1. Segurança Criptográfica

1.2.2. Interoperabilidade

1.2.3. Extensibilidade

1.2.4. Relativa Eficiência

1.3. O Protocolo SSL

1.3.1. Estados de Sessão e Conexão

1.4. Protocolo SSL Record

1.5. Protocolo Handshake

1.6. Usando SSL

2. Kerberos

2.1. Motivação

2.2. Kerberos Versão 4

2.2.1. Um simples diálogo de autenticação

2.2.2. Um diálogo de autenticação mais seguro

2.2.3. Diálogo de autenticação Versão 4

2.2.4. Examinando estes problemas.

2.2.5. Realms Kerberos e Múltiplos Kerberi

2.3. Kerberos Versão 5

2.4. Diferenças entre versão 4 e versão 5

2.4.1. Diálogo de autenticação Versão 5

2.4.2. Flags nos tickets

3. Segurança no Correio Eletrônico

3.1. Pretty Good Privacy (PGP)

3.1.1. Autenticação

3.1.2. Confidencialidade

3.1.3. Confidencialidade e Autenticação

3.1.4. Compressão

3.1.5. Compatibilidade de E-Mail

3.1.6. Segmentação e Remontagem

3.1.7. Sumário dos serviços do PGP

3.1.8. Chaves de Criptografia usadas pelo PGP

4. Bibliografia

SSL(Secure Sockets Protocol)

Introdução

O Objetivo Principal do protocolo SSL é prover privacidade e confiabilidade na comunicação entre aplicações.

O protocolo é composto de dois níveis. No nível mais baixo localizado acima de algum protocolo confiável , está o SSL Record Protocol. O SSLRecord Protocol é usado para encapsular os vários protocolos de nível mais alto. Um dos protocolos encapsulados, o SSL Handshake Protocol, permite que o servidor e cliente se autentiquem e negociem um algoritmo de criptografia e chaves criptografadas antes que o protocolo de aplicação mande ou receba seu primeiro byte de dado.

Uma vantagem do SSL é que ele é independente de protocolos de aplicação. Um protocolo de mais alto nível pode estar sobre o protocolo SSL transparentemente.

O protocolo SSL provê segurança de conexão que possui três propriedades básicas:

- A conexão é privada. Criptografia é usada depois de um inicial "handshake" onde é definida uma chave secreta. Criptografia simétrica é usada para criptografia de dados, ex.: DES.

- A identidade do processo par de comunicação pode ser autenticado usando criptografia assimétrica ou criptografia para chaves públicas(RSA, DSS)

- A conexão é confiável. Transporte de mensagens incluem uma checagem de integridade da mensagem usando MAC com chave. Funções de hash seguro, por exemplo, SHA, MD5, são usadas para computações MAC.

Objetivos

Os objetivos do protocolo SSL em ordem de prioridade são:

Segurança Criptográfica

SSL pode ser usada para estabelecer uma conexão segura entre duas partes.

Interoperabilidade

Programadores independentes estão capacitados a desenvolverem aplicações utilizando SSL 3.0, que poderão trocar parâmetros de criptografia com sucesso, sem conhecimento do código do outro.

OBS.: Não é o caso que, todas as instâncias de SSL(inclusive na mesma aplicação) estarão aptas a se conectarem . Por exemplo, se o servidor suporta um token de hardware e o cliente não tem acesso àquele token, então a conexão não irá ter sucesso.

Extensibilidade

SSL procura provê um patamar em que novas chaves públicas e métodos de criptografia de bulk possam ser incorporados quando necessário. Isso irá atingir também dois sub-objetivos: evitar a necessidade de criar um novo protocolo(e possibilitando a inserção de um novo problema), e para evitar a necessidade de implementar uma nova biblioteca de segurança completa.

Relativa Eficiência

Operações de Criptografia tendem a ser de intensiva carga de CPU, particularmente operações de chaves públicas. Por essa razão, o protocoloSSL tem incorporado um esquema de cache de sessão otimizado para reduzir o número de conexões que devem ser estabelecidas. Adicional cuidado é dado para reduzir a atividade da rede.

O Protocolo SSL

SSL é um protocolo nivelado. Em cada nível, mensagens podem incluir campos para tamanho, descrição e conteúdo. SSL recebe as mensagens a serem transmitidas, fragmenta os dados em blocos gerenciáveis, opcionalmente comprime os dados, aplica um MAC, criptografa, e transmite o resultado.

Dados recebidos são decriptografados, verificados, descomprimidos, e reajuntados, depois são entregues para os clientes de nível mais alto.

Estados de Sessão e Conexão

Uma sessão SSL é "Stateful". É de responsabilidade do protocolo Handshake coordenar os estados do cliente e servidor, permitindo a máquina de estados de cada protocolo operarem consistentemente, considerando o fato de que o estado não é exatamente paralelo.

Logicamente o estado é representado duas vezes, uma como o corrente estado de operação, e (durante o protocolo handshake) novamente como o estado pendente. Adicionalmente, estados de leituras e escritas separados são mantidos. Quando um cliente ou servidor recebe uma mensagem para mudar o cipher spec* , ele copia o estado da leitura pendente no corrente estado de leitura. Quando o cliente ou servidor manda uma mensagem para mudar o cipher spec, ele copia o estado da escrita pendente no corrente estado de escrita.

Quando a negociação Handshake está completa, cliente e servidor trocam mensagens para mudar o cipher spec, e então eles se comunicam usando a nova, recentemente acertada, cipher spec.

Uma sessão SSL pode incluir múltiplas conexões seguras; além disso, cada parte pode ter múltiplas sessões simultâneas.

O estado da sessão pode incluir os seguintes elementos: id da sessão, certificado do processo par, método de compressão, cipher spec, master secret, e um flag dizendo se a sessão pode ser usada para iniciar novas conexões.

- id da conexão: Uma arbitrária seqüência de bytes escolhida pelo servidor para identificar um estado de sessão ativa ou que irá começar.

- Método de Compressão: O algoritmo usado para comprimir dados prioritários para depois serem criptografados.

- Cipher Spec: especifica o algoritmo de criptografia dos dados, tal como null, DES, e um algoritmo MAC como, MD5 ou SHA. Ele também define atributos de criptografia tal como o hash_size.

O estado da conexão inclui os seguintes elementos: número randômico do servidor e do cliente, o segredo usado em operações MAC de escritas pelo servidor, o segredo de operações MAC de escrita pelo cliente, chave de escrita do servidor, chave de escrita do cliente, vetores de inicialização e números de seqüência.

Protocolo SSL Record

O nível SSL Record recebe dados não interpretados de níveis mais altos em blocos não vazios de tamanho arbitrário.

· Fragmentação

O nível Record fragmenta blocos de informações em registros SSLPlaintext de 2^14 bytes ou menos. Limites no tamanho da mensagem do cliente não é preservado no nível record, isto é múltiplas mensagens de clientes, do mesmo tipo, podem ser juntadas em um único registro SSLPlaintext.

· Compressão e De-Crompressão

Todos registros são comprimidos usando o algoritmo de compressão definido no estado da sessão corrente. Existe sempre um algoritmo de compressão ativo, entretanto inicialmente ele é definido como CompressionMethod.null.

O algoritmo de compressão traduz um estrutura SSLPlainText em uma estrutura SSLcomprimida. Funções de compressão apagam sua informação de estado sempre que o Cipher Spec é substituído.

OBS.: O Cipher Spec é parte do estado da sessão descrito acima.

· Proteção payload do Registro e o CipherSpec

Todos registros são protegidos usando a criptografia e algoritmos MAC definidos no CipherSpec corrente. Existe sempre um Cipher Spec ativo, entretanto inicialmente ele é definido como SSL_NULL_WITH_NULL_NULL, que não oferece nenhuma segurança.

Uma vez que o handshake está completo, as duas partes tem segredos compartilhados que são usados para criptografar registros e computar códigos de autenticação de mensagens chaveadas (MACs) em seu conteúdo.

Protocolo Handshake

Os parâmetros de criptografia do estado da sessão são produzidos pelo SSL Handshake Protocol, que opera no topo no nível de Record. Quando um cliente e servidor iniciam a comunicação ele concordam em uma versão de protocolo, selecionam algoritmos de criptografia, opcionalmente se autenticam, e usam técnicas de criptografia de chaves públicas para gerarem chaves secretas.

Esses processos são feitos pelo protocolo handshake, que pode ser sumarizado por: o cliente manda uma mensagem hello para a qual o servidor deve responder com também uma mensagem hello. O hello cliente e servidor estabelece os seguintes atributos: versão de protocolo, id da sessão, cipher suite, e método de compressão. Adicionalmente dois valores randômicos são gerados e trocados: ClientHello.random e ServerHello.random.

Seguindo as mensagens hello, o servidor irá mandar certificados se ele deve ser autenticado. Se o servidor é autenticado ele pode pedir um certificado do cliente, se isso é apropriado para o cipher suite selecionado. Agora o servidor irá mandar a mensagem de conclusão do server hello. O servidor irá esperar por uma reposta do cliente. Se o servidor tiver mandado uma mensagem de pedido de certificado, o cliente deve mandar a mensagem de certificado ou uma alerta de não certificado.

A mensagem de troca de chaves é então enviada e o conteúdo da mensagem irá depender do algoritmo de chave pública selecionado entre o client hello e server hello. Neste ponto uma mensagem de muda cipher spec é enviado pelo cliente, e o cliente copia o cipher spec pendente no corrente cipher spec.

O cliente então imediatamente manda a mensagem de fim através de novos algoritmos, chaves e segredos. Em resposta, o servidor irá mandar seu própria mensagem de change cipher spec, transferir o pendente para o corrente cipher spec, e mandar sua mensagem de finalização sobre a nova cipher spec.

Neste ponto o hanshake está completo e o cliente e servidor podem começar a trocar dados a nível de aplicação. A figura abaixo ilustrará este processo.

Cliente Servidor

Client Hello ------------------>

Server Hello

Certificate*

ServerKeyExchange*

CertificateRequest*

Server Hello Done

<------------------

Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished ------------------->

[ChangeCipherSpec]

Finished

<-------------------

Application Data <------------------> Application Data

OBS.: * indica mensagens opcionais ou dependentes da situação, que nem sempre são enviadas.

Usando SSL

Uma das questões mais perguntadas por pessoas novas ao SSL é : "Como eu posso usar SSL para mandar números de cartão de crédito de forma segura? " A resposta é direta, você precisa de um web browser que é usa criptografia.

Como o protocolo foi desenvolvido pela Netscape, SSL foi primeiramente popularizado pelo web browser e web server da Netsacape, desde então muitos outros web browsers e web servers incorporaram o SSL. Hoje SSL é um dos mais populares protocolos de criptografias na Internet.

Um objetivo do SSL é esconder a complexidade da criptografia de usuários e desenvolvedores. Se o usuário está usando um web browser capaz de usar SSL, ele pode instruir o browser a criar uma conexão criptografada para seu servidor apenas substituindo o "http" nas suas URLs por "https".

Da mesma forma se você tem um form CGI que permite pessoas a submeter informações sensitivas, tal como números de cartões de crédito, você poderá forçar a informação ser submetida criptograficamente simplesmente modificando a cláusula action= no arquivo html, novamente mudando o "http" por "https".

Por exemplo, se o tag <form> no arquivo html é da forma:

<form method=POST action="http://w.di.ufpe.br/cgi-bin/enter"> , mude-o para:

<form method=POST action="https://w.di.ufpe.br/cgi-bin/enter">.

Kerberos

É um serviço de autenticação desenvolvido como parte do projeto ATHENA no MIT. O problema que é objetivo para Kerberos resolver é: Assumindo um ambiente distribuído aberto em que usuários de workstations desejam acessar serviços em servidores distribuídos através da rede. Nós desejamos que servidores sejam capazes de restringir acesso a usuários autorizados e sejam capazes de autenticar pedidos para serviços. Neste ambiente uma workstation não pode estar confiante que identifica seus usuários corretamente para serviços de rede. Em particular, as seguintes ameaças existem:

Um usuário pode ganhar acesso para uma workstation particular e pretender ser um outro usuário operando desta workstation

Um usuário pode alterar um endereço de rede de uma workstation, de forma que pedidos enviados da workstation alterada chegarão na workstation personificada

Em qualquer destes casos, um usuário não autorizado pode ser capaz de ganhar acesso a serviços e dados que ele não tem autorização para acessar.

Ao contrário de protocolos de autenticação construídos de maneira elaborada para cada servidor, Kerberos oferece um serviço de autenticação centralizado cuja função é autenticar usuários para servidores e servidores para usuários. Kerberos conta exclusivamente com criptografia convencional, sem fazer uso de criptografia de chave pública.

Duas versões estão em uso. Versão 4, mais usada. Versão 5, que corrige algumas falhas de segurança da Versão 4 e tem sido utilizada como um DRAFT INTERNET STANDARD.

Motivação

Se um conjunto de usuários utiliza computadores pessoais que não possui conexões de rede, então os recursos de usuários e arquivos podem ser protegidos fisicamente cada um. Quando ao invés disto os usuários são servidos por um sistema centralizado de time-sharing, o sistema operacional time-sharing deve oferecer segurança. O sistema operacional pode utilizar políticas de controle de acesso baseadas na identificação do usuário e utilizar o procedimento de logon para identificá-los.

Atualmente, nenhum destes cenários é típico. Mais comum é uma arquitetura distribuída que possui workstations dedicadas (clientes) e servidores distribuídos ou centralizados. Nesta ambiente, três abordagens para segurança podem ser consideradas:

Contar com cada workstation cliente individual para garantir a identidade e seus usuários e contar com cada servidor para utilizar políticas baseadas na identificação do usuário(ID)

Pedir que os próprios sistemas clientes se autentiquem para servidores, mas confiar que o sistema cliente fará a identificação do usuário

Pedir para o usuário informar a identificação para cada serviço invocado. Também pedir que servidores provem suas identidades aos clientes

Em ambientes pequenos, fechados em que os sistemas operam por uma simples organização, a primeira ou a segunda estratégia pode ser suficiente. Mas em um sistema mais aberto, em que são suportadas conexões de rede para outras máquinas, a terceira abordagem é necessária para proteger informações e recursos de usuários residentes no servidor. Esta terceira abordagem é suportada por Kerberos. Kerberos assume uma arquitetura distribuída cliente/servidor e coloca um ou mais servidores Kerberos para oferecer serviço de autenticação.

Alguns requisitos para Kerberos são:

Segurança: um invasor de rede não deve ser capaz de obter as informações necessárias para se passar por um outro usuário. De forma mais geral, Kerberos deve ser robusto o suficiente para que um oponente não consiga invadir a rede.

Confiabilidade: todos os serviços confiam em Kerberos para controle de acesso. Assim Kerberos deve ser altamente confiável e deve utilizar uma arquitetura de servidor distribuída, com um sistema capaz de fazer backup do outro.

Transparência: o ideal é que o usuário não perceba onde está sendo feita a autenticação quando é pedido para entrar com a password.

Escalonável: O sistema deve ser capaz de suportar grande número de servidores e clientes. Novamente, isto sugere uma modular, arquitetura distribuída.

Kerberos Versão 4

Versão 4 de Kerberos utiliza DES para oferecer o serviço de autenticação.

Um simples diálogo de autenticação

Em um ambiente de rede desprotegido, qualquer cliente pode requisitar serviço de qualquer servidor. O risco óbvio de segurança é o de um usuário se passar por outro. Um oponente pode pretender ser um outro cliente e obter privilégios não autorizados em máquinas servidoras. Para ir de encontro a esta ameaça, servidores devem ser capazes de confirmar a identidade de seus clientes quando o serviço é requisitado.

Uma alternativa é utilizar um servidor de autenticação (AS - Authentication Server) que conhece as senhas de todos os usuários e armazena elas em uma base de dados centralizada. Além disso, o AS compartilha uma chave única secreta com cada servidor. Estas chaves tem sido distribuídas fisicamente ou de qualquer outra maneira mais segura. Agora consideraremos o seguinte diálogo hipotético:

1. C -> AS: IDc, Pc, IDv

2. AS -> C: Ticket

3. C -> V: IDc, Ticket

Ticket = Ek [IDc, ADc, IDv ]

onde:

C = cliente

` AS = servidor de autenticação

V = servidor

IDc = identificador do usuário em C

IDv = identificador de V

Pc = password de C

ADc = endereço de rede de C

Kv = chave de criptografia secreta compartilhada por AS e V

Neste cenário, o usuário loga em uma workstation e requisita acesso para o servidor V. O módulo cliente C na workstation do usuário requisita a password do usuário e então envia uma mensagem para o AS que inclui o ID do usuário, o ID do servidor e a password do usuário. O AS verifica em sua base de dados se o usuário forneceu a password apropriada para seu ID e checa para ver se ele é autorizado a utilizar o servidor V. Se ambos testes passam, o AS aceita o usuário como autenticado e deve agora convencer o servidor de que o usuário é autenticado. Para fazer isso, o AS cria um ticket que contem o ID e o endereço de rede do usuário e o ID do servidor. Este ticket é criptografado utilizando a chave secreta compartilhada por AS e este servidor. O ticket é então enviado para C. Devido ao fato do ticket ser criptografado ele não pode ser alterado por seu ou por seu oponente.

Com este ticket, C pode agora pedir o serviço a V. C envia uma mensagem para V contendo o ID de C e o ticket. V decriptografa o ticket e verifica se o ID de usuário do ticket é o mesmo da mensagem. Se isto acontece, o servidor considera o usuário autenticado e presta o serviço requisitado.

Cada um dos ingredientes da mensagem 3 (IDc, Ticket), são significantes. O ticket é criptografado para prevenir alteração. O ID do servidor é incluído no ticket para que o servidor possa verificar que decriptografou o ticket apropriadamente. IDc é incluído no ticket para indicar que o ticket tem sido cedido para C. Finalmente, ADc serve para ir de encontro a seguinte ameaça. Um oponente pode capturar o ticket transmitido na mensagem 2, então usa o mesmo IDc e transmite a mensagem 3 de uma outra workstation. O servidor receberá um ticket válido que casa o ID do usuário e dá acesso ao usuário em uma outra workstation. Para prevenir este ataque, o AS inclui no ticket o endereço de rede de onde foi originado o pedido. Agora o ticket é válido apenas se ele é transmitido da mesma workstation que requisitou o ticket inicialmente.

Um diálogo de autenticação mais seguro

Embora o cenário anterior resolve alguns dos problemas de autenticação em um ambiente de rede aberto, problemas ainda existem. Entre eles dois em particular. Primeiro, nós gostaríamos de minimizar o número de vezes que o usuário tem que entrar com a password. Suponha que cada ticket pode ser usado apenas uma vez. Se usuário C loga em uma workstation pela manhã e deseja verificar suas mail em um servidor de mail, C deverá entrar com a password para pegar um ticket para o servidor de mail. Se C deseja verificar suas mail várias vezes durante o dia, cada tentativa precisa que a password seja entrada novamente. Nós podemos melhorar isso se considerarmos que tickets são reusáveis. Para uma simples sessão de logon, a workstation pode armazenar o ticket do servidor de mail e utilizá-lo para vários acessos para o servidor de mail.

Neste esquema, temos ainda o caso que o usuário precisará de um novo ticket para todo serviço diferente. Se um usuário quiser acessar um servidor de impressão, um servidor de mail e um servidor de arquivo ao mesmo tempo, a primeira instância de cada acesso requer um novo ticket e assim precisa que o usuário entre com a password.

O segundo problema é que o cenário anterior envolve uma transmissão plaintext da password. Um invasor pode capturar a mensagem e usar qualquer serviço acessível a vítima.

Para resolver estes problemas adicionais, foi introduzido um esquema para evitar password plaintext e um novo servidor, conhecido como servidor ticket-granting (TGS). O novo mas ainda hipotético cenário é como segue:

uma vez por sessão de logon de usuário

C -> AS : ID_c, ID_Tgs

AS -> C : E_kc[Tickert_Tgs]

uma vez por tipo de serviço

C -> TGS : ID_c, ID_v, Ticket_Tgs

TGS -> C : Ticket_v

uma vez por sessão de serviço

C -> V : ID_c, Ticket_v

Ticket_tgs= E_ktgs[ID_c,ADc,ID_tgs,TS₁,Lifetime₁]

Ticket_v = E_kv [ID_c, AD_c, ID_v,TS_2,Lifetime₂]

O novo serviço, TGS, dá tickets para usuários que tenham sido autenticados pelo AS. Assim, o usuário primeiro requisita um ticket ticket-granting (Ticket tgs) de AS. Este ticket é salvo pelo módulo cliente na workstation do usuário. Cada vez que o usuário requer acesso para um novo serviço, o cliente aplica para o TGS, usando o ticket para autenticá-lo. O TGS então dá um ticket para o serviço particular. O cliente salva cada ticket service-granting e usa-o para autenticar seu usuário para um servidor cada vez que um serviço particular é requisitado. Agora, veremos detalhes deste esquema:

O cliente requisita um ticket ticket-granting por parte do usuário enviando o ID do usuário para o AS, junto com o TGS ID, indicando um request para usar o serviço TGS.

O AS responde com um ticket que é criptografado com uma chave que é derivada da password do usuário. Quando esta resposta chega ao cliente, o cliente pede ao usuário para entrar com sua password, gera a chave, e tenta decriptografar a mensagem que chegou. Se a password correta é fornecida, o ticket é recuperado com sucesso.

Como apenas o usuário correto deve conhecer a password, apenas o usuário correto pode recuperar o ticket. Assim, foi utilizado a password para obter credenciais Kerberos sem ter que transmitir a password plaintext. O ticket inclui o ID e endereço de rede do usuário, e o ID d TGS. Isto corresponde ao primeiro cenário. Agora, a idéia é que este ticket pode ser usado pelo cliente para requisitar múltiplos tickets service-granting. Assim o ticket ticket-granting é para ser reusável. Entretanto, nós não queremos que um oponente seja capaz de capturar o ticket e usá-lo. Considere o seguinte cenário: Um oponente captura o ticket e espera até que o usuário log off da workstation. Então o oponente ou ganha acesso para esta workstation ou configura sua workstation com o mesmo endereço de rede da vítima. Para ir de encontro a isto, o ticket inclui um timestamp, indicando a data e a hora que o ticket foi dado, e um tempo de vida, indicando o tempo que este ticket é válido. Assim, agora o cliente tem um ticket reusável e não precisa que o usuário entre com a password para cada novo serviço requisitado. Finalmente, note que o ticket ticket-granting é criptografado com uma chave secreta conhecida apenas pelo AS e pelo TGS. Isto previne alteração do ticket. O ticket é recriptografado com uma chave baseada na password do usuário. Isso garante que o ticket pode ser recuperado apenas pelo usuário correto dando a autenticação.

Agora que o cliente tem um ticket ticket-granting, acesso a qualquer servidor pode ser obtido com os seguintes passos:

3. O cliente pede um ticket service-granting por parte do usuário. Para isto, o cliente transmite uma mensagem para o TGS contendo o ID do usuário, o ID do serviço desejado, e o ticket ticket-granting.

4. O TGS decriptografa o ticket que chega e verifica o sucesso da decriptografia pela presença de seu ID. Ele checa para estar certo de que o tempo de vida não expirou. Então ele compara o ID do usuário e o endereço de rede com a informação que chega para do usuário autenticado. Finalmente, ele dá um ticket para dar acesso ao serviço requisitado.

O ticket service-granting tem a mesma estrutura que o ticket ticket-granting. Devido ao fato de TGS ser um servidor, nós esperamos que os mesmos elementos sejam necessários para autenticar um cliente para o TGS e para autenticar um cliente para um servidor de aplicação. Novamente. O ticket contém um timestamp e um tempo de vida. Se o usuário quiser acessar o mesmo serviço mais tarde, o cliente pode simplesmente usar o ticket service-granting obtido anteriormente, não sendo necessário que o usuário entre com a senha novamente. Note que o ticket é criptografado com uma chave secreta conhecida apenas pelo TGS e pelo servidor, prevenindo alteração.

Finalmente, com um ticket service-granting, o cliente pode dar acesso ao serviço correspondente com passo 5:

5. O cliente requisita acesso para um serviço por parte do usuário. Para isto, o cliente transmite uma mensagem para o servidor contendo o ID do usuário o ticket service-granting. O servidor autentica utilizando o conteúdo do ticket.

Este cenário satisfaz os dois requisitos, de apenas uma consulta para password por sessão de usuário e proteção da password.

Diálogo de autenticação Versão 4

Embora o último cenário obtém segurança comparado a primeira tentativa, restam dois problemas adicionais. O primeiro problema é o tempo de vida associado com o ticket ticket-granting. Se o tempo de vida é curto então o usuário será perguntado repetidamente por sua password. Se o tempo de vida é longo é uma grande oportunidade para um oponente dar um replay, ou seja, ele pode invadir a rede, capturar uma cópia do ticket ticket-granting e então esperar que o verdadeiro usuário dê o logout. Então, forja o endereço de rede do verdadeiro usuário e replay a mensagem. Isto dá ao oponente acesso ilimitado aos recursos e arquivos disponíveis para o verdadeiro usuário.

O mesmo acontece se o ticket capturado for um service-granting e ele usá-lo antes do tempo expirar. Desta forma, ele terá acesso ao serviço correspondente.

Assim, é preciso ter um requisito a mais a ser cumprido. Um serviço de rede (TGS ou serviço de aplicação) deve ser capaz de provar que a pessoa usando um ticket é a mesma pessoa para quem o ticket foi cedido.

O segundo problema é que o servidor deve ser capaz de autenticar a si mesmo, pois é possível que uma outra máquina pode interceptar a mensagem e enviar para um servidor falso e assim ele começar a negar serviços aos usuários.

Examinando estes problemas.

Primeiro, consideramos o problema de capturar tickets ticket-granting e a necessidade de determinar que o apresentador do ticket é o mesmo que pediu o ticket. A ameaça é que o oponente pode pegar o ticket e usa-o antes de expirar. Para resolver este problema, o AS dará a ambos cliente e TGS uma porção secreta de informação de maneira segura. Então o cliente pode provar sua identidade para o TGS revelando a informação secreta novamente de maneira segura. Uma maneira eficiente de conseguir isso é utilizando uma chave de criptografia como a informação segura; esta é referenciada como chave de sessão em Kerberos.

Abaixo será mostrada uma tabela que traz o protocolo Kerberos e mostra as técnicas para distribuição da chave de sessão.

(a) Comunicação do serviço de autenticação

(1) C -> AS: ID_C || ID_TGS || TS₁ (cliente requisita ticket ticket-granting)

ID_C : diz a AS a identidade do usuário deste cliente

ID_TGS: diz a AS que o usuário requisita acesso para TGS

TS₁: permite que AS verifique se o clock do cliente está sincronizado com o seu

(2) AS -> C: E_KC [ K_C,TGS || ID_TGS|| TS₂ || Tempo de vida₂ || Ticket_TGS] (AS retorna o ticket)

E_KC: criptografia é baseada na password do usuário, possibilitando AS e cliente verificar password, e proteger o conteúdo da mensagem 2

K_C,TGS: cópia da chave de sessão acessível ao cliente; criada por AS para permitir comunicação segura entre cliente e TGS sem precisar que eles compartilhem uma chave permanente.

ID_TGS: confirma que o ticket é para o TGS

TS₂ : informa ao cliente o tempo que este ticket foi liberado

Tempo de vida₂ : informa ao cliente do tempo de vida deste ticket

Ticket_TGS: ticket utilizado pelo cliente para acessar TGS

Ticket_{TGS =}E_KC [ K_C,TGS || ID_C|| AD_C|| ID_TGS|| TS₂ || Tempo de vida₂]

Como antes, o cliente envia uma mensagem para o AS requisitando acesso para o TGS (1). O AS responde com uma mensagem, criptografada com uma chave derivada da password do usuário (K_C), esta mensagem contém o ticket. Além disso, contém uma cópia da chave de sessão, K_C,TGS. Como esta chave de sessão esta dentro da mensagem criptografada com K_C, apenas o cliente do usuário pode ler. A mesma chave de sessão é incluída no ticket, o qual pode ser lido apenas pelo TGS. Assim, a chave de sessão tem sido liberada de maneira segura para o cliente e para o TGS. A mensagem (1) inclui alguns campos adicionais entre eles temos o tempo de vida.

Agora com a chave de sessão e o ticket, C está apto para abordar TGS.

(b) Comunicação do serviço Ticket-Granting

(3) C -> TGS: IDv || Ticket_TGS || Autenticador_C (cliente requisita ticket service-granting)

IDv : diz ao TGS qual o usuário que requisita acesso para o servidor V

Ticket_TGS : garante ao TGS que este usuário foi autenticado por AS

Autenticador_C: gerado pelo cliente para validar o ticket

(4) TGS -> C: E_KC,TGS [ K_C,V || ID_V|| TS₄ || Ticket_V] (TGS retorna ticket service-granting)

E_KC,TGS : chave compartilhada apenas por C e TGS; protege o conteúdo da mensagem

K_C,V : cópia da chave de sessão acessível ao cliente; criada por TGS para permitir comunicação segura entre cliente e servidor sem precisar que eles compartilhem uma chave permanente

ID_V: confirma que o ticket é para o servidor V

TS₄ : informa ao cliente o tempo que este ticket foi criado

Ticket_V: ticket para ser usado pelo cliente para acessar servidor V

Ticket_{TGS =}E_KTGS [ K_C,TGS || ID_C|| AD_C|| ID_TGS|| TS₂ || Tempo de vida₂] (ticket reusável)

E_KTGS : ticket é criptografado com chave conhecida apenas por AS e TGS

K_C,TGS : cópia da chave de sessão acessível para TGS; usado para decriptografar autenticador

ID_C: indica o dono do ticket

AD_C: previne o uso do ticket por uma workstation diferente da que solicitou o ticket

ID_TGS: garante ao servidor que ele decriptografou o ticket corretamente

TS₂ : informa ao TGS o tempo que este ticket foi criado

Tempo de vida₂: previne replay depois que o ticket expirou

Ticket_{V =}E_KV [ K_C,V|| ID_C|| AD_C|| ID_V|| TS₄ || Tempo de vida₄]

Autenticador_C= E _KC,TGS [ID_C|| AD_C|| TS₃] garante ao TGS que o apresentador do ticket é o mesmo que solicitou, tem curto tempo de vida para prevenir replay

E _KC,TGS : autenticador é criptografado com chave conhecida apenas pelo cliente e TGS

ID_C: deve ser igual ao ID no ticket autenticado

AD_C: deve ser igual ao endereço no ticket autenticado

TS₃: informa ao TGS do tempo que este autenticador foi gerado

Como antes, C envia uma mensagem para o TGS que inclui o ticket e o ID do serviço desejado (3). Além disso, C transmite um autenticador, o qual inclui o ID e o endereço do usuário C e um timestamp. Diferente do ticket que é reusável o autenticador é para ser usado uma única vez e tem um período curto de vida. Agora, o TGS pode decriptografar o ticket com a chave que ele compartilha com o AS. O TGS pode então verificar o nome e endereço do autenticador do ticket com o da mensagem que chegou. Se tudo correr bem, então o TGS está certo de que o enviador é o dono realmente. É importante notar que o ticket não prova qualquer identidade mas é uma maneira segura de distribuir chaves seguramente. É o autenticador que prova a identidade do cliente. Como o autenticador só pode ser utilizado apenas uma vez e tem o tempo de vida curto, a ameaça de um oponente pegar ambos o ticket e o autenticador para apresentar depois é combatida.

O reply do TGS (4), segue a forma da mensagem (2). A mensagem é criptografada com a chave compartilhada entre TGS e C e inclui uma chave de sessão para ser compartilhada entre C e o servidor V, o ID de V, e o timestamp do ticket. O ticket também inclui a chave de sessão.

C agora possui um ticket service-granting reusável para V.

(c) Comunicação da autenticação cliente/servidor

(5) C -> V: Ticket_V|| Autenticador_C (cliente requisita serviço)

Ticket_V: garante ao servidor que este usuário foi autenticado por AS

Autenticador_C: gerado pelo cliente para validar ticket

(6) V -> C: E_KC,V[ TS₅+ 1 ] ( autenticação opcional de servidor para cliente)

E_KC,V: garante a C que esta mensagem é de V

TS₅+ 1 : garante a C que este não é um replay de um reply antigo

Ticket_{V =}E_KV [ K_C,V|| ID_C|| AD_C|| ID_V|| TS₄ || Tempo de vida₄] (ticket reusável)

E_KV : ticket é criptografado por chave conhecida apenas por TGS e servidor

K_C,V: cópia da chave de sessão acessível para cliente, usado para decriptografar autenticador

ID_C: indica o dono do ticket

AD_C: previne o uso do ticket por uma workstation diferente da que solicitou o ticket

ID_V: garante ao servidor que ele decriptografou o ticket corretamente

TS₄ : informa ao servidor o temo que este ticket foi criado

Tempo de vida₄: previne replay depois que o ticket foi expirado

Autenticador_C= E _KC,TGS [ID_C|| AD_C|| TS₅] garante ao TGS que o apresentador do ticket é o mesmo que solicitou, tem curto tempo de vida para prevenir replay

E _KC,TGS : autenticador é criptografado com chave conhecida apenas pelo cliente e TGS

ID_C: deve ser igual ao ID no ticket autenticado

AD_C: deve ser igual ao endereço no ticket autenticado

TS₅: informa ao TGS do tempo que este autenticador foi gerado

Quando C apresenta este ticket (5), é enviado também um autenticador. O servidor pode decriptografar o ticket , recuperar a chave de sessão, e decriptografar o autenticador.

Se autenticação mútua é requerida, o servidor pode reply (6) retornando o timestamp do autenticador incrementado de 1, e criptografado com a chave de sessão. C pode decriptografar esta mensagem para recuperar o timestamp incrementado. Como a mensagem foi criptografada com a chave de sessão, C está certo que a mensagem veio de V. O conteúdo da mensagem garante a C que esta mensagem não é um replay de um reply antigo.

Finalmente como conclusão deste processo, temos que o cliente e o servidor compartilham uma chave secreta. Esta chave pode ser usada para criptografar mensagens futuras entre os dois.

Realms Kerberos e Múltiplos Kerberi

Um ambiente Kerberos consistindo de um servidor Kerberos, um número de clientes e um número de servidores de aplicação, requer o seguinte:

o servidor Kerberos deve ter o UID e password de todos os usuários participantes em uma base de dados. Todos os usuários são registrados no servidor Kerberos.

o servidor Kerberos deve compartilhar uma chave secreta com cada servidor. Todos servidores são registrados no servidor Kerberos.

Tal ambiente é chamado um realm. Redes de clientes e servidores sob diferentes organizações administrativas geralmente constituem diferentes realms. Entretanto, usuários em realm podem precisar acessar servidores em outros realms, e alguns servidores podem prover serviços para usuários em outros realms, visto que estes usuários são autenticados.

Kerberos prove um mecanismo para suportar tal autenticação inter-realm. Para dois realms suportarem autenticação inter-realm, um terceiro requisito é adicionado:

o servidor Kerberos em cada realm interoperando, compartilha uma chave secreta com o servidor no outro realm. Os dois servidores Kerberos são registrados um no outro.

O esquema requer que o servidor Kerberos em um realm confie no servidor Kerberos no outro realm para autenticar seus usuários. Da mesma forma, os servidores do segundo realm devem confiar no servidor do primeiro realm para autenticar seus usuários.

Com estas regras, pode-se descrever o mecanismo como segue: um usuário que deseja um serviço de um servidor em um outro realm precisa de um ticket para este servidor. O cliente do usuário segue o procedimento usual para pegar acesso para um TGS local e então requisita um ticket ticket-granting para um TGS remoto (TGS em um outro realm). O cliente pode então pedir para o TGS remoto um ticket service-granting para o servidor desejado no realm do TGS remoto.

Como é feita esta comunicação:

(1) C -> AS (3) C -> TGS (5) C -> TGS_rem (7) C -> V_rem

(2) AS -> C (4) TGS -> C (6) TGS_rem -> C

O ticket apresentado para o servidor remoto indica em que realm o usuário foi originalmente autenticado.

Se existe N realms, então deve ter [N(N-1)]/2 comunicação de chaves seguras de forma que cada realm Kerberos pode interoperar com todos os outros realms Kerberos.

Kerberos Versão 5

Kerberos versão 5 oferece melhoras para versão 4. Serão falados de modo geral as mudanças da versão 4 para versão 5 e depois será falada a versão 5.

Diferenças entre versão 4 e versão 5

Versão 5 tem como objetivo melhorar as limitações de versão 4 em duas áreas: falhas ambientais e deficiências técnicas. Serão citadas algumas delas:

Dependência do sistema de criptografia: versão 4 precisa utilizar DES. Em versão 5 o ciphertext é marcado com um identificador do tipo de criptografia, assim qualquer técnica pode ser usada. Chaves de criptografia são marcadas com o tipo e o tamanho, permitindo a mesma chave ser usada em diferentes algoritmos e permite a especificação de diferentes variações em um dado algoritmo.

Dependência do protocolo Internet: versão 4 requer o uso de endereços IP. Versão 5 endereços são marcados com o tipo e o tamanho, permitindo que qualquer tipo de endereço de rede seja utilizado.

Tempo de vida do ticket: em versão 4 valores de tempo de vida são codificados com 8 bits em unidades de 5 minutos. Assim, o tempo de vida máximo que pode ser expresso é 2⁸ x 5 = 1280 minutos ou 21 horas. Isto pode ser inadequado para algumas aplicações ( ex: simulação de longa execução que precisa de credenciais Kerberos durante a execução). Em versão 5 , tickets incluem um tempo inicial e um tempo final, permitindo tickets com tempo de vida arbitrários.

Forward de autenticação: versão 4 não permite que credenciais de um cliente sejam forward para algum outro host e usado por outro cliente. Isto pode permitir que um cliente acesse um servidor e este servidor acesse outro servidor por parte do cliente. Por exemplo, um cliente requisita serviço de um servidor de impressão que então acessa o arquivo do cliente no servidor de arquivos, usando a credencial do cliente para acessar. Versão 5 tem esta capacidade.

Autenticação inter-realm: em versão 4, interoperabilidade entre N realms precisa na ordem de N² relações Kerberos como descrito anteriormente. Versão 5 suporta um método que precisa de poucas relações.

Além das limitações citadas temos as limitações técnicas da versão 4. Muitas destas deficiências foram documentadas e tentou-se resolvê-las em versão 5.

Criptografia dupla: nas mensagens 1 e 4 de versão 4 mostradas anteriormente, os tickets dados aos clientes são criptografados duas vezes, uma com a chave secreta do servidor destino e mais uma vez com a chave secreta conhecida pelo cliente. A segunda é considerada desnecessária.

Criptografia PCBC: criptografia em versão 4 utiliza um modo não padrão de DES conhecido como plain-e-cipher cadeia de bloco (PCBC).Foi demonstrado que este modo é vulnerável a um ataque envolvendo a troca de blocos ciphertext. O PCBC foi desenvolvido para dar um check de integridade como parte da operação de criptografia. Versão 5 provê mecanismos de integridade explícitos, permitindo o modo padrão CBC ser usado para criptografia.

Chaves de sessão: cada ticket inclui uma chave de sessão que é usada pelo cliente para criptografar o autenticador enviado para o serviço associado a cada ticket. Além disso, a chave de sessão pode subseqüentemente ser usada pelo cliente e pelo servidor para proteger mensagens durante esta sessão. Entretanto, porque o mesmo ticket pode ser usado repetidamente para pedir serviço de um servidor particular, há o risco de um oponente replay mensagens de uma sessão antiga para o cliente ou para o servidor. Em versão 5, é possível para um cliente e para um servidor negociar uma chave de subseção, a qual pode ser usada para uma única conexão. Um novo acesso pelo cliente resultará no uso de uma nova chave de subseção.

Ataques de password: uma vulnerabilidade compartilhada por ambas versões é o ataque a password. A mensagem do AS para o cliente inclui material criptografado com a chave baseada na password do cliente. Um oponente pode capturar esta mensagem e tentar decriptografar ela tentando várias passwords. Se o resultado de um teste de decriptografia der certo, então o oponente descobriu a password do cliente e poderá utilizá-la subseqüentemente para autenticação de credenciais Kerberos. Versão 5 oferece um serviço de pré-autenticação que torna o ataque a password mais difícil, mas não previne totalmente.

Diálogo de autenticação Versão 5

Primeiro considere a comunicação do serviço de autenticação.

Mensagem 1 : cliente requisita um ticket ticket-granting.

(a) Comunicação do serviço de autenticação

(1) C -> AS: Opções || ID_C || Realm _c || ID_TGS|| Times || Nonces₁

Elementos adicionados:

Realm: indica o realm do usuário

Options: usado para indicar que alguns flags sejam setados no ticket de retorno

Times: usado pelo cliente para pedir as seguintes configurações de tempo no ticket:

- from: o tempo inicial do ticket requisitado

- till: o tempo de expiração para o ticket requisitado

- rtime: renovação do tempo

Nonce: um número randômico para ser repetido em mensagem 2 para garantir que a resposta não é replay de um oponente

ID_C : diz a AS a identidade do usuário deste cliente

ID_TGS: diz a AS que o usuário requisita acesso para TGS

Mensagem 2 retorna o ticket ticket-granting.

(2) AS -> C: Realm_c || ID_c || Ticket_TGS || E_KC [ K_C,TGS || Times || Nonce₁ || Realm_tgs || ID_TGS]

Mensagem 2 possui informação para o cliente, e um bloco criptografado usando a chave de criptografia baseda na password do usuário. Este bloco inclui a chave de sessão para ser usada entre o cliente e o TGS, o times especificado em mensagem 1, o nonce de mensagem 1, e a informação de identificação do TGS.

Ticket_TGS: ticket utilizado pelo cliente para acessar TGS. O ticket inclui a chave de sessão, identificando informação para o cliente, os valores de tempo requisitados, e os flags que refletem o status deste ticket e as opções pedidas.

Ticket_{TGS =}E_Ktgs [ Flags || K_c,tgs || Realm_c || ID_c || AD_c || Times ]

Os flags introduzem nova funcionalidade significante para versão 5. Serão discutidos mais adiante.

Comparando agora a comunicação do serviço ticket-granting para versões 4 e 5.

(a) Comunicação do serviço Ticket-Granting

(3) C -> TGS: Opções || ID_V || Realm _c || Ticket_TGS|| Times || Nonces₂ || Autenticador_C

Ticket_{TGS =}E_Ktgs [ Flags || K_c,tgs || Realm_c || ID_c || AD_c || Times ]

Como podemos ver a mensagem 3 para ambas versões incluem um autenticador, um ticket, e o nome do serviço requisitado. Além disso, versão 5 inclui times e requisitados e opções para o ticket e um nonce, todos com funções similares a mensagem 1. O autenticador é essencialmente o mesmo do utilizado em versão 4.

(4) TGS -> C: Realm_c || ID_c || TicketV || E_KC,TGS [ K_C,V || Times || Nonce₂ || Realm_V || ID_V]

Ticket_{V =}E_KV [ Flags || K_C,V || Realm_c || ID_c || AD_c || Times ]

Autenticador_C= E _KC,TGS [ID_C|| Realm_C|| TS₁]

Mensagem 4 tem a mesma estrutura da mensagem 2, retornando um ticket com informações a mais necessárias para o cliente, a última criptografada com a chave de sessão agora compartilhada pelo cliente e pelo TGS.

Finalmente, a comunicação da autenticação cliente/servidor, várias características novas aparecem em versão 5.

(c) Comunicação da autenticação cliente/servidor

(5) C -> TGS: Opções || Ticket_V|| Autenticador_C

(6) TGS -> C: E_C,V [ TS₂|| Subkey || Seq# ]

Mensagem 6 é utilizada se autenticação mútua é requerida, o servidor responde com esta mensagem. Esta mensagem inclui o timestamp do autenticador. É importante notar que em versão 4, o timestamp é incrementado por um. Isto não é necessário em versão 5 porque o formato das mensagens é tal que não é possível para um oponente criar mensagem 6 sem conhecer a chave de criptografia apropriada. O campo Subkey se apresentado é o mesmo da mensagem 5. O campo opcional de número de seqüência especifica o número de seqüência inicial a ser usado pelo cliente.

Ticket_{V =}E_KV [ Flags || K_C,V || Realm_c || ID_c || AD_c || Times ]

Autenticador_C= E _KC,V [ID_C|| Realm_C|| TS₂|| Subkey || Seq# ]

O autenticador inclui vários campos novos, entre eles temos:

Subkey: a escolha do cliente para uma chave de criptografia ser utilizada para proteger esta específica sessão de aplicação. Se este campo é omitido, a chave de sessão do ticket (K_C,V) é utilizada.

Sequence number: um campo opcional que especifica o número de seqüência inicial para ser usado para mensagens enviadas pelo cliente durante esta sessão. Mensagens sequenciadas podem ser usadas para detectar replay.

Flags nos tickets

Abaixo temos uma breve descrição do que significa cada flag que pode ser incluída nos tickets em versão 5.

Flags e descrição

INITIAL - o ticket foi liberado usando o protocolo AS, e não liberado baseado em um ticket ticket-granting

PRE-AUTHENT - durante autenticação inicial, o cliente foi autenticado pelo KDC antes do ticket ser liberado

HW-AUTHENT - o protocolo utilizado para autenticação inicial precisa usar hardware esperado para ser possuído apenas pelo cliente

RENEWABLE - diz a TGS que este ticket pode ser usado para obter um outro ticket que expire em uma data mais tarde

MAY-POSTDATE - indica que este ticket foi pos datado; o servidor final pode usar o campo authtime para ver quando a autenticação original ocorreu

INVALID - este ticket é inválido e deve ser validado pelo KDC antes de ser utilizado

PROXIABLE - diz ao TGS que um novo ticket service-granting com um endereço de rede diferente pode ser liberado baseado na apresentação deste ticket

PROXY - indica que este ticket é um proxy

FORWARDABLE - diz ao TGS que um novo ticket ticket-granting com um endereço de rede diferente pode ser liberado baseado neste ticket ticket-granting

FORWARDED - indica que este ticket foi forwarded ou foi liberado baseado em autenticação envolvendo um ticket forwarded ticket-granting

Segurança no Correio Eletrônico

Correio eletrônico é uma das aplicações de rede mais utilizadas atualmente. Além disso, é uma aplicação distribuída que é usada amplamente através de várias arquiteturas e plataformas.

Com o grande crescimento do uso do correio eletrônico para vários propósitos, cresceu também a necessidade do uso de serviços de autenticação e confidencialidade.

Alguns dos serviços solicitados são:

Privacidade: É a habilidade de fazer com que só o receptor da mensagem possa lê-la.

Autenticação: O receptor fica sabendo da identidade da pessoa que mandou a mensagem.

Integridade: Faz com que a mensagem não seja alterada no caminho do remetente ao receptor.

Prova de recepção: O receptor pode provar a um terceiro que o remetente realmente mandou a mensagem.

Prova de envio: Certifica ao remetente que a mensagem passou pelo sistema de entrega do correio.

Prova de entrega: Verificação de que o destinatário recebeu a mensagem.

Confidencialidade do fluxo de mensagem: Uma extensão de privacidade, com a diferença que não se pode saber se a mensagem foi mandada de uma pessoa para outra.

Anonimato: Mandar uma mensagem sem que a outra pessoa saiba quem a mandou.

Contenção: A habilidade da rede de manter alguns níveis de segurança de informação.

Auditoria: A rede grava alguns eventos que têm alguma relevância para segurança.

Auto destruição: Uma opção que permite que a mensagem seja destruída após ser lida pelo destinatário.

Integridade da seqüência das mensagens: Toda a seqüência de mensagem chega ao destinatário na ordem transmitida e sem nenhuma perda.

Privacidade

A maioria das pessoas pensa que o correio eletrônico tem privacidade, mas há algumas maneiras de ler mensagens alheias:

A mensagem pode ser lida enquanto está sendo transmitida pelo meio físico. Se a rede tiver links criptografados, isso pode ser evitado.

Nós (routers ou mail fowarders) podem ter softwares que guardam as mensagens e as divulgam para outras pessoas que não são as receptoras de fato.

Uma maneira de mandar uma mensagem para outra pessoa sem que outras possam lê-la é usar criptografia. Para isso a chave do destinatário deve ser usada na cifragem. Caso a pessoa queira mandar a mesma mensagem para várias pessoas diferentes, ela deve criptografar a mensagem com uma chave qualquer C e criptografar C para cada destinatário com sua respectiva chave, evitando assim de criptografar a mesma mensagem com cada chave diferente.

Autenticação

Quando uma pessoa recebe uma mensagem, geralmente ela quer saber se o remetente é realmente que consta na mensagem é realmente quem a mandou. Por este motivo, há alguns mecanismos de autenticação. Uma maneira de autenticar a mensagem é por nela uma assinatura digital. O remetente pode colocar na mensagem sua chave privada, assumindo que o destinatário conhece a chave pública do remetente. Desta maneira o receptor tem a certeza que a mensagem é segura. Uma outra maneira é quando ambos, remetente e destinatário tem uma chave secreta em comum. Colocando um trecho da mensagem criptografado com a chave secreta assegura ao receptor que o remetente é realmente quem se diz ser.

Integridade de mensagem

Não adianta a mensagem ser autenticada se não houver a certeza de que ela está íntegra, se não houve modificação em seu conteúdo durante a transmissão. Geralmente, quando o serviço de autenticação é oferecido, o serviço de integridade também o é.

Prova de recepção

Pode acontecer o fato de a pessoa negar que mandou a mensagem para outra pessoa. Isto pode ser evitado usando autenticação. Se o remetente manda uma mensagem autenticada para outra pessoa, o receptor pode provar que foi esta pessoa quem mandou a mensagem através da assinatura digital.

Para este propósito, são usados o PGP (Pretty Good Privacy) e o PEM( Privacy_Enhanced Mail). Neste documento abordaremos os aspectos do PGP.

Pretty Good Privacy (PGP)

PGP foi desenvolvido por Phil Zimmermann para oferecer um serviço com confidencialidade e autenticação que pode ser usado em aplicações de correio eletrônico e manutenção de arquivos.

Essencialmente, o que Zimmermann fez foi:

Selecionou os melhores algoritmos de criptografia;

Integrou estes algoritmos em uma aplicação de propósito geral que é independente de sistema operacional e processador baseado em um conjunto pequeno de funções fáceis de usar;

Tornou o pacote com sua documentação, incluindo o código fonte, livre para acesso via Internet;

Os motivos que tornaram o PGP bastante popular foram:

Está disponível livremente em versões que rodam em diferentes plataformas incluindo DOS/Windows, UNIX, Machintosh, e muitas outras. Além disso, a versão comercial do PGP dá direito a suporte.

Foi desenvolvido utilizando algoritmos que sobreviveram a extensivas revisões públicas e são considerados extremamente seguros. Especificamente, o pacote inclui RSA para cifragem utilizando chave pública, IDEA para cifragem convencional, e MD5 para hash coding.

Tem uma variedade de aplicações distintas. Desde uma corporação que deseja ter um padrão para criptografar seus arquivos e mensagens até indivíduos que desejam se comunicar com outras pessoas com segurança.

Não foi desenvolvido nem é controlado por nenhuma organização governamental.

Os recursos oferecidos pelo PGP são:

Autenticação

Confidencialidade

Compressão

Compatibilidade de e-mail

Segmentação

Autenticação

A autenticação segue a seguinte seqüência:

transmissor cria a mensagem;

MD5 é usado para gerar o hash code da mensagem com 128 bits;

O hash code é criptografado utilizando RSA com a chave privada do transmissor, e o resultado é integrado à mensagem;

O receptor usa RSA com a chave pública do transmissor para descriptografar e restabelecer o hash code;

O receptor gera um novo hash code para a mensagem e compara-o com o hash code descritpografado. Se os dois forem compatíveis, a mensagem é aceita como autêntica.

Figura 1 - Autenticação

Confidencialidade

Pode ser necessária para criptografar mensagens a serem transmitidas ou arquivos a serem guardados. Em ambos os casos, a criptografia convencional é utilizada. O algoritmo usado é o IDEA.

O problema enfrentado é como distribuir a chave secreta, já que este tipo de cifragem utiliza uma única chave que deve ser mantida secreta por ambos transmissor e receptor. Em PGP, cada chave convencional é usada uma única vez. Ou seja, uma nova chave é gerada randomicamente como um número de 128 bits para cada mensagem.

Os passos são os seguintes:

O transmissor gera a mensagem e um número randômico de 128 bits para ser usada como chave de sessão para apenas a mensagem corrente;

A mensagem é cifrada, usando IDEA com a chave de sessão;

A chave de sessão é cifrada com RSA, usando a chave pública do receptor, e é integrada à mensagem;

O receptor usa RSA com sua chave privada para decifrar e obter a chave de sessão;

A chave de sessão é usada para decifrar a mensagem.

Figura 2 - Confidencialidade

Confidencialidade e Autenticação

Ambos os serviços, confidencialidade e autenticação podem ser usados para a mesma mensagem. Primeiro, a assinatura é gerada para a mensagem plaintext e integrada a mensagem. Em seguida, a mensagem plaintext e a assinatura são criptografadas usando IDEA, e a chave de sessão é cifrada usando RSA.

Resumindo, quando ambos os serviços são usados, o transmissor primeiro assina a mensagem com sua chave privada, então criptografa a mensagem com a chave de sessão, e em seguida, cifra a chave de sessão com a chave pública do receptor.

Figura 3 - Confidencialidade e autenticação.

Compressão

PGP faz a compressão dos dados depois de aplicar a assinatura, mas antes de cifrar a mensagem. A assinatura é gerada antes da compressão por dois motivos:

É preferível assinar uma mensagem não comprimida porque a mensagem não comprimida pode ser guardada juntamente com a assinatura para verificações futuras. Se a assinatura fosse aplicada a uma mensagem comprimida, seria necessário guardar uma versão comprimida da mensagem para verificações futuras ou recomprimir a mensagem para verificar sua autenticidade quando fosse necessário novamente;

Mesmo que alguém quisesse dinamicamente gerar mensagens recomprimidas para verificação, haveria problemas. O algoritmo de compressão não é determinístico; várias implementações do algoritmo apresentam variações em tempo de execução e raio de compressão, e como resultado gera diferentes formatos de compressão.

A mensagem é criptografada depois da compressão para aumentar o grau de segurança. Como a mensagem comprimida tem menos redundância que o texto original, a criptanálise é mais difícil.

Compatibilidade de E-Mail

Quando PGP é usado, pelo menos parte do bloco a ser transmitido é cifrado. Desta forma, parte do bloco resultante consiste de um stream arbitrário de 8-bit octets. Contudo, muitos sistemas de correio eletrônico só permite o uso de blocos que consistem de texto ASCII. Para acomodar esta restrição, PGP disponibiliza o serviço de converter uma cadeia de 8 bits em caracteres ASCII.

O esquema utilizado para este propósito é conversão radix-64. Cada grupo de três octetos de dados binários é mapeado para quatro caracteres ASCII.

Segmentação e Remontagem

As facilidades de e-mail são geralmente restritas a um tamanho máximo de mensagem. Para acomodar esta restrição, PGP automaticamente divide as mensagens que são muito longas em segmentos pequenos o suficiente para serem enviados via e-mail. A segmentação é feita após todos os outros processos. A chave de sessão e a assinatura aparecem uma única vez, no início do primeiro segmento. No receptor final, PGP remonta o bloco inteiro original e faz o processamento necessário para descriptografar a mensagem.

Sumário dos serviços do PGP

Função	Algoritmos Utilizados	Descrição
Mensagem cifrada	IDEA, RSA	Uma mensagem é criptografada usando IDEA com uma chave secreta de uma única vez gerada pelo transmissor. A chave secreta é criptografada usando RSA com a chave pública do receptor e incluída com a mensagem.
Assinatura Digital	RSA, MD5	Um código hash é criado usando MD5. Esta mensagem é criptografada usando RSA com a chave privada do transmissor e incluída na mensagem.
Compressão	Zip	A mensagem pode ser comprimida para estocagem ou para transmissão.
Compat. e-mail	Conversão Radix 64	Para prover transferência nas aplicações de e-mail, uma mensagem criptografada pode ser convertida para strings ASCII usando a conversão Radix 64.
Segmentação	-	Para acomodar o tamanho máximo da mensagem, PGP faz segmentação e remontagem.

Tabela 1 - Resumo dos serviços oferecidos pelo PGP.

Serviços do PGP

Autenticação

Utiliza assinatura digital

Confidencialidade

Utiliza criptografia

Confidencialidade e autenticação

Assinatura digital é gerada e a mensagem é criptografada.

Compressão

Compressão é aplicada depois da geração da ass. digital e antes do texto ser criptografado.

Segmentação e remontagem

A segmentação é feita depois de todos os outros processamentos. A chave secreta e assinatura só aparecem no início do primeiro segmento.

Figura 4 - Diagrama genérico de transmissão ( de A ).

Figura 5 - Diagrama genérico de recepção ( para B ).

Chaves de Criptografia usadas pelo PGP

PGP faz uso de quatro tipos de chave: chave de sessão, chave pública, chave privada, e chave baseada em passphrase.

Nome	Algoritmo de Cifragem	Utilização
Chave de Sessão	IDEA	Cifrar mensagens para transmissão. É usada uma única vez e é gerada randomicamente.
Chave Pública	RSA	Cifrar chaves de sessão para transmissão com a mensagem. Ambos, transmissor e receptor devem ter uma cópia de cada chave pública.
Chave Privada	RSA	Formar uma assinatura. Apenas o receptor mantém uma cópia de sua chave privada.
Chave baseada em Passphrase	IDEA	Cifrar chave privada para ser estocada no transmissor.

Tabela 2 - chaves usadas pelo PGP.

Cada chave de sessão é associada a uma única mensagem e é usada apenas para cifrar e decifrar esta mensagem. Números randômicos de 128 bits são gerados utilizando o algoritmo RSA.

Uma mensagem criptografada é acompanhada de uma chave de sessão cifrada com a chave pública do receptor. Desta forma, apenas o receptor poderá decifrar a chave de sessão utilizando sua chave privada e em seguida decifrar a mensagem. Se cada usuário tivesse apenas um par de chaves pública/privada, esta decifragem poderia ser feita automaticamente. Mas, cada usuário pode ter mais de um par. Uma das razões do usuário ter mais de uma par de chaves é para poder utilizar cada par com um grupo diferente de usuários.

Uma forma de solucionar este problema de qual chave deve ser a utilizada é transmitir a chave pública juntamente com a mensagem. Esta solução não é muito interessante pois gera um overhead desnecessário. Uma outra solução é associar um identificador a cada chave que seria única, pelo menos no domínio de cada usuário. Esta solução também gera overhead, pois ambos, transmissor e receptor, teriam que ter um mapa que identificasse cada chave a seu identificador.

A solução adotada pelo PGP é gerar um ID para cada chave, mas este ID seria os 64 bits menos significantes da chave. Probabilisticamente seria muito difícil haver duplicatas de IDs.

Cada usuário deve guardar duas tabelas. Uma com as suas chaves privadas e uma outra com as chaves públicas dos outros usuários.

A tabela de chaves privadas tem os seguintes campos:

Timestamp: Dia/hora que o par de chaves foi gerado;

Key ID: Os últimos 64 bits significantes da chave pública;

Chave pública;

Chave privada: Este campo é criptografado;

User ID: Geralmente o e-mail do usuário.

A tabela de chaves públicas tem os seguintes campos:

Timestamp: Dia/hora que esta entrada foi gerada;

Key ID: Os últimos 64 bits significantes da chave pública;

Chave pública;

User ID: Identifica o dono da chave;

Além de outros campos.

Um dos problemas enfrentados pelo PGP é o gerenciamento das chaves públicas. Como saber se a chave pública associada a B é realmente de B.

Para minimizar estes problemas temos algumas sugestões. Suponhamos que A deseja obter a chave pública de B:

A deve receber fisicamente, pessoalmente, a chave de B. É um método seguro, porém ineficiente.

Verificar a chave de B por telefone, se A reconhecer bem a voz de B.

Obter a chave de B através de um terceiro confiável D que pode ser uma autoridade com certificado.

Bibliografia

Stallings, W., Network and Internetwork Security, Principles and Practice, Englewood Cliffs, NJ, Prentice Hall, 1995, pp. 107 - 96, pp. 360 - 383.

Kaufman, C., Pearlman, R., and Speciner, M.: Network Security, Englewood Cliffs, NJ: Prentice Hall, 1995.

http://nii.isi.edu/publications/kerberos-neuman-tso.html

ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.txt