Mecanismos de Autenticação
-----------------------------------------------------------------------------------------------------------------------Índice
1. Introdução.....................................................................................................................................................1
1.2 Mecanismos de autenticação.....................................................................................................................................1
1.2 Alguns conceitos.......................................................................................................................................................2
1.2.1 Endereço do remetente..................................................................................................................................................................................2
1.2.2 Serviço de DNS.............................................................................................................................................................................................2
2. Autenticação dos utilizadores e Transporte seguro.......................................................................................3
2.1 SASL (Simple Authentication and Security Layer)..................................................................................................3
2.2 TLS (Transport Layer Security)................................................................................................................................3
3. Autenticação efectuada pelos UAs................................................................................................................4
3.1 PGP (Pretty Good Privacy).......................................................................................................................................5
3.2 S/MIME (Secure MIME)..........................................................................................................................................5
4. Autenticação efectuada pelos MTAs.............................................................................................................6
4.1 SPF (Sender Policy Framework)..............................................................................................................................6
4.2 Sender ID..................................................................................................................................................................7
4.3 DKIM (DomainKeys Identified Mail)......................................................................................................................8
5. Conclusões....................................................................................................................................................9
Referências.......................................................................................................................................................9
------------------------------------------------------------------------------------------------------------------------
1. Introdução
De uma forma generalizada, pode-se identificar os seguintes problemas relacionados com a
autenticação dos emails:
• Envio de mensagens não solicitadas (spam), que pode ter os seguintes objectivos:
◦ estratégia comercial, por exemplo para a divulgação de um produto;
◦ propagação de vírus;
◦ provocar DoS (Denial of Service), por exemplo devido ao volume elevado de emails a
processar.
• Utilização indevida de mensagens, para:
◦ falsificação de identidade (spoofing);
◦ tentativa de conseguir dados pessoais (phishing).
Estes problemas não afectam apenas os utilizadores, mas também os servidores de email,
que compromete alguns dos seus requisitos não funcionais como: o desempenho, a fiabilidade e a
segurança.
1.2 Mecanismos de autenticação
Devido à maioria dos servidores de email terem suporte ao protocolo de transporte base
(SMTP), é muito difícil fazer alterações ao protocolo sem ter impactos sobre o funcionamento dos
mesmos.
Numa primeira fase, para minimizar estes tipos de problemas, recorreu-se:
• Sistemas de email com autenticação SASL;
• Sistemas anti-spam e anti-vírus;
• Autenticação dos emails com assinaturas digitais (ex: PGP, S/MIME).
•
•
Actualmente a resolução tem-se verificado com a reformulação do protocolo base (SMTP):
Publicação dos servidores que estão autorizados a enviar emails. (SPF, Sender ID);
Assinatura do cabeçalho e integridade dos dados (DKIM).
autenticacao_email_v3.odt
Página 1 de 9
1.2 Alguns conceitos
1.2.1 Endereço do remetente
Como no correio postal, as mensagens de email no mínimo têm dois tipos de endereços: um
no envelope e outro no cabeçalho da carta/mensagem. [1]
• O endereço do remetente no envelope (return-path) é utilizado durante o transporte da
mensagem entre os servidores de email. Em caso de falha na entrega, o servidor devolve a
mensagem para este endereço.
• O endereço do remetente no cabeçalho da mensagem é incluído no campo “From:” ou
“Sender:”, sendo este visível nos UAs. Normalmente os servidores de email não dão muita
importância a este endereço.
1.2.2 Serviço de DNS
O DNS (Domain Name System), é um serviço que efectua a tradução de um domínio num
endereço IP e vice-versa. É um serviço que funciona segundo o modelo cliente-servidor.
gnu14.netlab.fe.up.pt ↔ 172.16.2.14
O servidor de email interage com o DNS de dois modos:
• Para enviar emails – O servidor de email deve possuir uma ligação fiável ao servidor de
DNS para a resolução de domínios, de modo a determinar o encaminhamento a efectuar.
• Para receber emails – O domínio de destino deve estar correctamente configurado para
encaminhar as mensagens para o servidor de email do seu domínio.
Uma configuração incorrecta do servidor de DNS é uma fonte comum de problemas no
serviço de email.
Os nomes estão organizados, duma forma hierárquica em forma de árvore.
<figura>
O DNS é constituído por zonas, sendo que uma zona é uma sub-árvore resultante de uma
partição hierárquica. É da responsabilidade de um único servidor a informação relativa a uma zona,
mas um servidor poderá conter mais do que uma zona.
O serviço de DNS possui registos designados de resource records que contêm informações
de uma dada zona. Os diferentes registos oferecem vários tipos de informações, tais como
endereços IP, nameservers, hostname aliases e mail routing. Os registos necessários para o serviço
de email são:
• A – Mapeamento de nomes em endereços IP.
• CNAME – Apontam para outro hostname em vez do endereço IP.
• MX – O registo MX refere-se aos servidores de email. O registo MX contém informações
sobre o servidor e a prioridade (ou preferência) para o envio de emails nesse domínio.
Podem existir mais registos do tipo MX, que correspondem a servidores de email com uma
prioridade mais baixa e funcionam como servidores secundários. Em caso do servidor
primário deixar de funcionar, são os servidores secundários que recebem os emails.
• PTR – Mapeamento inverso, endereço IP em hostname.
• TXT – Uma descrição textual informativa, com máximo de 255 caracteres.
• SPF – Do mesmo tipo do registo TXT. Apenas para as versões recentes de servidores de
DNS.
autenticacao_email_v3.odt
Página 2 de 9
2. Autenticação dos utilizadores e Transporte seguro
O protocolo base SMTP não oferece nenhum mecanismo de autenticação dos utilizadores.
Como o endereço dos emails é fácil de falsificar, torna-se difícil determinar o verdadeiro remetente
da mensagem, a não ser que o servidor tenha a capacidade de fazer a autenticação dos utilizadores.
Para prevenir de usos não autorizados, pode-se limitar a utilização a determinados endereços
IPs. Mas com isto surge o problema quando os utilizadores se encontram em mobilidade, isto é
quando as suas ligações ao servidor não têm sempre o mesmo endereço IP, mas sim endereços IPs
dinâmicos.
O “SMTP Service Extension for Authentication” (RFC 2554) fornece uma extensão do
protocolo SMTP, que permite a autenticação dos clientes através do protocolo SASL (Simple
Authentication and Security Layer). Pode-se adicionalmente recorrer ao protocolo de transporte
seguro TLS (Transport Layer Security) [4].
2.1 SASL (Simple Authentication and Security Layer)
O protocolo SASL tem como objectivo fornecer um mecanismo de autenticação dos clientes
perante o servidor, sendo que estes clientes podem ser UAs ou outros MTAs.
Os UAs podem usar o SMTP com ou sem segurança, mantendo o mesmo porto (25). O
SASL permite ao cliente negociar com o servidor o esquema de segurança. No caso de optarem por
SMTP com segurança, primeiro é estabelecido um canal seguro TLS (STARTTLS) e depois o
cliente autentica-se através de username/password.
•
•
Para o SASL funcionar, necessita de saber:
Mecanismos de autenticação – desafios e respostas entre o cliente e o servidor, e como
estes devem ser codificados para a transmissão.
Esquema de autenticação – refere-se como o servidor guarda e verifica a informação
relativa à password.
De um modo geral, pode-se dizer que o SASL, oferece a autenticação dos clientes e a
encriptação nos dados transmitidos.
2.2 TLS (Transport Layer Security)
O TLS é o método de encriptação de dados mais utilizado na comunicação entre os
servidores Web e os browsers, mas também pode-se utilizar para os servidores de email e os seus
clientes. Sendo que em alguns mecanismos de SASL a password é transmitida sobre o TLS, de
modo a enviar num canal seguro.
•
•
•
•
•
•
•
TLS é versão actualizada do SSL (Secure Sockets Layer).
Fornece encriptação dos dados ponto-a-ponto.
Encriptação a nível da aplicação.
Faz uso de certificados X509 para autenticações.
Garante a privacidade e a integridade dos dados num canal de comunicação, que é
conseguida pela autenticação dos seus intervenientes e a criptografia dos dados trocados
entre ambas as partes.
Autenticação é conseguida com a troca de certificados.
Criptografia dos dados é garantida pela criptografia de chave pública.
autenticacao_email_v3.odt
Página 3 de 9
3. Autenticação efectuada pelos UAs
Aqui o UA efectua a autenticação do utilizador, pela colocação da assinatura digital na
mensagem, não havendo qualquer tipo de alteração no seu transporte, deste modo esta operação é
transparente para o MTA.
Os dois mecanismos mais conhecidos para efectuar este tipo de autenticação são: PGP
(Pretty Good Privacy) e S/MIME (Secure MIME). Ambos os protocolos permitem:
•
Assinatura digital - A assinatura digital garante a integridade, autenticidade e não repúdio.
O processo consiste na geração de uma assinatura com base numa função de hash obtida da
mensagem a transmitir. Posteriormente a etiqueta resultante (resumo) é cifrada com a chave
privada do autor permitindo a confirmação por parte do destinatário da origem da
mensagem.
•
Encriptação das mensagens - A confidencialidade das mensagens entre utilizadores, como
visto anteriormente, não é assegurada com o simples protocolo SMTP. É necessário recorrer
a criptografia de chave pública para o envio de mensagens com garantias de
confidencialidade.
=> Mensagem é cifrada com a
chave pública do destinatário.
=> Essa mensagem apenas é
decifrada com a respectiva chave
privada.
=> Como o destinatário é que tem a
posse da chave privada, apenas ele
é que pode decifrar a mensagem.
•
Assinatura e encriptação - Para garantir a confidencialidade e a autenticidade das
mensagens recorre-se aos dois mecanismos anteriores.
Características da criptografia de chave pública [5]:
• Existem duas chaves que matematicamente são relacionadas: Uma chave pública, de
conhecimento público e outra uma chave privada, que é apenas conhecida pelo próprio
dono.
• Características dos algoritmos: Computacionalmente impossível (em tempo útil) descobrir
uma chave, conhecendo a outra e o algoritmo.
• Computacionalmente fácil cifrar/decifrar quando chave é conhecida.
autenticacao_email_v3.odt
Página 4 de 9
3.1 PGP (Pretty Good Privacy)
O PGP é um protocolo que permite assinar e cifrar as mensagens de email, que foi
normalizado pelo IETF (Internet Engineering Task Force) com a designação de Open-PGP (RFC
4880). Recorre à criptografia de chave pública e utiliza cifras de domínio público, por exemplo
IDEA, de forma a evitar licenças sobre algoritmos proprietários.
A informação gerada pela codificação através da chave pública só consegue ser
descodificada utilizando o valor da chave privada. É por esta razão que necessitamos de conhecer a
chave pública do destinatário para enviar uma mensagem codificada através deste sistema (e só o
destinatário, com a sua chave privada, consegue descodificar os dados recebidos).
•
•
•
•
A assinatura pode ser codifica por vários algoritmos, a mais popular é o Base 64.
Verifica-se a adição da linha -----BEGIN PGP SIGNED MESSAGE----- indicando o início
de uma mensagem assinada.
Uma assinatura encontra-se delimitada entre -----BEGIN PGP SIGNATURE----- e -----END
PGP SIGNATURE-----.
Uma mensagem encriptada encontra-se delimitada por-----BEGIN PGP MESSAGE----- e
-----END PGP SIGNATURE-----.
3.2 S/MIME (Secure MIME)
O S/MIME (Secure/Multipurpose Internet Extension) é um melhoramento a nível de
segurança do MIME (Multipurpose Internet Extension).
O MIME é uma extensão ao protocolo SMTP, que veio essencialmente resolver o problema
do envio de mensagens com caracteres especiais, representados por 8bit e o envio de ficheiros em
anexos. A lógica consiste na conversão dessas mensagens ou ficheiros na representação de 7bit
ASCII, por parte dos UA. O MTA recebe a mensagem como esta definido na norma (7bit ASCII). E
para a leitura da mensagem no destinatário é feito a operação inversa (7bit ASCII para 8 bit).
•
•
•
•
•
•
•
S/MIME tal como o PGP, assina e cifra a mensagem (apenas o corpo da mensagem).
O cabeçalho não pode ser cifrado.
Criptografia de chave pública para cifrar as mensagens.
Utiliza certificados para a identificação do remetente → certificados X.509 tal como o SSL
utiliza (e.g. In HTTPS).
Os utilizadores obtêm os certificados a partir de uma autoridade certificadora (CA).
A assinatura digital garante que só algum com a posse da chave privada é que possa ter
enviado a mensagem.
A assinatura e a mensagem cifrada são enviadas em anexo, devidamente assinaladas com o
respectivo tipo de conteúdo (Content-Type:)
Comparação
O sistema de email é um modelo do tipo "store-and-forward", onde as mensagens passam de
servidor em servidor (via o SMTP) até chegarem ao seu destino final, que pode acontecer em alguns
minutos, horas ou até mesmo dias. A protecção dos dados ponto-a-ponto nestes casos não é
aplicável, pois não é possível ter um canal de comunicação sempre disponível. E é aqui que se exige
que haja uma segurança extremo-a-extremo, conseguida pelo PGP e S/MIME.
Estes dois mecanismos são muito semelhantes, permitem obter os resultados relativamente
iguais, diferindo nas tecnologias utilizadas. A grande diferença entre PGP e S/MIME, é que no PGP
a chave pública é utilizada à base de confiança, que não tem nenhuma autoridade que faça a sua
autenticação (CA), como o X.509 PKI utilizados pelo S/MIME.
Tanto o PGP como o S/MIME são suportados pelos principais UAs.
autenticacao_email_v3.odt
Página 5 de 9
4. Autenticação efectuada pelos MTAs
4.1 SPF (Sender Policy Framework)
SPF apenas faz a autenticação do servidor do remetente, no entanto não confirma se o
remetente é mesmo quem diz ser. [1]
SPF permite combater a falsificação de endereços de retorno dos emails (return-path). O
mecanismo permite:
• ao administrador de um domínio: definir e publicar uma política SPF, onde são designados
os endereços das máquinas autorizadas a enviar mensagens em nome deste domínio; e
• ao administrador de um servidor de email: estabelecer critérios de aceitação de mensagens
em função da verificação das políticas SPF publicadas para cada domínio.
Os servidores autorizados a enviar email de um domínio são definidas num registo de DNS
do tipo TXT ou SPF. Tal como descrito anteriormente, estes tipos de registos são utilizados para
apresentar informações textuais.
Exemplo:
Um administrador do domínio qqcoisa.pt, publica um registo do tipo TXT no seu servidor de
DNS que os servidores 200.200.200.200 e 200.200.200.201 estão autorizados de enviar os emails
com remetente @qqcoisa.pt, sendo que quaisquer outros servidores que tentam enviar emails com
@qqcoisa.pt serão considerados como falsos.
Este método poderá ser utilizado por exemplo no combate ao ataque do tipo phishing. Que
são emails enviados a pedido de nomes dos utilizadores e/ou senhas de acessos de contas
protegidas, sendo essa informação utilizada para fins maliciosos.
SPF pode ser considerado uma primeira barreira que evita a recepção completa do email por
parte do servidor, assim como evita o consumo de processamento.
autenticacao_email_v3.odt
Página 6 de 9
4.2 Sender ID
O Sender ID, definido no RFC 4406 é um protocolo desenvolvido pela Microsoft,
semelhante ao SPF que visa a autenticação de um dos endereços do cabeçalho. Recorre a um
algoritmo designado de PRA (Purported Responsible Address, definido no RFC 4407) para
determinar quem é que originou e quem é responsável pela mensagem.
Os registos do DNS utilizados pelo Sender ID têm uma sintaxe semelhante ao SPF. O
Sender ID efectua a autenticação do endereço resultante do algoritmo PRA enquanto o SFP faz a
autenticação do endereço do envelope. [1]
O Sender ID visa verificar que as mensagens com origem num determinado domínio são do
mesmo que dizem ser. [2] O funcionamento do Sender ID é ilustrado de seguida:
1. O utilizador envia a mensagem de email recorrendo ao UA ou com um cliente Web.
2. O servidor de email do destinatário recebe a mensagem. O qual utiliza Sender ID
Framework (SIDF) que efectua a verificação do registo SPF.
3. O servidor de email aceita ou rejeita em função dos resultados obtidos na operação anterior.
4. Caso aceite, a mensagem é depositada na respectiva caixa de email.
Sender ID tem como objectivos [2]:
• Melhorar a entrega de emails legítimos;
• Aumentar a protecção contra ataques do tipo phishing;
• Reduzir os falsos positivos;
• Melhorar a confiança e confidencialidade do serviço de email;
• Reduzir parcialmente as mensagens spam;
• Fácil implementação e de manutenção.
autenticacao_email_v3.odt
Página 7 de 9
4.3 DKIM (DomainKeys Identified Mail)
DKIM e o seu antecessor DomainKeys são também métodos de autenticação de email. O
DomainKeys (RFC 4870) desenvolvido pela Yahoo foi tornado obsoleto pelo DKIM (RFC 4871),
que é uma especificação do IETF. Estes RFCs foram publicados em Maio 2007, o DomainKeys
com o estado historical e o DKIM como Standard.
Oferece um mecanismo de autenticação baseado em criptografia de chave pública, que
garante a autenticidade conseguida com a assinatura do cabeçalho e do corpo da mensagem.
Ao contrario do que acontece no SPF e Sender ID, onde no seu servidor de DNS é publicado
um registo do tipo TXT com a indicação dos servidores de email autorizados a enviar emails, no
caso do DKIM é publicada a sua chave pública. O servidor do remetente antes de enviar a
mensagem, cifra o cabeçalho e o corpo com a sua chave privada, que depois na recepção é decifrada
com a utilização da chave pública obtida pelos consulta dos registos de DNS.[1] Assim no envio é a
mensagem é assinada e na recepção é feita a verificação, isto é, se veio do domínio que diz ser.
DKIM adiciona mais um campo no cabeçalho do email, “DKIM-Signature”, que contém a
assinatura digital do cabeçalho e do corpo da mensagem.
Características do DKIM:
• Baixo custo – sem necessidade de desenvolvimento de novas infraestruturas.
• Não necessita de entidades terceiras – como por exemplo key servers.
• Não existe a necessidade de actualização dos UA – o DKIM é transparente perante os UAs.
• Garante a integridade da mensagem – que não existe alterações no transporte.
• É extensível – para novos tipos de funções hash, …
Desvantagens:
• Se a mensagem durante o transporte for ligeiramente alterada, a assinatura passa a ser
inválida, podendo o servidor de destino rejeitar a mensagem.
• Devido às operações criptográficas que realiza, resulta numa carga computacional adicional
nos servidores de email.
autenticacao_email_v3.odt
Página 8 de 9
5. Conclusões
Todos os mecanismos apresentação não são 100% eficazes, resolvem apenas partes dos
problemas. Sendo que todos estes mecanismos são opcionais, de modo a haver compatibilidade com
o protocolo de transporte base (SMTP).
Referências
[1] http://www.openspf.org/Introduction
[2] http://www.microsoft.com/senderid
[3] http://www.dkim.org/
[4] Kyle Dent. Postfix: The Definitive Guide. O’Reilly Media, Inc., 1st edition, December 2003.
[5] Stallings William;Cryptography and Network Security, Prentice Hall, 2006.
[6] Comer, Douglas E. 2000. Internetworking with TCP/IP Vol.1: Principles, Protocols, and
Architecture. 4th ed. Prentice Hall.
autenticacao_email_v3.odt
Página 9 de 9
