Introducción
El correo electrónico
(correo-e) es una herramienta de uso generalizado en
la actualidad. Su funcionamiento ha quedado normado
por estándares como X.822, X.400, SMTP y MIME, los
cuales facilitan, la interacción pero contemplan tan
solo elementos básicos de privacidad y ninguno de
protección contra intrusos. Es por esto último que
se han considerado diversas medidas de seguridad
para mantener privacidad e integridad y garantizar
autenticidad en el correo-e.
Cualquier herramienta para
correo-e seguro ha de tener tres características: Ha
de ser surtido por varios vendedores o
productores, ha de ser interoperable y ha de
ser aprobado o avalado por las entidades
estandarizadoras de Internet. Entre los rasgos
que ha de mantener está la privacidad, es
decir, el encriptamiento de datos, la
autentificación, que conlleva la integridad de
los mensajes, y el manejo de llaves.
En el correo-e, el
encriptamiento se hace por lo general con métodos de
llave pública y la revisión de integridad mediante
firmas electrónicas y funciones de dispersión para
construir compendios a la manera de sumas de prueba.
El manejo de llaves se trata,
por lo general, mediante autoridades certificadoras
de llaves públicas, las cuales son expendedoras de
certificados. En el intercambio de mensajes, los
certificados quedan en función de las llaves
públicas de los usuarios y de otros factores tales
como “estampas de tiempo”, o “huellas digitales'”
(es decir, de valores de funciones de dispersión
dependientes de llaves, señas de identidad de los
usuarios, servidores de correo-e, etc.).
Arquitectura y Servicios
Los sistemas de correo-e se
integran de dos subsistemas: el agente usuario,
coloca los mensajes en la cola del correo-e; y él
agente transferencia de mensajes, es el responsable
de inicializar el enlace de comunicación con las
computadoras remotas y transmitir el correo-e. La
aplicación del agente usuario son los programas
locales que ofrecen una interacción con el sistema
de correo-e sobre la base de línea de comando,
basados en menús o con una interfase gráfica. Los
agentes transferencia de mensajes son usualmente los
demonios (procesos) del sistema operativo, y mueven
el correo-e a través del sistema o de la red. Un
sistema de correo-e soporta cinco funciones básicas:
composición, transferencia, reporte, despliegue y
disposición.
Además, a estos servicios
básicos, la mayoría de los sistemas correo-e
ofrecen una amplia variedad de características
avanzadas para administrar los mensajes del usuario.
Un servicio muy usado en el correo-e son las listas
de interés, las cuales permiten con sólo enviar un
mensaje a la lista de correo-e en particular,
repartir una copia idéntica del mensaje a todos los
subscriptores de la lista, lo que evita la necesidad
de enviar un correo-e a cada uno de ellos.
Una idea clave en todos los
sistemas modernos de correo-e es la distinción
entre el sobre y su contenido. El sobre envuelve el
mensaje. Este contiene toda la información necesaria
para transportar el mensaje, tales como la dirección
destino, prioridad y nivel de seguridad, lo anterior
es distinta del mensaje por sí mismo. El agente
transporte usa el sobre para el enrutamiento del
mensaje.
Formatos de los mensajes
El RFC 822 define un mensaje
que se integra de dos partes: un encabezado y un
cuerpo. El encabezado consiste de una serie de
nombres de campo, después del cual hay una línea en
blanco que marca el fin del encabezado y el
principio del cuerpo, el cual consiste de sólo texto
US ASCII (RFC 822). El encabezado contiene
información de control para el agente usuario. El
cuerpo del mensaje contiene el mensaje a recibir.
Para transmitir datos no ASCII
a través del correo-e, el IETF definió el formato
MIME (Multipurpose Internet Mail Extensions). MIME,
que permite que datos arbitrarios sean codificados
en ASCII y poder ser transmitidos en un mensaje de
correo-e normal. Para acomodar los tipos de datos
arbitrarios, cada mensaje MIME incluye información
que le dice al recipiente receptor el tipo de dato y
la codificación usada. La información de MIME reside
en el encabezado del mensaje según el RFC 822 – en
el encabezado MIME se especifica la versión de MIME
usada, el tipo de dato que esta siendo enviada y la
codificación usada para convertirlo los datos en
ASCII. En el formato MIME, existen siete tipos de
datos: texto, imagen, audio, vídeo, mensaje,
multiparte y aplicación.
SMTP
En adición a los formatos de
los mensajes, el protocolo TCP/IP especifica un
estándar para el intercambio de correo-e entre
computadoras. Esto es, la norma define el formato
exacto de los mensajes de correo-e a transferir de
un servidor a otro. El protocolo para transferencia
de mensajes es conocido con el nombre de SMTP,
Simple Mail Transfer Protocol.
SMTP define sus reglas para
transmitir el correo-e entre computadoras. El
protocolo tiene dos funciones: emisor y receptor. El
emisor establece una conexión TCP con el receptor,
usando el puerto 25. Durante una sesión SMTP el
emisor y el receptor intercambian una secuencia de
comandos y respuestas. Primero, identifican los
nombres de dominio de las computadoras. Después, el
emisor ejecuta una transacción de correo-e por la
secuencia siguiente: identifica el origen del
mensaje, identifica los recipientes de correo-e,
transmite el mensaje y transmite un código que
indica que el mensaje esta completo. Al final de la
transacción, el emisor puede: iniciar otra
transacción, invierte las funciones y se vuelve
receptor, termina y cierra la conexión.
Protocolos
Los servicios de seguridad
pueden ser agregados a cada enlace de comunicación a
lo largo de una trayectoria dada, o pueden ser
integrados alrededor de los datos que están siendo
enviados, siendo esto independiente de los
mecanismos de comunicación. Este enfoque avanzado es
frecuentemente llamado seguridad “nodo-a-nodo” (end-to-end).
Las dos características de este
tipo de seguridad son privacidad (donde el
recipiente deseado sólo puede leer el mensaje) y la
autentificación (en el otro caso, recipiente puede
asegurar la identidad del emisor). La capacidad
técnica de estas funciones es bien conocida desde
hace tiempo, sin embargo, recientemente ha sido sólo
aplicada al correo-e de Internet.
Es usual que se cuente con un
mecanismo de autentificación de quién origina el
mensaje y privacidad para los datos. Además, de
proveer un esquema de recepción firmada desde el
recipiente. En núcleo de estás capacidades en el uso
de la tecnología de llave pública y el uso a gran
escala de llaves públicas, lo que requiere un método
de certificación que dada una llave pertenece a un
usuario dado.
Aunque, se ofrecen servicios
parecidos al usuario final, los dos protocolos
tienen formatos distintos. Adicionalmente, y esto es
importante a los usuarios corporativos, en este caso
se cuenta con diversos formatos para los
certificados. Lo que significa, que no sólo los
usuarios no pueden comunicarse con los que usen
otro, además, no pueden compartir los certificados
de autenticación. La diferencia entre los dos
protocolos es parecida a la diferencia entre los
formatos GIF y JPEG, siendo que hacen las mismas
cosas, más no su formato entre ellos.
Existen dos propuestas
principales para ofrecer los servicios de seguridad
que hemos mencionado: S/MIME y PGP. Otros protocolos
han sido propuestos en el pasado como son PEM y MOSS,
no han tenido mayor presencia. Sin embargo, ahora
diversos proveedores de servidores de correo-e,
incluyen en sus productos a S/MIME, PGP/MIME y
OpenPGP.
PGP
PGP se ha vuelto una
herramienta convencional para el correo-e seguro. En
sus inicios, PGP utilizaba RSA para las firmas e
IDEA para encriptar. IDEA es un cifrador iterativo
(de 8 vueltas) que procede por bloques de 64 bits
con llaves de 128 bits, inmune a criptoanálisis de
tipo diferencial. En su especificación estándar, a
PGP se le han incorporado CAST y triple-DES para el
encriptamiento de mensajes ``en bulto'', RSA y DSA
para firmas electrónicas y MD5, RIPEMD-160, y SHA-1
para el cálculo de compendios de mensajes. La
compatibilidad con el correo-e se hace mediante una
conversión de tipo Radix-64. En cuanto a la
certificación de llaves, PGP se basa en una,
digamos, ``maraña de confianza''. Los certificados
de llaves en PGP contienen dos atributos
suplementarios: Confianza y validez. Localmente, la
colección de certificados comienza con la propia del
usuario. El usuario firma certificados de sus
corresponsales y éstos los de él mismo. El usuario
otorga grados de confianza a cada uno de sus
corresponsales. Cuando el usuario recibe mensajes
con un certificado de otras personas, éste se
considera válido si los certificantes quedan
conectados con el usuario en la maraña de confianza.
La revisión de conectividad se hace bien de manera
directa o bien mediante servidores de llaves, que
son bodegas de certificados PGP.
PEM
PEM (Privacy Enhanced Mail), es
un estándar oficial de Internet el cual se describe
con cuatro RFCs: 1421 al 1424. PEM cubre el mismo
territorio que PGP: privacidad y autentificación
para sistemas de correo basados en el RFC 822. Sin
embargo, presenta algunas diferencias en enfoque y
tecnología. Los mensajes enviados usando PEM son
inicialmente convertidos a una forma normalizada, de
tal manera que tengan las mismas características
sobre el uso de un espacio en blanco, tabuladores, y
el uso de retornos de carro y avances de línea. Esta
transformación se realiza para eliminar los efectos
sobre el agente emisor que transfiere el mensaje
evitando que lo modifique o presente tendencia a
modificarlo. Sin la normalización, tales
modificaciones podrían afectar el mensaje desde que
sale hasta que llega a su destinatario.
Un compendio de mensaje (hash)
es calculado usando MD2 o MD5, lo cual no es
opcional como en PGP. Por lo que la concatenación de
la función de dispersión y el mensaje son
encriptados usando DES. Conociendo la debilidad de
la llave de 56 bits, esta elección no es
conveniente. El mensaje encriptado puede ser
codificado usando Radix-64 y transmitido al
recipiente.
En PGP, el mensaje es
encriptado con una llave, al mismo tiempo que
protege al mensaje. Esta llave puede ser protegida
ya sea con RSA o con triple DES usando EDE. En la
práctica, todos usan RSA, y de esta forma PEM no nos
dice como se administra la llave con DES.
S/MIME
S/MIME fue desarrollado por RSA
Data Security, Inc. Se establece en el formato PKCS
#7 para los mensajes, y en el formato X.509V.3 para
los certificados. PKCS #7 se basa en el formato ASN.1
DER para datos.
S/MIME es una extensión del
estándar MIME de Internet. S/MIME es un estándar
``de hecho'' propulsado por RSA Data Security pero
debe contar aún con el visto bueno del IETF. Además,
de las partes convencionales de los mensajes
electrónicos (encabezado y cuerpo), el formato MIME
permite estructurar al cuerpo de un mensaje para
incluir archivos no meramente de texto. S/MIME
incorpora servicios de firmas electrónicas y de
encriptamiento a MIME y se ajusta al PKCS de RSA #7.
S/MIME puede utilizar dos
procedimientos para firmas digitales:
El “firmado limpio'' (clear
signed) es preferible cuando sé interactúa con
clientes que no son S/MIME, ya que la firma se
coloca como un anexo-MIME, codificado en Base64
llamado “smime.p7s”, fuera del texto (abierto) del
mensaje. Sin embargo, algunos “gateways” de correo-e
pueden recodificar los anexos MIME alterando en
consecuencia el contenido del mensaje.
El “firmado opaco” (opaque
signing) busca evitar los problemas del formateo en
tránsito que realizan algunos “gateways”. Un mensaje
se codifica a la MIME, en Base-64, en un solo anexo.
El problema es que el mensaje será ilegible para
usuarios que no utilicen S/MIME.
PGP/MIME, toma como base a PGP,
el cual se había desarrollado por diversos
investigadores, algunos de los cuales formaron a la
compañía PGP, Inc. Los formatos tanto para mensajes
como para certificados, fueron creados de
improvisar y usar una simple codificación binaria.
OpenPGP se funda en PGP.
S/MIME, PGP/MIME, y OpenPGP
usan MIME para estructurar sus mensajes. Los
esquemas antes mencionados tienen confianza en el
tipo MIME multipart/signed, el cual se describe en
el RFC 1847 para mover mensajes firmados sobre
Internet. Un cliente de correo-e puede
razonablemente aceptar y enviar ambos formatos.
S/MIME es un protocolo nuevo,
con una versión inicial desarrollada por un
consorcio privado de compañías. S/MIME ha conseguido
amplia adopción en la industria de correo-e de
Internet. La mayoría ha creado sus programas de
correo-e usando varios drafts del protocolo S/MIME
v.2 que han estado circulando en el IETF. Las partes
del protocolo son:
S/MIME Versión 2 Message
Specification (RFC 2311)
S/MIME Version 2 Certificate
Handling (RFC 2312)
PKCS #1: RSA Encryption Version
1.5 (RFC 2313)
PKCS #10: Certification Request
Syntax Version 1.5 (RFC 2314)
PKCS #7: Cryptographic Message
Syntax Version 1.5 (RFC 2315)
Description of the RC2 Encryption
Algorithm (RFC 2268)
Estos RFCs, tienen el carácter de
informativos. Es
importante notar que S/MIME V.2 no es un estándar
del IETF. S/MIME requiere el uso de una llave de
intercambio RSA, lo que es gravado por las patentes
americanas influenciado por RSA Data Security, Inc.
, lo que favorece que la versión 2 de S/MIME
requiera el uso de criptografía débil (llaves de
bits).
Algunos productos basados en
S/MIME son los siguientes:
Microsoft's Outlook Express
(es parte del Internet Explorer 4.01).
Netscape's Messenger (Communicator
4.04)
OpenSoft Corp.'s ExpressMail
2.5 es un “cliente” para correo de Internet.
Baltimore Technologies'
MailSecure
Worldtalk Corp.'s WorldSecure
Client 2.2
los
dos últimos requieren de clientes de correo-e ya
existentes, tales como Exchange y Outlook de
Microsoft, o Eudora Pro de QUALCOMM.
No hay completa
interoperabilidad entre ellos: No decodifican
mensajes encriptados por los demás, utilizan
distintas estrategias de certificación e incluso
utilizan distintos códigos de S/MIME.
Expedición de certificados
Los certificados, además de
convalidar la identidad de la persona certificada,
pueden proporcionar información sobre ella y
otorgarle ciertos privilegios en transacciones. La
certificación se basa en llaves públicas.
Las autoridades certificadoras
(AC's) han de sujetarse a ciertos estándares, por
ejemplo a la recomendación X.509 de 1988 de CCITT
(actualmente UIT), o al RFC1422 de IMC. El
almacenamiento de certificadores se hace siguiendo
LDAP. Entre los requerimientos con los que ha de
contar una CA están los siguientes:
Una base de datos para el
almacenamiento de llaves públicas,
Un procedimiento de
encriptamiento para la generación de certificados, y
Un procedimiento PKI para
revisar la vigencia de los certificados.
Usualmente, una CA codifica con
su propia llave la llave pública del cliente que
pide la certificación, y también, mediante una
función de dispersión, genera en base a la llave
pública del cliente una “huella digital”. El cliente
ha de concatenar el certificado y su huella digital
a cualquier mensaje suyo. Con fines de “no-repudio”
un corresponsal puede pedirle que encripte todo esto
con su propia llave privada.
PGP apareció y se generalizó
en su uso mucho antes de que apareciesen autoridades
certificadoras (AC). PGP hace de cada usuario una
AC. A grandes rasgos, su procedimiento de
certificación es el siguiente:
Si un usuario Fulano reconoce
como válida a la llave de otro usuario Zutano,
entonces puede Fulano firmar el certificado de
Zutano. Cualquier otro usuario que confíe en la
llave de Fulano, ha de confiar en la de Zutano. Se
desarrolla así una maraña de confianza (web trust).
Aparecen, naturalmente, dos
problemas: un nodo que otorgue firmas a llaves
apócrifas afecta a toda la comunidad. Cada usuario
ha de realizar complejas tareas administrativas
sobre la maraña de confianza. En vez de relegar su
confianza en un nodo inmediato, ha de confiar en
varios nodos.
Alternativamente, los usuarios
pueden otorgar una cierta confianza fraccional o
parcial, y estos valores han de propagarse
adecuadamente por transitividad.
Los usuarios de PGP transmiten
sus certificados de llaves públicas para ser
firmados. Los usuarios de S/MIME solicitan sus
validaciones ya sea por correo-e o por la WWW,
utilizando siempre el formato de PKCS #10. En un
ambiente jerárquico, PGP utiliza su Servidor de
Certificados: El Servidor de Certificados
Corporativo sé preconfigura en el ambiente de
trabajo del cliente y todo nuevo certificado se
carga usando LDAP.
Al recibir un mensaje firmado
con una firma no certificada, con PGP es necesario
buscar manualmente el certificado de esa firma.
Obviamente, es deseable que esto se haga
automáticamente. S/MIME, en cambio, añade un
certificado de llave pública a todo mensaje firmado.
SSL y TLS
El
protocolo de seguridad en Internet para las
conexiones punto a punto es SSL (Secure Sockets
Layer). SSL fue diseñado para resolver este
problema en un estándar abierto, Protegiendo contra
intromisión, manipulación sin autorización y
falsificación. Los servidores y clientes tienen la
capacidad de autentificación de uno con el otro y
establecer un enlace seguro (“pipe”) a través de
Internet o de Intranets, protegiendo la información
transmitida.
SSL
es similar a una llamada telefónica segura entre dos
computadoras en cualquier red de datos incluyendo a
Internet. Con este protocolo, una conexión se
establece, las partes son autentificadas y los datos
se intercambian en forma segura. La ultima extensión
de SSL es conocida con el nombre de Transport Layer
Security (TLS).
En
aplicaciones que utilizan SSL, la confiabialidad de
la información se garantiza usando tecnologías
robustas de encriptación. A través del uso de
certificados digitales, el protocolo realiza en
forma transparente la autenficación de servidores,
opcionalmente la de clientes. SSL usa el algoritmo
RSA para activar el esquema de seguridad usando
firmas digitales y envoltura (ensobretado) digital.
Para efectuar una encriptación y desencriptación
rápida, después de que una conexión ha sido
establecida, el algoritmo RC4 es la opción
preferida. Existen otros algoritmos disponibles en
la especificación de SSL.
Dado que la fuerza de SSL se
basa en un esquema robusto de criptografía, el
usuario final tiene confianza que su información es
confidencial, autentificada, y original durante una
conexión de red.
Conclusiones
Conforme la presencia de Internet y sus servicios se
vuelve más preponderante en nuestras vidas, hemos
visto como se incrementa su mal uso, sobre todo del
correo-e. Por lo que resulta importante contar con
mecanismos para asegurar que la información que se
transmita sobre Internet y otras redes sea altamente
confiable.
El uso de correo-e seguro, ya
tiene presencia en áreas como: la financiera, la
gubernamental, la corporativa, la educativa, por
citar sólo
algunas. Sin embargo, sé esta observando que debido
a que cada proveedor de software entiende y
desarrolla los algoritmos a su manera, además de las
soluciones propietarias, para integrar mecanismos de
seguridad en los servidores de correo, es necesaria
una mayor difusión
de los estándares en el uso e implementación de
estas herramientas. Se
ha propiciado la generación de entes aisladas entre
sí, razón por la cual el uso de esquemas de
seguridad en el correo-e no se ha extendido
ampliamente. Es importante considerar la
interoperabilidad de los diversos productos
comerciales existentes que administran el correo,
sin olvidar una seguridad robusta, y cuya
consecuencia principal será obtener un servicio de
comunicación electrónica altamente confiable.
Bibliografía
[RS] Rose, M. T., Strom, D.,
Secure e-mail: Problems, standards and prospects,
Internet Protocol Journal, CISCO, No. 1, 1999.
[LM91] Lai, X., Massey, J.L., A
proposal for a new block encryption standard. In
Advances in Cryptology Eurocrypt ’90, pp.
389-404, Springer-Verlag, 1991.
[Co] Comer, Douglas E.,
Internetworking with TCP/IP, Volume I, Principles,
Protocols and Architecture, Prentice-Hall, 3rd
edition, 1995.
[LR] Lynch, Daniel C., Rose,
Marshall T., Internet System Handbook,
Addison Wesley, 1993.
[T]
Tanenbaum, Andrew, Computer Networks, 3rd
edition, Prentice-Hall, 1996.
Acrónimos
Software
Gratis
