Archivo de la categoría: Firma digital

Gartner Hype Cycle en el mundo de la Firma Electrónica

1 respuesta

El sector ABC (Administración, Banca y Comercio, vistos como un solo grupo) es el gran impulsor de las tecnologías de relación virtual con valor probatorio, lo que da lugar primero al desarrollo de las tecnologías criptográficas de cifrado y firma electrónica y después a los conceptos de evidencias electrónicas, documento electrónico y custodia digital.

Intentando caracterizar el mercado, que es nuevo en algunos aspectos, he intentado situar algunos avances de los últimos años en el conocido modelo «Gartner Hype Cycle«.

En este caso mi interés radica en realizar un verdadero estudio de mercado, que no me suena que exista, en relación con la Diplomática Digital y los componentes necesarios para su desarrollo.

Una de mis sorpresas ha sido detectar el desequilibrio que se produce entre Europa (especialmente los paises del centro y sur) y Norteamérica (acompañada en esto, en cierta medida, por los paises del norte de Europa y el Reino Unido). Es decir, el punto en el que una tecnología es

tá en el «Hype Cycle» es diferente si consideramos, Europa, América y Asia, y es sorprendente que la gobalización no haya uniformizado las tendencias.

También sorprende la aparente novedad del concepto de «Diplomática Digital«, cuando la Diplomática clásica es una ciencia bien asentada (fundada en el siglo XVII por Jean Mabillon) y de carácter prácticamente universal, desarrollada en los principales idiomas:

En mi estudio, uno de los esfuerzos principales está consistiendo en caracterizar el documento electrónico y sus  propiedades, comparándolas y diferenciándolas de las del documento en papel. Una de las primeras conclusiones es que desaparece el concepto de «original» y características tales como la veracidad, la autenticidad, o la unicidad se han de desvincular del soporte, lo que no es tarea fácil. Aparecen tres conceptos claves (que se dan tanto en documentos en papel como en documentos electrónicos, pero en base a diferentes principios) como son la obliterabilidad, la endosabilidad y la completitud.

Las herramientas que permiten gestionar documentos electrónicos de carácter probatorio suponen todo un nuevo mercado que en general los analistas de diferentes consultoras no han sabido entender como coherente. Es cierto que elementos como la firma electrónica o la custodia digital aparecen a veces en los estudios, pero sin atender a su vinculación esencial en esta «nueva» rama de la diplomática.

Jornadas de Firma Electrónica de CatCert

Deja un comentario

Ya es tradicional el evento que todos los años organiza CatCert en torno a la Firma Electrónica.

Las VII Jornadas tienen lugar este año el 27 y 28 de octubre de 2010. Albalia está presente como entidad asesora en una de las innovaciones que CatCert introduce este año.

La actual edición de las Jornadas se estructura alrededor de actividades de diversa índole más allá de las clásicas conferencias: encontraran mesas redondas, casos, buenas prácticas, soluciones empresariales, asesoramiento de expertos, etc. donde el networking y el intercambio de experiencias, así como el enfoque multidisciplinar serán el leit motiv de las mismas.

El jueves 28, Albalia participa en las sesiones de asesoramiento, a través de Santi Casas

Más información.

Formación sobre el ENI y el ENS en Atenea Interactiva

Deja un comentario

El día 4 de Noviembre de 2010, Atenea Interactiva organiza en Madrid un seminario sobre el Esquema Nacional de Seguridad y el Esquema Nacional de Interoperabilidad, cubriendo las siguientes áreas de conocimiento:
  • Ley 11/2007 LAECSP.
  • Administración Electrónica.
  • Esquema Nacional de Interoperabilidad (ENI).
  • Esquema Nacional de Seguridad (ENS).
  • Similitudes con la certificación ISO 27001.
  • Planes de Adecuación.
Programa

1. Marco de referencia de los Esquemas Nacionales de Seguridad e Interoperabilidad

  • Ley 11/2007.
2. Entorno conceptual de la Administración Electrónica
  • Documento Electrónico.
  • Expediente Electrónico.
  • Procesos de relación con los ciudadanos (registro electrónico y notificaciones electrónicas).
3. Aspectos tecnológicos de la Administración Electrónica
  • La Firma Electrónica.
  • La custodia digital.
4. Esquema Nacional de Interoperabilidad
  • Interoperabilidad organizativa, semántica y técnica.
  • Infraestructura y servicios comunes.
  • Reutilización y transferencia de tecnología.
  • Firma electrónica y certificados.
  • Recuperación y conservación del documento electrónico.
  • Desarrollo del ENI.
5. Puntos clave del Plan de Adecuación al ENI
6. Esquemas Nacionales de Seguridad (ENS)
  • Principios básicos de ENI.
  • Requisitos mínimos de seguridad.
  • Comunicaciones electrónicas.
  • Auditoría de seguridad.
  • Respuesta ante incidentes.
  • Normas de Conformidad.
  • Categorización del sistema de información.
7. Similitudes entre el ENS y la certificación ISO 27001
8. Puntos clave del Plan de Adecuación al ENS.

8000 descargas de FactOffice

Deja un comentario

Aunque es una cifra que palidece frente a las descargas de software o contenidos relacionados con el ocio, estamos orgullosos de esta cifra por lo que significa.

En bastantes ocasiones, el software de fuentes abiertas se descarga porque es gratis (aunque no tenga por qué serlo) y raramente por la libertad que se deriva de la disponibilidad del código fuente.

Yo creo que en el caso de FactOffice es al contrario. Me consta que muchas empresas desarrolladoras se lo descargan precisamente porque es una de las pocas implementaciones en entornos de ejecución de Windows  de tecnologías relacionadas con la firma electrónica y la factura electrónica. Y se aprovechan de la libertad que otorga la licencia MSPL para incorporar parte de nuestro código a sus aplicaciones.

Para nosotros es un motivo de orgullo contribuir al desarrolllo de la factura electrónica y de la firma electrónica en España.

Aunque a lo largo de 2010 hemos dedicado un gran esfuerzo a OffInvoice, la versión más internacional de nuestro ribbon de facturación electrónica, en estos momentos estamos preparando una nueva versión de FactOffice que aporta algunos aspectos que nos han solicitado con frecuencia y resuelve algunas incidencias menores de la versión anterior.

Para elegir la versión más apropiada, puede estar bien conocer algunas de las diferencias entre ambos productos:

  • FactOffice: Funciona sobre Word 2007. Soporta el formato facturae. Está disponible en español, inglés y catalán. Utiliza una licencia especial de BackTrust para realizar la firma electrónica. Permite firmas XAdES-XL (TS 101 903)
  • OffInvoice: Funciona sobre Word 2010 y Excel 2010. Soporta los formatos facturae, UBL y CII. Está disponible en español, inglés y catalán (y próximamente en todos los idiomas de la Unión Europea). Utiliza una licencia especial de BackTrust para realizar la firma electrónica. Permite firmas XAdES-XL (TS 101 903)

Animamos a los lectores de este blog a que nos den sus opiniones sobre estos programas y nos aporten sugerencias sobre aquellos aspectos que les gustaría que mejoráramos. Y a que lo difundan en sus entornos para mejorar las estadísticas de uso de la factura electrónica en España.

Diseño y planificación de una infraestructura de clave pública (PKI)

3 respuestas

Albalia Interactiva, empresa especializada en firma electrónica, factura electrónica, banca electrónica y administración electrónica, en colaboración con IBM,  ofrece el servicio de Diseño y planificación de una infraestructura de claves públicas (PKI)

Una infraestructura de claves públicas (PKI) bien planificada y construida permite afrontar los requisitos estrictos de autenticación, cifrado y firma digital que se espera de las actuales aplicaciones de e-business.

Destacamos

Los servicios de diseño y planificación de la infraestructura de claves públicas de IBM preparan la estructura necesaria para cumplir con los objetivos de su empresa y mejorar la seguridad de sus iniciativas de e-business.

Gracias al aprovechamiento de las metodologías probadas y del capital intelectual, los asesores y arquitectos de IBM le permiten comprender cómo debe aplicarse la infraestructura de claves públicas (PKI) a su entorno empresarial, desarrollar la solución y preparar el despliegue de la tecnología PKI en su empresa.

El servicio incluye:

El siguiente conjunto de actividades conforma las fases de planificación y diseño de la infraestructura completa de servicios de PKI probados y se ofrece de forma individual o en paquetes, según sus necesidades:

  • La estrategia de la infraestructura de claves públicas (PKI) examina el entorno y la estrategia de su empresa y construye los fundamentos para tomar en consideración una infraestructura de claves públicas.
  • El asesoramiento de preparación de la PKI determina el modo en el que la creación de una infraestructura de claves públicas incidirá en la empresa y recomienda los pasos a seguir para su preparación.
  • El valor de la PKI describe las ventajas y la justificación empresarial de una infraestructura de claves públicas.
  • Los requisitos de la PKI definen los requisitos empresariales, tecnológicos y del proceso de seguridad que responden a las necesidades de su empresa.
  • La política de PKI define las políticas operativas, de procedimiento y de seguridad que regularán la infraestructura de claves públicas.
  • La arquitectura conceptual identifica la estructura de la PKI, el modelo de seguridad y los principios del diseño.
  • La arquitectura funcional se basa en la arquitectura conceptual de la infraestructura de claves públicas y define sus funciones requeridas y las relaciones entre dichas funciones.
  • La selección de productos de PKI proporciona un análisis de los requisitos de su infraestructura de claves públicas y de la arquitectura conceptual de la misma, en comparación con las soluciones del sector para que pueda escoger la tecnología que mejor se ajusta a sus necesidades.
  • La selección del sitio y el diseño de la infraestructura le permiten evaluar las posibles ubicaciones y ofrece recomendaciones para el diseño y el despliegue del recurso.
  • La arquitectura de los componentes se basa en la arquitectura funcional de la infraestructura de claves públicas y define las tecnologías, los estándares, las interfaces y los productos seleccionados que cumplan con los requisitos, la estrategia y la política de la infraestructura de claves públicas de su empresa.
  • El desarrollo de procesos describe los procesos necesarios para dar soporte a la infraestructura de claves públicas, incluidos el registro, la revocación, el mantenimiento de registros y la generación de claves de la entidad emisora de certificados.
  • Las prácticas de certificación de la PKI destacan los componentes técnicos de los documentos de la política de infraestructura de claves públicas más importantes, la declaración de práctica de certificación y las políticas de certificación.
  • El plan de implementación incluye los pasos, los conocimientos y los recursos necesarios para implementar la infraestructura de claves públicas.

Una vez definidos los planes, el siguiente paso es integrar e implementar su solución de PKI mediante nuestros servicios personalizados, que están disponibles previa petición.

En los entornos corporativos, que disponen de Mainframe, con z/OS, parte de los recursos hardware y software necesarios están ya disponibles, por lo que la estrategia de gestión de PKI es una alternativa económica o otros sistemas de gestión de certificados.

IBM ha publicado los documentos que explican la forma de desplegar su PKI en organizaciones con sistemas z/OS:

Otros artículos relacionados:

    Período de gracia en las firmas XAdES-XL

    5 respuestas

    Debido al estado de desarrollo de los PSC cuando se redactaron algunas normas de firma electrónica, se tuvo en consideración el llamado «periodo de gracia para comprobación del estado de revocación de un certificado».

    En alguna de aquellas normas  se recomendaba tener en cuenta la existencia de un periodo de tiempo de espera, conocido como periodo de precaución o periodo de gracia, para comprobar el estado de revocación de un certificado. Por ello, toda la información de revocación en formatos AdES se recomendaba incluirla después de trascurrido el periodo de precaución o periodo de gracia desde la obtención del sellado de tiempo. Este periodo como mínimo debía ser el tiempo máximo permitido para el refresco completo de las CRLs o el tiempo máximo de actualización del estado del certificado en el servicio OCSP. Estos tiempos podrán ser variables según la Declaración de Prácticas de Certificación del Prestador de Servicios de Certificación.

    En la actualidad, está precaución no tiene sentido, especialmente cuando las firmas XAdES-XL se generan del lado del firmante y es este el que inlcuye los datos de timestamping y de validación basada en OCSP (y por tanto conoce si su certificado está revocado o no).

    Efectivamente, en la actualidad, la información sobre revocación de certificados que ofrecen los prestadores de servicios de certificación sobre OCSP incluyen de forma inmediata cualquier información de revocación que se produzca, en tiempo real.

    Sólo hay que tomar precauciones cuando se utilice como mecanismo de comprobación de la revocación el acceso a las listas CRL (un mecanismo obsoleto que solo se usa en algunos contextos) o cuando se utilice un servicio de validación que, aun siendo soportado por el protocolo OCSP, se basa en la consulta de CRLs para su funcionamiento.

    En España, los únicos certificados que podrían requerir el mantenimiento del período de gracia son los de FNMT-RCM, ya que en muchos casos siguen distribuyendo CRLs. Igualmente, cuando se utilice @firma como plataforma de validación, conviene cerciorarse que el servicio no esté basado en consulta de CRLs.

    EADTrust – European Agency of Digital Trust

    3 respuestas

    Logo EAD Trust As I mentioned in other articles, one of the companies with which I am working is EADTrust, European Agency of Digital Trust, a CSP (Certification Service Provider) that provides services related to electronic signatures in the framework of Law 59/2003 (or Directive 1999/93/CE) with a philosophy we intend to be innovative:

    • It is not planned to issue individual certificates to natural persons (we might consider issuing certificates to natural persons linked to groups as part of a project).
    • It provides services to manage trust of the Information Society, particularly by encouraging the creation of high quality electronic signatures with timestamping services, validation of digital certificates and electronic document custody.
    • It provides advanced services, some specifically designed for public administrations in the framework of eGovernment Law 11/2007: certified publication in the contractor’s profile, certified service of notice, electronic invoicing or generation and verification of electronic signatures through the OASIS DSS protocol (the Ministry of Presidence announced that the evolution of the official @firma platform will evolve to implement this protocol).
    • It manages two root CAs linked together, combining RSA cryptography and ECC (Elliptic curve cryptography).

    The latter is a significant milestone, since this way EADTrust becomes the first certification authority in the world with dual technology, and possibly the first European Certification Authority that manages a PKI hierarchy based on elliptic curve cryptography.

    The root CAs of both of the certificate hierarchies are as follows:

    • RSA (sha1RSA). RSA 2048-bit key size
    • ECC (sha1ECDSA). ECC key sizes: 256 bits (equivalent to 3020 bit RSA)

    Both root CA certificates and keys were generated in the presence of a notary, a procedure that we have been refining on several CA (Certification Authority) key generation ceremonies to other certification providers with whom we have collaborated: FESTE, Camerfirma, Banesto and ANCERT.

    The certification authority based on Elliptic Curve algorithm, uses random 256 BITS ECDSAFp (secp256r1), as indicated in the documents generated by the NIST (National Institute of Standards and Technology) FIPS (Federal Information Processing Standards) 186 -2 and FIPS 186-3 in Appendices 6 and D respectively in their sections on the Recommended Elliptic Curves for Federal Government use (United States).

    This algorithm is also described in document ETSI TS 102 176-1 V2.0.0 (2007-11) «Technical Specification. Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms».

    Other references:

    • RFC 4051 «Additional XML Security Uniform Resource Identifiers (URIs)»
    • RFC 4492 «Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)»
    • ISO/IEC 15946 «Information technology — Security techniques — Cryptographic techniques based on elliptic curves»
    • ANSI X9.62:2005 «Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)»

    Obtener certificados de CERES – FNMT

    7 respuestas

    Aunque muchos usuarios de firma electrónica ya saben que la solicitud y obtención de certificados de CERES es algo más sencilla con el navegador Mozilla Firefox que con Internet Explorer 8 (especialmente en sistemas operativos Windows Vista y Windows 7),  teniendo en cuenta unas sencillas indicaciones (que el propio servicio CERES de la FNMT remite a los usuarios que experimentan algún problema y solicitan ayuda a través de los números 902181696 / 913463892 / 917040191) es posible gestionarlos adecuadamente en estos entornos.

    Las indicaciones se recogen seguidamente y hay que seguirlas antes de solicitar el certificado.

    El problema, que no es específico de la FNMT, sino que afecta a todos los PSC que incluyan un mecanismo parecido de «enrollment»,  aparece como consecuencia de que el  control de solicitud de certificados (CertEnroll) no funciona con Internet Explorer 8 en equipos que ejecutan Windows 7 cuando se incluye en un elemento FRAME o IFRAME en la página web, que es el caso de la página de la FNMT. Se explica en el blog de desarrolladores MSDN de Microsoft:  CertEnroll control won’t work when hosted inside a frame/iframe in IE8

    La forma de resolverlo para los usuarios es descargar e instalar el hotfix 322891 relacionado con el artículo KB 2078942 de la Microsoft Knowledge Base o que la entidad de certificación prepare las páginas teniendo en cuenta ciertas recomendaciones (como se indica en el citado blog).

    Al descargarse el parche, es preciso elegir el paquete adecuado para instalar. Las opciones son:

    • Windows 7/WindowsServer 2008 R2 (x86) – Para Windows 7 de 32 bits
    • Windows 7/WindowsServer 2008 R2 (x64) – Para Windows 7 de 64 bits
    • Windows 7/WindowsServer 2008 R2 (ia64) – Para Arquitectura Intel (Intel Itanium) de 64 bits

    En el proceso hay que introducir una dirección de correo electrónico a la que se enviará un email con el enlace para descargar el paquete. En dicho correo también se le enviará la contraseña para poder instalar el paquete.

    Después de instalar el hotfix hay que configurar el navegador (Internet Explorer) accediendo a la sección de opciones de menú siguientes: Herramientas/Opciones de Internet/Seguridad.

    • Pulsar en «Sitios de Confianza».
    • En el control de nivel de la izquierda, desplazar hacia abajo hasta seleccionar nivel «bajo». Si no aparece control de nivel hay que pulsar el botón «nivel predeterminado«
    • Pulsar en el botón «Sitios«.
    • Abajo, desmarcar la opción de «Requerir comprobación del servidor (https://) para todos los sitios de la zona»
    • En el cuadro de texto «Agregar este sitio Web a la zona»: hay que agregar las siguientes URLs http://*.fnmt.es y https://*.fnmt.es
    • Cerrar la ventana.
    • En el icono «Sitios de Confianza» pulsar botón Nivel personalizado y reducir los niveles de seguridad habilitando las siguientes opciones de configuración:
    1. Comportamiento de binarios y scripts
    2. Descargar los controles ActiveX firmados.
    3. Descargar los controles ActiveX sin firmar.
    4. Ejecutar controles y complementos de ActiveX.
    5. Generar scripts de los controles ActiveX marcados como seguros para scripting.
    6. Inicializar y generar scripts de los controles ActiveX no marcados como seguros para scripts.
    7. Permitir que todos los controles activeX no usados anteriormente se ejecuten sin preguntar.
    8. Permitir scriptlets.
    9. Preguntar automáticamente si se debe usar un control activeX
    • Pulsar en Aceptar, tras el que aparecerá un mensaje para confirmar que se deberá aceptar.
    • Aplicar y aceptar la última ventana.
    • Cerrar el navegador para que se apliquen los cambios.

    Una vez instalado el parche y ajustados los parámetros es posible solicitar el certificado. Después de realizar la solicitud (y la instalación del certificado tras acudir a una de las entidades de registro), se puede volver a reestablecer las opciones de seguridad a un nivel más alto.

    Hay más información en el sitio web de Microsoft.

    Una alternativa para no usar la extensión de «Certificate enrollment» que suele ser fuente de problemas desde hace muchos años, en Albalia recomendamos a los PSC que generen directamente el fichero PKCS#12 con las claves y los certificados, de modo que el propio fichero ya es un respaldo (backup) para que los usuarios lo puedan guardar en un lugar seguro y además para que lo puedan importar con facilidad en diferentes navegadores.

    Un ejemplo es la propia CA de pruebas que Albalia ha desarrollado y a la que ya he hecho mención en alguna ocasión. Los certificados de prueba generados por esta CA no tienen valor legal pero son muy útiles para experimentar.

    EADTrust – European Agency of Digital Trust

    1 respuesta

    Como ya he mencionado en otros artículos, una de las empresas en las que colaboro es EADTrust, European Agency of Digital Trust, un Prestador de Servicios de Certificación que presta servicios relacionados con la firma electrónica en el marco de la Ley 59/2003 con una filosofía que intentamos que sea novedosa:

    • No está prevista la emisión de certificados individuales a personas físicas (podría considerarse la emisión de certificados a personas vinculadas a colectivos, en el marco de un proyecto).
    • Se prevé que gestione servicios de confianza de la Sociedad de la Información, especialmente favoreciendo la creación de firmas electrónicas de alta calidad con servicios de timestamping, validación de certificados y custodia digital de documentos electrónicos
    • Proporciona servicios avanzados, algunos especialmente diseñados para administraciones públicas en el marco de la Ley 11/2007: publicación fehaciente en el perfil del contratante, notificación fehaciente, facturación electrónica o generación y verificación de firmas electrónicas mediante protocolo DSS de OASIS (el Ministerio de Presidenca ha anunciado que la evolución de la plataforma @firma se orientará a la implementación de este protocolo).
    • Dispone de CAs root vinculadas que combinan criptografía RSA y criptografía ECC (Elliptic curve cryptography)

    Este último es un hito significativo, al ser la primera autoridad de certificación del mundo con tecnología dual, y, posiblemente, la primera autoridad de certificación europea que cuenta con una jerarquía PKI basada en curvas elípticas.

    Los certitificados raiz de la jerarquía dual son estos:

    • RSA (sha1RSA). Tamaño clave RSA 2048 bits
    • ECC (sha1ECDSA). Tamaño clave ECC: 256 bits (equivalente a 3020 bits en RSA)

    Ambas root se generaron en presencia notarial, siguiendo un procedimiento que hemos ido perfeccionando en sucesivas ceremonias de  generación de claves de CA (Certification Authority) en otros prestadores con los que hemos colaborado: FESTE, Camerfirma, Banesto y ANCERT.

    La autoridad de certificación basada en algoritmo de Curva Elíptica utiliza, en particular,  ECDSAFp de 256 BITS aleatorios (secp256r1), según se indica en los documentos generados por el NIST (National Institute of Standards and Technology) FIPS (Federal Information Processing Standards) 186-2 y FIPS 186-3 en sus apéndices 6 y D respectivamente en sus secciones referentes a las Curvas Elípticas Recomendadas para uso del Gobierno Federal (Estados Unidos).

    Colisiones en las firmas en PDF

    1 respuesta

    Florian Zumbiehl reporta un problema en las firmas PDF que permitiría forzar colisiones de funciones resumen (hash) de documentos de forma que la firma electrónica de uno de ellos podria ser utilizada para aparentar que el firmado es el otro.

    Según su descripción es una vulnerabilidad que radica en la propia especificación del formato PDF por lo que no depende de la implementación, y por tanto no cabe atribuirlo a un producto en particular.

    En mi opinión, el tipo de ataque documentado no supone un problema real para los documentos PDF ya firmados, más allá de los aspectos probabilísticos  de las colisiones, consustanciales a las funciones resumen.

    Es decir, siempre que obtengamos colisiones de documentos «a priori» estas colisiones podrán ser utilizadas para «suplantar» los documentos que colisionan, utilizando la firma de uno para dar la apariencia de firma al otro.

    En este caso particular la concatenación de documentos, siendo uno de ellos firmado, podría dar lugar a que se considerara válida una firma sin serlo, ya que solo aplicaría a uno de los documentos y no al otro.

    La solución general es utilizar funciones resumen diferentes en sistemas de firma dual o múltiple, tal y como hacemos en el proyecto Binum, que ya mencioné en este blog o tal como es posible llevar a cabo con certificados emitidos en la jerarquía de certificación dual de EADTrust.

    Y, por supuesto, también merece la pena adoptar la solución propuesta por Florian, que consiste en afinar un poco más la especificación de la firma en PDF para que se reforzaran los controles que identifican lo que va firmado dentro del PDF.