Versión: 1.2. Fecha: 05 de Noviembre de 2013
|
|
- Veronica Río Revuelta
- hace 2 años
- Vistas:
Transcripción
1 Alternativas a los Applets de Java en las aplicaciones Web de firma Versión: 1.2 Fecha: 05 de Noviembre de Página 1 de 24
2 HOJA DE CONTROL Título Alternativas a los Applets de Java en Nombre del Alternativas a los Applets de Java en.pdf fichero Autor Tomás García-Merás Versión 1.2 Fecha Versión 05/11/2013 Copyright MinHAP Licencia CC-by-sa Aprobado por MinHAP Fecha Aprobación 05/11/13 Nº Total de páginas 24 Página 2 de 24
3 Contenido 1 Introducción Opción 1: Extensiones en navegadores Web Descripción de la solución Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Opción 2: API JavaScript normalizado y nativo a los navegadores Web Soporte del W3C a la criptografía vía JavaScript Detalle propuesta de tareas a realizar para la implementación práctica de la alternativa API Básico JavaScript Definición del API Implementación del API como extensión de Firefox Implementación del API como extensión de Chrome / Chromium Tareas de normalización API Extendido JavaScript PAdES XAdES Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Opción 3: Uso de aplicaciones nativas invocadas mediante protocolo (protocolo a medida) Descripción de la solución Página 3 de 24
4 4.2 Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Tareas comunes independientes de opción de implementación Resumen Página 4 de 24
5 1 Introducción Desde hace ya tiempo, se vienen sufriendo ciertos problemas con Java que están poniendo cada día más difícil considerar los Applets de Java como una solución de futuro para el Desde la falta de soporte en las nuevas plataformas operativas (Apple ios, Google Android, Microsoft Windows Phone, RT y 8 y superiores en modo UI Moderno, BlackBerry 10, etc.) hasta los grandes problemas de seguridad que plantean (continuas vulnerabilidades descubiertas), pasando por las dificultades que los navegadores ponen a su ejecución, como advertencias y diálogos de confirmación. La sustitución de los Applets de Java por otra tecnología no es tarea fácil, ya que, por una parte, se necesita una comunicación bidireccional con el JavaScript de la página Web (la firma es un paso más dentro de un completo flujo de trabajo) y, por otra, un acceso a los almacenes de claves y certificados, siendo por supuesto deseable el soporte de tarjetas inteligentes y dispositivos externos (como el DNIe). En este sentido, son varias las opciones posibles, siendo tres las más asequibles y alineadas con el proyecto 1. Desarrollo de extensiones para navegadores Web 2. Implantación de un API JavaScript normalizado 3. Uso de aplicaciones nativas con invocación por protocolo 2 Opción 1: Extensiones en navegadores Web 2.1 Descripción de la solución La mayoría de los navegadores Web soportan ampliaciones de su funcionamiento vía los llamados plugins y addons (extensiones). Estos se desarrollan habitualmente con tecnología nativa (usualmente C o C++), teniendo muy pocas restricciones en lo referente al acceso al sistema operativo subyacente (y por lo tanto a los almacenes de claves) y permiten exponer un API vía JavaScript para ser usados desde las aplicaciones Web. No obstante, lo que hace unos pocos años no era tan mala opción (de hecho, fue la escogida por muchos componentes de firma ), en la actualidad no es óptima, como a continuación se explica, en su soporte (enumerando las distintas tecnologías) en las Página 5 de 24
6 siguientes plataformas operativas: Microsoft Windows o ActiveX para Internet Explorer, se necesitan versiones diferentes de 32 y 64 bits para las distintas arquitecturas del navegador. o NSAPI/NPAPI para Chrome, Firefox y otros. Microsoft Windows 8 y 8.1 en modo UI Moderno y Windows RT o Internet Explorer no soporta complementos. Apple ios o Safari no admite complementos. o Chrome no admite complementos. Apple Mac OS X o NSAPI/NPAPI para Safari, Chrome, Firefox y otros. Google Android o Chrome no admite complementos. o Extensiones XPCOM para Mozilla Firefox. Linux o NSAPI/NPAPI para Chrome, Firefox y otros. Otros entornos o Internet Explorer en Windows Phone no admite complementos. o El navegador Web de BlackBerry 10 no admite complementos. Se puede observar de los datos anteriormente enumerados que una estrategia de extensiones de navegador podría dar una buena experiencia de usuario en Chrome y Firefox tanto en Linux, Windows, Mac OS X y Android, pero sin poder ofrecer compatibilidad en Apple ios. Sería necesario para Internet Explorer un desarrollo específico para el desarrollo de un control ActiveX, si bien conviene tener en cuenta que no funcionaría en las versiones UI Moderno de Windows 8 y 8.1, ya que la tecnología ActiveX está en pleno abandono por parte de Microsoft. No obstante, esta opción daría soporte a la gran mayoría de los usuarios, proporcionando una experiencia de usuario muy buena, ya que si se exponen las operaciones de firma vía JavaScript el usuario realmente no apreciaría ni cambios de contexto, ni advertencias, ni necesidad de acciones manuales ni otros efectos adversos que sí padecen los Applets de Java. No obstante, se introduce un inconveniente realmente difícil de evitar, que no se encontraba con los Applets de Java, y es la heterogeneidad de los entornos operativos, aspecto que afecta en dos sentidos: Página 6 de 24
7 Arquitectura de las extensiones de los navegadores. o Siendo las extensiones habitualmente desarrolladas en código nativo, se tienen que generar ejecutables para distintos entornos y arquitecturas, lo cual implica esfuerzos adicionales. Distintas tecnologías de almacenes de claves y certificados que obligan a distintos desarrollos, incluso para un mismo navegador. o CAPI en Windows, Llavero en Mac OS X, el almacén central de Android, NSS para los almacenes de Firefox, etc. El resultado final sería un núcleo de código común, y luego, en base a un esfuerzo adicional, toda una colección de módulos de acceso a almacenes de claves y certificados y proyectos de desarrollo en diferentes entornos (Visual Studio, Xcode, GCC, etc.). 2.2 Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Extensión Active Xpara Internet Explorer Dada la posibilidad de creación de controles ActiveX usando C# con.net, es posible la reutilización de ciertos activos del para Windows 8, entre los que encontramos: El motor de firma CAdES. La adaptación de las bibliotecas BouncyCastle para C#. En este sentido, sería necesario ejecutar las siguientes tareas para cerrar un control ActiveX completamente funcional: Tarea Coste estimado Estructura control ActiveX Instalador CAdES - Ampliación motor CAdES a multifirmas PAdES - Adaptación itextsharp PAdES - Motor PAdES XAdES - Motor XAdES TOTAL Extensión NPAPI / NSAPI / XPCOM Al haberse programado el motor CAdES para Apple ios en C estándar (en contraposición a Objective C, muy ligado a sistemas Apple), sería posible reutilizar ciertos activos del Cliente Página 7 de 24
8 @firma para Apple ios, entre los que encontramos: El motor de firma CAdES (incluidas las compilaciones ASN.1). La adaptación de las bibliotecas OpenSSL. En este sentido, sería necesario ejecutar las siguientes tareas para cerrar una extensión completamente funcional: Tarea Coste estimado Estructura extensión NSAPI/NPAPI Estructura extensión XPCOM Instalador Windows Instalador Mac OS X Instalador Linux CAdES - Ampliación motor CAdES a multifirmas PAdES - Ampliación bibliotecas Haru para soporte firmas PAdES - Motor PAdES en lenguaje C XAdES - Motor XAdES TOTAL Opción 2: API JavaScript normalizado y nativo a los navegadores Web Si bien las extensiones de los navegadores Web constituyen en muchos casos una opción viable para la realización de firmas s (hay que recordar que los Applets Java se ejecutan con Java Plugin, que no es otra cosa que una extensión), lo óptimo sería que pudiese hacerse el 100% del proceso en JavaScript con las funcionalidades estándar que proporcionan los navegadores, eliminando así la necesidad de binarios adicionales Por desgracia, el API JavaScript normal de los navegadores Web no incluye las funcionalidades necesarias. Adicionalmente, sería un error acotar las funcionalidades necesarias a la implementación de las operaciones criptográficas (RSA, huellas digitales, etc.) en JavaScript, que si bien es una tarea difícil (JavaScript no está pensado para los tratamientos binarios que requiere ASN.1 y los algoritmos RSA y de huellas digitales), lo cierto es que éste es una tema resuelto desde hace ya algunos años, y se pueden encontrar trabajos previos en los que basarse: Página 8 de 24
9 Etc. Partiendo de estos trabajos, se podría desarrollar la base para realizar cifrados RSA y huellas digitales SHA-1 y SHA-2, más un API ASN.1 básico (lo indispensable para operaciones PKCS#1), y con reutilizaciones adicionales y un trabajo extra de consolidación, un buen API JavaScript para X.509. No obstante, esto no soluciona la incapacidad de acceder de forma segura a las claves privadas de los ciudadanos desde JavaScript, asegurando que en ningún momento éstas queden accesibles para otro uso. De hecho, lo ideal es que el PKCS#1 por completo, incluyendo la huella digital, se realizase de una forma opaca para el JavaScript, proporcionando así una mayor seguridad. 3.1 Soporte del W3C a la criptografía vía JavaScript Hace un tiempo que se publicó por parte del W3C el borrador de una especificación que resulta bastante interesante en este sentido. La Web Cryptography API (http://www.w3.org/tr/webcryptoapi/), que cuenta con el soporte directo de Mozilla y Google (con lo que se adoptaría previsiblemente en Firefox y Chrome), más un apoyo algo más tímido por parte de Microsoft, quien expresa (a consultas del equipo del su intención de soportarla en Internet Explorer, una vez pasase de borrador a especificación final y fuese adoptada de forma general por la industria. Con el soporte de tres grandes navegadores en un estándar promovido por la W3C sería previsible su adopción por el resto del mercado (especialmente por Apple WebKit, que es la base de Apple Safari, Opera y el navegador de Android) y podría darse la impresión de que el problema estaría resuelto. No es así ya que, si se entra en el detalle de la especificación, se puede observar que lo que se propone es una implementación de ciertas operaciones criptográficas comunes (como cifrados RSA y firmas PKCS#1) a las cuales se le daría un API normalizado en JavaScript. Esas operaciones podrían estar aceleradas por el sistema operativo (y por hardware si este último lo soporta), pero no se resuelve el acceso seguro a las claves privadas y certificados del ciudadano. Es sin duda un avance, pero no solventa el principal inconveniente. No obstante, hay otra especificación del W3C específicamente para tratar los aspectos que la anterior dejaba sin hacerlo, la WebCrypto Key Discovery (https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/overview.html). Una lectura con detalle de la especificación muestra que es justo lo que se necesita: el acceso a Página 9 de 24
10 claves privadas pre-provisionadas (previamente instaladas en el equipo del ciudadano). De nuevo, existen inconvenientes, y son que la especificación no cuenta con un apoyo generalizado de la industria. Está promovida por Netflix con el interés de permitir modos avanzados de gestión de derechos digitales (DRM, básicamente sistemas anti-piratería y anti-copia) y esta orientación choca con el modelo de negocio de Google (que obtiene sus ingresos de la publicidad, en contraposición a la venta de activos digitales) y con el espíritu abierto de la Fundación Mozilla, por lo que no es previsible su soporte ni en Chrome ni en Firefox. En esta difícil situación, una de las vías de avance abiertas desde el equipo del consiste en el inicio de contactos con la Fundación Mozilla para evaluar la posible ampliación de la Web Cryptography API con funcionalidades que permitiesen referenciar claves privadas pre-existentes para operaciones seguras de firma. La respuesta ha sido muy positiva (con involucración directa de la Fundación Mozilla y Mozilla Hispano), siendo los pasos siguientes a recorrer una definición detallada del API necesario, más una implementación de referencia junto al resto de la especificación Web Cryptography API (posiblemente como una extensión de Firefox), mientras se propone como un API estándar (que vendría directamente con el navegador, sin necesitar extensiones). Por supuesto, sería necesaria también una coordinación cohesionada con Chromium y Google (igualmente con una extensión como implementación de referencia, intentando reutilizar el máximo número de activos de la extensión de Firefox), y más adelante, ya con el API consolidado y las implementaciones de referencia, contactar con Microsoft. Si se consiguiese la ampliación del estándar con el soporte de Mozilla, Google y Microsoft, sería cuestión de tiempo verlo reflejado en Apple WebKit y, por lo tanto, soportado en la práctica totalidad de las plataformas. 3.2 Detalle propuesta de tareas a realizar para la implementación práctica de la alternativa API Básico JavaScript Definición del API La base del proyecto es la definición de un API JavaScript normalizado que permita la realización de firmas s usando las claves privadas que el usuario tuviese instaladas en su navegador o sistema operativo. Página 10 de 24
11 El API deberá ser completamente seguro en lo referente a la custodia de las claves privadas y debe permitir al usuario tener control completo en todo momento sobre su uso. Las funcionalidades a proporcionar por el API serán como mínimo: Selección (segura) de una clave privada en base a su alias en el almacén de claves y certificados del usuario. Esta operación devolverá una referencia a la clave privada (nunca la clave privada en sí), sobre la que el usuario podrá dar permiso para un solo uso o para múltiples usos dentro de la misma sesión, con o sin confirmación explícita (habilitando así el uso en firmas masivas). Se deberá poder establecer filtros en la selección de la referencia en base a las características del certificado de su titular. o En base al número de serie del certificado. o En base al titular (sintaxis según RFC 2254). o En base al emisor (sintaxis según RFC 2254). o o En base al KeyUsage Otros filtros pre-construidos: Uso de DNIe. Cualificado de firma en base a su par de autenticación. Etc. Firma PKCS#1 de un contenido en Base64 usando una referencia a una clave privada. Obtención de la cadena de certificados asociada a una referencia a una clave privada. El API definido deberá estar fuertemente basado en las actuales iniciativas de la Página 11 de 24
12 W3C sobre criptografía, buscando en todo momento la reutilización y colaboración entre equipos de trabajo: Web Cryptography API : WebCrypto Key Discovery: https://dvcs.w3.org/hg/webcryptokeydiscovery/raw-file/tip/overview.html Implementación del API como extensión de Firefox El API JavaScript definido deberá implementarse como una extensión de Firefox que use NSS como origen de los certificados y las claves privadas del usuario, incluyendo los módulos PKCS#11 que el usuario tuviese instalados en Firefox (viendo el usuario final todos los módulos como un único almacén). La extensión deberá ser compatible con las siguientes versiones de Firefox: Firefox 32 bits para Microsoft Windows Firefox para Apple Mac OS X Firefox para Google Android Firefox 32 bits para Linux La extensión deberá ser desarrollada en colaboración con la Fundación Mozilla, de forma que puedan coordinarse, primero con la actual extensión de David Dahl para la W3C WebCrypto API (DOMCrypt: https://addons.mozilla.org/enus/firefox/addon/domcrypt/) y con las futuras implementaciones de los API del W3C Implementación del API como extensión de Chrome / Chromium El API JavaScript definido deberá implementarse como una extensión de Google Chrome / Chromium para Windows que use CAPI (Microsoft Crypto API) como origen de los certificados y las claves privadas del usuario. Debe buscarse en todo comento una colaboración y coordinación con Google que permita un trabajo conjunto en la implementación futura de los API del W3C. Página 12 de 24
13 Tareas de normalización Para asegurar que el API generado es una opción viable como estándar futuro de mercado, deberán trabajarse en las siguientes líneas: El Centro Criptológico Nacional (CCN: https://www.ccn.cni.es/) debe auditar los trabajos y certificar la seguridad de los mismos. Debe procurarse un trabajo con W3C, y en particular con Mozilla, Google y Netflix para intentar influir en los estándares desarrollados por esta organización. Debe procurarse un trabajo conjunto con Google y Mozilla, de forma que se intente que el API forme parte del núcleo JavaScript de Chrome y Firefox, con independencia de si finalmente se corresponden con los trabajos del W3C. Debe procurarse un contacto directo con Microsoft de forma que se pueda tener influencia directa para el soporte de estas tecnologías en Internet Explorer. Se deberá trabajar en implementaciones de servicios de referencia con organismos de primera línea, no solo como pruebas piloto, sino como forma de influencia general. Por ejemplo: Agencia Tributaria Ministerio de Hacienda y Administraciones Públicas Ministerio de Industria, Energía y Turismo. Etc API Extendido JavaScript Si bien el soporte de criptografía RSA, PKCS#1 y huellas digitales más el tratamiento seguro de claves privadas constituye la base mínima sobre la que implementar firmas digitales, es necesario un trabajo adicional considerable para poder construir firmas AdES completas, que se concreta en una serie de API desarrollados completamente en JavaScript. CAdES Página 13 de 24
14 Tareas adicionales a realizar (cada tarea tiene dependencias con las anteriores): API de tratamiento binario básico sobre Base64. API ASN.1 completo. API X.509 completo. Como mínimo tratamiento del TBSCertificate (To Be Signed), del Principal de emisor y titular, de clave pública, número de serie y KeyUsage. API CAdES. Capaz de generar al menos CAdES-BES-EPES. Contenido firma explícito o implícito. SigningCertificatev1 o SigningCertificatev2. Deberán reutilizarse los trabajos de software libre existentes que tengan una calidad suficiente y una licencia compatible: https://github.com/ziyan/javascript-rsa Etc PAdES Tareas adicionales a realizar (cada tarea tiene dependencias con las anteriores, y todo el bloque depende de la disponibilidad del soporte CAdES descrito en el punto anterior): Página 14 de 24
15 API PDF general. API diccionario PDF. API firmas PDF. El desarrollo deberá basarse, siempre que sea posible, en el API PDF de Mozilla (http://mozilla.github.io/pdf.js/), trabajando de forma conjunta con la Comunidad de Software Libre de ese proyecto en su evolución XAdES De forma análoga a CAdES, deberá implementarse un API que permita la formación de firmas XAdES-BES/EPES completas, soportando al menos las siguientes variantes: Tipos de dereferenciación: Local Remota por HTTP o HTTPS cuando el destino de la referencia no suponga un problema de XSS (Cross Site Scripting). Tipos de transformaciones: XPATH XPATH2 Enveloped Base64 Modos de firma Externally Detached Internally Detached Enveloped Página 15 de 24
16 Enveloping Referencias con MANIFEST Las tareas a desarrollar serían las siguientes: API XML genérico. API XML para transformaciones. API XML para dereferenciaciones. API XML para XMLDSig con atributos XAdES. Como en el resto de tareas, debe buscarse la reutilización de activos existentes de software libre (API XML, etc.) con licencia compatible y calidad apropiada. 3.3 Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Ningún activo actual del proyecto sería directamente reutilizable, por lo que sería necesario el desarrollo desde cero (usando bibliotecas de software libre cuando sea posible) de la totalidad de los módulos: Tarea Coste estimado General - API ASN.1 X.509 basado en biblioteca software libre General - API ASN.1 RSA basado en biblioteca software libre CAdES - Motor ASN.1 JavaScript CAdES - Motor CAdES PAdES - Ampliación JSPDF para soporte de firmas XAdES - Motor XAdES General - Extensión Firefox General - Gestión referencias claves privadas JavaScript TOTAL Página 16 de 24
17 4 Opción 3: Uso de aplicaciones nativas invocadas mediante protocolo (protocolo a medida) 4.1 Descripción de la solución En la actualidad, el ya implementa medios de firma desde aplicaciones Web que prescinden de Applets de Java, extensiones de navegador y API nativos JavaScript, y es lo que actualmente está disponible en el para Google Android (https://play.google.com/store/apps/details?id=es.gob.afirma), usando para ello la invocación por protocolo de aplicaciones nativas. La invocación por protocolo consiste en que una aplicación registra en el sistema operativo que es capaz de atender un determinado protocolo, de forma que cuando se produzca una llamada para apertura de una URI con ese protocolo, se invocará dicha aplicación. Esta técnica no es novedosa, y se implementa en la actualidad en todos los sistemas operativos y por miles de aplicaciones. Así, en cualquier entorno operativo, si se pide abrir una URI del tipo se abrirá el navegador Web, y si pide abrir otra que empiece por sip:// (Session Initiation Protocol) se abrirá, si se tiene, el programa de telefonía IP (Microsoft Lync por ejemplo en un sistema Windows). Trasladando esto al sería necesario desarrollar una aplicación nativa que registre el tratamiento de una URI cuyo esquema con seguridad no va a utilizar ninguna otra aplicación (por ejemplo afirma:// ). Así, cualquier llamada a este protocolo, hará que se abra la aplicación nativa. Entonces (tal y como se hace en las versiones para Android, ios y Windows 8 del se realiza desde JavaScript en la aplicación Web de firma, en vez de la carga del una llamada a este protocolo que contenga todo lo necesario para realizar la operación de firma, por ejemplo: afirma://sign?data=datosafirmar&alg=sha512withrsa&format=cades Esto provocaría que nuestra aplicación nativa (una nueva versión del se invocase recibiendo la URI completa, obteniendo entonces de ella qué es exactamente lo que debe hacer (en este ejemplo simplificado, una firma CAdES con SHA512). Si bien la invocación por protocolo consigue comunicar aplicación JavaScript en un navegador Web con una aplicación nativa que puede acceder a claves privadas de los ciudadanos sin exponer vulnerabilidades de seguridad, lo hace en un único sentido, siendo necesario Página 17 de 24
18 implementar medios adicionales para devolver por parte de la aplicación nativa los datos firmados al JavaScript que la invocó. Dado que no se puede establecer una comunicación IP local (causaría problemas de XSS si la Web original está alojada con SSL), una solución es que la aplicación nativa la envíe al servidor donde se aloja la aplicación Web para que ésta, mediante JavaScript asíncrono, la recoja cuando esté disponible. El proceso resultante sería más o menos el descrito en la imagen: 1. El navegador Web invoca a una App nativa mediante una URI especial, indicando una serie de información (datos a firmar, formato, opciones, etc.). 2. La App recibe los datos y realiza la firma usando las funciones nativas de gestión de claves y certificados. 3. La App nativa deposita el resultado de la firma en un servidor intermediario mediante una llamada a un servicio Web simple. 4. El navegador Web recoge el resultado de la operación del firma del servidor intermediario y continúa la ejecución de la lógica de negocio. 5. El resultado es que se consigue una comunicación bidireccional asíncrona entre aplicación JavaScript y Aplicación nativa que permite prescindir de los Applets de Java. Evidentemente, al proceso se le han añadido medidas de seguridad para que el tránsito de su firma por la red en el camino desde la aplicación Web hacia el JavaScript no implique peligro. Página 18 de 24
19 Este proceso es viable en la totalidad de sistemas operativos actuales, incluyendo Apple ios, Windows 8 y RT y Windows Phone (a partir de Windows Phone 8). Adicionalmente, se podría pensar en la posibilidad de registrar este tratamiento de protocolo a medida asociándolo a una aplicación Java, lo cual permitiría la reutilización de los activos actuales del en Java. Aunque las aplicaciones seguirían siendo Java, ya no serían Applets de Java, que es lo realmente problemático (por seguridad y compatibilidad) y, al menos Windows, Linux y Mac OS X, estarían cubiertos con un esfuerzo más o menos acotado. 4.2 Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución En los expedientes en curso del se incluye ya soporte de invocación por protocolo para la mayoría de los entornos: Microsoft Windows 7, Vista, XP o Soporte completo. Apple OS X o Soporte completo. Linux o Soporte completo. Google Android o PAdES y CAdES (carencia de XAdES monofásico). Apple ios o CAdES (carencia de XAdES y PAdES monofásico). Windows / Windows RT 8 y 8.1 o CAdES (carencia de XAdES y PAdES monofásico). Página 19 de 24
20 Para mejora del soporte, sería no obstante conveniente la ampliación del soporte monofásico del para Windows 8 a PAdES. Tarea Coste estimado CAdES - Ampliación motor CAdES a multifirmas PAdES - Adaptación itextsharp PAdES - Motor PAdES TOTAL Tareas comunes independientes de opción de implementación Observando las cifras del actual proyecto (http://devel.uji.es/sonar/dashboard/index/1993), con líneas de código, es fácil observar que el esfuerzo necesario para lograr la actual funcionalidad ha sido ingente, y por lo tanto que el migrarlo a distintos lenguajes de programación, con distintas bibliotecas, no será tampoco pequeño. Lo cierto es que una implementación auto-contenida, sin dependencias externas, en el que toda la funcionalidad se agrupe en un programa local (como el actual MiniApplet es absolutamente deseable, y muy especialmente si optásemos por la vía de API JavaScript estándar en los navegadores Web, ya que este código podría utilizarse sin modificaciones no solo en cualquier cliente (Windows, ios, Android, etc.), sino incluso en servidores. No obstante hay muchos factores que condicionan el esfuerzo necesario para llegar a este objetivo: Motores CAdES. o ios, Linux, Mac OS X y Windows (excepto RT, UI Moderno y Phone) Una implementación en C portable, usando compiladores ASN.1 y las bibliotecas OpenSSL es perfectamente viable (de hecho, es lo que se está haciendo actualmente en el para ios). No obstante, es un esfuerzo considerable, y el actual motor para ios carece aún de soporte de contrafirmas y cofirmas. Página 20 de 24
21 o o o Navegadores Web con JavaScript Tenemos API ASN.1 en JavaScript muy primitivos que pueden servir de base (incluso con un soporte inicial de X.509), pero el trabajo a realizar es enorme. Windows RT, Windows 8 y 8.1 ( UI Moderno ) y Windows Phone La existencia de las bibliotecas BouncyCastle en C# alivia mucho el esfuerzo necesario. De hecho, el ya un motor CAdES simple en.net para Windows 8 perfectamente funcional. Android Afortunadamente, el trabajo sobre JSE es 100% compatible con Android, por lo que este entorno operativo no presenta trabajo adicional, gracias a la buena calidad de los actuales activos del Motores PAdES o ios, Linux, Mac OS X y Windows (excepto RT, UI Moderno y Phone) El trabajo necesario para crear un API para el manejo de PDF en C o C++ es enorme. Aunque hay productos de Software Libre sobre los que empezar a trabajar (por ejemplo: ninguno ofrece las facilidades de itext (las bibliotecas que usa actualmente el o Navegadores Web con JavaScript Está disponible el API pdf.js de Mozilla como punto de partida, pero el trabajo que habría que realizar supera incluso al de un motor en C/C++. o Windows RT, Windows 8 y 8.1 ( UI Moderno ) y Windows Phone La existencia de las bibliotecas itext en C# alivia mucho el esfuerzo necesario, pero su calidad no es la misma que en Java, y no es desdeñable la dificultad de la tarea. o Android Afortunadamente, el trabajo sobre JSE es 100% compatible con Android con unas pequeñas modificaciones sobre itext, así que este entorno operativo no presenta trabajo adicional (de nuevo gracias a la alta calidad de los activos actuales). Si bien existe itextdroid, una versión de itext para Android, el usa un desarrollo propio basado en este, ya que el original presentaba problemas en las firmas s. Página 21 de 24
22 Motores XAdES o En cualquiera de los casos es necesaria una implementación completa partiendo de un API XML..NET dispone de ciertas facilidades y existen bibliotecas de Software Libre para C y C++ No obstante, la cantidad de opciones que dan las firmas XML (dereferenciaciones, transformaciones, modos, manifest, etc.) hace que cualquier aproximación al problema sea problemática. En este punto, vemos que si bien la parte de viabilidad de las alternativas viene dada por el acceso a los almacenes de claves desde JavaScript de forma segura (apoyándose en una aplicación externa), el peso de la dificultad en la implementación puede estar en la implementación de los motores de firma en los distintos formatos. En general, se podría tener cierto nivel de reutilización de los activos actuales del proyecto (en verde módulos necesarios que pueden tener cierto nivel de reutilización, en azul aquellos que deben desarrollarse desde cero): Interfaz Esquema Protocolo URL o API JavaScript (nativo o vía extensiones de navegador) Clientes Trifásicos C Motor CAdES C Clientes Trifásicos C# /.NET Motor CAdES C# /.NET Clientes Trifásicos Java Motor CAdES Java App Apple ios Extensión NSAPI/NPAPI Almacén NSS Llavero Mac OS X App Windows 8 / RT App Windows Phone Almacén PKCS#12 Aplicación Windows XP, Vista y 7 App Google Android Applet Java No obstante, todo problema tiene siempre distintas formas de resolverse, ya que estamos quizás olvidando que existen los llamados procesos de firma en varias fases, en los que parte del proceso, y es justo la composición del formato final de firma, se realiza en un servidor. Página 22 de 24
Invocación por protocolo de aplicaciones nativas desde páginas Web
Invocación por protocolo de aplicaciones nativas desde páginas Web Qué es la invocación por protocolo? Es un funcionamiento universal que los sistemas operativos mantengan una serie de asociaciones entre
Plataforma @firma Matriz de compatibilidad de applet 3.4
Versión:v01r01 Fecha: 10/07/2015 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio,
INSTRUCCIONES PARA EL USO DE LA FIRMA ELECTRÓNICA EN LA SEDE ELECTRÓNICA DE LA AGENCIA ESTATAL DE SEGURIDAD AÉREA
SECRETARÍA GENERAL COORDINACIÓN DE SISTEMAS DE INFORMACIÓN INSTRUCCIONES PARA EL USO DE LA FIRMA ELECTRÓNICA EN LA SEDE ELECTRÓNICA DE LA DE SEGURIDAD AÉREA Novedades A partir de noviembre de 2015, las
Plataforma @firma Matriz de compatibilidad de applet 3.4
Versión:v01r00 Fecha: 25/05/2015 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio,
Sistema Operativo Windows XP SP3 / Vista SP2 / 7 SP1 / Server 2003 SP2 / Server 2008 SP2 / 8 y superiores
Requisitos mínimos Sistema Operativo Windows XP SP3 / Vista SP2 / 7 SP1 / Server 2003 SP2 / Server 2008 SP2 / 8 y superiores - El Applet Cliente @firma no es compatible con Windows 8 RT. Linux 2.6 (Guadalinex
Requisitos cliente de firma de la plataforma @firma
Requisitos cliente de firma de la plataforma @firma 1. Requisitos mínimos. - Sistema Operativo: o Windows XP SP3 / Vista SP2 / 7 SP1 / Server 2003 SP2 / Server 2008 SP2 / 8 / 8.1 y es El Applet Cliente
Nombre del proyecto: Cliente @firma Organismo que lo presenta: Secretaría de Estado de Administraciones Públicas del Ministerio de Hacienda y
Nombre del proyecto: Cliente @firma Organismo que lo presenta: Secretaría de Estado de Administraciones Públicas del Ministerio de Hacienda y Administraciones Públicas. Dirección General de Modernización
Manual del integrador del
Manual del integrador del Versión 3.4 Esta obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. Manual de Integración Página 1 de 100 Índice 1 Introducción...
Versión:v01r06 Fecha: 07/11/2013. Plataforma @firma. Matriz de compatibilidad del cliente 3.3.1
Versión:v01r06 Fecha: 07/11/2013 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio,
Documento para la revisión de la configuración del ordenador para el uso del servicio electrónico de instalaciones de baja tensión
Documento para la revisión de la configuración del ordenador para el uso del servicio electrónico de instalaciones de baja tensión ÍNDICE ÍNDICE... 2 1. REVISION DE CONFIGURACION... 3 1.1. Comprobación
Sede electrónica DGT. Requisitos técnicos equipos informáticos de los ciudadanos para el uso del cliente de firma
Sede electrónica DGT Requisitos técnicos equipos informáticos de los ciudadanos para el uso del cliente de firma Índice General 1 CONFIGURACIÓN... 3 2 REQUISITOS MÍNIMOS... 3 2.1 VERSIÓN DEL NAVEGADOR
Manual del integrador del MiniApplet v1.3 del Cliente @firma
DIRECCIÓN DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS Manual del integrador del MiniApplet v1.3 del Cliente @firma Índice de contenidos 1 Introducción...7 1.1 Productos de terceros incluidos con el...7 2 Requisitos
Suite @firma. Dirección de Tecnologías de la Información y las Comunicaciones Ministerio de Hacienda y Administraciones Públicas.
Suite @firma Dirección de Tecnologías de la Información y las Comunicaciones Ministerio de Hacienda y Administraciones Públicas @firma 1 Soluciones Firma Autenticación? Identidad 2 2 Suite @firma @firma
Consejería de Hacienda y Administración Pública. Cliente 3.1.0 @firma v5: Preguntas, problemas y respuestas
Sevilla, noviembre de 2010 Control de Versiones Hoja de control Fecha Autor Descripción 15/11/2010 RPV Versión 1.0 Página 2 de 15 Contenido 1 Sobre el cliente de firma... 4 2 Entornos soportados... 4 3
Plataforma @firma. Matriz de compatibilidad del cliente de firma 3.2.1. Versión:v02r00 Fecha: 09/04/2012
Versión:v02r00 Fecha: 09/04/2012 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio,
Título del proyecto: Cliente @firma Implantación: Administraciones públicas en general, organismos, empresas y ciudadanía. Organismo que lo presenta:
Título del proyecto: Cliente @firma Implantación: Administraciones públicas en general, organismos, empresas y ciudadanía. Organismo que lo presenta: Secretaría de Estado de Administraciones Públicas del
Manual de usuario para el uso del certificado electrónico en la Universidad de Murcia
Manual de usuario para el uso del certificado electrónico en la Universidad de Murcia Versión: 2.14.10.03 Contenido 1 Qué puedo encontrar en este manual?... 3 2 Uso del certificado electrónico desde la
DEV SISTEMA DE NOTIFICACIONES ELECTRÓNICAS VIALES ADMINISTRATIVAS DIRECCIÓN ELECTRÓNICA VIAL
DEV SISTEMA DE NOTIFICACIONES ELECTRÓNICAS VIALES ADMINISTRATIVAS DIRECCIÓN ELECTRÓNICA VIAL Requisitos técnicos equipos informáticos de los ciudadanos Índice General 1 VERIFICACIÓN RÁPIDA DE CONFIGURACIÓN...
PRIMEROS PASOS EN DELTA
PRIMEROS PASOS EN DELTA INTRODUCCIÓN Para comenzar a utilizar la aplicación Delta, es necesario llevar a cabo una serie de pasos de configuración y verificación previos. Algunos de ellos son comunes a
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)...
Manual del integrador del
Manual del integrador del Versión 3.3.1 u5 Esta obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. Manual de Integración Página 1 de 160 Índice 1Introducción...3
Requisitos mínimos. ANEXO I: Certificado digital
Página 1 de 16 ANEXO I: Certificado digital Requisitos mínimos Sistema Operativo o Windows 2000 / XP / Vista / 7 / Server 2003 / Server 2008 y superiores o Linux 2.6 (Guadalinex y Ubuntu) y superiores
SOLICITUD ELECTRÓNICA DE AYUDAS
Sólo podrán presentar la solicitud aquellos usuarios identificados con un certificado electrónico aceptado por la Administración Pública. A excepción de personas físicas, sin representante legal, que quieran
Requisitos dd de funcionamiento y entornos probados Contenido
Requisitos dd de funcionamiento y entornos probados Contenido 1. Requisitos en función del Sistema operativo... 2 1.1. Requisitos de funcionamiento en Windows XP (32 )... 2 1.2. Requisitos de funcionamiento
Resolución de incidencias para el applet de @firma. Versión 1.0
Resolución de incidencias para el applet de @firma Versión 1.0 Control Versión 1.0 Fecha: 10-06-2014 Modificaciones: Primera versión 1 Introducción 4 2 Requisitos mínimos 4 2.1 Entorno de ejecución de
PRIMEROS PASOS EN LA APLICACIÓN REA
PRIMEROS PASOS EN LA APLICACIÓN REA INTRODUCCIÓN El objetivo de este documento es facilitar al usuario la utilización de los certificados y la firma electrónica en la aplicación REA, mediante la realización
MARCO DE REFERENCIA PARA LA PLATAFORMA DE INTEROPERABILIDAD. Tratamiento de incidencias sobre Firma Digital en Platino
Interoperabilidad de los servicios telemáticos de la Administración Pública de la CAC Página 1 de 21 MARCO DE REFERENCIA PARA LA PLATAFORMA DE INTEROPERABILIDAD Tratamiento de incidencias sobre Firma Digital
OVIA: Oficina Virtual de Impuestos Autonómicos
OVIA: Oficina Virtual de Impuestos Autonómicos La Oficina Virtual de Impuestos Autonómicos (OVIA) permite realizar trámites de forma no presencial para presentar impuestos y modelos de la Junta de Castilla
Manual usuario Empresas Plataforma intercambio seguro de fichas.
ÍNDICE 1. Introducción... 5 2. Plataforma de Intercambio Seguro de Fichas... 7 3. Generación de Fichas... 8 4. Compresión de Fichas... 9 4.1 Requisitos... 9 4.2 Proceso... 9 5. Ensobrado y Firma del Envío...
PRESENTACIÓN DE ESCRITOS Y COMUNICACIONES. Requisitos Técnicos
PRESENTACIÓN DE ESCRITOS Y COMUNICACIONES Requisitos Técnicos Índice General 1 INTRODUCCIÓN... 3 2 SI USA COMO NAVEGADOR MS INTERNET EXPLORER... 4 2.1 CONFIGURACIÓN DE LAS PROPIEDADES DEL CERTIFICADO RAÍZ
Manual del uso de la Firma Electrónica en la Sede del Consejo Superior de Deportes. Manual de usuario Versión 1.2
Manual del uso de la Firma Electrónica en la Sede del Consejo Superior de Deportes Manual de usuario Versión 1.2 Histórico de versiones: Versión Fecha Resumen de los cambios producidos 1.0 03/12/2014 Versión
Consejería de Hacienda y Administración Pública. Manual del integrador del cliente
Sevilla, noviembre de 2010 Control de Versiones Hoja de control Fecha Autor Descripción 03/11/2010 RPV Adaptación manual del integrador MPR Página 2 de 106 Contenido 1 Introducción... 8 2 Objeto y alcance...
Manual de usuario. Configuración de navegadores para el uso de funcionalidades de firma en la Sede Electrónica de la Seguridad Social
Manual de usuario Configuración de para el uso de funcionalidades de firma en la Sede Electrónica de la Seguridad Social INDICE 1. OBJETIVO... 3 2. CONFIGURACIÓN DE LOS NAVEGADORES... 4 2.1. Restricción
SPRI FIRMA ELECTRONICA DE DOCUMENTOS
SPRI FIRMA ELECTRONICA DE DOCUMENTOS CONTENIDO Apartado Página 1 Introducción... 1 2 Configuración previa del navegador... 2 2.1 Chrome...3 2.2 Internet Explorer...7 2.3 Firefox...9 2.4 Safari... 13 3
Bit4id Soluciones en Identidad y Firma Digital
Bit4id Soluciones en Identidad y Firma Digital Bit4id 2 >> claves Zero Installation: hacer funcionar nuestra tecnología sin los costes de gestión relacionados con la instalación. Portable: total independencia
KESDEE Equipo de Apoyo. Fecha: 03 de enero 2014
Detalles de acceso para Cursos Desarrollado por KESDEE Autor: KESDEE Equipo de Apoyo Versión: 3.0 Fecha: 03 de enero 2014 1 Tabla de contenidos 1. Introducción... 3 2. KESDEE s E-learning & Producto de
SOLICITUD ELECTRÓNICA DE AYUDAS
Sólo podrán presentar la solicitud aquellos usuarios identificados con un certificado electrónico aceptado por la Administración Pública. A excepción de personas físicas, sin representante legal, que quieran
Introducción a Gestión de Proyectos. Beneficios del Sistema. Arquitectura y Diseño del Aplicativo. Requerimientos del Sistema.
Introducción a Gestión de Proyectos. Beneficios del Sistema. Arquitectura y Diseño del Aplicativo. Requerimientos del Sistema. Introducción a gestión de proyectos Un sistema de gestión de proyectos es
LBINT. http://www.liveboxcloud.com
2014 LBINT http://www.liveboxcloud.com LiveBox Srl no asume responsabilidades o garantías sobre el contenido y uso de ésta documentación y declina cualquier garantía explicita o implícita de comercialidad
GUÍA DE CONFIGURACIÓN PC PARA HACER USO DE LA SEDE ELECTRÓNICA DEL CABILDO DE GRAN CANARIA
GUÍA DE CONFIGURACIÓN PC PARA HACER USO DE LA SEDE ELECTRÓNICA DEL CABILDO DE GRAN CANARIA CONTROL DE CAMBIOS Versión Fecha Páginas afectadas Cambios 1.0 14/10/2015 Todas Versión inicial del documento
Guía de Incidencias del
Guía de Incidencias del Autor: Tipo de Documento: Grupo de Trabajo: Versión: Ministerio de la Presidencia Junta de Andalucía Guía @firma 1.0 RC6 Fecha: 08/02/2010 Fichero: Guía Incidencias 1.0 RC6 Guía
Preguntas más Frecuentes en el Uso de ORVE/SIR COD. ORVE12072. Proyecto/Servicio. Tipo de documento. Fecha de entrega 21/08/2013.
MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS SECRETARÍA DE ESTADO DE ADMINISTRACIONES PÚBLICAS DIRECCIÓN GENERAL DE MODERNIZACIÓN ADMINISTRATIVA, PROCEDIMIENTOS E IMPULSO DE LA ADMINISTRACIÓN ELECTRONICA
WEBSIGNER APPLET FAQS
WebSigner 6.4 WEBSIGNER APPLET FAQS Versión 1.1 HOJA DE CONTROL DOCUMENTAL Resumen El propósito de este documento es proveer una guía de FAQs para resolver las preguntas más comunes sobre este componente.
INSTITUTO POLITÉCNICO NACIONAL
INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE TURISMO TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN NAVEGADOR Y BUSCADOR WEB MÁRQUEZ GARCÍA ALLAN ITM7 Navegador Un Explorador Web o Navegador es un
PRIMEROS PASOS EN DELTA
PRIMEROS PASOS EN DELTA INTRODUCCIÓN Para comenzar a utilizar la aplicación Delta, es necesario llevar a cabo una serie de pasos de configuración y verificación previos. Algunos de ellos son comunes a
MANUAL DE INSTRUCCIONES PARA LA INSCRIPCIÓN TELEMÁTICA EN LAS PRUEBAS DE SELECCIÓN PARA VIGILANTES DE SEGURIDAD Y SUS ESPECIALIDADES.
MANUAL DE INSTRUCCIONES PARA LA INSCRIPCIÓN TELEMÁTICA EN LAS PRUEBAS DE SELECCIÓN PARA VIGILANTES DE SEGURIDAD Y SUS ESPECIALIDADES. INSTRUCCIONES BÁSICAS PARA CUMPLIMENTAR LA SOLICITUD DE INSCRIPCIÓN
Preguntas más Frecuentes en el Uso de ORVE/SIR COD. ORVE12072. Proyecto/Servicio. Tipo de documento. Fecha de entrega 27/05/2013.
MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS SECRETARÍA DE ESTADO DE ADMINISTRACIONES PÚBLICAS DIRECCIÓN GENERAL DE MODERNIZACIÓN ADMINISTRATIVA, PROCEDIMIENTOS E IMPULSO DE LA ADMINISTRACIÓN ELECTRONICA
APLICACIÓN PARA LA RENDICIÓN TELEMÁTICA DE CUENTAS Y REMISIÓN DE LA INFORMACIÓN RELATIVA A LA CONTRATACIÓN
APLICACIÓN PARA LA RENDICIÓN TELEMÁTICA DE CUENTAS Y REMISIÓN DE LA INFORMACIÓN RELATIVA A LA CONTRATACIÓN GUÍA DE PROCEDIMIENTOS DE ALTA Y ACCESO DE USUARIOS VERSIÓN 12 ÍNDICE 1. INTRODUCCIÓN... 3 2.
Acuerdo de Nivel de Servicio de la Plataforma de validación y firma electrónica @firma del MINHAP para Organismos Usuarios
Acuerdo de Nivel de Servicio de la Plataforma de validación y firma electrónica @firma del MINHAP para Organismos Autor: Tipo de Documento: Grupo de Trabajo: Versión: 2.8 Fecha: 14/04/2015 Fichero: Ministerio
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
DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES
DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES SERVICIO DE NOTIFICACIONES ELECTRÓNICAS Y DIRECCIÓN ELECTRÓNICA HABILITADA MANUAL DE CONFIGURACIÓN PARA SISTEMAS WINDOWS NOMBRE FECHA Elaborado por:
CarFirma Firma electrónica del Gobierno de La Rioja Manual de usuario
CarFirma Firma electrónica del Gobierno de La Rioja Manual de usuario 1 ÍNDICE Í 1 ÍNDICE...2 2 INTRODUCCIÓN...3 3 DETECCIÓN DE LA APLICACIÓN...4 4 DESCARGA...6 5 INSTALACIÓN Y DESINSTALACIÓN...8 6 EJECUCIÓN...10
Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada
Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada Apartado Postal Electrónico Manual de Configuración de Navegadores Abril 2011 Versión: Abril 2011 Página 1 de 28 Índice de Contenidos
Análisis funcional del Cliente @firma
Análisis funcional del Índice de contenidos Anexo A.Introducción... 3 Anexo B.Requisitos funcionales... 7 Anexo C.Descomposición funcional... 9 Anexo D.Algoritmos de cifrado... 27 Anexo E.Sobres digitales...
Manual de configuración navegador Mozilla Firefox
Manual de configuración navegador Mozilla Firefox Guía de configuración del navegador Mozilla Firefox para un correcto funcionamiento con la Banca electrónica de particulares ÍNDICE 0. Introducción 1.
CONFIGURACIÓN DEL NAVEGADOR PARA EL USO DE LA SEDE ELECTRÓNICA DE DEFENSA
MINISTERIO DE SEDE ELECTRÓNICA DEL CONFIGURACIÓN DEL NAVEGADOR PARA EL USO DE LA SEDE ELECTRÓNICA DE SEDE ELECTRÓNICA DEL Este documento contiene información y material confidencial propiedad del Ministerio
Antes de iniciar su solicitud, desde la AECID, se recomienda tenga en cuenta las siguientes consideraciones:
Instrucciones Técnicas para cumplimentar una SOLICITUD DE SUBVENCIONES A ACCIONES DE COOPERACIÓN PARA LA REALIZACIÓN PROYECTOS DE INNOVACIÓN PARA EL DESARROLLO DE LA AECID. En el presente documento encontrará
SealSign for SharePoint Gestión documental, workflow y firma digital
SealSign for SharePoint Gestión documental, workflow y firma digital Introducción SealSign for SharePoint es una plataforma integrada de gestión documental, flujos de trabajo y firma digital que permite
REQUISITOS TÉCNICOS. Entidad emisora de certificados. Documento Nacional de Identidad electrónico (DNIe) www.dnielectronico.es
REQUISITOS TÉCNICOS 1. Certificado Digital La inscripción en procesos selectivos a través del portal del ciudadano ips.060.es requiere disponer de un certificado digital reconocido. La relación de certificados
MANUAL DE USUARIO DE LA UTILIDAD DE COPIA, FIRMA Y VALIDACIÓN ELECTRÓNICA ecofirma v1.1.1
MANUAL DE USUARIO DE LA UTILIDAD DE COPIA, FIRMA Y VALIDACIÓN ELECTRÓNICA ecofirma v1.1.1 Madrid, 03 de agosto de 2009 Í n d i c e 1. INTRODUCCIÓN...3 2. REQUISITOS...5 3. CONFIGURACIÓN DE LA UTILIDAD...6
SealSign. Plataforma completa para la firma digital y biométrica de documentos electrónicos
SealSign Plataforma completa para la firma digital y biométrica de documentos electrónicos SealSign Plataforma de firma de documentos electrónicos accesible desde las aplicaciones de negocio y los dispositivos
APLICACIÓN PARA LA RENDICIÓN TELEMÁTICA DE CUENTAS Y REMISIÓN DE LA INFORMACIÓN RELATIVA A LA CONTRATACIÓN GUÍA DE AYUDA AL USUARIO VERSIÓN 10
APLICACIÓN PARA LA RENDICIÓN TELEMÁTICA DE CUENTAS Y REMISIÓN DE LA INFORMACIÓN RELATIVA A LA CONTRATACIÓN GUÍA DE AYUDA AL USUARIO VERSIÓN 10 Pág. 2 de 19 ÍNDICE 1. INTRODUCCIÓN... 4 2. SOLICITUD DE ALTA
INFORME DE VULNERABILIDADES 2º SEMESTRE 2011
INFORME DE VULNERABILIDADES 2º SEMESTRE 2011 2º Semestre 2011 La presente publicación pertenece al Instituto Nacional de Tecnología de la Comunicación (INTECO) y esta bajo licencia Reconocimiento-No comercial
PREGUNTAS FRECUENTES. Junta Electoral Central. Elecciones a Rector/a 2013
PREGUNTAS FRECUENTES 1 1. Cuál es el período de votación? El voto electrónico comienza el 3 de junio a las 10h y finaliza el 13 de junio a las 15h. 2. Dónde se realiza el voto electrónico? En la web de
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
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
Requisitos técnicos para acceder a los servicios con certificado Versión Optimizada Windows
MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS Requisitos técnicos para acceder a los servicios con certificado Versión Optimizada Windows 1. Certificado digital... 1 2. Entorno Java... 1 3. Navegadores
La versión SonicOS Standard 3.9 es compatible con los siguientes dispositivos SonicWALL: SonicWALL TZ 180 SonicWALL TZ 180 Wireless
SonicOS Notas de la versión SonicOS Standard 3.9.0.1 para TZ 180/180W Índice Índice... 1 Compatibilidad de plataformas... 1 Cómo modificar el idioma de la interfaz gráfica de usuario... 2 Mejoras... 2
Sistema de Gestion de Locutorios SIGELOC Para acceso a Internet. Ministerio de Defensa
Sistema de Gestion de Locutorios SIGELOC Para acceso a Internet. Ministerio de Defensa DATOS GENERALES Antecedentes del servicio En el MINISDEF se han recibido solicitudes de diferentes Organismos solicitando
Parque Científico y Tecnológico de Cantabria Calle Isabel Torres, 7 39011 Santander Cantabria España Vicente Alciturri Gandarillas
Semicrol, S.L. Santander, a 2 de Julio de 2015 Razón Social: C.I.F.: Domicilio: Contacto: SEMICROL, S.L. B39024732 Parque Científico y Tecnológico de Cantabria Calle Isabel Torres, 7 39011 Santander Cantabria
Conferencia Web Empresas
Conferencia Web Empresas Requerimientos técnicos Mínimos PC y navegadores Windows: opera con Windows 2000, XP de 32 bits (SP3), 2003, Vista de 32 bits/64 bits/windows 7 de 32 bits/64 bits. Los requisitos
Administración General del Estado plataforma de verificación certificados europeo
Suite @firma 1 Origen Ley 11/2007 Art. 21.3: La Administración General del Estado dispondrá, al menos, de una plataforma de verificación del estado de revocación de todos los certificados admitidos en
Manual de configuración de navegadores para el uso de componentes Java
Manual de configuración de navegadores para el uso de componentes Java Índice de contenido Descargar e instalar Java...3 Notificaciones sobre Java desactivado y restauración de peticiones de datos...4
LOGO. Modulo 2. Carlos Villanueva
SSO5501 Hardening de un Sistema Operativo de Red LOGO Modulo 2 Carlos Villanueva Introduccion Hardering, del ingles Endurecimiento, se refiere al proceso de segurizar un Sistema o Aplicación Objetivos
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
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
PROCESO DE FIRMA CON DNI ELECTRÓNICO en http://eva.coaburgos.com
REQUISITOS TÉCNICOS PROCESO DE FIRMA CON DNI ELECTRÓNICO en http://eva.coaburgos.com CONTENIDO REQUISITOS... 1 CONFIGURACIÓN DE JAVA... 2 INSTALACIÓN PARA EL DNI ELECTRÓNICO... 3 ALTERNATIVA A FIRMA DESDE
MANUAL DE INSTALACIÓN DEL CLIENTE @FIRMA
Instituto Andaluz de Administración Pública CONSEJERÍA DE HACIENDA Y ADMINISTRACIÓN PÚBLICA MANUAL DE INSTALACIÓN Fecha: 13/12/2011 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción,
Manual de Usuario e Instalación McAfee Multi Access
Manual de Usuario e Instalación McAfee Multi Access Bienvenido a McAfee Multi Access! McAfee Multi Access es un servicio de seguridad que proporciona una protección completa hasta en cinco dispositivos
DESARROLLO WEB EN ENTORNO CLIENTE
DESARROLLO WEB EN ENTORNO CLIENTE CAPÍTULO 1: Selección de arquitecturas y herramientas de programación Juan Manuel Vara Mesa Marcos López Sanz David Granada Emanuel Irrazábal Jesús Javier Jiménez Hernández
OpenProdoc. ECM Open Source
OpenProdoc ECM Open Source Índice Visión General Arquitectura Funciones Seguridad Administración Requerimientos Evolución Visión General OpenProdoc es un gestor documental de código abierto. Cuenta con
Manual de uso de la sede electrónica del CIEMAT
Manual de uso de la sede electrónica del CIEMAT V1.0 Centro de Investigaciones Energéticas, Medioambientales y Tecnológicas Secretaría General Unidad de Programación y Modernización Julio 2014 Manual de
Instalación Componente Cliente
Instalación Componente Cliente Manual de usuario Referencia: Autor: Fecha de creación: 05/11/2014 Última actualización: 05/11/2014 Versión: 1.6 AST-EFIRMA- InstalacionComponenteCliente.doc Aragonesa de
Consejería de Hacienda y Administración Pública. Guía de uso del cliente
Sevilla, noviembre de 2010 Control de Versiones Hoja de control Fecha Autor Descripción 18/11/2010 RPV Adaptación guía de uso del cliente MPR Página 2 de 34 Contenido 1 Introducción... 5 2 Objetivos...
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
Servicio de Informática Vicerrectorado de Tecnologías de la Información y la Comunicación
Vicerrectorado de Tecnologías de la Información y la Comunicación Guía de Usuario Última Actualización 10 de febrero de 2015 Tabla de contenido 1.- Introducción... 3 2.- Novedades de Office 2013... 3 3.1.-
Office 365. para empresas y profesionales. María Pérez Marqués
Office 365 para empresas y profesionales María Pérez Marqués Office 365 para empresas y profesionales María Pérez Marqués ISBN: 978-84-940725-8-1 EAN: 9788494072581 BIC: UFBC Copyright 2013 RC Libros RC
Programación de red con Cisco Application Centric Infrastructure
Informe técnico Programación de red con Cisco Application Centric Infrastructure Descripción general En este documento se examina la compatibilidad de la programación de Cisco Application Centric Infrastructure
Módulo de firmas XML. Esta obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. Módulo de firmas XML
Módulo de firmas XML Esta obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. Módulo de firmas XML Página 1 de 66 Índice 1 Introducción... 3 2 Objetivos...
eboe: Boletín Oficial del Estado, edición electrónica. Ministerio de la Presidencia.
eboe: Boletín Oficial del Estado, edición electrónica. Ministerio de la Presidencia. DATOS GENERALES Antecedentes del servicio Las ediciones BOE y BORME en formato papel, así como el BOE en internet como
Abril 2011. WebApp STR- a3erp. Aplicación de registro de pedidos, albaranes y facturas para a3erp. Compatible con las principales plataformas
WebApp STR- a3erp Aplicación de registro de pedidos, albaranes y facturas para a3erp Alto ahorro de costes en empresas con representantes y/o técnicos móviles Compatible con las principales plataformas
MailStore Server 7 Especificaciones técnicas
MailStore Server 7 Especificaciones técnicas MailStore Server El estándar para el almacenamiento de correo electrónico Con MailStore Server, las empresas de todos los tamaños pueden aprovechar todas las
Lección 01. Introducción a los Lenguajes de Programación. Contenido. Conceptos Básicos. Lenguaje de Programación. Introducción al Lenguaje Maquina
Lección 01 Introducción a los Lenguajes de Programación Contenido Conceptos Básicos Lenguaje de Programación Introducción al Lenguaje Maquina Introducción al Lenguaje Ensamblador Introducción al Lenguaje
Desarrollo de Aplicaciones móviles para Android y IOS
Desarrollo de Aplicaciones móviles para Android y IOS Desarrollo de Aplicaciones móviles para Android y IOS Los cursos para desarrollar aplicaciones sólo para Android o sólo para ios son cosa del pasado.
Matriz de compatibilidad idad del cliente de firma de ficheros 3.1.0 de @firma v5 (Servicios de la Extensión JA)
idad del cliente de firma de Sevilla, noviembre de 2010 Control de Versiones Hoja de control Fecha Autor Descripción 09/11/2010 MIMR, RPV Compatibilidad cliente 3.1.0 final Página 2 de 22 Contenido 1 Alcance
OpenText Exceed ondemand
OpenText Exceed ondemand Acceso a aplicaciones empresariales confiable y seguro O pentext Exceed ondemand es la solución para el acceso seguro a las aplicaciones gestionadas. Ella permite que las empresas
Los distintos navegadores para movernos por Internet
www.solucionesenlaweb.com Los distintos navegadores para movernos por Internet Para que los usuarios puedan navegar por Internet y ver la información que más les interesa en cada momento, utilizamos los
Notas de la versión del servidor
Dell KACE K1000 Aparato de administración de sistemas Versión 5.5 Notas de la versión del servidor Acerca de estas notas de la versión Las presentes notas de la versión proporcionan información acerca
e-fácil: Factura Electrónica / CIRCE Local Ministerio de Industria, Turismo y Comercio DATOS GENERALES Antecedentes del servicio
e-fácil: Factura Electrónica / CIRCE Local Ministerio de Industria, Turismo y Comercio DATOS GENERALES Antecedentes del servicio El proyecto e-fácil tiene como objetivo proponer desde el Ministerio de
CONSEJERÍA DE EDUCACIÓN
ISE Andalucía Ente Público Andaluz de Infraestructuras y Servicios Educativos CONSEJERÍA DE EDUCACIÓN Manual de ayuda para firma digital AAEE Fecha de Última Actualización: 07/10/2011 9:04:00 Versión: