Experiencia Piloto de Firma Digital de Actas Académicas · La firma digital de actas académicas...

Resumen – La irrupción de la criptografía en el mundo de

las telecomunicaciones ha supuesto una explosión de nuevos

servicios. Uno de los desarrollos que más ha contribuido a esta

expansión ha sido la tecnología de la identidad digital. La

madurez de esta tecnología y su avanzado estado de

implementación han permitido dibujar nuevas formas de

comunicación en la sociedad. Sin embargo, la aplicación de

estas soluciones en entornos particulares no es tarea sencilla.

Para hacer frente a las necesidades que se plantean, es

fundamental analizar previamente el ámbito de aplicación y

realizar un estudio de los requerimientos técnicos, humanos y

organizativos que supone la entrada en funcionamiento de este

tipo de servicios. En este artículo se presenta la experiencia de

implementación de una solución de identidad digital aplicada

al entorno de la Universitat de les Illes Balears.

Palabras clave – Autoridad de Certificación, certificado

digital, criptografía de clave pública, directorio LDAP, firma

digital, Infraestructura de Clave Pública.

I. INTRODUCCIÓN

N mayo de 2002, el Centre de Tecnologies de la Informació de la Universitat de les Illes Balears (CTI@UIB) comenzó a trabajar en la implementación

de una Infraestructura de Clave Pública (de ahora en adelante, PKI) de ámbito universitario. El objetivo era doble:

- Generar conocimiento práctico a través del estudio de la tecnología actual en el mundo de las Infraestructuras de Clave Pública.

- Construir una plataforma tecnológica que permitiera la puesta en marcha de futuros servicios basados en certificación y firma digital.

En la operativa diaria de una universidad, todo proceso oficial de evaluación debe concluir con la firma manuscrita del profesor sobre el acta académica de la asignatura. Como parte fundamental de la gestión académica, la firma de actas supone una excelente oportunidad para la aplicación de las nuevas tecnologías en el ámbito de la identidad digital.

La experiencia piloto del Centre de Tecnologies de la Informació tenía como objetivo informatizar e integrar en un solo proceso las operaciones de generación, cierre y firma de actas académicas con los requerimientos de seguridad que exige una institución universitaria. En el entorno de trabajo de la Universitat de les Illes Balears (de

Jaime Ferragut Martínez-Vara de Rey es Ingeniero Técnico de

Telecomunicación por la Escola Politècnica Superior de la Universitat de les Illes Balears (e-mail: [email protected]).

Bartomeu J. Serra Cifre es Catedrático de Ciencias de la Computación e Inteligencia Artificial de la Universitat de les Illes Balears (e-mail: [email protected]).

ahora en adelante, UIB), la mayoría de procesos relacionados con el tratamiento de la información académica ya habían sido informatizados. No obstante, la firma manuscrita del profesor seguía siendo necesaria para dotar al documento final de validez académica.

II. OBJETIVOS Y PLANIFICACIÓN

El principal objetivo de la experiencia piloto era el de profundizar en la utilización de la criptografía de clave pública como mecanismo para simplificar al máximo los trámites académicos que supone la firma de actas. Una vez implementado, el nuevo proceso de validación digital evitaría desplazamientos de profesores, agilizaría los trámites y convertiría al actual aplicativo ÁGORA (Aplicatiu de Gestió de l‘ORganització Acadèmica) en una herramienta que integraría todos los procesos de la gestión académica.

La firma digital de actas académicas se apoyaba en dos grandes líneas de desarrollo: en primer lugar era necesaria la puesta en marcha de una Infraestructura de Clave Pública como elemento generador de confianza y mecanismo de certificación digital al servicio de los colectivos de PAS (Personal de Administración y Servicios) y PDI (Personal Docente e Investigador). En segundo lugar, y para minimizar el impacto sobre la estructura existente, era preciso diseñar un sistema que permitiera a los profesores enviar, de forma segura, las actas firmadas digitalmente al personal de Secretaría Académica.

El desarrollo de esta experiencia piloto comprendió los meses de mayo a septiembre de 2002. La prueba definitiva tuvo lugar durante los meses de septiembre y octubre de 2002, fechas en las que se firmaron las actas de la convocatoria de septiembre del curso académico 2001-2002.

Las sucesivas secciones describen la experiencia de trabajo de la primera fase, lo que se dio a conocer públicamente como el Piloto de Firma Digital de Actas Académicas. A esta primera fase le siguió una segunda cuyo objetivo era el de consolidar los resultados obtenidos en la implementación de una PKI de ámbito universitario.

III. ANÁLISIS DE REQUERIMIENTOS

Para establecer el entorno de trabajo y definir las líneas de implementación, se organizaron diversas reuniones de coordinación con el equipo responsable del proyecto. Inicialmente este equipo estaba integrado por el Director y dos técnicos del Centre de Tecnologies de la Informació, así como por un profesor del Departamento de Ciencias Matemáticas e Informática. Las siguientes subsecciones describen el análisis de requerimientos en todas las áreas implicadas: Sistema Gestor de Certificados Digitales, tipos de certificados a expedir, utilización de tokens externos, elección de los profesores participantes, seguridad de la PKI, equipamiento hardware y dinámica de la firma digital

Experiencia Piloto de Firma Digital de Actas Académicas

J. Ferragut Martínez-Vara de Rey, B. Serra Cifre, Universitat de les Illes Balears, España

E

IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005 205

de actas académicas.

A. Sistema Gestor de Certificados Digitales: La elección del software que implementaría el Sistema

Gestor de Certificados Digitales (SGCD) era una decisión importante, ya que iba a definir el entorno de trabajo. En lo que se refiere a este tema, el análisis de requerimientos arrojó las siguientes conclusiones:

1.- La solución de implementación para la PKI quedaba a libre elección de los responsables técnicos. No obstante, y como mecanismo para la generación de conocimiento, surgió la idea de realizar un análisis comparativo entre diferentes soluciones PKI, tanto comerciales como de código abierto. Finalmente, este conjunto de aplicaciones se redujo a tres soluciones representativas de la tecnología actual de mercado: Microsoft Windows 2000 Certificate Services, OpenCA y SunONE Certificate Server.

2.- Una de las pocas consideraciones que marcó la selección del SGCD fue la posibilidad de utilizar módulos PKCS#11 externos. Esta decisión se tomó en vistas a facilitar una futura integración del parque de tarjetas inteligentes de la UIB en la estructura de la PKI.

B. Tipos de certificados digitales En cuanto al tipo de certificados digitales que expediría

la Infraestructura de Clave Pública, se tuvieron en cuenta las siguientes consideraciones:

1.- En la experiencia piloto, la PKI sólo expediría certificados digitales de identidad personal con longitudes de clave de 1024 bits.

2.- Para favorecer la integración con las aplicaciones de usuario, los certificados digitales respetarían la estructura X.509 versión 3 de la ITU-T [1]. No se utilizarían extensiones propietarias.

3.- El periodo de validez de los certificados digitales abarcaría los meses de septiembre, octubre y noviembre de 2002. Se escogieron estas fechas porque es en ellas cuando se procede a firmar las actas académicas de la convocatoria de septiembre.

4.- Al tratarse de un conjunto controlado de profesores, se podían relajar los mecanismos de verificación de identidad necesarios para la generación de los certificados.

5.- Para futuras verificaciones, los certificados digitales se almacenarían en un directorio público.

C. Utilización de tokens externos: Un token externo es un dispositivo físico que sirve como

almacén de credenciales digitales (tarjetas inteligentes, llaves criptográficas USB, etc.). Para favorecer un desarrollo rápido del Piloto de Firma Digital de Actas Académicas, en un primer momento se optó por no utilizar tokens externos. A este respecto, las decisiones tomadas en la fase de análisis fueron las siguientes:

1.- En cuanto al sistema de firma digital, era necesario buscar soluciones de implementación de impacto mínimo para los profesores. En el escenario de escogido, la utilización de teclados equipados con lector de tarjetas inteligentes complicaba la entrada en funcionamiento de la experiencia piloto (instalación de drivers, problemas ocasionados por incompatibilidades, cambio de teclados, formación adicional, etc.)

2.- Frente a la utilización de tarjetas inteligentes, la

opción de almacenar las claves privadas en el propio sistema operativo resultaba menos segura. Sin embargo, esta decisión simplificaba la tarea de los desarrolladores y reducía las molestias para el usuario final.

3.- Al margen de las consideraciones anteriores, se decidió abrir una línea de trabajo en el área de tokensexternos. El objetivo era generar conocimiento para una futura utilización criptográfica del parque de tarjetas inteligentes bancarias de la UIB.

D. Profesores participantes: En la elección del conjunto de profesores que se

someterían al Piloto de Firma Digital de Actas Académicas se tuvieron en cuenta las siguientes consideraciones:

1.- El número de profesores participantes debía ser lo suficientemente elevado como para obtener un conjunto de impresiones representativo y lo suficientemente reducido como para que un único responsable técnico pudiera atender sus necesidades.

2.- Para impulsar la implantación y el desarrollo de la experiencia piloto, los profesores participantes debían responder a un perfil técnico con conocimientos previos en las tecnologías de certificación y firma digital.

3.- Para favorecer la realización y el seguimiento de un considerable número de pruebas, se optó por seleccionar a miembros del Centre de Tecnologies de la Informació con responsabilidades docentes, así como a algunos profesores del Departamento de Ciencias Matemáticas e Informática.

E. Seguridad de la PKI: En una Infraestructura de Clave Pública, la seguridad de

los sistemas que la integran es crítica. Al tratarse de un entorno de pruebas controlado, el Piloto de Firma Digital de Actas Académicas contó con unos requerimientos de seguridad más relajados que los de una implementación real. Las consideraciones de seguridad que afectaron tanto a los sistemas de la PKI como al resto de aplicaciones implicadas en la firma digital de actas académicas son las siguientes:

1.- El Sistema Gestor de Certificados Digitales debía funcionar sobre un sistema operativo provisto de mecanismos de control de acceso.

2.- El equipo informático sobre el que trabajara la Autoridad de Certificación (CA) se ubicaría en el Centre de Tecnologies de la Informació.

3.- El administrador de la PKI debía definir mecanismos de autentificación para que únicamente los profesores participantes en la experiencia piloto pudieran solicitar certificados digitales. Cualquier otra solicitud sería descartada inmediatamente.

4.- Los profesores únicamente podían firmar las actas correspondientes a sus asignaturas.

5.- El tráfico de datos entre las Secretarías Académicas y los profesores debía ser auténtico y confidencial.

6.- Existiría un único responsable en las Secretarías Académicas provisto de identidad digital. Este responsable se encargaría del almacenamiento seguro de las actas firmadas digitalmente, así como del envío de los acuses de recibo.

7.- Paralelamente a las Secretarías Académicas, el Centre de Tecnologies de la Informació mantendría una base de datos de backup para las actas académicas firmadas.

8.- De forma periódica se realizarían copias de seguridad del Sistema Gestor de Certificados Digitales e imágenes binarias de los equipos informáticos de la PKI.

206 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005

F. Equipamiento informático y de comunicaciones: Al tratarse de una experiencia piloto, para la

implementación de la PKI se necesitaba una infraestructura mínima en lo que a comunicaciones y equipos informáticos se refiere. Bastaba con un punto de acceso a la red pública de la Universitat de les Illes Balears, una estación de trabajo de gama media/alta y una cuenta de usuario en el servidor de correo electrónico de la UIB. Las consideraciones de sistema operativo, software antivirus, soluciones LDAP

(Lightweight Directory Access Protocol) y SGCD se discutirán posteriormente en la sección de implementación.

G. Dinámica de la firma digital de actas académicas: Las consideraciones que debían regir el procedimiento

por el que un profesor firmaba digitalmente un acta académica eran las siguientes:

1.- Había que tener en cuenta los desarrollos existentes: el profesor obtendría el acta académica a través de la interfaz web segura de ÁGORA.

2.- En lo que respecta al acceso a la información, ÁGORA

ya incorporaba sus propios mecanismos de autentificación basados en login y password.

3.- Para simplificar la tarea de los desarrolladores y provocar un impacto mínimo sobre los procedimientos de gestión académica, el sistema de firma digital debía integrarse fácilmente en un entorno web o de correo electrónico.

4.- El objetivo principal era evitar desplazamientos de los profesores a las dependencias de Secretaría Académica.

5.- La Secretaría Académica debía remitir acuse de recibo a los profesores que hubieran completado correctamente el proceso de firma digital de actas académicas.

6.- Los profesores debían tener la posibilidad de analizar detenidamente el contenido del acta antes de firmarla.

7.- Había que respetar escrupulosamente la dinámica habitual de firma de actas y tener en cuenta las opiniones de los agentes implicados (profesores y personal de Secretaría Académica).

En la próxima sección se describe el diseño adoptado para la realización de la experiencia piloto, tanto en el área de PKI como en la del sistema de firma digital de actas académicas.

IV. DISEÑO DE LA SOLUCIÓN

En la fase de diseño de la experiencia piloto se discutieron aspectos que debían regir desde la arquitectura de la Infraestructura de Clave Pública hasta el funcionamiento del sistema de firma digital de actas académicas. Las decisiones tomadas en estas áreas son las siguientes:

A. Infraestructura de Clave Pública: Tomando como punto de partida la existencia de un

conjunto muy reducido de usuarios, se adoptó la decisión de diseñar una estructura sencilla para los sistemas integrados en la PKI. Sobre una misma máquina coexistirían los servicios de Autoridad de Certificación y directorio LDAP.En este diseño no se consideró la existencia de Autoridades de Registro, ya que el reducido número de usuarios y los mecanismos de autentificación no las hacían necesarias.

El directorio LDAP tendría una doble atribución en la Infraestructura de Clave Pública. Por un lado, se

aprovecharía como repositorio público de los certificados digitales expedidos. Por otro lado, actuaría como base de datos para la autentificación de usuarios durante el proceso de generación de las credenciales digitales. Cada participante de la experiencia piloto contaría con una entrada en el directorio creada previamente por el administrador de la PKI. De forma presencial y confidencial se entregaría a cada profesor un sobre con un manual de usuario y la pareja {UID, password} necesaria para autentificarse frente a la PKI. Así, sólo los usuarios autorizados podrían generar sus credenciales digitales a través de los formularios web provistos por la Autoridad de Certificación. El administrador de la PKI únicamente debería preocuparse de crear las entradas LDAP para cada usuario y de entregar de forma segura la documentación.

B. Tipos de certificados digitales: Los certificados digitales se adaptarían al estándar X.509

versión 3 de la ITU-T. Finalmente, para evitar problemas derivados de posibles retrasos en la firma de actas, se decidió no restringir el periodo de validez a los meses de septiembre, octubre y noviembre. Todos los certificados digitales tendrían validez por un año y la longitud del par de claves sería de 1024 bits, tanto para profesores como para el personal de Secretaría Académica. Al tratarse de una experiencia muy acotada en el tiempo, no se considerarían mecanismos de renovación o revocación de certificados digitales.

Como medida de uniformización, los usuarios no deberían introducir sus datos personales en los formularios web de solicitud de certificados digitales. Al proporcionar su UID y password, la Autoridad de Certificación construiría automáticamente el campo Subject del certificado tomando como referencia los datos personales contenidos en la correspondiente entrada LDAP.

C. Tokens externos: Para favorecer un desarrollo rápido de la experiencia

piloto se decidió no trabajar con tokens externos: los certificados digitales se almacenarían de forma segura en el disco duro del ordenador. De igual manera, el personal de Secretaría Académica tampoco trabajaría con tokensexternos. Independientemente del mecanismo de control de acceso del sistema operativo se aconsejaba a los usuarios proteger la clave privada con una contraseña.

D. Profesores participantes: Para llevar a cabo la experiencia piloto se contó con la

colaboración de 9 miembros del Centre de Tecnologies de la Informació, 2 profesores del Departamento de Ciencias Matemáticas e Informática y un profesor del Departamento de Derecho Privado.

E. Dinámica de la firma digital de actas académicas: En el diseño del procedimiento de firma digital se debían

respetar escrupulosamente dos principios básicos: mantener la dinámica de la firma manuscrita e integrar los procesos de firma digital en los clientes web o de correo electrónico.

Para cumplir con el primer principio, se decidió trabajar con actas académicas en formato Adobe PDF debido a su parecido con el formato papel.

Para respetar el segundo principio, se decidió que el flujo de información entre los profesores y el personal de Secretaría Académica se implementara a través de correos

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC 207

electrónicos firmados y cifrados a los que se adjuntarían las actas en formato PDF. Como la práctica totalidad de clientes de correo electrónico implementan el protocolo S/MIME, el impacto de la solución de firma digital sobre el conjunto de usuarios sería mínimo.

El procedimiento por el que un profesor descargaba un acta académica, la firmaba digitalmente y la enviaba a Secretaría Académica se resume en los siguientes cinco pasos:

1.- El administrador de la PKI entregaba en mano al profesor un sobre con la información necesaria para generar sus credenciales digitales (UID y password de su entrada en el directorio LDAP).

2.- Mediante una conexión segura, el profesor accedía desde su equipo informático a un formulario web de la Autoridad de Certificación, introducía la pareja {UID,password} y automáticamente generaba sus credenciales digitales con los datos almacenados en su entrada LDAP.

3.- El profesor accedía a la interfaz web de ÁGORA, se identificaba introduciendo su login/password y solicitaba la descarga de una de las actas académicas pendientes de firmar. En ese momento, ÁGORA consultaba la base de datos de gestión académica, generaba dinámicamente el archivo PDF y lo enviaba al ordenador del profesor.

4.- El profesor descargaba en su sistema de ficheros el acta académica y revisaba detenidamente su contenido. Una vez comprobado, redactaba un correo electrónico firmado y cifrado, adjuntando el archivo PDF. El mensaje S/MIME

resultante se remitía al personal de Secretaría Académica.

Fig. 1. Procedimiento de firma digital de actas académicas

5.- Un responsable de Secretaría Académica recibía el

mensaje de correo electrónico, verificaba la firma digital del profesor sobre el mismo, almacenaba el acta de forma segura y remitía de vuelta un acuse de recibo cifrado y firmado. Las actas digitales se guardaban bajo llave en soporte óptico junto con los certificados digitales que permitían verificar sus firmas (certificados digitales de los profesores y de la Autoridad de Certificación).

El diagrama temporal de la fig. 1 describe gráficamente el procedimiento de firma digital de actas académicas. Cada una de las flechas representa una transacción de información de acuerdo con los cinco pasos anteriormente descritos.

V. FASE DE IMPLEMENTACIÓN

Finalizado el diseño del sistema de firma digital y la arquitectura de la PKI, el siguiente paso era la selección de la tecnología para completar la fase de implementación (equipos informáticos, sistema operativo, soluciones PKI y LDAP, etc.) Posteriormente había que instalar y configurar todos estos componentes para cumplir con los objetivos del Piloto de Firma Digital de Actas Académicas.

Al margen de estas consideraciones técnicas, también era necesario establecer líneas de diálogo con los profesores y el personal de Secretaría Académica para perfilar los detalles de implementación de la experiencia piloto.

En esta sección se describen las decisiones tomadas durante la fase de implementación; desde aspectos puramente técnicos hasta consideraciones de tipo organizativo.

A. Selección de la solución PKI: Para la implementación de la experiencia piloto se

escogió la solución PKI SunONE Certificate Server 4.7, en su versión para el sistema operativo Windows 2000 Server.

De las soluciones PKI citadas anteriormente, Sun ONE Certificate Server es la más robusta y completa. Windows 2000 Certificate Services fue descartada por ofrecer una solución excesivamente vinculada a los sistemas operativos de la familia Microsoft. La solución de código abierto OpenCAconstituía una opción flexible y barata, pero requería fuertes conocimientos del sistema operativo Linux y del entorno de programación. Debido a las restricciones temporales de la experiencia piloto, el equipo de desarrolladores no estaba en posición de asumir estos esfuerzos.

Sun ONE Certificate Server se adaptaba perfectamente a las necesidades del Piloto, ya que combinaba un potente Sistema Gestor de Certificados Digitales con una interfaz de administración muy sencilla. El proceso de instalación era trivial y los esfuerzos de personalización se simplificaban enormemente gracias a la utilización de módulos JAVA

específicos provistos de interfaces visuales. Además, el SGCD ya incorporaba el software SunONE Directory Server 5.1 SP1, necesario para la implementación de un servicio de directorio basado en el protocolo LDAP. Toda la operativa de administración y mantenimiento de la PKI se canalizaba o bien a través de interfaces web de gestión, o bien e través de la consola iPlanet. Esta aplicación se incluía de serie en el SGCD y permitía gestionar los servidores de la suite SunONE.

B. Selección y preparación de la plataforma de trabajo: SunONE Certificate Server está disponible para los sistemas

operativos Windows NT, 2000 Server y Solaris 8. En la implementación de la experiencia piloto se escogió la

Admin.PKI Profesor CA ÁGORA B.DD. Secr. Acad.

1

2

2

3

3

3

3

4

5


plataforma Intel Pentium II equipada con Windows 2000 Server.

Las características técnicas del sistema sobre el que se instaló SunONE Certificate Server son las siguientes:

- Procesador Intel Pentium II a 350 MHz- 256 MB de memoria RAM- 2 discos duros SCSI de 4GB de capacidad cada uno- Tarjeta de red Ethernet a 10/100 Mbps

En principio, el sistema tenía potencia suficiente como para soportar la estructura PKI del Piloto de Firma Digital de Actas Académicas. En cuanto a la preparación del equipo para la instalación del Sistema Gestor de Certificados Digitales, este fue el procedimiento seguido:

1.- En primer lugar, se formatearon los dos discos duros del equipo: uno con el sistema de ficheros NTFS (para la instalación del sistema operativo y las aplicaciones) y otro con el sistema FAT32 (para el almacenamiento de los datos).

2.- En segundo lugar, se procedió a la instalación del sistema operativo Windows 2000 Server en su versión inglesa. Numerosos desarrolladores recomiendan la utilización de las versiones inglesas de los sistemas operativos de Microsoft por ser las primeras en ser sometidas a pruebas de estabilidad y contar con las primeras distribuciones de parches de seguridad (hotfixes). Tras Windows 2000 Server se instalaron los componentes ServicePack 2 (SP2) y Service Pack 2 Security Release Package 1(SP2SRP1).

3.- Finalizada la instalación de Windows 2000 Server, el siguiente paso fue la realización de una imagen binaria del disco de sistema operativo con la aplicación Ghost de Symantec. Ghost es un pequeño ejecutable capaz de escanear bit a bit un disco duro o partición y almacenar todo su contenido en un fichero comprimido de extensión .gho. Si con el paso del tiempo se produjeran anomalías en el comportamiento del sistema operativo, Ghost proporciona un mecanismo sencillo para la recuperación del estado inicial. Tan sólo hay que arrancar la aplicación y lanzar sobre el disco duro de sistema operativo la imagen binaria que se realizó justo después de la instalación. El único inconveniente de Ghost es que sólo puede volcar imágenes sobre particiones FAT32. Por este motivo se tomó la decisión de formatear el disco duro de datos con este sistema de ficheros.

Fig. 2. Generación y grabación de imágenes binarias con Ghost

4.- Para finalizar la preparación de la plataforma de trabajo, sólo restaba configurar las propiedades de red del equipo e instalar un software antivirus. En cuanto a las

comunicaciones, el equipo fue incorporado a la red de datos - Segunda instancia de Directory Server: al margen del

repositorio público de información, SunONE Certificate Server instala un segundo directorio LDAP que actúa como base de datos interna de la Autoridad de Certificación (almacenamiento de solicitudes, certificados expedidos, registro de logs, etc.). A nivel de operativa interna, este directorio recibe el nombre de tango internal-db.

- Al margen de la figura del Directory Server Manager,durante el proceso de configuración se crea un nuevo perfil de administración responsable de la Autoridad de Certificación. Este usuario recibe el nombre de Administrador del CMS (Certificate Management System Administrator) y su tarea consiste en personalizar la CA y aprobar (o denegar) la solicitud de certificados digitales.

- La Autoridad de Certificación implementa una serie de interfaces web para la gestión de los servicios y la interacción con los usuarios finales. Para el acceso de administradores y agentes se habilitaron los puertos seguros 8200 y 8100. Para la interacción con los usuarios finales se habilitaron los puertos 1027 (para conexiones HTTPS) y 1024 (para conexiones HTTP).

Dentro del proceso de configuración se crean los primeros tres certificados de la CA. Estas credenciales internas son necesarias para el correcto funcionamiento de algunos servicios básicos, como por ejemplo la generación de certificados digitales de usuario, el establecimiento de conexiones seguras mediante el protocolo SSL o la autentificación del administrador del CMS frente al sistema. A continuación se describe cada uno de ellos:

- Certificado de autofirma de la CA: La función principal de una Autoridad de Certificación es expedir certificados digitales. Para poder firmarlos, es necesario que la CA genere un par de claves. SunONE Certificate Serveralmacena la clave privada de la CA en el sistema de ficheros del ordenador o en un token externo. Para el almacenamiento de la clave pública, la Autoridad de Certificación crea un certificado autofirmado (los campos Issuer y Subject son idénticos) que liga la clave pública a su identidad en Internet (Distinguished Name).

- Certificado SSL para la CA: SunONE Certificate Server implementa múltiples interfaces de comunicación seguras. En todas ellas se emplea como mecanismo de transporte el protocolo de comunicaciones SSL. Para proveer autentificación de servidor, es necesaria la existencia de un certificado de servidor SSL expedido a nombre de la máquina que alberga los servicios de Autoridad de Certificación. Cuando un cliente web se conecta a esta máquina a través de alguna de sus interfaces seguras, el servidor muestra dicho certificado para garantizar autenticidad y confidencialidad en las comunicaciones.

- Certificado SSL para el administrador del CMS: En este caso, este certificado es de cliente SSL y está expedido a nombre del administrador de la Autoridad de Certificación. Cuando éste se conecta a la interfaz web segura de administración de la CA, el servidor se autentifica presentando un certificado digital. Igualmente, al tratarse de un usuario con privilegios, el cliente debe mostrar su certificado de administrador del CMS.

Todos estos certificados tenían un periodo de validez de dos años. Para la generación de las credenciales digitales se utilizaron claves RSA de 1024 bits y el algoritmo de firma

HD1

HD2

Sistema operativo y aplicaciones

(NTFS)

Datos de usuario (FAT32)

Symantec GHOST

00100101101...

imagen.gho


SHA1withRSA.La fig. 3 describe gráficamente la arquitectura final de la

Infraestructura de Clave Pública en la experiencia piloto. Completada la preparación de la plataforma de trabajo e

instalado el SGCD, el Centre de Tecnologies de la Informació ya contaba con la infraestructura básica para comenzar a expedir certificados digitales. Sin embargo, algunos subsistemas de la PKI (Autoridad de Certificación y Directorio LDAP) debían someterse a un proceso de personalización para adaptarse a las necesidades específicas de la experiencia piloto.

Fig. 3. Arquitectura de la PKI de la experiencia piloto

1) Autoridad de Certificación: La primera tarea que se llevó a cabo sobre este

subsistema fue la definición de una sencilla política de certificación (CP, Certificate Policy) para garantizar uniformidad en los certificados expedidos. La recomendación RFC2527 [2] sugiere que toda Autoridad de Certificación debe contar con un documento público en el que se plasme el conjunto de las consideraciones de su CP. Al tratarse de una experiencia de pruebas, el Piloto de Firma Digital de Actas Académicas no implicaba la puesta en marcha de una CA en un entorno real de producción. En este sentido, se optó por definir una serie de valores estándar para la generación de certificados digitales.

TABLA IVALORES ESTÁNDAR DEFINIDOS EN LA POLÍTICA DE CERTIFICACIÓN DE LA

PKI DE LA EXPERIENCIA PILOTO

Atributo Valor estándar

Algoritmo generación de claves RSA

Longitud de las claves 1024 bits

Algoritmo de firma SHA1withRSA

Periodo de validez 1 año

SunONE Certificate Server ofrece a los administradores de la PKI un menú de configuración de políticas referentes a la Autoridad de Certificación. Este menú comprende un conjunto de reglas que permiten controlar aspectos como el

algoritmo de firma de los certificados, la longitud del par de claves o el periodo de validez. Cada una de estas reglas se implementa a través de una clase JAVA cuya función es comunicar al módulo generador de certificados digitales los detalles de la política de certificación. Para definir y activar las reglas era necesario localizar y modificar adecuadamente cada uno de estos módulos JAVA. En la personalización de TANGO se configuraron las siguientes reglas:

RSAKeyConstraints: Esta regla permite definir la longitud del par de claves RSA que se proporcionará al usuario. Para la experiencia piloto se optó por un tamaño fijo de 1024 bits. La definición formal de esta regla en la sintaxis de SunONE CS es la siguiente:

Enable rule Predicate: HTTP_PARAMS.certType==client MinSize: 1024MaxSize: 1024Exponents: 17, 65537

SigningAlgorithmConstraints: Esta clase JAVA permite definir el algoritmo de firma de los certificados expedidos por la Autoridad de Certificación. En la experiencia piloto se escogió el algoritmo de firma SHA1withRSA para todos los certificados. La definición formal de esta regla en la sintaxis de SunONE Certificate Server es la siguiente:

Enable rule Predicate: HTTP_PARAMS.certType==client Algorithm: SHA1withRSAValidityConstraints: Este módulo permite definir el

periodo de validez de los certificados digitales expedidos por la CA. Para las credenciales digitales de los profesores se fijó un periodo máximo de 365 días a partir del momento de la emisión. La definición formal de esta regla en la sintaxis de SunONE Certificate Server es la siguiente:

Enable rule Predicate: HTTP_PARAMS.certType==client MinValidity: 365MaxValidity: 365LeadTime: 0 LagTime: 0 NotBeforeSkew: 0

Por otra parte, la Autoridad de Certificación se configuró para publicar automáticamente en el directorio LDAP su certificado digital y los certificados expedidos por los profesores participantes (como ya se ha comentado, el administrador de la PKI había creado entradas previamente para cada uno de ellos). Para implementar el proceso de publicación se optó por la utilización conjunta de mappers y publishers.

Un mapper es un módulo capaz de construir un Distinguished Name a partir de determinados atributos del campo Subject Name de un certificado digital. Este DN lo aprovecha posteriormente la Autoridad de Certificación para apuntar a la entrada de un profesor en el directorio LDAP.Finalmente, el módulo publisher incorpora el certificado digital a la entrada del usuario en forma de atributo binario.

Uno de los atributos LDAP de uso más extendido es userCertificate (OID1=2.5.4.36). Este atributo está ligado a la sintaxis Certificate (OID=1.3.6.1.4.1.1466.115.121.1.8) y se utiliza para añadir certificados digitales X.509 a la entrada LDAP de un usuario. La sintaxis Certificate permite realizar búsquedas y aplicar reglas de similitud sobre cada

1 Acrónimo de Object Identifier, identificador de objeto en Internet.

Consola iPlanet

389

8200

15277

User-config directory

Internal-db

Certificate Manager

Administration Server

38900

8100

1027

1024

LDAP

HTTPS

HTTP

HTTPS

HTTPS

HTTP

LDAP

TANGO


uno de los campos del certificado (Issuer, Subject Name,Validity, etc.). Gracias a esta sintaxis un cliente LDAP puede llevar a cabo búsquedas de certificados digitales en base a criterios como la Autoridad de Certificación emisora, el periodo de validez del certificado, la organización a la que pertenece el titular, etc. Las pruebas realizadas a lo largo de la experiencia piloto concluyeron que la versión 5.1 ServicePack 1 de SunONE Directory Server (enero de 2003) implementa el atributo userCertificate pero no lo liga a su sintaxis natural (Certificate), sino a la sintaxis binaria por defecto (Binary, OID=1.3.6.1.4.1.1466.115.121.1.5). Esta sintaxis trata el certificado digital como una ristra de bits sin sentido alguno, lo que impide realizar búsquedas y aplicar reglas de similitud sobre el contenido del mismo.

En el Piloto de Firma Digital de Actas Académicas se utilizaron los mappers LdapSimpleMap y LdapCaSimpleMap,que permiten localizar las entradas de los usuarios finales y la Autoridad de Certificación, respectivamente.

La fig. 4 describe gráficamente el proceso de localización de la entrada LDAP de un usuario y la posterior publicación de su certificado digital. En esta figura se ha considerado un ejemplo real del Piloto de Firma Digital de Actas Académicas.

Fig. 4. Construcción del Distinguished Name y publicación del certificado

Para la configuración del mapper LdapUserCertMap se escogió la siguiente definición de dnPattern:

dnPattern:UID=$req.HTTP_PARAMS.UIDou=$subj.ouo=$subj.o, c=ES

La función de esta plantilla es generar un Distinguished Name que apunte a una entrada concreta del directorio LDAP. Para la construcción de este DN se utilizó el atributo UID del formulario web de solicitud y los atributos OU, O y C del certificado digital.

Por otra parte, la configuración del mapper

LdapCaCertMap fue la siguiente:

dnPattern:UID=CA del CTI@UIB ou=Peopleo=Universitat de les Illes Balears c=EScreateCAEntry: yes

A diferencia de la anterior esta plantilla no genera un Distinguished Name dinámicamente, sino que toma como referencia un conjunto de valores fijados por el administrador de la PKI. El principal problema es que este DN apuntaba a una entrada inexistente en el directorio LDAP

(la carga inicial de datos sólo implicaba a los profesores participantes en la experiencia piloto, no a la Autoridad de Certificación). El campo createCAEntry permite crear manualmente una entrada LDAP para la CA, de tal forma que el mapper siempre sea capaz de encontrarla. A modo de ejemplo a continuación se muestra el volcado LDIF (LDAPData Interchange Format) de la entrada de una CA:

dn: UID=ca-cti,DC=uib,DC=escn: ca-cti sn: ca-cti objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: certificationAuthority authorityRevocationList:cACertificate:: MIIDijC... certificateRevocationList:: MIIBlD... UID: ca-cti

Con respecto a la publicación de certificados, el proceso de configuración es muy similar al descrito hasta ahora. A diferencia de los mappers, los publishers no se encargan de localizar entradas en un directorio, sino de especificar bajo qué atributo y sintaxis se almacenará el certificado digital en la entrada LDAP de un usuario.

En el Piloto de Firma Digital se utilizaron dos módulos: LdapUserCertPublisher y LdapCaCertPublisher. El primero se encargaba de publicar los certificados digitales de los profesores en las entradas apuntadas por LdapUserCertMap. La función del segundo era la de publicar el certificado digital de la Autoridad de Certificación en la entrada apuntada por LdapCaCertMap.

En el caso de los profesores, los certificados se incluyeron en las entradas LDAP como atributos userCertificate con sintaxis binaria por defecto (como ya se ha comentado anteriormente, la implementación de SunONE Directory Server no soporta la sintaxis Certificate). En el caso de la Autoridad de Certificación, el certificado digital se añadió a su correspondiente entrada LDAP como un atributo caCertificate con sintaxis binaria por defecto. Para permitir la utilización del atributo caCertificate en la entrada de la CA, el publisher se encargó previamente de convertirla en un objeto de clase certificationAuthority.

Como último paso en la personalización del SGCD, se procedió a la configuración de un módulo de autentificación específico que permitiera a los profesores generar sus credenciales digitales proporcionando únicamente la pareja {UID, password}.

SunONE Certificate Server incorpora un conjunto de clases JAVA que permiten definir diferentes esquemas de autentificación para la generación de certificados digitales. En la implementación de la experiencia piloto se escogió el

Version

Serial number

Signature AlgorithmIdentifier

...

Subject Name

...

Mapper DN: dc=uib, dc=es, ou=People, cn=tsola

dc=uib, dc=es

ou=People

cn=tsola

Mapper

Publisher

Certificado digital X.509

Distinguished Name (DN)

Directorio LDAP

Entrada LDAP

dn dc=es, dc=uib, ou=People, cn=tsolaTelephoneNumber: (+34) 971 172 mail [email protected] AntonioobjectClass topobjectClass person

objectClass organizationalPersonsn Sola VenteouserCertificate Ux/9ji...

o=NetscapeRoot


módulo UIDPwdDirAuth (UID and Password Directory Authentication Module). Para garantizar la confidencialidad de los datos proporcionados por los profesores, SunONE Certificate Server se configuró para que el procedimiento de solicitud se realizara a través de la interfaz web segura para usuarios finales (puerto 1027).

A continuación se detalla la configuración del módulo UIDPwdDirAuth:

dnPattern:E=$attr.mailCN=$attr.cnOU=$attr.ouO=$attr.oC=ESldap.ldapconn.host: tango.uib.es ldap.ldapconn.port: 389 ldap.ldapconn.secureConn: non-SSL ldap.ldapconn.version: 3 ldap.basedn: dc=uib,dc=es,OU=People

El campo dnPattern indica qué atributos de la entrada LDAP de un usuario se mostrarán finalmente en el campo Subject Name de su certificado digital. En la experiencia piloto, todos los componentes del Subject Name se recuperaron de forma dinámica a partir de las entradas LDAP a excepción del atributo C (Country), cuyo valor se fijó manualmente a “ES” (España). Los campos ldap.ldapconn.host y ldap.ldapconn.port determinan el directorio LDAP contra el que la Autoridad de Certificación debe autentificar las solicitudes recibidas. Finalmente el campo ldap.basedn fija el nodo del árbol LDAP a partir del cual la CA debe buscar las entradas de los usuarios. Como muestra la fig. 4, este nodo tiene por DN la cadena dc=uib, dc=es, ou=People.

2) Directorio LDAP:Para la realización del Piloto de Firma Digital de Actas

Académicas se definió una estructura de directorio experimental. Como ya se ha comentado anteriormente, la función de esta estructura era doble: por un lado, se utilizaría como repositorio público de los certificados expedidos. Por otro lado actuaría como base de datos para la autentificación de usuarios en los procesos de generación de credenciales digitales.

Fig. 5. Estructura de directorio de la experiencia piloto

La estructura del directorio era muy sencilla. Dentro de la primera instancia de SunONE Directory Server (user-config

& publishing directory) se crearon dos ramas de publicación. La primera de ellas (o=NetscapeRoot) se encargaba de almacenar la información de configuración de los servidores SunONE gestionados por la consola iPlanet.Bajo la segunda rama (dc=uib, dc=es, ou=People) se almacenaban las entradas de la CA y los profesores participantes en la experiencia piloto. La fig. 5 describe gráficamente esta estructura de directorio.

Como paso previo a la entrada en funcionamiento del Piloto, se crearon entradas LDAP bajo la rama dc=uib, dc=es, ou=People para cada uno de los profesores participantes. Para construir el UID se tomó la primera letra del nombre propio y todo el primer apellido. Para el password se utilizó un generador aleatorio de contraseñas. Además, en previsión de un futuro servicio de páginas blancas, se incluyó información de contacto (extensión telefónica, dirección postal, correo electrónico, etc.), así como una fotografía personal.

dn: UID=jferragut,ou=people,dc=uib,dc=estelephoneNumber: 971172334 mail: [email protected] givenName: Jaime objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson cn: Jaime Ferragut Martinez-Vara de Rey UID: jferragut postalAddress: Campus Universitari. description: Technical Staff sn: Ferragut Martinez-Vara de Rey userCertificate:: MIIDfz... jpegPhoto:: /9j/4AAQS...

Uno de los puntos más críticos del proceso inicial de carga fue la inclusión del atributo mail en cada una de las entradas LDAP de los profesores. En la experiencia piloto, este atributo no sólo se utilizaba como mecanismo para el almacenamiento de la dirección de correo electrónico, sino también como fuente de información para la generación de las credenciales digitales. En previsión de la utilización del protocolo S/MIME

para el envío de las actas académicas, era estrictamente necesario que en el campo Subject Name de los certificados figurara, además de otros valores, el atributo E (e-mail) con la dirección de correo electrónico del profesor. En este sentido era fundamental mantener la consistencia entre los datos contenidos en el directorio y la configuración de los clientes de correo electrónico de los profesores. La falta de sintonía entre estas dos fuentes de información podía producir errores graves en la verificación de las actas académicas firmadas digitalmente. Por otra parte, al tratarse de una experiencia piloto, no se definieron Instrucciones de Control de Acceso (ACI, Access Control Instructions) sobre los objetos almacenados en el directorio LDAP.

C. Modificaciones en ÁGORA:Para la generación dinámica y posterior descarga de las

actas académicas en formato PDF era necesario modificar sensiblemente el código de la aplicación de gestión académica. Por un lado, ÁGORA provee una interfaz web para la interacción de los profesores. Por otro lado, el Centre de Tecnologies de la Informació mantiene la base de datos de información académica de la Universitat de les Illes Balears. El Piloto de Firma Digital pretendía conectar estos dos elementos para que un profesor pudiera descargar vía web un acta académica a partir de los registros almacenados

cn=xoliva

cn=tserra

dc=uib, dc=es

ou=People

cn=tsola

Rama de configuración de los servidores SunONE

o=NetscapeRoot

Rama de publicación


en la base de datos. La solución de implementación escogida se apoyó en la

utilización del componente Report Server de ORACLE. Este servidor escucha peticiones de los clientes con el objetivo de recuperar registros de una base de datos y consolidarlos posteriormente en un único fichero. En el esquema diseñado para la experiencia piloto, el profesor, a través de la interfaz web de ÁGORA, proporcionaba a Report Server la información necesaria para poder lanzar un proceso reportcontra la base de datos académica. A partir de la terna {código de la asignatura, convocatoria, grupo} Report Server atacaba a la base de datos, recuperaba los registros correspondientes al acta y generaba automáticamente un fichero PDF con toda la información. Finalmente, ÁGORA

enviaba dicho fichero al ordenador del profesor. Como medida de seguridad adicional, un profesor sólo podía generar actas en PDF de asignaturas en las que tuviera responsabilidades docentes durante ese curso académico.

En el Piloto de Firma Digital de Actas Académicas se definieron las siguientes transacciones de información entre aplicaciones:

1.- A través de la versión web de ÁGORA, el profesor seleccionaba la terna {código de la asignatura,convocatoria, grupo} y ejecutaba la operación de descarga.

2.- ÁGORA enviaba estos parámetros de búsqueda a la aplicación Report Server de ORACLE.

3.- Con estos parámetros, Report Server construía una llamada a un procedimiento PL/SQL almacenado en la base de datos de información académica.

4.- La base de datos devolvía a Report Server los registros seleccionados por el procedimiento de búsqueda.

5.- Report Server consolidaba estos registros en un único documento PDF y lo remitía a ÁGORA.

6.- Finalmente, ÁGORA enviaba el documento PDF al ordenador del profesor.

Al margen de la configuración de Report Server, la versión web de ÁGORA necesitaba ser modificada para incorporar estas nuevas funcionalidades. Particularmente, las modificaciones llevadas a cabo se limitaron a la programación de nuevos formularios web para la selección de los parámetros de búsqueda y a la implementación de los procesos de comunicación con Report Server. La fig. 6 muestra la interfaz web de la nueva versión de ÁGORA.

Fig. 6. Interfaz web de la nueva versión de ÁGORA

D. Política de backups: En previsión de fallos en los sistemas que soportan los

servicios de la Infraestructura de Clave Pública, para el Piloto de Firma Digital de Actas Académicas se escogió una política de backups híbrida. Esta política suponía la realización de imágenes binarias del sistema informático y copias de seguridad de los servidores de la PKI.

1) Imágenes binarias: Una vez instalado y configurado el SGCD, se procedió a

la realización de una nueva imagen binaria de la partición de sistema operativo. El archivo resultante se almacenó tanto en la partición de datos (FAT32) como en un CD. En caso de producirse errores graves en el funcionamiento del sistema operativo y las aplicaciones instaladas, se recuperaría el estado inicial de SunONE Certificate Server con sólo lanzar esta imagen.

2) Copias de seguridad de los datos: Todos los servidores de SunONE Certificate Server

incorporan funciones para la realización de copias de seguridad de sus configuraciones. En la experiencia piloto, al finalizar los procesos de configuración de la Autoridad de Certificación y carga inicial del directorio LDAP, se procedió a la realización de un backup completo de la información. El archivo resultante se almacenó tanto en la partición de datos del equipo informático, como en un CD. Gracias a este archivo, la operación de restauración de SunONE Certificate Server permitiría recuperar una estructura de PKI totalmente adaptada a las necesidades del Piloto de Firma Digital de Actas Académicas.

Una política basada en imágenes binarias permite recuperar con cierta rapidez estados estables del sistema operativo y las aplicaciones de usuario. Por otra parte, la realización de backups periódicos de la información contenida en dichas aplicaciones permite preservar tanto la configuración de los subsistemas de la PKI como los datos de usuario almacenados en ellos. Tras un fallo catastrófico, una estrategia basada en la utilización conjunta de estas dos medidas garantiza la recuperación de toda la estructura PKI en poco tiempo.

VI. RESULTADOS

La primera experiencia de firma digital de actas académicas se llevó a cabo en el mes de septiembre de 2002. Posteriormente, y hasta finales de julio de 2003, se continuó trabajando en el desarrollo del Piloto de Firma Digital de Actas Académicas. En esta sección se describen los resultados obtenidos durante este tiempo.

A. Profesores participantes: De los doce profesores participantes sólo ocho eran

titulares de sus asignaturas, por lo que el conjunto real de firmantes se redujo de doce a ocho. De estos ocho profesores, un total de cuatro firmaron digitalmente sus actas académicas. De los cuatro restantes, uno sufrió problemas técnicos a la hora de generar sus credenciales digitales, uno no pudo firmar su acta al ser cofirmada y dos no completaron el proceso de firma digital de forma voluntaria.

B. Problemas en la generación de certificados digitales: En el caso del sistema operativo Windows, SunONE

Certificate Server se apoya en la utilización de la librería de enlace dinámico xenroll.dll para la generación de los pares


de claves RSA y la construcción de los mensajes PKCS#10 de solicitud de certificados digitales. De esta forma, cuando un usuario rellena los campos del formulario web de la Autoridad de Certificación y ejecuta una operación Submit,un pequeño código Javascript/VisualBasic embebido en el formulario web invoca a la librería xenroll.dll para que genere los pares de claves y construya la estructura PKCS#10.

Todas las librerías de enlace dinámico se encuentran registradas unívocamente en Windows mediante identificadores de clase, o ClassID. Un ClassID es una secuencia de dígitos y letras a los que se debe hacer referencia para poder invocar a una librería dinámica. Para xenroll.dll, su ClassID es 43F8F289-7A20-11D0-8F06-00C04FC295E1.

En el caso de que los usuarios finales utilicen el navegador Internet Explorer, todos los formularios web de solicitud de certificados digitales incorporan pequeños scripts de VisualBasic con las siguientes líneas:

<OBJECT classid=”clsid:43F8F289-7A20-11D0-8F06-

00C04FC295E1” CODEBASE=”/xenroll.dll” Id=Enroll>

</OBJECT>

Esta porción de código permite invocar a los módulos CSP (Cryptographic Service Provider) internos de Windowspara seleccionar la longitud del par de claves RSA.

Los problemas técnicos aparecieron cuando algunos profesores usuarios de Internet Explorer no fueron capaces de visualizar la lista de proveedores criptográficos. En el formulario web de solicitud proporcionado por la Autoridad de Certificación desaparecía la lista desplegable que permitía seleccionar el módulo CSP con el que se iba a generar el par de claves RSA. Al no poder seleccionar ningún proveedor criptográfico, el navegador web mostraba un mensaje de error y abortaba el proceso de generación de claves.

Tras algunas investigaciones, finalmente se pudo dar con el error. En el documento [3] Microsoft notificaba un error en el diseño de la librería de enlace dinámico xenroll.dll.Esta vulnerabilidad permitía que código malicioso incrustado en páginas web borrara y añadiera certificados digitales en la base de datos del navegador sin el consentimiento expreso del usuario. Microsoft publicó y distribuyó un parche de seguridad (Q323172) que deshabilitaba la antigua xenroll.dll y proporcionaba una nueva versión de la librería. Sin embargo, esta nueva versión de xenroll.dll contaba con un ClassID diferente, por lo que había que actualizar las referencias en los formularios web de SunONE Certificate Server. De no ser así, el código VisualBasic apuntaría a una xenroll.dll inoperante debido a la existencia de una nueva versión.

Las modificaciones realizadas sobre los formularios web de SunONE Certificate Server para hacer referencia a la nueva versión de la librería xenroll.dll son las siguientes:

Antes de la aplicación del parche:

<OBJECT classid=”clsid:43F8F289-7A20-11D0-8F06-

00C04FC295E1” CODEBASE=”/xenroll.dll” Id=Enroll> </OBJECT>

Después de la aplicación del parche:

<OBJECT classid=”clsid:127698e4-e730-4e5c-a2b1-

21490a70c8a1”

CODEBASE=”/xenroll.cab#Version=5,131,3659,0”

Id=Enroll>

</OBJECT>

De esta forma, se preparó el SGCD para mostrar los proveedores criptográficos a todos los clientes que hubieran actualizado su sistema operativo con el parche de seguridad Q323172 de Microsoft. Además, se incluyó en los formularios un mensaje de advertencia que informaba a los usuarios de los pasos a seguir en caso de no visualizar la lista de CSP.

Por otra parte, los profesores que no utilizaron el sistema operativo Windows también se encontraron con problemas técnicos del mismo tipo. En estos casos el error era evidente, ya que SunONE Certificate Server invocaba a una librería de enlace dinámico que no existía en el sistema operativo.

SunONE Certificate Server está optimizado para navegadores Netscape Communicator 4.79 e inferiores. La instalación de estos clientes web proporciona su propio módulo PKCS#11 interno para la generación de pares de claves y mensajes de solicitud de certificados digitales. Los formularios web de SunONE Certificate Server incluyen pequeños códigos Javascript que permiten seleccionar la longitud de la clave RSA a generar (512, 1024 y 2048 bits). Al igual que en el caso anterior, en la implementación de estos códigos Javascript se pone de manifiesto una excesiva personalización para los navegadores Netscape Communicator 4.79 o inferiores. Durante el desarrollo del Piloto de Firma Digital de Actas Académicas, los profesores que accedían a las interfaces web de la Autoridad de Certificación con Netscape 6.0 o superiores no eran capaces de visualizar las longitudes de clave disponibles.

Para solucionar este problema se estudió la forma en la que el código Javascript generaba la lista de longitudes de clave posibles. SunONE Certificate Server sólo mostraba la lista desplegable si el navegador Netscape del cliente cumplía el siguiente condicional:

si (versión_navegador 3) o(versión_pkcs#11 = no_definida) entonces mostrar_lista_desplegable;

fsi;Para navegadores Netscape 4.79 e inferiores esta

condición siempre se cumplía. En cambio, el condicional fallaba con Netscape 6.0 y superiores, por lo que la lista desplegable con las longitudes de clave no aparecía. La tabla II muestra los valores obtenidos tras introducir algunas trazas en el código Javascript.

TABLA IICOMPARATIVA DE ATRIBUTOS INTERNOS DE NETSCAPE 4.79 Y 7.0

Navegador Versión Versión PKCS#11

Netscape 4.79 3 No definida

Netscape 7.0 5 2.3

Como se puede comprobar, Netscape 7.0 no cumplía


ninguna de las dos condiciones para mostrar la lista de longitudes de claves. Para solucionar este problema, se definió un nuevo condicional que se adaptara a los valores proporcionados por las últimas versiones de los navegadores Netscape:

si (versión_navegador 5) o(versión_pkcs#11 = 2.3) entonces mostrar_lista_desplegable;

fsi;Las modificaciones realizadas en el código Javascript

para permitir la visualización de la lista de longitudes de clave son las siguientes:

Antes de la aplicación del parche:

if (navigator.appName == 'Netscape') { if (navMajorVersion() <= 3 ||

typeof(crypto.version) == 'undefined') { document.write('<KEYGEN

name="subjectKeyGenInfo">'); } }

Después de la aplicación del parche:

if (navigator.appName == 'Netscape') { if (navMajorVersion() <= 5 ||

typeof(crypto.version) == 2.3) { document.write('<KEYGEN

name="subjectKeyGenInfo">'); } }

C. Tratamiento de las actas cofirmadas: Uno de los profesores participantes en la experiencia

piloto era responsable del 50% de la docencia y evaluación de una asignatura, lo que implicaba la introducción del concepto de acta cofirmada (acta que debe ser firmada por más de un profesor). Aunque existen esquemas para implementar este tipo de firmas, estos documentos suponían una excepción que complicaban la dinámica del Piloto, por lo que finalmente la asignatura en cuestión quedó excluida de los procesos de firma digital.

Al término de la experiencia piloto se inició una línea de trabajo con el objetivo de estudiar el tratamiento de firmas jerárquicas o paralelas sobre documentos digitales. El objetivo era determinar si la estructura PKCS#7 de RSALaboratories permitía la existencia de firmas anidadas sobre un mismo contenido.

La estructura de datos PKCS#7, descrita en ASN.1(Abstract Syntax Notation One) en el documento [4], define un contenedor para el almacenamiento de información con criptografía aplicada (documentos firmados y/o cifrados). A modo de resumen, PKCS#7 define dos estructuras complementarias: SignedData y EnvelopedData. La primera de ellas permite almacenar información junto con su correspondiente firma digital, la segunda almacena datos que han sido sometidos a procesos de cifrado.

PKCS#7 contempla la inclusión de atributos arbitrarios en su estructura, como el instante de firma (SigningTime), o refrendatas (Countersignatures). La existencia de este último atributo sugiere la posibilidad de utilizar estructuras PKCS#7 SignedData como almacenes de información con múltiples firmas digitales asociadas. No obstante, el diseño y la implementación de un sistema de firma digital de actas

cofirmadas excedían los objetivos de esta experiencia piloto. El estudio realizado sobre el estándar PKCS#7 arrojó un

resultado interesante. En la página 13 del documento [4] se encontró un error en la definición ASN.1 de la estructura de datos PKCS#7. En un párrafo de este documento se confundían los tipos de datos SignerInfo (información relativa al firmante) y SignedData (información sobre la que se efectuaba la firma digital). Localizado y contrastado el error, se procedió a la notificación del mismo al personal de RSA Laboratories, responsables últimos de la edición y publicación de los estándares PKCS. La respuesta oficial de RSA Laboratories reconocía la existencia del error y garantizaba su subsanación en sucesivas versiones del documento.

D. Interacción de SunONE CS con navegadores web: En el entorno de trabajo de la Universitat de les Illes

Balears, el Piloto de Firma Digital de Actas Académicas fue la primera experiencia de interacción entre diferentes navegadores web y la solución PKI SunONE Certificate Server.

Los profesores participantes en la experiencia piloto constituían un buen entorno de pruebas para evaluar la interacción web de SunONE Certificate Server. Antes del lanzamiento del Piloto no se esperaba ningún tipo de problema técnico derivado del uso de los navegadores. No obstante la experiencia demostró que éste sería, precisamente, el mayor foco de problemas.

Como ya se ha comentado, la generación de los pares de claves RSA y la construcción de los mensajes de solicitud de certificados digitales son responsabilidades de los módulos CSP y PKCS#11. Para invocar a estos componentes software, los desarrolladores de SunONE Certificate Server insertaron código Javascript/VisualBasicen los formularios web de interacción con los usuarios finales.

E. Integración de los certificados en clientes de correo: Los certificados digitales expedidos por SunONE

Certificate Server cumplían el estándar X.509 versión 3 de la ITU-T, por lo que su integración en los clientes de correo electrónico tradicionales (Outlook, Outlook Express,Netscape Messenger, Netscape Mail, etc.) fue totalmente transparente.

En la Experiencia Piloto de Firma Digital de Actas Académicas no se produjo ningún problema técnico relacionado con el uso de clientes de correo electrónico. Sin embargo el estudio de las diferentes soluciones de implementación arrojó algunos resultados en lo que a prestaciones se refiere. A continuación se presentan algunos de ellos.

1) Microsoft Outlook y Outlook Express: La integración de certificados digitales X.509 en estos

clientes de correo resulta muy sencilla para el usuario. Las aplicaciones Internet Explorer, Outlook y Outlook Express comparten la misma base de datos de certificados digitales, por lo que cualquier credencial importada desde InternetExplorer es automáticamente reconocida por todos los clientes de correo de Microsoft. No obstante, Outlook yOutlook Express incorporan asistentes para la importación de certificados digitales almacenados en archivos .cer o .pfx.

A nivel de rendimiento, estas aplicaciones se muestran


lentas cuando proceden al envío o recepción de mensajes con criptografía aplicada. Es frecuente que un cliente de correo Outlook u Outlook Express tarde algunos segundos al intentar visualizar el contenido de un mensaje firmado o cifrado.

Ambos clientes de correo incorporan soporte para servicios de directorio. Tanto Outlook como Outlook Express permiten conectar la libreta de direcciones a un directorio LDAP, de tal forma que las búsquedas por nombre, apellidos, dirección de correo electrónico, etc. se realicen de forma remota. Sin embargo, en ambas aplicaciones no está automatizada la importación de certificados digitales desde directorios LDAP. Esto implica que el usuario debe descargar el certificado digital de otro usuario en el sistema de archivos local y proceder, a través de un asistente, a su instalación en la base de datos de certificados.

Para comprobar la autenticidad del correo electrónico, Outlook Express compara el campo From de las cabeceras SMTP con el atributo E-mail del titular del certificado digital adjunto al mensaje. Inexplicablemente, Microsoft Outlookno lleva a cabo esta comprobación.

2) Netscape Messenger y Netscape Mail: Netscape Messenger es el cliente de correo electrónico

incluido de serie en los navegadores Netscape Communicator 4.79 e inferiores. Netscape Mail aparece como componente estándar de Netscape 6.0 y versiones superiores. Al igual que en el ejemplo anterior, ambos clientes de correo comparten la base de datos de certificados digitales con sus respectivos navegadores web. También permiten la importación de certificados digitales a través de un sencillo asistente.

En cuanto al cómputo de operaciones criptográficas, el rendimiento de estas dos aplicaciones es bastante mejor que el de Outlook y Outlook Express. Netscape Messenger yNetscape Mail no sufren retardos significativos al enviar o recibir mensajes de correo electrónico S/MIME.

Estos dos clientes de correo soportan la interacción con servicios de directorio basados en el protocolo LDAP. Al igual que Outlook y Outlook Express, la libreta de direcciones puede conectarse a un servidor LDAP para realizar búsquedas y recuperar información de forma remota. Sin embargo, Netscape Messenger y Netscape Mail permiten importar certificados digitales desde el directorio de forma automática, por lo que el usuario no tiene que preocuparse de descargarlos en el sistema de archivos local e importarlos en el cliente de correo. Con respecto a la comparación de las cabeceras SMTP con la información contenida en el certificado, ambos clientes de correo verifican que el emisor del mensaje se corresponde con el titular del certificado digital.

3) Otros clientes de correo electrónico: Al margen de los mencionados anteriormente, también se

realizaron pruebas de importación de certificados digitales expedidos por SunONE Certificate Server con el cliente de correo electrónico The Bat. Los resultados fueron satisfactorios y nuevamente pusieron de manifiesto la perfecta integración de este tipo de certificados con las aplicaciones de navegación y correo electrónico.

VII. CONCLUSIONES

La conclusión más destacable del trabajo realizado se resume en una frase: los objetivos propuestos se han cumplido satisfactoriamente.

1.- El Piloto de Firma Digital de Actas Académicas ha supuesto la primera experiencia real de implementación de una PKI en el entorno de producción de la Universitat de les Illes Balears.

2.- Tras el cierre definitivo del periodo de firmas, se inició una ronda de contactos con los profesores participantes y el personal de Secretaría Académica para recabar todo tipo opiniones y experiencias:

Por parte del colectivo de PDI, los resultados fueron muy satisfactorios, destacando sobre todo la comodidad que suponía canalizar todos los procesos de la gestión académica a través de la aplicación ÁGORA.

El personal de Secretaría Académica se manifestó mayoritariamente a favor de la reducción de los trámites administrativos y a la eliminación de los flujos de documentación en papel.

3.- La realidad de una implementación es muy diferente al panorama descrito por las recomendaciones técnicas. Existe una gran diferencia entre el estudio de las normas, protocolos y estándares que rigen las Infraestructuras de Clave Pública y la implementación de un modelo sencillo de PKI como soporte tecnológico a una experiencia piloto de identidad digital. La mayor parte de la problemática de una PKI se deriva de la necesidad de que aplicaciones de naturaleza heterogénea se comuniquen entre sí correctamente para servir a una comunidad de usuarios.

4.- Se ha realizado un profundo análisis y evaluación de diferentes soluciones PKI, directorios LDAP y tokensexternos, recogido en el documento [5]. Uno de los principales problemas con el que se encuentran los desarrolladores de Infraestructuras de Clave Pública es la escasez de información a la hora de seleccionar un entorno de desarrollo. La experimentación con diferentes Sistemas Gestores de Certificados Digitales ha arrojado una visión del estado del arte y ha contribuido activamente a la generación de conocimiento.

5.- El Piloto de Firma Digital de Actas Académicas se presentó oficialmente en los Grupos de Trabajo y Jornadas Técnicas de RedIRIS, Red Española de I+D+i, celebrados el mes de noviembre de 2002 en la Universidad de Salamanca. Para ello se optó por un doble formato: por un lado, se presentó como ponencia en los Grupos de Trabajo; por otro lado, se diseñó y exhibió como póster [6] en las Jornadas Técnicas. Dicho póster se publicó posteriormente en los números 62-63 de los boletines de la Red Española de I+D+i. Además se llevaron a cabo diversas presentaciones en las instalaciones del CTI@UIB para responsables de instituciones como Santander Central Hispano, la Universidad Autónoma de Barcelona o los directores de los Servicios de Informática del Grupo 9 de Universidades2.

6.- El Piloto de Firma Digital de Actas Académicas puso de manifiesto que la implementación de una PKI en un entorno universitario afecta a un gran número de agentes:

Se requiere un gran esfuerzo para diseñar e

2 El Grupo 9 de Universidades es una asociación sin ánimo de lucro

formada por las universidades públicas de Islas Baleares, Zaragoza, La Rioja, Navarra, País Vasco, Cantabria, Oviedo, Extremadura y Castilla La Mancha constituida en el convenio firmado el 16 de mayo de 1997.


implementar la plataforma tecnológica de identidad digital. Hay que transmitir la confianza necesaria a los órganos

directivos de la universidad para introducir nuevos mecanismos en los procesos de gestión académica.

Es necesario formar al personal (tanto PDI como PAS) en la utilización de técnicas de identidad digital.

Es necesario contar con el respaldo y la labor consultiva de los servicios legales de la universidad para dotar a todos los procesos de un estatus comparable al de la firma manuscrita.

En resumen, una experiencia piloto como la puesta en práctica por la Universitat de les Illes Balears no sirve únicamente como método de experimentación con soluciones PKI, sino también como mecanismo para localizar y evaluar problemáticas en una futura extensión del servicio al conjunto de la comunidad universitaria. La experiencia ha demostrado que los esfuerzos realizados en el plano humano y organizativo son notablemente superiores a los esfuerzos técnicos de implementación.

VIII. LÍNEAS DE TRABAJO FUTURO

Como ya se ha comentado, el trabajo realizado a lo largo de esta experiencia piloto ha permitido generar una gran cantidad de conocimiento práctico en el ámbito de la certificación digital y las Infraestructuras de Clave Pública. Al término del Piloto de Firma Digital de Actas Académicas se plantearon numerosas líneas de trabajo futuro, muchas de ellas se desarrollaron durante fases posteriores del proyecto. Sin embargo, la implementación de una PKI en un entorno real de producción es un complejo proceso con implicaciones no sólo técnicas, sino también organizativas, humanas y legales. En esta sección se presentan las líneas de trabajo para seguir avanzando hacia la consecución de una implementación real de PKI en un entorno universitario.

Para cumplir con la RFC 2527 [2], es necesario desarrollar una Política de Certificación que describa formalmente todos los detalles del servicio de PKI ofrecido por el Centre de Tecnologies de la Informació. Además, es necesario redactar una Declaración de Prácticas (CPS, Certificate Policy Statement) que determine con exactitud los usos atribuidos a los certificados digitales. Tanto la CP como la CPS deben publicarse en Internet. También es recomendable añadir una extensión X.509 versión 3 en los certificados para incluir un URL (Universal Resource Locator) que apunte a la Política de Certificación.

El Real Decreto Ley 14/1999 sobre firma electrónica [7] fija unas obligaciones extraordinariamente amplias y estrictas para los Prestadores de Servicios de Certificación Digital. Aunque la Infraestructura de Clave Pública del Centre de Tecnologies de la Informació actúe sobre un entorno cerrado, es conveniente realizar un estudio de estas leyes y aplicar las conclusiones a la implementación desarrollada.

Uno de los aspectos más importantes en una Infraestructura de Clave Pública es la seguridad de los sistemas informáticos y de las aplicaciones que la integran. En este sentido, es conveniente utilizar redes virtuales (VLAN, Virtual LANs), o mecanismos equivalentes, para aislar a los sistemas críticos de la PKI de la red pública de la Universitat de les Illes Balears, ubicar los equipos informáticos en salas de máquinas con acceso restringido, filtrar los puertos de los servidores mediante firewalls,analizar periódicamente los archivos de logs, etc.

En cuanto a la interacción de las aplicaciones con tokensexternos, es interesante abrir una línea de trabajo que apueste por el desarrollo de un módulo PKCS#11 propio. Para ello, es necesario realizar un profundo estudio técnico del parque de tarjetas inteligentes de la UIB, evaluando aspectos como la estructura de ficheros de cada modelo, las prestaciones de memoria, el sistema operativo, etc. Este estudio debe conducir a la implementación de una librería de funciones PC/SC (Personal Computer/SmartCard) que interactúen directamente con las tarjetas inteligentes y puedan ser invocadas desde el módulo PKCS#11.

Otro aspecto interesante para contribuir a la mejora y ampliación de la PKI es el desarrollo de un servicio de consultas OCSP (Online Certificate Status Protocol) como alternativa a las Listas de Certificados Revocados. En este sentido, la herramienta SunONE Certificate Server incluye soporte para OCSP, tanto en el componente Certificate Manager como en Registration Manager.

Para favorecer la interoperabilidad de los certificados emitidos, es conveniente establecer relaciones de certificación digital con Infraestructuras de Clave Pública de orden superior, como por ejemplo, RedIRIS-PKI3. Además, desde el punto de vista organizativo, la solicitud de una rama propia de OID contribuye a la definición formal de la PKI y al registro de los atributos y clases de objeto propietarios.

Una buena medida para contribuir a la difusión de los servicios de identidad digital en la comunidad universitaria, es el desarrollo de un portal web de certificación. Este portal permitiría a los usuarios conocer la estructura y el funcionamiento de la PKI, solicitar certificados digitales de prueba, acceder a la Política de Certificación y a la Declaración de Prácticas, navegar por el servicio de páginas blancas, remitir consultas a los responsables técnicos, etc.

Tras la finalización del Piloto de Firma Digital de Actas Académicas, uno de los problemas que suscitó mayor interés fue el de la modificación de documentos firmados digitalmente. Para resolverlo, en un primer momento se pensó en una estructura anidada de contenedores PKCS#7 en los que se encapsulara la pareja {documento, firma digital}. Otra estrategia apostaba por la definición de una estructura ASN.1 en la que se incluyera la información contenida en el documento original junto con las sucesivas firmas y modificaciones. En cualquier caso el hecho de modificar y anidar firmas digitales a documentos ya firmados constituye una línea de trabajo interesante.

En relación con las actas académicas, al finalizar la experiencia piloto se abrió una línea de desarrollo para buscar alternativas a la utilización de clientes de correo electrónico en el esquema de firma digital. El objetivo era desarrollar un applet JAVA que implementara las operaciones de descarga, firma y envío del acta a la base de datos de información académica. Este applet se ejecutaría automáticamente al acceder a la interfaz web de ÁGORA, de tal forma que el profesor no tuviera que utilizar aplicaciones adicionales. Gracias a la portabilidad de JAVA, se contribuiría a la desaparición de los problemas derivados de la utilización de navegadores y clientes de correo específicos. En el documento [6] se describe con detalle esta

3 RedIRIS-PKI certifica única y exclusivamente las claves públicas de

aquellas Autoridades de Certificación ubicadas en organismos e instituciones de la comunidad RedIRIS.


estrategia de firma digital de actas académicas.

IX. AGRADECIMIENTOS

Los autores agradecen las contribuciones de M. Canals, J. L. Ferrer Gomila, C. Malagón, J. Masa, M. Bolado y de todo el personal técnico del Centre de Tecnologies de la Informació de la Universitat de les Illes Balears durante las fases de análisis, diseño e implementación de esta experiencia piloto.

Igualmente los autores agradecen la colaboración de T. Jiménez, J. Gil, J. García, J. J. Meseguer, S. Navarro y de todo el Servicio de Informática de la Universidad de Murcia por compartir los resultados de su trabajo.

X. REFERENCIAS

[1] R. Housley, W. Ford, W. Polk, D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”. IETF Request for Comments #2459 (online). Enero de 1999, consultado el 20 de febrero de 2003. http://www.ietf.org/rfc/rfc2459.txt

[2] S. Chokhani, W. Ford, “X.509 Internet Public Key Infrastructure Certificate Policy and Certification Practices Framework”. IETFRequest for Comments #2527 (online). Marzo de 1999, consultado el 9 de junio de 2003. http://www.ietf.org/rfc/rfc2527.txt

[3] Microsoft Technet, “Microsoft Security Bulletin MS02-048: Flaw in Certificate Enrollment Control Could Allow Deletion of Digital Certificates (Q323172)”. Microsoft Technet Security Bulletin (online).Agosto de 2002, consultado el 20 de junio de 2003. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-048.asp

[4] RSA Laboratories, “PKCS#7: Cryptographic Message Syntax Standard, v1.5”. Nota técnica de RSA Laboratories (online).Noviembre de 1993, consultada el 20 de junio de 2003. ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc

[5] J. Ferragut, “Implementación de una Infraestructura de Clave Pública en la Universitat de les Illes Balears”. Proyecto Fin de Carrera. Julio de 2003.

[6] B.Serra, J. Ferrer, M. Canals, J. Ferragut, “Piloto de Firma Digital de Actas Académicas”. Boletín de RedIRIS, Red Nacional de I+D+i, núm. 62-63 (online). Diciembre 2002-enero 2003. http://www.rediris.es/rediris/boletin/62-63/poster.pdf

[7] Boletín Oficial del Estado, “REAL DECRETO-LEY 14/1999, de 17 de septiembre, sobre firma electrónica”. BOE núm.224, pág.33593 (online). Septiembre de 1999, consultado el 9 de junio de 2003. http://www.boe.es/boe/dias/1999-09-18/pdfs/A33593-33601.pdf


XI. BIOGRAFÍAS

Jaime Ferragut Martínez-Vara de Rey

nació en Palma de Mallorca, España, el 16 de abril de 1978. Es Ingeniero Técnico de Telecomunicación por la Escola Politècnica Superior de la Universitat de les Illes Balears. Actualmente colabora en el Departamento de Ingeniería Telemática de la Universitat Politècnica de Catalunya.

Durante tres años trabajó en el Centre de Tecnologies de la Informació de la Universitat de

les Illes Balears como miembro del equipo responsable del Proyecto Piloto de Certificación Digital. Sus principales áreas de interés son la criptografía, las Infraestructuras de Clave Pública y la seguridad en redes de comunicaciones.

Bartomeu J. Serra Cifre es doctor en Ciencias por la Universitat de les Illes Balears desde 1984 y Catedrático del área de Ciencias de la Computación e Inteligencia Artificial de la misma universidad desde el año 1991.

Ha sido fundador y director durante más de 20 años del Centro de Tecnologías de la Información de la UIB (1983-2003). En la actualidad, además de la docencia e investigación que realiza desde su Cátedra de la Escuela Politécnica Superior de

la UIB, colabora con diferentes instituciones públicas y privadas en la implantación de las Tecnologías de la Información y las Comunicaciones en la Comunidad Autónoma de las Islas Baleares.


Experiencia Piloto de Firma Digital de Actas Académicas · La firma digital de actas académicas...

Documents

Transcript of Experiencia Piloto de Firma Digital de Actas Académicas · La firma digital de actas académicas...