Experiencia piloto de certificación en la Universidad de Murcia

El número de usuarios de Internet (y en general, de todas las redes) ha experimentado en los últimos años un increíble aumento, debido en parte a la mejora de los servicios y al abaratamiento de los costes. Este hecho ha sido aprovechado por el mundo empresarial, que está utilizando cada vez más Internet como medio de difusión para dar a conocer sus productos y ofrecer sus servicios. Es el denominado comercio electrónico.

Sin embargo, este fenómeno ha puesto al descubierto una de las mayores deficiencias de Internet: su seguridad. Los protocolos sobre los que se ha construido esta red (TCP/IP) no ofrecen ningún tipo de seguridad; un paquete viaja por varias redes hasta alcanzar su destino y es fácil leerlo (o incluso modificarlo) en cualquiera de ellas, lo cual es un problema cuando la información que se transmite es especialmente sensible: datos personales, número de tarjeta de crédito, etc.

Todo esto es aplicable a una universidad, pues aunque su función no es lucrativa, si que va necesitar transmitir información sensible en aplicaciones como consulta de expedientes, automatrícula, gestión económica, etc., requiriendo, por tanto, de los mismos mecanismos de seguridad que el comercio electrónico.

Reconociendo este problema, la Universidad de Murcia ha puesto en marcha un proyecto para dotar a sus miembros de los mecanismos básicos de seguridad: autenticación, integridad y confidencialidad, tanto en conexiones web como en comunicaciones mediante correo electrónico.

El marco en el cual se define este proyecto viene determinado por la existencia de aulas de ordenadores de libre acceso (conectadas a la red Internet) y también los distintos ordenadores personales de profesores y personal de administración y servicios.

La solución que hemos desarrollado consiste en implantar una infraestructura de certificación. Dicha infraestructura se basa en la criptografía asimétrica según la cual cada usuario posee dos claves: una pública y otra privada. La clave pública, junto a otra información, forma el certificado [1], [2] que es un documento digital que identifica a la persona.

2.- Creación de una infraestructura de clave pública

El primer paso para crear una infraestructura de clave pública es definir los elementos que la forman. De acuerdo al RFC 1422 [3], deberá existir una (o varias) Autoridades de Certificación (CA) que generen y revoquen los certificados de los usuarios. En nuestro caso existe una única CA que firma todos los certificados de la Universidad de Murcia.

Los procedimientos que esta CA debe seguir para generar y revocar los certificados están recogidos en un documento denominado política de certificación. Nuestra política de certificación (al igual que la del RFC 1875[4]) especifica que existirán unas entidades llamadas Autoridades de Registro (RA) que actuarán como punto intermedio entre la CA y los usuarios finales. Serán las encargadas de verificar la identidad de los usuarios, así como de enviar sus solicitudes a la CA. Estas RAs se sitúan en las secretarías de las facultades y otros puntos de atención. El usuario acude a ellas con el DNI para probar su identidad. En este momento se genera su solicitud de certificado, así como su clave privada. La RA (secretaría) recoge la solicitud y se encarga de hacerla llegar a la CA. La CA es, en realidad, una máquina off-line que cada cierto tiempo recoge las solicitudes de las distintas RAs y las firma, generando los certificados. El procedimiento se muestra en la figura 1.

Una vez se han definido los mecanismos de generación de certificados y claves privadas para toda la comunidad universitaria y teniendo en cuenta el número de miembros que la componen (aproximadamente 40.000, entre alumnos, personal docente y personal de administración y servicios), se plantea como un punto importante dentro del desarrollo de la infraestructura de certificación la utilización de sistemas de almacenamiento adecuados tanto para los certificados como para las claves privadas.

Para los certificados, dado su carácter público, se ha optado por el uso del servidor X.500 de la propia Universidad, que contiene la información básica de los miembros de la comunidad universitaria, esto es, nombre, correo electrónico, titulación a la que pertenece (si es alumno) o cargo desempeñado (si es personal de la propia Universidad), etc. De este modo, los navegadores pueden buscar y recuperar el certificado de cualquier entidad empleando el protocolo LDAP (Ligthweight Directory Access Protocol) [5].

En lo que respecta a las claves privadas, el almacenamiento debe realizarse de forma que sólo su propietario pueda utilizarla. En nuestro caso, se decidió el uso de tarjetas inteligentes ya que sobre ellas el usuario tiene un control físico basado en su posesión, y un control funcional aportado por el conocimiento de un PIN o número de identificación personal. Dichas tarjetas inteligentes son multiaplicación, y disponen, dentro de su arquitectura, de un campo de datos (conocido como fichero elemental o EF) dedicado a almacenar la información de seguridad que se considere oportuna. El planteamiento ideal pasaría por almacenar en dicho campo la clave privada completa, con lo que se consigue que cada usuario tenga en su propia tarjeta la información secreta que necesita para realizar comunicaciones seguras. Esto implica unas necesidades de espacio en la tarjeta que estarán disponibles en las nuevas tarjetas que se harán llegar el próximo curso académico a los miembros de la comunidad universitaria.

Sin embargo, dado que en las tarjetas repartidas actualmente el campo de datos (que sólo cuenta en la actualidad con 16 bytes) tiene menor tamaño que la clave privada, se ha optado por un esquema en el que la propia Universidad es la que almacena en una de sus bases de datos las claves privadas, las cuales no se van a encontrar en "claro", sino cifradas por una clave simétrica IDEA que se guardará en el campo de la tarjeta al que antes hacíamos referencia. Sólo el propietario de la tarjeta, que conoce su PIN, tiene la posibilidad de recuperar la clave simétrica que permite descifrar su clave privada.

3.- Servicios de seguridad en la Universidad

Una vez definidos los elementos que forman nuestra arquitectura, pasamos a describir los servicios de seguridad sobre los que se va a aplicar.

3.1.- Seguridad en Web

Uno de los servicios más importantes es el del Web. Se han propuesto diversas soluciones para realizar comunicaciones seguras sobre este servicio: S-HTTP (Secure HTTP), SET[13] (Secure Electronic Transactions) y SSL [6] (Secure Socket Layer). Nos decidimos por esta última ya que se ha convertido en el estándar de hecho y es soportado por una gran cantidad de navegadores y servidores Web. SSL es un protocolo abierto, propuesto por Netscape. Trabaja entre el nivel de transporte y el nivel de aplicación (figura 2), siendo independiente del nivel superior. Su objetivo es proporcionar una comunicación segura entre cliente y servidor, ofreciendo los siguientes servicios: confidencialidad, autenticación e integridad de los mensajes. Para conseguir estos objetivos SSL utiliza técnicas de criptografía de clave pública o asimétrica junto con criptografía de clave privada o simétrica que cliente y servidor negocian en el momento de la conexión, permitiendo al protocolo incorporar nuevos algoritmos de encriptación o respetar cuestiones legales relativas a la exportación y uso de éstos.

Para intercambio de claves SSL utiliza los certificados X.509[1] que, además de la clave pública, contiene información personal del propietario a través de los nombres distinguidos (DN) de X.500 como: su nombre, correo electrónico, localidad, país, etc., lo que facilita el uso de este directorio para la difusión de certificados.

Existen varias librerías que implementan este protocolo entre las que podemos destacar la versión del australiano Eric Young [7]conocida como SSLeay que no está sujeta a los problemas de exportación a los que las leyes estadounidenses someten a los desarrollos en materia de criptografía. Por este motivo, ha sido la elegida por nosotros para desarrollar parte del software necesario en la infraestructura de seguridad.

3.2.- Seguridad en correo electrónico: el estándar S/MIME

Los estándares de seguridad en correo electrónico proporcionan confidencialidad, integridad, autenticación y no repudio de origen. Cada estándar se puede dividir en cuatro componentes: algoritmos, formatos de los mensajes, formatos de los certificados y gestión de la confianza. En la Universidad de Murcia, el estándar de correo debía soportar estructuras MIME, emplear los mismos certificados X.509 usados en el acceso a web seguro (SSL) y, por tanto, tener como esquema de confianza el de la estructura jerárquica de autoridades de certificación de la Universidad. Por ello, se decidió seleccionar S/MIME [8], que es el estándar que cubre todos los requisitos anteriores. La mayoría de los agentes de correo (UA) actuales soportan este estándar, entre ellos Netscape Messenger, que es el agente sobre el que hemos implementado el servicio.

3.3- Otros servicios

Se está trabajando en la modificación de las aplicaciones de automatrícula, consulta de expendientes, reserva de puestos en las aulas de libre acceso, reserva de instalaciones deportivas, etc., para adaptarlas a la arquitectura de seguridad antes descrita.

4.- Operaciones básicas sobre la infraestructura de certificación

4.1.- Generación de los certificados

El proceso de generación de los certificados aparece esbozado en la figura 3. Las RAs son PCs que se encuentran en cada una de las secretarías de las facultades. Cada RA dispone de un dispositivo lector/grabador de tarjetas inteligentes. El personal responsable del registro emplea un programa para introducir en la tarjeta inteligente 128 bits de una clave simétrica IDEA con la que se cifra la clave privada RSA del usuario. Dicha clave privada cifrada se almacena en una base de datos de la propia Universidad, al tiempo que los certificados (claves públicas firmadas) están en el servidor X.500. Los pasos a seguir para certificar a un integrante de la comunidad universitaria en línea son los siguientes:

1. La secretaria identifica al usuario e introduce su tarjeta en el dispositivo.
2. La aplicación recupera del Servidor X.500 los datos del DN del usuario: nombre, correo electrónico, unidad organizativa y se los devuelve a la RA para que los visualice.
3. La aplicación de la RA genera un par de claves pública/privada para el usuario. La clave pública se introduce en una solicitud de certificado con el DN obtenido en el paso anterior.
4. La clave privada se cifra con una clave simétrica IDEA generada a partir de una clave maestra de la RA y de ciertos datos personales del usuario.
5. La RA envía a través de una conexión SSL la clave privada cifrada del usuario a una base de datos. Al mismo tiempo graba en el carnet inteligente la clave simétrica con la que se cifró la clave privada. La clave simétrica queda protegida por el PIN de la tarjeta.
6. La aplicación establece una conexión segura SSL con una aplicación servidor que está en la máquina que actúa como Repositorio de Solicitudes de Certificado y le envía la solicitud generada en el paso 3.
7. Por último, cada cierto tiempo, la CA recoge las solicitudes del Repositorio de Solicitudes de Certificado y las firma, almacenando los certificados en el servidor X.500.

En el caso de las nuevas tarjetas con espacio suficiente para almacenar la clave privada, los pasos 4 y 5 desaparecerían y sólo sería necesario grabar la clave privada en la tarjeta del usuario.

4.2.- Carga de certificados

El principal problema que se nos planteó era el de disponer de la clave privada y el certificado en el equipo. Como cada usuario por lo general no va a tener su propio ordenador donde almacenarlos, como ocurre, por ejemplo, en las aulas de libre acceso, deben introducirse cuando él decida utilizar el certificado y descargarse cuando abandone el ordenador. Dos alternativas han sido estudiadas basadas en las especificaciones PKCS (Public Key CryptoSystem) de RSA: PKCS#12 y PKCS#11 aunque no habrá que perder de vista la norma PC/SC [11] .

PKCS#12 nos permite importar el certificado contenido en un fichero con extensión ".p12" con la opción importar del menú seguridad del Communicator. El problema es que una vez importado se almacena en la propia base de datos de certificados del navegador y habría que eliminarla manualmente con los problemas que esto podría acarrear (olvido del usuario, poca transparencia, etc.).

PKCS#11 define una interfaz entre aplicaciones y tarjetas inteligentes. El objetivo es que una misma aplicación pueda utilizar lectores de diferentes fabricantes, ya que siempre llama a las mismas funciones (API) para obtener el certificado del cliente y para realizar operaciones criptográficas con la clave privada. Esta solución es mucho más transparente para el usuario, ya que para cargar su certificado sólo necesita introducir su tarjeta inteligente en el lector y el módulo se encarga del resto. La carga de este módulo se puede realizar manualmente o mediante un fichero JAR (Java ARchive) que contienen una librería de enlace dinámico que implementa el módulo criptográfico y un script que instala, registra y configura el módulo de forma automática. Estos módulos están firmados por el creador del módulo y son verificados por el navegador antes de proceder con la instalación.

Cuando el usuario requiere de su certificado el módulo PKCS#11 que hemos desarrollado sigue básicamente los siguientes pasos (figura 4):

1. El usuario introduce el pin de la tarjeta.
2. Se comprueba que el pin que ha introducido es correcto
3. El módulo transfiere del servidor la clave privada cifrada con IDEA.
4. Descifra mediante la clave IDEA almacenada en la tarjeta.
5. Descarga el certificado del servidor LDAP que accede a la base de datos X.500.
6. A partir de este momento, el certificado y la clave privada se encuentran a disposición del navegador.

En el caso de las tarjetas con espacio suficiente para almacenar la clave privada completa los pasos 3 y 4 no serían necesarios, al encontrarse la clave privada en el carné inteligente.

El usuario al cerrar su sesión con el navegador o al extraer la tarjeta borra toda referencia a su certificado sin que este quede almacenado en la propia base de datos de certificados del navegador. De esta forma el proceso es muy sencillo para el usuario que sólo deber utilizar su pin.

4.3.- Revocación

Cuando un certificado se ve comprometido por cualquier motivo (porque se ha puesto en peligro o se ha perdido la tarjeta que almacena la clave privada, porque se ha dejado de pertenecer a la organización, etc.), éste deja de ser válido y la CA difunde públicamente este hecho, revocándolo. Un certificado revocado se tiene que añadir a la lista de revocación de certificados[1] (CRL, Certificate Revocation List), que como su nombre indica es la lista donde se recogen todos los certificados revocados y firmados por la CA.

En nuestro caso, cuando la CA revoca un certificado, además de añadirlo a la lista de revocación, lo elimina del X.500 y suprime también la clave privada cifrada de la base de datos (si existe). Además, publica la nueva lista de revocación de certificados en el X.500 para que cualquier aplicación la pueda consultar.

El proceso de revocación se realiza a través de las RAs para los alumnos, y directamente en la consola de la CA para el personal laboral. Para el caso de los alumnos, las RAs envían la solicitud de revocación al mismo servidor que recibía las solicitudes de certificado. Cada cierto tiempo la CA ejecuta un proceso que se encarga de recoger estas solicitudes, para posteriormente revocar los certificados asociados. La seguridad de este procedimiento reside en que el proceso de acceso a las solicitudes de revocación está certificado, es decir, posee identidad propia dentro de la infraestructura de seguridad. Nuestra CA sólo revocará certificados cuyas solicitudes de revocación se hayan recogido mediante un proceso que posea un certificado autorizado para ello, que en nuestro sistema es único. La Figura 5 muestra el esquema de conexión entre los elementos que intervienen en la revocación de certificados.

5.- Conclusión

Dentro del objetivo inicial de conseguir una infraestructura de seguridad dentro de la Universidad de Murcia, hemos desarrollado un piloto que dota de autenticación, confidencialidad e integridad a las comunicaciones en Web y correo, basadas en los protocolos SSL y S/MIME. Uno de los logros más importantes es hacer totalmente transparente al usuario la manipulación de su certificado y su clave privada. Sin embargo, todavía quedan objetivos por cumplir: dotar de acuse de recibo al correo electrónico mediante librerías como SFL[12] (S/MIME Freeware Library), estudiar los nuevos estándares que están apareciendo en el mundo de las tarjetas inteligentes y la integración con el PC como PC/SC (Personal Computer/Smart Card), así como los nuevos tipos de tarjetas RSA, etc.

Bibliografía

1. ISO/IEC, ITU-T, Information Technology- OSI. The Directory - Authentication Framework. ISO/IEC Internatinal Standard 9594-8 ITU X.509, Junio 1997.
2. GIL VALERA, Estudio de técnicas de criptografía aplicadas a las comunicaciones, Proyecto Fin de Carrera. Universidad de Murcia.1997.
3. KENT S, Privacy Enhancement for Internet Electronic Mail : Part II : Certificate-Based Key Management, Request For Commnets (RFC) 1423, Febrero 1993.
4. N. BERGE, UNINET PCA Policy Statements, Request For Commnets (RFC) 1875, Diciembre 1995.
5. M. WAHL, Lightweight Directory Access Protocol (v3), Request For Commnets (RFC) 2251,1997
6. ALAN,FREIER, KOCHER, The SSL Protocol Protocol Version 3.0, Internet Draft, 1996
7. HUDSON, YOUNG. SSLeay Programmer Reference, Internet Draft, Enero 1996.
8. RSA Laboratories, S/MIME Message Specification, 1996
9. RSA Laboratories, Personal Information Exchange Syntax Standard PKCS#12, version 1.0, Abril 1997.
10. RSA Laboratories, PKCS#11 : Cryptographic Token Interface Standard. Version 2.0, Abril 1997.
11. PC/SC WORKGROUP, Interoperability Specification for ICCs and Personal Computer Systems, 1997
12. VAN DYKE, S/MIME Freeware Library. Application Programming Interface. Draft, Marzo 1998.
13. MASTERCARD, VISA, SET Secure Electronic Transation Specification. Book 1: Business Description, Book 2: Programmer’s Guide, Book 3: Format Protocol Definition. Draft for testing, Version 1.0. May 1997.

Antonio F. Gómez, Fº Javier García,
 skarmeta [at] dif [dot] um.es  jgarcia [at] fcu [dot] um.es
Josefa Gil, Eduardo Martínez,
 pepi [at] fcu [dot] um.es  edumart [at] fcu [dot] um.es
Gregorio Martínez, Alfonso Caja, Oscar Cánovas
 gremar [at] dif [dot] um.es  acaja [at] fcu [dot] um.es ocanovas [at] fcu [dot] um.es
Universidad de Murcia