IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO.

2, APRIL 2005

205

Experiencia Piloto de Firma Digital de Actas Acadmicas

J. Ferragut Martnez-Vara de Rey, B. Serra Cifre, Universitat de les Illes Balears, Espaa


Resumen La irrupcin de la criptografa en el mundo de las telecomunicaciones ha supuesto una explosin de nuevos servicios. Uno de los desarrollos que ms ha contribuido a esta expansin ha sido la tecnologa de la identidad digital. La madurez de esta tecnologa y su avanzado estado de implementacin han permitido dibujar nuevas formas de comunicacin en la sociedad. Sin embargo, la aplicacin 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 aplicacin y realizar un estudio de los requerimientos tcnicos, humanos y organizativos que supone la entrada en funcionamiento de este tipo de servicios. En este artculo se presenta la experiencia de implementacin de una solucin de identidad digital aplicada al entorno de la Universitat de les Illes Balears. Palabras clave Autoridad de Certificacin, certificado digital, criptografa de clave pblica, directorio LDAP, firma digital, Infraestructura de Clave Pblica.

ahora en adelante, UIB), la mayora de procesos relacionados con el tratamiento de la informacin acadmica ya haban sido informatizados. No obstante, la firma manuscrita del profesor segua siendo necesaria para dotar al documento final de validez acadmica. II. OBJETIVOS Y PLANIFICACIN El principal objetivo de la experiencia piloto era el de profundizar en la utilizacin de la criptografa de clave pblica como mecanismo para simplificar al mximo los trmites acadmicos que supone la firma de actas. Una vez implementado, el nuevo proceso de validacin digital evitara desplazamientos de profesores, agilizara los trmites y convertira al actual aplicativo GORA (Aplicatiu de Gesti de lORganitzaci Acadmica) en una herramienta que integrara todos los procesos de la gestin acadmica. La firma digital de actas acadmicas se apoyaba en dos grandes lneas de desarrollo: en primer lugar era necesaria la puesta en marcha de una Infraestructura de Clave Pblica como elemento generador de confianza y mecanismo de certificacin digital al servicio de los colectivos de PAS (Personal de Administracin y Servicios) y PDI (Personal Docente e Investigador). En segundo lugar, y para minimizar el impacto sobre la estructura existente, era preciso disear un sistema que permitiera a los profesores enviar, de forma segura, las actas firmadas digitalmente al personal de Secretara Acadmica. 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 acadmico 2001-2002. Las sucesivas secciones describen la experiencia de trabajo de la primera fase, lo que se dio a conocer pblicamente como el Piloto de Firma Digital de Actas Acadmicas. A esta primera fase le sigui una segunda cuyo objetivo era el de consolidar los resultados obtenidos en la implementacin de una PKI de mbito universitario. III. ANLISIS DE REQUERIMIENTOS Para establecer el entorno de trabajo y definir las lneas de implementacin, se organizaron diversas reuniones de coordinacin con el equipo responsable del proyecto. Inicialmente este equipo estaba integrado por el Director y dos tcnicos del Centre de Tecnologies de la Informaci, as como por un profesor del Departamento de Ciencias Matemticas e Informtica. Las siguientes subsecciones describen el anlisis de requerimientos en todas las reas implicadas: Sistema Gestor de Certificados Digitales, tipos de certificados a expedir, utilizacin de tokens externos, eleccin de los profesores participantes, seguridad de la PKI, equipamiento hardware y dinmica de la firma digital

I. INTRODUCCIN 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 implementacin de una Infraestructura de Clave Pblica (de ahora en adelante, PKI) de mbito universitario. El objetivo era doble:

- Generar conocimiento prctico a travs del estudio de la tecnologa actual en el mundo de las Infraestructuras de Clave Pblica. - Construir una plataforma tecnolgica que permitiera la puesta en marcha de futuros servicios basados en certificacin y firma digital. En la operativa diaria de una universidad, todo proceso oficial de evaluacin debe concluir con la firma manuscrita del profesor sobre el acta acadmica de la asignatura. Como parte fundamental de la gestin acadmica, la firma de actas supone una excelente oportunidad para la aplicacin de las nuevas tecnologas en el mbito de la identidad digital. La experiencia piloto del Centre de Tecnologies de la Informaci tena como objetivo informatizar e integrar en un solo proceso las operaciones de generacin, cierre y firma de actas acadmicas con los requerimientos de seguridad que exige una institucin universitaria. En el entorno de trabajo de la Universitat de les Illes Balears (de
Jaime Ferragut Martnez-Vara de Rey es Ingeniero Tcnico de Telecomunicacin por la Escola Politcnica Superior de la Universitat de les Illes Balears (e-mail: jfer3351@alu-etsetb.upc.es). Bartomeu J. Serra Cifre es Catedrtico de Ciencias de la Computacin e Inteligencia Artificial de la Universitat de les Illes Balears (e-mail: tomeu.serra@uib.es).

206

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

de actas acadmicas. A. Sistema Gestor de Certificados Digitales: La eleccin del software que implementara el Sistema Gestor de Certificados Digitales (SGCD) era una decisin importante, ya que iba a definir el entorno de trabajo. En lo que se refiere a este tema, el anlisis de requerimientos arroj las siguientes conclusiones: 1.- La solucin de implementacin para la PKI quedaba a libre eleccin de los responsables tcnicos. No obstante, y como mecanismo para la generacin de conocimiento, surgi la idea de realizar un anlisis comparativo entre diferentes soluciones PKI, tanto comerciales como de cdigo abierto. Finalmente, este conjunto de aplicaciones se redujo a tres soluciones representativas de la tecnologa actual de mercado: Microsoft Windows 2000 Certificate Services, OpenCA y SunONE Certificate Server. 2.- Una de las pocas consideraciones que marc la seleccin del SGCD fue la posibilidad de utilizar mdulos PKCS#11 externos. Esta decisin se tom en vistas a facilitar una futura integracin 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 expedira la Infraestructura de Clave Pblica, se tuvieron en cuenta las siguientes consideraciones: 1.- En la experiencia piloto, la PKI slo expedira certificados digitales de identidad personal con longitudes de clave de 1024 bits. 2.- Para favorecer la integracin con las aplicaciones de usuario, los certificados digitales respetaran la estructura X.509 versin 3 de la ITU-T [1]. No se utilizaran extensiones propietarias. 3.- El periodo de validez de los certificados digitales abarcara los meses de septiembre, octubre y noviembre de 2002. Se escogieron estas fechas porque es en ellas cuando se procede a firmar las actas acadmicas de la convocatoria de septiembre. 4.- Al tratarse de un conjunto controlado de profesores, se podan relajar los mecanismos de verificacin de identidad necesarios para la generacin de los certificados. 5.- Para futuras verificaciones, los certificados digitales se almacenaran en un directorio pblico. C. Utilizacin de tokens externos: Un token externo es un dispositivo fsico que sirve como almacn de credenciales digitales (tarjetas inteligentes, llaves criptogrficas USB, etc.). Para favorecer un desarrollo rpido del Piloto de Firma Digital de Actas Acadmicas, en un primer momento se opt por no utilizar tokens externos. A este respecto, las decisiones tomadas en la fase de anlisis fueron las siguientes: 1.- En cuanto al sistema de firma digital, era necesario buscar soluciones de implementacin de impacto mnimo para los profesores. En el escenario de escogido, la utilizacin de teclados equipados con lector de tarjetas inteligentes complicaba la entrada en funcionamiento de la experiencia piloto (instalacin de drivers, problemas ocasionados por incompatibilidades, cambio de teclados, formacin adicional, etc.) 2.- Frente a la utilizacin de tarjetas inteligentes, la

opcin de almacenar las claves privadas en el propio sistema operativo resultaba menos segura. Sin embargo, esta decisin simplificaba la tarea de los desarrolladores y reduca las molestias para el usuario final. 3.- Al margen de las consideraciones anteriores, se decidi abrir una lnea de trabajo en el rea de tokens externos. El objetivo era generar conocimiento para una futura utilizacin criptogrfica del parque de tarjetas inteligentes bancarias de la UIB. D. Profesores participantes: En la eleccin del conjunto de profesores que se someteran al Piloto de Firma Digital de Actas Acadmicas se tuvieron en cuenta las siguientes consideraciones: 1.- El nmero de profesores participantes deba ser lo suficientemente elevado como para obtener un conjunto de impresiones representativo y lo suficientemente reducido como para que un nico responsable tcnico pudiera atender sus necesidades. 2.- Para impulsar la implantacin y el desarrollo de la experiencia piloto, los profesores participantes deban responder a un perfil tcnico con conocimientos previos en las tecnologas de certificacin y firma digital. 3.- Para favorecer la realizacin y el seguimiento de un considerable nmero 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 Matemticas e Informtica. E. Seguridad de la PKI: En una Infraestructura de Clave Pblica, la seguridad de los sistemas que la integran es crtica. Al tratarse de un entorno de pruebas controlado, el Piloto de Firma Digital de Actas Acadmicas cont con unos requerimientos de seguridad ms relajados que los de una implementacin 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 acadmicas son las siguientes: 1.- El Sistema Gestor de Certificados Digitales deba funcionar sobre un sistema operativo provisto de mecanismos de control de acceso. 2.- El equipo informtico sobre el que trabajara la Autoridad de Certificacin (CA) se ubicara en el Centre de Tecnologies de la Informaci. 3.- El administrador de la PKI deba definir mecanismos de autentificacin para que nicamente los profesores participantes en la experiencia piloto pudieran solicitar certificados digitales. Cualquier otra solicitud sera descartada inmediatamente. 4.- Los profesores nicamente podan firmar las actas correspondientes a sus asignaturas. 5.- El trfico de datos entre las Secretaras Acadmicas y los profesores deba ser autntico y confidencial. 6.- Existira un nico responsable en las Secretaras Acadmicas provisto de identidad digital. Este responsable se encargara del almacenamiento seguro de las actas firmadas digitalmente, as como del envo de los acuses de recibo. 7.- Paralelamente a las Secretaras Acadmicas, el Centre de Tecnologies de la Informaci mantendra una base de datos de backup para las actas acadmicas firmadas. 8.- De forma peridica se realizaran copias de seguridad del Sistema Gestor de Certificados Digitales e imgenes binarias de los equipos informticos de la PKI.

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

207

F. Equipamiento informtico y de comunicaciones: Al tratarse de una experiencia piloto, para la implementacin de la PKI se necesitaba una infraestructura mnima en lo que a comunicaciones y equipos informticos se refiere. Bastaba con un punto de acceso a la red pblica de la Universitat de les Illes Balears, una estacin de trabajo de gama media/alta y una cuenta de usuario en el servidor de correo electrnico de la UIB. Las consideraciones de sistema operativo, software antivirus, soluciones LDAP (Lightweight Directory Access Protocol) y SGCD se discutirn posteriormente en la seccin de implementacin. G. Dinmica de la firma digital de actas acadmicas: Las consideraciones que deban regir el procedimiento por el que un profesor firmaba digitalmente un acta acadmica eran las siguientes: 1.- Haba que tener en cuenta los desarrollos existentes: el profesor obtendra el acta acadmica a travs de la interfaz web segura de GORA. 2.- En lo que respecta al acceso a la informacin, GORA ya incorporaba sus propios mecanismos de autentificacin basados en login y password. 3.- Para simplificar la tarea de los desarrolladores y provocar un impacto mnimo sobre los procedimientos de gestin acadmica, el sistema de firma digital deba integrarse fcilmente en un entorno web o de correo electrnico. 4.- El objetivo principal era evitar desplazamientos de los profesores a las dependencias de Secretara Acadmica. 5.- La Secretara Acadmica deba remitir acuse de recibo a los profesores que hubieran completado correctamente el proceso de firma digital de actas acadmicas. 6.- Los profesores deban tener la posibilidad de analizar detenidamente el contenido del acta antes de firmarla. 7.- Haba que respetar escrupulosamente la dinmica habitual de firma de actas y tener en cuenta las opiniones de los agentes implicados (profesores y personal de Secretara Acadmica). En la prxima seccin se describe el diseo adoptado para la realizacin de la experiencia piloto, tanto en el rea de PKI como en la del sistema de firma digital de actas acadmicas. IV. DISEO DE LA SOLUCIN En la fase de diseo de la experiencia piloto se discutieron aspectos que deban regir desde la arquitectura de la Infraestructura de Clave Pblica hasta el funcionamiento del sistema de firma digital de actas acadmicas. Las decisiones tomadas en estas reas son las siguientes: A. Infraestructura de Clave Pblica: Tomando como punto de partida la existencia de un conjunto muy reducido de usuarios, se adopt la decisin de disear una estructura sencilla para los sistemas integrados en la PKI. Sobre una misma mquina coexistiran los servicios de Autoridad de Certificacin y directorio LDAP. En este diseo no se consider la existencia de Autoridades de Registro, ya que el reducido nmero de usuarios y los mecanismos de autentificacin no las hacan necesarias. El directorio LDAP tendra una doble atribucin en la Infraestructura de Clave Pblica. Por un lado, se

aprovechara como repositorio pblico de los certificados digitales expedidos. Por otro lado, actuara como base de datos para la autentificacin de usuarios durante el proceso de generacin de las credenciales digitales. Cada participante de la experiencia piloto contara con una entrada en el directorio creada previamente por el administrador de la PKI. De forma presencial y confidencial se entregara a cada profesor un sobre con un manual de usuario y la pareja {UID, password} necesaria para autentificarse frente a la PKI. As, slo los usuarios autorizados podran generar sus credenciales digitales a travs de los formularios web provistos por la Autoridad de Certificacin. El administrador de la PKI nicamente debera preocuparse de crear las entradas LDAP para cada usuario y de entregar de forma segura la documentacin. B. Tipos de certificados digitales: Los certificados digitales se adaptaran al estndar X.509 versin 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 tendran validez por un ao y la longitud del par de claves sera de 1024 bits, tanto para profesores como para el personal de Secretara Acadmica. Al tratarse de una experiencia muy acotada en el tiempo, no se consideraran mecanismos de renovacin o revocacin de certificados digitales. Como medida de uniformizacin, los usuarios no deberan introducir sus datos personales en los formularios web de solicitud de certificados digitales. Al proporcionar su UID y password, la Autoridad de Certificacin construira automticamente el campo Subject del certificado tomando como referencia los datos personales contenidos en la correspondiente entrada LDAP. C. Tokens externos: Para favorecer un desarrollo rpido de la experiencia piloto se decidi no trabajar con tokens externos: los certificados digitales se almacenaran de forma segura en el disco duro del ordenador. De igual manera, el personal de Secretara Acadmica tampoco trabajara con tokens externos. Independientemente del mecanismo de control de acceso del sistema operativo se aconsejaba a los usuarios proteger la clave privada con una contrasea. D. Profesores participantes: Para llevar a cabo la experiencia piloto se cont con la colaboracin de 9 miembros del Centre de Tecnologies de la Informaci, 2 profesores del Departamento de Ciencias Matemticas e Informtica y un profesor del Departamento de Derecho Privado. E. Dinmica de la firma digital de actas acadmicas: En el diseo del procedimiento de firma digital se deban respetar escrupulosamente dos principios bsicos: mantener la dinmica de la firma manuscrita e integrar los procesos de firma digital en los clientes web o de correo electrnico. Para cumplir con el primer principio, se decidi trabajar con actas acadmicas en formato Adobe PDF debido a su parecido con el formato papel. Para respetar el segundo principio, se decidi que el flujo de informacin entre los profesores y el personal de Secretara Acadmica se implementara a travs de correos

208

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

electrnicos firmados y cifrados a los que se adjuntaran las actas en formato PDF. Como la prctica totalidad de clientes de correo electrnico implementan el protocolo S/MIME, el impacto de la solucin de firma digital sobre el conjunto de usuarios sera mnimo. El procedimiento por el que un profesor descargaba un acta acadmica, la firmaba digitalmente y la enviaba a Secretara Acadmica se resume en los siguientes cinco pasos: 1.- El administrador de la PKI entregaba en mano al profesor un sobre con la informacin necesaria para generar sus credenciales digitales (UID y password de su entrada en el directorio LDAP). 2.- Mediante una conexin segura, el profesor acceda desde su equipo informtico a un formulario web de la Autoridad de Certificacin, introduca la pareja {UID, password} y automticamente generaba sus credenciales digitales con los datos almacenados en su entrada LDAP. 3.- El profesor acceda a la interfaz web de GORA, se identificaba introduciendo su login/password y solicitaba la descarga de una de las actas acadmicas pendientes de firmar. En ese momento, GORA consultaba la base de datos de gestin acadmica, generaba dinmicamente el archivo PDF y lo enviaba al ordenador del profesor. 4.- El profesor descargaba en su sistema de ficheros el acta acadmica y revisaba detenidamente su contenido. Una vez comprobado, redactaba un correo electrnico firmado y cifrado, adjuntando el archivo PDF. El mensaje S/MIME resultante se remita al personal de Secretara Acadmica.

mensaje de correo electrnico, verificaba la firma digital del profesor sobre el mismo, almacenaba el acta de forma segura y remita 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 permitan verificar sus firmas (certificados digitales de los profesores y de la Autoridad de Certificacin). El diagrama temporal de la fig. 1 describe grficamente el procedimiento de firma digital de actas acadmicas. Cada una de las flechas representa una transaccin de informacin de acuerdo con los cinco pasos anteriormente descritos. V. FASE DE IMPLEMENTACIN Finalizado el diseo del sistema de firma digital y la arquitectura de la PKI, el siguiente paso era la seleccin de la tecnologa para completar la fase de implementacin (equipos informticos, sistema operativo, soluciones PKI y LDAP, etc.) Posteriormente haba que instalar y configurar todos estos componentes para cumplir con los objetivos del Piloto de Firma Digital de Actas Acadmicas. Al margen de estas consideraciones tcnicas, tambin era necesario establecer lneas de dilogo con los profesores y el personal de Secretara Acadmica para perfilar los detalles de implementacin de la experiencia piloto. En esta seccin se describen las decisiones tomadas durante la fase de implementacin; desde aspectos puramente tcnicos hasta consideraciones de tipo organizativo. A. Seleccin de la solucin PKI: Para la implementacin de la experiencia piloto se escogi la solucin PKI SunONE Certificate Server 4.7, en su versin para el sistema operativo Windows 2000 Server. De las soluciones PKI citadas anteriormente, Sun ONE Certificate Server es la ms robusta y completa. Windows 2000 Certificate Services fue descartada por ofrecer una solucin excesivamente vinculada a los sistemas operativos de la familia Microsoft. La solucin de cdigo abierto OpenCA constitua una opcin flexible y barata, pero requera fuertes conocimientos del sistema operativo Linux y del entorno de programacin. Debido a las restricciones temporales de la experiencia piloto, el equipo de desarrolladores no estaba en posicin 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 administracin muy sencilla. El proceso de instalacin era trivial y los esfuerzos de personalizacin se simplificaban enormemente gracias a la utilizacin de mdulos JAVA especficos provistos de interfaces visuales. Adems, el SGCD ya incorporaba el software SunONE Directory Server 5.1 SP1, necesario para la implementacin de un servicio de directorio basado en el protocolo LDAP. Toda la operativa de administracin y mantenimiento de la PKI se canalizaba o bien a travs de interfaces web de gestin, o bien e travs de la consola iPlanet. Esta aplicacin se inclua de serie en el SGCD y permita gestionar los servidores de la suite SunONE. B. Seleccin y preparacin de la plataforma de trabajo: SunONE Certificate Server est disponible para los sistemas operativos Windows NT, 2000 Server y Solaris 8. En la implementacin de la experiencia piloto se escogi la

Admin.PKI

Profesor

CA

GORA

B.DD.

Secr. Acad.

Fig. 1. Procedimiento de firma digital de actas acadmicas

5.- Un responsable de Secretara Acadmica reciba el

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

209

plataforma Intel Pentium II equipada con Windows 2000 Server. Las caractersticas tcnicas 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 tena potencia suficiente como para soportar la estructura PKI del Piloto de Firma Digital de Actas Acadmicas. En cuanto a la preparacin del equipo para la instalacin 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 instalacin 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 instalacin del sistema operativo Windows 2000 Server en su versin inglesa. Numerosos desarrolladores recomiendan la utilizacin 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 Service Pack 2 (SP2) y Service Pack 2 Security Release Package 1 (SP2SRP1). 3.- Finalizada la instalacin de Windows 2000 Server, el siguiente paso fue la realizacin de una imagen binaria del disco de sistema operativo con la aplicacin Ghost de Symantec. Ghost es un pequeo ejecutable capaz de escanear bit a bit un disco duro o particin y almacenar todo su contenido en un fichero comprimido de extensin .gho. Si con el paso del tiempo se produjeran anomalas en el comportamiento del sistema operativo, Ghost proporciona un mecanismo sencillo para la recuperacin del estado inicial. Tan slo hay que arrancar la aplicacin y lanzar sobre el disco duro de sistema operativo la imagen binaria que se realiz justo despus de la instalacin. El nico inconveniente de Ghost es que slo puede volcar imgenes sobre particiones FAT32. Por este motivo se tom la decisin de formatear el disco duro de datos con este sistema de ficheros.

comunicaciones, el equipo fue incorporado a la red de datos - Segunda instancia de Directory Server: al margen del repositorio pblico de informacin, SunONE Certificate Server instala un segundo directorio LDAP que acta como base de datos interna de la Autoridad de Certificacin (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 configuracin se crea un nuevo perfil de administracin responsable de la Autoridad de Certificacin. 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 Certificacin implementa una serie de interfaces web para la gestin de los servicios y la interaccin con los usuarios finales. Para el acceso de administradores y agentes se habilitaron los puertos seguros 8200 y 8100. Para la interaccin con los usuarios finales se habilitaron los puertos 1027 (para conexiones HTTPS) y 1024 (para conexiones HTTP). Dentro del proceso de configuracin se crean los primeros tres certificados de la CA. Estas credenciales internas son necesarias para el correcto funcionamiento de algunos servicios bsicos, como por ejemplo la generacin de certificados digitales de usuario, el establecimiento de conexiones seguras mediante el protocolo SSL o la autentificacin del administrador del CMS frente al sistema. A continuacin se describe cada uno de ellos: - Certificado de autofirma de la CA: La funcin principal de una Autoridad de Certificacin es expedir certificados digitales. Para poder firmarlos, es necesario que la CA genere un par de claves. SunONE Certificate Server almacena la clave privada de la CA en el sistema de ficheros del ordenador o en un token externo. Para el almacenamiento de la clave pblica, la Autoridad de Certificacin crea un certificado autofirmado (los campos Issuer y Subject son idnticos) que liga la clave pblica a su identidad en Internet (Distinguished Name). - Certificado SSL para la CA: SunONE Certificate Server implementa mltiples interfaces de comunicacin seguras. En todas ellas se emplea como mecanismo de transporte el protocolo de comunicaciones SSL. Para proveer autentificacin de servidor, es necesaria la existencia de un certificado de servidor SSL expedido a nombre de la mquina que alberga los servicios de Autoridad de Certificacin. Cuando un cliente web se conecta a esta mquina a travs 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 Certificacin. Cuando ste se conecta a la interfaz web segura de administracin 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 tenan un periodo de validez de dos aos. Para la generacin de las credenciales digitales se utilizaron claves RSA de 1024 bits y el algoritmo de firma

HD1

00100101101...

Sistema operativo y aplicaciones (NTFS)

Symantec GHOST
imagen.gho

HD2

Datos de usuario (FAT32)

Fig. 2. Generacin y grabacin de imgenes binarias con Ghost

4.- Para finalizar la preparacin de la plataforma de trabajo, slo restaba configurar las propiedades de red del equipo e instalar un software antivirus. En cuanto a las

210

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

SHA1withRSA. La fig. 3 describe grficamente la arquitectura final de la Infraestructura de Clave Pblica en la experiencia piloto. Completada la preparacin de la plataforma de trabajo e instalado el SGCD, el Centre de Tecnologies de la Informaci ya contaba con la infraestructura bsica para comenzar a expedir certificados digitales. Sin embargo, algunos subsistemas de la PKI (Autoridad de Certificacin y Directorio LDAP) deban someterse a un proceso de personalizacin para adaptarse a las necesidades especficas de la experiencia piloto.
TANGO User-config directory 389

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 travs de una clase JAVA cuya funcin es comunicar al mdulo generador de certificados digitales los detalles de la poltica de certificacin. Para definir y activar las reglas era necesario localizar y modificar adecuadamente cada uno de estos mdulos JAVA. En la personalizacin 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 tamao fijo de 1024 bits. La definicin formal de esta regla en la sintaxis de SunONE CS es la siguiente:
Enable rule Predicate: HTTP_PARAMS.certType==client MinSize: 1024 MaxSize: 1024 Exponents: 17, 65537

LDAP

Internal-db

38900

LDAP HTTPS Consola iPlanet HTTPS 8200 Certificate Manager 8100 HTTPS 1027 HTTP 1024 HTTP Administration Server

SigningAlgorithmConstraints: Esta clase JAVA permite definir el algoritmo de firma de los certificados expedidos por la Autoridad de Certificacin. En la experiencia piloto se escogi el algoritmo de firma SHA1withRSA para todos los certificados. La definicin formal de esta regla en la sintaxis de SunONE Certificate Server es la siguiente:
Enable rule Predicate: HTTP_PARAMS.certType==client Algorithm: SHA1withRSA

15277

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

1) Autoridad de Certificacin: La primera tarea que se llev a cabo sobre este subsistema fue la definicin de una sencilla poltica de certificacin (CP, Certificate Policy) para garantizar uniformidad en los certificados expedidos. La recomendacin RFC2527 [2] sugiere que toda Autoridad de Certificacin debe contar con un documento pblico 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 Acadmicas no implicaba la puesta en marcha de una CA en un entorno real de produccin. En este sentido, se opt por definir una serie de valores estndar para la generacin de certificados digitales.
TABLA I VALORES ESTNDAR DEFINIDOS EN LA POLTICA DE CERTIFICACIN DE LA PKI DE LA EXPERIENCIA PILOTO

ValidityConstraints: Este mdulo 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 mximo de 365 das a partir del momento de la emisin. La definicin formal de esta regla en la sintaxis de SunONE Certificate Server es la siguiente:
Enable rule Predicate: HTTP_PARAMS.certType==client MinValidity: 365 MaxValidity: 365 LeadTime: 0 LagTime: 0 NotBeforeSkew: 0

Atributo Algoritmo generacin de claves Longitud de las claves Algoritmo de firma Periodo de validez

Valor estndar RSA 1024 bits SHA1withRSA 1 ao

SunONE Certificate Server ofrece a los administradores de la PKI un men de configuracin de polticas referentes a la Autoridad de Certificacin. Este men comprende un conjunto de reglas que permiten controlar aspectos como el

Por otra parte, la Autoridad de Certificacin se configur para publicar automticamente 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 haba creado entradas previamente para cada uno de ellos). Para implementar el proceso de publicacin se opt por la utilizacin conjunta de mappers y publishers. Un mapper es un mdulo 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 Certificacin para apuntar a la entrada de un profesor en el directorio LDAP. Finalmente, el mdulo publisher incorpora el certificado digital a la entrada del usuario en forma de atributo binario. Uno de los atributos LDAP de uso ms 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 aadir certificados digitales X.509 a la entrada LDAP de un usuario. La sintaxis Certificate permite realizar bsquedas y aplicar reglas de similitud sobre cada
1

Acrnimo de Object Identifier, identificador de objeto en Internet.

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

211

uno de los campos del certificado (Issuer, Subject Name, Validity, etc.). Gracias a esta sintaxis un cliente LDAP puede llevar a cabo bsquedas de certificados digitales en base a criterios como la Autoridad de Certificacin emisora, el periodo de validez del certificado, la organizacin a la que pertenece el titular, etc. Las pruebas realizadas a lo largo de la experiencia piloto concluyeron que la versin 5.1 Service Pack 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 bsquedas y aplicar reglas de similitud sobre el contenido del mismo. En el Piloto de Firma Digital de Actas Acadmicas se utilizaron los mappers LdapSimpleMap y LdapCaSimpleMap, que permiten localizar las entradas de los usuarios finales y la Autoridad de Certificacin, respectivamente. La fig. 4 describe grficamente el proceso de localizacin de la entrada LDAP de un usuario y la posterior publicacin de su certificado digital. En esta figura se ha considerado un ejemplo real del Piloto de Firma Digital de Actas Acadmicas.
Distinguished Name (DN)

LdapCaCertMap fue la siguiente:

dnPattern: UID=CA del CTI@UIB ou=People o=Universitat de les Illes Balears c=ES createCAEntry: yes

A diferencia de la anterior esta plantilla no genera un Distinguished Name dinmicamente, 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 slo implicaba a los profesores participantes en la experiencia piloto, no a la Autoridad de Certificacin). 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 continuacin se muestra el volcado LDIF (LDAP Data Interchange Format) de la entrada de una CA:
dn: UID=ca-cti,DC=uib,DC=es cn: ca-cti sn: ca-cti objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: certificationAuthority authorityRevocationList: cACertificate:: MIIDijC... certificateRevocationList:: MIIBlD... UID: ca-cti

Version Serial number Signature Algorithm Identifier ...

Mapper

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

Mapper Subject Name ...

Certificado digital X.509

dc=uib, dc=es

Publisher

o=NetscapeRoot

ou=People

cn=tsola

Directorio LDAP Entrada LDAP

dn dc=es, dc=uib, ou=People, cn=tsola TelephoneNumber: (+34) 971 172 mail toni.sola@uib.es givenName Antonio objectClass top objectClass person objectClass organizationalPerson sn Sola Venteo userCertificate Ux/9ji...

Fig. 4. Construccin del Distinguished Name y publicacin del certificado

Para la configuracin del mapper LdapUserCertMap se escogi la siguiente definicin de dnPattern:

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

La funcin de esta plantilla es generar un Distinguished Name que apunte a una entrada concreta del directorio LDAP. Para la construccin 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 configuracin del mapper

Con respecto a la publicacin de certificados, el proceso de configuracin 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 mdulos: LdapUserCertPublisher y LdapCaCertPublisher. El primero se encargaba de publicar los certificados digitales de los profesores en las entradas apuntadas por LdapUserCertMap. La funcin del segundo era la de publicar el certificado digital de la Autoridad de Certificacin 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 implementacin de SunONE Directory Server no soporta la sintaxis Certificate). En el caso de la Autoridad de Certificacin, el certificado digital se aadi a su correspondiente entrada LDAP como un atributo caCertificate con sintaxis binaria por defecto. Para permitir la utilizacin 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 personalizacin del SGCD, se procedi a la configuracin de un mdulo de autentificacin especfico 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 autentificacin para la generacin de certificados digitales. En la implementacin de la experiencia piloto se escogi el

212

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

mdulo 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 travs de la interfaz web segura para usuarios finales (puerto 1027). A continuacin se detalla la configuracin del mdulo UIDPwdDirAuth:
dnPattern: E=$attr.mail CN=$attr.cn OU=$attr.ou O=$attr.o C=ES ldap.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

& publishing directory) se crearon dos ramas de publicacin. La primera de ellas (o=NetscapeRoot) se encargaba de almacenar la informacin de configuracin 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 grficamente 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 contraseas. Adems, en previsin de un futuro servicio de pginas blancas, se incluy informacin de contacto (extensin telefnica, direccin postal, correo electrnico, etc.), as como una fotografa personal.
dn: UID=jferragut,ou=people,dc=uib,dc=es telephoneNumber: 971172334 mail: jaime.ferragut@uib.es 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...

El campo dnPattern indica qu atributos de la entrada de un usuario se mostrarn finalmente en el campo Subject Name de su certificado digital. En la experiencia piloto, todos los componentes del Subject Name se recuperaron de forma dinmica a partir de las entradas LDAP a excepcin del atributo C (Country), cuyo valor se fij manualmente a ES (Espaa). Los campos ldap.ldapconn.host y ldap.ldapconn.port determinan el directorio LDAP contra el que la Autoridad de Certificacin 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.
LDAP

2) Directorio LDAP: Para la realizacin del Piloto de Firma Digital de Actas Acadmicas se defini una estructura de directorio experimental. Como ya se ha comentado anteriormente, la funcin de esta estructura era doble: por un lado, se utilizara como repositorio pblico de los certificados expedidos. Por otro lado actuara como base de datos para la autentificacin de usuarios en los procesos de generacin de credenciales digitales.

o=NetscapeRoot

dc=uib, dc=es

ou=People

cn=tsola

Uno de los puntos ms crticos del proceso inicial de carga fue la inclusin del atributo mail en cada una de las entradas LDAP de los profesores. En la experiencia piloto, este atributo no slo se utilizaba como mecanismo para el almacenamiento de la direccin de correo electrnico, sino tambin como fuente de informacin para la generacin de las credenciales digitales. En previsin de la utilizacin del protocolo S/MIME para el envo de las actas acadmicas, era estrictamente necesario que en el campo Subject Name de los certificados figurara, adems de otros valores, el atributo E (e-mail) con la direccin de correo electrnico del profesor. En este sentido era fundamental mantener la consistencia entre los datos contenidos en el directorio y la configuracin de los clientes de correo electrnico de los profesores. La falta de sintona entre estas dos fuentes de informacin poda producir errores graves en la verificacin de las actas acadmicas 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 generacin dinmica y posterior descarga de las actas acadmicas en formato PDF era necesario modificar sensiblemente el cdigo de la aplicacin de gestin acadmica. Por un lado, GORA provee una interfaz web para la interaccin de los profesores. Por otro lado, el Centre de Tecnologies de la Informaci mantiene la base de datos de informacin acadmica de la Universitat de les Illes Balears. El Piloto de Firma Digital pretenda conectar estos dos elementos para que un profesor pudiera descargar va web un acta acadmica a partir de los registros almacenados

Rama de configuracin de los servidores SunONE

cn=xoliva

cn=tserra

Rama de publicacin

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

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

213

en la base de datos. La solucin de implementacin escogida se apoy en la utilizacin 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 diseado para la experiencia piloto, el profesor, a travs de la interfaz web de GORA, proporcionaba a Report Server la informacin necesaria para poder lanzar un proceso report contra la base de datos acadmica. A partir de la terna {cdigo de la asignatura, convocatoria, grupo} Report Server atacaba a la base de datos, recuperaba los registros correspondientes al acta y generaba automticamente un fichero PDF con toda la informacin. Finalmente, GORA enviaba dicho fichero al ordenador del profesor. Como medida de seguridad adicional, un profesor slo poda generar actas en PDF de asignaturas en las que tuviera responsabilidades docentes durante ese curso acadmico. En el Piloto de Firma Digital de Actas Acadmicas se definieron las siguientes transacciones de informacin entre aplicaciones: 1.- A travs de la versin web de GORA, el profesor seleccionaba la terna {cdigo de la asignatura, convocatoria, grupo} y ejecutaba la operacin de descarga. 2.- GORA enviaba estos parmetros de bsqueda a la aplicacin Report Server de ORACLE. 3.- Con estos parmetros, Report Server construa una llamada a un procedimiento PL/SQL almacenado en la base de datos de informacin acadmica. 4.- La base de datos devolva a Report Server los registros seleccionados por el procedimiento de bsqueda. 5.- Report Server consolidaba estos registros en un nico documento PDF y lo remita a GORA. 6.- Finalmente, GORA enviaba el documento PDF al ordenador del profesor. Al margen de la configuracin de Report Server, la versin web de GORA necesitaba ser modificada para incorporar estas nuevas funcionalidades. Particularmente, las modificaciones llevadas a cabo se limitaron a la programacin de nuevos formularios web para la seleccin de los parmetros de bsqueda y a la implementacin de los procesos de comunicacin con Report Server. La fig. 6 muestra la interfaz web de la nueva versin de GORA.

servicios de la Infraestructura de Clave Pblica, para el Piloto de Firma Digital de Actas Acadmicas se escogi una poltica de backups hbrida. Esta poltica supona la realizacin de imgenes binarias del sistema informtico y copias de seguridad de los servidores de la PKI. 1) Imgenes binarias: Una vez instalado y configurado el SGCD, se procedi a la realizacin de una nueva imagen binaria de la particin de sistema operativo. El archivo resultante se almacen tanto en la particin de datos (FAT32) como en un CD. En caso de producirse errores graves en el funcionamiento del sistema operativo y las aplicaciones instaladas, se recuperara el estado inicial de SunONE Certificate Server con slo lanzar esta imagen. 2) Copias de seguridad de los datos: Todos los servidores de SunONE Certificate Server incorporan funciones para la realizacin de copias de seguridad de sus configuraciones. En la experiencia piloto, al finalizar los procesos de configuracin de la Autoridad de Certificacin y carga inicial del directorio LDAP, se procedi a la realizacin de un backup completo de la informacin. El archivo resultante se almacen tanto en la particin de datos del equipo informtico, como en un CD. Gracias a este archivo, la operacin de restauracin de SunONE Certificate Server permitira recuperar una estructura de PKI totalmente adaptada a las necesidades del Piloto de Firma Digital de Actas Acadmicas. Una poltica basada en imgenes binarias permite recuperar con cierta rapidez estados estables del sistema operativo y las aplicaciones de usuario. Por otra parte, la realizacin de backups peridicos de la informacin contenida en dichas aplicaciones permite preservar tanto la configuracin de los subsistemas de la PKI como los datos de usuario almacenados en ellos. Tras un fallo catastrfico, una estrategia basada en la utilizacin conjunta de estas dos medidas garantiza la recuperacin de toda la estructura PKI en poco tiempo. VI. RESULTADOS La primera experiencia de firma digital de actas acadmicas 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 Acadmicas. En esta seccin se describen los resultados obtenidos durante este tiempo. A. Profesores participantes: De los doce profesores participantes slo 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 acadmicas. De los cuatro restantes, uno sufri problemas tcnicos 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.

Fig. 6. Interfaz web de la nueva versin de GORA

D. Poltica de backups: En previsin de fallos en los sistemas que soportan los

B. Problemas en la generacin de certificados digitales: En el caso del sistema operativo Windows, SunONE Certificate Server se apoya en la utilizacin de la librera de enlace dinmico xenroll.dll para la generacin de los pares

214

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

de claves RSA y la construccin 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 Certificacin y ejecuta una operacin Submit, un pequeo cdigo Javascript/VisualBasic embebido en el formulario web invoca a la librera xenroll.dll para que genere los pares de claves y construya la estructura PKCS#10. Todas las libreras de enlace dinmico se encuentran registradas unvocamente en Windows mediante identificadores de clase, o ClassID. Un ClassID es una secuencia de dgitos y letras a los que se debe hacer referencia para poder invocar a una librera dinmica. Para xenroll.dll, su ClassID es 43F8F289-7A20-11D0-8F0600C04FC295E1. En el caso de que los usuarios finales utilicen el navegador Internet Explorer, todos los formularios web de solicitud de certificados digitales incorporan pequeos scripts de VisualBasic con las siguientes lneas:
<OBJECT classid=clsid:43F8F289-7A20-11D0-8F0600C04FC295E1 CODEBASE=/xenroll.dll Id=Enroll> </OBJECT>

Despus de la aplicacin del parche:

<OBJECT classid=clsid:127698e4-e730-4e5c-a2b121490a70c8a1 CODEBASE=/xenroll.cab#Version=5,131,3659,0 Id=Enroll> </OBJECT>

Esta porcin de cdigo permite invocar a los mdulos CSP (Cryptographic Service Provider) internos de Windows para seleccionar la longitud del par de claves RSA. Los problemas tcnicos aparecieron cuando algunos profesores usuarios de Internet Explorer no fueron capaces de visualizar la lista de proveedores criptogrficos. En el formulario web de solicitud proporcionado por la Autoridad de Certificacin desapareca la lista desplegable que permita seleccionar el mdulo CSP con el que se iba a generar el par de claves RSA. Al no poder seleccionar ningn proveedor criptogrfico, el navegador web mostraba un mensaje de error y abortaba el proceso de generacin de claves. Tras algunas investigaciones, finalmente se pudo dar con el error. En el documento [3] Microsoft notificaba un error en el diseo de la librera de enlace dinmico xenroll.dll. Esta vulnerabilidad permita que cdigo malicioso incrustado en pginas web borrara y aadiera 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 versin de la librera. Sin embargo, esta nueva versin de xenroll.dll contaba con un ClassID diferente, por lo que haba que actualizar las referencias en los formularios web de SunONE Certificate Server. De no ser as, el cdigo VisualBasic apuntara a una xenroll.dll inoperante debido a la existencia de una nueva versin. Las modificaciones realizadas sobre los formularios web de SunONE Certificate Server para hacer referencia a la nueva versin de la librera xenroll.dll son las siguientes: Antes de la aplicacin del parche:
<OBJECT classid=clsid:43F8F289-7A20-11D0-8F0600C04FC295E1 CODEBASE=/xenroll.dll Id=Enroll> </OBJECT>

De esta forma, se prepar el SGCD para mostrar los proveedores criptogrficos a todos los clientes que hubieran actualizado su sistema operativo con el parche de seguridad Q323172 de Microsoft. Adems, 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 tambin se encontraron con problemas tcnicos del mismo tipo. En estos casos el error era evidente, ya que SunONE Certificate Server invocaba a una librera de enlace dinmico que no exista en el sistema operativo. SunONE Certificate Server est optimizado para navegadores Netscape Communicator 4.79 e inferiores. La instalacin de estos clientes web proporciona su propio mdulo PKCS#11 interno para la generacin de pares de claves y mensajes de solicitud de certificados digitales. Los formularios web de SunONE Certificate Server incluyen pequeos cdigos 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 implementacin de estos cdigos Javascript se pone de manifiesto una excesiva personalizacin para los navegadores Netscape Communicator 4.79 o inferiores. Durante el desarrollo del Piloto de Firma Digital de Actas Acadmicas, los profesores que accedan a las interfaces web de la Autoridad de Certificacin 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 cdigo Javascript generaba la lista de longitudes de clave posibles. SunONE Certificate Server slo mostraba la lista desplegable si el navegador Netscape del cliente cumpla el siguiente condicional:
si (versin_navegador 3) o (versin_pkcs#11 = no_definida) entonces mostrar_lista_desplegable; fsi;

Para navegadores Netscape 4.79 e inferiores esta condicin siempre se cumpla. En cambio, el condicional fallaba con Netscape 6.0 y superiores, por lo que la lista desplegable con las longitudes de clave no apareca. La tabla II muestra los valores obtenidos tras introducir algunas trazas en el cdigo Javascript.
TABLA II COMPARATIVA DE ATRIBUTOS INTERNOS DE NETSCAPE 4.79 Y 7.0

Navegador Netscape 4.79 Netscape 7.0

Versin 3 5

Versin PKCS#11 No definida 2.3

Como se puede comprobar, Netscape 7.0 no cumpla

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

215

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 (versin_navegador 5) o (versin_pkcs#11 = 2.3) entonces mostrar_lista_desplegable; fsi;

Las modificaciones realizadas en el cdigo Javascript para permitir la visualizacin de la lista de longitudes de clave son las siguientes: Antes de la aplicacin del parche:
if (navigator.appName == 'Netscape') { if (navMajorVersion() <= 3 typeof(crypto.version) == 'undefined') { document.write('<KEYGEN name="subjectKeyGenInfo">'); } } ||

cofirmadas excedan los objetivos de esta experiencia piloto. El estudio realizado sobre el estndar PKCS#7 arroj un resultado interesante. En la pgina 13 del documento [4] se encontr un error en la definicin ASN.1 de la estructura de datos PKCS#7. En un prrafo de este documento se confundan los tipos de datos SignerInfo (informacin relativa al firmante) y SignedData (informacin sobre la que se efectuaba la firma digital). Localizado y contrastado el error, se procedi a la notificacin del mismo al personal de RSA Laboratories, responsables ltimos de la edicin y publicacin de los estndares PKCS. La respuesta oficial de RSA Laboratories reconoca la existencia del error y garantizaba su subsanacin en sucesivas versiones del documento. D. Interaccin 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 Acadmicas fue la primera experiencia de interaccin entre diferentes navegadores web y la solucin PKI SunONE Certificate Server. Los profesores participantes en la experiencia piloto constituan un buen entorno de pruebas para evaluar la interaccin web de SunONE Certificate Server. Antes del lanzamiento del Piloto no se esperaba ningn tipo de problema tcnico derivado del uso de los navegadores. No obstante la experiencia demostr que ste sera, precisamente, el mayor foco de problemas. Como ya se ha comentado, la generacin de los pares de claves RSA y la construccin de los mensajes de solicitud de certificados digitales son responsabilidades de los mdulos CSP y PKCS#11. Para invocar a estos componentes software, los desarrolladores de SunONE Certificate Server insertaron cdigo Javascript/VisualBasic en los formularios web de interaccin con los usuarios finales. E. Integracin de los certificados en clientes de correo: Los certificados digitales expedidos por SunONE Certificate Server cumplan el estndar X.509 versin 3 de la ITU-T, por lo que su integracin en los clientes de correo electrnico tradicionales (Outlook, Outlook Express, Netscape Messenger, Netscape Mail, etc.) fue totalmente transparente. En la Experiencia Piloto de Firma Digital de Actas Acadmicas no se produjo ningn problema tcnico relacionado con el uso de clientes de correo electrnico. Sin embargo el estudio de las diferentes soluciones de implementacin arroj algunos resultados en lo que a prestaciones se refiere. A continuacin se presentan algunos de ellos. 1) Microsoft Outlook y Outlook Express: La integracin 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 Internet Explorer es automticamente reconocida por todos los clientes de correo de Microsoft. No obstante, Outlook y Outlook Express incorporan asistentes para la importacin de certificados digitales almacenados en archivos .cer o .pfx. A nivel de rendimiento, estas aplicaciones se muestran

Despus de la aplicacin 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 evaluacin de una asignatura, lo que implicaba la introduccin del concepto de acta cofirmada (acta que debe ser firmada por ms de un profesor). Aunque existen esquemas para implementar este tipo de firmas, estos documentos suponan una excepcin que complicaban la dinmica del Piloto, por lo que finalmente la asignatura en cuestin qued excluida de los procesos de firma digital. Al trmino de la experiencia piloto se inici una lnea de trabajo con el objetivo de estudiar el tratamiento de firmas jerrquicas o paralelas sobre documentos digitales. El objetivo era determinar si la estructura PKCS#7 de RSA Laboratories permita 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 informacin con criptografa 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 informacin junto con su correspondiente firma digital, la segunda almacena datos que han sido sometidos a procesos de cifrado. PKCS#7 contempla la inclusin 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 informacin con mltiples firmas digitales asociadas. No obstante, el diseo y la implementacin de un sistema de firma digital de actas

216

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

lentas cuando proceden al envo o recepcin de mensajes con criptografa 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 bsquedas por nombre, apellidos, direccin de correo electrnico, etc. se realicen de forma remota. Sin embargo, en ambas aplicaciones no est automatizada la importacin 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 travs de un asistente, a su instalacin en la base de datos de certificados. Para comprobar la autenticidad del correo electrnico, 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 Outlook no lleva a cabo esta comprobacin. 2) Netscape Messenger y Netscape Mail: Netscape Messenger es el cliente de correo electrnico incluido de serie en los navegadores Netscape Communicator 4.79 e inferiores. Netscape Mail aparece como componente estndar 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. Tambin permiten la importacin de certificados digitales a travs de un sencillo asistente. En cuanto al cmputo de operaciones criptogrficas, el rendimiento de estas dos aplicaciones es bastante mejor que el de Outlook y Outlook Express. Netscape Messenger y Netscape Mail no sufren retardos significativos al enviar o recibir mensajes de correo electrnico S/MIME. Estos dos clientes de correo soportan la interaccin 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 bsquedas y recuperar informacin de forma remota. Sin embargo, Netscape Messenger y Netscape Mail permiten importar certificados digitales desde el directorio de forma automtica, 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 comparacin de las cabeceras SMTP con la informacin 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 electrnico: Al margen de los mencionados anteriormente, tambin se realizaron pruebas de importacin de certificados digitales expedidos por SunONE Certificate Server con el cliente de correo electrnico The Bat. Los resultados fueron satisfactorios y nuevamente pusieron de manifiesto la perfecta integracin de este tipo de certificados con las aplicaciones de navegacin y correo electrnico.

VII. CONCLUSIONES La conclusin ms destacable del trabajo realizado se resume en una frase: los objetivos propuestos se han cumplido satisfactoriamente. 1.- El Piloto de Firma Digital de Actas Acadmicas ha supuesto la primera experiencia real de implementacin de una PKI en el entorno de produccin 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 Secretara Acadmica para recabar todo tipo opiniones y experiencias: Por parte del colectivo de PDI, los resultados fueron muy satisfactorios, destacando sobre todo la comodidad que supona canalizar todos los procesos de la gestin acadmica a travs de la aplicacin GORA. El personal de Secretara Acadmica se manifest mayoritariamente a favor de la reduccin de los trmites administrativos y a la eliminacin de los flujos de documentacin en papel. 3.- La realidad de una implementacin es muy diferente al panorama descrito por las recomendaciones tcnicas. Existe una gran diferencia entre el estudio de las normas, protocolos y estndares que rigen las Infraestructuras de Clave Pblica y la implementacin de un modelo sencillo de PKI como soporte tecnolgico a una experiencia piloto de identidad digital. La mayor parte de la problemtica de una PKI se deriva de la necesidad de que aplicaciones de naturaleza heterognea se comuniquen entre s correctamente para servir a una comunidad de usuarios. 4.- Se ha realizado un profundo anlisis y evaluacin de diferentes soluciones PKI, directorios LDAP y tokens externos, recogido en el documento [5]. Uno de los principales problemas con el que se encuentran los desarrolladores de Infraestructuras de Clave Pblica es la escasez de informacin a la hora de seleccionar un entorno de desarrollo. La experimentacin con diferentes Sistemas Gestores de Certificados Digitales ha arrojado una visin del estado del arte y ha contribuido activamente a la generacin de conocimiento. 5.- El Piloto de Firma Digital de Actas Acadmicas se present oficialmente en los Grupos de Trabajo y Jornadas Tcnicas de RedIRIS, Red Espaola 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 pster [6] en las Jornadas Tcnicas. Dicho pster se public posteriormente en los nmeros 62-63 de los boletines de la Red Espaola de I+D+i. Adems se llevaron a cabo diversas presentaciones en las instalaciones del CTI@UIB para responsables de instituciones como Santander Central Hispano, la Universidad Autnoma de Barcelona o los directores de los Servicios de Informtica del Grupo 9 de Universidades2. 6.- El Piloto de Firma Digital de Actas Acadmicas puso de manifiesto que la implementacin de una PKI en un entorno universitario afecta a un gran nmero de agentes: Se requiere un gran esfuerzo para disear e
2 El Grupo 9 de Universidades es una asociacin sin nimo de lucro formada por las universidades pblicas de Islas Baleares, Zaragoza, La Rioja, Navarra, Pas Vasco, Cantabria, Oviedo, Extremadura y Castilla La Mancha constituida en el convenio firmado el 16 de mayo de 1997.

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

217

implementar la plataforma tecnolgica de identidad digital. Hay que transmitir la confianza necesaria a los rganos directivos de la universidad para introducir nuevos mecanismos en los procesos de gestin acadmica. Es necesario formar al personal (tanto PDI como PAS) en la utilizacin de tcnicas 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 prctica por la Universitat de les Illes Balears no sirve nicamente como mtodo de experimentacin con soluciones PKI, sino tambin como mecanismo para localizar y evaluar problemticas en una futura extensin 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 tcnicos de implementacin. VIII. LNEAS 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 prctico en el mbito de la certificacin digital y las Infraestructuras de Clave Pblica. Al trmino del Piloto de Firma Digital de Actas Acadmicas se plantearon numerosas lneas de trabajo futuro, muchas de ellas se desarrollaron durante fases posteriores del proyecto. Sin embargo, la implementacin de una PKI en un entorno real de produccin es un complejo proceso con implicaciones no slo tcnicas, sino tambin organizativas, humanas y legales. En esta seccin se presentan las lneas de trabajo para seguir avanzando hacia la consecucin de una implementacin real de PKI en un entorno universitario. Para cumplir con la RFC 2527 [2], es necesario desarrollar una Poltica de Certificacin que describa formalmente todos los detalles del servicio de PKI ofrecido por el Centre de Tecnologies de la Informaci. Adems, es necesario redactar una Declaracin de Prcticas (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. Tambin es recomendable aadir una extensin X.509 versin 3 en los certificados para incluir un URL (Universal Resource Locator) que apunte a la Poltica de Certificacin. El Real Decreto Ley 14/1999 sobre firma electrnica [7] fija unas obligaciones extraordinariamente amplias y estrictas para los Prestadores de Servicios de Certificacin Digital. Aunque la Infraestructura de Clave Pblica del Centre de Tecnologies de la Informaci acte sobre un entorno cerrado, es conveniente realizar un estudio de estas leyes y aplicar las conclusiones a la implementacin desarrollada. Uno de los aspectos ms importantes en una Infraestructura de Clave Pblica es la seguridad de los sistemas informticos 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 crticos de la PKI de la red pblica de la Universitat de les Illes Balears, ubicar los equipos informticos en salas de mquinas con acceso restringido, filtrar los puertos de los servidores mediante firewalls, analizar peridicamente los archivos de logs, etc.

En cuanto a la interaccin de las aplicaciones con tokens externos, es interesante abrir una lnea de trabajo que apueste por el desarrollo de un mdulo PKCS#11 propio. Para ello, es necesario realizar un profundo estudio tcnico 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 implementacin de una librera de funciones PC/SC (Personal Computer/SmartCard) que interacten directamente con las tarjetas inteligentes y puedan ser invocadas desde el mdulo PKCS#11. Otro aspecto interesante para contribuir a la mejora y ampliacin 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 certificacin digital con Infraestructuras de Clave Pblica de orden superior, como por ejemplo, RedIRIS-PKI3. Adems, desde el punto de vista organizativo, la solicitud de una rama propia de OID contribuye a la definicin formal de la PKI y al registro de los atributos y clases de objeto propietarios. Una buena medida para contribuir a la difusin de los servicios de identidad digital en la comunidad universitaria, es el desarrollo de un portal web de certificacin. Este portal permitira a los usuarios conocer la estructura y el funcionamiento de la PKI, solicitar certificados digitales de prueba, acceder a la Poltica de Certificacin y a la Declaracin de Prcticas, navegar por el servicio de pginas blancas, remitir consultas a los responsables tcnicos, etc. Tras la finalizacin del Piloto de Firma Digital de Actas Acadmicas, uno de los problemas que suscit mayor inters fue el de la modificacin 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 definicin de una estructura ASN.1 en la que se incluyera la informacin 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 lnea de trabajo interesante. En relacin con las actas acadmicas, al finalizar la experiencia piloto se abri una lnea de desarrollo para buscar alternativas a la utilizacin de clientes de correo electrnico en el esquema de firma digital. El objetivo era desarrollar un applet JAVA que implementara las operaciones de descarga, firma y envo del acta a la base de datos de informacin acadmica. Este applet se ejecutara automticamente 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 contribuira a la desaparicin de los problemas derivados de la utilizacin de navegadores y clientes de correo especficos. En el documento [6] se describe con detalle esta
3 RedIRIS-PKI certifica nica y exclusivamente las claves pblicas de aquellas Autoridades de Certificacin ubicadas en organismos e instituciones de la comunidad RedIRIS.

218

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

estrategia de firma digital de actas acadmicas. IX. AGRADECIMIENTOS Los autores agradecen las contribuciones de M. Canals, J. L. Ferrer Gomila, C. Malagn, J. Masa, M. Bolado y de todo el personal tcnico del Centre de Tecnologies de la Informaci de la Universitat de les Illes Balears durante las fases de anlisis, diseo e implementacin de esta experiencia piloto. Igualmente los autores agradecen la colaboracin de T. Jimnez, J. Gil, J. Garca, J. J. Meseguer, S. Navarro y de todo el Servicio de Informtica 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 S. Chokhani, W. Ford, X.509 Internet Public Key Infrastructure Certificate Policy and Certification Practices Framework. IETF Request for Comments #2527 (online). Marzo de 1999, consultado el 9 de junio de 2003. http://www.ietf.org/rfc/rfc2527.txt 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/s ecurity/bulletin/MS02-048.asp RSA Laboratories, PKCS#7: Cryptographic Message Syntax Standard, v1.5. Nota tcnica de RSA Laboratories (online). Noviembre de 1993, consultada el 20 de junio de 2003. ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc J. Ferragut, Implementacin de una Infraestructura de Clave Pblica en la Universitat de les Illes Balears. Proyecto Fin de Carrera. Julio de 2003. B.Serra, J. Ferrer, M. Canals, J. Ferragut, Piloto de Firma Digital de Actas Acadmicas. Boletn de RedIRIS, Red Nacional de I+D+i, nm. 62-63 (online). Diciembre 2002-enero 2003. http://www.rediris.es/rediris/boletin/62-63/poster.pdf Boletn Oficial del Estado, REAL DECRETO-LEY 14/1999, de 17 de septiembre, sobre firma electrnica. BOE nm.224, pg.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

[2]

[3]

[4]

[5] [6]

[7]

DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC

219

XI. BIOGRAFAS
Jaime Ferragut Martnez-Vara de Rey naci en Palma de Mallorca, Espaa, el 16 de abril de 1978. Es Ingeniero Tcnico de Telecomunicacin por la Escola Politcnica Superior de la Universitat de les Illes Balears. Actualmente colabora en el Departamento de Ingeniera Telemtica de la Universitat Politcnica de Catalunya. Durante tres aos 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 Certificacin Digital. Sus principales reas de inters son la criptografa, las Infraestructuras de Clave Pblica 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 Catedrtico del rea de Ciencias de la Computacin e Inteligencia Artificial de la misma universidad desde el ao 1991. Ha sido fundador y director durante ms de 20 aos del Centro de Tecnologas de la Informacin de la UIB (1983-2003). En la actualidad, adems de la docencia e investigacin que realiza desde su Ctedra de la Escuela Politcnica Superior de la UIB, colabora con diferentes instituciones pblicas y privadas en la implantacin de las Tecnologas de la Informacin y las Comunicaciones en la Comunidad Autnoma de las Islas Baleares.