Archivo de la categoría: Time stamping

time.eadtrust.eu


Un servicio útil para todos los ordenadores es el de sincronización de tiempo.

EADTrust dispone de un servicio gratuito de sincronización del que ya hice mención en el artículo «Sincronicemos nuestros relojes»

Es un servicio NTP sincronizado con el Real Observatorio de la Armada (fuente oficial del tiempo en España), que sirve para todo tipo de ordenadores.

Puede ser utilizado en sistemas operativos veteranos como Windows 95/98/98SE/ME/2000 y Windows NT3.51/4/2000 Server gracias a programas gratuitos como por ejemplo AboutTime

En general, debe tenerse en cuenta que en los Firewall se debe tener permitido el acceso de entrada salida por el puerto 123/ UDP

En los sistemas operativos Windows XP/Vista/7 el soporte de NTP está integrado y se accede a su control haciendo doble click en la parte inferior derecha de la pantalla en la que se indica la fecha y la hora.

Es importante tener en cuenta que sólo los Administradores y los Usuarios Avanzados pueden cambiar la fecha y la hora.
Para poder hacerlo desde una cuenta de usuario limitada con la que normalmente se usa el equipo, hay que ir  a
Panel de Control > Herramientas Administrativas > Directiva de Seguridad Local > Directivas Locales > Asignación de derechos de usuario.

En el objeto Cambiar la Hora del Sistema, hay que añadir el nombre de la cuenta limitada a la que se quiere permitr el cambio de configuración de la hora del sistema.

Para sincronizar múltiples equipos basados en Windows en grandes redes configuradas como dominios Microsoft, se pueden usar los recursos definidos de foema nativa para este tipo de redes:

  1. Sincronizar el servidor PDC (Primary Domain Controller) o Active Directory con el servidor de tiempo.
  2. Sincronizar los ordenadores con la hora del servidor PDC o Active Directory por medio de protocolos propios como el servicio de horario de Windows W32Time. También se pueden usar scripts con comandos # net time

Para sincronizar equipos basados en Mac OSX, en la pestaña de las Propiedades de la Fecha y Hora, agregar la URL del servicio de sincronización temporal.

En sistemas operativos semejantes a Linux, se deben iniciar los servicios NTP, a través del interfaz gráfico o mediante comandos

  1. Probar la conexión a través del comando:  ntpdate time.eadtrust.eulo que dará como respuesta la sincronización de la hora con el servidor
  2. Editar el archivo:  /etc/ntp.conf y agregar la línea:   server time.eadtrust.net
  3. Iniciar el servicio ntp, con el comando: service ntpd start.

Productos y servicios basados en DSS


En el artículo «Firma electrónica con OASIS DSS» ya di algunas indicaciones de la importancia de este protocolo para desplegar servicios de firma electrónica en las grandes organizaciones. Recientemente se ha anunciado que está previsto incluir esta funcionalidad en futuras versiones de @firma, la herramienta más utilizada en las administraciones públicas para gestionar firmas electrónicas.

En el momento actual, solo dos productos dan soporte a este protocolo:

Sin embargo, sí que está disponible como servicio (en lo que en Albalia llamamos Trustworthiness of services in the cloud) a través de algunos prestadores de servicios de certificación:

En cuanto a entidades, Caixa Galicia lo ha implantado en su arquitectura sobre zSeries (Mainframe IBM), gracias a zBackTrust, la variante de BackTrust orientada a zLinux y z/OS, con Websphere.

Sincronicemos nuestros relojes


El asunto de la sincronización de todos los relojes utilizados en informática resulta crucial y desde luego es importante en los ámbitos en los que se emplea la firma electrónica.

En las organizaciones es vital la sincronización de relojes, especialmente por motivos de seguridad, cuando se custodian logs (registros) de transacciones, operaciones o alertas, ya que en ocasiones es preciso correlacionar sucesos almacenados en diferentes sistemas, que tienen sentido si los datos se refieren al mismo marco temporal.

En relación con las firmas electrónicas, la modalidad XAdES-T incorpora un sello de tiempo y conviene que la haga el firmante en el momento mismo de la firma. El sello de tiempo lo emite una TSA (como EADTrust) que utiliza una referencia de tiempos fiable. El sello de tiempo vincula un documento (a partir de su HASH o resumen) con un instante de tiempo y esa vinculación queda firmada electrónicamente por la TSA.

Para la sincronización de relojes y para las referencias de sello firmadas (timestamping) debemos recurrir a las fuentes fiables de tiempo disponibles en los diferentes paises.

Una de estas entidades es el ROA (Real Observatorio de la Armada), que determina la hora oficial española.Puede accederse a su servidor NTP a través de la URL hora.roa.es (al ser una fuente de tiempo de referencia, desde el punto de vista de NTP se denomina Stratum 1).

El protocolo NTP (Network Time Protocol) está basado en el estándar RFC 1305 (NTP version 3) publicado en marzo de 1992. Existe una versión simplificada (SNTP, Simple Network Time Protocol, version 4) publicada como Informational RFC  (RFC 2030) en octubre de  1996, diseñada para entornos que no requieren todas las funciones de NTP y que supone la mayor parte del tráfico NTP actual. En la actualidad se está intentando minimizar los problemas de interoperabilidad entre las versiones NTPv3 and SNTPv4, al tiempo que se añaden características de seguridad (ver, por ejemplo, el borrador de norma «Network Time Protocol Version 4 Autokey Specification«)

En España existen otros servidores NTP subordinados (que denominamos Stratum 2), además del de ROA, y sincronizados con él:

  • time.eadtrust.net
  • time.camerfirma.com
  • ntp.escomposlinux.org
  • hora.oxixares.com
  • hora.rediris.es
  • hora.uniovi.es
  • hora.unex.es
  • hora.uvigo.es
  • hora.uv.es
  • gong.uv.es

He tocado con frecuencia el tema del tiempo en otros artículos:

24 uvas


Esta es la noticia que he oído esta mañana en una radio musical (no olvidemos el día que es hoy):

El alcalde de Madrid, Alberto Ruiz Gallardón, ha anunciado que este año se sustituye el tradicional reloj de la Puerta de Sol por uno digital, para anunciar el cambio de año.

Por este motivo, en vez de 12 campanadas sonarán 24 pitidos al alcanzar la hora 24 del 31 de diciembre de 2009 que se transformará en las 00 del 1 de enero de 2010.

Efectivamente, en vez de las campanadas de los 4 cuartos previos a las de las horas, doce, sonarán 2 pitidos largos, que indican la fase de «preparados» y «listos»  y a continuación 24 pitidos cortos que señalan las horas del día que se alcancen en ese momento, veinticuatro.

Un representante de los vendedores de uva navideña ha elogiado la medida, señalando que este avance tecnológico situará a España como referente mundial.

24 campanadas

Características de zBackTrust


La firma electrónica es parte de los requisitos que tienen que cumplir entidades financieras y aseguradoras (junto con otras entidades «de especial relevancia económica») para implementar su sistema de interlocución telemática según se dicta en el artículo 2 de la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. También forma parte de la Sede Electrónica, el Registro Telemático y los sistemas de publicación y notificación fehaciente que todos los organismo de la administración pública deben implementar como consecuencia de la aplicación de las Leyes  30/2007, de 30 de octubre, de Contratos del Sector Público y 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

En las instituciones que cuentan con equipos System z, la solución de firma electrónica de elección es zBackTrust, conjunto de módulos de firma electrónica diseñado por Albalia Interactiva para los equipos de IBM y comercializado conjuntamente con INSA.

El módulo principal es un servicio Web basado en el estándar OASIS DSS (Digital Signature Service) que se instala de forma centralizada y que ofrece funcionalidades de Firma Electrónica Remota, Verificación y Ampliación de Firmas XAdES-XL a toda la organización. Dispone de funcionalidades de firma electrónica de PDFs y está disponible también en forma de API.

Estas son algunas de las características de zBackTrust:

  • Celeridad en los procesos de generación y comprobación de Firmas electrónicas a través de API y DSS (Digital Signature Service).
  • Generación de firmas completas XAdES – XL
  • Validación de certificados y firmas electrónicas (permite comprobar los certificados de cualquier prestador de servicios de certificación)
  • Generación de evidencias electrónicas para la custodia digital de documentos electrónicos firmados
  • Compatible con el procesador criptográfico (HSM) IBM 4764
  • Compatible con diferentes Middleware: WebSphere, Weblogic y Tomcat.
  • Entornos z/OS y z/Linux
  • Cumplimiento de estándares de ETSI y OASIS.

Ventajas de la Solución

  • Indenpendiza los servicios de seguridad y confianza de los procesos de negocio, al disponer de una infraestructura común de firma electrónica para todas las aplicaciones en las que se requiere integrar dichas funcionalidades.
  • Garantiza el crecimiento del sistema con nuevas funcionalidades, sin que afecte al desarrollo del resto de aplicaciones.
  • Minimiza los costes de desarrollo y mantenimiento, evitando la programación de código común en múltiples aplicaciones y plataformas.
  • Garantiza la capacidad de aceptar certificados de cualquier prestador de servicios de certificación europeo.
  • Permite cumplir con la normativa reciente:
    • Factura electrónica (Orden PRE/2971/2007)
    • Contratación Pública (Ley 30/2007)
    • Administración Electrónica (Ley 11/2007)
    • Interlocución Telemática (Ley 56/2007)
    • Directiva 1999/93/CE

Otros artículos relacionados:

zBackTrust, firma electrónica para System Z


Acaba de incluirse en la oferta de INSA la solución desarrollada por Albalia Interactiva zBackTrust, que permite desarrollar el soporte a la firma electrónica desde las plataformas corporativas más avanzadas basadas en equipos System z de IBM.

En su continuo empuje por los sistemas Mainframe, IBM tiene planeado el lanzamiento de unas 30 mejoras de software para la plataforma System z, las cuales se irán introduciendo a lo largo del 2009.

12 de ellas ya se han puesto en el mercado y están relacionadas con las herramientas de desarrollo Rational Software, la administración de los datos de InfoSphere y Cognos, las ofertas de gestión de transacciones de WebSphere y los servicios TI de Tivoli.

El Gigante Azul ha hablado durante años del resurgimiento de los sistemas Mainframe para dar respuesta a las nuevas cargas de trabajo. El aumento de los MIPS (Millones de Instrucciones por Segundo) y el creciente interés de los ISV (Vendedores de Software Independientes) por estos sistemas así lo confirma.

No en vano y según la compañía, durante el año pasado más de 150 ISVs se han pasado a la plataforma System z y se han añadido más de 1.000 aplicaciones que pueden ser ejecutadas en los mainframes.

Los analistas indican que buena parte de este resurgir de la plataforma se puede atribuir a los nuevos motores de procesado que IBM ha construido para hacer más fácil la ejecución de tareas Linux y Java en los System z.

Otros vendedores también están ayudando a este crecimiento. Es el caso de los desarrolladores de software CA o BMC Software, que siguen mejorando sus soluciones para la gestión de los mainframes. Por su parte Unisys lanzó a finales de mayo nuevos equipos basados en la plataforma de IBM.

Los sistemas z son excelentes entornos de ejecución Java, tanto operando sobre sistema operativo z/OS como zLinux, por lo que permiten la adopción de las tecnologías más avanzadas en un marco de ejecución de alto rendimiento corporativo.

Referencias:

Interoperabilidad de los Prestadores de Servicios de Certificación


En pasados artículos he hecho referencia a que un cumplimiento diligente de la Directiva 199/93/CE de firma electrónica implicaba la aceptación de los certificados reconocidos (o cualificados) de todos los prestadores de servicios de certificación europeos.

Este punto de vista ha quedado recogido, por ejemplo en la Orden EHA/962/2007, pero hay quien piensa que la Ley 11/2007 y el Esquema Nacional de Interoperabilidad dejan margen para que un organismo concreto pueda establecer criterios propios de aceptación.

Debe aclararse que «los criterios propios» de aceptación solo son de aplicación a las firmas avanzadas, y que el criterio general es que las firmas avanzadas basadas en un certificado reconocido (es decir, cualificado), o en un certificado en cuya política se han utilizado mecanismos de verificación de identidad del firmante presenciales o equivalentes a presenciales, tienen un nivel de aceptación próximo al de las firmas reconocidas o cualificadas.

Sin embargo para facilitar la interoperabilidad de las firmas electrónicas en el marco europeo, hay algunos detalles que conviene tener en cuenta:

  1. Las URL de la CRL y del OCSP del prestador deben estar correctamente codificados en todos sus certificados (extensión AIA).
  2. El servicio OCSP, o, al menos el de CRL, de los prestadores válidos (los que figuran en la TSL) han de estar accesibles sin coste
  3. La información de URL de la Root, de la CPS, de los servicios OCSP y CRL de cada prestador de servicios de certificación deben estar codificados en las TSL de cada estado (que en España corresponde al MITyC, no al MAP) y en la TSL armonizada.
  4. Siempre que el destinatario de una firma sea una entidad privada, la firma electrónica debería construirse con arreglo a las especificaciones XAdES-XL o CAdES-XL (respectivamente descritas en las normas TS 101 903 y TS 101 733). En general, este tipo de firma debería ser de elección en todos los casos. Las administraciones públicas que generen firmas siempre deberían hacerlo con estos formatos (ya que eliminan la carga de la verificación de validez del certificado al receptor)

Es necesario contar con una lista actualizada de prestadores europeos, que debería ser posible obtener a partir del sistema de notificación del artículo 11 de la directiva 1999/93/CE. La información de cada prestador debería contener, además de la URL de la home page, su dirección, email y teléfono (lo que más o menos ya se recoge hoy en día) junto con las URL de la Root, de la CPS, de los servicios OCSP y de la CRL de sus CAs (lo que es esencial para la interoperabilidad, pero resulta difícil de encontrar en la página web del prestador en el sistema actual) .

Es necesario que los sistemas nacionales de supervisión que notifican el estado de gestión de los sistemas de certificación de su pais a la Comisión Europea recojan los datos mencionados en sus repositorios. En España, esta responsabilidad corresponde al MITyC, según se establece en la Ley 59/2003.

Conviene poner en valor los Sistemas Voluntarios de Acreditación, como el de ASIMELEC.

Y es conveniente ir eliminando mecanismos alternativos de verificación de validez de certificados como los definidos en la orden EHA/1181/2003 que tuvieron su razón de ser antes de la publicación de la Ley 59/2003, pero no tienen sentido en el actual marco legislativo. El repositorio de la AEAT ya solo tendría sentido en el marco de la normativa de factura electrónica. En su momento supuso un gran empuje a los prestadores de servicios de certificación españoles, pero en la actualidad supone  un ejemplo mal copiado por muchos organismos públicos que crean sus propias listas de prestadores de servicios de certificación sin ser conscientes con que basta con remitirse a la lista del MITyC.

El problema de censar a los prestadores de servicios de certificación, que NUNCA debería ser un problema del tercero que confía, se está convirtiendo en uno de los frenos al desarrollo de la firma electrónica. Y hubiera sido algo muy sencillo de desarrollar si se hubiera aplicado correctamente el artículo 11 de la directiva 1999/93/CE. Es decir, si los datos antes indicados (URL de la Root, de la CPS, de los servicios OCSP y de la CRL de las CAs de cada pais) se hubieran recogido correctamente desde el principio, y el comité del artículo 9 hubiera sido más proactivo.

Por esta ineficiencia de la Comisión ha sido necesario gastar cientos de miles de euros en proyectos de interoperabilidad cuyos resultados están por ver, y se han creado malas costumbres que se tardará años en erradicar.

Otros artículos relacionados:

FactOffice 1.2


Acabamos de subir a Codeplex la versión 1.2 de FactOffice.

Soluciona un error de validación del CIF europeo en las plantillas. La parte de código interno de dicha validación ya se actualizó en la versión 1.1

Se han producido 1483 descargas del instalador de la versión 1.0, y 220 del código fuente. De la versión 1.1 se han producido 1614 descargas del instalador y 180 del código fuente.

Valoramos positivamente de los desarrolladores que se inspiran en nuestro código el  que hagan mención a Albalia y Microsoft en sus agradecimientos.

Sin necesidad de tener que tocar el código fuente es posible cambiar «el aspecto» de las plantillas que proporciona Factoffice, como por ejemplo el color de las tablas, agregar datos o images corporativas.

Basta con abrir una plantilla de las que se proporcionan, y cambiar lo que se desee. Eso si, es muy importante no eliminar nada de lo que hay ni cambiar el nombre de ningún componente, ya que implicaria un mal funcionamiento de la plantilla.

Una vez realizados los cambios se guarda el archivo como plantilla de word (*.dotx) y ya tenemos una plantilla personalizada.

En algunos casos, habrá componentes bloqueados que no se pueden editar. Para soslayarlo  hay que habilitar la pestaña de programador en la cinta de opciones, abrir la vista diseño y a partir de ahí ya tenemos acceso a todos los componentes.

«Insistimos, es muy importante: no quitar nada de lo que hay ni modificar los nombre de los componentes».

Se puede aprender esto y mucho más en los cursos de FactOffice que organiza Atenea Interactiva. Este es el 

Programa:

9:15 Recepción de asistentes y entrega de documentación

9:30 Novedades Importantes de la nueva normativa de Facturación

  • Marco Internacional
  • Normativa española: RD 1496/2003; RD 87/2005, de 31 de enero; Orden EHA /962/2007
  • Ley 59/2003, de 19 de diciembre, de Firma Electrónica.
  • Contenido de la factura.
  • Requisitos legales de los sistemas de facturación electrónica.
  • Fechas de entrada en vigor de la obligación de facturar electrónicamente
  • Formatos de las facturas electrónicas XML (formato facturae)

10:30 La firma y certificación electrónica: concepto y aplicaciones

  • Formatos de las firmas electrónicas XML (firmas XAdES)
  • Firmas electrónicas avanzadas y reconocidas. Dispositivos de creación de firma
  • Firmas simples y completas. Revocación de certificados y timestamping
  • Certificados electrónicos reconocidos o cualificados.
  • El DNI electrónico

11:30 Coffee-Break

12.00 La facturación electrónica con FactOffice

  • FactOffice como sistema de facturación electrónica, desde MS Word 2007
  • Obtención e Instalación de Factoffice 1.2
  • Configuración de FactOffice. OCSP y Timestamping
  • Generación de facturas, en papel y electrónicas. Firma electrónica de facturas
  • Envío y recepción de facturas electrónicas. Importación y exportación de facturas

13:00 Ejercicios para practicar el uso de FactOffice

Para esta parte del curso se recomienda que los alumnos acudan con su ordenador portátil compatible con Windows XP, Vista o Windows 7. 

Seminario eAdministración en Sevilla


El próximo 20 de octubre de 2009 tendrá lugar en Sevilla el Seminario «eAdministración –
Adaptación a la Ley 11/2007 y a la Ley 30/2007» que impartiremos, mano a mano, Bartolomé Borrego, Vocal Responsable de la División de Nuevas Tecnologías en la Delegación Especial de la AEAT en Andalucía y yo.

Lo organiza Atenea Interactiva y cuesta 300 euros + IVA.

Creo que puede ser de interés para organismos públicos o de participación pública que se enfrentan al reto de aplicar la Ley 11/2007 y a la Ley 30/2007, en lo relativo a la Administración Electrónica y a la Contratación Pública Electrónica.

Incluyo a continuación el programa previsto.

9:00-9:30    Recepción de los asistentes y entrega de la documentación

9:30-10:15 Obligaciones para las administraciones públicas derivadas del nuevo marco normativo de e-administración y  contratación pública.

D. Julián Inza

10:15 -10:45 Identidad Digital y DNIe.

  • La identidad digital en Internet.
  • Los sistemas de federación de identidades
  • Los sistemas “fuertes” de autenticación
  • Los certificados digitales y el DNIe
  • La gestión de las capacidades y la representación.
  • Aceptación de Certificados de otros países.

D. Julián Inza

10:45-11:15 Coffee-Break

11:15-11:45 Firma Electrónica

  • Certificados Reconocidos
  • Dispositivos seguros de creación de firma. 
  • La firma electrónica reconocida
  • Servicios de validación de certificados.
  • La certificación de tiempo. El TimeStamping
  • La firma electrónica de larga duración (CAdES/XAdES)
  • Los servicios de firma electrónica (OASIS DSS)

D. Julián Inza

11:45-12:15 Implementación del Perfil del Contratante

  • Requisitos a cumplir. Artículo 42 de la Ley de 30/2007.
  • La Plataforma de Contratación del Estado
  • La prueba del momento: Time Stamping. 
  • El testigo electrónico.

D. Julián Inza

12:15-13:15 Facturación electrónica en el sector público

  • Formatos y Firmas. 
  • Plataformas.
  • Gestión integrada de recepción de facturas (papel y electrónicas)

D. Julián Inza

13:15-13:45 Claves de la reforma de la Ley 11/2007 de acceso de los ciudadanos a los servicios electrónicos

  • Ámbito.
  • Principios.
  • Derechos de los ciudadanos.

D. Bartolomé Borrego Zabala

13:45-14:15  Registros Electrónicos o telemáticos

  • Antecedentes. Requisitos.
  • Justificaciones de presentaciones telemáticas.
  • Regulación de los plazos

D. Bartolomé Borrego Zabala

14:15-15:30  Comida: Cocktail Buffet

15:30-16:15 Notificaciones fehacientes por medios electrónicos

  • Notificaciones telemáticas seguras.
  • Consulta de notificaciones.
  • Notificación por comparecencia.
  • Publicación electrónica del tablón de anuncios o edictos.
  • SMS y Correo electrónico certificados.

D. Bartolomé Borrego Zabala

16:15-16:45  Uso de la firma electrónica en la Administración Pública

  • Sistemas de firma electrónica para la actuación administrativa automatizada.
  • Firma electrónica del personal al servicio de las Administraciones Públicas.
  • Identificación y autenticación de los ciudadanos por funcionarios públicos.

D. Bartolomé Borrego Zabala

16:45-17:15  Plataformas de Pagos

  • Justificante electrónico del pago. Medios de pago.
  • Pasarela de pago de la AEAT. Otras pasarelas de pago.
  • Centralización de servicios de pagos electrónicos.
  • Plataforma de Servicio de Pago Telemático (Red.es)

D. Bartolomé Borrego Zabala

17:15-17:45  Copias electrónicas, Compulsa electrónica y Digitalización Certificada.

  • Documento electrónico
  • La compulsa electrónica por las Administraciones Públicas.
  • Copia de documentos electrónicos. Digitalización Certificada.

D. Bartolomé Borrego Zabala

17:45-18:30  Representación en los procedimientos electrónicos.

  • La representación y la Colaboración Social.
  • Apoderamiento para la realización de trámites electrónicos

D. Bartolomé Borrego Zabala
 
18:30-19:00  Coloquio y conclusiones