Boletín de RedIRIS n. 32

Seguridad en redes telemáticas Parte II: Entornos seguros

Lourdes López, Eloy Portillo

Introducción

En la primera parte de este artículo titulada La problemática de la seguridadse vio cómo los organismos de normalización proponen dotar a las redes telemáticas de una serie de servicios de seguridad para protegerlas contra posibles ataques y operaciones ilegales. Estos servicios de seguridad se proporcionan a través de una serie de mecanismos de seguridad que se basan, en su mayoría, en técnicas criptográficas.

La cantidad y el tipo de servicios de seguridad que son necesarios en una red depende de las características de las aplicaciones que se desean proteger. Por lo tanto, no se puede hablar de redes seguras en general, sino de entornos seguros formados por una serie de sistemas integrados para la seguridad, que incluyen además de una serie de servicios de seguridad sobre varias aplicaciones, una gestión de claves global.

En esta segunda parte del artículo se va a presentar un resumen de las experimentaciones sobre varios sistemas seguros, en las que ha participado el Departamento de Ingeniería y Arquitecturas Telemáticas (DIATEL) de la EUIT de Telecomunicación de la UPM. Como se verá a continuación, estos sistemas permiten proporcionar servicios de seguridad sobre una o varias aplicaciones que realizan transferencia de información a través de redes y la mayoría de ellos utilizan en su base, criptografía de clave pública.

La necesidad de establecer un entorno seguro

En la actualidad, la falta de medidas de seguridad en las redes es un problema que está en crecimiento. Cada vez es mayor el número de atacantes y cada vez están más organizados, por lo que van adquiriendo día a día habilidades más especializadas que les permiten obtener mayores beneficios en su labor de piratería.

Tal y como se avanzaba en la primera parte de este articulo, la criptografía por sí sola no es suficiente para prevenir los posibles ataques que se perpetran sobre las redes, sino que es necesario establecer unos mecanismos más complejos que utilizan los distintos sistemas criptográficos en sus cimientos. Pero el problema no queda solucionado instalando en una serie de servidores herramientas de seguridad, porque ¿quién tendría acceso a esas herramientas?, ¿a qué aplicaciones se aplicarían?, ¿qué sucedería si sólo uno de los dos interlocutores en una comunicación tiene acceso a herramientas de seguridad?. Por lo tanto, cuando se habla de seguridad en redes es necesario definir el entorno en el que se va a aplicar.

La definición de un entorno seguro implica la necesidad de estudiar varios aspectos y de establecer una infraestructura que dé soporte a los servicios de seguridad que se quieren proporcionar. Lo primero que hay que establecer es qué aplicaciones necesitan seguridad y cuántos servicios se necesitan. En segundo lugar hay que determinar cómo se van a proporcionar esos servicios, si van a ser transparentes al usuario, si se le va a dejar elegir el tipo de servicio, etc. También es necesario determinar en qué nivel se van a proporcionar, si en el nivel de aplicación o en niveles inferiores. Y sobre todo, tanto si se utiliza criptografía de clave secreta, como si se utiliza criptografía de clave pública es necesario diseñar un sistema de gestión de claves y definir una política que determine la forma en la que se debe operar.

Cuando se utiliza únicamente criptografía de clave simétrica, aunque el sistema de generación de claves suele ser sencillo, ya que no se requiere una gran infraestructura para soportarlo, los mecanismos de distribución de las claves suelen ser muy complejos. En este caso, los principales parámetros que hay que tener en cuenta son el modo de difundir la clave secreta de forma segura a las dos entidades que van a utilizarla y la frecuencia con la que se deben renovar las claves para evitar que sean desveladas.

Cuando se utiliza criptografía de clave pública, el sistema de gestión de claves se complica. En primer lugar es necesario almacenar las claves públicas en un lugar al que tengan libre acceso todos los usuarios que forman parte del entorno de seguridad. ITU, en su recomendación X.509[1], propone la utilización del Directorio para este fin; pero no todos los usuarios de seguridad tienen acceso al Directorio X.500, por lo que en muchos entornos es necesario crear o utilizar otro tipo de bases de datos.

El segundo problema que se plantea al utilizar criptosistemas de clave pública, es que las claves públicas, por el simple hecho de ser públicas, están expuestas a la manipulación por parte de todos los usuarios, por lo que es necesario buscar un mecanismo que permita confiar en su validez. Siguiendo el ejemplo de los actuales sistemas legales, aparece la figura de una autoridad de confianza que se encarga de certificar las claves públicas. Estas autoridades, conocidas con el nombre de Autoridades de Certificación (CA "Certification Authority"), emiten certificados de las claves públicas de los usuarios firmando con su clave secreta un documento, válido por un período determinado de tiempo, que asocia el nombre distintivo de un usuario con su clave pública. En la recomendación X.509[1] se define en sintaxis ASN.1 el siguiente modelo de certificado:


     Certificate ::= SIGNED SEQUENCE{
	version			[0] Version DEFAULT 0,
	serialNumber		CertificateSerialNumber,
	signature		AlgorithmIdentifier,
	issuer			Name,
	validity		Validity,
	subject			Name,
	SubjectPublicInfo	SubjectPublicInfo,
	issuerUniqueId		[1] IMPLICIT BIT STRING OPTIONAL,
	SUBJECTUniqueId		[1] IMPLICIT BIT STRING OPTIONAL}
Además, para que los usuarios puedan estar seguros de la validez de los certificados de las claves pública de sus interlocutores, la CA debe mantener una lista con los certificados emitidos por ella y que han sido revocados por detección de un uso fraudulento de la clave pública certificada o de la clave secreta asociada. Estas listas se conocen con el nombre de Listas de Certificados Revocados (CRL, "Certificate Revocation List").

Cuando la comunidad de usuarios crece, una sola CA puede verse desbordada por el número de certificados que tiene que gestionar. En otros casos, las empresas o instituciones quieren tener cierto control sobre la manera en que sus usuarios generan las claves, la caducidad de los certificados, etc. Esto hace conveniente distribuir las funciones de certificación entre varias CAs, cuya política de seguridad puede ser diferente. En la recomendación X.509 [1]ya se prevé la necesidad de una organización de CAs donde se certifiquen unas a otras, sin indicar el tipo de relación organizativa que se debe establecer entre ellas. De esta forma, dependiendo de las necesidades de cada entorno han aparecido distintos modelos de organización de CAs.

Entorno seguro para la transferencia de información

Uno de los puntos más vulnerables de las redes frente a ataques de intrusos, es la captura de información durante su transferencia. Aunque cada sistema que forma parte de una red se proteja internamente a sí mismo y a la información que tiene almacenada, cuando la información se transfiere de un sistema a otro no se conoce a priori el encaminamiento que va a seguir ni las medidas de seguridad que poseen los sistemas por los que atraviesa y los medios por los que se transmite. Por este motivo la transferencia segura de información a través de las redes es en la actualidad, el principal problema que los investigadores intentan solucionar.

DIATEL ha estado trabajando en los últimos años en el proyecto de la UE, COST225 "Secure Communications", cuya coordinación en la última fase, ha sido llevada a cabo por uno de los miembros del grupo de seguridad del Departamento, que ha realizado la función de "chairman"[2].El objetivo de este proyecto, que ha concluido al inicio de 1995, ha sido el de estudiar y experimentar en varios entornos seguros en los que se realiza transferencia de información, como son el correo electrónico y la transferencia de ficheros a través de FTP y FTAM. Concretamente, en DIATEL se ha montado un entorno de seguridad que permite transferir información con distintos niveles de seguridad, a través de cualquier aplicación.

El desarrollo consta de dos partes fundamentales. La primera parte consiste en una aplicación, denominada SECKit[3], que permite a un usuario manejar distintas herramientas de seguridad con el fin de poder convertir a un fichero normal, en un fichero con un cierto nivel de seguridad. La aplicación SECKit que por su carácter experimental no incluye un interfaz de usuario amigable, presenta un único menú en el que aparece la lista de operaciones que permite realizar.

SECKit 3.0 (Imagen 1)

La segunda parte consiste en el desarrollo de un servidor de seguridad denominado SECServer[4]. Este servidor de seguridad no sólo oferta los servicios de una autoridad de certificación (generación de certificados de claves públicas), sino que además ofrece la posibilidad de generación de claves RSA para aquellos usuarios que no sean capaces de generarlas, y se encarga del almacenamiento y distribución de los certificados de los usuarios que lo soliciten. Las peticiones de servicios al SECServer se realizan a través de correo electrónico y el SECServer envía los certificados o las claves solicitadas a través de correo electrónico, FTP o FTAM.

En este entorno de seguridad los usuarios antes de transferir un fichero lo pueden transformar en un fichero firmado, en un fichero encriptado con DES o RSA, o en lo que en el entorno se denomina, un fichero seguro. Y cuando reciben un fichero firmado, encriptado o seguro, procedente de otro usuario, lo pueden transformar en el fichero original, verificando la validez de la información recibida.

Un fichero seguro es el resultado de combinar los mecanismos de seguridad de firma y encriptado con el fin de proporcionar los servicios de autenticación de origen y destino, integridad, confidencialidad y no repudio de origen.

Cuando un usuario A desea enviar un fichero seguro a un usuario B, debe seguir los siguientes pasos:

  1. A debe cifrar el fichero que quiere enviar a B. Para cifrarlo utilizará una clave simétrica K, generada en ese momento, y un algoritmo de cifrado DES.

  2. Para que B pueda descifrar el contenido del fichero necesita conocer la clave K empleada. A debe enviar a B la clave K de una forma segura. Para ello, A utilizará un algoritmo de cifrado asimétrico RSA y cifrará K con la clave pública de B. De esta forma se garantiza que el único destinatario que puede recibir el fichero original es B. Cuando B reciba el fichero seguro, deberá utilizar su clave secreta para obtener la clave K, de esta forma sólo B podrá conocer la clave de cifrado empleada, con lo que queda totalmente garantizada la confidencialidad del contenido del fichero.

  3. Para proporcionar el servicio de integridad y de autenticación del origen de los datos, A firmará el fichero original comprimiendo el contenido con una función hash y cifrando el resultado con su clave secreta. Cuando B reciba el fichero podrá verificar la firma comprobando así la integridad del mismo y autenticando al originador de los datos. Para verificar la firma, B deberá descifrarla utilizando la clave pública de A, obteniendo así el contenido del fichero comprimido. Si B obtiene la clave pública de A de su certificado, queda garantizado ante la CA que A es quien ha enviado el certificado. Una vez descifrado el fichero original, B puede comprimirlo con la función hash que se ha empleado en la firma, comparando el resultado con el obtenido de la firma, de forma que si ambos coinciden queda garantizado que el contenido del fichero original no ha sido manipulado durante su transferencia.

Fichero Seguro (Imagen 2)

El entorno diseñado en esta experimentación es un entorno muy abierto. Cualquier usuario de Internet que tenga correo electrónico puede acceder al SECServer para solicitar claves RSA o certificados. Si los usuarios del servidor tienen acceso al Directorio X.500[5], ellos mismos pueden guardar sus certificados en su entrada correspondiente y pueden recuperar los certificados de sus interlocutores. Los usuarios que tienen certificadas las claves publicas por la CA del entorno no necesitan obligatoriamente tener instalada la aplicación de usuario SECKit para realizar comunicaciones seguras; basta con que los usuarios tengan un traductor de sintaxis ASN.1 y una implementación de los algoritmos utilizados en el entorno.

COST 225. Entorno de Experimentación (Imagen 3)

En la última fase del proyecto COST 225, varias de las instituciones participantes, y entre ellas DIATEL, han centrado sus esfuerzos en plantear nuevos modelos en los que participan varias CAs[6]. Se han estudiado distintas arquitecturas de organización de las CAs y se han buscado soluciones para que los usuarios puedan conocer los caminos de certificación compuestos por los certificados que se deben examinar para que un usuario A tenga plena confianza en la validez de la clave pública de un usuario B.

Un experiencia de entornos seguros en el ámbito académico: Proyecto PASSWORD

El proyecto PASSWORD Piloting an European Security Infraestructure for Network Application financiado por la Unión Europea dentro del programa VALUE tenía como objetivo central el desarrollo de un entorno de seguridad apropiado para la comunidad investigadora europea. Se trataba de poner a prueba la madurez de las tecnologías empleadas en la provisión de servicios de seguridad en redes telemáticas en aspectos como la adecuación y completitud de los protocolos y herramientas criptográficas, adecuación del hardware disponible (tarjeta inteligente), aspectos ergonómicos, etc. [7]

Para probar la dificultad real de desarrollar independientemente sistemas que interoperen entre sí, se constituyeron tres consorcios. Cada uno de los consorcios desarrolló un sistema de seguridad completamente independiente a partir de cero, con los que luego se probarían distintas comunicaciones seguras. Cada consorcio estaba formado por instituciones de un país distinto de la Unión Europea y cada uno estaba liderado por una prestigiosa institución investigadora.

  • Gran Bretaña, (encabezaba el consorcio el University College de Londres)

  • Alemania (GMD), y

  • Francia (INRIA)

El diseño inicial incluye una infraestructura de gestión de claves basada en claves certificadas según X.509 y el aseguramiento de varias aplicaciones de uso común: Directorio X.500, documentos ofimáticos en formato ODA y correo electrónico, tanto X.400 (versión 88) como Internet PEM. Cada aplicación era modificada para hacer uso de los servicios de seguridad y todas ellas usaban una misma infraestructura de claves. El directorio cumplía una doble función de aplicación asegurada y colaborador de la infraestructura de certificados al ser la vía preferida para la distribución de estos.

DIATEL participó en el proyecto como institución piloto, instalando una DSA segura y dos Autoridades de Certificación con varios usuarios. Durante la experiencia se pudieron realizar varias comunicaciones seguras con los otros participantes en el proyecto. Las aplicaciones probadas fueron, correo Internet PEM y Directorio seguro X.500 utilizando autenticación fuerte en peticiones y respuestas. Para ello se utilizó el software público SecuDE 4.2 del GMD[8] e ISODE 8.0. En el transcurso del proyecto se contribuyó a depurar el software y afloraron algunas de las limitaciones de este modelo que se exponen más adelante.

El Correo PEM

PEM (Privacy Enhancement for Internet Electronic Mail) es el formato de correo seguro normalizado por Internet[9]. Incluye los servicios de autenticación fuerte de origen, integridad, no repudio en el origen y, opcionalmente, privacidad. Los tres primeros servicios se consiguen por medio de la firma digital tal y como se pudo ver en la primera entrega de este trabajo. Para implementar la confidencialidad se hace uso del algoritmo simétrico DES: para cada mensaje se utiliza una clave DES que llamaremos de sesión. Se cifra el mensaje con esta clave y a continuación se envía encriptada con la clave secreta del destinatario. De esta manera se garantiza que sólo el destinatario puede recuperar la clave de sesión y leer el mensaje.

En cualquiera de los casos (con o sin privacidad) tanto el mensaje como la firma y la clave de sesión se encapsulan en un formato imprimible (7 bits) que luego puede ser incluido en un mensaje RFC 822 o bien transmitido por cualquier otro medio. El formato de un correo PEM ya ha sido comentado con detalle en las páginas de este boletín[10]. En la actualidad se trabaja en la implementación de los mismos servicios al correo multicuerpo y multimedia MIME.

Jerarquía de certificación

Como se expuso anteriormente, la existencia de múltiples CAs obliga a establecer algún modelo organizativo entre ellas. Si la organización es jerárquica, los problemas de autoridad y consistencia se simplifican. Se llama camino de certificación al conjunto de certificados que se deben comprobar para llegar de un usuario A a otro usuario B. Cuando se adopta una estructura perfectamente piramidal, cada usuario necesita únicamente comprobar los certificados que de cada CA emite su superior hasta llegar a un punto de confianza común que en el peor de los casos será el vértice de la pirámide.

PASSWORD: JERARQUÍA ESTABLECIDA (Imagen 4)

En el proyecto PASSWORD se planteó inicialmente una arquitectura basada en una CA de máximo nivel (Top Level CA o TLCA) por país y una serie de Policy CAs en un segundo nivel. Dependiendo de cada Policy CA se extienden una serie de CAs cuyos usuarios deben cumplir la política de Seguridad establecida por esta Policy CA. De modo parecido, la comunidad Internet había establecido para su correo seguro PEM, una jerarquía similar donde todas las Policy CAs son certificadas "a efectos de registro" por una TLCA llamada Internet Policy Registration Authority IPRA[9]. La dificultad para usar simultáneamente ambas jerarquías, y el deseo de utilizar correo PEM hizo que finalmente se cambiaran las especificaciones y se adoptara una jerarquía PEM. Al no estar operativa la IPRA en el momento de las experiencias, se sustituyó por una TLCA creada al efecto que fue operada por el UCL.

Uno de los requisitos para el uso de los certificados de clave pública consiste en que se deben establecer mecanismos que eviten el mal uso de las claves, evitando así que se extienda la jerarquía más allá de sus límites naturales. Una CA no debe certificar usuarios fuera del ámbito para el que fue creada. Un usuario tampoco debe usar su clave pública para emitir un certificado. Para facilitar la detección de estas irregularidades, tanto la jerarquía inicialmente planteada en PASSWORD como la jerarquía PEM, establecen la "regla de subordinación" que indica que el Distinguished Name (DN) de una CA debe ser un subconjunto del DN del usuario que certifica, garantizando así que el usuario pertenece a la organización o unidad organizativa asociada con la CA. Por ejemplo, se detectaría inmediatamente que es fraudulento un certificado extendido por la CA <C=ES; O=Banca Hispano-Gibratareña; OU=Compras y Suministros> a favor de un usuario <C=ES; O=UPM; OU=Diatel; CN=Pérez>. Sólo las TLCAs y las Policy CAs quedan exentas del cumplimiento de esta regla.

Esta regla, aunque eficaz, se considera demasiado estricta y plantea problemas derivados, entre otras cosas, de la equivalencia que se hace del nombre de una organización o un departamento con su CA. Muchas veces, una organización puede necesitar varias CAs en el mismo lugar de su árbol organizativo, bien para implementar varias políticas con distintos grados de confianza, bien para separar usos diferenciados de las claves (comunicaciones internas frente a externas...). Para solucionar éste y algunos otros problemas detectados durante el proyecto PASSWORD, se han propuesto algunas medidas transitorias sobre maneras de organizar la certificación usando la norma X.509 versión 2 (véase [5]). Además toda la experiencia obtenida durante este proyecto y la prueba simultánea de los servicios PEM en la Internet está siendo de gran utilidad en el proceso de modificación del formato de certificado. Como resultado existe ya un borrador de X.509 versión 3 que incluye, entre otros, varios campos opcionales para distinguir varias claves públicas del mismo usuario, distintas políticas de seguridad y privilegios o acreditaciones asociados a la clave certificada.

Entornos seguros comerciales

Hoy en día existen ya algunos sistemas integrados de seguridad que van más allá de desarrollos experimentales y que se pueden obtener en el mercado informático. DIATEL ha realizado un estudio paralelo de tres de los sistemas comerciales más conocidos.

KERBEROS

Kerberos que era el perro de tres cabezas que, según la leyenda, guardaba la puerta de los infiernos, es ahora el encargado de la seguridad en el proyecto Athena.

En 1983, en colaboración con IBM y con Digital Equipment Corporation, el MIT emprendió el proyecto Athena, para poner a disposición de alumnos y profesores, medios informáticos avanzados basados en la arquitectura cliente-servidor[11]. Kerberos es, por lo tanto, el sistema de autenticación que usa el proyecto Athena.

El objetivos principal de Kerberos es el de proporcionar un sistema de autenticación entre clientes y servidores que evite que las passwords de los usuarios viajen continuamente por la red. El sistema se basa en una serie de intercambios cifrados, denominados "tickets" o vales, que permiten controlar el acceso desde las estaciones de trabajo a los servidores. Kerberos proporciona, asimismo, una serie de verificaciones criptográficas para garantizar que los datos transferidos entre estaciones y servidores no estén corrompidos, bien por accidente o bien por ataques intencionados.

La versión de Kerberos utilizada en el MIT utiliza el criptosistema simétrico DES, aunque en la actualidad se estén desarrollando versiones de Kerberos basadas en RSA.

ARQUITECTURA BÁSICA DE KERBEROS (Imagen 5)

En el entorno Kerberos cuando un usuario desea utilizar un determinado servicio, envía su "login" (1->) a un centro distribuidor de claves (KerAS), el cual genera un vale con el "login" del usuario, la hora, un período de validez, el nombre de la estación de trabajo y una clave de sesión. El vale se cifra con la clave secreta del centro servidor de claves, se añade de nuevo la clave de sesión y se cifra todo con la contraseña del usuario, y esta información se devuelve a la estación de trabajo (1<-). La estación de trabajo solicita al usuario su contraseña, la convierte en una clave DES, y con ella extrae el vale y la clave de sesión. A continuación, la estación de trabajo crea una credencial con la hora actual, el nombre del usuario y la dirección de la estación, la cifra con la clave de sesión y se la envía al centro de concesión de vales (KerTGS) junto con el vale que había recibido en el paso anterior (2->). En el centro de concesión de vales se descifra el vale y se extrae la clave de sesión que contenía, y se usa esta clave para descifrar la credencial. Se verifica la validez de los sellos de tiempo y la concordancia entre vale y credencial y se crea un nuevo vale con una nueva clave de sesión. El segundo vale se cifra con la clave secreta del servidor, se le añade la segunda clave de sesión y se cifra todo con la primera clave de sesión y el resultado se envía de vuelta al cliente (2<-). El cliente usa la primera clave de sesión para extraer el vale y la segunda clave de sesión, crea una nueva credencial y la cifra con la segunda clave de sesión, y envía la credencial cifrada y el vale al servidor (3->), el cual descifra el vale, descifra la credencial, los compara y si todo es correcto pasa a proporcionar el servicio solicitado (3<-).

SPX

Es la arquitectura de seguridad desarrollada por Digital E. C. y propuesta para su elección como estándar dentro de la iniciativa DCE del llamado "Grupo de Gibraltar"[12]. Usa claves asimétricas RSA certificadas según la norma X.509 combinadas con el uso de DES como algoritmo de cifrado con claves de sesión. Al igual que Kerberos dispone de un centro de autenticación ante el que se identifican los usuarios (LEAF: Login Enrollment Agent Facility). El otro componente básico es un Centro de Distribución de Certificados (CDC) que gestiona un repositorio con los certificados de las claves públicas de clientes y servidores.

El proceso de autenticación se basa en el uso inicial de una clave privada RSA por parte del usuario que se autentica, esta clave se sustituye por una clave temporal llamada clave de delegación disminuyendo la exposición de la clave privada del usuario.

El uso de una jerarquía de certificados de clave pública permite solucionar los problemas de escalabilidad que presenta Kerberos.

Pretty Good Privacy (PGP)

Pretty Good Privacy es un programa de libre distribución escrito por Phil Zimmermann, un programador independiente y activista de los derechos civiles, para poner la criptografía al alcance de cualquiera. Se ha extendido rápidamente por todo el mundo con el consiguiente disgusto del gobierno norteamericano, que como dijimos mantiene la política de limitar en lo posible la exportación de material criptográfico. De formato parecido a PEM, coinciden fundamentalmente en que están concebidos como 'filtros' que producen, a partir de una entrada cualquiera, un encapsulado seguro que se codifica en un formato imprimible (ASCII 7 bits). Este resultado puede luego incluirse en un correo electrónico, puede ser transferido como un fichero, enviado en disquete, etc.

Al contrario que PEM usa claves de sesión IDEA, un algoritmo simétrico, esto es, de claves secretas, mucho más sólido que DES. La clave de sesión se protege igualmente con un cifrado RSA usando la clave pública del destinatario.

Para la distribución de claves se ha diseñado un sencillo formato de certificado, no compatible con X.509, que sirve tanto para que una autoridad certifique claves ajenas (desempeñando el papel de CA) como para que un usuario certifique sus propias claves. Queda así al arbitrio del usuario el establecer sus propios criterios para confiar o no en las claves ajenas según los certificados que la avalen. En definitiva, cada cual es responsable de fijar su política de seguridad. En la practica se establecen caminos de confianza muy fáciles de extender que recuerdan la rapidez con que se extendieron en tiempos las rutas de correo sobre protocolo UUCP. Al igual que el UUCP, plantea problemas parecidos de escalabilidad si no se establecen autoridades de certificación y servidores de claves.

Con sus inconvenientes y sus ventajas, entre las que destaca su facilidad de uso, la gran difusión de PGP ha hecho de él un estándar de facto para correo. En la actualidad diferentes grupos trabajan en el desarrollo de herramientas que faciliten de alguna manera el acceso simultáneo tanto al mundo PEM como al de PGP.

Entorno seguro para intercambio electrónico de mensajes EDI y mensajería electrónica X.400

En la actualidad DIATEL se encuentra trabajando en el proyecto EDISE. EDISE es el acrónimo de un proyecto de seguridad cuyo título completo es "Desarrollo de funciones y servicios de seguridad según las normativas X.400 y X.509 y su integración en entornos EDI". En este proyecto, que forma parte del programa PASO, colaboran junto con DIATEL la Universidad Carlos III, las empresas P3K y el CCS, el Ministerio del Interior y el CSIC.

Los objetivos principales de este proyecto consisten en dotar de servicios de seguridad a un servicio EDI que utiliza sintaxis EDIFACT y en incluir servicios de seguridad en correo electrónico X.400, con el fin de integrar los resultados obtenidos para proporcionar el servicio EDI sobre MTAs X.400, conforme a la norma X.435.

Un intercambio EDIFACT está formado por uno o varios mensajes que llevan una serie de cabeceras y colas con información específica. Los servicios de seguridad, integridad de secuencia de mensaje, integridad de contenido del mensaje, autenticación del origen del mensaje y no repudio de origen pueden estar integrados en el mensaje o se pueden proporcionar en un mensaje separado[14].

Todos los servicios mencionados se pueden proporcionar incluyendo cabeceras y colas de seguridad, después de la cabecera de mensaje y antes de la cola de mensaje, respectivamente. Las cabeceras de seguridad especifican los métodos de seguridad asociados al mensaje, y los datos necesarios para poder realizar los cálculos de validación (identificación de algoritmos, certificados, etc). Las colas de seguridad especifican los resultados de seguridad correspondientes a las funciones especificadas en la cabecera. La cabecera y cola de seguridad se repiten por cada conjunto de servicios y originador.

Los servicios de seguridad se pueden proporcionar también, utilizando un mensaje de seguridad asociado, denominado AUTACK. Este mensaje específico proporciona los servicios de seguridad para uno o más mensajes. También se puede utilizar para proporcionar el servicio de no repudio en destino, dando al emisor un reconocimiento seguro de que el receptor ha recibido el mensaje original, sin tener que retornarlo.

El servicio de confidencialidad se proporciona utilizando un nuevo tipo de mensaje llamado CIPHER.

Conclusiones

Una vez extendidas las redes, no cabe duda de que en algunas aplicaciones telemáticas resulta imprescindible incorporar servicios de seguridad para que cubran los objetivos para los que fueron previstas. En aplicaciones de nuevo desarrollo sería conveniente que se tengan en cuenta los requerimientos de seguridad antes de su implantación.

En la actualidad la tecnología existente permite incluir seguridad en las aplicaciones con unos costes razonables. Los interfaces de usuario deben ser suficientemente amigables para conseguir que los servicios de seguridad añadidos dificulten lo menos posible el manejo de las aplicaciones.

Referencias

  1. "Inf. Tech.-OSI. The Directory-Authentication Framework", ITU X.509, ISO/IEC IS 9594-8, Dic. 1991.

  2. "COST225 Secure Communications Final Report", J. Carracedo, A. Gómez (Editors), COST Telecommunications Secretariat, Brussels March 1995.

  3. "A toolkit to provide the users with security functions to send and to receive secure information", A. Gómez, J. Carracedo, L. López, Proceedings of the COST225 International Workshop Secure Applications with Public Key Certification, Stockholm Feb. 1994.

  4. "Provisión de servicios de autenticación, integridad y confidencialidad en la transferencia de ficheros", J. Carracedo, A. Gómez, L. López, URSI 93, Valencia Sep. 1993.

  5. "Almacenamiento de Certificados en el Directorio X.500", L. López, E. Portillo, J. Carracedo, URSI 94, Las Palmas Sep. 1994.

  6. "Proposal of CAs infrastructure in the framework of the COST225 Project", L. López, J. Carracedo, COST Document 225TD(95)002, Brussels Feb. 1995.

  7. "PASSWORD R1.1: Service Requirements", M. Roe. et al. agosto 1992.

  8. "SecuDE: Vol. 3: Security Applications Guide. Ver. 4.3". W. Schneider (editor). GMD Darmstadt, Alemania May. 1994.

  9. "Privacy Enhancement for Internet Electronic Mail (PEM)". Internet RFCs 1421-1424. Feb. 1993.

  10. "Seguridad en el correo electrónico: Proyecto P8 de COSINE". F. Jordán, M. Medina y E. Peig. Boletín de RedIRIS num. 22. Marzo 1993.

  11. "Kerberos: An Authentication Service for Open Network Systems". J. Steiner, C. Neuman, J. Schiller.

  12. "SPX. Global Authentication Using Public Key Certificates". J. Tardo, K. Apagappan, Digital E. C.

  13. "PGP User's Guide". P. Zimmermann. Mayo 1994.

  14. "Recommendations for UN/EDIFACT message level security from the UN/EDIFACT Security JWG", Dic. 1993.

Lourdes López
Eloy Portillo
Profesores de DIATEL
EUIT de Telecomunicación de la UPM
dirección de correo lourdes [dot] lopez [at] diatel.upm.es
dirección de correo eloy [dot] portillo [at] diatel.upm.es