Archivo de la categoría: Normalización

Cumbre sobre «La facturación electrónica en Europa», Madrid, 27, 28 y 29 de abril de 2010

2 respuestas

En el marco de la Presidencia Española de la Unión Europea, tendrá lugar en Madrid la Conferencia sobre «La facturación electrónica en Europa» auspiciada por la Comisión Europea. Esta conferencia, de carácter marcadamente internacional,  tendrá lugar en el Auditorio de la Secretaria de Estado de Telecomunicaciones y para la Sociedad de la Información y enlazará con el Congreso de Factura Electrónica que anualmente organiza ASIMELEC, y que este año también contará con un marcado componente internacional.

La conferencia institucional tendrá lugar los dias 27 y 28 de abril de 2010, y el Congreso de eFactura de ASIMELEC se celebrará el dia 29 de abril de 2010. Los asistentes internacionales podrán aprovechar el viaje para participar en ambos eventos asociados.

Marco internacional de la factura electrónica

Las facturas electrónicas, en comparación con las facturas en papel, ofrecen ventajas importantes para las organizaciones públicas y privadas de todos los tamaños. La adopción a gran escala de la facturación electrónica puede ser de considerable beneficio para la economía de la UE con un ahorro potencial para los socios comerciales (emisores y receptores de facturas).

Sin embargo, la mayoría de las posibilidades que ofrece la e-facturación permanece sin explotar, especialmente entre las PYME, debido a la persistencia de barreras técnicas y reglamentarias para su pleno despliegue.

En los últimos años, la Comisión Europea ha prestado un apoyo constante a la adopción de soluciones de e-facturación. Varias iniciativas a nivel europeo se han puesto en marcha con el fin de facilitar la creación de un sistema paneuropeo de un entorno electrónico de facturación de las empresas y administraciones públicas.

En particular, la Comisión creó un grupo independiente de expertos en e-facturación que propuso, a finales de 2009, un Marco Europeo de e-facturación  (EEIF: European e-Invoicing Framework) con recomendaciones para la prestación de servicios de e-facturación como  un proceso abierto, competitivo e interoperable  en toda Europa.

En paralelo a estas iniciativas, otras actividades que afectan a la adopción de las facturación electrónica son:

  • La creación de la Zona Única de Pagos para el Euro (SEPA) y
  • La Directiva sobre el IVA (2006/112/CE) y las propuestas de modificación de esta directiva que en el aspecto de la facturación electrónica
    están en debate en el Consejo.

El marco de facturación electrónica de la Comunidad Europea de propuesto por el Grupo de Expertos responde a las barreras identificadas, reglamentarias y técnicas, con las recomendaciones que tratan de normas,  interoperabilidad,  requisitos legales y de incentivos a la adopción de la facturación electrónica en las PYME. Estas propuestas han sido publicadas y están abiertas a consulta pública hasta el 26 de febrero de 2010. He tratado en este Blog algunos aspectos del informe del Grupo de Expertos.

La conferencia se celebra en un momento adecuado para debatir las recomendaciones del Grupo de Expertos y discutir las acciones prioritarias que deben adoptarse para eliminar las barreras que afectan actualmente a la utilización de facturas electrónicas.

En ese sentido, se han previsto cuatro sesiones orientadas a tratar sobre la superación de las dificultades actuales de la facturación electrónica:

  • Las PYME y la facturación electrónica
  • Interoperabilidad
  • Normas
  • Marco jurídico de las facturas electrónicas

Entre los oradores figuran los miembros del Parlamento Europeo y la Comisión Europea, representantes del Banco Central Europeo, representantes de alto nivel de la UE los gobiernos de los Estados miembros, las empresas, organismos de normalización y las ONG.

La conferencia está organizada por la Comisión Europea bajo los auspicios de la Presidencia española del Consejo. La conferencia tendrá lugar en la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información en Madrid el 27 y 28 de abril de 2010.

Congreso de ASIMELEC

ASIMELEC ha celebrado 4 Congresos sobre Factura Electrónica y Digitalización Certificada, y este año celebra un lustro de actividades relacionadas con la factura electrónica. El evento del año 2010 se ha planificado de forma que coincida con la cumbre europea de factura electrónica, y pueda enmarcarse entre las actividades vinculadas a la presidencia española  del Consejo. La fecha prevista es el 29 de abril de 2010, y el lugar del encuentro está por determinar, ya que aunque el Auditorio de la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información es un excelente marco para el evento, su capacidad está limitada a 200 personas y se esperan para este evento cerca de 300 congresistas.

Este año es relevante, además por las diferentes iniciativas asociadas a la Interoperabilidad, sobre las que se dará cuenta en el evento. En particular sobre el Proyecto Invoicex.

Este próximo congreso, El V Congreso de Factura Electrónica y Digitalización Certificada, tiene un coste  de 200 euros. Ya se ha habilitado la inscripción en el web de ASIMELEC.

Otros artículos relacionados:

Discrepancia con el Informe del Grupo de Expertos

Deja un comentario

Recientemente he hecho referencia al Informe final del Grupo de Expertos en Factura Electrónica enfatizando algunas discrepancias que he detectado entre lo que es opinión mayoritaria en España (y en algunos paises europeos) y lo que refleja el propio Final Report of the Expert Group on e-Invoicing .

Hoy he tenido ocasón de comentarlo en Radio Líder, emisora que se escucha en toda Galicia.

Este es el trozo del programa «Entre nosotros» que dirige la periodista Ana Valiño, y que se ha interesado por este tema:

Los puntos claves son el «equal treatment«, la firma electrónica y el formato de la factura, que debería ser UBL ya que CII (el formato identificado por el Grupo de Expertos), como ya he comentado en otra ocasión, no está todavía listo.

Arquitectura normalizada de recepción de facturas electrónicas en la Administración General del Estado

Deja un comentario

El entorno de normalización de la factura electrónica en España parte de la Orden PRE/2971/2007 que definía el formato facturae y en cuya disposición final segunda se establecía su evolución en el plazo de dos años (que ya se han cumplido) al estándard UBL 2.0

Aunque aun no se ha publicado ninguna versión de facturae basada en UBL, sí que se han publicado otras versiones que resuelven algunos problemas detectados (y crean otros, ya que las versiones no son compatibles). Además de acoger extensiones sectoriales.

Con la publicación en el marco del Centro de Transferencia de Tecnología (CTT) de la arquitectura normalizada de recepción de facturas electrónicas en la Administración General del Estado se da un paso más en la disponibilidad de especificaciones técnicas para llevar a cabo la facturación electrónica al sector público.

La Comisión Permanente del Consejo Superior de Administración Electrónica (CSAE), en su reunión de 25 de marzo de 2009, acordó, a propuesta del Ministerio de Economía y Hacienda, la constitución de un grupo de trabajo sobre la arquitectura general de facturación electrónica en la Administración General del Estado. Este grupo surge dada la urgente necesidad de diseñar una arquitectura general de recepción de facturas electrónicas en el ámbito de la AGE para evitar la dispersión de esfuerzos y facilitar la implantación de la facturación electrónica. La coordinación de dicho grupo es encargada al propio Ministerio de Economía y Hacienda.

El objeto y alcance del grupo de trabajo se ha centrado en el análisis y elaboración de una propuesta de arquitectura general para la recepción de facturas electrónicas en la Administración General del Estado y organismos autónomos, y en la definición de las interfaces de las plataformas de facturación con los servicios de facturación de los proveedores, por un lado, con los sistemas de gestión económico-presupuestaria, por otro, y con los sistemas de registro electrónico, por último.

El Coordinador del grupo ha sido D. José María Sobrino, de la Intervención General de la Administración del Estado (IGAE) del Ministerio de Economía y Hacienda.

En el grupo de trabajo han participado representantes de 9 Ministerios (MPRE-Ministerio de la Presidencia, MEH-Ministerio de Economía y Hacienda, Ministerio de Justicia, Ministerio de Defensa, Ministerio del Interior, Ministerio de Fomento, MTIN-Ministerio de Tecnología e Innovación, MITyC-Ministerio de Industria, Turismo y Comercio y Ministerio de Cultura ) y de 7 entidades públicas (AEAT, INE, FNMT, Comisión Nacional de la Competencia, RED.es, Correos, Seguridad Social), con una media de asistencia a las reuniones de 23 personas.

Las conclusiones del grupo de trabajo y sus documentos se finalizaron el 25 de noviembre de 2009.

Objetivos

El objeto y alcance del grupo de trabajo se ha circunscrito a la arquitectura general para la facturación electrónica en la Administración General del Estado y organismos autónomos, siendo sus principales objetivos:

  1. Analisis de la conveniencia de plantear un punto general de entrada y distribución de facturas electrónicas (PGEFe) y, si se adopta la decisión de su conveniencia, establecer:
    • Las funciones del PGEFe.
    • Las necesidades adicionales para el enrutamiento automático de la factura
  2. Análisis de la posibilidad adicional de que el PGEFe pueda desempeñar la función de plataforma de emisión y recepción de facturas electrónicas para aquellos departamentos, centros gestores u organismos que optaran por no disponer de su propia plataforma.
  3. Normalización de las interfaces entre los sistemas de facturación de los proveedores y las plataformas de facturación electrónica de las entidades públicas (y, en su caso, el PGE-Fe).
  4. Normalización de las interfaces entre las plataformas de facturación electrónica (y, en su caso, el PGEFe) y los sistemas de registro electrónico de los departamentos.
  5. Normalización de las interfaces de comunicación entre las plataformas de facturación electrónica y los sistemas de gestión.

Ventajas

  • Se establecen unas interfaces puestas a disposición de los proveedores de plataformas de facturación y de sistemas de gestión económico- presupuestaria de modo que se facilita la implementación y gestión de la facturación electrónica.
  • Se apuesta por la creación de un punto general de entrada y distribución de facturas electrónicas (PGEFe).
  • El PGEFe puede actuar como punto general de entrada y distribución, y plataforma de emisión y recepción de facturas electrónicas para aquellos departamentos, centros gestores u organismos que optaran por no disponer de su propia plataforma.

Detalles técnicos

Estos son los Escenarios de la arquitectura e interfaces de facturación electrónica en la AGE

Escenario I: El organismo receptor de facturas dispone de su propia plataforma de recepción de facturas electrónicas y solicita al proveedor que le envíe directamente las facturas a dicha plataforma.

Escenario II: El organismo receptor de facturas dispone de su propia plataforma de recepción de facturas electrónicas, pero la recepción y consulta de estado de las facturas se realiza a través del punto único PGEFe.

Escenario III: El organismo receptor de facturas no dispone de su propia plataforma de recepción de facturas electrónicas. En este caso, se utiliza la Plataforma Central de Facturación AGE.

Restricciones para la recepción de facturas electrónicas en la AGE

  • Formato de recepción de facturas: Actualmente Facturae, en cualquiera de sus versiones publicadas (3.0, 3.1 y 3.2 en la actualidad).
  • Implícitamente, se limita también el formato de firma electrónica admitida según definición de Facturae:
    • Estándar XAdES (EPES o XL).
    • Política de firma Facturae (2 versiones publicadas hasta el momento: 3.0 y 3.1).
  • Los accesos a la plataforma de recepción de facturas AGE son siempre securizados (acceso vía certificado electrónico o usuario y contraseña).
  • No se admiten facturas por lotes ni envíos de arrays de facturas.

Interfaces

Interfaz proveedor con plataformas o PGEFe.

Dos mecanismos: Automático (servicios web alojados en las plataformas) o Manual (formularios web).

  • Recepción de facturas.
  • Consulta de facturas (por identificador de factura o por apunte registral).
  • Anulación de facturas.

Interfaz plataformas o PGEFe con Sistemas de Gestión.

Vía automática (servicios web alojados en los sistemas de gestión)

  • Alta de factura.
  • Consulta de estado de facturas.
  • Anulación de facturas.

Vía no automática (servicios web alojados en la plataforma de facturación).

  • Solicitud de relación de nuevas facturas.
  • Descarga de facturas.
  • Cambio de estado de facturas.

Vía manual (ver facturas disponibles; descarga de fichero facturae y actualización de estado de factura).

Asignación de código electrónico en la plataforma de facturación.

Interfaz plataformas o PGEFe con Registro órgano gestor o Registro Electrónico Común.

  • Registro.
  • Consulta de apuntes.

Informe final del Grupo de Expertos en Factura Electrónica

2 respuestas

El Final Report of the Expert Group on e-Invoicing es el resultado de más de un año de trabajo de más de 30 expertos de toda Europa.

Junto con conclusiones que verdaderamente pueden ser de consenso se incluyen otras que parecen sesgadas por determinados intereses políticos, y en defensa de algunas posiciones particulares.

El informe tiene partidarios y detractores como puede verse en estos blogs:

Las dos posiciones son relevantes porque de la tesis «triunfadora» depende el consenso para la modificación de la Directiva 2006/112/EC, cuyo borrador actual está disponible.

La posición mayoritaria en España es que no es conveniente cambiar las reglas del juego a mitad del partido, y que tampoco es aceptable, ni siquiera dar a entender que se pueden cambiar. El efecto que tendría es que todos los jugadores se pararan hasta que queden claras las reglas de nuevo, ralentizando la expansión de la factura electrónica. Otra posición mayoritaria en España es que tampoco se deben cambiar las reglas de forma que favorezcan a los más lentos (o a los más torpes) del mercado pero con gran potencia de lobby como algunas entidades financieras europeas (afortunadamente, no las españolas).

Entre todos los conceptos que se manejan, el más peligroso es el de «equal treatment» refiriéndose a un tratamiento igual de las facturas electrónicas respecto a las de papel. Y sin definir qué significa eso.

Para ser correcto, debería llevar la coletilla latina «mutatis mutandi», que significa que se aplica la semejanza cambiando lo que haya que cambiar, como consecuencia de la diferencia de soporte que conlleva formas diferentes de gestionar. Por ejemplo, en una factura en papel se le puede poner el sello «pagado» sobre el documento original. Eso no es tan fácil de representar en un documento electrónico, salvo que se tengan en cuenta parámetros de autenticidad electrónica que algunos de los expertos pretenden eliminar de la factura electrónica.

En todo caso, mi posición personal es que no se puede imponer un modelo que cada vez es menos seguro (el del papel) sobre otro que nace con cierto nivel de seguridad. Por el contrario, dado que las facturas en papel son fácilmente falsificables se debería imponer una exigencia de seguridad adicional (se me ocurren varias: usar papel con marcas de agua, usar papel timbrado, usar papel con marcas de trepado, por ejemplo indicando el CIF del emisor, usar papel con tintas ultravioletas,…)

Por todos estos argumentos y algunos más estoy preparando un documento que recoja la posición española a favor del mantenimento de la firma electrónica de las facturas electrónicas en la Directiva 2006/112/CE, y de la adopción internacional a corto de plazo del estándar UBL, sin perjuicio de una migración futura a CII, cuando la norma esté más madura. La idea es enviarlo a la UE en el marco de la consulta  «Consultation on the Final Report of the Expert Group on e-Invoicing».

Estoy abierto a que me envieis comentarios y sugerencias para su inclusión en el documento, pero recordad que el período de la consulta se extiende desde el 30.11.2009 hasta el  26.2.2010, por lo que tengo que enviar el documento en inglés antes del cierre del plazo. Si alguien quiere contactar conmigo para este tema, que llame al 902 365 612.

Proyecto Invoicex

2 respuestas

El pasado verano del año 2009 se cumplieron las fechas definidas en la ley 30/2007 de contratos del sector público para la entrada en vigor de la obligación de los proveedores de las administraciones públicas de enviar a estas las facturas electrónicas correspondientes a sus servicios prestados o productos suministrados.

Aunque no se ha publicado ninguna norma formal en desarrollo de la disposición final novena de la Ley 30/2007, contamos con la Orden PRE/2971/2007 que definía el formato facturae y en cuya disposición final segunda se establecía su evolución en el plazo de dos años (que ya se han cumplido) al estándard UBL 2.0

Con la publicación de la arquitectura normalizada de recepción de facturas electrónicas en la Administración General del Estado se da un paso más en la disponibilidad de especificaciones técnicas para llevar a cabo la facturación electrónica al sector público.

Por otro lado, algunas comunidades autónomas ya han iniciado los trabajos para constituir plataformas que faciliten la recepción de facturas electrónicas en los organismo públicos de su ámbito. Entre ellas, Cataluña, País Vasco, la Comunidad de Valencia y La Rioja.

En todo caso el mercado es cada vez más maduro, y las diferentes plataformas de facturación electrónica están en mejor disposición que nunca para llevar a cabo esfuerzos cooperativos que faciliten la interoperabilidad.

Este es el objetivo del proyecto Invoicex, presentado por Albalia Interactiva al Programa de Ayudas del Plan Avanza, junto con ASIMELEC y otras 7 entidades, y al que se ha invitado a participar a un conjunto amplio de empresas y organismos relacionados con la factura electrónica, incluyendo a las entidades financieras. Al finalizar el año hemos recibido la resolución definitiva por parte del Ministerio de Industria, Turismo y Comercio, del proyecto identificado con el código TSI-020512-2009-69.

En total ya son 20 las entidades participantes y aun estamos abiertos a empresas y organismos interesados en impulsar la interoperbilidad de los intercambios de los documentos electrónicos (inicialmente facturas) entre empresas españolas y entre estas y las del resto del mundo. Las entidades interesadas en participar pueden contactar con el 902 365 612.

FactOffice, la madurez de la eFactura y de la firma electrónica

Deja un comentario

Me encantó la presentación que Santi Casas hizo ayer en las Jornadas de Signatura Electrónica. Aunque la anticipa en su blog,  merece la pena verla y oirla.

Le he pedido que la pase a video. A ver si se anima.

Empieza con importantes efemérides, como el 40 aniversario del nacimiento de Internet, el 20 aniversario de la caida del muro de Berlín o el 10 aniversario de la existencia de normativa de firma electrónica.

Y luego repasa 10 años de desarrollo de la firma electrónica y otras circunstancias anejas, entre las que se incluye la factura electrónica. Normas, estándares, navegadores, sistemas operativos, prestadores, empresas,…

Para concluir que FactOffice supone la culminación del proceso. Una aplicación sencilla, para personas sin excesivos conocimientos del tema, que permite gestionar facturas en papel y electrónicas con pleno valor legal.

 

zBackTrust, firma electrónica para System Z

10 respuestas

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

8 respuestas

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:

Sistemas de Acceso Condicional

2 respuestas

En la TDT de pago, «pago por visión», se utilizan Sistemas de Acceso Condicional. Una buena descripción de estos sistemas se incluye en el documento «Especificación de receptores de televisión digital terrestre para acceso condicional» elaborado por el Subgrupo 3 del Grupo de Trabajo 7 del Foro Técnico de la televisión digital coordinado por la Subdirección General de Infraestructuras y Normativa Técnica del Ministerio de Industria, Turismo y Comercio, al que ya hice referencia.

Reproduzco del citado documento.

Los sistemas de acceso condicional (CAS), de acuerdo con la definición de la LGTel, se utilizan para ocultar los contenidos a aquellos usuarios que no disponen de los permisos adecuados y al mismo tiempo permiten ver los contenidos a aquellos usuarios que sí disponen de dichos permisos.

Un sistema de acceso condicional consta de un sistema de codificación del contenido más un sistema de cifrado de claves y derechos para prevenir una recepción no autorizada.

Los sistemas CAS pueden ser muy variados, los principales sistemas se basan en algoritmos estándares que se describen en la norma “DVB Common Scrambling Algorithm”. Estos sistemas interactúan con la cabecera de TV digital y siempre que ambos sistemas cumplan con la norma DVB antes citada, el multiplexor será quién codifique los contenidos y envíe al sistema de acceso condicional la clave de cifrado.

El proceso de cifrado es complejo, se genera una palabra de control (CW) que sirve para codificar los contenidos digitales según el algoritmo utilizado y a la vez la misma CW se envía al receptor para que éste pueda descifrar dichos contenidos si se obtienen los derechos pertinentes. En todo caso el cifrado podrá ser siempre a nivel de PES o bien a nivel de TS, pero no en ambos a la vez.

Una descripción funcional de los sistemas de Acceso Condicional se presenta a en la siguiente figura proporcionada por la UER:

Sistemas de Acceso Condicional

Sistemas de Acceso Condicional

Desde del punto de vista de coexistencia de sistemas, los sistemas de acceso condicional se pueden dividir en dos tipos:

  • Simulcrypt. El mismo contenido se protege con dos sistemas de acceso condicional de forma simultánea. Normalmente el parque de receptores es diferente.
  • Multicrypt. Que permite la implementación simultánea de varios CAS en el mismo dispositivo con el fin de proteger contenidos diferenciados.

Los sistemas de acceso condicional requieren de diversos elementos que se distribuyen entre la cabecera de TV digital y el descodificador digital. Atendiendo al grado de integración en los receptores digitales, estos sistemas pueden estar en un módulo externo o estar embebidos (con tarjeta inteligente o chip ensamblado) y ser genéricamente de los siguientes tipos:

  • Sistemas basados en la Interfaz Común del DVB (DVB-CI): En este tipo, el sistema de acceso condicional reside en un módulo Interfaz Común (CAM) externo (tipo la tarjeta PCMCIA de los sistemas informáticos), que se inserta en una ranura normalizada del DVB-CI en el descodificador. A su vez, la Interfaz Común puede disponer de una tarjeta chip externa para almacenar parte del sistema de acceso condicional o tenerlo todo integrado en el módulo CAM.
  • Sistemas basados en una tarjeta inteligente: En este tipo de sistemas la seguridad está repartida entre un S/W residente y una tarjeta inteligente extraíble. La parte esencial del sistema de acceso condicional reside, por razones de seguridad, en una tarjeta inteligente del tipo ISO7816 . El descodificador traslada la información que proviene del operador a la tarjeta, y sigue las órdenes
    que provienen de la misma. El descodificador requiere de una ranura para interfaz ISO7816 en donde se inserta la tarjeta y de la integración de un módulo software en el descodificador para realizar las funciones antes indicadas. La parte de S/W residente en el receptor es actualizable vía las propias emisiones del canal de televisión.
  • Sistemas basados en un chip, en los que el sistema de acceso condicional o parte de él está integrado en el chip, el cual, a su vez, debe ser integrado en el hardware del descodificador. No se requieren de elementos externos al descodificador. Todas las actualizaciones y gestión del sistema se realiza vía las propias emisiones del canal de televisión. Se debe tener en cuenta que los sistemas basados en chips también pueden estar alojados en las tarjetas CAM’s.
  • Sistemas basados en tarjeta inteligente virtual, en los que el STB tiene conectividad IP, disponiendo de un canal dedicado, permanente y seguro (mediante protocolos IP adecuados), entre el terminal y la red interactiva. Este canal permite realizar una función equivalente a la de la tarjeta inteligente, pero donde las operaciones de obtención de derechos se realizan en la red, en un servidor especial que provee el proveedor de la solución CAS.

Existen diferentes alternativas para la configuración de sistemas de Acceso Condicional desde un punto de vista del terminal. En todo caso se debe entender que los equipos son muy sensibles a las diferentes modalidades por lo que se debe minimizar las implicaciones en ellos:

    ƒ

  • Sistema Residente. Sistema integrado y activado desde el inicio de la fabricación del terminal.

    • ƒ

  • Sistema Descargado vía OTA. Posteriormente a su salida al mercado y siempre que se hayan llegado a los acuerdos pertinentes entre los proveedores de CAS y los fabricantes de terminales se podrá realizar una descarga del CAK.

    • ƒ

  • Sistema Durmiente. En otros casos los fabricantes de terminales y proveedores de CAS llegan a un acuerdo para que los equipos lleven implantado un determinado sistema de acceso condicional, pero que no se active hasta que no reciba la instrucción por el aire.

Documentos de referencia

  • ETSI EN 300 744 Digital Video Broadcasting (DVB); DVB Framing structure, channel coding and modulation for digital terrestrial television.
  • ETSI EN 300 468 Digital Video Broadcasting (DVB): Digital broadcasting systems for television, sound and data services: Specification for Service Information (SI) in Digital Video Broadcasting (DVB) systems.
  • DVB A 011 Common Scrambling Algorithm. DVB Blue Book A011.
  • ETSI EN 50221 Common Interface for Conditional Access and other Digital Video Broadcasting Decoder Applications.
  • ETSI ETR 289 Digital Video Broadcasting (DVB); Support for use of scrambling and Conditional Access within digital broadcasting systems.
  • ETSI TS 101 699 Digital Video Broadcasting (DVB); Extensions to the Common Interface Specification.
  • ETSI ETR 154 ed3 Digital Video Broadcasting (DVB); Implementation Guidelines for the use of MPEG-2 Systems, Video and Audio in Satellite Cable and Terrestrial Broadcasting Applications.
  • ETSI ETR 211 Digital Broadcasting Systems for Television, Sound and
    Data Services; Guidelines on the Implementation and Usage of DVB Service
    Information.
  • ETSI TS 102 201 Digital Video Broadcasting (DVB); Interfaces for DVB
    Integrated Receiver Decoder (DVB-IRD)
  • ETSI TS 101 154 DVB Specification for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream.
  • ETSI TS 101 812 Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification version 1.0.3
  • ETSI TS 102 006 Digital Video Broadcasting (DVB) Specification for SSU (System Software Update) in DVB systems.
  • ETSI TS 102 366 DVB Digital Audio Compression (AC-3, Enhanced AC-3) Standard.
  • ISO/IEC 7816, partes 1 a 3 Identification cards – Integrated circuit cards with contacts, Parts 1-3. ISO/IEC International Standard IS 7816.
  • NorDig Unified NorDig Unified Requirements for Integrated Receiver Decoders for use in cable, satellite, terrestrial and IP-based networks, Version 1.0.2.
  • Ley 32/2003 Ley general de Telecomunicaciones y Real Decreto 2296/2004 Reglamento sobre mercados de comunicaciones electrónicas, acceso a las redes y numeración.
  • AENOR UNE 133 300 AENOR UNE 133 300 Navegación y Acceso.Información de los contenidos en las emisiones de TDT.
  • CENELC EN 62216-1 Receptores de TV digital terrestre para sistemas DVB-T. Parte 1: Especificación del receptor básico.
  • CENELEC R 206 001 “Guidelines for Implementations and Use of the Common Interface for DVB Decoder Applications”.
  • ISO/IEC 13818 Information Technology – Generic coding of Moving Pictures and associated audio information.
  • CI Plus Specification V1.2. Technical Specification. CI Plus Specification. Content Security Extensions to the common interface.
  • PPSCVA T1 Perfil de protección para la aplicación de creación y verificación de firma electrónica Tipo 1 de INTECO.
  • DGTVi D-Book DGTVi D-Book 1.2, rev.1, Compatible DTV receivers for the Italian market: baseline requirements.
  • EMV 4.2 Book 1. Application Independent ICC to Terminal Interface Requirements.

Innovación tecnológica en entornos empresariales

Deja un comentario

content-adobe-docsEl próximo martes 14 de Julio de 2009, de 9:15 a 13:00 tendrá lugar en el Hotel Eurostars Madrid Tower, Paseo de la Castellana 259 B, (situado en una de las 4 emblemáticas torres que señalan el norte de Madrid) la JORNADA ADOBE DE INNOVACIÓN TECNOLÓGICA EN ENTORNOS EMPRESARIALES.

La inscripción es gratuita.

Incluyo la reseña del evento:

El entorno actual exige un mayor desarrollo e innovación en materia TIC para contribuir al éxito de un modelo de crecimiento económico basado en el incremento de la competitividad y la productividad y la mejora de la calidad de servicio al ciudadano y los consumidores.

Las obligaciones legales y las normativas sobre el acceso a la información telemática ofrecen un marco idóneo para realizar cambios que contribuyan a la mejora de los procesos para hacerlos más rentables y eficientes.

Los retos de adaptación con fechas muy tensas requieren reflexionar sobre las herramientas disponibles y por ello nos complace invitarte a unirte a nosotros en esta jornada de innovación tecnológica para revisar los puntos clave de las soluciones Adobe, usadas por las principales empresas públicas y privadas en todo el mundo.

 Agenda

09.15 a 09.30 – Registro

09.30 a 09.45 – Bienvenida y presentación objetivos de la jornada, por Alfons Sort.

09.45 a 10.15 – Adaptación normativa de la Sociedad de la Información en la Administración Pública y Grandes Empresas con Julián Inza.

10.15 a 11:00 – El formato PDF y Adobe Acrobat 9. Estándares ISO, seguridad, firma electrónica, accesibilidad e interoperabilidad.

11.00a 11.15 – Pausa-café

11.15 a 12.45 – Presentación de Soluciones de Adobe:

  • Tramitación electrónica y expediente electrónico. 
  • Hacia la Banca del futuro: Formularios, Seguridad, firma electrónica y RIAs
  • Componentes de la Plataforma Adobe Livecycle ES y su valor añadido

12.45 a 13.00 – Debate

Ponentes:

  • Alfonso Sort, Director General Adobe Systems Ibérica.
  • Julián Inza, Presidente de Albalia Interactiva, profesor del Instituto de Empresa, miembro del Observatorio del Notariado para la Sociedad de la Información, Chairman del UBL Security SC de OASIS Open
  • Javier Fernández, Director Comercial para Administración Pública Adobe Systems Ibérica
  • Ramón de La fuente, Director Comercial para Banca y Seguros Adobe Systems Ibérica
  • Roberto Boya, Director Técnico Adobe Systems Ibérica