Archivo de la categoría: TS 101 903

El Time Stamping y el cambio de hora


Esta pasada noche ha cambiado la hora oficial, de modo que hemos atrasado nuestros relojes para marcar una hora menos, y este fin de semana es una hora más largo.

¿Cómo se refleja la hora en los fechadores de tiempo utilizados en firma electrónica?

No es difícil. El indicador horario tiene la posibilidad de reflejar 2 campos: hora oficial y hora UTC (Tiempo Univeral Coordinado), o sólo este último dato, para lo que el sistema que lo use deberá prever el momento del cambio horario. Aunque la hora oficial cambie entre los horarios de verano y de invierno, el tiempo UTC es prácticamente continuo (salvo los segundo intercalares de junio y diciembre) . Por otro lado, al no coincidir el cambio horario con horas en las que tengan lugar eventos significativos o transiciones temporales de referencia (como las de medianoche o mediodía, o inicio o fin de cotización bursátil) el impacto es muy pequeño.

Recordemos que en la España peninsular la hora oficial es UTC+1 en invierno (CET ó Central European Time) u UTC+2 en verano (CEST ó Central European Summer Time) y en Canarias es UTC, en invierno y UTC+1 en verano (WET ó Western European Time).

Recordemos también que en España la Fuente Oficial de Tiempo es el ROA (Real Observatorio de la Armada, o por su nombre completo Real Instituto y Observatorio de la Armada en San Fernando) que dispone de un servicio para conocer la hora via web.

SDK de Firma Electrónica


Ahora que el DNI electrónico está provocando el que muchas administraciones y empresas privadas se planteen el desarrollo de servicios en los que sea posible la identificación y la firma electrónica con el DNI (o con cualquier otro certificado reconocido), y que por otro lado muchas empresas estén desarrollando proyectos de Factura Electrónica y Digitalización Certificada se plantea frecuentemente la consulta de qué recusros técnicos hay para ello.

En el mundo del software libre y entre las herramientas de desarrollo de Microsoft y de Java existen ya librerías que resuelven muchos de los pasos necesarios.

También en nuestra empresa hemos recopilado y desarrollado un conjunto de herramientas de desarrollo de software (SDK, Software Development Kit) que permiten acometer proyectos de firma y validación electrónicas.

  • Manejo de los estándares RFC 3126 y sus variantes TS 101 733 (CAdES) y TS 101 903 (XAdES) para firma respectivamente en CMS (PKCS#7) y XML (XML DSig – XML DSign), con la armonización propuesta en TR 102 047 (International Harmonization of Electronic Signature Formats)
  • Soporte de estándares
    • RFC 3280 – Certificate and Certificate Revocation List (CRL) Profile,
    • RFC 3275 – (Extensible Markup Language) XML-Signature Syntax and Processing ,
    • RFC 2797 – Certificate Management Messages over CMS,
    • RFC 2585 – Operational Protocols: FTP and HTTP,
    • RFC 3161 – Time-Stamp Protocol (TSP),
    • RFC 3029 – Data Validation and Certification Server Protocols,
    • RFC 3852 – Cryptographic Message Syntax (deja obsoletos los RFC3369, RFC 3211, RFC 2630, RFC 2315-PKCS #7 version 1.5-)
    • RFC 4853 (Actualización Marzo 2008) Cryptographic Message Syntax – Multiple Signer Clarification
  • Hash según FIPS PUB 180-1 (Secure Hash Standard).
  • Consultas OCSP sobre la validez de los certificados utilizados (RFC 2560)
  • Inserción de sello de tiempo (TS 101 861)
  • Generación y Firma de PDF a partir de ficheros gráficos
  • Firmas automatizadas (Portafolio de Firmas) en PDF hasta 100 firmas por segundo (más de 300.000 firmas por hora)

Estas herramientas las completamos con servicios de Validación y Sello de Tiempo altamente competitivos.

La idea es resolver no sólo la problemática de la firma sino también la de la validación, que es bastante más compleja.

Con tantas siglas y referencias a normas es difícil aclararse. Las normas sobre infraestructura de clave púbkica (PKI) del IETF están recogidas en la página del Grupo PKIX.

(Actualización Marzo 2008) El SDK de Firma Electrónica de  Albalia Interactiva, ahora se incluye como parte de la Suite de Productos Backtrust

Comentarios a la Ley de Administración Electrónica


Recientemente y hasta el 30 de septiembre de 2006 el Ministerio de Administraciones Públicas ha abierto un par de Foros para recoger opiniones de temas que debería ser cubiertos en esta Ley. El primer foro es el de Administración Electrónica y el segundo el de Firma Electrónica.

He enviado algunos comentarios que edito para ampliarlos aquí.

Firma de órgano administrativo como asimilada de la de persona jurídica 

Por la normativa de Potestades, la firma del órgano se deriva de la firma de quien tiene atribuciones para representarlo. No traslademos a la Administración Pública lo que es un error flagrante de la Ley 59/2003 de Firma Electrónica: la atribución de la «capacidad» de firmar a las Personas Jurídicas. Las Personas Jurídicas no tienen firma, lo tienen sus representantes. Otra cosa sería que se publicara una «Ley del Sello Electrónico» que atributa ciertos efectos (pero no los de equivalencia funcional con la firma manuscrita, obviamente)al uso de la criptografía de clave pública de forma automatizada, o con un control laxo de la identidad de quien activa esta modalidad de «firma», tal y como sucede en la actualidad con los sellos de caucho.

Firma electrónica con diferentes sistemas operativos y navegadores 

Tanto Safari para Mac como Konqueror para KDE tienen soporte para la gestión de certificados, al menos en la variante de «Client Certificate» de SSL 2.0. Al igual que Firefox y todas las variantes de Mozilla, al igual que IE y Opera. En todos los casos se pueden instalar los ficheros PKCS#12 que generan varios Prestadores de Servicios de Certificación. En mi opinión, el PSC (de entre los que emiten «Certificados Cualificados») que lo hace más sencillo para los usuarios es Camerfirma. También se pueden hacer «pruebas» con certificados gratuitos en Mac, Linux o Windows con los disponibles en este sitio de Certificados de Prueba. No obstante, para obtener un certificado cualificado (el que otorga valor de firma manuscrita a la electrónica) se debe pasar por un procedimiento que obligatoriamente supone verificación presencial de identidad.

Tractis, modelo de buenas prácticas en Firma Electrónica


Acabo de publicar mi primer POST como blogger invitado en el Blog de Negonation, como preparación del próximo lanzamiento de Tractis.

La verdad es que estoy muy orgulloso del pequeño pero importante papel de Albalia en el proyecto.,

Las frecuentes críticas a determinadas implementaciones de firma electrónica (o recomendaciones de otras) que hago en este blog han sido tenidas en cuenta en el proyecto de Tractis.  Mi visión sobre la obligatoriedad de reconocer cualquier certificado reconocido, ha sido tenida en cuenta en el proyecto de Tractis. La importancia de generar evidencias electrónicas con indicación de tiempo y validación, ha sido tenida en cuenta en el proyecto de Tractis.

La transparencia en el esfuerzo de desarrollo, elementos de visión y de implementación, y el conocimiento de las personas que están detrás del proyecto, me hacen abrigar grandes expectativas respecto a su éxito. Cuando eso suceda podré decir: «yo estuve allí, preparando el lanzamiento«.

Digitalización Certificada


En el borrador de la normativa que la AEAT está preparando para aclarar conceptos relativos a la Facturación Telemática, aparece un concepto nuevo que tiene cierto parecido con la Compulsa Electrónica.

Cabe la posibilidad de digitalizar facturas en papel y otros documentos de interés tributario, siempre que los dispositivos que permiten la digitalización incluyan en el proceso una firma electrónica avanzada.

Tanto los fabricantes de estos aparatos como las empresas que los usan, deben auditar respectivamente su funcionamiento y la metodología de digitalización.

Nuestra empresa está ya ofreciendo servicios de auditoría de lo que posiblemente se denominará «digitalización certificada» para empresas desarrolladoras de software de digitalización, de forma que se puedan cumplir los requisitos de la norma, una vez que se publique en el BOE.

El algoritmo de hash del DNI electrónico


Estos días he leido muchas tonterías (a mí me lo parecen) sobre si el SHA-1 es malo y lo único bueno es el SHA-256 y sobre lo que esto implica en el nuevo DNI electrónico.

Lo cierto es que desde hace unos pocos años, algunas personas afirman de oidas que se ha roto el MD-5 o el SHA-1.

Lo que ha sucedido es que se ha demostrado que la probabilidad de encontrar dos documentos distintos con el mismo hash, siendo muy pequeña, es menos pequeña de lo que se sospechaba cuando se diseñó el algoritmo.

Con esto en mente, podemos afirmar que no es cierto que unos algoritmos de hash sean buenos y otros malos, así sin más.

En todo caso, no hay algoritmos buenos, sino más o menos vulnerables a determinados tipos de ataque.

Y, desde luego, la mejor opción es utilizar 2 algoritmos de hash simultáneamente.

Lo que esto quiere decir es que si, sumando casualidades, somos capaces de generar un documento que tiene una información que nos interesa y con el que queremos sustituir a otro para el que se ha calculado el Hash, habremos conseguido que el hash firmado para el documento sustituido ampare al documento con el que lo sustituimos.

En general, en documentos estructurados esto es imposible incluso con mecanismos de hash "·malos" porque es importante preservar la legibilidad y consistencia del documento. No es lo mismo con ficheros gráficos o con ficheros que tengan áras de "pad" (de manipulación) porque es posible manipular esas áreas o los bits menos significativos del gráfico hasta que el fichero entre por el aro (lo que tampoco es nada fácil).

De todas formas, cuando existen dos algoritmos de hash simultáneos, lo que podamos hacer para "arreglar" el fichero de cara a un Hash, nos lo "descojona" de cara al otro.

En definitiva, el certificado incluido en el DNI electrónico es lo suficientemente seguro ya que el hash generado con SHA-1 implica que no es posible generar otro certificado con el mismo aspecto y cambiando algunos datos según nos interese. Pero ya es la releche al volver a firmar por la CA el SHA-256 del mismo contenido. Aunque no podamos utilizarlo ni con Internet Explorer, ni con Opera, ni con Firefox. Es, desde luego, INFALSIFICABLE.

Otro aspecto distinto es la manera en la que firmemos nosotros nuestros documentos con el DNI electrónico. Ahí sí que podemos hacer lo que queramos. Por ejemplo, desarrollar por nuestra cuenta un programa de software que utilice formatos no estándar al cifrar y al descifrar (firmar y comprobar la firma), y que emplee MD-4, MD-5, SHA-1 y SHA-256 simultánemaente.

A ver si vamos a ser muy paranóicos con las gilipoyeces y luego no comprobamos si el certificado está revocado o no.

TS 101 903 XAdES


El estándar TS 101 903 de codificación de firmas electrónicas cualificadas en XML (XAdES) va por su versión 1.3.2 y está referenciado en el ETSI. Existe, incluso, un informe en relación con los esfuerzos de interoperabilidad que han llevado a cabo los desarrolladores de soluciones de firma electrónica (ya ha habido tests de interoperabilidad en ETSI en el 2003 y en el 2004).

Actualización (abril 2009) Albalia ha participado en los test de interoperabilidad de 2008 (2 de XAdES ) y de 2009  (1 de CAdES -TS 101 733- y XAdES)

Poco a poco se va extendiendo, aunque de forma más lenta de lo esperado. Yo, particularmente, me siento un poco apóstol de su adopción ya que procuro mencionarlo en todas mis conferencias relacionadas con la Firma Electrónica y la Factura Electrónica.

De hecho, creo que la actual mención del formato recomendado de la firma electrónica en la propuesta de formato de factura electrónica desarrollada por el Comité de Cooperación Interbancaria (CCI) puede tener algo que ver con unas recomendaciones mías en el proceso de comentarios abierto por la Agencia Tributaria.

Por cierto, se ha creado un grupo de discusión sobre este formato en Yahoo Groups: Discusión-eFactura-AEAT-CCI.

Estos días estoy viendo con satisfacción que el formato se va adoptando oficialmente en las administraciones públicas españolas. He hecho un pequeño estudio de la normativa española que menciona este estándar, que me gustaría completar con las aportaciones de quienes leen esta bitácora.

Por el momento, las normas que mencionan la norma TS 101 903 son las siguientes:

  • REAL DECRETO 686/2005, de 10 de junio, por el que se modifica el Real Decreto 2188/1995, de 28 de diciembre, por el que se desarrolla el régimen de control interno ejercido por la Intervención General de la Administración del Estado. (BOE 25.06.2005)
  • Resolución de 28 de noviembre de 2005, de la Intervención General de la Administración del Estado, por la que se regulan los procedimientos para la tramitación de los documentos contables en soporte fichero. (BOE 14.12.2005)
  • Licitación de «BASE – Gestió Integral de Multes» publicado en el BUTLLETÍ OFICIAL DE LA PROVÍNCIA DE TARRAGONA Núm. 158 Divendres, 9 de juliol de 2004

Es una interesante iniciativa de la Secretaría de Estado de Hacienda y Presupuestos, dependiente del Ministerio de Economía y Hacienda la difusión de una herramienta para facilitar la generación de firmas electrónicas cualificadas en base a este estándar TS 101 903. La herramienta se denomina DOCEL.

Por último, adjunto el enlace a una página web bastante completa sobre Seguridad XML, lo que incluye firmas electrónicas