Experiencia Piloto de Firma Digital de Actas Académicas

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Experiencia Piloto de Firma Digital de Actas Académicas"

Transcripción

1 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 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 comenzó a trabajar en la implementación de una Infraestructura de Clave Pública (de ahora en adelante, PKI) de ámbito universitario. El objetivo era doble: - Generar conocimiento práctico a través del estudio de la tecnología actual en el mundo de las Infraestructuras de Clave Pública. - Construir una plataforma tecnológica que permitiera la puesta en marcha de futuros servicios basados en certificación y firma digital. En la operativa diaria de una universidad, todo proceso oficial de evaluación debe concluir con la firma manuscrita del profesor sobre el acta académica de la asignatura. Como parte fundamental de la gestión académica, la firma de actas supone una excelente oportunidad para la aplicación de las nuevas tecnologías en el ámbito de la identidad digital. La experiencia piloto del Centre de Tecnologies de la Informació tenía como objetivo informatizar e integrar en un solo proceso las operaciones de generación, cierre y firma de actas académicas con los requerimientos de seguridad que exige una institución universitaria. En el entorno de trabajo de la Universitat de les Illes Balears (de Jaime Ferragut Martínez-Vara de Rey es Ingeniero Técnico de Telecomunicación por la Escola Politècnica Superior de la Universitat de les Illes Balears ( Bartomeu J. Serra Cifre es Catedrático de Ciencias de la Computación e Inteligencia Artificial de la Universitat de les Illes Balears ( 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 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 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

2 206 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005 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 Se escogieron estas fechas porque es en ellas cuando se procede a firmar las actas académicas de la convocatoria de septiembre. 4.- Al tratarse de un conjunto controlado de profesores, se podían relajar los mecanismos de verificación de identidad necesarios para la generación de los certificados. 5.- Para futuras verificaciones, los certificados digitales se almacenarían en un directorio público. C. Utilización de tokens externos: Un token externo es un dispositivo físico que sirve como almacén de credenciales digitales (tarjetas inteligentes, llaves criptográficas USB, etc.). Para favorecer un desarrollo rápido del Piloto de Firma Digital de Actas Académicas, en un primer momento se optó por no utilizar tokens externos. A este respecto, las decisiones tomadas en la fase de análisis fueron las siguientes: 1.- En cuanto al sistema de firma digital, era necesario buscar soluciones de implementación de impacto mínimo para los profesores. En el escenario de escogido, la utilización de teclados equipados con lector de tarjetas inteligentes complicaba la entrada en funcionamiento de la experiencia piloto (instalación de drivers, problemas ocasionados por incompatibilidades, cambio de teclados, formación adicional, etc.) 2.- Frente a la utilización de tarjetas inteligentes, la opción de almacenar las claves privadas en el propio sistema operativo resultaba menos segura. Sin embargo, esta decisión simplificaba la tarea de los desarrolladores y reducía las molestias para el usuario final. 3.- Al margen de las consideraciones anteriores, se decidió abrir una línea de trabajo en el área de 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.

3 DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC 207 F. Equipamiento informático y de comunicaciones: Al tratarse de una experiencia piloto, para la implementación de la PKI se necesitaba una infraestructura mínima en lo que a comunicaciones y equipos informáticos se refiere. Bastaba con un punto de acceso a la red pública de la Universitat de les Illes Balears, una estación de trabajo de gama media/alta y una cuenta de usuario en el servidor de correo electrónico de la UIB. Las consideraciones de sistema operativo, software antivirus, soluciones LDAP (Lightweight Directory Access Protocol) y SGCD se discutirán posteriormente en la sección de implementación. G. Dinámica de la firma digital de actas académicas: Las consideraciones que debían regir el procedimiento por el que un profesor firmaba digitalmente un acta académica eran las siguientes: 1.- Había que tener en cuenta los desarrollos existentes: el profesor obtendría el acta académica a través de la interfaz web segura de ÁGORA. 2.- En lo que respecta al acceso a la información, ÁGORA ya incorporaba sus propios mecanismos de autentificación basados en login y password. 3.- Para simplificar la tarea de los desarrolladores y provocar un impacto mínimo sobre los procedimientos de gestión académica, el sistema de firma digital debía integrarse fácilmente en un entorno web o de correo electrónico. 4.- El objetivo principal era evitar desplazamientos de los profesores a las dependencias de Secretaría Académica. 5.- La Secretaría Académica debía remitir acuse de recibo a los profesores que hubieran completado correctamente el proceso de firma digital de actas académicas. 6.- Los profesores debían tener la posibilidad de analizar detenidamente el contenido del acta antes de firmarla. 7.- Había que respetar escrupulosamente la dinámica habitual de firma de actas y tener en cuenta las opiniones de los agentes implicados (profesores y personal de Secretaría Académica). En la próxima sección se describe el diseño adoptado para la realización de la experiencia piloto, tanto en el área de PKI como en la del sistema de firma digital de actas académicas. IV. DISEÑO DE LA SOLUCIÓN En la fase de diseño de la experiencia piloto se discutieron aspectos que debían regir desde la arquitectura de la Infraestructura de Clave Pública hasta el funcionamiento del sistema de firma digital de actas académicas. Las decisiones tomadas en estas áreas son las siguientes: A. Infraestructura de Clave Pública: Tomando como punto de partida la existencia de un conjunto muy reducido de usuarios, se adoptó la decisión de diseñar una estructura sencilla para los sistemas integrados en la PKI. Sobre una misma máquina coexistirían los servicios de Autoridad de Certificación y directorio LDAP. En este diseño no se consideró la existencia de Autoridades de Registro, ya que el reducido número de usuarios y los mecanismos de autentificación no las hacían necesarias. El directorio LDAP tendría una doble atribución en la Infraestructura de Clave Pública. Por un lado, se aprovecharía como repositorio público de los certificados digitales expedidos. Por otro lado, actuaría como base de datos para la autentificación de usuarios durante el proceso de generación de las credenciales digitales. Cada participante de la experiencia piloto contaría con una entrada en el directorio creada previamente por el administrador de la PKI. De forma presencial y confidencial se entregaría a cada profesor un sobre con un manual de usuario y la pareja {UID, password} necesaria para autentificarse frente a la PKI. Así, sólo los usuarios autorizados podrían generar sus credenciales digitales a través de los formularios web provistos por la Autoridad de Certificación. El administrador de la PKI únicamente debería preocuparse de crear las entradas LDAP para cada usuario y de entregar de forma segura la documentación. B. Tipos de certificados digitales: Los certificados digitales se adaptarían al estándar X.509 versión 3 de la ITU-T. Finalmente, para evitar problemas derivados de posibles retrasos en la firma de actas, se decidió no restringir el periodo de validez a los meses de septiembre, octubre y noviembre. Todos los certificados digitales tendrían validez por un año y la longitud del par de claves sería de 1024 bits, tanto para profesores como para el personal de Secretaría Académica. Al tratarse de una experiencia muy acotada en el tiempo, no se considerarían mecanismos de renovación o revocación de certificados digitales. Como medida de uniformización, los usuarios no deberían introducir sus datos personales en los formularios web de solicitud de certificados digitales. Al proporcionar su UID y password, la Autoridad de Certificación construiría automáticamente el campo Subject del certificado tomando como referencia los datos personales contenidos en la correspondiente entrada LDAP. C. Tokens externos: Para favorecer un desarrollo rápido de la experiencia piloto se decidió no trabajar con tokens externos: los certificados digitales se almacenarían de forma segura en el disco duro del ordenador. De igual manera, el personal de Secretaría Académica tampoco trabajaría con 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

4 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 Fig. 1. Procedimiento de firma digital de actas académicas 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

5 DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC 209 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 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 Sistema operativo y aplicaciones (NTFS) HD2 Datos de usuario (FAT32) imagen.gho Symantec GHOST Fig. 2. Generación y grabación de imágenes binarias con Ghost 4.- Para finalizar la preparación de la plataforma de trabajo, sólo restaba configurar las propiedades de red del equipo e instalar un software antivirus. En cuanto a las comunicaciones, el equipo fue incorporado a la red de datos - Segunda instancia de Directory Server: al margen del repositorio público de información, SunONE Certificate Server instala un segundo directorio LDAP que actúa como base de datos interna de la Autoridad de Certificación (almacenamiento de solicitudes, certificados expedidos, registro de logs, etc.). A nivel de operativa interna, este directorio recibe el nombre de tango internal-db. - Al margen de la figura del Directory Server Manager, durante el proceso de configuración se crea un nuevo perfil de administración responsable de la Autoridad de Certificación. Este usuario recibe el nombre de Administrador del CMS (Certificate Management System Administrator) y su tarea consiste en personalizar la CA y aprobar (o denegar) la solicitud de certificados digitales. - La Autoridad de Certificación implementa una serie de interfaces web para la gestión de los servicios y la interacción con los usuarios finales. Para el acceso de administradores y agentes se habilitaron los puertos seguros 8200 y 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

6 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. Consola iplanet LDAP HTTPS HTTP 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 Algoritmo generación de claves Longitud de las claves Algoritmo de firma Periodo de validez Internal-db TANGO Certificate Manager Administration Server User-config directory LDAP Valor estándar RSA bits SHA1withRSA 1 año HTTPS 8100 HTTPS 1027 HTTP 1024 SunONE Certificate Server ofrece a los administradores de la PKI un menú de configuración de políticas referentes a la Autoridad de Certificación. Este menú comprende un conjunto de reglas que permiten controlar aspectos como el algoritmo de firma de los certificados, la longitud del par de claves o el periodo de validez. Cada una de estas reglas se implementa a través de una clase JAVA cuya función es comunicar al módulo generador de certificados digitales los detalles de la política de certificación. Para definir y activar las reglas era necesario localizar y modificar adecuadamente cada uno de estos módulos JAVA. En la personalización de TANGO se configuraron las siguientes reglas: RSAKeyConstraints: Esta regla permite definir la longitud del par de claves RSA que se proporcionará al usuario. Para la experiencia piloto se optó por un tamaño fijo de 1024 bits. La definición formal de esta regla en la sintaxis de SunONE CS es la siguiente: Enable rule Predicate: HTTP_PARAMS.certType==client MinSize: 1024 MaxSize: 1024 Exponents: 17, 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 (OID 1 = ). Este atributo está ligado a la sintaxis Certificate (OID= ) 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.

7 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 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= ). 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. Version Serial number Signature Algorithm Identifier... Subject Name... Certificado digital X.509 Publisher dn dc=es, dc=uib, ou=people, cn=tsola TelephoneNumber: (+34) mail givenname Antonio objectclass top objectclass person objectclass organizationalperson sn Sola Venteo usercertificate Ux/9ji... Entrada LDAP Mapper o=netscaperoot 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 Distinguished Name (DN) DN: dc=uib, dc=es, ou=people, cn=tsola Mapper dc=uib, dc=es ou=people cn=tsola Directorio LDAP La función de esta plantilla es generar un Distinguished Name que apunte a una entrada concreta del directorio LDAP. Para la construcción de este DN se utilizó el atributo UID del formulario web de solicitud y los atributos OU, O y C del certificado digital. Por otra parte, la configuración del mapper LdapCaCertMap fue la siguiente: dnpattern: UID=CA del 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

8 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 LDAP de un usuario se mostrarán finalmente en el campo Subject Name de su certificado digital. En la experiencia piloto, todos los componentes del Subject Name se recuperaron de forma dinámica a partir de las entradas LDAP a excepción del atributo C (Country), cuyo valor se fijó manualmente a ES (España). Los campos ldap.ldapconn.host y ldap.ldapconn.port determinan el directorio LDAP contra el que la Autoridad de Certificación debe autentificar las solicitudes recibidas. Finalmente el campo ldap.basedn fija el nodo del árbol LDAP a partir del cual la CA debe buscar las entradas de los usuarios. Como muestra la fig. 4, este nodo tiene por DN la cadena dc=uib, dc=es, ou=people. 2) Directorio LDAP: Para la realización del Piloto de Firma Digital de Actas Académicas se definió una estructura de directorio experimental. Como ya se ha comentado anteriormente, la función de esta estructura era doble: por un lado, se utilizaría como repositorio público de los certificados expedidos. Por otro lado actuaría como base de datos para la autentificación de usuarios en los procesos de generación de credenciales digitales. o=netscaperoot Rama de configuración de los servidores SunONE dc=uib, dc=es ou=people cn=tsola 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: mail: 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 ( ) 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

9 DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC 213 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. 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 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

10 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-8F06-00C04FC295E1. En el caso de que los usuarios finales utilicen el navegador Internet Explorer, todos los formularios web de solicitud de certificados digitales incorporan pequeños scripts de VisualBasic con las siguientes líneas: <OBJECT classid= clsid:43f8f289-7a20-11d0-8f06-00c04fc295e1 CODEBASE= /xenroll.dll Id=Enroll> </OBJECT> Esta porción de código permite invocar a los módulos CSP (Cryptographic Service Provider) internos de 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-8f06-00c04fc295e1 CODEBASE= /xenroll.dll Id=Enroll> </OBJECT> Después de la aplicación del parche: <OBJECT classid= clsid:127698e4-e730-4e5c-a2b a70c8a1 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 Q 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 No definida Netscape Como se puede comprobar, Netscape 7.0 no cumplía

11 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 (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 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

12 216 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 2, APRIL 2005 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 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. 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 de los boletines de la Red Española de I+D+i. Además se llevaron a cabo diversas presentaciones en las instalaciones del 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 Universidades 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.

13 DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC 217 implementar la plataforma tecnológica de identidad digital. Hay que transmitir la confianza necesaria a los órganos directivos de la universidad para introducir nuevos mecanismos en los procesos de gestión académica. Es necesario formar al personal (tanto PDI como PAS) en la utilización de técnicas de identidad digital. Es necesario contar con el respaldo y la labor consultiva de los servicios legales de la universidad para dotar a todos los procesos de un estatus comparable al de la firma manuscrita. En resumen, una experiencia piloto como la puesta en práctica por la Universitat de les Illes Balears no sirve únicamente como método de experimentación con soluciones PKI, sino también como mecanismo para localizar y evaluar problemáticas en una futura extensión del servicio al conjunto de la comunidad universitaria. La experiencia ha demostrado que los esfuerzos realizados en el plano humano y organizativo son notablemente superiores a los esfuerzos técnicos de implementación. VIII. LÍNEAS DE TRABAJO FUTURO Como ya se ha comentado, el trabajo realizado a lo largo de esta experiencia piloto ha permitido generar una gran cantidad de conocimiento práctico en el ámbito de la certificación digital y las Infraestructuras de Clave Pública. Al término del Piloto de Firma Digital de Actas Académicas se plantearon numerosas líneas de trabajo futuro, muchas de ellas se desarrollaron durante fases posteriores del proyecto. Sin embargo, la implementación de una PKI en un entorno real de producción es un complejo proceso con implicaciones no sólo técnicas, sino también organizativas, humanas y legales. En esta sección se presentan las líneas de trabajo para seguir avanzando hacia la consecución de una implementación real de PKI en un entorno universitario. Para cumplir con la RFC 2527 [2], es necesario desarrollar una Política de Certificación que describa formalmente todos los detalles del servicio de PKI ofrecido por el Centre de Tecnologies de la Informació. Además, es necesario redactar una Declaración de Prácticas (CPS, Certificate Policy Statement) que determine con exactitud los usos atribuidos a los certificados digitales. Tanto la CP como la CPS deben publicarse en Internet. También es recomendable añadir una extensión X.509 versión 3 en los certificados para incluir un URL (Universal Resource Locator) que apunte a la Política de Certificación. El Real Decreto Ley 14/1999 sobre firma electrónica [7] fija unas obligaciones extraordinariamente amplias y estrictas para los Prestadores de Servicios de Certificación Digital. Aunque la Infraestructura de Clave Pública del Centre de Tecnologies de la Informació actúe sobre un entorno cerrado, es conveniente realizar un estudio de estas leyes y aplicar las conclusiones a la implementación desarrollada. Uno de los aspectos más importantes en una Infraestructura de Clave Pública es la seguridad de los sistemas informáticos y de las aplicaciones que la integran. En este sentido, es conveniente utilizar redes virtuales (VLAN, Virtual LANs), o mecanismos equivalentes, para aislar a los sistemas críticos de la PKI de la red pública de la Universitat de les Illes Balears, ubicar los equipos informáticos en salas de máquinas con acceso restringido, filtrar los puertos de los servidores mediante firewalls, analizar periódicamente los archivos de logs, etc. En cuanto a la interacción de las aplicaciones con 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-PKI 3. 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.

14 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] 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 [2] 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 [3] Microsoft Technet, Microsoft Security Bulletin MS02-048: Flaw in Certificate Enrollment Control Could Allow Deletion of Digital Certificates (Q323172). Microsoft Technet Security Bulletin (online). Agosto de 2002, consultado el 20 de junio de ecurity/bulletin/ms asp [4] RSA Laboratories, PKCS#7: Cryptographic Message Syntax Standard, v1.5. Nota técnica de RSA Laboratories (online). Noviembre de 1993, consultada el 20 de junio de ftp://ftp.rsasecurity.com/pub/pkcs/doc/pkcs-7.doc [5] J. Ferragut, Implementación de una Infraestructura de Clave Pública en la Universitat de les Illes Balears. Proyecto Fin de Carrera. Julio de [6] B.Serra, J. Ferrer, M. Canals, J. Ferragut, Piloto de Firma Digital de Actas Académicas. Boletín de RedIRIS, Red Nacional de I+D+i, núm (online). Diciembre 2002-enero [7] Boletín Oficial del Estado, REAL DECRETO-LEY 14/1999, de 17 de septiembre, sobre firma electrónica. BOE núm.224, pág (online). Septiembre de 1999, consultado el 9 de junio de

15 DE REY AND CIFRE : DIGITAL SIGNATURE PILOT TEST FOR ACADEMIC 219 XI. BIOGRAFÍAS Jaime Ferragut Martínez-Vara de Rey nació en Palma de Mallorca, España, el 16 de abril de 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 Ha sido fundador y director durante más de 20 años del Centro de Tecnologías de la Información de la UIB ( ). 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.

Dr.Web Enterprise Security Suite 10 Guía Rápida de Implantación (Windows)

Dr.Web Enterprise Security Suite 10 Guía Rápida de Implantación (Windows) Dr.Web Enterprise Security Suite 10 Guía Rápida de Implantación (Windows) Versión de Dr.Web ESS: 10.0 Última actualización: 24/09/2014 2014 IREO Mayorista de ITSM y Seguridad Guía de Implantación Dr.Web

Más detalles

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL SUBDIRECCIÓN GENERAL DE RECAUDACIÓN PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL INDICE 1 INTRODUCCIÓN...

Más detalles

SERVICIOS MÓDULOS FUNCIONALIDADES DESCRIPCIÓN

SERVICIOS MÓDULOS FUNCIONALIDADES DESCRIPCIÓN MANUAL Solicitud desde el Cliente de su propio Certificado de propósito Multiple (Correo, Firma Documentos, Usuario, Sellado de Fecha, etc...) El cliente dispondrá de un interfaz completamente personalizado

Más detalles

Guía Rápida de Inicio

Guía Rápida de Inicio Guía Rápida de Inicio 1. Acerca de esta Guía Esta guía le ayudará a instalar y dar los primeros pasos con BitDefender Security for Exchange. Para disponer de instrucciones detalladas, por favor, diríjase

Más detalles

Aranda 360 ENDPOINT SECURITY

Aranda 360 ENDPOINT SECURITY Tabla de contenido Product Architecture Product Architecture Introducción Ambiente Redesdetrabajo Configuraciones Políticas Servidores Componentes Agente Servidor Base de datos Consola Comunicación Consola

Más detalles

Intercambio de ficheros institucionales

Intercambio de ficheros institucionales Intercambio de ficheros institucionales Unidad de Infraestructuras Junio 2013 Versión: 1.0 INDICE 1. INTRODUCCIÓN... 4 2. INICIO DEL CLIENTE DE INTERCAMBIO DE FICHEROS INSTITUCIONALES... 5 3. VISTA GENERAL

Más detalles

Procedimiento de Instalación y Configuración del. cliente VPN. Acceso Remoto a la Red Corporativa

Procedimiento de Instalación y Configuración del. cliente VPN. Acceso Remoto a la Red Corporativa Acceso Remoto a la Red Corporativa Acceso Remoto a la Red Corporativa Página 1 de 30 Procedimiento de Instalación y Configuración del cliente VPN Acceso Remoto a la Red Corporativa Este documento es confidencial

Más detalles

GUÍA DE USO E INSTALACIÓN DE CERTIFICADOS DIGITALES EN EL SISTEMA DE BONIFICACIONES 2009

GUÍA DE USO E INSTALACIÓN DE CERTIFICADOS DIGITALES EN EL SISTEMA DE BONIFICACIONES 2009 GUÍA DE USO E INSTALACIÓN DE CERTIFICADOS DIGITALES EN EL SISTEMA DE BONIFICACIONES 2009 Marzo 2009 ÍNDICE Introducción....................................................1 Objetivos.....................................................2

Más detalles

GUÍA DE INSTALACIÓN DEL DNIE EN MS-WINDOWS INTECO-CERT

GUÍA DE INSTALACIÓN DEL DNIE EN MS-WINDOWS INTECO-CERT GUÍA DE INSTALACIÓN DEL DNIE EN MS-WINDOWS INTECO-CERT Abril 2012 El presente documento cumple con las condiciones de accesibilidad del formato PDF (Portable Document Format). Se trata de un documento

Más detalles

Guía Rápida de Inicio

Guía Rápida de Inicio Guía Rápida de Inicio 1. Acerca de esta Guía Esta guía le ayudará a instalar y dar los primeros pasos con BitDefender Security for Mail Servers. Para disponer de instrucciones detalladas, por favor, diríjase

Más detalles

ADMINISTRACIÓN FEDERAL DE INGRESOS PÚBLICOS GUÍA PARA GESTIÓN DE CERTIFICADOS DIGITALES

ADMINISTRACIÓN FEDERAL DE INGRESOS PÚBLICOS GUÍA PARA GESTIÓN DE CERTIFICADOS DIGITALES ADMINISTRACIÓN FEDERAL DE INGRESOS PÚBLICOS AUTORIDAD CERTIFICANTE GUÍA PARA GESTIÓN DE CERTIFICADOS DIGITALES Versión 2.07 27/06/2012 ADMINISTRACION FEDERAL DE INGRESOS PUBLICOS Página 1 de 23 INDICE

Más detalles

CONFIGURACIÓN PARA CORREO ELECTRÓNICO SEGURO CON MOZILLA

CONFIGURACIÓN PARA CORREO ELECTRÓNICO SEGURO CON MOZILLA PÚBLICA Página Página 1 de 15 1 OBJETIVO Este manual tiene como objetivo servir de guía para los usuarios que desean utilizar su cliente de correo Mozilla para enviar correo electrónico seguro mediante

Más detalles

Manual de instalación. Lector USB de DNI electrónico SATYCON

Manual de instalación. Lector USB de DNI electrónico SATYCON Antes de comenzar con la instalación de este dispositivo verifique que su usuarios es un administrador del sistema. Esto es muy importante, por que necesitara realizar cambios en el ordenador que sin los

Más detalles

Gestión de la Seguridad Informática

Gestión de la Seguridad Informática Documento de Gestión de la Seguridad Informática Versión 01 ARCHIVO: ANEXO6_GESTION DE LA SEGURIDAD INFORMATICA Nº. PÁG: 1 / 6 CREADO: 11/11/a TABLA DE CONTENIDO 1. GESTIÓN DE SEGURIDAD INFORMÁTICA...

Más detalles

1. CONFIGURACIÓN Y DESARROLLO FACTURACIÓN ELECTRÓNICA. a. CONFIGURACION DE SERVIDORES b. CERTIFICADO DIGITAL c. MODULO GENERADOR DOCUMENTOS XML d.

1. CONFIGURACIÓN Y DESARROLLO FACTURACIÓN ELECTRÓNICA. a. CONFIGURACION DE SERVIDORES b. CERTIFICADO DIGITAL c. MODULO GENERADOR DOCUMENTOS XML d. 1. CONFIGURACIÓN Y DESARROLLO FACTURACIÓN ELECTRÓNICA. a. CONFIGURACION DE SERVIDORES b. CERTIFICADO DIGITAL c. MODULO GENERADOR DOCUMENTOS XML d. MODULO FIRMA DIGITAL XML e. MODULO WEB SERVICE SUNAT 2.

Más detalles

Ayuda para la instalación Componente Firma Digital INDICE. 1 Configuración previa...2. 1.1 Configuración Internet Explorer para ActiveX...

Ayuda para la instalación Componente Firma Digital INDICE. 1 Configuración previa...2. 1.1 Configuración Internet Explorer para ActiveX... INDICE 1 Configuración previa...2 1.1 Configuración Internet Explorer para ActiveX...2 1.2 Problemas comunes en sistema operativo Windows...8 1.2.1 Usuarios con sistema operativo Windows XP con el Service

Más detalles

ADMINISTRACIÓN ELECTRÓNICA EN EL AREA DE JUSTICIA.

ADMINISTRACIÓN ELECTRÓNICA EN EL AREA DE JUSTICIA. ADMINISTRACIÓN ELECTRÓNICA EN EL AREA DE JUSTICIA. CASO PRÁCTICO REGISTRO DE CONTRATOS DE SEGUROS CON COBERTURA POR FALLECIMIENTO INDICE Negocio - Introducción - Proyecto Pionero - El Cliente - Valores

Más detalles

Aplicativo WEBSEC Banxico (WEBSEC )

Aplicativo WEBSEC Banxico (WEBSEC ) Aplicativo WEBSEC Banxico (WEBSEC ) Manual de Usuario Versión E ADVERTENCIA El Banco de México se ha preocupado por la difusión y el correcto uso de la firma electrónica avanzada. Por tal motivo, publica

Más detalles

PROCEDIMIENTO ESPECÍFICO. Código G022-02 Edición 0

PROCEDIMIENTO ESPECÍFICO. Código G022-02 Edición 0 Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. COMPONENTES

Más detalles

Requisitos Técnicos y de Configuración Sistema de Notificación Electrónica

Requisitos Técnicos y de Configuración Sistema de Notificación Electrónica Requisitos Técnicos y de Configuración Sistema de Notificación Electrónica Índice 1. CLIENTES WINDOWS... 3 2.1.1. Sistemas Operativos aceptados.... 3 2.1.2. Navegadores de Internet.... 5 2.1.3. Máquina

Más detalles

Guía para verificar documentos firmados digitalmente.

Guía para verificar documentos firmados digitalmente. Guía para verificar documentos firmados digitalmente. DIRECCIÓN DE CERTIFICADORES DE FIRMA DIGITAL Versión 1.0 Fecha Versión Autor(es) Aprobado Descripción 14-12-2012 1.0 Mario Alvarez C. Alexander Barquero,

Más detalles

DNI electrónico / FNMT

DNI electrónico / FNMT DNI electrónico / FNMT Máster en Economía Digital e Industrias Creativas Miguel Vidal ETSIT, URJC Twitter: @mvidallopez Israel Herraiz ETSICCP, UPM Twitter: @herraiz 7 de octubre de 2011 Miguel Vidal /

Más detalles

Certificados de sede electrónica

Certificados de sede electrónica GOBIERNO MINISTERIO DE ESPAÑA Centro de Calidad, Auditoría y Seguridad Certificados de sede electrónica Políticas de Certificación CORREO ELECTRONICO C/ Dr. Tolosa Latour, s/n 24041 MADRID TEL: 91 390

Más detalles

Política de certificación Certification policy Certificados de sello de Administración, Órgano o Entidad de Derecho Público

Política de certificación Certification policy Certificados de sello de Administración, Órgano o Entidad de Derecho Público Signe Autoridad de Certificación Política de certificación Certification policy Certificados de sello de Administración, Órgano o Entidad de Derecho Público Versión 1.0 Fecha: 2/11/2010 Seguridad documental

Más detalles

Software Criptográfico FNMT-RCM

Software Criptográfico FNMT-RCM Software Criptográfico FNMT-RCM ÍNDICE 1. DESCARGA E INSTALACIÓN DEL SOFTWARE 2. EXPORTACIÓN DE CERTIFICADOS EN MICROSOFT INTERNET EXPLORER 3. IMPORTACIÓN DEL CERTIFICADO A LA TARJETA CRIPTOGRÁFICA -2-

Más detalles

SISTEMAS IDEALES SISTIDE, S.A. SISTEMA GESTION DE USUARIOS

SISTEMAS IDEALES SISTIDE, S.A. SISTEMA GESTION DE USUARIOS SISTEMAS IDEALES SISTIDE, S.A. SISTEMA GESTION DE USUARIOS PÁGINA 2 SISTEMAS IDEALES SISTIDE, S.A. SISTEMA DE GESTIÓN DE USUARIOS (SGU) Hoy en día los centros de tecnología de información tienen a su cargo

Más detalles

Guía de instalación de certificado digital y DNIe. v 04

Guía de instalación de certificado digital y DNIe. v 04 Guía de instalación de certificado digital y DNIe v 04 14/11/2011 Índice 1 Introducción... 3 2 Requisito de acceso a la sede de Diputación de Valladolid, Cómo incluir en Windows una Entidad de confianza?...

Más detalles

Aplicaciones Clientes

Aplicaciones Clientes Manual de Técnico de Instalación Versión 1.0 Aplicaciones Clientes Segunda Generación de Sistemas Ingresadores Mayo 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN...1 2 OBJETIVO...1 3 TÉRMINOS Y DEFINICIONES...1

Más detalles

Conceptos útiles y glosario de definiciones

Conceptos útiles y glosario de definiciones http://www.java.com/es/download/faq/helpful_concepts.xml junio 16, 2015 Conceptos útiles y glosario de definiciones Para ayudar a los que visiten las páginas de ayuda con los conceptos y términos con los

Más detalles

1. Requisitos Mínimos... 2. 2. Consideraciones de la Versión de java JRE 1.5 update22 o superior (No la versión JRE 1.6)... 3. 2.1. Instalación...

1. Requisitos Mínimos... 2. 2. Consideraciones de la Versión de java JRE 1.5 update22 o superior (No la versión JRE 1.6)... 3. 2.1. Instalación... Guía de usos Sede electrónica OARGT Excma. Diputación Provinciall de Cáceres INDICE 1. Requisitos Mínimos... 2 2. Consideraciones de la Versión de java JRE 1.5 update22 o superior (No la versión JRE 1.6)...

Más detalles

Dirección General de Administración de Bienes y Contratación Administrativa

Dirección General de Administración de Bienes y Contratación Administrativa Dirección General de Administración de Bienes y Contratación Administrativa Señores Directores Administrativos Proveedurías Institucionales S.O. San José, 01 de abril del 2011 DGABCA-NP-239-2011 Estimados(as)

Más detalles

Sistema de Recepción de Información de Resoluciones en materia de Comprobación Fiscal Manual del Usuario

Sistema de Recepción de Información de Resoluciones en materia de Comprobación Fiscal Manual del Usuario Sistema de Recepción de Información de Resoluciones en materia de Comprobación Fiscal Manual del Usuario 1 ÍNDICE INTRODUCCIÓN...3 OBJETIVO...4 ALCANCE...5 CONFIGURACION...6 REQUERIMIENTOS Y CARACTERÍSTICAS

Más detalles

Guía de Inicio Respaldo Cloud

Guía de Inicio Respaldo Cloud Respaldo Cloud Para Microsoft Windows Versión 1.0 1. Contenidos Guía de Inicio Qué es Respaldo Cloud?... 3.1 Información de Acceso... 3.2 Requisitos de Sistema... 4.3 Sistemas operativos soportados...

Más detalles

MANUAL DE USUARIO DE LA AUTORIDAD CERTIFICADORA DE GUERRERO

MANUAL DE USUARIO DE LA AUTORIDAD CERTIFICADORA DE GUERRERO MANUAL DE USUARIO DE LA AUTORIDAD CERTIFICADORA DE GUERRERO 1 Contenido Prefacio... 4 Dirigido a... 4 Estructura del Documento... 4 Capitulo 1: Requisitos Previos... 4 Capitulo 2: Marco Legal... 4 Capitulo

Más detalles

Guía Rápida de Inicio

Guía Rápida de Inicio Guía Rápida de Inicio 1. Acerca de esta Guía Esta guía le ayudará a instalar y dar los primeros pasos con BitDefender Security for File Servers. Para disponer de instrucciones detalladas, por favor, diríjase

Más detalles

SGNTJ. Desarrollo LexNet. Manual de Usuario LexNet: Requisitos técnicos de instalación de LexNet. Público. SGNTJ - Desarrollo LexNet

SGNTJ. Desarrollo LexNet. Manual de Usuario LexNet: Requisitos técnicos de instalación de LexNet. Público. SGNTJ - Desarrollo LexNet SGNTJ Desarrollo LexNet Manual de Usuario LexNet: Requisitos técnicos de instalación de LexNet Público ELABORADO POR: Desarrollo LexNet REVISADO POR: Desarrollo LexNet APROBADO POR: SGNTJ Fecha: 24/07/2014

Más detalles

Manual de Usuario Edición: 1.00 Marzo 2008. C/Orense Nº62 Local. 28020 Madrid Tel.: +34 91 417 08 90 Fax: +31 91 555 03 62. www.fenitel.

Manual de Usuario Edición: 1.00 Marzo 2008. C/Orense Nº62 Local. 28020 Madrid Tel.: +34 91 417 08 90 Fax: +31 91 555 03 62. www.fenitel. Manual de Usuario Edición: 1.00 Marzo 2008 C/Orense Nº62 Local. 28020 Madrid Tel.: +34 91 417 08 90 Fax: +31 91 555 03 62 www.fenitel.es CONTENIDO CONTENIDO...1 1. INTRODUCCIÓN...2 2. DESCRIPCIÓN GENERAL...2

Más detalles

Icards Solutions S.A. de C.V.

Icards Solutions S.A. de C.V. Este documento explica la instalación, configuración y operación del sistema de emisión de tarjetas México Emprende. Fecha Autor Revisor Versión 10-06- 2011 Ana Karen Aguilar Rubén Pacheco López 1.0 24-06.2011

Más detalles

PROYECTO. Solución Empresarial Ingeniería y Desarrollo de Software www.solucionempresarial.com.ar - info@solucionempresarial.com.

PROYECTO. Solución Empresarial Ingeniería y Desarrollo de Software www.solucionempresarial.com.ar - info@solucionempresarial.com. PROYECTO 1 ÍNDICE 1. Presentación 2. Que es LDAP 3. Ventajas 4. Funcionamientos 5. Paquetes Adicionales 6. Requisitos 7. Objetivos 8. Presupuesto 7. Presupuesto 2 Presentación Se quiere implementar un

Más detalles

WINDOWS SERVER 2008 WINDOWS SERVER 2003

WINDOWS SERVER 2008 WINDOWS SERVER 2003 WINDOWS SERVER 2008 WINDOWS SERVER 2003 Requerimientos, Versiones y Características Eduardo Cruz Romero www.tics-tlapa.com Windows Server 2008 Windows Server 2008 diseñado para ofrecer a las organizaciones

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

SDK (SOFTWARE DEVELOPMENT KIT) DE FIRMA ELECTRÓNICA

SDK (SOFTWARE DEVELOPMENT KIT) DE FIRMA ELECTRÓNICA SDK (SOFTWARE DEVELOPMENT KIT) DE FIRMA ELECTRÓNICA Oscar García Reyes Business Sales Consultant. Área de Seguridad Grupo SIA Carlos Guerra Belver Consultor Técnico. Área de Infraestructuras de Seguridad

Más detalles

Instalación de certificados digitales

Instalación de certificados digitales Instalación de certificados digitales CONTENIDO El presente documento recoge una serie de indicaciones para poder usar certificados digitales en los navegadores soportados por la Sede Electrónica del CIEMAT

Más detalles

MANUAL DE INSTLACION ETOKEN PARA WINDOWS DESDE LA WEB. Gerente General Gerente General Gerente General

MANUAL DE INSTLACION ETOKEN PARA WINDOWS DESDE LA WEB. Gerente General Gerente General Gerente General MANUAL DE INSTLACION ETOKEN PARA WINDOWS DESDE LA IDENTIFICADOR NOMBRE DEL DOCUMENTO ESTADO DEL DOCUMENTO AREA RESPONSABLES REVISORES COM-MA-035 Manual de instalación etoken para Windows XP desde la web.

Más detalles

SILTRA Guía Técnica. Subdirección General de Afiliación, Cotización y Gestión del Sistema RED

SILTRA Guía Técnica. Subdirección General de Afiliación, Cotización y Gestión del Sistema RED SILTRA Guía Técnica Subdirección General de Afiliación, Cotización y Gestión del Sistema RED Julio de 2015 INDICE 1 Introducción... 3 2 Instalación de SILTRA... 3 2.1 Requerimientos... 3 2.2 Actuaciones

Más detalles

Generador de Requerimiento de Certificado de Firma Electrónica Avanzada

Generador de Requerimiento de Certificado de Firma Electrónica Avanzada SISTEMA PARA EL AHORRO PARA EL RETIRO DE LOS TRABAJADORES DE LA EDUCACIÓN DE TAMAULIPAS MÁS DE 15 AÑOS CONSTRUYENDO BENEFICIOS PARA UNA MEJOR CALIDAD DE VIDA Generador de Requerimiento de Certificado de

Más detalles

Contenido. 1. Requerimientos tecnológicos para utilizar los servicios informáticos de la... 3. 2. Ingresar al portal de la DIAN...

Contenido. 1. Requerimientos tecnológicos para utilizar los servicios informáticos de la... 3. 2. Ingresar al portal de la DIAN... Contenido 1. Requerimientos tecnológicos para utilizar los servicios informáticos de la... 3 2. Ingresar al portal de la DIAN... 6 3. Habilitar su cuenta de usuario externo... 8 4. Activar un certificado

Más detalles

MANUAL DE USUARIO. Funcionalidad del Asistente Técnico de Movistar. Funcionalidad del Asistente Técnico de Movistar. Guía Básica de Manejo

MANUAL DE USUARIO. Funcionalidad del Asistente Técnico de Movistar. Funcionalidad del Asistente Técnico de Movistar. Guía Básica de Manejo MANUAL DE USUARIO Funcionalidad del Asistente Técnico de GUÍA BÁSICA DE MANEJO Asistente Técnico de Índice Índice... 2 1 Introducción al Asistente Técnico de... 3 2 Funcionalidad recogida en el Asistente

Más detalles

Carpeta Virtual de Expedientes. Manual de usuario Solicitante

Carpeta Virtual de Expedientes. Manual de usuario Solicitante Carpeta Virtual de Expedientes Manual de usuario Solicitante ÍNDICE 1. Descripción general del servicio... 6 1.1. Funcionalidad del sistema... 6 1.2. Diccionario de claves... 6 2. Acceso al Servicio...

Más detalles

Seguridad. Estos son algunos de los elementos de alta tecnología que BANCOLOMBIA utiliza para garantizar la seguridad en sus transacciones:

Seguridad. Estos son algunos de los elementos de alta tecnología que BANCOLOMBIA utiliza para garantizar la seguridad en sus transacciones: Seguridad Su información está segura en BANCOLOMBIA En BANCOLOMBIA nos hemos propuesto asegurar la confidencialidad, disponibilidad e integridad de la información, uno de nuestros recursos más valiosos.

Más detalles

PROYECTO CÁLAMO: Mª Victoria Figueroa Domínguez Subdirectora Adjunta de Sistemas de Información Ministerio de Presidencia

PROYECTO CÁLAMO: Mª Victoria Figueroa Domínguez Subdirectora Adjunta de Sistemas de Información Ministerio de Presidencia PROYECTO CÁLAMO: Sistema de Información para la gestión de las reuniones de la Comisión General de Secretarios de Estado y Subsecretarios Sistema de Comisión Virtual sobre tablet PC Subdirectora Adjunta

Más detalles

Panda Perimetral Management Console. Guía para Partners

Panda Perimetral Management Console. Guía para Partners Panda Perimetral Management Console Guía para Partners Aviso de copyright Panda Security 2014. Todos los derechos reservados. Ni la documentación, ni los programas a los que en su caso acceda, pueden copiarse,

Más detalles

Autenticación LDAP - ORACLE

Autenticación LDAP - ORACLE I.E.S. Gonzalo Nazareno Autenticación LDAP - ORACLE Sistemas Gestores de Bases de Datos Pier Alessandro Finazzi José Manuel Ferrete Benítez 2011 Índice Oracle Identity Management... 3 Por qué Oracle Identity

Más detalles

Manual de Firma de documentos en Microsoft Word

Manual de Firma de documentos en Microsoft Word Manual de Firma de documentos en Microsoft Word Fecha: 05/09/2006 Versión: 1.0 Estado: APROBADO Nº de páginas: 25 OID: 1.3.6.1.4.1.8149.1.1.8.21 Clasificación: PUBLICO Archivo: firma-microsoft-word.doc

Más detalles

SISTEMA DE GESTIÓN DEL SERVICIO (SGS) Servicio de Puestos Virtuales. Guía de Usuario de Escritorios Virtuales

SISTEMA DE GESTIÓN DEL SERVICIO (SGS) Servicio de Puestos Virtuales. Guía de Usuario de Escritorios Virtuales SISTEMA DE GESTIÓN DEL SERVICIO (SGS) Servicio de Puestos Virtuales Guía de Usuario de Escritorios Virtuales Vicerrectorado de TIC, Calidad e Innovación Centro de Informática y Comunicaciones Título Entregable

Más detalles

Servicios TIC para el PAS

Servicios TIC para el PAS Servicios TIC para el PAS 2005, Tabla de contenidos 1 Objetivo del documento... 3 2 Introducción... 3 3 Equipamiento personal... 3 3.1 Hardware y Software... 3 3.2 Teléfonos... 4 3.3 Impresoras y fotocopiadoras...

Más detalles

DFirma PDA Aplicación de firma electrónica en dispositivos móviles. Manual de Usuario

DFirma PDA Aplicación de firma electrónica en dispositivos móviles. Manual de Usuario DFirma PDA Aplicación de firma electrónica en dispositivos móviles. Manual de Usuario Versión 1.0 TABLA DE CONTENIDO 1 Introducción... 3 2 Instalación... 3 2.1 Instalación de la aplicación en el dispositivo

Más detalles

MANUAL DEL INSTALADOR

MANUAL DEL INSTALADOR MANUAL DEL INSTALADOR Índice Índice... 2 Instalación... 3 Extracción de archivos... 3 Actualización de los archivos de sistema... 3 Pantalla inicial... 4 Selección de la ruta de instalación... 4 Selección

Más detalles

Despliegue de plataforma Q-expeditive

Despliegue de plataforma Q-expeditive How to Despliegue de plataforma Q-expeditive Versión: 2.0 Fecha de publicación 08-04-2011 Aplica a: Q-expeditive 3.0 y Q-flow 3.1 Índice Requerimientos de Software... 4 Diagramas de arquitectura... 5 Componentes

Más detalles

Pág. Tabla de contenido

Pág. Tabla de contenido Pág. Tabla de contenido Qué es Blackboard?... 4 Requerimientos de Hardware y Software... 4 Cómo iniciar?... 5 Cómo recuperar la contraseña?... 6 Navegación... 9 Cómo configurar mi perfil?... 9 Cambiar

Más detalles

Declaración Anual Personas Morales 2014

Declaración Anual Personas Morales 2014 Declaración Anual Personas Morales 2014 Estrategia de implementación: El 5 de diciembre 2014 inició la instalación de las aplicaciones. El 12 de diciembre 2014 se da a conocer a las ALSC, proporcionado

Más detalles

Arsys Backup Online Manual de Usuario

Arsys Backup Online Manual de Usuario Arsys Backup Online Manual de Usuario 1 Contenido 1. Instalación del Programa Cliente... 3 Pasos previos... 3 Instalación... 3 Configuración del acceso... 6 Ubicación del servidor de seguridad... 6 Datos

Más detalles

Seguridad en Internet

Seguridad en Internet Seguridad en Internet. Resumen Cuando se realizan pagos en Internet y acceso a sitios Web que requieren certificado, intervienen dos protocolos seguros SSL y SET, ofreciendo confidencialidad, identificación,

Más detalles

Certificados Digitales Tributarios. Guía de Instalación En Estaciones de Trabajo Microsoft Internet Explorer Versión 1.3s

Certificados Digitales Tributarios. Guía de Instalación En Estaciones de Trabajo Microsoft Internet Explorer Versión 1.3s Certificados Digitales Tributarios Guía de Instalación En Estaciones de Trabajo Microsoft Internet Explorer Versión 1.3s 10 de agosto de 2005 Introducción Este documento se ha preparado para ayudar en

Más detalles

Aplicación para la petición de Certificados Digitales

Aplicación para la petición de Certificados Digitales Aplicación para la petición de Certificados Digitales Descarga e instalación... 3 Petición Certificado Autoridad de Registro... 3 Requisitos para Autoridades de Registro... 3 Creación de un Certificado

Más detalles

Guía Práctica. Certificado electrónico: Qué es y cómo obtenerlo

Guía Práctica. Certificado electrónico: Qué es y cómo obtenerlo Guía Práctica Certificado electrónico: Qué es y cómo obtenerlo Qué es un certificado electrónico? Es un certificado que nos permite realizar trámites y gestiones con la Administración de la Comunidad de

Más detalles

La firma digital Las TIC en el comercio minorista de Aragón

La firma digital Las TIC en el comercio minorista de Aragón La firma digital Índice 1. Presentación... 3 2. Firma electrónica... 4 3. Cómo funciona?... 5 4. Cómo se consigue?... 6 5. Dónde se utiliza?... 7 6. Certificados digitales... 8 7. Características... 9

Más detalles

Eagle e Center. Tel 57 1 6064173 Bogotá Colombia. estadístico que genera reportes gráficos y consolidados de esta información.

Eagle e Center. Tel 57 1 6064173 Bogotá Colombia. estadístico que genera reportes gráficos y consolidados de esta información. El valor de la información, definiendo información como los datos procesados bajo parámetros útiles, es determinante en los mercados actuales, donde las decisiones basadas en hechos y datos garantizan

Más detalles

SOFTWARE DE LA CARPETA FAMILIAR

SOFTWARE DE LA CARPETA FAMILIAR SOFTWARE DE LA CARPETA FAMILIAR MANUAL DEL USUARIO DE LA HERRAMIENTA INFORMATICA S CF Manual detallado sobre el manejo y configuración del Software de la Carpeta Familiar, desde la configuración hasta

Más detalles

GESTOR DE DESCARGAS. Índice de contenido

GESTOR DE DESCARGAS. Índice de contenido GESTOR DE DESCARGAS Índice de contenido 1. Qué es DocumentosOnLine.net?...2 2. Qué es el Gestor de Descargas?...3 3.Instalación / Configuración...5 4.Descarga de Documentos...9 5.Búsqueda / Consulta de

Más detalles

SOLICITUD DEL CERTIFICADO

SOLICITUD DEL CERTIFICADO Tabla de Contenido MANUAL DEL USUARIO... Error! Marcador no definido. 1. Requerimiento de Certificación... 1 1.1 Llenar la forma... 2 1.2 Seleccionar el nivel de seguridad... 3 1.3 Generar las llaves...

Más detalles

PROCEDIMIENTO PARA EL ALTA, REHABILITACION, DESBLOQUEO Y BAJA DE USUARIOS UEPEX DE LA DGSIAF- SECRETARÍA DE HACIENDA

PROCEDIMIENTO PARA EL ALTA, REHABILITACION, DESBLOQUEO Y BAJA DE USUARIOS UEPEX DE LA DGSIAF- SECRETARÍA DE HACIENDA DE USUARIOS UEPEX DE LA - 1. Introducción 2 2. Alcance 2 3. Requerimientos 2 4. Procedimiento 3 4.1. Solicitud alta, rehabilitación, desbloqueo y/o baja de usuario 3 4.1.1. Alta de usuario 3 4.1.2. Baja

Más detalles

OPC Server PS/PSS MANUAL DE INSTRUCCIONES

OPC Server PS/PSS MANUAL DE INSTRUCCIONES SERVIDOR DE COMUNICACIONES OPC Server PS/PSS Versión 1.4 MANUAL DE INSTRUCCIONES (M98222901-03-13A) CIRCUTOR S.A. OPC Server PS/ PSS -1- ÍNDICE 1.- INSTALACIÓN DEL SERVIDOR OPC POWERSTUDIO / SCADA... 3

Más detalles

PORTAFIRMAS MANUAL DE CONFIGURACIÓN

PORTAFIRMAS MANUAL DE CONFIGURACIÓN PORTAFIRMAS MANUAL DE CONFIGURACIÓN V1.1_CAS GISA Portafirmas de negociados Página 2 de 29 TABLA DE CONTENIDOS 1 Introducción... 3 2 Requisitos del entorno... 4 3 Configuración de los certificados... 7

Más detalles

Portal Del Emisor MANUAL DEL USUARIO. Plataforma de Facturación Electrónica

Portal Del Emisor MANUAL DEL USUARIO. Plataforma de Facturación Electrónica Portal Del Emisor MANUAL DEL USUARIO Plataforma de Facturación Electrónica 1. Índice 1. Índice... 2 2. Descripción General... 3 2.1. Alcance... 3 2.2. Flujo de navegación... 4 2.3. Perfil del Usuario...

Más detalles

SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO

SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO 1 Objetivo del Manual Elaborado por: Revisado por: Aprobado por: Fecha: 13/08/2015 Difusión: Información del Manual

Más detalles

GUÍA BÁSICA DE USO DEL SISTEMA RED

GUÍA BÁSICA DE USO DEL SISTEMA RED SUBDIRECCIÓN GENERAL DE AFILIACIÓN, COTIZACIÓN Y GESTIÓN DEL SISTEMA RED GUÍA BÁSICA DE USO DEL SISTEMA RED Junio 2013 MINISTERIO DE EMPLEO Y SEGURIDAD SOCIAL TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL INDICE

Más detalles

CONVOCATORIA COMFUTURO

CONVOCATORIA COMFUTURO CONVOCATORIA COMFUTURO PRIMERA EDICIÓN GUÍA DEL SOLICITANTE Una iniciativa de ÍNDICE 0. Fases del proceso de solicitud.3 1. Preparación de la documentación a adjuntar en el formulario.3 A. Documentación

Más detalles

Las Firmas y los Certificados electrónicos (de la Administración Pública del Estado-CSIC)

Las Firmas y los Certificados electrónicos (de la Administración Pública del Estado-CSIC) Las Firmas y los Certificados electrónicos (de la Administración Pública del Estado-CSIC) Luis Hernández Encinas Grupo de investigación en Criptología y Seguridad de la Información (GiCSI) Dpto. Tratamiento

Más detalles

Manual de usuario de la aplicación para la presentación de solicitudes de ayudas para el Programa de Extensión de la Banda Ancha de Nueva Generación

Manual de usuario de la aplicación para la presentación de solicitudes de ayudas para el Programa de Extensión de la Banda Ancha de Nueva Generación aplicación para la presentación de solicitudes de ayudas para el Programa de Extensión de la Banda Ancha de Nueva Abril 2015 (v1.0) Índice. 1. Introducción... 3 2. Requisitos para ejecutar la aplicación...

Más detalles

Administración Local Soluciones

Administración Local Soluciones SISTEMA INTEGRADO DE GESTIÓN DE EXPEDIENTES MODULAR (SIGM) CONFIGURACIÓN PARA LA INTEGRACIÓN CON SISNOT Y CORREOS SIGM v3 Administración Local Soluciones Control de versiones Versión Fecha aprobación Cambio

Más detalles

Alcance y descripción del servicio BACKUP IPLAN

Alcance y descripción del servicio BACKUP IPLAN Alcance y descripción del servicio BACKUP IPLAN 1. Introducción. BACKUP IPLAN le permite al Cliente realizar resguardos periódicos la información, utilizando la infraestructura que IPLAN posee para este

Más detalles

MANUAL DE REGISTRO Y ACREDITACIÓN

MANUAL DE REGISTRO Y ACREDITACIÓN Recaudación Electrónica Versión 5.2 MANUAL DE REGISTRO Y ACREDITACIÓN Versión 5.2 Recaudación Electrónica Versión 5.2 2 ÍNDICE ÍNDICE... 2 CERTIFICACIÓN... 4 Sitio Web Recaudación Electrónica... 6 Home...

Más detalles

Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas.

Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas. 1. Manual de usuario 1.1 Esquema de Oasis Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas. Gracias a OASIS usted podrá comprar o seleccionar aplicaciones

Más detalles

EL TOKEN CDCARD: UNA SOLUCIÓN PARA GENERALIZAR LA FIRMA ELECTRÓNICA Y AUMENTAR LA SEGURIDAD EN LOS PROCESOS DE AUTENTICACIÓN

EL TOKEN CDCARD: UNA SOLUCIÓN PARA GENERALIZAR LA FIRMA ELECTRÓNICA Y AUMENTAR LA SEGURIDAD EN LOS PROCESOS DE AUTENTICACIÓN EL TOKEN CDCARD: UNA SOLUCIÓN PARA GENERALIZAR LA FIRMA ELECTRÓNICA Y AUMENTAR LA SEGURIDAD EN LOS PROCESOS DE AUTENTICACIÓN Profesor de Lenguajes y Sistemas Informáticos Universitat Jaume I Secretario

Más detalles

SISTEMA DE COPIAS DE SEGURIDAD

SISTEMA DE COPIAS DE SEGURIDAD SISTEMA DE COPIAS DE SEGURIDAD Ya tiene a su disposición el servicio de copias de seguridad adbackup en acuerdo con la ASOCIACIÓN DE ASESORÍAS DE EMPRESA haciendo más asequible el servicio, y con el respaldo

Más detalles

PREGUNTAS FRECUENTES PREGUNTAS RESPUESTAS. Principal» PREGUNTAS FRECUENTES

PREGUNTAS FRECUENTES PREGUNTAS RESPUESTAS. Principal» PREGUNTAS FRECUENTES Principal» PREGUNTAS FRECUENTES PREGUNTAS FRECUENTES PREGUNTAS 1. Qué tipos de certificados digitales pueden utilizarse con las aplicaciones telemáticas? 2. QUE SISTEMAS OPERATIVOS ME GARANTIZAN ACTUALMENTE

Más detalles

Guía de Firma Digital para XólidoSign DIRECCIÓN DE CERTIFICADORES DE FIRMA DIGITAL

Guía de Firma Digital para XólidoSign DIRECCIÓN DE CERTIFICADORES DE FIRMA DIGITAL Guía de Firma Digital para XólidoSign DIRECCIÓN DE CERTIFICADORES DE FIRMA DIGITAL Fecha Versión Autor(es) Aprobado Descripción 11-07-2012 1.0 Mario Alvarez C. Alexander Barquero Elizondo, Director DCFD

Más detalles

SERVICIO SaaS DE FIRMA ELECTRONICA AVANZADA

SERVICIO SaaS DE FIRMA ELECTRONICA AVANZADA SERVICIO SaaS DE FIRMA ELECTRONICA AVANZADA matedi 2014. TITULO 1 ÍNDICE 1. ANTECEDENTES. 2.CONSULTORÍA. 3. VALORACIÓN. 4. RESUMEN. matedi 2015. 2 1. ANTECEDENTES. Las empresas llevan a cabo una serie

Más detalles

PKI INTERNA EN EL MINISTERIO DEL INTERIOR

PKI INTERNA EN EL MINISTERIO DEL INTERIOR PKI INTERNA EN EL MINISTERIO DEL INTERIOR Francisco Romero Royo Jefe del Área de Redes y Comunicaciones S. G. del Centro de Sistemas de Información. Subsecretaría. Ministerio del Interior 1 Blanca PKI

Más detalles

Implantación de Aplicaciones Web Fecha: 20-09-13

Implantación de Aplicaciones Web Fecha: 20-09-13 Página 1 de 24 RESUMEN DE LA PROGRAMACIÓN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED CURSO AC. 2012 / 2013 ÁREA / MATERIA / MÓDULO PROFESIONAL Implantación de Aplicaciones Web (84 horas 4 horas semanales)

Más detalles

SGNTJ. Desarrollo LexNet. Manual de Usuario LexNet: Administrador Delegación Colegio Procuradores. Público. SGNTJ - Desarrollo LexNet

SGNTJ. Desarrollo LexNet. Manual de Usuario LexNet: Administrador Delegación Colegio Procuradores. Público. SGNTJ - Desarrollo LexNet SGNTJ Desarrollo LexNet Manual de Usuario LexNet: Administrador Delegación Colegio Procuradores Público ELABORADO POR: Desarrollo LexNet REVISADO POR: Desarrollo LexNet APROBADO POR: SGNTJ Fecha: Fecha:

Más detalles

Guía 1: Implementación de Modelo de Firma Electrónica Simple con Identificador/Clave

Guía 1: Implementación de Modelo de Firma Electrónica Simple con Identificador/Clave Guía 1: Implementación de Modelo de Firma Electrónica Simple con Identificador/Clave Agustinas 1291, piso 5, ofic. G - Santiago de Chile F: (56 2) 694 5808 / (56 2) 694 5964 - Fax: (56 2) 694 5965 http://www.modernizacion.gov.cl

Más detalles

Token ikey 2032 de Rainbow. Guía instalación y uso para Internet Explorer

Token ikey 2032 de Rainbow. Guía instalación y uso para Internet Explorer Token ikey 2032 de Rainbow Guía instalación y uso para Internet Explorer Abril de 2006 INDICE 1. Introducción 3 2. Requisitos mínimos 4 2.1 Requisitos de Hardware y Software 4 3. Configuración del ikey

Más detalles

Manual de usuario del módulo DEM Cliente

Manual de usuario del módulo DEM Cliente Manual de usuario del módulo DEM Cliente Febrero, 2012 Manual de usuario del módulo DEM Cliente INTRODUCCIÓN... 3 OBJETIVO... 3 REQUERIMIENTOS... 4 Equipo... 4 Software... 4 Conocimientos del usuario...

Más detalles

Contenido. Cambiar su contraseña o actualizar preguntas de recuperación de la contraseña de su cuenta de usuario.

Contenido. Cambiar su contraseña o actualizar preguntas de recuperación de la contraseña de su cuenta de usuario. Contenido Requerimientos tecnológicos se requieren para utilizar los servicios informáticos de la DIAN. Ingresar al Portal de la DIAN Habilitar cuenta de usuario externo Activar un certificado digital

Más detalles

MANUAL DE USUARIO FORMA OFICIAL 76 INFORMACIÓN DE OPERACIONES RELEVANTES (ARTÍCULO 31-A DEL CÓDIGO FISCAL DE LA FEDERACIÓN)

MANUAL DE USUARIO FORMA OFICIAL 76 INFORMACIÓN DE OPERACIONES RELEVANTES (ARTÍCULO 31-A DEL CÓDIGO FISCAL DE LA FEDERACIÓN) FORMA OFICIAL 76 INFORMACIÓN DE OPERACIONES RELEVANTES (ARTÍCULO 31-A DEL CÓDIGO FISCAL DE LA FEDERACIÓN) Mayo 2015 El Servicio de Administración Tributaria (SAT), pone a su disposición una guía para interactuar

Más detalles

Preguntas y respuestas más frecuentes (FAQ). ANIMSA

Preguntas y respuestas más frecuentes (FAQ). ANIMSA Preguntas y respuestas más frecuentes (FAQ). ANIMSA 1. Qué es una factura electrónica? 2. Qué ventajas aporta la factura electrónica? 3. Tiene validez legal la factura electrónica? 4. A qué obliga la LEY

Más detalles

TALLER DE TECNOLOGÍAS PARA LA EDUCACIÓN: PerúEduca Guía de Instalación y Configuración para Servidores

TALLER DE TECNOLOGÍAS PARA LA EDUCACIÓN: PerúEduca Guía de Instalación y Configuración para Servidores TALLER DE TECNOLOGÍAS PARA LA EDUCACIÓN: PerúEduca Guía de Instalación y Configuración para Servidores 1 GUÍA DE INSTALACIÓN Y CONFIGURACIÓN PARA SERVIDORES 1. INTRODUCCIÓN El sistema para servidores

Más detalles