MX2008003128A - Metodo y aparato para proporcionar un motor de administracion de derechos digitales. - Google Patents

Metodo y aparato para proporcionar un motor de administracion de derechos digitales.

Info

Publication number
MX2008003128A
MX2008003128A MX2008003128A MX2008003128A MX2008003128A MX 2008003128 A MX2008003128 A MX 2008003128A MX 2008003128 A MX2008003128 A MX 2008003128A MX 2008003128 A MX2008003128 A MX 2008003128A MX 2008003128 A MX2008003128 A MX 2008003128A
Authority
MX
Mexico
Prior art keywords
key
service
traffic
addition
data set
Prior art date
Application number
MX2008003128A
Other languages
English (en)
Inventor
Alexander Medvinsky
Petr Peterka
Kuang Ming Chen
Erik John Elstermann
Original Assignee
Gen Instrument Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gen Instrument Corp filed Critical Gen Instrument Corp
Publication of MX2008003128A publication Critical patent/MX2008003128A/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26606—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing entitlement messages, e.g. Entitlement Control Message [ECM] or Entitlement Management Message [EMM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26613—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8355—Generation of protective data, e.g. certificates involving usage data, e.g. number of copies or viewings allowed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método recibe un conjunto de datos. Además, el método recibe una clave de tráfico. Además, el método determina un grupo de protección de tráfico para el conjunto de datos. El método también encripta el conjunto de datos de acuerdo con la clave de tráfico para generar un conjunto encriptado de datos. Finalmente, el método proporciona el conjunto encriptado de datos a través de una red a un dispositivo.

Description

MÉTODO Y APARATO PAPA PROPORCIONAR UN MOTOR DE ADMINISTRACIÓN DE DERECHOS DIGITALES CAMPO DE LA INVENCIÓN Esta descripción generalmente se refiere al campo de difusión de datos. Más particularmente, la descripción se refiere a la seguridad de los datos que se difunden.
ANTECEDENTES DE LA INVENCIÓN Se han hecho desarrollos en el área para difundir contenido digital a dispositivos portátiles. Por ejemplo, el estándar Difusión de Video Digital para Dispositivos Móviles ("DVB-H") ha sido efectivo para permitir que dispositivos portátiles reciban el contenido digital, por ejemplo, un espectáculo de televisión. Un dispositivo portátil configurado para DVB-H recibe datos en ráfagas de modo que la cantidad de tiempo en que está encendido el dispositivo portátil tiene que optimizarse. Como resultado, baterías son suficientes para proporcionar energía para que el dispositivo portátil opere. Aunque DVB-H proporciona soporte para protocolos que protegen el contenido, por ejemplo, el Protocolo de Transporte en Tiempo Real Seguro ("SRTP") y la Carga Útil de Seguridad de Encapsulamiento de Protocolo de Internet ("IPSec/ESP") , la DVB-H no proporciona un mecanismo de seguridad para proteger las claves que se utilizan en la protección de contenido. En otras palabras, DVB-H carece de una infraestructura para proporcionar una generación y sincronización seguras de la encriptación y las claves de servicio. DVB-H define un mecanismo para distribuir claves de tráfico encriptadas a microteléfonos mediante un protocolo de mensajería, pero no define cómo las claves de tráfico se sincronizan entre el subsistema de encriptación y el subsistema de generación de mensajes de clave o cómo las claves de encriptación de la clave de tráfico, es decir, las claves de servicio, van a generarse o sincronizarse entre el subsistema de generación de mensajes de claves y el subsistema de distribución de claves.
SUMARIO DE LA INVENCIÓN En un aspecto de la descripción, se proporciona un método. El método recibe un conjunto de datos. Además, el método recibe una clave de tráfico. Además, el método determina un grupo de protección de tráfico para el conjunto de datos. El método también encripta el conjunto de datos de acuerdo con la clave de tráfico para generar un conjunto encriptado de datos. Finalmente, el método proporciona el conjunto encriptado de datos a través de una red a un dispositivo. En otro aspecto de la descripción, se proporciona un método. El método genera una clave de tráfico. Además, el método encripta la clave de tráfico con una clave de encriptación de autorización. Además, el método proporciona la clave de tráfico encriptada en un mensaje de corrientes de claves a través de una red a un dispositivo. En aún otro aspecto de la descripción, se proporciona un método. El método genera una clave de servicio para un conjunto de datos. Además, el método recibe una solicitud de la clave de servicio. Además, el método proporciona una clave de servicio de modo que una clave de tráfico se genera para un grupo de protección de tráfico para el conjunto de datos.
BREVE DESCRIPCIÓN DE LAS FIGURAS Las características antes mencionadas de la presente descripción se volverán más aparentes con referencia a la siguiente descripción tomada junto con las figuras anexas donde números de referencias similares denotan elementos similares y en los cuales: La Figura 1 ilustra un ambiente de difusión en el cual una pluralidad de proveedores de servicio ofrece cada uno un servicio. La Figura 2 ilustra una vista extendida del Canal de solapamiento . La Figura 3 ilustra un ambiente de difusión en el cual un motor de DRM se utiliza para proporcionar transmisión segura de contenido. La Figura 4 ilustra una vista extendida del motor de DRM. La Figura 5 ilustra la interacción entre los componentes del motor de DRM. La Figura 6 proporciona una arquitectura 600 para derivación y diseminación de servicios, programas y claves de tráfico que se presenta interna y externamente al Motor de DRM. La Figura 7 ilustra una secuencia de transacciones de claves de servicio. La Figura 8 ilustra una configuración en la cual el motor de DRM puede implementarse . La Figura 9 ilustra una arquitectura de componentes de tiempo de ejecución que pueden utilizarse para la implementación del motor de DRM. La Figura 10 ilustra como el RTE utiliza la arquitectura para hacer que se genere TEK, encriptar los paquetes de RTP con TEK, y hacer que los paquetes de SRTP se generen. La Figura 11 ilustra como ECMG utiliza IPRM para adquirir las claves de servicio y de tráfico. La Figura 12 ilustra como el RI utiliza un Agente de IPRM para adquirir la clave de servicio.
La Figura 13 ilustra como SKG utiliza IPRM para hacer que se genere y almacene la clave de servicio en la KS. La Figura 14 ilustra un proceso que puede utilizarse por el RTE en el motor de DRM. La Figura 15 ilustra un proceso que puede utilizarse por el ECMG en el Motor de DRM. La Figura 16 ilustra un proceso que puede utilizarse por el almacén de claves en el Motor de DRM. La Figura 17 ilustra un diagrama de bloque de una estación o sistema que implementa el Motor de DRM.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Se describe un método y aparato, los cuales proporcionan un motor de administración de derechos digitales ("DRM") . El motor de DRM puede utilizarse en una variedad de ambientes diferentes, por ejemplo, aplicaciones de difusión móvil que utilizan el estándar de DVB-H de otros estándares, para proporcionar seguridad para datos que se utilizan. El motor de DRM proporciona un mecanismo de seguridad efectivo para proteger la generación y sincronización de claves de tráfico y claves de encriptacion de clave de tráfico. La Figura 1 ilustra un ambiente 100 de difusión en el cual una pluralidad de proveedores de servicio ofrecen cada uno un servicio. Ejemplos de proveedores de servicio son proveedores de contenido por cable y satélite. Cada proveedor de servicio proporciona un servicio, el cual es una recolección de uno o más canales para el consumo basado en suscripción. Por ejemplo, un primer proveedor de servicio puede proporcionar servicio X 102 que incluye Canal A 106, Canal B 108, y Canal C 110. Además, un segundo proveedor de servicio puede proporcionar servicio Y 104 que incluye el Canal C 110, Canal D 112, Canal E 114, y Canal F 116. Cada canal es una recolección asociada de uno o más flujos de medios. En una modalidad, los flujos de medios pueden sincronizarse. Un flujo de medios es una corriente de video o de audio. Por ejemplo, un canal de televisión incluye uno o más flujos de medios, es decir, una o más corrientes de video y audio. Cada canal puede proporcionar un programa, el cual es un evento de duración finita tal como un noticiero, película, evento deportivo y similares. Un ejemplo de un flujo de medios es un flujo de medios que es soportado por el Protocolo de Transporte en Tiempo Real en el cual un flujo de medios incluye un par de direcciones de destino de trasporte que corresponden con una dirección de destino común, por ejemplo, dirección de IP, y dos puertos de destino únicos (UDP")para el Protocolo de Transporte en Tiempo Real ("RTP") y los paquetes de Protocolo de Control de RTP ("RTCP") .
El Canal C 110 es un canal de solapamiento entre el servicio X 102 y el servicio Y 104. Por consiguiente, tanto el proveedor de servicio para el servicio X 102 como el proveedor de servicio para el servio Y 104 ofrecen el mismo Canal C 110. El motor de DRM permite a un suscriptor de un servicio, por ejemplo, el servicio X 102, acceder al contenido protegido del Canal C 110 de solapamiento sin aprender el mecanismo de seguridad empleado por el servicio Y 104 para proteger el mismo contenido. La Figura 2 ilustra una vista extendida del Canal C 110 de solapamiento. El Canal C 110 puede incluir una pluralidad de flujos de medios. Por ejemplo, el Canal C 110 puede incluir un primer flujo de medios, un segundo flujo de medios, un tercer flujo de medios, un cuarto flujo de medios, un quinto flujo de medios, un sexto flujo de medios, y un séptimo flujo de medios. El motor de DRM se utiliza para categorizar el flujo de medios en grupos de protección de tráfico. El grupo de protección de tráfico es un grupo de uno o más flujos de medios que se encriptan utilizando una Clave de Tráfico ("TK") común, periodo criptográfico, y protocolo de protección. Por ejemplo, el primer flujo de medios y el segundo flujo de medios pueden categorizarse en un grupo de protección de tráfico a 202. Además, el tercer flujo de medios y el cuarto flujo de medios y el quinto flujo de medios pueden categorizarse en un grupo de protección de tráfico ß 204. Finalmente, el tercer flujo de medios, el sexto flujo de medios, y el séptimo flujo de medios pueden categorizarse en un grupo de protección de tráfico ? 206. El motor de DRM utiliza una corriente de claves única, la cual es un control de autorización, para cada uno de los grupos de protección de tráfico para encriptar los flujos de medios dentro del grupo de protección de tráfico. Un mensaje de corriente de clave única ("KSM") se genera para cada uno de los grupos de protección de tráfico y servicios. Como resultado, los TK encriptados pueden distribuirse a los dispositivos de recepción, por ejemplo, dispositivos móviles utilizando KSM. Por ejemplo, un KSM único puede generarse para el grupo de protección de tráfico a 202 para el servicio X 102. Por consiguiente, KSM Xa 208 puede utilizarse para distribuir las TK que son claves de servicio únicas proporcionadas por el proveedor de servicio del servicio X 102. Además, una KSM única puede generarse para el grupo de protección de tráfico a 202 para el servicio Y 104. El KSM ?a 210 puede utilizarse para distribuir las TK que son claves de servicio únicas proporcionadas por el proveedor de servicio de servicio Y 104. Como resultado, diferentes KSM se utilizan para proporcionar acceso a los flujos de medios en el mismo Canal C 110. Un primer dispositivo suscrito al servicio X 102 escucha KSM ?a 208 mientras un segundo dispositivo suscrito al servicio Y 104 escucha el KSM Ya 210. Ambos dispositivos son capaces de derivar las mismas TK para el grupo de protección de tráfico a 202 y de este modo accede el contenido para el Canal C 110. Además, KSM Xp 212 y KSM Yp puede generarse para el grupo de protección de tráfico ß 204. Además, KSM Xy 216 y KSM Yy 218 pueden generarse para el grupo de protección de tráfico y 206. La Figura 3 ilustra un ambiente 300 de difusión el cual se utiliza un motor 302 de DRM para proporcionar transmisión segura de contenido. El contenido puede proporcionarse por los proveedores de servicio a través de una o más redes 304 de proveedores de contenido. Además, el contenido puede ser una corriente que pertenece a una de las siguientes categorías; (1) no nacional en tiempo real; (2) nacional en tiempo real; (3) no nacional en tiempo no real; o (4) nacional en tiempo no real. Cualquiera de estas corrientes de contenido pueden encriptarse. Por consiguiente, un descifrador 306 no nacional en tiempo real puede utilizarse para descifrar el contenido no nacional en tiempo real, un descifrador 308 nacional en tiempo real puede utilizarse para descifrar el contenido nacional en tiempo real, un descifrador 310 no nacional en tiempo no real puede utilizarse para descifrar el contenido no nacional en tiempo no real, y un descifrador 312 nacional en tiempo no real puede utilizarse para descifrar el contenido nacional en tiempo no real. El contenido no nacional en tiempo real puede tener que transcodificarse . Por consiguiente, el contenido nacional en tiempo real puede enviarse a un transcodificador 314 de audio/visual ("A/V") para transcodificarse . Dentro del transcodificador 314 de A/V, un descodificador 316 de A/V puede descodificar el contenido no nacional en tiempo real y un codificador 318 de A/V puede codificar el contenido no nacional en tiempo real. Las corrientes en tiempo real, es decir, las corrientes no nacional en tiempo real y nacional en tiempo real, se envía al motor 302 de DRM para la protección en ruta para dispositivos 320 de usuario autorizados mediante una red 322 de difusión. El contenido no nacional en tiempo no real también puede tener que transcodificarse . Por consiguiente, el contenido no nacional en tiempo no real puede enviarse a un transcodificador 324 para transcodificarse . Dentro del transcodificador 324, un descodificador puede descodificar el contenido no nacional en tiempo no real y un codificador 326 puede codificar el contenido no nacional en tiempo no real. Las corrientes de tiempo no real, es decir, las corrientes nacional en tiempo no real y no nacional en tiempo no real se almacenan en un medio 330 de almacenamiento que se puede acceder a través de un Servidor 332 de Distribución de Contenido. Por consiguiente, las corrientes en tiempo no real pueden accederse para la reproducción subsiguiente o recuperación. En una modalidad, el medio 330 de almacenamiento se integra dentro del Servidor 332 de Distribución de Contenido. En otra modalidad, el medio 330 de almacenamiento es distinto del Servidor 332 de Distribución de Contenido, pero puede accederse por el Servidor 332 de Distribución de Contenido, por ejemplo, a través de una conexión de red. En una modalidad alternativa, las corrientes en tiempo no real pueden pre-encriptarse antes del almacenamiento en el medio 330 de almacenamiento. Por consiguiente, puede proporcionarse un pre-encriptador para recibir y pre-encriptar la corriente nacional en tiempo no real transcodificada y/o la corriente no nacional en tiempo no real. El pre-encriptador puede enviar entonces la corriente pre-encriptada al medio 330 de almacenamiento para su almacenamiento. Además, metadatos tales como datos de descripción de servicio y datos de guias de programas se envía desde una o más redes 304 de proveedor de contenido hasta un Generador de Guías de Servicio Electrónico ( "ESGG" ) 334 para facilitar el servicio, descubrimiento de canal y selección por los usuarios en los dispositivos 320 de usuario autorizado. Los metadatos pueden enviarse desde el ESGG 334 a un programador 340 de programas. Por consiguiente, el programa 340 de programas utiliza el motor 302 de DRM para acceder a los flujos de medios y asocia los metadatos con el flujo de medios correspondiente. Además, el programa 340 de programas proporciona los metadatos y el contenido a un servidor 342 de presentación que puede proporcionar el contenido al dispositivo 320 de usuario a través de la red 336 interactiva. Por consiguiente, el motor 302 de DRM proporciona varias funciones para facilitar la distribución segura de flujos de medios hasta los dispositivos 320 de usuario autorizados. El motor 302 de DRM proporciona encriptación en tiempo real de flujos de medios. Además, el motor 302 de DRM genera y almacena las claves de nivel de servicio, nivel de programa y nivel de tráfico. Además, el motor 302 de DRM proporciona la distribución de TK y las reglas de acceso/uso para los dispositivos 320 de usuario a través de KSM. El motor 302 de DRM también se interconecta con el sistema 338 de administración de autorización que envían claves de servicio y programas a los dispositivos 320 de usuario autorizados. Además, el sistema 338 de administración de autorización puede interactuar con una aplicación 344 de auditoria, un sistema 346 de administración de suscriptores , y un sistema 348 de comercio electrónico. El sistema 348 de comercio electrónico puede interactuar entonces con el dispositivo 320 de usuario a través de la red 336 interactiva. La Figura 4 ilustra una vista extendida del motor 302 de DRM. Por consiguiente, el motor 302 de DRM tiene un administrador de configuración ("CM") 402 que administra el Motor 302 de DRM. En una modalidad, el CM 402 también puede proporcionar la interfaz de usuario primaria para proporcionar un generador de mensajes de control de autorización ("ECMG") 404 y un encriptador en tiempo real ("RTE") 406. El ECMG 404 crea y proporciona las TK en el RTE 406. Además, el ECMG 404 puede proporcionar KSM a la red 322 de difusión para facilitar el descifrado de contenido por el dispositivo 320 de usuario. El RTE 406 proporciona encriptación en tiempo real de corrientes. En una modalidad, el RTE 406 soporta el SRTP. En otra modalidad, el RTE 406 también puede soportar IPSec/ESP. El motor 302 de DRM también tiene un Centro 408 de Distribución de Claves ("KDC") . El KDC 408 puede proporcionar un mecanismo de autentificación de rotulación para transacciones seguras entre los componentes del motor 302 de DRM y aplicaciones externas que ejecutan una Interfaz de Programación de Aplicaciones ("API") de Administración de Derechos de IP ("IPRM") . Además, un almacén de claves ("KS") 410 es un depósito para claves de servicio, claves de programas y reglas de acceso/uso relacionadas. El KS 410 también puede proporcionar generación de claves de servicio y programas. En una modalidad, los componentes del motor 302 de DRM puede interactuar con uno o más agentes de IPRM para facilitar la generación e intercambio de claves. Un generador de claves de servicio ("SKG") es un agente de IPRM que se comunica con el KS 410 para solicitar la generación de claves de servicio. El SKG puede co-alojarse con el ECMG 404. Además, un recuperador de claves de servicio ("SKR") es un agente de IPRM que se comunica con el KS 410 para recuperar claves de servicio. Además, el SKR puede utilizarse en el ECMG 404 para obtener claves de servicio para la generación de KSM. El SKR puede utilizarse también Empleado en un Sistema de Administración de Autorización ("EMS") 338 el cual puede ser un Emisor de Derechos ("RI"), para facilitar la distribución de claves de servicio a los dispositivos 320 de usuario autorizados, por ejemplo, terminales de "suscripción" mediante la red 336 interactiva, por ejemplo, una red celular. Un generador de claves de programas ("PKG") puede comunicarse con el KS 410 para solicitar la generación de claves de programas. Además, el PKG puede utilizarse con aplicaciones para la programación de eventos de programas. Un recuperador de claves de programas ("PKR") puede comunicarse con el KS 410 para recuperar las claves de programas. El PKR puede utilizarse en el ECMG 404 para obtener claves de programas para la generación de Mensajes de Corrientes de Claves. Además, el PKR puede utilizarse en el EMS 338 para facilitar la distribución de claves de programas a terminales de "pago por evento" mediante la red 336 interactiva . En una modalidad, los componentes pueden interactuar entre si a través de una red 412 de control. Además, el RTE 406 puede proporcionar las corrientes encriptadas a una red 414 de medios para el procesamiento de datos de medios. Las corrientes encriptadas entonces pueden enviarse al programador de programas y el generador 340 de guias. La Figura 5 ilustra la interacción entre los componentes del motor 302 de DRM. Una TK es una clave de la cual la encriptación de flujo de medios y las claves de autentificación se derivan. La TK puede utilizarse en el RTE 406 para la encriptación/autentificación de SRTP y/o IPSec/ESP. Además, la TK se distribuye en forma segura a terminales mediante un mensaje de control de autorización de difusión ("cubierto" por las claves de programas y/o servicios) . Las TK pueden actualizarse frecuentemente, por ejemplo, en segundos.
Además, una clave de programas ("PK") es una clave que puede utilizarse para proteger la programación de pago por evento. La PK se distribuye en forma segura a terminales de pago por evento mediante la red 336 interactiva. En otra modalidad, para el canal que soporta suscripciones y el canal de pago por evento, la PK puede utilizarse para dispositivos 320 de usuario tales como terminales basadas en suscripción mediante un mensaje de control de autorización de difusión ("ECM") , el cual puede encriptarse por una clave de servicio ("SK") . Una PK típicamente abarca un evento de programa que dura de varios minutos a varias horas. Además, un SK puede utilizarse para proteger las TK difundidas para los servicios basados en suscripción o proteger las claves de programas distribuidas a las terminales de sólo suscripción. Por consiguiente, la clave de servicio actúa como una clave de suscripción. Las SK se proporcionan para autorizar dispositivos 320 de usuario "conectados" o "desconectados" mediante la red 336 interactiva como Objetos de Derechos. Las SK pueden actualizarse pero con poca frecuencia (por ejemplo, de días a meses), típicamente equivalente con un ciclo de facturación de suscripción. El dispositivo 320 de usuario se registra con un Emisor de Derechos, por ejemplo, el EMS 338, para obtener un Objeto de Derechos ("RO") que contiene claves de servicios y/o programas encriptadas y la información de autorización relacionada. El Agente 502 de DR del Dispositivo 320 de Usuario Final descifra esta información para revelar la SK y/o PK. Si los derechos de dispositivo 320 de usuario concuerdan con las reglas, el Agente 502 de DRM entonces envía la SK y/o PK a un Agente 504 de ECM del dispositivo 320 de usuario para exponer la TK encriptada en ECM, es decir, KSM, distribuidas por la red 322 de difusión. Por consiguiente, un descifrador 506 del dispositivo 320 de usuario entonces puede utilizarse para que TK descifre el contenido de modo que el dispositivo 320 de usuario tenga acceso al contenido. Los siguientes modos de mensajes de corrientes de claves son soportados donde E{X} (data) denota datos encriptados bajo la clave X. Para un modo de sólo suscripción, el material de la clave de KSM puede ser E{SK} (TK) . Además, para un modo de sólo pago por evento, el material de clave KSM puede ser E{PK}(TK). Además, para un modo de suscripción y pago por evento, el material de clave de KSM puede ser E{PK}(TK) y E{SK}(PK). En el modo híbrido, es decir, el modo de suscripción y pago por evento, los dispositivos 320 de usuario tales como terminales de suscripción primero utilizan la SK para revelar la PK la cual entonces se utiliza para derivar la TK despejada. Las terminales de pago por evento no necesitan utilizar la SK para revelar la PK. Las terminales de pago por evento pueden utilizar la PK para derivar la TK despejada. En este punto, la terminal puede utilizar la TK para descifrar el contenido si se permite, de acuerdo con las reglas de acceso/uso llevadas en el KSM. La Figura 6 proporciona una arquitectura 600 para la derivación y diseminación de claves de servicios, programas y tráfico que se presentan interna y externamente al Motor 302 de DRM. Las transacciones se protegen utilizando agentes de IPRM co-alojados con cada aplicación participante . En una modalidad, la KS 410 es la instalación primaria para la generación y almacenamiento de claves de servicios y programas. En este modelo, un agente de IPRM, tal como SKG, de la entidad etiquetada como "A" 602 es responsable de solicitar la generación de claves de servicio. Además, la entidad "B" 604 puede recuperar las claves de servicio para distribución a dispositivos 320 de usuario tales como terminales de suscriptor mediante la red 336 interactiva. La entidad "C" 606, que tiene un agente de IPRM que opera como un PKG solicita la generación de claves de programas por evento de programa y suministra los criterios de acceso/uso de programas asociados a la KS 410 para almacenamiento y recuperación subsiguiente por otras aplicaciones. Además, la entidad "D" 608, que tiene un agente de IPRM tal como PKR puede solicitar claves de programas para la distribución a las terminales de pago por evento mediante la red 336 interactiva. Para aplicaciones de difusión móvil, estos elementos pueden corresponder con componentes de un Servidor 332 de Distribución de Contenido. Por ejemplo, las entidades B 604 y D 608 pueden ser Emisores de Derechos de la Alianza Móvil Abierta ( "OMA" ) mientras la entidad C 606 puede ser una ESGG 334, como se ve en la Figura 3, o aplicación equivalente con la funcionalidad de programación de programas. En una modalidad, la S G puede co-alojarse con el ECMG 404. Además de suministrar los ECM, el ECMG 404 también soporta creación y almacenamiento de claves de tráfico. Dependiendo del modo configurado (por canal), el ECMG 404 recupera SK y/o PK de la KS 410 para la generación de KSM distribuidas a las terminales mediante la red 322 de difusión. Basándose en cada periodo criptográfico de tráfico de canal, el RTE 406 que solicita periódicamente la generación de claves de tráfico por el ECMG 404 para la encriptacion y autentificación de cada uno de los flujos de medios de canales. La Figura 7 ilustra una secuencia de transacciones de claves de servicio. En la operación A 706, la cual es gobernada por un periodo criptográfico de claves de servicio configurado, un Generador de Claves de Servicio solicita periódicamente la creación de una clave de servicio, específicamente identidad de servicio, por ejemplo, socID y serviceBaseCID, y el tiempo de expiración de clave de la KS 410. Inicialmente , las claves de servicio actuales y siguientes se solicitan. Además, en la Operación B 708, la KS 410 genera y almacena la clave de servicio y confirma la solicitud. Además, en la Operación C 710, un Recuperador 704 de Calve solicita una clave de servicio actual y/o siguiente para un servicio especifico. En la Operación D 712, la KS 410 envía la clave de servicio y el tiempo de expiración al Recuperador 704 de Clave, por ejemplo, Emisor de Derechos. El Recuperador 704 de Clave utiliza el tiempo de expiración de la clave de servicio actual (SK[n]) para determinar el tiempo en el cual la siguiente clave de servicio (SK[n+l]) se vuelve activa, es decir, actual y para programar la siguiente recuperación de clave de servicio (SK[n+2]). Además, una Operación E 714, el ECMG 404 (agente de IPRM que actúa como Recuperador de Clave) solicita la clave de servicio actual y/o siguiente del KS 410. Además, en la Operación F 716, la KS 410 envía la clave de servicio y el tiempo de expiración al ECMG 404. El ECMG 404 utiliza el tiempo de expiración de la clave de servicio actual (SK[n]) para programar el tiempo en el cual la siguiente clave de servicio (SK[n+l]) se vuelve activa, es decir, actual y la siguiente clave de servicio (SK[n+2]) debe recuperarse. En operación G 718, el RTE 406 solicita generación y almacenamiento de una nueva clave de tráfico cada periodo criptográfico de clave de tráfico. Cuando expira TK[m], TK[m+l] se vuelve clave de tráfico activa y TK[m+2] se solicita. Además, en una octava transacción, el EC G 404 genera, almacena y regresa la siguiente clave de tráfico. Finalmente, en la Operación H 720, el ECMG 404 genera, almacena y regresa la siguiente clave de tráfico. En una modalidad, el Recuperador 704 de Claves puede enviar las claves de servicio actuales y siguientes a un dispositivo 320 de usuario. Por lo tanto, el recuperador 704 de claves debe tener acceso a ambas claves. En otra modalidad, si el RTE 406 no es capaz de comunicarse con ECMG 404, el RTE 406 debe suspender la salida de cada flujo de medios asociados al final de su último periodo criptográfico de tráfico valido. En una Operación I 722, existe una salida de ECM E{SK} (TK) . La Figura 8 ilustra una configuración 800 en la cual el motor 302 de DRM puede implementarse . Por consiguiente, los diversos componentes del motor 302 de DRM pueden implementarse con una agrupación de dispositivos de cómputo. Además, la configuración 800 incluye una pluralidad de redes lógicas y las interacciones de los componentes del motor 302 de DRM con las redes lógicas. El KS 410 se conecta a una Red 802 de Control para el procesamiento de IPRM. Un navegador 808 de web puede utilizarse para acceder a la red 802 de control. El ECMG 414 se conecta a la Red 802 de Control (para mensajería de IPRM) y la Red de Difusión (para difusión de ECM) . El RTE 406 se conecta a la Red 802 de Control (para mensajería de IPRM) , la Red 414 de Medios (para procesamiento de datos de medios) , y la Red 322 de Difusión (para difusión de medios encriptada) . Un Proveedor 804 de Datos de Guías se conectan a la Red 414 de Medios para la emisión de datos de guía. Además, el ESGG 334 se conecta a la Red 414 de medios para la recepción de datos de guía y la Red 322 de Difusión para la difusión de datos de guía. Además, una pluralidad de codificadores 806 se conecta a la Red 414 de Medios para proporcionar el contenido de medios. El Sistema 338 de Administración de Autorización, por ejemplo, un emisor de derechos, se conecta a la Red 802 de Control para solicitar claves de servicio. Por consiguiente, el Sistema 338 de Administración de Autorización entonces puede proporcionar las claves de servicio al dispositivo 320 de usuario a través de la red 336 interactiva. La Figura 9 ilustra una arquitectura 900 de componentes de tiempo de ejecución que pueden utilizarse para la implementación del motor 302 de DRM. La arquitectura 900 soporta un servicio de proporción que configura un componente 902 Daemon de Corredor de Seguridad Electrónica ("ESB") de IP M, el cual ejecutará el RTE 406 asi como el EC G 404. Un servicio de proporción puede incluir uno o más procedimientos que reúnen información de autentificación sobre un componente y comunican la información de autentificación a un servicio de autentificación . El servicio de proporción también puede establecer el destino por defecto de mensajería de IPRM, es decir, para definir dónde enviar los mensajes de protocolo de IPRM. Además, la arquitectura 900 soporta servicios de autentificación que autentifican las dos partes, cliente de IPRM y servidor de IPRM, de modo que la identificación de la entidad es verificada por ambos lados. Por ejemplo, el ECMG 404 autentifica la identidad del RTE 406 y proporciona prueba de identidad de sí mismo al RTE 406 antes del intercambio de claves. Además, la arquitectura 900 también soporta un servicio de administración de claves que genera claves y la distribuye en forma segura. Este es el servicio más visible en cuanto a lo que tiene que ver con DVB-H ya que el IPRM genera y distribuye las claves de servicio, programas y tráfico de DVB-H. Sin embargo, este servicio es dependiente de los dos servicios previos. Sin provisión, las entidades de tiempo de ejecución no pueden autentificarse y sin autentificación, no puede establecerse confianza y las claves no se distribuirán. La arquitectura 900 también proporciona un servicio de almacenamiento de claves, el cual genera claves y las almacena en un almacén permanente para acceso seguro posterior. La arquitectura 900 incluye ejecutables y una biblioteca de enlaces. El componente 902 Daemon ESB es uno de los dos ejecutables y se involucra en la ejecución del protocolo de seguridad de IPRM. Además, un ejecutable 904 de KDC/KS se utiliza con los servicios de autentificación y almacén de claves. La biblioteca de enlaces tiene un agente 906 de IPRM, el cual es una capa de software. El Agente 906 de IPRM proporciona acceso a la funcionalidad de IPRM para las aplicaciones. El SKG 702 envía mensajes de solicitud de claves para pedir al ejecutable 904 de DKC/KS que genere y almacene claves de servicio de KS 410. El ECMG 404 y un emisor de derechos ("RI") , el cual es un componente del Sistema 338 de Administración de Autorización mostrado en la Figura 3, envía mensajes de solicitud de claves para solicitar al ejecutable 904 de KDC/KS recupere y devuelva las claves de servicio desde el KS 410. Además, el RTE 406 envía los mensajes de solicitud de claves para solicitar al ECMG 404 que genere y devuelva las claves de tráfico. Los mensajes de solicitud de claves son protegidos por el protocolo de seguridad de IPRM. Por consiguiente, las claves de encriptación de tráfico se distribuyen en forma segura y se sincronizan entre el ECMG 404 y RTE 406. El ECMG 404 reenvía en forma subsiguiente las claves de encriptación de tráfico a los dispositivos 320 de usuario. La Figura 10 ilustra cómo el RTE 406 utiliza la arquitectura 900 para hacer las Claves de Encriptación de Tráfico ("TEK") se generen, encriptar los paquetes de RTP con TEK, y hacer que los paquetes de SRTP se generen. En una Operación A 1002, el Agente 1024 de IPRM se inicializa. Además, en una Operación B 1004, una sesión de seguridad de IPRM se establece. El parámetro SessType específica el tipo de la sesión, tal como SRTP e IPSEC. En una modalidad, IPRM_TKS_SRTP se utiliza. La etiqueta auth denota si aplicar la autentificación de paquete a la corriente de SRTP. Además, en una Operación C 1006, el IPRM ejecuta el protocolo de KeyRequest contra los componentes 1028 de IPRM en el ECMG 404. En una Operación D 1008, el ECMG 404 genera TEK y el índice de Claves Maestro ( "MKI" ) . Además, en una Operación E 1010, el ECMG 404 devuelve a KeyReply que incluye TEK y MKI. Además, en una Operación F 1012, el RTE 406 establece el cronómetro de TEK. En una Operación G 1014, el IPRM devuelve SSID a la Aplicación 1026 de RTE. TEK se 'oculta' detrás de SSID. Puesto que IPRM también realiza la encriptación, la aplicación de RTE no tiene que acceder al TEK. Además, en una Operación H 1016, el RTE 406 recibe una corriente de RTP. En una operación I 1018, el RTE 406 invoca IPRM_Encrypt por paquete de RTP. Además, en una Operación J 1020, el Agente de IPRM actualiza el Grupo de Protección de Tráfico ( "TPG" ) _Info . Además, en una Operación K 1022, el Agente 1024 de IPRM devuelve un paquete de SRTP. Además, en una Operación L 1024, una corriente de SRTP se produce. El siguiente código puede utilizarse para implementación de la arquitectura 900: struct TK_DOI_Y { rte_id authenticatión t ra f fi _encrypt ior,_key t ra f fic_encr pcion key 1 ifet inte mas t e r_ke y_incte:·; currOr ext eyFlag struct TK_DOI_X ( rte_id keyLif t ime authent ica ión T?G_:nfo } struct TPG_Info ! tra f fic_prot ec ior:_cjroup_ID r.um er of media flows for(j=0 i <nuraber_of_media flows; Sequenc_Number synchroni zatior._source rol.] over_cüunLer i La Figura 11 ilustra cómo el ECMG 404 utiliza IPRM para adquirir las claves de servicio y de tráfico. En una Operación A 1102, el Agente 1124 de IPRM se inicializa.
Además, en una Operación B 1104, se establece una sesión de seguridad para la recuperación de claves de servicio.
Además, en una Operación C 1106, el Agente 1124 de IPRM envía una KeyRequest para la recuperación de claves al KS 410. En una Operación D 1108, el KS 410 devuelve la subclave de servicio. Además, en una Operación E 1110, el Agente 1124 de IPRM devuelve SSID. Además, en una Operación F 1112, el ECMG 404 llama a IPRM_GetKey con SSID. En una Operación G 1114, el Agente 1124 de IPRM devuelve la clave de encriptación de servicio ("SEK") y la semilla a la autentificación de servicio ("SAS") . Además, en una Operación H 1116, la KeyRequest se recibe del RTE . Además, en una Operación I 1118, el Agente 1124 de IPRM genera TEK, MKI, y el objeto grande binario (blob) de datos TK_DOI_Y. TK_DOI_Y es una seudo estructura de datos que muestra qué elementos de datos se contiene. El Agente 1124 de IPRM envía KeyReply. El Agente 1124 de IPRM establece el cronómetro. Cuando la clave de tráfico expira, IPRM en el lado de RTE repetirá las etapas anteriores. En una Operación J 1120, la aplicación 1126 de ECMG llama al IPRM_GetTKContext para obtener la información de contexto por el RTE y el TPG para obtener la última clave de tráfico. En una Operación K 1122, el Agente 1124 de IPRM devuelve la estructura de datos local a la aplicación 1126 de ECMG. Las aplicaciones pueden llamar a IPRM_GetKey siempre que las aplicaciones lo requieran, sin preocuparse sobre la duración de la clave, debido a que la validez de las claves se mantiene por el Agente 1124 de IPRM automáticamente. Por consiguiente, el Agente 1124 de IPRM devuelve una estructura de datos local en memoria, y por lo tanto la sobre carga de procesamiento no es demasiado difícil . El siguiente código puede utilizarse en una implementación para permitir que el ECMG 404 utilice el Agente 1124 de IPRM para adquirir las claves de servicio y de tráfico: struct TPG_Info { t rafí: i c protec t ion group ID nuR'ber_o f_medi a _f1ows for(j=C; j<number_ f_media_flows; j++) { Sequenc_Number synchron i za z i on_source rol 1 o e r_cou nter } ? struc T _DOl_X ( rte_id keyld f ex. i me authentieation PG Info struct TK_DOI_Y ( rte_i authenticat ;or¡ t ra f fic_encryp z i o:i_ ey traffic_encryption_key_lifetime master_key_index currOr e z Key 1ag TPG_Info ) La Figura 12 ilustra cómo el Emisor 908 de Derechos ("RI") utiliza un Agente 1216 de IPRM para adquirir la clave de servicio. El RI 908 es un componente en el EMS 338, el cual recupera la clave de servicio del Almacén 410 de Claves y emite el Objeto de Derechos ("RO") a los dispositivos 320 de usuario. En una Operación A 1202, el Agente 1216 de IPRM se inicializa. Además, en una Operación B 1204, se establece una sesión de seguridad para la recuperación de claves de servicio. Además, en una Operación C 1206, el Agente 1216 de IPRM envía KeyRequest para la recuperación de claves al KS 410. En Operación D 1208, el KS 410 devuelve la subclave de servicio. Además, en una Operación E 1210, el Agente 1216 de IPRM devuelve SSID. Además, en una Operación F 1212, la aplicación 1218 de RI llama a IPRM_GetKey con SSID. En una Operación G 1214, el Agente 1216 de IPRM devuelve la clave de encriptación de servicio ("SEK") y la semilla de autentificación de servicio ("SAS") a la aplicación 1218 de RI . La Figura 13 ilustra como el SKG utiliza IPRM para hacer que la clave de servicio se genere y almacene en el KS 410. En una Operación A 1302, el Agente 1312 de IPRM se inicializa. Además, en una Operación B 1304, se establece una sesión de seguridad para la generación de claves de servicio. Además, en una Operación C 1306, el Agente 1312 de IPRM envía KeyRequest para la generación de claves a KS 410. En una Operación D 1308, KS 410 devuelve la subclave de servicio. Finalmente, en una Operación E 1310, el Agente 1312 de IPRM devuelve SSID a la aplicación 1314 de SKG. En una modalidad, la arquitectura 900 proporciona herramientas para proporcionar aplicaciones que utilizan la arquitectura 900. La herramienta genera un archivo de configuración como resultado, y el archivo de configuración puede utilizarse por el Daemon ESB cuando el Daemon ESB comienza. La proporción necesita ejecutarse solamente una vez por entidad de aplicación, por ejemplo, una vez para el RTE 406 y una vez para el ECMG 406. La Figura 14 ilustra un proceso 1400 que puede utilizarse por el RTE 404 en el motor 302 de DRM. En un bloque 1402 de proceso, el proceso 1400 recibe un conjunto de datos. Además, en un bloque 1404 de proceso, el proceso 1400 recibe una clave de tráfico. Además, en un bloque 1406 de proceso, el proceso 1400 determina un grupo de protección de tráfico para el conjunto de datos. Además, en un bloque 1408 de proceso, el proceso 1400 encripta el conjunto de datos de acuerdo con la clave de tráfico para generar un conjunto encriptado de datos. Finalmente, en un bloque 1410 de proceso, el proceso 1400 proporciona el conjunto encriptado de datos a través de una red a un dispositivo. La Figura 15 ilustra un proceso 1500 que puede utilizarse por el ECMG 406 en el motor 302 de DRM. En un bloque 1502 de proceso, el proceso 1500 genera una clave de tráfico. Además, en un bloque 1504 de proceso, el proceso 1500 encripta la clave de tráfico con una clave de encriptación de autorización para generar una clave de tráfico encriptada. Además, en un bloque 1506 de proceso, el proceso 1500 proporciona la clave de tráfico encriptada en un mensaje de corriente de clave a través de una red a un dispositivo. La Figura 16 ilustra un proceso 1600 que puede utilizarse por el almacén 410 de claves en el motor 302 de DRM. En un bloque 1602 de procesos, el proceso 1600 genera una clave de servicio para un conjunto de datos. Además, en un bloque 1604 de proceso, el proceso 1600 recibe una solicitud por la clave de servicio. Además, en un bloque 1606 de proceso, el proceso 1600 proporciona la clave de servicio de modo que una clave de tráfico se genera para un grupo de protección de tráfico para el conjunto de datos. La Figura 17 ilustra un diagrama de bloque de una estación o sistema 1700 que implementa el Motor 302 de DRM. En una modalidad, la estación o sistema 1700 se implementa utilizando una computadora de propósito general o cualesquier otros equivalentes de hardware. De este modo, la estación o el sistema 1700 comprende un procesador 1710, una memoria 1720, por ejemplo, memoria de acceso aleatorio ("RAM") y/o memoria de sólo lectura ("ROM"), un módulo 1740 de Motor de DRM, y varios dispositivos 1730 de entrada/salida (por ejemplo, dispositivos de almacenamiento, que incluyen pero no se limitan a, una unidad de cinta, una unidad de disco flexible, una unidad de disco duro o una unidad de disco compacto, un receptor, un transmisor, un altavoz, una pantalla, un sensor de captura de imagen, por ejemplo, aquellos utilizados en una cámara digital fija o videocámara digital, un reloj, una lumbrera de salida, un dispositivo de entrada de usuario (tal como teclado, un teclado alfanumérico, un ratón, y similares, o un micrófono para capturar los comandos de conversación) ) . Se debe entender que el módulo 1740 de motor de DRM puede implementarse como uno o más dispositivos físicos que se acoplan al procesador 1710 a través de un canal de comunicación. Alternativamente, el módulo 1740 de motor de DRM puede representarse por una o más aplicaciones de software (o incluso una combinación de software y hardware, por ejemplo, utilizando los circuitos integrados de aplicación específica (ASIC) ) , donde el software se carga desde un medio de almacenamiento (por ejemplo, una unidad magnética u óptica o disquete) y operado por el procesador en la memoria 1720 de la computadora. Como tal, el módulo 1740 de motor de DRM (que incluye estructuras de datos asociadas) de la presente invención pueden almacenarse en un medio que se puede leer por computadora, por ejemplo, memoria RAM, unidad de disco magnética u óptica o disquete y similares.
Se entiende que el motor 302 de DRM descrito en la presente también puede aplicarse en otros tipos de sistemas. Aquellos con experiencia en la técnica apreciarán que las diversas adaptaciones y modificaciones de las modalidades de este método y aparato pueden configurarse sin apartarse del alcance y espíritu del presente método y sistema. Por lo tanto, se entenderá que dentro de las reivindicaciones anexas, el presente método y aparato puede practicarse en forma diferente a como se describe específicamente en la presente.

Claims (20)

  1. NOVEDAD DE LA INVENCION Habiendo descrito la presente invención se considera como novedad y por lo tanto se reclama como propiedad lo descrito en las siguientes reivindicaciones.
  2. REIVINDICACIONES 1. Un método caracterizado porque comprende: recibir un conjunto de datos; recibir una clave de tráfico; determinar un grupo de protección de tráfico para el conjunto de datos; encriptar el conjunto de datos de acuerdo con la clave de tráfico para generar un conjunto encriptado de datos; y proporcionar el conjunto encriptado de datos a través de una red a un dispositivo. 2. El método de conformidad con la reivindicación 1, caracterizado porque el conjunto de datos incluye contenido no nacional en tiempo real.
  3. 3. El método de conformidad con la reivindicación 1, caracterizado porque el conjunto de datos incluye contenido nacional en tiempo real.
  4. 4. El método de conformidad con la reivindicación 1, caracterizado porque el conjunto de datos incluye contenido no nacional en tiempo no real.
  5. 5. El método de conformidad con la reivindicación 1, caracterizado porque el conjunto de datos incluye contenido no nacional en tiempo no' real.
  6. 6. El método de conformidad con la reivindicación 1, caracterizado porque la red es una red de difusión.
  7. 7. El método de conformidad con la reivindicación 1, caracterizado porque el dispositivo es un dispositivo móvil .
  8. 8. El método de conformidad con la reivindicación 1, caracterizado porque el conjunto de datos incluye contenido de audio.
  9. 9. El método de conformidad con la reivindicación 1, caracterizado porque el conjunto de datos incluye contenido de video.
  10. 10. Un método caracterizado porque comprende: generar una clave de tráfico; encriptar la clave de tráfico con una clave de encriptación de autorización; y proporcionar la clave de tráfico encriptada en un mensaje de corriente de claves a través de una red a un dispositivo .
  11. 11. El método de conformidad con la reivindicación 10, caracterizado porque la clave de encriptación de autorización es una clave de programa.
  12. 12. El método de conformidad con la reivindicación 10, caracterizado porque la clave de autorización es una clave de servicio.
  13. 13. El método de conformidad con la reivindicación 10, caracterizado porque la red es una red de difusión.
  14. 14. El método de conformidad con la reivindicación 10, caracterizado porque la red es una red de difusión móvil.
  15. 15. Un método caracterizado porque comprende: generar una clave de servicio para un conjunto de datos ; recibir una solicitud por la clave de servicios; y proporcionar a la clave de servicio de modo que una clave de tráfico se genera para un grupo de protección de tráfico para el conjunto de datos.
  16. 16. El método de conformidad con la reivindicación 15, caracterizado porque la clave de servicio es para servicio.
  17. 17. El método de conformidad con la reivindicación 16, caracterizado porque el servicio incluye uno o más canales.
  18. 18. El método de conformidad con la reivindicación 17, caracterizado porque uno o más canales son basados en suscripción.
  19. 19. El método de conformidad con la reivindicación 15, caracterizado porque el servicio incluye contenido de video.
  20. 20. El método de conformidad con la reivindicación 15, caracterizado porque el servicio incluye contenido de audio.
MX2008003128A 2007-03-05 2008-03-05 Metodo y aparato para proporcionar un motor de administracion de derechos digitales. MX2008003128A (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/681,965 US20080219436A1 (en) 2007-03-05 2007-03-05 Method and apparatus for providing a digital rights management engine

Publications (1)

Publication Number Publication Date
MX2008003128A true MX2008003128A (es) 2009-02-25

Family

ID=39731969

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2008003128A MX2008003128A (es) 2007-03-05 2008-03-05 Metodo y aparato para proporcionar un motor de administracion de derechos digitales.

Country Status (4)

Country Link
US (1) US20080219436A1 (es)
EP (1) EP1986433A1 (es)
CA (1) CA2623089C (es)
MX (1) MX2008003128A (es)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7706534B2 (en) * 2006-02-28 2010-04-27 Nokia Corporation Pay per minute for DVB-H services
RU2339077C1 (ru) * 2007-03-13 2008-11-20 Олег Вениаминович Сахаров Способ функционирования системы условного доступа для применения в компьютерных сетях и система для его осуществления
US8239479B2 (en) * 2007-06-22 2012-08-07 Microsoft Corporation Server-assisted and peer-to-peer synchronization
US8721738B1 (en) 2007-11-02 2014-05-13 Timothy T. Miller System and method for ensuring security of data stored on data storage devices
US7930755B1 (en) * 2007-11-02 2011-04-19 Miller Timothy T System and method for ensuring security of data stored on electronic computing devices
EP2225848B1 (en) * 2008-03-10 2012-08-15 NDS Limited Key distribution system
KR101514840B1 (ko) * 2008-06-11 2015-04-23 삼성전자주식회사 휴대 방송 시스템에서의 암호화 키 분배 방법 및 이를 위한시스템
US8806198B1 (en) 2010-03-04 2014-08-12 The Directv Group, Inc. Method and system for authenticating a request
US9654829B1 (en) 2010-03-04 2017-05-16 The Directv Group, Inc. Method and system for retrieving data from multiple sources
JP5527912B2 (ja) * 2010-04-02 2014-06-25 サムスン エレクトロニクス カンパニー リミテッド ブロードキャストサービスの暗号化キー管理方法及びシステム
US9083998B2 (en) * 2010-11-30 2015-07-14 Arris Technology, Inc. Rights metadata caching by switched digital video multiplexers
US20130298155A1 (en) * 2012-05-03 2013-11-07 Rawllin International Inc. Video personal identification code for video on demand services
US9342666B2 (en) * 2012-10-31 2016-05-17 Intel Corporation Providing security support for digital rights management in different formats
KR20170011363A (ko) * 2015-07-22 2017-02-02 삼성전자주식회사 디스플레이 장치 및 디스플레이 방법
JP6872129B2 (ja) * 2015-11-27 2021-05-19 ソニーグループ株式会社 情報処理装置、情報処理方法、受信装置、および受信方法
US11165758B2 (en) * 2018-04-09 2021-11-02 International Business Machines Corporation Keystream generation using media data
EP3977687A4 (en) * 2019-05-30 2022-06-15 ZTE Corporation AUTHENTICATING A TWO-WAY RETRANSMISSION DETECTION

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7242772B1 (en) 2000-09-07 2007-07-10 Eastman Kodak Company Encryption apparatus and method for synchronizing multiple encryption keys with a data stream
KR100415109B1 (ko) * 2001-10-23 2004-01-13 삼성전자주식회사 셀룰러 무선통신 네트워크에서 상업적 방송 서비스 방법및 장치
US7243366B2 (en) * 2001-11-15 2007-07-10 General Instrument Corporation Key management protocol and authentication system for secure internet protocol rights management architecture
US7568111B2 (en) * 2003-11-11 2009-07-28 Nokia Corporation System and method for using DRM to control conditional access to DVB content
US20060059573A1 (en) * 2004-08-26 2006-03-16 International Business Machines Corporation Controlling with rights objects delivery of broadcast encryption content for a network cluster from a content server outside the cluster
KR100811046B1 (ko) * 2005-01-14 2008-03-06 엘지전자 주식회사 브로드캐스트/멀티캐스트 서비스에서 디지털 저작권관리방법
US9225698B2 (en) * 2005-05-12 2015-12-29 Nokia Technologies Oy Fine grain rights management of streaming content
EP1722564A1 (fr) * 2005-05-13 2006-11-15 Nagra France Sarl Méthode d'accès conditionnel local pour équipements mobiles
KR100704678B1 (ko) * 2005-06-10 2007-04-06 한국전자통신연구원 무선 휴대 인터넷 시스템에서의 그룹 트래픽 암호화 키갱신 방법
US7706534B2 (en) * 2006-02-28 2010-04-27 Nokia Corporation Pay per minute for DVB-H services
US20090180614A1 (en) * 2008-01-10 2009-07-16 General Instrument Corporation Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network

Also Published As

Publication number Publication date
CA2623089C (en) 2014-04-29
CA2623089A1 (en) 2008-09-05
EP1986433A1 (en) 2008-10-29
US20080219436A1 (en) 2008-09-11

Similar Documents

Publication Publication Date Title
CA2623089C (en) Method and apparatus for providing a digital rights management engine
US7266198B2 (en) System and method for providing authorized access to digital content
US7055030B2 (en) Multicast communication system
US7769177B2 (en) Method for managing digital rights in broadcast/multicast service
US7404082B2 (en) System and method for providing authorized access to digital content
JP4086782B2 (ja) ブロードキャスト・コンテンツへのアクセス
US7933414B2 (en) Secure data distribution
US20080065548A1 (en) Method of Providing Conditional Access
US8619993B2 (en) Content protection for OMA broadcast smartcard profiles
US20110158411A1 (en) Registering client devices with a registration server
US20070189535A1 (en) Method and apparatus for protecting contents supporting broadcast service between service provider and a plurality of mobile stations
US20060047976A1 (en) Method and apparatus for generating a decrpytion content key
CN1933393A (zh) 用于内容保护的实体间连接方法、设备和系统
CA2586172C (en) System and method for providing authorized access to digital content
US8468341B2 (en) System and method for content distribution with broadcast encryption
US8417933B2 (en) Inter-entity coupling method, apparatus and system for service protection
WO2010000786A1 (en) Process to ensure massive data diffusion security, and devices associated
EP2109314A1 (en) Method for protection of keys exchanged between a smartcard and a terminal

Legal Events

Date Code Title Description
FG Grant or registration