ES2250346T3 - Autentificacion de datos transmitidos en un sistema de transmision digital. - Google Patents

Abstract

Método de autentificación de datos (46, 60) transmitidos mediante un sistema de transmisión digital (1), caracterizado porque dicho método incluye las siguientes etapas anteriores a la transmisión: determinación de, al menos, dos valores cifrados (146) para al menos una parte de los datos, determinándose cada valor cifrado para los mismos datos utilizando una clave de un respectivo algoritmo de cifrado; y salida de al menos dichos dos valores cifrados con dichos datos.

Description

Autentificación de datos transmitidos en un sistema de transmisión digital.

La presente invención hace referencia a un método de autentificación de los datos transmitidos en un sistema de transmisión digital.

La emisión de datos digitales es muy conocida en el ámbito de los sistemas de TV de pago, en los que se envía información audiovisual codificada, normalmente mediante un enlace vía satélite o satélite/cable, a diversos abonados, cada uno de los cuales posee un decodificador capaz de decodificar el programa transmitido para su posterior visionado. También son conocidos los sistemas de transmisión terrestre. Algunos sistemas recientes también han utilizado el enlace de transmisión para transmitir otros datos además de los datos audiovisuales, tales como programas informáticos o aplicaciones interactivas a un decodificador o al PC que está conectado.

Un problema especial en la transmisión de datos de aplicaciones se encuentra en la necesidad de verificar la integridad y el origen de dichos datos. Dado que pueden utilizarse datos de este tipo para reconfigurar el decodificador, así como para llevar a cabo cualquier número de aplicaciones interactivas, es esencial que los datos recibidos estén completos y sean identificados como procedentes de una fuente conocida. De lo contrario, pueden surgir problemas operativos relacionados con la descarga de datos incompletos, así como el riesgo de que el decodificador permanezca abierto a ataques por parte de terceros o similares.

La verificación de la integridad de dichos datos puede llevarse a cabo mediante verificación del flujo de paquetes de datos recibidos directamente por el decodificador. Con anterioridad a la transmisión, los paquetes suelen firmarse mediante la aplicación de un algoritmo de troceo al menos a una parte de los datos del paquete. El valor troceado resultante se almacena en el paquete. Al recibir el paquete de datos, el decodificador aplica a los datos el mismo algoritmo de troceo y compara el valor troceado calculado por el decodificador con el valor troceado almacenado en el paquete recibido a fin de verificar la integridad de los datos recibidos. Por ejemplo, en caso de fallo o de interrupción de la transmisión, el valor troceado calculado no será el mismo que el valor troceado recibido. Entonces se alertará al decodificador sobre la presencia de posibles errores en el paquete de datos descargado y se volverá a cargar el paquete de datos defectuoso.

Un problema asociado con el uso de un algoritmo de troceo bien conocido, como el algoritmo "Message Digest MD5", es que el cálculo del valor troceado se lleva a cabo de acuerdo con una serie de etapas de cálculo conocidas públicamente, con el resultado que cualquiera puede calcular el valor troceado de un paquete de datos. Por lo tanto, no será posible verificar el origen de un paquete de datos recibido por el decodificador. Esto puede tener una especial importancia cuando los datos recibidos modifican los archivos de datos operativos del decodificador.

Para superar este problema, en lugar de utilizar un algoritmo de troceo para calcular un valor troceado para al menos una parte de los datos, puede calcularse un valor de firma de un paquete de datos utilizando un valor de clave secreta conocido sólo por el emisor. Esta clave puede obtenerse utilizando un algoritmo de clave simétrica, tal como el algoritmo "Data Encryption Standard [estándar de cifrado de datos]" o algoritmo DES, almacenando el decodificador una clave equivalente. No obstante, puede ser más conveniente utilizar un algoritmo de clave pública/privada asimétrica, como el algoritmo de Rivest, Shamir y Adleman, o RSA, en el cual las claves pública y privada forman componentes complementarios de una ecuación matemática.

El transmisor responsable de la elaboración de los paquetes de datos almacena la clave privada y calcula el valor de firma utilizando la clave privada. La clave pública se almacena en los decodificadores que van a recibir los datos, codificando mediante hardware la clave pública en la memoria del decodificador durante el proceso de fabricación. Al recibir el paquete de datos, el decodificador verifica el valor de la firma utilizando la clave pública almacenada mediante la comparación de los datos recibidos con el resultado de la aplicación del algoritmo de clave pública al valor de firma recibido.

Incluso en estos sistemas seguros es posible que el valor de la clave privada corra peligro, por ejemplo, de ser distribuido públicamente de forma ilegal. En estos casos, es necesario que el transmisor revoque rápidamente el uso de la clave pública equivalente para impedir la recepción no autorizada de paquetes de datos. Además también será necesario utilizar una nueva pareja de claves pública/privada. Por lo tanto, el emisor deberá sustituir la clave pública almacenada en los decodificadores de los usuarios legales por una nueva clave pública. Dependiendo de la sensibilidad de la clave pública, esta operación puede exigir que el emisor deba ocuparse de organizar la costosa y problemática devolución de estos decodificadores al fabricante para la codificación mediante hardware de la nueva clave pública en las memorias de estos decodificadores.

El documento GB 2301919 describe un sistema de firmas de etapas múltiples que utiliza múltiples dispositivos de firma para estampar una sola firma que pueda verificarse utilizando una sola clave de verificación pública. Cada dispositivo de firma posee una parte de la clave de firma y estampa una firma parcial en respuesta a la autorización de una pluralidad de agentes de autorización. La seguridad del sistema se ve aumentada mediante la distribución de la capacidad para estampar firmas entre una pluralidad de dispositivos de firma y mediante la distribución de la autoridad para estampar una firma parcial entre una pluralidad de agentes de autorización. No obstante, en el caso de simulación de la clave privada, todos los receptores tendrán que actualizar la clave de verificación pública, lo que puede resultar costoso y tedioso, especialmente cuando, como se ha descrito anteriormente, la clave está codificada mediante hardware, por ejemplo en un decodificador.

La presente invención, al menos en sus realizaciones preferidas, trata de resolver estos y otros problemas facilitando una solución resistente a la simulación de una clave privada.

Un primer aspecto de la presente invención facilita un método para autentificar los datos transmitidos en un sistema de transmisión digital, incluyendo dicho método, con anterioridad a la transmisión, las siguientes etapas:

determinación de, al menos dos valores cifrados para al menos una parte de los datos, determinándose cada valor cifrado para los mismos datos, utilizando una clave de un algoritmo de cifrado respectivo, y

la salida de, al menos dichos dos valores cifrados con dichos datos.

La presente invención resulta especialmente aplicable, sin limitación, a situaciones en las que resulta deseable actualizar con seguridad datos sensibles, tal como una clave que va a utilizarse en un nuevo algoritmo de cifrado, a fin de asegurarse que los datos se reciben como se han enviado. Para facilitar dicha seguridad, se determinan al menos dos valores cifrados para al menos una parte, preferiblemente la mayoría y más preferiblemente la totalidad de los datos. Cada valor cifrado se determina utilizando una clave de un respectivo algoritmo de cifrado. Si una de las claves se encuentra en situación de peligro, puede ser posible que un pirata informático intercepte los datos y modifique el contenido de los datos y del valor cifrado calculado utilizando la clave en peligro. No obstante, no será posible que el pirata informático cambie el valor cifrado calculado utilizando la clave que no está en peligro. Por lo tanto, al verificar los valores cifrados, utilizando claves equivalentes a las claves utilizadas para calcular los valores cifrados, los dos valores que utilizan las claves equivalentes no serán el mismo, lo que indicará que los datos se han corrompido.

Por tanto, la presente invención se extiende a un método de autentificación de los datos transmitidos mediante un sistema de transmisión digital, incluyendo dicho método las siguientes etapas:

recepción de dichos datos y de al menos dos valores cifrados determinados para al menos una parte de los datos, determinándose cada valor cifrado para los mismos datos utilizando una clave de un algoritmo de cifrado, respectivo;

almacenamiento de una pluralidad de claves;

procesamiento de cada valor cifrado utilizando una clave almacenada de dicho algoritmo de cifrado respectivo; y

comparación de cada valor resultante subsiguiente con al menos dicha parte de los datos para autentificar al menos dicha parte de los datos.

La presente invención también proporciona un aparato para autentificación de los datos que van a trasmitirse en un sistema de transmisión digital, incluyendo dicho aparato:

medios para determinar al menos dos valores cifrados para al menos una parte de los datos, siendo determinado cada valor cifrado para los mismos datos utilizando una clave de un algoritmo de cifrado respectivo; y

medios para obtener con dichos datos al menos dichos dos valores cifrados.

La presente invención se extiende a un receptor/decodificador que incluye:

medios para la recepción de un archivo de datos que incluye datos y al menos dos valores cifrados determinados para al menos una parte de los datos, siendo determinado cada valor cifrado para dichos datos utilizando una clave de un algoritmo de cifrado respectivo;

medios para almacenar una pluralidad de claves;

medios para procesar cada valor cifrado utilizando una clave almacenada de dicho algoritmo de cifrado respectivo; y

medios para comparar cada valor resultante subsiguiente con al menos una parte de los datos para autentificar al menos dicha parte de los datos.

El término "receptor/decodificador" o "decodificador" como se utiliza en este documento puede indicar un receptor para la recepción de señales codificadas o sin codificar, por ejemplo señales de televisión y/o radio que pueden ser emitidas o transmitidas por alguno otro medio. Entre las realizaciones de dichos receptores/decodificadores pueden incluirse un decodificador integrado en el receptor para decodificar las señales recibidas, por ejemplo en un "decodificador doméstico", funcionando dicho decodificador en combinación con un receptor físicamente independiente o un decodificador que incluya funciones adicionales, como un navegador web, o que esté integrado con otros dispositivos como una grabadora de vídeo o una televisión.

Según se utiliza en el presente documento, el término "sistema de transmisión digital" incluye cualquier sistema de transmisión para la transmisión o emisión, por ejemplo, de datos básicamente audiovisuales o digitales multimedia. Aunque la presente invención resulta especialmente aplicable a un sistema de televisión digital, la invención también puede ser aplicable a una red fija de telecomunicaciones para aplicaciones multimedia a través de Internet, a un circuito cerrado de televisión, etc.

Según se utiliza en el presente documento, el término "sistema de televisión digital" incluye, por ejemplo, cualquier sistema de transmisión vía satélite, terrestre, por cable y de otro tipo.

Entre los algoritmos más adecuados para ser utilizados en esta invención a fin de generar claves privadas/públicas simétricas pueden incluirse las RSA, Fiat-Shamir o Diffie-Hellman, y entre los algoritmos de clave simétricos apropiados pueden incluirse los algoritmos de tipo DES, por ejemplo. No obstante, a menos que sea obligatorio a la vista del contexto o se especifique en otra forma, no se efectúa ninguna distinción en general entre las claves asociadas a algoritmos simétricos y las asociadas con algoritmos públicos/privados.

Se han utilizado los términos "codificado" y "cifrado", así como "palabra de control" y "clave" en diversas partes del texto con fines de aclaración. No obstante, se entenderá que no se efectúa ninguna distinción fundamental entre "datos codificados" y "datos cifrados" ni entre "palabra de control" y "clave".

Adicionalmente, se han utilizado los términos "cifrado" y "firmado" y "descifrado" y "verificado" en diversas partes del texto con fines de aclaración. No obstante, se entenderá que no se efectúa ninguna distinción fundamental entre "datos cifrados" y "datos firmados" ni entre "datos descifrados" y "datos verificados".

Igualmente, el término "clave equivalente" se utiliza para denominar una clave adaptada para descifrar los datos cifrados por una clave mencionada en primer lugar o viceversa.

Las características anteriormente descritas relativas a aspectos del método de la presente invención también pueden aplicarse a aspectos materiales y viceversa.

A continuación se describirá, únicamente a modo de ejemplo, una realización preferida de la invención haciendo referencia a las figuras adjuntas, en las cuales:

La figura 1 muestra el diagrama esquemático de un sistema de televisión digital para su uso con la presente invención.

La figura 2 muestra la estructura de un decodificador del sistema de la figura 1.

La figura 3 muestra la estructura de diversos componentes del flujo de transporte de emisiones MPEG;

La figura 4 muestra la división de una aplicación de software en diversas tablas MPEG.

La figura 5 muestra la relación existente entre los archivos de datos DSM-CC y las tablas MPEG eventualmente generadas.

La figura 6 muestra la relación entre cliente, servidor y gestor de red según se define en el contexto de DSM-CC.

La figura 7 muestra los objetos, directorio, subdirectorio y archivo autentificados.

La figura 8 muestra los formatos de un certificado de emisor, un certificado de autoridad de certificación y un certificado de autoridad de certificación raíz.

La figura 9 muestra el formato de una lista de revocación de certificaciones.

La figura 10 muestra el formato de un mensaje de gestión de certificados raíz (RCMM).

La figura 11 muestra las etapas correspondientes al procesamiento de un RCMM tras su recepción por un decodificador.

En la figura 1 se muestra el esquema de un sistema de televisión digital 1 de acuerdo con la presente invención. La invención incluye un sistema básicamente convencional de televisión digital 2 que utiliza el conocido sistema de compresión MPEG-2 para transmitir señales digitales comprimidas. En mayor detalle, el compresor MPEG-2 3 de un centro emisor recibe un flujo de señales digitales (normalmente una cadena de señales digitales). El compresor 3 está conectado a un multiplexor y codificador 4 mediante la conexión 5.

El multiplexor 4 recibe una pluralidad de señales de entrada digitales, ensambla el flujo de transporte y transmite las señales digitales comprimidas a un transmisor 6 del centro de emisiones a través de la conexión 7, que por supuesto puede adoptar una amplia variedad de formas, incluyendo un enlace de telecomunicaciones. El transmisor 6 transmite señales electromagnéticas a través del enlace de subida 8 hacia un transpondedor vía satélite 9 donde son procesadas electrónicamente y emitidas a través de un enlace de bajada nocional 10 al receptor terrestre 12, convencionalmente en forma de antena parabólica propiedad del usuario final o alquilada por este. Las señales recibidas por el receptor 12 se transmiten a un receptor/decodificador integrado 13 propiedad del usuario final o alquilado por este y que se encuentra conectado a la televisión 14 del usuario final. El receptor/decodificador 13 decodifica la señal comprimida MPEG-2 en una señal de televisión para el aparato de televisión 14.

Por supuesto, son posibles otros canales de transporte para la transmisión de datos, como la emisión terrestre, la transmisión por cable, los enlaces combinados satélite/cable, las redes telefónicas, etc.

En un sistema multicanal, el multiplexor 4 gestiona información de audio y vídeo recibida desde diversas fuentes paralelas e interactúa con el transmisor 6 para emitir la información a través del número de canales correspondiente. Además de la información audiovisual, los mensajes o aplicaciones o cualquier otro tipo de datos digitales pueden introducirse en algunos o en la totalidad de estos canales entrelazados con la información de audio y vídeo digital transmitida. En este caso, el compresor 3 comprimirá y empaquetará en formato MPEG un flujo de datos digitales en forma, por ejemplo, de mensajes y archivos de software en formato DSM-CC (Digital Storage Media Command and Control [Control y comando de medios de almacenamiento digital]). La descarga de los módulos de software se describirá a continuación en mayor detalle.

Un sistema de acceso condicional 15 se conecta al multiplexor 4 y al receptor/decodificador 13 y se encuentra situado parcialmente en el centro emisor y parcialmente en el decodificador. Permite al usuario final acceder a emisiones de televisión digital procedentes de uno o más proveedores de emisiones. Una tarjeta inteligente capaz de descifrar mensajes relativos a ofertas comerciales (es decir, uno o varios programas de televisión vendidos por el proveedor de la emisión) puede insertarse en el receptor/decodificador 13. Utilizando el decodificador 13 y la tarjeta inteligente, el usuario final puede adquirir ofertas comerciales bien en la modalidad de abono o en una modalidad de pago por visión. En la práctica, el decodificador puede configurarse para gestionar sistemas de control de acceso múltiple, por ejemplo del diseño Simulcrypt o Multicrypt.

Como se ha mencionado anteriormente, los programas transmitidos por el sistema se codifican en el multiplexor 4, estando determinadas las condiciones y claves de acceso aplicadas a una transmisión dada por el sistema de control de acceso 15. De este modo, la transmisión de datos codificados es muy conocida en el ámbito de los sistemas de TV de pago. Normalmente, los datos codificados se transmiten junto con una palabra de control para la descodificación de los datos, encontrándose la propia palabra de control cifrada mediante la denominada clave de explotación, transmitiéndose en formato cifrado.

Los datos codificados y la palabra de control cifrada se reciben en el decodificador 13, que tiene acceso a un equivalente de la clave de explotación almacenada en una tarjeta inteligente insertada en el decodificador para descifrar la palabra de control cifrada y descodificar posteriormente los datos transmitidos. Un abonado que se encuentre al corriente de pagos recibirá, por ejemplo, en un EMM (Entitlement Management Message [mensaje de gestión de autorización]) emitido mensualmente la clave de explotación necesaria para descifrar la palabra de control cifrada a fin de permitirle ver la transmisión. Además de su utilización para el descifrado de programas de televisión audiovisuales, pueden generarse y transmitirse claves de explotación similares para verificar otros datos, como módulos de software, como se describirá más adelante.

Un sistema interactivo 16, que también se encuentra conectado al multiplexor 4 y al receptor/decodificador 13 y que se encuentra también situado parcialmente en el centro de emisiones y parcialmente en el decodificador, permite al usuario final interactuar con diversas aplicaciones mediante un canal de retorno de módem 17. El canal de retorno de módem también puede utilizarse para las comunicaciones usadas en el sistema de acceso condicional 15. Por ejemplo, un sistema interactivo se puede utilizar para permitir al espectador comunicarse inmediatamente con el centro de transmisiones para solicitar la autorización que le permita ver un evento específico, descargar una aplicación,
etc.

Elementos físicos del Receptor/Decodificador

Haciendo referencia a la figura 2, los elementos físicos del receptor/decodificador 13 o decodificador doméstico adaptado para su uso en la presente invención se describirá brevemente a continuación. Los elementos mostrados en esta figura se describirán mediante bloques funcionales.

El decodificador 13 comprende un procesador central 20 que incluye elementos de memoria asociados y está adaptado para recibir datos de entrada procedentes de un interfaz serie 21, de un interfaz paralelo 22 y de un módem 23 (conectado al canal de retorno de módem 17 de la figura 1).

El decodificador está adaptado adicionalmente para recibir entradas procedentes de un mando a distancia de infrarrojos 25 a través de una unidad de control 26 y a través de los conmutadores 24 situados en el panel central del decodificador. El decodificador también posee dos lectores de tarjetas inteligentes 27, 28 adaptados para leer tarjetas inteligentes, bancarias y de abono 29,30, respectivamente. La entrada también puede recibirse a través de un teclado de infrarrojos (no mostrado). El lector de tarjetas inteligentes de abono 28 interactúa con una tarjeta de abono insertada 30 y con una unidad de acceso condicional 29 para suministrar la palabra de control necesaria a un desmultiplexor/decodificador 30 para permitir la decodificación de la señal de emisión cifrada. El decodificador también incluye un sintonizador convencional 31 y un desmodulador 32 para recibir y desmodular la transmisión vía satélite antes de ser filtrada y desmultiplexada por la unidad 30.

El procesamiento de datos en el interior del descodificador suele ser gestionado por el procesador central 20. La arquitectura de software del procesador central se corresponde con una máquina virtual que interactúa con un sistema operativo de nivel inferior realizado en los componentes de hardware del decodificador.

Estructura de Paquete de los Datos Transmitidos

A continuación se describirá, haciendo referencia a las figuras 3 y 4, la estructura de paquete de los datos incluidos en el flujo de transporte MPEG enviado desde el transmisor al decodificador. Como se observará, aunque la descripción se va a centrar en el formato de tabulación utilizado en la norma MPEG, los mismos principios son igualmente de aplicación a otros formatos de flujos de datos en paquetes.

Haciendo particular referencia a la figura 3, un flujo de bits MPEG incluye una tabla de acceso a programas ("PAT") 40 que cuenta con un identificador de paquete ("PID") de 0. La PAT contiene referencias a los PIDS de las tablas de mapa de programas ("PMTs") 41 de diversos programas. Cada PMT contiene una referencia a los PIDs de los flujos de las tablas de audio MPEG 42 y de las tablas de vídeo MPEG 43 correspondientes a dicho programa. Un paquete cuyo PID sea cero, es decir, la tabla de acceso al programa 40, proporciona el punto de acceso para todos los accesos MPEG.

A fin de poder descargar aplicaciones y datos para ello, se definen dos nuevos tipos de flujos, y la correspondiente PMT también incluye referencias a los PIDs de los flujos de las tablas MPEG de aplicaciones (o de secciones de estas) y de las tablas MPEG de datos 45 (o de secciones de estas). De hecho, aunque en algunos casos podría ser conveniente definir tipos de flujos independientes para el software ejecutable de aplicaciones y datos para el procesamiento de dicho software, esto no es esencial. En otras realizaciones, los datos y el código ejecutable pueden ensamblarse en un único flujo al que se accede a través de la PMT, como ya se ha descrito.

Haciendo referencia a la figura 4, para poder descargar, por ejemplo, una aplicación incluida en un flujo 44, la aplicación 46 se divide en módulos 47, cada uno de los cuales está formado por una tabla MPEG. Algunas de estas tablas incluyen una única sección, mientras que otras pueden estar compuestas por una pluralidad de secciones 48. Una sección típica 48 incluye una cabecera, que a su vez incluye un identificador de tabla ("TID") de un octeto 50, el número de sección 51 de dicha sección de la tabla. El número total 52 de secciones de dicha tabla y una referencia a la extensión TID de dos octetos 53. Cada sección también incluye un componente de datos 54 y un CRC 55. Para una tabla específica 47, todas las secciones 48 que constituyen dicha tabla 47 tiene el mismo TID 50 y la misma extensión TID 53. Para una aplicación específica 46, todas las tablas 47 que constituyen dicha aplicación 46 poseen el mismo TID 50, pero distintas extensiones TID respectivas.

Para cada aplicación 46, se utiliza una sola tabla MPEG como tabla de directorio 56. La tabla de directorio 56 tiene en su cabecera el mismo TID que el resto de las tablas 47 que constituyen la aplicación. No obstante, la tabla de directorio tiene una extensión TID predeterminada de cero, a efectos de identificación, y debido al hecho de que sólo es necesaria una sola tabla para la información en el directorio. El resto de las demás tablas 47 tendrá normalmente extensiones TID distintas de cero, y están formadas por diversas secciones asociadas 48. La cabecera de la tabla de directorio también incluye un número de versión de la aplicación que va a descargarse.

Haciendo nuevamente referencia a la Figura 3, la PAT 40, las PNTs 41 y los componentes de aplicación y flujo de datos 44, 45 se transmiten cíclicamente. Cada aplicación transmitida cuenta con su respectivo TID predeterminado. Para descargar una aplicación, la tabla MPEG que posea el TID adecuado y una extensión TID de cero se descargan en el receptor/decodificador. Esta es la tabla de directorio correspondiente a la aplicación solicitada. Los datos que contiene el directorio se procesan seguidamente mediante el decodificador para determinar las extensiones TID de las tablas que constituyen la aplicación requerida. Con posterioridad, podrá descargarse cualquier tabla requerida que cuente con el mismo TID que la tabla de directorio y una extensión TID determinada a partir del directorio.

El decodificador está configurado para verificar cualquier actualización de la tabla de directorios. Esta operación puede llevarse a cabo descargando periódicamente la tabla de directorios, por ejemplo, cada treinta segundos, o cada minuto o cada cinco minutos, y comparando el número de versión de la tabla de directorios previamente descargada. Si el número de versión que acaba de descargarse se corresponde con una versión posterior, se borrarán las tablas asociadas con la tabla de directorios previa y se descargarán y ensamblarán las tablas asociadas a la nueva
versión.

En una configuración alternativa, el flujo de bits entrante se filtra utilizando una máscara correspondiente al TID, a la extensión TID y al número de versión, con unos valores configurados para el TID de la aplicación, una extensión TID de cero y un número de versión superior al número de versión del directorio actualmente descargado. Por ello, puede detectarse el incremento del número de versión, y una vez detectado, se descarga el directorio y se actualiza la aplicación, como se ha descrito anteriormente. Si debe terminarse una aplicación, se transmite un directorio vacío con el siguiente número de versión, pero sin que aparezca módulo alguno listado en el directorio. En respuesta a la recepción de dicho directorio vacío, el decodificador 2020 se programará para borrar la aplicación.

En la práctica, el software y los programas informáticos para la implementación de aplicaciones en el decodificador pueden introducirse a través de cualquiera de los componentes del decodificador, y especialmente, en el flujo de datos recibido a través del enlace vía satélite, como ya se ha descrito, pero también a través del puerto serie, la tarjeta inteligente, etc. Dicho software puede incluir aplicaciones de alto nivel utilizadas para implementar aplicaciones interactivas dentro del decodificador, como navegadores de Internet, aplicaciones de concursos, guías de programación, etc. El software puede también descargarse para cambiar la configuración de trabajo del software del decodificador, por ejemplo, mediante "parches" o similares.

Las aplicaciones también pueden descargarse a través del decodificador y se envían a un PC o similar conectado al decodificador. En este caso, el decodificador actúa como encaminador de comunicaciones para el software, que eventualmente se ejecuta en el dispositivo conectado. Además de esta función de encaminamiento, el decodificador también puede funcionar para convertir los datos en paquetes MPEG antes de encaminarlos al PC como software formado por archivos organizados, por ejemplo, de acuerdo con el protocolo DSM-CC (véase más adelante).

Organización de los datos en archivos de datos

La figura 5 muestra la relación entre datos organizados en un conjunto de archivos de datos DSM-CC-U-U (usuario a usuario) 60, en una aplicación ensamblada 46 y encapsulados en una serie de tablas MPEG 47. Esta relación se describe en el documento WO99/49614, cuyos contenidos quedan incorporados a este documento por referencia.

Con anterioridad a la transmisión, los archivos de datos se ensamblan en la aplicación 46 y, posteriormente, un compresor MPEG los empaqueta en tablas o módulos MPEG 47, como se ha descrito anteriormente, incluyendo una cabecera 49 específico del flujo de paquetes MPEG e incluyendo la ID de la tabla, el número de versión, etc. Como puede apreciarse, puede no existir una relación fija entre los datos organizados en los archivos de datos 61 y las eventuales tablas MPEG 47. Tras su recepción y filtrado por el decodificador, se descartan las cabeceras de paquetes 49 y la aplicación 46 se reconstruye a partir de los datos útiles de las tablas 47.

El formato DSM-CC correspondiente a los archivos de datos es una norma adaptada en particular para su uso en redes multimedia, y que define una serie de formatos de mensaje y de comandos de sesión para la comunicación entre un usuario cliente 70, un usuario servidor 71 y un gestor de recursos de red 72, como se muestra en la figura 6. El gestor de recursos de red 72 puede ser considerado como una entidad lógica que actúa para gestionar la atribución de recursos dentro de una red.

La comunicación entre un cliente y un servidor se establece mediante una serie de sesiones, intercambiándose una primera serie de mensajes entre un usuario (cliente 70 o servidor 71) y el gestor de la red 72, a fin de configurar el cliente y/o el servidor para las comunicaciones. Dichos mensajes se formatean de acuerdo con el protocolo denominado DSM-CC U-N (usuario a red). Se ha definido especialmente un subconjunto de este protocolo para la descarga de datos mediante emisión.

Una vez que se ha establecido un enlace de comunicaciones, se intercambian posteriormente mensajes entre el cliente 70 y el servidor 71 de acuerdo con el protocolo DSM-CC U-U. Una secuencia de mensajes de este tipo corresponde a los archivos de datos 60 de la figura 5. En el caso de los mensajes DSM-CC U-U, los datos se organizan en una serie de mensajes 61 agrupados de acuerdo con el protocolo BIOP (Broadcast InterOrb Protocol [protocolo InterOb de Emisor]).

Cada mensaje u objeto 61 incluye una cabecera 62, un sub-cabecera 63 y unos datos útiles 64, que contienen los propios datos. De acuerdo con el protocolo BIOP, la cabecera 62 contiene, entre otras cosas, una indicación del tipo de mensaje y de la versión de BIOP, mientras que el sub-cabecera indica el tipo de objeto y otras informaciones que debe definir el arquitecto del sistema.

Los objetos de datos 64 con los datos útiles de los archivos DSM-CC U-U pueden definirse generalmente como pertenecientes a uno de tres tipos: objetos de directorio, objetos de archivo y objetos de flujo. Los objetos de directorio definen directorios raíces o subdirectorios utilizados para servir de referencia a una serie de objetos de archivo asociados que contienen los datos reales de la aplicación.

Los objetos de flujo pueden utilizarse para activar una relación temporal que se establece entre los datos contenidos en los archivos de datos y en el propio flujo del paquete MPEG. Esto se puede utilizar, por ejemplo, en el caso de aplicaciones interactivas contenidas en los archivos de datos y diseñadas para su sincronización con los flujos elementales de vídeo o de audio recibidos y procesados por el decodificador. Como se ha mencionado anteriormente, de lo contrario podría no existir una correlación directa entre los datos en paquetes MPEG y los archivos de datos.

A diferencia de las tablas MPEG, cuando un sólo directorio hace referencia a un conjunto de tablas con un sólo nivel de jerarquía, los archivos de datos 60 pueden organizarse de una forma jerárquica bastante más compleja. Al igual que en el caso de los archivos almacenados en un PC o servidor, un directorio principal o raíz puede hacer referencia a uno o más subdirectorios, que a su vez se refieren a un segundo nivel de archivos de datos. Puede incluso hacerse referencia a un segundo directorio raíz asociado a otro conjunto de datos de aplicación.

Estructura de archivos para un conjunto de archivos de datos

Haciendo referencia a la figura 7, se muestra un ejemplo de estructura de archivos para un conjunto de archivos. Un directorio raíz DIR A0 indicado con el número 75 establece una relación entre un grupo de subdirectorios A1 y archivos de objeto 77. Para ofrecer una mayor claridad, tan sólo se muestra un solo grupo de archivos de objeto F1, F2, etc. asociados al subdirectorio A4. En la práctica, puede hacerse referencia a diversos grupos de archivos de objeto mediante cada uno de los subdirectorios A1 a A4.

Dentro de cada directorio y subdirectorio se introduce una serie de etapas de autentificación para los archivos vinculados a dicho directorio. Haciendo referencia al directorio raíz 75, la subcabecera 63 incluye un valor troceado obtenido mediante la aplicación de un algoritmo de troceado a una parte o a la totalidad de los datos almacenados en los archivos del subdirectorio A1 a A4, indicados con la referencia 76. El algoritmo de troceo utilizado puede ser de cualquier tipo conocido, tal como por ejemplo, el algoritmo "Message Digest MD5".

En una realización, el algoritmo puede aplicarse a cada archivo o subdirectorio asociado individualmente, almacenándose una relación de los valores de troceado para cada subdirectorio 76 en el directorio raíz 75 con anterioridad a la transmisión. No obstante, aunque dicha solución permite un grado mayor de resolución de verificación, en lo relativo a la verificación de cada subdirectorio, esta solución puede ser bastante ineficaz en lo relativo al tiempo de procesamiento necesario para que el decodificador calcule las firmas correspondientes. Por ende, la subcabecera 63 del directorio 79 preferiblemente comprende un valor troceado acumulativo 79, calculado mediante la aplicación del algoritmo de troceo MD5 a la combinación de subcabecera y secciones de datos útiles 63, 64 de los subdirectorios 76, es decir, sin la cabecera 62. Concretamente, los valores de troceado 82 incluidos en los subdirectorios 76 y que hacen referencia a la capa de objetos archivo 77 se encuentran incluidos en este cálculo de troceo.

En el caso del subdirectorio A4 mostrado en la Figura 7, este subdirectorio se refiere a un conjunto de archivos de objeto F1-Fn indicado con la referencia 77. Este valor se incluye en el proceso de troceo que da lugar al valor troceado 79. Por lo tanto, no es posible cambiar ninguno de los archivos objeto 77 sin cambiar el valor troceado 82 del subdirectorio 76, lo que a su vez modificará el valor troceado 79 del directorio 75.

En el caso actual, se calcula un valor troceado combinado para todos los subdirectorios A1-A4 a los que se hace referencia en el directorio. Este valor troceado se almacena junto con un identificador del grupo de subdirectorios del cual se han tomado los datos. En otras realizaciones, puede almacenarse en la subcabecera del directorio una serie de valores de troceado combinados o individuales y los correspondientes identificadores.

Por ejemplo, una segunda serie de directorios, también asociados al directorio raíz, pero que hacen referencia a un conjunto diferente de datos o código ejecutable pueden también agruparse, y se calcula un valor troceado acumulativo para estos directorios, almacenándose en el directorio raíz de la subcabecera. Un valor troceado único asociado a un directorio único puede almacenarse igualmente en la subcabecera del directorio raíz.

La autorización de grupos o archivos de datos individuales no impide, por supuesto, al directorio raíz (o, de hecho, a cualquier otro archivo) que haga también referencia a archivos de datos no validados o no sometidos al proceso de troceado, pero la ausencia de validación de dicho archivo deberá tenerse en cuenta durante cualquier operación con dicho archivo. A este respecto, puede no ser necesario, por ejemplo, autentificar los objetos del flujo.

En este caso, la utilización de la función troceo permite que el decodificador verifique la integridad o el grado de exactitud de los archivos de datos descargados. En el caso, por ejemplo, de un fallo o interrupción de la transmisión, el funcionamiento de un algoritmo de troceo acumulativo sobre los archivos dependientes recibidos no arrojará los mismos resultados que el valor troceado correspondiente a estos archivos almacenados en el directorio raíz. A continuación se alertará al decodificador sobre la presencia de posibles errores en los datos descargados y se recargarán los archivos de datos defectuosos.

Valor de firma para el directorio raíz

Para una mayor seguridad, se calcula un valor de firma para el directorio raíz 75. En esta realización se utiliza un algoritmo de clave privada/pública como el de Rivest, Shamir y Adleman, o RSA, siendo el emisor el responsable de generar los archivos de datos que poseen el valor de la clave privada, estando almacenados en los decodificadores los valores de la clave pública. Alternativamente, la clave secreta puede corresponder a una clave obtenida mediante un algoritmo de clave simétrica, tal como el algoritmo Data Encryption Standard o DES (estándar de cifrado de datos).

Como se muestra en la figura 7, el directorio raíz 75 comprende un identificador del emisor 80 que identificará al decodificador la clave pública que va a utilizarse durante la etapa de verificación, junto con el valor de firma calculado 81, generado utilizando la clave privada del emisor. En este caso, el valor de la firma 81 se genera aplicando la clave privada en poder del emisor a una parte o a la totalidad de los datos del directorio 75, incluyendo, preferiblemente, los datos útiles 64 y/o el valor o los valores de troceado acumulativos 79. A continuación, el decodificador podrá verificar este valor de la firma 81 utilizando la correspondiente clave pública identificada por el identificador del emisor 80.

En este ejemplo, los datos que se encuentran en el directorio 75 están sin cifrar y la clave pública se utiliza simplemente para proporcionar una valor de firma verificable por la clave pública. En realizaciones alternativas, una parte o la totalidad de los contenidos del directorio puede ser cifrada por la clave privada y ser descifrada posteriormente mediante la clave correspondiente.

En cualquiera de los casos, la generación de una valor de firma o un bloque de código cifrado mediante el uso de una clave secreta permite que un decodificador verifique la integridad y el origen del directorio 75 y, por implicación, la integridad y origen de los archivos a los que se refiere este directorio raíz. Debido a que los valores de troceado acumulativos para los archivos de referencia se encuentran incluidos en el cálculo de la firma 81, no es posible alterar estos valores sin que ello se detecte en la etapa de verificación. Debido a que cada valor troceado es generalmente único para un conjunto dado de datos, por lo tanto no sería posible modificar los contenidos de cualquier archivo dependiente sometido a troceado sin cambiar su valor troceado característico y, por lo tanto, el valor de firma resultante de un directorio.

Como podrá apreciarse, son posibles diversas variaciones, especialmente para reducir la cantidad de datos que se someten a troceado o se firman en cada etapa. En particular, en el caso de una firma o valor troceado en un directorio o subdirectorio utilizado para verificar un archivo de datos de nivel inferior, podrá generarse la firma del directorio o el valor troceado utilizando tan sólo el valor troceado de nivel inferior, y no otros datos.

Por ejemplo, el valor troceado combinado 79 en el directorio A0 75 puede generarse utilizando los valores de troceado combinados 82, 83 de cada uno de los subdirectorios A1-A4 indicados en 76. Dado que estos valores tienen la misma unicidad que los datos incluidos en los datos útiles del subdirectorio, el valor troceado combinado 79 seguirá siendo único para los subdirectorios en cuestión. Además, puede seguir asumiéndose la integridad del nivel inferior de los archivos de objeto y directorio 77, 78, debido a que los valores de troceado 82 siguen utilizándose para el cálculo.

Certificados digitales del emisor

Haciendo referencia a la figura 8, la clave pública 91 y el identificador de emisor 80 se facilitan al usuario del decodificador en un certificado digital, preferiblemente bajo la forma de la conocida norma X.509 de la International Standards organisation (ISO), codificado por hardware en la memoria del decodificador durante su fabricación. Dichos certificados se distribuyen entre los fabricantes de decodificadores a través de terceros de confianza, a los que normalmente se denominan Autoridades de Certificación (CAs). La utilización de estos certificados es cada vez más extendida, debido básicamente al protocolo de transporte Secure Socket Layer (SSL) [capa de conexión segura], desarrollado por Netscape Communications para garantizar las operaciones con tarjeta de crédito a través de la World Wide Web (WWW).

Al igual que la clave pública 91 y el identificador del emisor 80, el certificado digital asociado al emisor, o el certificado de emisor 90, también incluye:

\bullet

Un número de versión 92 del certificado del emisor 90;

\bullet

Un número de serie 93 del certificado del emisor 90;

\bullet

Una identidad CA 94 de la CA que distribuyó el certificado de emisor 90;

\bullet

El período de validez 95 del certificado de emisor 90 para indicar el inicio y el final del período de tiempo durante el cual se pretende utilizar el certificado; y

\bullet

Un valor de firma 96 del certificado de emisor 90.

Como se apreciará en los párrafos precedentes, el certificado de emisor incluye dos identificadores diferentes, un primer identificador del "nombre del expedidor", que se corresponde con la identidad 94 del distribuidor del certificado, y un segundo identificador de "nombre de argumento", correspondiente al identificador 80 que identifica la clave pública 91.

La CA calcula el valor de firma 96 del certificado de emisor 90, aplicando una clave privada de la CA, o una clave privada CA, al menos a una parte o a la totalidad de los datos incluidos en el certificado de emisor. A continuación, el decodificador puede verificar este valor de firma 96 mediante el procesamiento de la firma utilizando la correspondiente clave pública CA 101 identificada por la identidad de la CA 94, a fin de determinar que los contenidos del certificado no han sido modificados con posterioridad a la firma por parte de la CA.

El decodificador puede almacenar una pluralidad de dichos certificados para los diferentes emisores respectivos.

Certificados digitales de la Autoridad de Certificación

Haciendo nuevamente referencia a la figura 8, la clave pública CA correspondiente 101 y el identificador CA 94 se facilitan al usuario del decodificador en un Certificado CA 100, que también está codificado por hardware en el decodificador durante su fabricación. El Certificado CA 100 también incluye:

\bullet

Un número de versión 102 del certificado CA 100;

\bullet

Un número de serie 103 del certificado CA 100;

\bullet

Una identidad RCA 104 de la Autoridad del Certificado Raíz (RCA), como el European Telecommunications Standard Institute (ETSI), que distribuye el certificado CA 100

\bullet

El período de validez 105 del certificado CA 100; y

\bullet

Un valor de firma 106 del certificado CA 100.

Como puede apreciarse de cuanto antecede, un certificado CA también incluye dos identificadores diferentes, un primer identificador "nombre del expedidor" que se corresponde con la identidad 104 del distribuidor del certificado, y un segundo identificador de "nombre de argumento" correspondiente al identificador 94 que identifica la clave pública 101.

El RCA calcula el valor de firma 106 del certificado CA 100 aplicando una clave privada del RCA, o clave privada RCA, al menos a una parte o a la totalidad de los datos incluidos en el certificado CA. A continuación, el decodificador puede verificar este valor de la firma 106 procesando el certificado mediante la utilización de una clave pública RCA correspondiente 111 identificada mediante la identidad RCA 104, a fin de determinar sí los contenidos del certificado no se han modificado con posterioridad a la firma por parte del RCA.

El decodificador puede almacenar una pluralidad de dichos certificados para diferentes CAs respectivas.

Certificados digitales de Autoridad de certificación raíz

La correspondiente clave pública RCA 111 y el identificador RCA 104 se facilitan al usuario del decodificador en una RCA, o certificado raíz 110, que también está codificado mediante hardware en la memoria del decodificador durante su fabricación. Normalmente, cada decodificador incluye un conjunto de dos o más certificados raíz. Cada certificado raíz 110 también incluye:

\bullet

Un número de versión 112 del certificado raíz 110;

\bullet

Un número de serie 113 del certificado raíz 110;

\bullet

El período de validez 114 del certificado raíz 110; y

\bullet

Un valor de firma 115 del certificado raíz 110.

Como puede apreciarse de cuanto antecede, el certificado raíz tan sólo incluye un único identificador, a saber, la identidad 104 del distribuidor del certificado. Esta identidad 104 también identifica la clave pública 111. De este modo, puede definirse un certificado raíz como un certificado en el que el nombre del expedidor es el mismo que el nombre del argumento.

Como el certificado raíz es el certificado final en la cadena formada por el certificado de emisor 90 -certificado CA 100- certificado raíz 110, el certificado raíz está auto-firmado, es decir, que el valor de firma se calcula utilizando la clave privada equivalente a la clave pública 111. Por lo tanto, es muy importante que no se hagan públicos los contenidos de un certificado raíz.

Por supuesto, es posible que el RCA facilite directamente los certificados de emisor 90 al fabricante del decodificador, en cuyo caso el certificado de emisor contendrá el identificador RCA 111 e irá firmado utilizando la clave privada RCA.

Lista de revocación de certificados

Cualquiera de los certificados de emisor 90 y de los certificados CA 100 puede ser revocado, por ejemplo, mediante borrado, con anterioridad a la finalización del período de validez especificado en ellos sí, por ejemplo, se ha puesto en peligro una clave privada correspondiente a la clave pública almacenada en el certificado. Dicha revocación puede efectuarse mediante la transmisión al decodificador de una lista de revocación de certificados (CRL) que contenga una lista de los números de serie 92, 102 de los certificados que van a revocarse. Cuando se efectúa la revocación, el certificado deja de ser utilizable, lo que impide la descarga de cualquier paquete de datos no autorizado, y posiblemente malicioso, que haya sido generado utilizando la clave privada en peligro.

Las CRLs son distribuidas mediante una CA o RCA al emisor, que transmite las CRLs a los decodificadores bien mediante el canal de retorno de módem o mediante la emisión de las CRLs a través del flujo de transporte MPEG. No es esencial que el emisor inserte las CRLs en todos los flujos de transporte enviados desde el emisor al decodificador; es suficiente que el emisor inserte los CRLs en los flujos de transporte que es muy probable que vayan a ser sintonizados por los decodificadores. Por ejemplo, puede insertarse una CRL como un archivo de datos en un directorio raíz 75 o subdirectorio 76 de un conjunto de archivos de datos emitidos desde el transmisor al decodificador.

En relación con la figura 9, una CRL 120 normalmente incluye:

\bullet

La identidad 94 o 104 de la CA o de la RCA que distribuyó la CRL 120;

\bullet

La fecha 122 en la cual se expidió la CRL 120;

\bullet

La fecha 124 en la cual se espera que se expida la siguiente CRL;

\bullet

Una lista 125 de los números de serie de los certificados que van a revocarse, incluyendo para cada certificado revocado la fecha y la hora de la revocación de dicho certificado; y

\bullet

Un valor de firma 126 de la CRL, calculado utilizando la clave privada de la CA o RCA que distribuyó la CRL 120.

Al recibirse una CRL, el decodificador compara la fecha 122 en la que se expidió la CRL 120 con la fecha 124 en la cual se esperaba dicha CRL 120, de acuerdo con lo notificado por la CRL anteriormente recibida. Si la fecha 122 de la CRL recién recibida no es posterior a la fecha 124 en la cual se esperaba dicha CRL, se ignora la CRL.

Si la fecha 122 de la CRL recibida recientemente es posterior a la fecha 124 en la que se esperaba la CRL, se verificará la firma de la CRL utilizando la clave pública del emisor de la CA identificado mediante la identidad 94 o 104 contenida en la CRL.

Si se verifica de este modo la integridad de la CRL, la CRL se procesará para añadir la fecha 124 a fin de almacenar en la memoria permanente la fecha 124 en la cual se espera la expedición de la siguiente CRL, y para almacenar la lista 125 de los números de serie de los certificados revocados. La lista recibida 125 de certificados revocados se almacena también en la memoria permanente del decodificador. Por motivos de rendimiento, se prefiere que la CRL 120 permanezca en la memoria caché del decodificador. También se prefiere que la memoria caché del decodificador almacene las CLRs 120 de forma arborescente, estando situada la CRL de la RCA en la parte superior del árbol y las CRLs de las CAs a las cuales distribuye certificados la RCA en la parte inferior del árbol.

En el caso de una revocación de un certificado de emisor 90, por ejemplo, si la clave privada del emisor estuviese en peligro, la Autoridad de Certificación de dicho emisor añadirá el número de serie 93 del certificado del emisor 90 a su CRL 120. La Autoridad de Certificación distribuye posteriormente la nueva CRL 120 a todos los emisores a los cuales distribuye certificados de emisor 90 para su transmisión. Tan pronto como el decodificador ha descargado las nuevas CRL 120, por ejemplo, cuando se zapea por el canal de un emisor, se actualiza la CRL de la caché y se lleva a cabo la revocación de cualesquiera certificados identificados como tales en la lista 125 de la CRL 120.

Los certificados de emisor de sustitución 90 son generados por la Autoridad de Certificación 100 y transmitidos al usuario en un directorio 75 o 76 de un archivo. El certificado de emisor de sustitución incluirá, entre otras cosas, una nueva clave pública 91, un número de versión actualizado 92, un período de validez actualizado 95, y un nuevo valor de firma 96 calculado utilizando la clave privada de la CA. El identificador del emisor 80 y el identificador de la CA 94 permanecerán sin cambios. Al recibir el certificado de emisor de sustitución 90, el decodificador verifica el certificado procesándolo mediante la correspondiente clave pública CA contenida en el certificado CA identificado por la identidad CA 94.

Al revocar un certificado CA 100, se elimina la CRL de dicha CA de la memoria del decodificador. Por lo tanto, podría ser deseable revocar voluntariamente un certificado CA 100 si, por ejemplo, el tamaño de la CRL de dicha CA es demasiado largo para su almacenamiento en la memoria caché del decodificador. En este caso, la RCA que distribuye el certificado CA 100 a dicha CA añadirá el número de serie 103 de dicho certificado CA 100 a su CRL. La Autoridad de Certificación Raíz distribuye posteriormente la nueva CRL a todos los emisores a los cuales las CAs a las que distribuye certificados CA dicha RCA distribuyen a su vez certificados de emisor para la transmisión. Tan pronto como un decodificador ha descargado la nueva CRL, por ejemplo, al zapear por el canal de un emisor, se actualiza la CRL caché y se efectúa la revocación de los certificados CA identificados como tales en la lista 125 de la CRL 120.

Al producirse la revocación de un certificado CA 100 de una Autoridad de Certificación, además del almacenamiento de un nuevo certificado CA para dicha Autoridad de Certificación en el decodificador, es necesario sustituir los certificados de emisor 90 para todos los emisores entre los que dicha Autoridad de Certificación distribuye certificados ya que, al haber dejado de ser válido el par de claves privadas correspondiente a dicha Autoridad de Certificación, serán necesarios nuevos certificados de emisor 90, firmados mediante una clave privada diferente o actualizada de la Autoridad de Certificación. La Autoridad de Certificación Raíz 110 genera un certificado CA 100 de sustitución y lo envía al usuario en un directorio 75 o 76 de un archivo. Al igual que un certificado de emisor de sustitución, el certificado CA de sustitución incluirá, entre otras cosas, una nueva clave pública CA 101, un número de versión actualizado 102, un período de validez actualizado 105 y un nuevo valor de firma 106 calculado utilizando la clave privada de la RCA. El identificador CA 94 y el identificador RCA 104 permanecerán sin cambios. Al recibir el certificado CA de sustitución 100, el decodificador verifica el certificado, procesándolo mediante la correspondiente clave pública RCA contenida en el certificado RCA 110 identificado por la identidad RCA 104.

Mensaje de Gestión del Certificado Raíz

Al revocar un certificado RCA 110 de una Autoridad de Certificación Raíz, es necesario sustituir el certificado RCA revocado con una nueva RCA. Como se ha descrito anteriormente, los certificados RCA van autofirmados y, por lo tanto, no es deseable la inclusión de un certificado RCA en una CRL, ya que es posible que un pirata informático entre en posesión del certificado si conoce la clave privada utilizada para firmar la CRL. Por lo tanto, hasta ahora ha sido necesario devolver el decodificador al fabricante cada vez que debía actualizarse un certificado RCA, por ejemplo cuando había caducado o se había revocado.

Para superar este problema, la Autoridad de Certificación Raíz genera un Mensaje de Gestión de Certificados Raíz (RCMM) para su transmisión a los decodificadores a través de los emisores. Como se explica en más detalle más adelante, un RCMM, al igual que una CRL, contiene una lista 125 de los números de serie de los certificados raíz que van a revocarse, incluyendo para cada certificado raíz revocado la fecha y la hora de revocación de dicho certificado, junto con uno o más certificados raíz de sustitución correspondientes a aquellos certificados que han caducado o se encuentran identificados en la lista 125.

Como podrá comprobarse, debido a la sensibilidad del contenido (nuevos certificados raíz) del RCMM, es muy importante garantizar que el decodificador recibe un RCMM según ha sido emitido al emisor, es decir asegurarse de que los contenidos del RCMM no han cambiado entre su distribución y su recepción. También es importante asegurarse de que sólo pueden acceder al RCMM los decodificadores a los cuales se dirige el RCMM.

A fin de mejorar la seguridad, un RCMM, a diferencia de una CRL, contiene al menos dos valores de firma para al menos una parte, y preferiblemente la totalidad, de los datos incluidos en él. Cada valor de firma se calcula utilizando una clave de un respectivo algoritmo de cifrado, como una clave privada de una pareja de claves pública/privada.

Cuando una Autoridad de Certificación Raíz (RCA) expide un RCMM e incluye un nuevo certificado raíz 110, el RCMM incluye al menos dos valores de firma. Cada valor de firma se calcula utilizando la respectiva clave privada de, por ejemplo, una Autoridad de Certificación a la cual suministra certificados la RCA (aunque puede seleccionarse cualquier clave para la cual el decodificador almacena una clave equivalente). Si, inadvertidamente para una de dichas Autoridades de Certificación, su clave privada se encontrase en peligro, podría ser posible que un pirata informático interceptase la transmisión del emisor y, en caso de conocer las claves privadas del emisor y de la Autoridad de Certificación, cambiase el contenido del RCMM y el valor de la firma del RCMM calculado utilizando la clave privada de la Autoridad de Certificación. No obstante, al pirata informático no le será posible cambiar el valor de la firma calculada utilizando la clave privada de la otra Autoridad de Certificación, ya que esta clave no se encuentra en peligro. Por lo tanto, cuando el decodificador verifica las firmas utilizando las claves públicas de las dos Autoridades de Certificación, los dos valores calculados por el decodificador utilizando las respectivas claves públicas no serán los mismos. Por lo tanto, se alertará al decodificador sobre la falta de integridad del contenido del RCMM y se rechazará o no se seguirá procesando el RCMM.

En consecuencia, los certificados raíz pueden actualizarse con seguridad, siempre que el número de certificados en peligro sea inferior al número de firmas que contiene el RCMM. Por tanto, el número de firmas del RCMM es una variable determinada por la Autoridad de Certificación Raíz que distribuye los RCMMs.

A continuación se describirá en más detalle el formato de un RCMM haciendo referencia a la figura 10.

El RCMM 130 incluye:

\bullet

La identidad 132 de la RCA que distribuyó el RCMM 130;

\bullet

La fecha 134 en la cual se expidió el RCMM 130;

\bullet

El número 136 de valores de firma que contiene el siguiente RCMM;

\bullet

Un campo 138 que contenga uno o más certificados raíz actualizados o de sustitución para su almacenamiento en el decodificador;

\bullet

Una lista 140 con los números de serie de los certificados raíz que van a revocarse, incluyendo para cada certificado raíz revocado la fecha y la hora de la revocación de dicho certificado; y

\bullet

Al menos dos campos de firma 142, conteniendo cada uno de ellos

Un identificador 144 del certificado almacenado en el decodificador que contiene la clave pública que va a utilizarse para verificar el valor de firma contenido en dicho campo de firma; y

Un valor de firma 146 del RCMM, calculado utilizando la clave privada equivalente a la clave pública contenida en el certificado identificado mediante el identificador 144.

\newpage

El número de campos de firma 142 debería ser igual o superior al número 136 de campos de firma indicados en el RCMM recibido anteriormente.

Es preferible que los RCMMs se transmitan a través del flujo de transporte MPEG, dado que el canal de retorno del módem puede desconectarse con facilidad o puede simplemente no estar presente. También se prefiere que los RCMMs sean insertados por el emisor como un archivo de datos en un directorio raíz 75 a fin de asegurar que el RCMM ha sido descargado por el decodificador.

Procesamiento y Generación de Mensajes de Gestión de Certificados Raíz

A continuación se describirá la recepción y el procesamiento de un RCMM por un decodificador haciendo referencia a la figura 11.

Al recibir un RCMM en la etapa 200, el decodificador compara la fecha 134 en la cual se expidió dicho RCMM 130 con la fecha de expedición del RCMM anterior. Si la fecha 134 del RCMM recibido recientemente no es posterior a la fecha en la cual se expidió el RCMM anterior, se rechaza el RCMM.

Si la fecha 134 del RCMM recientemente recibido es posterior a la fecha de recepción del RCMM anterior, el número 136 de valores de firma que debe contener el RCMM recibido recientemente, de acuerdo con lo notificado por el RCMM recibido anteriormente, se compara en la etapa 202 con el número de valores de firma realmente contenidos en el RCMM recibido recientemente. Si el número de firmas contenidas en el RCMM recibido recientemente es inferior al esperado, se rechaza el RCMM. De este modo se puede impedir que se procese un RCMM como resultado de la eliminación por parte de un pirata informático de las firmas asociadas a pares de claves privada/pública que no se encuentren en peligro.

Si el número de firmas contenidos en el RCMM recientemente recibido es igual o superior al número de firmas esperado, en la etapa 204 cada valor de firma 146 contenido en el RCMM se verifica utilizando la clave pública identificada por el identificador 144 contenido en el mismo campo de firma 142 como dicho valor de firma. En la etapa 206, el decodificador determina si al menos uno de los valores calculados utilizando una clave pública es diferente de cualquiera de los otros valores calculados utilizando una clave pública diferente. Si al menos un valor calculado es diferente de al menos uno de los otros valores calculados, se rechaza el RCMM.

Si la integridad del RCMM ha quedado demostrada en la etapa 206, el RCMM se procesa en la etapa 208 para almacenar la lista 140 de los números de serie de los certificados raíz revocados en la memoria permanente del decodificador en la etapa 212 para almacenar cada uno de los certificados raíz contenidos en el campo 138 en la memoria permanente del decodificador y en la etapa 212 para almacenar en la memoria permanente la fecha 134 del RCMM. Si se borra un certificado de una Autoridad de Certificación Raíz, también se borrarán cualesquiera CRLs expedidas por dicha Autoridad.

Es preferible que se mantenga la integridad del almacenamiento permanente de los datos contenidos en el RCMM si el decodificador se desconecta durante el procesamiento del mensaje RCMM. Por lo tanto, si se desconecta la alimentación durante el procesamiento del RCMM, la lista 140 asociada al RCMM anteriormente procesado que está almacenado en el decodificador se conserva como si no se hubiese procesado el mensaje RCMM recientemente recibido.

Como se ha mencionado anteriormente, una Autoridad de Certificación Raíz (RCA) tiene normalmente, al menos, dos certificados RCA, RC0 y RC1, almacenados en cada decodificador. En el caso de que uno de estos certificados, por ejemplo RC0, pase a estar en peligro, será necesario sustituir todos los certificados CA almacenados en el decodificador que hayan sido firmados utilizando la clave privada equivalente a la clave pública almacenada en RC0, y generar un nuevo certificado RCA RC2 que sustituya a RC0.

Haciendo referencia a la figura 12, para sustituir estos certificados CA, en primer lugar en la etapa 300 la RCA expide un mensaje CRL adecuado en el que se identifican los números de serie de los certificados CA que van a revocarse. En segundo lugar, en la etapa 302, los certificados CA de sustitución firmados utilizando la clave privada del certificado RC1 que no se encuentra en peligro, son transmitidos al emisor para su transmisión al decodificador.

Sólo falta borrar el certificado RCA RC0 que se encuentra en peligro y sustituir dicho certificado por un nuevo certificado RCA RC2. En la etapa 304, la RCA genera una nueva pareja de claves pública/privada, inserta la nueva clave pública en el certificado RC2 y firma el certificado utilizando la nueva clave privada.

En la etapa 306, la RCA genera un RCMM que contiene, en el campo 138, un certificado RC2 y, en la lista 140, el número de serie de RC0. El RCMM se distribuye entre los emisores para su transmisión, en la etapa 308, a los decodificadores, para borrar el certificado RC0 que se encuentra en peligro y sustituirlo por el nuevo certificado RC2.

Los certificados RCA RC1 y RC2 se suministrarán posteriormente al fabricante del decodificador para su codificación mediante hardware en la memoria de los nuevos decodificadores.

\newpage

Se entenderá que la presente invención se ha descrito anteriormente tan sólo a modo de ejemplo y que pueden introducirse modificaciones de detalle dentro del ámbito de la invención.

Por ejemplo, el RCMM puede incluir, además de los nuevos certificados RCA 110, nuevos certificados CA 100 y/o nuevos certificados de emisor 90, y la lista 140 puede incluir identificadores de certificados CA y/o certificados de emisor que deben revocarse. Esto puede permitir obviar la generación de mensajes independientes CRL por parte de una RCA.

Todas las características recogidas en la descripción, y (en su caso) las reivindicaciones y figuras pueden facilitarse independientemente o en cualquier combinación adecuada.

Claims (10)

1. Método de autentificación de datos (46,60) transmitidos mediante un sistema de transmisión digital (1), caracterizado porque dicho método incluye las siguientes etapas anteriores a la transmisión:

determinación de, al menos, dos valores cifrados (146) para al menos una parte de los datos, determinándose cada valor cifrado para los mismos datos utilizando una clave de un respectivo algoritmo de cifrado; y

salida de al menos dichos dos valores cifrados con dichos datos.

2. Método de acuerdo con la reivindicación 1, en el que dichos datos incluyen una clave (91, 101, 111).

3. Método de acuerdo con la reivindicación 2, en el que dichos datos incluyen, al menos, un certificado digital (90, 100, 110) que contiene una clave pública (91, 101, 111) de un algoritmo de cifrado para procesamiento de datos.

4. Método de acuerdo con la reivindicación 3, en el que dichos datos incluyen al menos un certificado raíz digital (110) que contiene una clave pública (111) de un algoritmo de cifrado para procesamiento de datos.

5. Método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dichos datos incluyen un identificador (94, 104) de una clave pública revocada.

6. Método de acuerdo con la reivindicación 5, en el que dicho identificador incluye un identificador de un certificado digital que contiene dicha clave pública revocada.

7. Método de acuerdo con la reivindicación 6, en el que dicho identificador incluye un identificador de un certificado raíz digital que contiene dicha clave pública revocada.

8. Método de autentificación de los datos transmitidos en un sistema de transmisión digital, caracterizado porque dicho método incluye las etapas de:

recepción de dichos datos y de, al menos, dos valores cifrados determinados para, al menos, una parte de los datos, estando determinado cada valor cifrado para los mismos datos utilizando una clave de un algoritmo de cifrado respectivo;

almacenamiento de una pluralidad de claves;

procesamiento (204) de cada valor cifrado utilizando una clave almacenada de dicho algoritmo de cifrado respectivo; y

comparación (206) de cada valor resultante subsiguiente con al menos dicha parte de datos para autentificar al menos dicha parte de datos.

9. Aparato para autentificación de datos a transmitir mediante un sistema de transmisión digital, caracterizado porque dicho aparato comprende:

medios para determinar al menos dos valores cifrados para al menos una parte de los datos, determinándose cada valor cifrado para los mismos datos utilizando una clave de un algoritmo de cifrado respectivo; y

medios para la salida de al menos dichos dos valores cifrados con dichos datos.

10. Receptor/decodificador (13) que incluye:

medios (20) para almacenar una pluralidad de claves, estando caracterizado dicho receptor/decodificador porque adicionalmente incluye:

medios (31, 32, 30, 20) para la recepción de un archivo de datos que incluye datos y al menos dos valores cifrados determinados para al menos una parte de los datos, siendo determinado cada valor cifrado para los mismos datos utilizando una clave de un algoritmo de cifrado respectivo;

medios (20) para procesar cada valor cifrado utilizando una clave almacenada de dicho algoritmo de cifrado respectivo; y

medios (20) para comparar cada valor resultante subsiguiente al menos con dicha parte de los datos para autentificar al menos dicha parte de los datos.