MÉTODO Y APARATO PARA DISTRIBUCIÓN Y SINCRONIZACIÓN DE INFORMACIÓN DE CONTEXTO CRIPTOGRÁFICO" CAMPO DE LA INVENCIÓN La presente invención se refiere a sistemas y métodos para la distribución segura de contenido y, más particularmente, a un método y aparato para la distribución y sincronización de información de contexto criptográfico en un sistema de distribución de video.
ANTECEDENTES DE LA INVENCIÓN Actualmente, los proveedores de programación desean la capacidad de suministrar contenido digital a dispositivos móviles portátiles, tales como teléfonos celulares, asistentes digitales personales (PDAs -personal digital assistants) , y lo similar, de manera eficaz. Una manera de distribuir el contenido digital a dispositivos portátiles es el sistema de transmisión de Emisión de Video Digital (DVB - digital video broadcasting) para terminales portátiles (DVB-H - DVB-handheld) , publicada por el Instituto Europeo de Normas de Telecomunicaciones (ETSI -European Telecommunications Standards Institute) . El sistema de DVB-H se basa en el sistema de DVB terrestre (DVB-T - DVB-terrestrial) para la recepción fija de contenido digital. El sistema de DVB-H es un sistema de
emisión de punto a punto para el envío de cualquier tipo de contenido digital utilizando mecanismos basados en el Protocolo de Internet (IP - Internet Protocol) optimizados para dispositivos con limitaciones de recursos computacionales y batería (por ejemplo, dispositivos móviles portátiles) . La norma DVB-H proporciona administración de derechos digitales (DRM - digital rights management) , donde un conjunto de métodos que asegura que un dispositivo de usuario solamente puede utilizar contenido particular cuando se han cumplido las condiciones relevantes (por ejemplo, condiciones de acceso) . El contenido se cifra por un algoritmo de cifrado simétrico utilizando una clave. Los mensajes de control de autorizaciones (ECMs entitlement control messages) se generan para transmitir con seguridad datos de contexto criptográfico a los dispositivos. Los datos de contexto criptográfico incluyen las claves utilizadas para cifrar el flujo de medios, así como también otra información necesaria para descifrar y recuperar el contenido en los dispositivos. Sin embargo, la norma DVB-H no define una implementación para generar y distribuir los ECMs. En particular, la norma DVB-H no define cómo obtiene los datos de contexto criptográfico la unidad funcional que genera los ECMs. La norma DVB-H tampoco define cómo se sincronizan los datos de contexto
criptográfico con el contenido cifrado. De acuerdo con lo anterior, existe la necesidad en la materia de un método y aparato o para distribución y sincronización de información de contexto criptográfico en un sistema de DVB-H.
BREVE DESCRIPCIÓN DE LA INVENCIÓN Se describe el método y aparato para distribución y sincronización de información de contexto criptográfico. Un aspecto de la invención se refiere a sincronizar un cifrador y una lógica de administración de claves en un sistema de distribución de video. Un mensaje de solicitud he recibido proveniente del cifrador. El mensaje de solicitud incluye datos de autenticación y parámetros dependientes del flujo asociados con un flujo de paquetes de protocolo de internet (IP) a cifrarse. La autenticidad del cifrador se verifica utilizando los datos de autenticación. Un contexto criptográfico para el flujo de paquetes de IP se genera teniendo los parámetros dependientes del flujo y al menos una clave de cifrado. Los mensajes de flujo de claves que tienen el contexto criptográfico se distribuyen hacia los dispositivos de usuario. Los dispositivos de usuario se encuentran recibiendo una versión cifrada del flujo de paquetes de IP generado por el cifrador.
BREVE DESCRIPCIÓN DE LOS DIBUJOS Así que la manera en la cual las características de la presente invención descritas con anterioridad pueden comprenderse detalladamente, puede brindarse una descripción más particular de la invención, para referencia a las modalidades, algunas de las cuales se ilustran en los dibujos anexos. Sin embargo, debe observarse que los dibujos anexos solamente ilustrada modalidades típicas de la invención y, por lo tanto, no deben considerarse limitantes de su alcance para que la invención puede admitir otras modalidades igualmente efectivas. La Figura 1 es un diagrama de bloques que representa gráficamente una modalidad a manera de ejemplo de un sistema de distribución de contenido de acuerdo con uno o más aspectos de la invención; La Figura 2 es un diagrama de bloques que representa gráficamente una modalidad a manera de ejemplo del sistema de protección de contenido de acuerdo con uno o más aspectos de la invención; La Figura 3 es un diagrama de flujo que representa gráficamente una modalidad a manera de ejemplo de un método para sincronizar un contenido criptográfico con un flujo de paquetes de IP a cifrarse de acuerdo con uno o más aspectos de la invención; La Figura 4 es un diagrama de bloques que
representa gráficamente una modalidad a manera de ejemplo de una computadora para implementar los procesos y métodos descritos en la presente de acuerdo con uno o más aspectos de la invención; La Figura 5 es un diagrama de flujo que representa gráficamente una modalidad a manera de ejemplo de una secuencia de mensajes entre un cifrador en tiempo real (RTE- real-time encryptor) y un generador de mensajes de control de autorizaciones (ECM) de acuerdo con uno o más aspectos de la invención; y La Figura 6 es un diagrama de flujo que representa gráficamente una modalidad a manera de ejemplo de una secuencia de mensajes entre un generador de ECM, un almacenamiento de claves, y un RTE de acuerdo con uno o más aspectos de la invención. A fin de facilitar la comprensión, se han utilizado números de referencia idénticos, donde es posible designar elementos idénticos que son comunes a las figuras.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La Figura 1 es un diagrama de bloques que representa gráficamente una modalidad a manera de ejemplo de un sistema de distribución de contenido 100 de acuerdo con uno o más aspectos de la invención. El sistema de distribución de contenido 100 incluye un segmento de
difusión de contenido 102, un segmento de procesamiento de emisión de video digital portátil (DVB-H) 104, un segmento de protección de contenido 106, y un segmento de DVB terrestre (DVB-T) 108. El segmento de difusión de contenido 102 se encuentra configurado para recibir flujos de contenido. Los flujos de contenido pueden comprender flujos de video codificados y formateados de acuerdo con cualquier norma de compresión de vídeo digital conocida, tal como MPEG-2 (Moving Pictures Experts Group - Grupo de Expertos de Imágenes en Movimiento), H.264 (también conocida como codificación de video avanzado (AVC advanced video coding) y MPEG-4, parte 10), y lo similar. El vídeo, como se utiliza en la presente, puede incluir opcionalmente audio y/o información asociada de control de presentación de audio/video y/o datos del usuario. El segmento de difusión de contenido 102 incluye una pluralidad decodificadores de flujo 110. Los codificadores de flujo 110 se encuentran configurados para convertir los flujos de contenido en flujos de paquetes de protocolo de internet (IP) . El segmento de difusión de contenido 102 le proporciona los flujos de paquetes de IP al segmento de procesamiento de DVB-H 104. El segmento de procesamiento de DVB-H 104 incluye encapsuladores de IP 112, los cuales operan en cooperación con el segmento de protección de contenido 106. El segmento de protección de
contenido 106 se encuentra configurado para cifrar los flujos de paquetes de IP y proporcionar flujos para transportar claves de cifrado, autorizaciones, derechos de acceso, y lo similar. El segmento de protección de contenido 106 incluye lógica de administración de claves 107 para generar con seguridad, administrar, y distribuir las claves de cifrado. Los encapsuladores de IP 112 se encuentran configurados para crear flujos de transporte de DVB-H provenientes de los flujos de paquetes de IP cifrados y los flujos presentados por el segmento de protección de contenido 106. Como se conoce en la materia, los flujos de transporte de DVB-H incluyen paquetes de flujo de transporte de MPEG-2 que encapsular los paquetes de IP. Los detalles de encapsulación de IP de DVB-H son bien conocidos en la materia y pueden encontrarse en la especificación EN 302 304 del Instituto Europeo de Normas de Telecomunicaciones (ETSI) "Difusión de Video Digital (DVB) ; Sistema de Transmisión para Terminales Portátiles (DVB-H)" ("Digital Video Broadcasting (DVB); Transmission System for Handheld Termináis (DVB-H)"), VI.1.1, Noviembre de 2004. Los flujos de transporte de DVB-H se proporcionan al segmento de DVB-T 108 (DVB terrestre) . El segmento de DVB-T 108 incluye un modulador 114. El modulador 114 se encuentra configurado para modular los flujos de transporte
de DVB-H para la transmisión a los dispositivos de usuario 118. Los dispositivos de usuario 118 se encuentran configurados para recibir señales de DVB-T, analizar los flujos de transporte de DVB-H, y descifrar y convertir los flujos de paquetes de IP para que el usuario visualice el contenido. Los detalles de la modulación y transmisión de DVB-T son conocidos en la materia y pueden encontrarse en la especificación EN 300 744 del ETSI "Difusión de Video Digital (DVB) ; estructura de tramas, codificación de canal y modulación para televisión terrestre digital" ("Digital Video Broadcasting (DVB) ; Framing structure, channel coding and modulation for digital terrestrial televisión" , V.1.5.1, Noviembre de 2004). La Figura 2 es un diagrama de bloques que representa gráficamente una modalidad a manera de ejemplo del sistema de protección de contenido 106 de acuerdo con uno o más aspectos de la invención. El sistema de protección de contenido 106 incluye un emisor de derechos 202, un cifrador en tiempo real (RTE) 204, un generador de mensajes de control de autorizaciones (ECM) 206, un generador de claves de servicio 208, un centro de distribución de claves (KDC - key distribution center) 210, y un almacenamiento de claves 212. El emisor de derechos 202, el RTE 204, el generador de ECMs 206, el almacenamiento de claves 212 y el generador de claves de
servicio 208 incluyen agentes de administración de derechos digitales (DR - digital rights management) 214, 216, 218, 219, y 220, respectivamente. Los agentes de DRM 214 a 220 se implementen colectivamente la lógica de administración de claves 107 del sistema de protección de contenido 106. El emisor de derechos 202, el RET 204, el generador de ECM 206, el generador de claves de servicio 208, el KDC 210, y el almacenamiento de claves 212 se acoplan, cada uno de ellos, a una red 250 (por ejemplo, una red de IP) para la comunicación entre ellos. Para propósitos de claridad del ejemplo, únicamente se muestra un solo RTE 204, un solo generador de ECMs 206, un solo generador de claves de servicio 208, un solo KDC, y un solo almacenamiento de claves 212. Debe comprenderse que el sistema de protección de contenido 106 generalmente puede incluir al menos uno de cada uno de los componentes. Por ejemplo, el sistema de protección de contenido 106 incluye una pluralidad de RTEs para cifrar una pluralidad respectiva de flujos de IP. El RTE 204 se encuentra configurado para recibir al menos un flujo de paquetes de IP. El RTE 204 cifra cada flujo de paquetes de IP utilizando un algoritmo de cifrado simétrico, tal como el algoritmo de la norma de cifrado avanzado (AES - advanced encryption standard) , el algoritmo de la norma de triple cifrado de datos (3DES - triple data encryption standard), o lo similar. La clave utilizada
para cifrar en flujo de paquetes de IP es referir en la presente como la clave de cifrado de tráfico (TEK - traffic encryption key) . La TEK puede utilizarse para cifrar directamente el flujo de paquetes de IP (es decir, la TEK es aplicada directamente por el algoritmo de cifrado) . Alternativamente, la TEK puede ser una clave maestra a partir de la cual se derivan una o más claves, utilizándose tal (es) clave (s) para cifrar el flujo de paquetes de IP. La(s) clave (s) puede (n) derivarse a partir de la TEK de manera criptográficamente segura utilizando una función de derivación de claves. El cifrado puede realizarse en la capa de enlace, la capa de sesión, o la capa de contenido. En una modalidad, el cifrado se realiza en la capa de sesión de acuerdo con el protocolo de transporte seguro en tiempo real (SRTP - secure real-time protocol) , como se describe a continuación. El RTE 204 obtiene la TEK proveniente del generador de ECMs 206. En una modalidad, el RTE 204 establece una sesión segura con el generador de ECMs 206. Durante la sesión segura, el RTE 204 y el generador de ECMs 206 se autentican mutuamente y los mensajes intercambiados entre ellos pueden asegurarse. Como se utiliza en la presente, "autenticación" es la verificación criptográfica de las identidades de los elementos de comunicación. La "seguridad" es la protección criptográfica (cifrado)
aplicada a la información intercambiada entre los elementos de comunicación. El establecimiento de la sesión segura se facilita por los agentes de DR 216 y 218 del RTE 204 y el generador de ECMs 206, respectivamente. A continuación se describen las modalidades a manera de ejemplo para implementar sesión aseguras. A fin de obtener una TEK, el RTE 204 le envía un mensaje de solicitud de clave al generador de ECMs 206. El RTE 204 recibe un mensaje de respuesta de clave proveniente del generador de ECMs 206. El mensaje de respuesta de clave incluye al menos una TEK para cifrar el flujo de paquetes de IP. En una modalidad, se configura una TEK para expirar. Después de la expiración de cada TEK, el RTE 204 envía otro mensaje de solicitud de clave y recibe otro mensaje de respuesta de clave que tiene una TEK válida. El RTE 204 entrega como salida flujo(s) de paquete de IP cifrados . El generador de ECMs 206 se configura para procesar mensajes de solicitud de claves provenientes del RTE 204. Para un mensaje de solicitud de claves determinado, el generador de ECMs 206 genera un contexto criptográfico que incluye al menos una TEK para cifrar el flujo de paquetes de IP. El contexto criptográfico incluye otros diversos parámetros que son requeridos en el dispositivo de usuario para descifrar el flujo de paquetes
de IP cifrado. Tales parámetros dependen del protocolo particular empleado por el RTE 204. Algunos o todos estos parámetros pueden depender del flujo de paquetes de IP en particular que estén siendo cifrados ("parámetros dependientes del flujo"). A continuación se describen los parámetros dependientes del flujo a manera de ejemplo para SRTP. El RTE 204 le proporciona los parámetros dependientes del flujo al generador de ECMs 206 en el mensaje de solicitud de claves. De esta manera, el contexto criptográfico se sincroniza con el flujo de paquetes de IP a cifrarse. A continuación se describe un contexto criptográfico a manera de ejemplo para SRTP. El generador de ECMs 206 transmite la TEK al RTE 204 en el mensaje de respuesta de clave. El generador de ECMs 206 también se encuentra configurado para formar mensajes de flujo de claves (ECMs) para su uso por las terminales de usuario a fin de reconstruir las TEKs para descifrar el contenido en los flujos de paquetes de IP cifrado. Para cada flujo de paquetes de IP cifrados entregado como salida por el RTE 204, el generador de ECMs 206 genera una secuencia de ECMs cada una de las cuales tiene el contexto criptográfico asociado. Al menos la porción de cada ECM que lleva una TEK se cifra utilizando un algoritmo de cifrado simétrico, tal como la AES, 3DES, o algún algoritmo similar. La clave utilizada en el
algoritmo para cifrar la TEK es referida como la clave de cifrado de servicio (SEK) . El generador de ECMs 206 obtiene la SEK a partir del almacenamiento de claves 212. En una modalidad, el generador de ECMs 206 establece una sesión segura con el almacenamiento de claves 212. El generador de ECMs 206 y el almacenamiento de claves 212 se autentican mutuamente y los mensajes intercambiados entre ellos pueden asegurarse. El establecimiento de la sesión segura se facilita por los agentes de DRM 218 y 219 del generador de ECMs 206 y el almacenamiento de claves 212, respectivamente. A fin de obtener una SEK, el generador de ECMs 206 envía un mensaje de solicitud de clave al almacenamiento de claves 212. El generador de ECMs 206 recibe un mensaje de respuesta de clave proveniente del almacenamiento de claves 212 que incluye una SEK o información a partir de la cual puede derivarse la SEK (referida como subclave de servicio) . En una modalidad, una SEK (o su clave de servicios) se encuentra configurada para expirar. Después de la expiración de cada SEK (o su clave de servicio) , el generador de ECMs 206 envía otro mensaje de solicitud de clave y recibe otro mensaje de respuesta de clave que tiene una SEK fresca (o su clave de servicio) . El generador de ECMs 206 entrar como salida un flujo de ECMs. El emisor de derechos 202 se encuentra
configurado para formar mensajes de administración de derechos y autorizaciones (EMMs - entitlement management messages) . Los EMMs incluyen derechos de acceso de contenido para su uso por los flujos de contenido particular de acceso de terminales de usuario. Típicamente, los EMMs se intercambien como resultado de una transacción de compra o suscripción por una terminal de usuario. Los derechos de acceso de contenido incluyen al menos una SEK utilizada para acceder a los ECMs para un flujo de paquetes de IP. Los derechos de acceso de contenido también pueden incluir autorizaciones y derechos asociados con el contenido transportado por el flujo de paquetes de IP. Las autorizaciones y derechos controlan la reproducción, transferencia, copia y lo similar para el contenido. Al menos la porción de cada EMM que lleva una SEK se encuentra cifrada. La terminal o terminales de usuario que reciben los EMMs son abastecidos con o, de otra manera, obtienen la clave necesaria para descifrar la SEK. Por ejemplo, la SEK puede cifrarse utilizando un algoritmo de cifrado asimétrico (clave pública) , tal como SA, criptografía de curva elíptica (ECC - elliptic curve cryptography) , y lo similar. El emisor de derechos 202 obtiene SEKs a partir del almacenamiento de claves 212. En una modalidad, el emisor de derechos 202 establece una sesión segura con el
almacenamiento de claves 212. El emisor de derechos 202 y el almacenamiento de claves 212 se autentican mutuamente y los mensajes intercambiados entre ellos pueden asegurarse. El establecimiento de la sesión segura es facilitado por los agentes de DRM 214 y 219 del emisor de derechos 202 y el almacenamiento de claves 212, respectivamente. Para obtener una SEK, el emisor de derechos 202 le envía un mensaje de solicitud de clave al almacenamiento de claves 212. El emisor de derechos 202 recibe un mensaje de respuesta de clave proveniente del almacenamiento de claves 212 que incluye una SEK o información a partir de la cual puede derivarse la SEK. Si la SEK (o subclave de servicio) se configura para expirar, después de la expiración de cada SEK (o subclave de servicio) , el emisor de derechos 202 envía otro mensaje de solicitud de clave y recibe otro mensaje de respuesta de clave que tiene una SEK válida (o subclave de servicio) . El emisor de derechos 202 entrega como salida un flujo de EMM. El generador de claves de servicio 208 se encuentra configurado para iniciar la generación de SEKs . En una modalidad, el generador de claves de servicio 208 establece una sesión segura con el almacenamiento de claves 212. El generador de claves de servicio 208 y el almacenamiento de claves 212 se autentican mutuamente y los mensajes intercambiados entre ellos pueden asegurarse. El
establecimiento de la sesión segura es facilitado por los agentes de DRM 220 y 219 del generador de claves de servicio 208 y el almacenamiento de claves 212, respectivamente. Para generar una SEK, el generador de claves de servicio 208 envía un mensaje de solicitud de generación de claves al almacenamiento de claves 212. El generador de claves de servicio 208 recibe un mensaje de respuesta de clave a partir del almacenamiento de claves 212 que incluye una SEK o información a partir de la cual puede derivarse la SEK. El generador de claves de servicio 208 puede configurar la SEK (o subclave de servicio) para expirar. En este caso, el generador de claves de servicio 208 repite la solicitud de generación de claves para generar una SEK válida (o subclave de servicio) . El almacenamiento de claves 212 se encuentra configurado para procesar mensajes de solicitud de clave, tales como los mensajes de solicitud de clave para las SEKs a partir de las cuales el generador de ECMs 206 y el emisor de derechos 202. El almacenamiento de claves 212 también se configura para procesar los mensajes de solicitud de generación de claves provenientes del generador de claves de servicio 208. En respuesta a un mensaje de solicitud de generación de claves, el almacenamiento de claves 212 genera aleatoriamente una SEK. Alternativamente, el almacenamiento de claves 212 puede generar aleatoriamente
una subclave de servicio que puede utilizarse para derivar una SEK. La subclave de servicio se utiliza como entrada a una función de derivación de clave, la cual produce la SEK. Los elementos que reciben la subclave de servicio (por ejemplo, el generador de ECM 206 y el emisor de derechos 202) son abastecidos con o, de alguna otra manera, han obtenido la función de derivación de clave. La función de derivación de clave puede ser una función de troceado criptográfico o una combinación de tales funciones de troceado, donde la subclave comprende al menos una porción de mensaje (s) tomados como entrada para la(s) función (es) de troceado. En cualquier caso, el almacenamiento de claves 212 almacena SEKs (o subclaves de servicio) en una base de datos 222. En respuesta a un mensaje de solicitud de clave, el almacenamiento de clave 212 transmite la SEK solicitada (o subclave de servicio) en una clave respuesta al elemento de solicitud. Como se describió con anterioridad, se establecen sesiones seguras entre el RTE 204 y el generador de EMCs 206, entre el generador de EMCs 206 y el almacenamiento de claves 212, entre el emisor de derechos 202 y el almacenamiento de claves 212, y entre el generador de claves de servicio 208 y el almacenamiento de claves 212. Las sesiones seguras se establecen mediante los intercambios de solicitud/respuesta . En general, el
intercambio de solicitud/respuesta es un intercambio de cliente/servidor, donde el solicitante es el cliente y el replicante es el servidor. En una modalidad, antes de que un servidor le proporcione una clave solicitada a un cliente, los agentes de DRM del cliente y el servidor realizan la autenticación mutua. Es decir, el servidor autentica al cliente, y el cliente autentica al servidor. La autenticación puede realizarse utilizando cualquier tipo de técnica de autenticación conocida. Por ejemplo, la autenticación puede lograrse utilizando una infraestructura de clave pública (PKI - public key infrastructure) . Un mensaje o troceo generado por el cliente se firma digitalmente por el cliente utilizando la clave privada del cliente. El servidor verifica la autenticidad del cliente utilizando la clave pública del cliente. El servidor puede obtener la clave pública del cliente a partir de un certificado digital recibido de parte del cliente, u obtenido de otra manera. La PKI es bien conocida en la materia . En otra modalidad, la autenticación es una sesión segura se logra utilizando testigos circulantes de autenticación obtenidos a partir del centro de KDC 210. Antes de que un cliente pueda autenticarse por un servidor particular, el agente de DRM del cliente debe obtener un testigo circulante de autenticación a partir del KDC 210
para ese servidor. Consecuentemente, el agente de DRM 216 del RTE 204 obtiene un testigo circulante de autenticación para el generador de EMCs 206. El agente de DRM 218 del generador de EMCs, el agente de DRM 220 del generador de claves de servicio 208, y el agente de DRM 214 del emisor de derechos 202 obtienen cada uno de ellos un testigo circulante de autenticación para el almacenamiento de claves 212. El testigo circulante de autenticación incluye información que puede utilizarse para verificar la autenticidad mutua entre un cliente y un servidor. En una modalidad, un testigo circulante de autenticación incluye una clave de sesión que se cifra utilizando una clave conocida solamente por el KDC 210 y el servidor (referido como clave de servicio) . El KDC 210 egresa una copia de la clave de sesión al agente de DRM del cliente junto con el testigo circulante de autenticación. Habiendo obtenido el testigo circulante de autenticación y la clave de sesión relacionada, el agente de DRM del cliente es capaz de establecer una sesión segura con el agente de DRM del servidor. El cliente se autentica a sí mismo con el servidor al enviarle al servidor el testigo circulante de autenticación y un troceo dividido en claves generado utilizando la clave de sesión (también referida como un valor de suma de verificación) . El troceo dividido en claves es la prueba de posesión del cliente de
la clave de sesión. A su vez, el servidor se autentica a sí mismo con un troceo dividido en claves generado a partir de la misma clave de sesión. El servidor debe poseer su clave de servicio con objeto de descifrar y extraer la clave de sesión proveniente del testigo circulante de autenticación. Consecuentemente, el troceo dividido en claves es la prueba de posesión del servidor de su clave de servicio. De esta manera, el cliente y el servidor se autentican mutuamente. El cliente puede enviarle el testigo circulante de autenticación y el valor de suma de verificación en claves al servidor en el mensaje de solicitud de clave. El servidor puede enviarle su valor de verificación en claves al cliente en el mensaje de respuesta de clave. En una modalidad, los clientes deben establecer una sesión segura con el KDC 210 para obtener los testigos circulantes de autenticación y las claves de sesión. La DR del cliente puede establecer una sesión segura con el KDC 210 utilizando una infraestructura de PKI u otro tipo de operación de clave pública, tal como ECC . Alternativamente, la DRM del cliente puede haber sido proporcionada con un testigo circulante de autenticación asociado con el KDC 210. Independientemente de la técnica de autenticación empleada, en algunas modalidades, se cifra al menos una
parte de la información transferida entre el cliente y el servidor durante una sesión segura. Al menos una porción del mensaje de solicitud de clave, y al menos una porción del mensaje de respuesta de clave, puede cifrarse utilizando la clave de sesión u otra clave o claves negociada (s) . La(s) clave(s) puede(n) negociarse utilizando cualquier algoritmo de acuerdo de claves conocido en la materia, tal como Diffie-Hellman o Diffie-Hellman de Curva Elíptica (ECDH - Elliptic Curve Diffie-Hellman) . Por ejemplo, durante una sesión segura entre el RTE 204 y el generador de EMCs, se cifra la TEK dentro de un mensaje de respuesta de clave. En otro ejemplo, durante las sesiones seguras con el almacenamiento de claves 212, se cifra la SEK (o subclave de servicio) dentro de un mensaje de respuesta de clave. Por supuesto, puede cifrarse cualquier información intercambiada entre el cliente y el servidor durante una sesión segura, incluyendo información suministrada como parte de los mensajes de solicitud de clave proveniente de los clientes. Los flujos de paquetes de IP cifrado, el flujo de
ECM, y el flujo de EMM puede proporcionarse al segmento de procesamiento de DVB-H 104 a fin de producir los flujos de transporte de DVB-H. Los flujos de ECM y EMM se proporcionan la distribución de información de contexto criptográfico a los dispositivos de usuario 118.
Notablemente, un contexto criptográfico se sincroniza con su flujo de paquetes de IP cifrados a través del establecimiento de una sesión segura entre el RTE 204 y el generador de EMC 206. A través de la sesión segura, el RTE 204 proporciona parámetros dependientes del flujo asociados con un flujo de paquetes de IP a cifrarse al generador de EMC 206. El generador de EMC 206 utiliza los parámetros dependientes de flujo a fin de establecer un contexto criptográfico, el cual incluye una TEK. El generador de EMC proporciona al menos la TEK al RTE 204 para cifrar el flujo de paquetes de IP. El generador de EMC 206 distribuye el contexto criptográfico en el flujo de ECM. La Figura 3 es un diagrama de flujo que representa gráficamente una modalidad a manera de ejemplo de un método 300 para sincronizar un contexto criptográfico con un flujo de paquetes de IP a cifrarse de acuerdo con uno o más aspectos de la invención. El método 300 comienza en el paso 302, donde el cifrador envía un mensaje de solicitud de clave al generador de ECM. El mensaje de solicitud de clave incluye datos de autenticación y parámetros dependientes de flujo asociados con un flujo de paquetes de IP a cifrarse. En el paso 304, el generador de EMC verifica la autenticidad del cifrador utilizando los datos de autenticación. Las modalidades de autenticación se describen con anterioridad. En el paso 306, el
generador de EMC genera un contexto criptográfico para el flujo de paquetes de IP que tiene los parámetros dependientes del flujo y al menos una clave de cifrado. En el paso 308, el generador de EMC le envía un mensaje de respuesta al cifrador. El mensaje de respuesta incluye la(s) clave (s) de cifrado generada (s) y opcionalmente puede incluir datos de autenticación. En el paso opcional 310, el cifrador verifica la autenticidad del generador de EMC utilizando los datos de autenticación en el mensaje de respuesta (si se incluye) . En el paso 312, el generador de EMC distribuye mensajes de flujo de clave que tienen el contexto criptográfico hacia los dispositivos de usuario. Después, el cifrador puede cifrar el flujo de paquetes de IP utilizando la(s) clave (s) de cifrado para la distribución a los dispositivos de usuario. La Figura 4 es un diagrama de bloques que representan gráficamente una modalidad a manera de ejemplo de una computadora 400 de acuerdo con uno o más aspectos de la invención. La computadora 400 cualquiera de los elementos en el segmento de protección de contenido 106, incluyendo el RTE 204, el generador de EMC 206, el generador de claves de servicio 208, el emisor de derechos 202, el almacenamiento de claves 212, y el KDC 210. Aunque tales elementos se muestran separadamente en la Figura 2, aquellos expertos en la materia observarán que pueden
implementarse uno o más de tales elementos como módulos en una sola computadora. Por ejemplo, el almacenamiento de claves 212 y el KDC 210 pueden implementarse en la misma computadora. El generador de claves de servicio 208 puede implementarse con el almacenamiento de claves 212 en la misma computadora. La computadora 400 incluye uno o más procesadores 401, una memoria 403, diversos circuitos de soporte 404, y una interfase de E/S (I/O input/output ) 402. El (los) procesador (es) 401 puede (n) ser cualquier tipo de microprocesador conocido en la materia. Los circuitos de soporte 404 para el (los) procesador (es) 401 incluyen memoria asociada convencional, suministros de energía, circuitos de reloj, registros de datos, interfases de E/S, y lo similar. La interfase de E/S 242 puede acoplarse directamente a la memoria 403 o acoplarse mediante el (los) procesador (es) 401. La interfase de E/S 402 puede acoplarse a la red 250. La memoria 403 puede incluir uno o más de entre memoria de acceso aleatorio, memoria de solo lectura, memoria de lectura/escritura magneto-resistiva, memoria de lectura/escritura óptica, memoria asociada, memoria de lectura/escritura magnéticas, y lo similar, así como también medios que soporten señales como los descritos a continuación. La memoria 403 almacena instrucciones ejecutables
por procesador y/o datos que pueden ser ejecutados por y/o utilizados por el (los) procesadores 401 como se describió detalladamente a continuación. Estas instrucciones ejecutables por procesador pueden comprender hardware, firmware, software, y lo similar, o alguna combinación de las mismas. Los módulos que tienen instrucciones ejecutables por procesador que son almacenadas en la memoria 403 incluyen al agente de DRM 412 y la aplicación 414. El agente de DRM 412 se encuentra configurado para funcionar como los agentes de DRM 214-220 descritos con anterioridad. En particular, el agente de DRM 412 se encuentra configurado para establecer secciones seguras para la autenticación mutua y la transferencia segura de mensajes, incluyendo claves de cifrado. El agente de DRM 412 también puede configurarse para administrar claves de cifrado, como se describe en las modalidades expuestas a continuación. La aplicación 414 dicta la función de la computadora 400, por ejemplo, cifrado en tiempo real, generación de EMC, emisor de derechos, generación de claves de servicio, almacenamiento de claves, y/o distribución de claves . Aunque se describen uno o más aspectos de la invención implementados como procesador (es) que ejecuta (n) un programa de software, aquellos expertos en la materia observarán que la invención puede implementarse en
hardware, software, o una combinación de hardware y software. Tales implementaciones pueden incluir un determinado número de procesadores independientemente que ejecutan diversos programas y hardware dedicado, tales como ASICs. La computadora 400 puede programarse con un sistema operativo, el cual puede ser OS/2, Máquina Virtual de Java, Linux, Solaris, Unix, Windows, Windows95, windows98, Windows NT, y Windows2000, WindowsME, y WindowsXP, entre otras plataformas conocidas. Puede colocarse al menos una porción de un sistema operativo en la memoria 403. Refiriéndose de nueva cuenta a la Figura 2, en una modalidad, el (los) flujo (s) de paquetes de IP se formatea(n) en la capa de sesión de acuerdo con el protocolo de transporte en tiempo real (RTP) ("flujos de RTP"). RTP se describe en Solicitud de Comentarios (RFC -Request for Comments) 3550, publicadas en Julio de 2003 por el Grupo de Estudio de Diseño de Internet (IETF - Internet Engineering Task Forcé) . Los flujos de paquetes de IP cifrados producidos por el RTE 204 se formatean en la capa de sesión de acuerdo con el protocolo de transporte seguro en tiempo real (SRTP) ("flujos de SRTP" ) . El SRTP se describe en RFC 3711, publicado en Marzo de 2004 por el IETF, el cual se incorpora en la presente para referencia. A fin de comprender adicionalmente la invención, se describen brevemente los aspectos del SRTP. Cada
paquete de SRTP incluye, entre otros parámetros, un número de secuencia, un identificador de fuente de sincronización (SSRC - synchronization source) , y una carga útil. Cada paquete de SRTP puede incluir opcionalmente un identificador de clave maestra (MKI - master key identifier) y una etiqueta de autenticación. La carga útil de SRTP incluye un cifrado de una carga útil de RTP. El número de secuencia del paquete de SRTP es el mismo que el paquete de RTP subyacente. Cada paquete de RTP incluye un número de secuencia que comprende 16 bits . El número de secuencia se incrementa en uno para cada paquete de RTP enviado. El SSRC identifica una fuente de sincronización de paquetes de RRTP que forman parte del mismo espacio de número de secuencia y sincronización. Se utiliza una etiqueta de autenticación para transportar datos de autenticación de mensajes para un paquete de SRTP. El MKI identifica una clave maestra a partir de la cual se deriva (n) la(s) clave (s) de sesión para cifrar los paquetes de RTP. En el SRTP, una clave de sesión es una clave utilizada directamente por un algoritmo de cifrado. Una clave maestra es una cadena aleatoria de bits a partir de la cual se derivan las claves de sesión de manera criptográficamente segura (por ejemplo, utilizando una función de derivación de claves) . Un flujo de SRTP requiere que el emisor y receptor mantengan un contexto
criptográfico. Un contexto criptográfico de SRTP incluye, entre otros parámetros, un contador giratorio (ROC rollover counter) , un número de secuencia, clave(s) maestra(s), un valor de MKI , una vida útil de clave maestra, y un identificador de contexto (ID de contexto) . El ROC registra cuántas veces se ha restablecido en cero el número de secuencia de 16 bits después de pasar 65,535. El ID de contexto único identifica el contexto criptográfico y comprende un triplete de SSRC, dirección de red destino, y número de puerto de transporte destino. La Figura 5 es un diagrama de flujo que representa gráficamente una modalidad a manera de ejemplo de una secuencia de mensajes 500 entre el RTE 204 y el generador de EC 206 de acuerdo con uno o más aspectos de la invención. El RTE 204 incluye una aplicación de RTE 550. En el paso 502, la aplicación de RTE 550 invoca al agente de DRM 216 para establecer una sesión segura con el agente de DRM 218 del generador de ECM 206. El agente de DRM 216 manejará la autenticación y seguridad para un intercambio de solicitud/respuesta de clave. La solicitud de RTE 550 le proporciona una estructura de información al agente de DRM 216 que tiene parámetros dependientes de flujo asociados con un flujo de RTP. En una modalidad, la estructura de información incluye el número de sesiones de RTP, un número de secuencia para cada sesión de RTP, un
identificador de fuente de sincronización (SSRC) para cada sesión de RTP, y un contador giratorio (ROC) para cada sesión de RTP. Como se conoce en la materia, un flujo de RTP puede incluir una o más sesiones de RTP (por ejemplo, una sesión de video, y sesión de audio, etc.) . En el paso 504, el agente de DRM 216 un mensaje de solicitud de clave al agente de DRM 218 del generador de ECM 206. El mensaje de solicitud de clave incluye la estructura de información descrita con anterioridad, y puede incluir otros datos, tales como una vida útil de clave, una bandera de autenticación, y un identificador del RTE 204. El parámetro de vida útil de clave le permite a la TEK expirar después de un determinado tiempo. La bandera de autenticación indica si las etiquetas de autenticación van a utilizarse en los paquetes de SRTP. El agente de DRM 216 anexa los datos de autenticación al mensaje de solicitud de clave para su uso por el agente de DRM 218. En el paso 506, el agente de DRM 218 genera una TEK y un identificador de clave maestra (MKI) . La TEK es la clave maestra del SRTP. El agente de DRM 218 construye un contexto criptográfico que incluye la TEK, la MKI, la información recibida en el mensaje de solicitud de clave (por ejemplo, la estructura de información, bandera de autenticación, vida útil de la clave, etc.), y un ID de
contexto. En el paso 508, el agente de DRM 218 transmite un mensaje de respuesta de clave al agente de DRM 216. El agente de DRM 218 puede anexarle datos de autenticación al mensaje de respuesta de clave. El mensaje de respuesta de clave incluye la TEK y el MKI . En el paso 510, el agente de DRM 216 inicia o reinicia un sincronizador. El sincronizador se utiliza para determinar cuándo expira la TEK. Los pasos 504, 506, 508, y 510 se repiten cada vez que expira la TEK. En el paso 512, el agente de DRM 216 regresa un identificador de sesión segura (SSID - secure session identifier) a la aplicación de RTE 550. En el paso 514, la aplicación de RTE 550 recibe un flujo de RTP. En el paso 516, la aplicación de RTE 550 invoca al agente de DRM 216 para cifrar un paquete de RTP. La aplicación de RTE 550 le proporciona el SSID al agente de DRM 216 junto con el paquete. En el paso 518, el agente de DRM 216 cifra el paquete de RTP utilizando la TEK actual y actualiza la estructura de información (por ejemplo, el número de secuencia, ROC, SSRC para cada sesión de RTP) . En el paso 522, el agente de DRC 216 envía un paquete de SRTP a la aplicación de RTE 550. Los pasos 516, 518, y 522 se repiten para cada paquete de RTP en el flujo de RTP. En el paso 524, la aplicación de RTE 550 entrega como salida un flujo de SRTP.
La Figura 6 es un diagrama de flujo que representa gráficamente una modalidad a manera de ejemplo de una secuencia de mensajes 600 entre el generador de ECM 206, el almacenamiento de claves 212, y el RTE 204 de acuerdo con uno o más aspectos de la invención. El generador de ECM 206 incluye una aplicación de ECM 650. En el paso 602, la aplicación de ECM 650 invoca al agente de DRM 218 para establecer una sesión segura con el agente de DRM 219 del almacenamiento de claves 212. En el paso 604, el agente de DRM 218 envía un mensaje de solicitud de clave al agente de DRM 219. El agente de DRM 218 anexa los datos de autenticación al mensaje de solicitud de clave. En el paso 606, el agente de DRM 219 le envía un mensaje de respuesta de clave al agente de DRM 218. El mensaje de respuesta de clave incluye una SEK o una subclave de servicio. El agente de DRM 219 puede anexar datos de autenticación al mensaje de respuesta de clave. Los pasos 604 y 606 se repiten cada vez que expira la SEK o la subclave de servicio. En el paso 608, el agente de DRM 218 envía un
SSID asociado con la SEK o subclave de servicio a la aplicación de ECM 650. En el paso 610, la aplicación de ECM 650 envía una solicitud para la SEK o subclave al agente de DRM 218. La aplicación de ECM 650 identifica la SEK o su clave de servicio utilizando el SSID. En el paso
612, el agente de DRM 218 regresa la SEK o su clave servicio a la aplicación de ECM 650. La aplicación de ECM 650 puede solicitar la SEK o subclave de servicio al agente de DRM 218 en cualquier momento que sea requerida tal clave sin preocupaciones acerca de la vida útil de la clave. La validez de la SEK o subclave de servicio es mantenida por el agente de DRM 218, el cual guarda automáticamente la SEK o su clave de servicio actual. En el paso 614, el agente de DRM 218 recibe un mensaje de solicitud de clave proveniente del agente de DRM 216 del RTE 204. Tal mensaje de solicitud de clave se describe con anterioridad. En el paso 616, el agente de DRM 218 genera una TEK y un identificador de clave maestra (MKI) junto con un contexto criptográfico descrito con anterioridad en la Figura 5. En el paso 618, el agente de DRM 218 le envía un mensaje de respuesta de clave al agente de DRM 216 que tiene la TEK y el MKI. Los pasos 614, 616, 618 se repiten cada vez que expira la TEK. En el paso 620, la aplicación de ECM 650 envía una solicitud de contexto criptográfico al agente de DRM 218. La aplicación de ECM 650 incluye un ID de contexto en la solicitud. Utilizando el ID de contexto, en el paso 622, el agente de DRM 218 recupera y le envía el contexto criptográfico apropiado a la aplicación de ECM 650. En el paso 624, la aplicación de ECM 650 cifra al menos la TEK
dentro del contexto criptográfico utilizando la SEK o una SEK derivada de una subclave de servicio y entrega como salida un flujo de ECM. Aunque lo anterior se refiere a modalidades ilustrativas de la presente invención, pueden contemplarse otras modalidades adicionales de la invención sin aislarse del alcance básico de la misma, y el alcance de las mismas es determinado por las reivindicaciones expuestas a continuación .