Lourdes López, Eloy Portillo
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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<-).
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.
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.
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.
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.