PDF Full-Text

IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
205
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
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:
E
- 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
206
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
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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 tokens
externos. 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.
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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
207
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 tokens
externos. 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
208
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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.
Admin.PKI
Profesor
CA
ÁGORA
B.DD.
Secr. Acad.
1
2
2
3
3
3
3
4
5
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 OpenCA
constituí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
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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 Service
Pack 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.
HD1
00100101101...
Sistema operativo
y aplicaciones
(NTFS)
HD2
Symantec
GHOST
imagen.gho
Datos de usuario
(FAT32)
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
209
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 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 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
210
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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.
TANGO
LDAP
User-config
directory
Enable rule
Predicate: HTTP_PARAMS.certType==client
MinSize: 1024
MaxSize: 1024
Exponents: 17, 65537
389
Internal-db
38900
LDAP
HTTPS
Consola
iPlanet
HTTPS
8100
8200
HTTPS
Certificate
Manager
1027
HTTP
1024
HTTP
15277
Administration
Server
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 I
VALORES 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
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:
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
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: SHA1withRSA
ValidityConstraints: 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: 365
MaxValidity: 365
LeadTime: 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.
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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 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 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.
Distinguished Name (DN)
Mapper
Version
DN: dc=uib, dc=es, ou=People, cn=tsola
Serial number
Signature Algorithm
Identifier
...
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 [email protected]
givenName Antonio
objectClass top
objectClass person
objectClass organizationalPerson
sn Sola Venteo
userCertificate Ux/9ji...
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.UID
ou=$subj.ou
o=$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
211
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 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 (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
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
212
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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.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
El campo dnPattern indica qué atributos de la entrada
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.
LDAP
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.
o=NetscapeRoot
dc=uib, dc=es
ou=People
cn=tsola
Rama de configuración de
los servidores SunONE
cn=xoliva
cn=tserra
Rama de publicación
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=es
telephoneNumber: 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
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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 report
contra 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.
213
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.
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
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
214
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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-8F0600C04FC295E1.
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-8F0600C04FC295E1”
CODEBASE=”/xenroll.dll”
Id=Enroll>
</OBJECT>
Esta porción de código permite invocar a los módulos
CSP (Cryptographic Service Provider) internos de Windows
para 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-8F0600C04FC295E1”
CODEBASE=”/xenroll.dll”
Id=Enroll>
</OBJECT>
Después de la aplicación del parche:
<OBJECT
classid=”clsid:127698e4-e730-4e5c-a2b121490a70c8a1”
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 II
COMPARATIVA 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
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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 RSA
Laboratories 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
215
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/VisualBasic
en 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 Internet
Explorer es automáticamente reconocida por todos los
clientes de correo de Microsoft. No obstante, Outlook y
Outlook Express incorporan asistentes para la importación
de certificados digitales almacenados en archivos .cer o .pfx.
A nivel de rendimiento, estas aplicaciones se muestran
216
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 Outlook
no 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 y
Netscape 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.
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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 tokens
externos, 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.
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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.
217
En cuanto a la interacción de las aplicaciones con tokens
externos, 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.
218
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005
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]
[2]
[3]
[4]
[5]
[6]
[7]
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 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
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.
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
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
DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC
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.
219