SISTEMA Y MÉTODO PARA PROPORCIONAR UN PROTOCOLO DE MANEJO DE CLAVE CON VERIFICACIÓN DE CLIENTE DE AUTORIZACIÓN
1. Campo de la Invención La presente invención se relaciona generalmente a una seguridad de red, y más específicamente a un método y sistema para proporcionar privacidad de cliente cuando solicita el contenido desde un servidor de aplicación.
2. Antecedentes de la Invención La Internet es una red insegura. Muchos de los protocolos utilizados en la Internet no proporcionan ninguna seguridad. Los datos que se transmiten sobre la Internet sin utilizar encriptación o cualquier otro tipo de esquema de seguridad se dice que se transmite "en la vía libre" . Las herramientas son fácilmente disponibles ya que permiten a los piratas informáticos "husmear" datos, tales como contraseñas, números de tarjetas de crédito, identidad y nombres del cliente, etc., estos se transmiten sobre la Internet en la vía libre. De este modo, las aplicaciones que envían datos desencriptados sobre la Internet son extremadamente vulnerables. Kerberos es un ejemplo de un protocolo de autenticación de red conocido, que se designa para proporcionar la autenticación para las aplicaciones de cliente/servidor utilizando criptografía de clave secreta. El protocolo Kerberos, que está disponible del Massachussets Institute of Technology, utiliza criptografía de modo que un cliente puede presuntamente proporcionar su identidad a un servidor (y viceversa) a través de una conexión de red insegura. Después de que un cliente y servidor ha utilizado Kerberos proporciona su identidad, también puede encriptar todas sus comunicaciones para presuntamente asegurar la privacidad e integridad de datos cuando conduzca sus negocios. — Esto es con respecto a estos y otros factores de información anterior relevante con el campo de seguridad de red que la presente invención ha abarcado.
SUMARIO DE LA INVENCIÓN La presente invención proporciona un método para proporcionar un cliente con una copia de datos de autorización que puede accesarse y utilizarse por el cliente. El método incluye las etapas de: recibir un mensaje de solicitud de servidor de autenticación (AS_REQ) de un cliente; generar un mensaje de respuesta de servidor de autenticación (AS_REP) enviar el AS_REP al cliente; recibir un mensaje de solicitud de servidor de concesión de pase (TGS_REQ) de cliente; generar un mensaje de respuesta de servidor de concesión de pase (TGS_REP) que tiene dos copias de datos de autorización; y enviar el TGS_REP con las dos copias de los datos de autorización al cliente. En otra modalidad, la presente invención proporciona un método que incluye las etapas de: generar un pase de servicio que incluye una primera copia de datos de autorización; generar una respuesta de servidor de concesión de pase que incluye el pase de servicio; y enviar la respuesta del servidor de concesión de pase y una segunda copia de los datos de autorización a un cliente. En una modalidad, la etapa de enviar la segunda copia de los datos de autorización incluyen encriptar al menos la segunda copia de los datos de autorización utilizando una clave de sesión de cliente de manera que el cliente es capaz de desencriptar y utilizar la segunda copia de los datos de autorización, y la etapa de generar el pase de servicio que incluye encriptar al menos los primeros datos de utilización utilizando una clave de servidor . En otra modalidad, la invención puede caracterizarse como un sistema para proporcionar una privacidad de cliente cuando se solicita contenido de un servidor de aplicación. El sistema incluye un centro de distribución de clave que se configura para generar una respuesta de servidor de posición de pase que incluye al menos dos copias de datos de autorización, en donde el centro de distribución de cable se acopla con un cliente configurado para recibir la respuesta del servidor de concesión de pase y para utilizar una copia de los datos de autorización para verificar la autorización, y donde el cliente se acopla con un servidor de aplicación configurado para suministrar contenido al cliente, en donde el cliente además se configura para verificar el uso autorizado del contenido que utiliza una de las copias de los datos de autorización. En otra modalidad, la invención puede caracterizarse como un sistema para proporcionar a un cliente con acceso al contenido y/o servicios. El sistema incluye medios para generar un pase de servicio que incluye una primera copia de datos de autorización; un medio para generar una respuesta de servidor de concesión de pase que incluye el pase de servicio y una segunda copia de los datos de autorización; y un medio para enviar la respuesta de servidor de concesión de pase a un cliente. El medio para generar la respuesta de servidor de concesión de pase puede incluir un medio para encriptar al menor la segunda copia de los datos de autorización que utiliza una clave de sesión de cliente y el medio para encriptar al menos el segundo dato de autorización puede incluir un medio para encriptar al menos la segunda copia de los datos de autorización de manera que el cliente es capaz de desencriptar y utilizar la segunda copia de los datos de autorización. El medio para generar el pase de servicio puede incluir un medio para encriptar al menos la primera copia de los datos de autorización que utiliza una clave de servidor. La segunda copia de los datos de autorización puede configurarse para permitir al cliente verificar una solicitud para servicios desde un servidor de aplicación. La segunda copia de los datos de autorización también puede configurarse para permitir al cliente determinar el uso autorizado del contenido recibido. Un mejor entendimiento de las características y ventajas de la presente invención se obtendrá mediante referencia a la siguiente descripción detallada de la invención y los dibujos anexos los cuales establecen una modalidad ilustrativa en la cual los principios de la invención se utilizan.
BREVE DESCRIPCIÓN DE LOS DIBUJOS Lo anterior y otros aspectos, características y ventajas de la presente invención serán más aparentes a partir de la siguiente descripción más particular de la misma, presentada junto con los dibujos siguientes en donde :
La FIGURA 1 representa un diagrama de bloque simplificado de un sistema hecho de acuerdo con una modalidad de la presente invención; la FIGURA 2 representa un diagrama de bloque simplificado de un sistema de acuerdo a una implementación de una modalidad de la presente invención; la FIGURA 3 representa un diagrama de flujo de un método para proporcionar a un cliente con una segunda copia de datos de autorización para el uso por el cliente. la FIGURA 4 representa un diagrama de flujo simplificado de una implementación de un proceso similar al proceso mostrado en la FIGURA 3 y la FIGURA 5 representa un diagrama de flujo simplificado de una implementación de un proceso para un cliente que solicita y recibe contenido y/o servicios desde un servidor de aplicación. Los caracteres de referencia correspondientes indican componentes correspondientes a través de las diversas vistas de los dibujos.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Los Kerberos sufren de la desventaja que una entidad de la red, tal como un cliente o servidor, no puede verificar los datos de autorización que se envían a un servidor de aplicación para accesar servicios y/o el contenido suministrado por el servidor de aplicación. En parte, los datos de autorización definen límites de los servicios y/o contenido para suministrarse al cliente. Los datos de autorización algunas veces son específicos en el servidor 106 de aplicación y el contenido y/o servicios proporcionados por el servidor 106 de aplicación. Debido a que el cliente no puede verificar la autorización, el cliente es incapaz de verificar la solicitud por los contenidos para asegurar que no existen opciones seleccionadas que no se autoricen. Adicionalmente , debido a que el cliente no puede verificar los datos de autorización, el cliente solicita comunicación e información adicional para determinar si el cliente se autoriza para copiar el contenido suministrado al cliente. Esto resulta en errores, tráfico de red en exceso y uso innecesario de recursos y procesamientos de red. Aún además, debido a que el cliente es incapaz de verificar los datos de autorización, el cliente es incapaz de determinar si el cliente está autorizado, por ejemplo, para reproducir el contenido más de una vez sin recibir comunicación e información adicional . La presente invención proporciona un método y sistema que supera estas y otras desventajas que suministran una copia de datos de autorización al cliente que el cliente puede accesar y utilizar para mejorar la eficiencia de red, reducir el tráfico de red, y contenido de steam line y/o acceso y uso de servicio. Suministrando a un cliente con una copia de cliente de los datos de autorización, el cliente es capaz de verificar las solicitudes evitando la inclusión de opciones ilegales en las solicitudes para contenido, y determinar a los clientes en uso autorizado del contenido y/o servicios suministrados, por ejemplo determinar si una copia de contenido suministrado puede guardarse, y determinar si el contenido puede reproducirse más de una vez. La presente invención es muy adecuada para los protocolos de manejo de clave que utilicen el concepto de pases, que son señales de autenticación encriptadas con una clave simétrica que permite a un cliente autentificar a un servidor específico. De acuerdo con una modalidad de la presente invención, un centro de distribución de clave (KDC) incluye dos copias de datos de autorización dentro de un pase de servicio cuando el KDC regresa el pase de servicio a un cliente, un servidor u otra entidad de la red. Una de las copias de la autorización, una copia de cliente, se configura de manera que el cliente (servidor u otra entidad) puede accesar a los datos de autorización para el uso por el cliente, y una de las copias de los datos de autorización, una copia de servidor, se suministra a un servidor de aplicación con una selección de contenido y/o una solicitud de clave del cliente. La presente invención supera las desventajas que Kerberos normales y otros protocolos previos, suministrando una copia de los datos de autorización que pueden accesarse y utilizarse por un cliente o servidor intentando obtener acceso al contenido y/o servicios proporcionados por un servidor de aplicación. Con referencia a la FIGURA 1, se ilustra un diagrama de bloque simplificado de un sistema 100 para proporcionar comunicación segura hecha de acuerdo con una modalidad de la presente invención. El sistema 100, que comprende un ejemplo de una implementación posible de la presente invención, utiliza un protocolo de manejo de clave de autenticación que proporciona seguridad y privacidad en una red, de manera que la Internet, una Intranet u otra red, que pueden escalar a millones de usuarios. En general, el sistema 100 involucra al menos un cliente 102 que interactúa con uno o más centros 104 de distribución de claves en (KDC) centralizados utilizando los algoritmos de clave pública y clave simétrica así como con servidor de aplicación individual, tal como el servidor 106 de aplicación (y el tercer servidor 140, véase FIGURA 2), utilizando algoritmos de claves simétrica. El protocolo es genérico y puede fácilmente adaptarse a aplicación diferentes que requieren autenticación en un ambiente distribuido. Además, puede ser de interfaz con una base de datos de usuario centralmente administrada. El cliente 102 puede comprender un proceso, la aplicación o dispositivo que hace uso de un servicio de red a nombre de un usuario. A modo de ejemplo, el cliente 102 puede comprender cualquier tipo de computadora, o el cliente 102 puede comprender un "cliente delgado" tal como un teléfono inalámbrico, buscapersonas , asistente digital personal (PDA) electrodoméstico casero que tiene un microprocesador de extremo bajo o sustancialmente cualquier otro dispositivo que tiene capacidades de procesamiento limitada o baja. Observe que en algunos casos, un servidor puede por si mismo ser un cliente de algún otro servidor (por ejemplo un servidor de impresión puede ser un cliente de un servidor de archivo) . El servidor 106 de aplicación proporciona un recurso a clientes de red. En la modalidad ilustrada, el KDC 104 incluye una primera etapa 108 y un segunda etapa 110. En una modalidad, la primera etapa es un servidor 108 de autenticación (servidor AS) y la segunda etapa es un servidor 110 de concesión de pase (servidor TGS) . El servidor 108 AS emite un pase de concesión de pase (pase TGT) al cliente 102 después de verificar sus credenciales. El servidor 110 TGS proporciona un pase de servicio de servidor de aplicación (pase ST) al cliente 102. El pase ST es un pase de servicio final que el cliente 102 presenta al servidor 106 de aplicación cuando el cliente 102 solicita un servicio. El servidor 106 de aplicación proporciona varios servicios al cliente 102, cuando el cliente 102 se autentifica para utilizar los pases ST. Los tipos de mensaje básicos utilizados por el sistema 100 son como sigue: (A) Mensaje de Solicitud de Servicio de
Autenticación (AS_REQ) : Mensaje del cliente 102 para solicitar el pase TGT del servidor 108 AS; (B) Mensaje de Respuesta de Servidor de
Autenticación (AS_REP) ; Mensaje de respuesta al cliente
102 del servidor 108 AS con el pase TGT; (C) Mensaje de Solicitud de Servidor de Consesión de Pase (TGS_REQ) : Mensaje del cliente 102 para solicitar un pase ST del servidor 110 TGS; (D) Mensaje de Respuesta de Servidor de Consesión de Pase (TGS_REP) : Mensaje de respuesta del servidor 110 TGS al cliente 102 con el pase ST; (E) Mensaje de Solicitud de Clave (KEY_REQ) : El mensaje se envía del cliente 102 al servidor 106 de aplicación para solicitar parámetros de seguridad (manejo de clave) ,- (F) Mensaje de Respuesta de Clave (KEY_REP) : El mensaje de respuesta del servidor 106 de aplicación al cliente 102 con la subclave y los datos específicos de aplicación; (H) Mensaje de Solicitud para Contenido y/o Servicios (CON_REQ) : El mensaje se envía desde el cliente 102 al servidor 106 de aplicación para solicitar el contenido y/o los servicios deseados; (I) Contenido (C0N_REP) : El mensaje se envía del servidor 106 de aplicación al cliente 102 que suministra el contenido y/o servicios deseados al cliente. El contenido se encripta típicamente antes de enviarse al cliente. Cada uno de los mensajes generalmente incluye un encabezado seguido por el cuerpo del mensaje, con el encabezado siendo común a los mensajes. A modo de ejemplo, el encabezado puede incluir un campo tipo mensaje, o campo de número de versión de protocolo y suma de comprobación. El campo tipo mensaje indica el tipo de mensaje, tal como AS_REQ, AS_REP, etc. Siguiendo el encabezado del mensaje está el cuerpo del mensaje que tiene la lista de atributos preferiblemente en formato de tipo-longitud-valor (TLV) .
El cliente 102 genera un mensaje AS_REQ para iniciar el intercambio de servicio de autenticación entre el cliente 102 y el servidor 108 AS (parte del KDC 104) cuando el cliente desea obtener un pase TGT, el cual es un pase para el servidor 110 TGS, también parte del KDC 104. En otras palabras, el mensaje AS_REQ se envía por el cliente 102 al servidor 108 AS para obtener el pase TGT el cual se utiliza por el cliente para solicitar pases ST para servidores de aplicación específica, tal como el servidor 106 de aplicación. A modo de ejemplo, el mensaje AS_REQ puede incluir la identidad del cliente (por ejemplo nombre) , la identidad del servidor 110 TGS y en esta ocasión asociarlo a una respuesta. También puede incluir una lista de algoritmos de encriptación simétricos que se soportan por el cliente 102. Para verificar nuevamente las repeticiones, este mensaje también puede incluir un reloj fechador, así como una firma para la integridad del mensaje. La firma puede ser una suma de comprobación tecleada o una firma digital. La clave pública para verificar una firma se mantiene preferiblemente en la base de datos de un usuario. Los certificados digitales pueden opcionalmente incluirse en el mensaje AS_REQ y pueden utilizarse en lugar de las claves públicas almacenadas para verificar las firmas digitales. La clave simétrica permanente del cliente 102 para verificar una suma de comprobación tecleada preferiblemente se mantiene en la misma base de datos de usuario. El mensaje AS_REQ también puede incluir la información de clave pública que es necesaria para acuerdos de clave (por ejemplo parámetros Elliptic Curve Diffie-Hellman) . A modo de ejemplo, Elliptic Curve también puede utilizarse para la encriptación de clave pública debido a su velocidad de procesamiento. El uso de Elliptic Curve típicamente es una o dos órdenes de magnitud más rápidas que otras encriptaciones , tal como RSA. La encriptación Rijndael normal puede utilizarse con la longitud de clave de 128 bites. El servidor 108 AS procesa el mensaje AS_REQ para verificarlo. Si el procesamiento AS_REQ no genera errores, el servidor 108 AS genera un mensaje AS_REP en respuesta al mensaje AS_REQ. Típicamente, el servidor 108 AS busca las claves del cliente 102 y el servidor 110 TGS en la base de datos y genera una clave de sesión de cliente aleatoria, para la autenticación subsecuente con el KDC 104. El servidor 108 AS genera un pase TGT. El pase TGT típicamente incluye una parte de vía libre y una encriptada. La identidad del servidor 110 TGS y el periodo de validez de pase pueden proporcionarse en la vía libre en lugar del pase TGT emitido. La parte encriptada del pase puede incluir información tal como el nombre del cliente 102, la clave de sesión de cliente y cualesquier otros datos para mantenerlo en privado. El pase TGT también puede proporcionar una lista de tipos de encriptación y tipos de suma de comprobación soportados por el KDC 104. La parte encriptada del pase puede encriptarse utilizando la clave secreta del KDC 104. En una modalidad, el mensaje AS_REP se firma mediante el KDC 104 utilizando un algoritmo que es idéntico a uno utilizado por el cliente 102 para generar una firma para el mensaje AS_ EQ . Esta firma puede ser ya sea una firma digital o una suma de comprobación tecleada utilizando la clave secreta del cliente 102. La información de clave pública es la parte pública del KDC 104 de los parámetros de acuerdo a la clave y deben indicar el mismo algoritmo de acuerdo con la clave como el seleccionado por el cliente 102. El mensaje AS_REP de preferencia también contiene esta ocasión que es una copia de la ocasión generada por el cliente en el mensaje AS_REQ, para prevenir repeticiones. En una modalidad, la parte encriptada del mensaje AS_REP proporciona el cliente 102 con acceso a sus propios datos de autorización. Suministrando al cliente con una copia del cliente de los datos de autorización proporciona una conveniencia al cliente (y usuario) debido a que si el cliente 102 conoce sus propios datos de autorización, este no tiene la intención de pretender ser retrasado teniendo la intención de simplemente rechazarse por un servidor de aplicación, ya que un servidor de aplicación acredita solamente la copia de información del cliente que se encripta dentro de un pase. También, para los clientes con seguridad hardware que prevén a un usuario de la piratería de piratas informáticos y cambiar sus propios datos de autorización, está característica puede ser una ventaja de seguridad debido a que los datos de autorización leíbles también pueden autorizar al cliente para algunas acciones locales, tal como el derecho de guardar y repetir el contenido (por ejemplo películas en un disco local). La copia de cliente de los datos de autorización recibidos en el mensaje AS_REP típicamente define las autorizaciones de cliente general y no es específico para servidores. El uso de la copia de cliente de los datos de autorización además se describe en lo siguiente. La parte encriptada del mensaje AS_REP también puede contener la identidad del cliente 102 para verificar que esta repetición originalmente se construyó por el KDC 104 para este cliente 102 particular. Los datos preferiblemente se encriptan con una clave simétrica derivada del algoritmo de acuerdo con la clave. El cliente 102 procesa el mensaje AS_REP para verificar su autenticidad y para desencriptar la parte de pase privado en el mensaje para obtener el pase TGT. si la autenticidad del mensaje AS_REP no puede verificarse, el cliente 102 preferiblemente no envía un mensaje de error de regreso al servidor 108 AS. En algunos casos, el cliente puede reintentar con otro mensaje AS_REQ. La presente invención opcionalmente permite el paso de certificados digitales en los mensajes AS_REQ y AS_REP, para permitir al cliente 102 y al KDC 104 autentificarse entre sí con certificados digitales. Sin los certificados, se espera que el cliente 102 ya este provisto con la clave pública KDC y que el KDC 104 ya tenga la clave pública del cliente 102 en su base de datos. Una firma digital en un AS_REQ se verifica por el KDC 104 con la clave pública del cliente que lo busca en su base de datos. El cliente 102 verifica una firma digital en un AS_REP con una clave pública KDC pre-provista . Después de que el cliente 102 ha obtenido un pase TGT mediante el intercambio de servidor 108 AS, el cliente 102 inicia el intercambio de mensajes TGS_REQ entre el cliente 102 y el servidor 110 TGS del KDC 104 cuando el cliente 102 desea obtener credenciales de autenticación para un servidor de aplicación particular o dado, tal como el servidor 106 de aplicación. El mensaje TGS_REQ se genera y envía por el cliente 102 al servidor 110 TGS para obtener un pase de servicio de servidor de aplicación (pase ST) que se utiliza en el mensaje EY_REQ (descrito además en lo siguiente) . El cliente 102 presenta el pase TGT obtenido del mensaje AS_REP como parte del mensaje TGS_REQ . El mensaje TGS_REQ especifica la identidad del servidor 106 de aplicación así como la identidad del cliente 102, que está típicamente dentro del pase TGT, y el cliente típicamente lo incluye en esta ocasión. En una modalidad, el cliente de identidad 102 se protege debido a que está en la parte encriptada del pase TGT y no se incluye en la parte de vía libre del mensaje. La clave de sesión del cliente del pase TGT puede utilizarse por la encriptación y desencriptación en el intercambio TGS_REQ. De este modo, un entrometido es incapaz de detectar que servicios se solicita por el cliente (por ejemplo un usuario) . El cliente 102 preferiblemente guarda el valor de la ocasión para más tarde validar el mensaje TGS_REP igualado del KDC 104. El cliente 102 preferiblemente mantiene el valor de la ocasión hasta que el valor de plazo configurable expira. Después del plazo, el cliente 102 ya no es capaz de procesar el TGS_REP correspondiente y tiene que reintentar. El servidor 110 de TGS verifica el mensaje TGS_REP y procesa el pase TGT. El servidor 110 de TGS entonces genera el mensaje TGS_REP en respuesta al mensaje TGS_REQ. El mensaje TGS_REP incluye el pase ST (el cual es el pase de servicio final) emitido por el KDC 104 que el cliente 102 presenta al servidor 106 de aplicación cuando el cliente intenta solicitar contenido y/o servicios. La identidad del servidor 106 de aplicación y el periodo de validez de pase pueden proporcionarse en la vía libre dentro del pase ST emitido. La parte encriptada del pase ST contiene el nombre del cliente 102 y una clave de sesión del servidor encriptada con una clave del servidor compartida por el servidor 106 de aplicación y el KDC 104. La parte encriptada del pase ST adicionalmente incluye una primera copia de datos de autorización (por ejemplo una copia de servidor) la cual en parte define los límites de los servicios y/o contenido para suministrarse al cliente. Los datos de autorización son específicos en el servidor 106 de aplicación y el contenido y/o servicios proporcionados por un servidor 106 de aplicación. En una modalidad, los datos de autorización contienen objetos específicos de servicio y/o contenido y los derechos para aquellos objetos. Cualesquier datos de cliente adicionales que se necesiten para privarse también pueden incluirse como parte de la parte encriptada del pase ST.
En una modalidad, el TGS_REP adicionalmente incluye una segunda copia de los datos de autorización (por ejemplo una copia de clientes) que se encripta utilizando la clave de sesión de cliente a partir del pase TGT generada por el servidor 108 AS en el mensaje AS_REP . Como se describió en lo anterior, la clave de sesión se conoce por el servidor 110 TGS y el cliente 102. Debido a que la segunda copia de los datos de autorización (la copia de cliente) se encriptan utilizando la clave de sesión del pase TGT, el cliente 102 puede desencriptar los datos de autorización y utilizar los datos de autorización tal como para propósitos de verificación y otros propósitos, como se describe en lo siguiente en detalle. La segunda copia de los datos de autorización recibidos en el mensaje TGS_REP pueden proporcionar más autorización específica, incluyendo más autorización específica de servidor, que una segunda copia de los datos de autorización recibidos en el mensaje AS_REP. Los datos de autorización recibidos en el mensaje AS_REP son más generales y definen autorizaciones de cliente específicos sin servidor, por ejemplo, si el cliente está autorizado para almacenar contenido . El mensaje TGS_REP se firma por el KDC 104 con una suma de comprobación tecleado utilizando la clave de sesión del pase TGT. El mensaje TGS_REP adicionalmente contiene esta ocasión que se copia del mensaje TGS_REQ, para prevenir repeticiones. A modo de ejemplo, el servidor 110 TGS puede generar el mensaje TGS_REP utilizando el procedimiento siguiente. Primero, la ocasión del mensaje TGS_REQ se incluye en el mensaje TGS_REP para asociarlo a la solicitud. Enseguida, el KDC 104 asigna el tipo de clave de sesión de pase aleatorio ST. Si más de un algoritmo de encriptación está disponible, el KDC 104 preferiblemente selecciona uno potente. El KDC 104 entonces genera el pase ST que incluye la primera copia, la copia de servidor, de los datos de autorización. La clave secreta del servidor 106 de aplicación se utiliza para encriptar la parte encriptada del pase ST y también genera la suma de comprobación tecleada sobre el pase ST total. El tiempo final del pase ST preferiblemente se determina por el KDC 104. El cliente 102 puede especificar un tiempo de vida más corto, si se desea. La parte encriptada del pase ST contiene la identidad del cliente 102, la primera copia de los datos de autorización, la clave de sesión y otros datos privados. El mensaje TGS_REP además incluye una porción de datos encriptados, en donde la clave de sesión del pase TGT se utiliza para generar la porción de datos encriptada. La porción de datos encriptada incluye la segunda copia de los datos de autorización, y una suma de comprobación tecleada, generada utilizando la clave de sesión TGT, puede agregarse sobre el mensaje TGS_REP. Nuevamente, esto es solo un ejemplo del procedimiento que el servidor 110 TGS puede utilizar para generar el mensaje TGS_REP que incluye dos copias de los datos de autorización . Debido a que el mensaje TGS__REP incluye dos copias de los datos de autorización, uno contiene la parte encriptada del pase ST y uno encriptado con la clave de sesión del pase TGT, el servidor 106 de aplicación así como el cliente 102 tienen acceso y pueden utilizar los datos de autorización. Esta forma de cliente es capaz de realizar chequeos y verificaciones sin la necesidad para comunicaciones adicionales y datos adicionales. La presente invención difiere de Kerberos, donde en Kerberos una respuesta KDC a la solicitud de pase de un cliente para un servidor de aplicación particular solo incluye una copia sencilla de los datos de autorización que sólo son accesibles al servidor de aplicación en la desencriptacion del pase ST. El cliente no tiene acceso a los datos de autorización y no puede utilizar los datos. Alternativamente, el KDC en la presente invención genera una respuesta a una solicitud de pase de un cliente para un servidor de aplicación particular incluyendo dos copias de los datos de autorización, una encriptada dentro del pase ST y una encriptada utilizando la clave de sesión de pase TGT de cliente permitiendo al cliente 102 desencriptar la segunda copia de los datos de autorización y utilizar los datos de autorización. En una modalidad, el cliente 102 incluye un módulo 122 de autorización. El módulo de autorización recibe la segunda copia de los datos de autorización y se configura para analizar los datos de autorización para determinar que y como el cliente se autorizó para utilizar el contenido y/o servicios proporcionados por el servidor 106 de aplicación. El módulo 122 de autorización puede implementarse a través del hardware, software o una combinación de hardware y software. En una modalidad, el módulo 122 de autorización es un módulo de hardware que decodifica la autorización extraída de los datos de autorización, verifica la autorización del cliente 102 para el contenido y/o servicios y procesos para desencriptar el contenido solicitado y/o para proporcionar servicios solo si el cliente no excede la autorización. Para resistir el ataque de piratas informáticos de software fuera del módulo de hardware, la clave secreta utilizada para verificar la suma de comprobación tecleada para los datos de autorización no se expone en el cliente fuera del módulo de hardware. Para lograr que, en una modalidad, el protocolo de manejo de clave completa se implemente dentro del mismo módulo 122 de hardware y las claves secretas o privadas no se expongan en la vía libre dentro del cliente exterior del módulo hardware . A modo de ejemplo, el cliente 102 puede utilizar el siguiente procedimiento para procesar el mensaje TGS_REP. En este ejemplo, "cliente" se refiere a cualquier cliente 102 por si mismo o al módulo 122 de autorización (cuando está presente dentro del cliente) . Un experto en la técnica deberá reconocer que un cliente con un módulo 122 de autorización típicamente no permite el proceso criptográfico para ocurrir fuera del módulo de autorización. Primero, el cliente 102 analiza el encabezado del mensaje TGS_REP. Si el análisis de encabezado falla, entonces el cliente 102 actúa como si el TGS_REP nunca se recibió. El cliente 102 preferiblemente no envía un mensaje de error de regreso al servidor 110 TGS . En algunos casos, el cliente 102 reintenta con otro mensaje TGS_REQ . Si existen mensajes TGS_REQ pendientes, el cliente 102 puede continuar esperando para una respuesta hasta un plazo y luego reintentar. Enseguida, el cliente 102 verifica el número de versión de protocolo en el encabezado. Si esta versión de protocolo no se soporta, el cliente 102 actúa como si el mensaje TGS_REP nunca se recibió. De otro modo, el cliente 102 entonces analiza el resto del mensaje. Si el formato de mensaje se encuentra que es ilegal, el cliente 102 actúa como si el mensaje TGS_REP nunca se recibió. Enseguida, el cliente 102 busca para reintentar un mensaje TGS_REQ con la misma ocasión. Si no hay igualación, el cliente procede como si el mensaje nunca se recibió. Si existe una igualación, entonces el cliente 102 verifica la suma de comprobación utilizando la clave de sesión de pase TGT . Si la suma de comprobación no se verifica, este mensaje se cae y el cliente 102 procede como si el mensaje nunca se recibió. El cliente entonces desencripta la parte del pase privado en el mensaje TGS_REP, utilizando la clave de sesión de pase TGT. Si la parte del pase privado no puede desencriptarse debido al tipo de clave de sesión de pase TGT y el tipo de datos encriptados no se iguala, un error fatal se reporta al usuario y el cliente 102 no reintenta. Si el texto vía libre resultante contiene errores de formato, contiene una clave de sesión con el tipo que no se soporta por el cliente 102, o contiene una identidad de cliente que no se iguala a la solicitud, un error fatal también se reporta al usuario y el cliente 102 no reintenta. Si el tipo de clave de sesión se soporta y el cliente es capaz de desencriptar la parte del pase privado del mensaje TGS_REP, el cliente extrae la segunda copia de los datos de autorización, verifica y retiene para su uso posterior. El cliente 102 entonces procesa el pase ST. Si existe un error en el pase ST, se reporta al usuario como un error fatal y el cliente 102 no intenta con otro mensaje TGS_REQ. Si ninguno de los errores de mensaje TGS_REP se detectan, el cliente 102 guarda el pase ST completo y la parte del pase privado de texto vía libre incluye la segunda copia de los datos de autorización en una nueva entrada en su memoria caché de pase . En una modalidad en donde un módulo 122 de autorización está presente dentro del cliente 102, el pase ST puede almacenarse fuera del módulo 122 de autorización dentro del cliente 102 debido a que el cliente no posee la clave de servidor para generar una suma de comprobación para una versión modificada del pase. Los datos de autorización pueden almacenarse dentro del módulo 122 de autorización o autentificarse con una suma de comprobación tecleada o una firma digital y luego almacenarse fuera del módulo dentro del cliente 102. Si los datos de autorización se almacenan fuera del módulo 122 de autorización (para minimizar los requerimientos de almacenaje del módulo), los intentos por un pirata informático para cambiar los datos de autorización se detectarán por el módulo 122 de autorización. Esto es debido a que la clave utilizada para generar la suma de comprobación tecleada o la firma digital para los datos de autorización no es leíble fuera del módulo 122 de autorización. Los mensajes KEY_REQ y KEY_REP se utilizan por el manejo de clave y la autenticación entre el cliente 102 y el servidor 106 de aplicación. El mensaje KEY_REQ se envía por el cliente 102 al servidor 106 de aplicación para establecer un nuevo juego de parámetros de seguridad. El mensaje KEY_REQ también puede utilizarse por el cliente 102 para establecer periódicamente nuevas claves con el servidor 106 de aplicación. El cliente 102 inicia con un pase válido ST, previamente obtenido en un mensaje TGS_REP. El servidor 106 de aplicación inicia con su clave de servicio que la puede utilizar para desencriptar y validar pases. El cliente genera el mensaje KEY_REQ que incluye el pase ST y la suma de comprobación tecleada necesitada para autentificar al cliente 102. El mensaje KEY_REQ preferiblemente también contiene una ocasión para asociarla al mensaje KEY_REP de respuesta y al reloj fechador de cliente para prevenir ataques de repetición. Cuando el cliente 102 genera el mensaje KEY_REQ, la primera copia de los datos de autorización y, en una modalidad, la identidad del cliente 102 están en la parte encriptada del pase ST. Después de que el cliente 102 envía el mensaje KEY_REQ, guarda el valor de ocasión de cliente para más tarde validar el mensaje KEY_REP igualado del servidor 106 de aplicación. El cliente 102 mantiene el valor de ocasión de cliente hasta que el valor de plazo configurable termina. Después del plazo, el cliente 102 ya no es capaz de procesar el mensaje KEY_REP correspondiente. El cliente 102 puede reintentar después de este plazo. El mensaje KEY_REP se envía por el servidor 106 de aplicación en respuesta al mensaje KEY_REQ . A modo de ejemplo, el mensaje KEY_REP puede incluir una o más subclaves aleatoriamente generadas, encriptadas con la clave de sesión compartida entre el cliente 102 y el servidor 106 de aplicación. El mensaje KEY_REP también puede incluir información adicional que se necesite para establecer parámetros de seguridad. El cliente 102 recibe el mensaje KEY_REP y procede el mensaje KEY_REP. El cliente analiza el resto del mensaje, iguala la ocasión en el KEY_REP con la ocasión del cliente KEY_REQ existente y verifica la suma de comprobación utilizando la tecla de sesión compartida entre el cliente 102 y el servidor 106 de aplicación. El cliente además desencripta la subclave de KEY_REP utilizando la clave de sesión compartida, verifica que una serie de cifras seleccionada sea aceptable, analice el objeto EncryptedDOI (autorización) genere la desencriptación de contenido y las claves de autenticación de la subclave y las guarde para usarlas más tarde. En una modalidad, el mensaje CON_REQ se envía por el cliente 102 al servidor 106 de aplicación una vez que el cliente recibe y verifica el EY_REP . En la generación del mensaje C0N_REQ el cliente accesa a la segunda copia desencriptada de los datos de autorización, en lo cual el cliente recibe y desencripta del mensaje y/o mensajes TGS_REP con el pase ST, y confirma los datos de autorización para asegurar que el mensaje CON_REQ no contiene opciones ilegales o no autorizadas. Por lo tanto, la interfaz del usuario de cliente se mejora y el usuario puede prevenirse de seleccionar opciones no autorizadas del gran comienzo, sin tener que enviar un mensaje CON_REQ al servidor y esperar por una respuesta. En una modalidad, si el cliente 102 de algún modo aún genera un mensaje CON_REQ no autorizado, el módulo 122 de autorización mantiene una clave simétrica necesitada para generar una suma de comprobación tecleada del mensaje CON_REQ y rechaza para generar esta suma de comprobación tecleada por un mensaje C0N_REQ que viola o excede la autorización del cliente como se definió por la segunda copia de los datos de autorización. Por lo tanto, un servidor 106 de aplicación típicamente no ve mensajes C0N_REQ no autorizados cuando se rechazan sin requerir el servidor 106 para verificar la autorización del cliente. La confirmación de los datos de autorización además optimiza el sistema evitando el procesamiento de mensajes no autorizados en el servidor 106 de aplicación y mejora la interacción del cliente con el usuario, permitiendo al usuario localmente evaluar la autorización sin esperar por un servidor 106 de aplicación de respuesta. En una modalidad, los mensajes C0N_REQ se encriptan utilizando la clave de sesión compartida entre el cliente 102 y un servidor 106 de aplicación. En la recepción del mensaje C0N_REQ el servidor 106 de aplicación procesa el mensaje C0N_REQ y valida la solicitud con la primera copia de los datos de autorización recibidos como parte del pase ST encriptado. Si no existen errores y la solicitud para el contenido no viola la autorización de los datos de autorización, el servidor 106 de aplicación genera el mensaje CON_REP e inicia el suministro de un contenido y/o servicio solicitado por el cliente. Típicamente, el contenido suministrado se encripta por el servidor 106 de aplicación utilizando la clave de sesión compartida entre el cliente 102 y el servidor 106. El cliente 102 recibe el contenido, desencripta el contenido y comienza a procesar y utilizar el contenido. En una modalidad, debido a que el cliente 102 tiene una copia de los datos de autorización, el cliente puede determinar el uso autorizado del contenido y/o servicios recibidos. Por ejemplo, el cliente 102 puede determinar verificando los datos de autorización si o no el cliente se autoriza para almacenar o guardar una copia del contenido. El módulo 122 de autorización verifica los datos de autorización y determina la autorización del cliente. Si el cliente se autoriza, el cliente puede guardar el contenido como se recibió y desencripto. Adicionalmente , debido a que el cliente tiene una copia de los datos de autorización, el cliente 102, en una modalidad a través del módulo 122 de autorización además puede determinar verificando la autorización si o no el cliente puede reproducir o reutilizar el contenido más que de una vez. El módulo 122 de autorización típicamente contiene las claves de desencriptación contenidas o almacenadas y rechaza al desencriptar el contenido sin la autorización adecuada. La capacidad para determinar que la autorización del cliente se logre utilizando la segunda copia de los datos de autorización el cliente 102 recibido en el mensaje TGS_REP y almacenado para el uso local. Esto mejora la operación del cliente y los límites de comunicación a través de la red. En una modalidad, el sistema 100 no requiere el intercambio TGS_REQ y TGS_REP para que ocurra en orden de importancia para que el cliente obtenga un pase ST y una copia de cliente de los datos de autorización. El cliente 102 envía un AS_REQ para un pase de servicios en un servidor específico, por ejemplo el servidor 106 de aplicación. El DC 104 procesa AS_REQ y regresa el pase ST para el primer servidor de aplicación, el cual incluye la primera copia de los datos de autorización. El KDC además envía la segunda copia de los datos de autorización al cliente formateado para accesarse y utilizarse por el cliente 102. Típicamente, el KDC 104 regresa un AS_REP que incluye el pase ST con la primera copia de los datos de autorización, y la copia del cliente de los datos de autorización. De este modo, el cliente aún obtiene la copia de cliente de los datos de autorización junto con el pase ST sin enviar el TGS_REQ . La FIGURA 2 representa un diagrama de bloque simplificado de un sistema 101 de acuerdo a una implementación de una modalidad de la presente invención. En una modalidad, el cliente 102 accesa al tercer servidor 140 para seleccionar el contenido y/o servicios deseados y luego accesar al servidor 106 de aplicación para actualmente recibir el contenido y/o servicios seleccionado. En la selección del contenido y/o servicios, el cliente 102 utiliza la copia de cliente de los datos de autorización. Previo al envío de una selección para el contenido y/o servicios al tercer servidor 140, el cliente determina el contenido y/o servicios deseados, y luego verifica la copia de cliente de los datos de autorización para evitar hacer una selección que exceda la autorización del cliente. El cliente 102 luego envía el selección de contenido y/o servicios al tercer servidor 140. El tercer servidor 140 entonces verifica el selección de contenido y/o servicios y envía un mensaje de respuesta de selección de contenido y/o servicios al cliente 102 incluyendo la información que se utiliza por el servidor 106 de aplicación para autorizar al cliente y permitir al cliente ganar acceso al contenido y/o servicios seleccionados. De este modo, el cliente 102 hace referencia a los datos de autorización y evita la autorización solicitada por el contenido y/o servicios del tercer servidor 140 que solo será rechazado por el servidor 106 de aplicación cuando el servidor de aplicación intente determinar la autorización del cliente basada en la tercera información de servidor.
En una modalidad, el tercer servidor 140 de aplicación adicionalmente incluye una autenticación de la tercera información. Esta autenticación adicionalmente se regresa por el cliente 102 al servidor 106 de aplicación, típicamente en un mensaje KEY_REQ. El servidor 106 de aplicación utiliza está autenticación para autentificar la tercera información de servidor suministrada por el servidor de aplicación por el cliente 102 para asegurar que la información utilizada para utilizar el cliente se suministra actualmente al cliente del tercer servidor 140 y ninguna otra entidad de red, o ninguna otra información falsa generada por el cliente. En el envío del mensaje KEY_REQ al servidor 106 de aplicación, el cliente 102 incluye la tercera información de servidor y la autenticación si se suministra al cliente. El servidor 106 de aplicación procesa el mensaje KEY_REQ, autentifica la tercera información de servidor, y utiliza la información para verificar la autorización del cliente. Una vez autentificado y verificado, el servidor 106 de aplicación genera el KEY_REP como se describió en lo anterior. Con referencia a la FIGURA 3, se ilustra un diagrama de flujo de un método 200 para proporcionar un cliente con una segunda copia de datos de autorización para el uso por el cliente cuando solicita y utiliza el contenido y/o servicios de un servidor de aplicación. A modo de ejemplo, el método 200 puede implementarse por el sistema 100 y los tipos de mensaje apropiados descritos en lo anterior. En la etapa 202 una solicitud para un pase TGT se recibe a partir de un cliente, tal como el cliente 102. En la etapa 204 el pase TGT se genera. La etapa 204 puede realizarse, por ejemplo, mediante un servidor 108 AS. En la etapa 206 el pase TGT se envía al cliente. Esta etapa también se realiza por el servidor 108 AS. En una modalidad, el cliente extrae la copia de cliente de los datos de autorización, si la copia de cliente de los datos de autorización se incluye con el AS_REP . En la etapa 208 una solicitud para un pase ST para un servidor de aplicación particular se recibió del cliente. La solicitud para el pase ST incluye el pase TGT y típicamente no proporciona la identidad de cliente en la vía libre. En la etapa 210 un mensaje TGS_ EP se genera incluyendo un pase ST con una primera copia de los datos de autorización encriptados dentro del pase ST, y una segunda copia de los datos de autorización encriptados utilizan la clave de sesión del pase TGT. En una modalidad, la generación de TGS_REP se realiza por el servidor 110 TGS . En la etapa 210 un mensaje TGS_REP se envía al cliente sin copias de los datos de autorización, que también pueden realizarse por el servidor 110 TGS. En la etapa 214, el cliente recibe el TGS_REP. En la etapa 216, el cliente extrae al menos la segunda copia de los datos de autorización del TGS_REP . En la etapa 220 el cliente genera y envía un mensaje KEY_REQ que incluye el pase ST, el cual además incluye la primera copia de los datos de autorización. En la etapa 222 el servidor de aplicación recibe y procesa el KEY_REQ . El servidor de aplicación extrae el pase ST, desencripta el pase ST y valida la primera copia de los datos de autorización. En la etapa 224, el servidor de aplicación genera un mensaje EY_REP y envía el mensaje KEY_REP al cliente. En la etapa 226 el cliente verifica el mensaje KEY_REP y lo iguala con un mensaje KEY_REQ. La FIGURA 4 representa un diagrama de flujo simplificado de una implementación de un proceso 240, similar al proceso 200 representado en la FIGURA 3. En la etapa 242, el cliente envía la solicitud del pase TGT. En la etapa 244, el KDC 104 genera el pase TGT. En la etapa 446, el KDC 104 envía el pase TGT con una copia de cliente de los datos de autorización de cliente. En la etapa 248, el cliente recibe el pase TGT y extrae una copia de cliente general de los datos de autorización. En la etapa 250, el cliente 102 envía el TGS_REQ que solicita el pase ST. En la etapa 252, el KDC regresa al TGS_REP. En la etapa 254, el cliente recibe el TGS_REP y extrae el pase ST y la segunda copia específica de servidor de los datos de autorización. En la etapa 256, el cliente determina el contenido y/o servicios que se desean, entonces accesa la copia de cliente de los datos de autorización y verifica el contenido y/o servicios deseados para evitar que solicite el contenido y/o servicios que exceden la autorización. En la etapa 256, el cliente 102 envía una selección de contenido y/o servicios al tercer servidor 140. En la etapa 260, el tercer servidor envía la respuesta de selección de contenido y/o servicios que incluye la tercera información utilizada para la autorización de un cliente y una autenticación de está información (por ejemplo una suma de comprobación tecleada) . La tercera información incluye una información que puede utilizarse para verificar la autorización del cliente, por ejemplo: la identificación del contenido seleccionado por el cliente; varias opciones de compra asociadas con el contenido, tal como "cargo para una tarjeta de crédito", "permitir al cliente guardar este contenido" y otra información. La tercera información también puede incluir restricciones asociadas con el contenido, tal como una lista de regiones de apagón (por ejemplo regiones de apagón basadas en los países, estados o códigos postales) y otras restricciones. En la etapa 262, el cliente 102 envía un mensaje KEY_REQ al servidor 106 de aplicación que no excede los datos de autorización. El mensaje KEY_REQ incluye la tercera información junto con su autenticación y el pase ST, el cual además incluye la primera copia de los datos de autorización. En la etapa 264, el servidor 106 de aplicación autentifica la información, verifica la autorización de cliente para el contenido y/o servicios que utiliza la tercera información y la primera copia de los datos de autorización. En la etapa 266 el servidor 106 de aplicación envía el KEY_REP al cliente 102. La FIGURA 5 representa un diagrama de flujo simplificado de una implementacion de un proceso 310 para que un cliente solicite y reciba el contenido y/o servicios de un servidor de aplicación. En una modalidad, el proceso 310 sigue la etapa 226 del proceso 200, como se muestra en la FIGURA 3, suministrando a un cliente con una segunda copia de los datos de autorización. En la etapa 312, el cliente, tal como un cliente 102 determina qué contenido y/o servicio se desea. Por ejemplo, el cliente recibe una solicitud para el contenido de un usuario u otra entidad de red. En la etapa 314, el cliente verifica la solicitud para el contenido y/o servicios para asegurar que la solicitud se autorice y no exceda el uso autorizado, verificando y comprobando la solicitud para el contenido con la segunda copia de los datos de autorización previamente obtenidos y almacenados. Una vez que el cliente verifica la solicitud, el cliente genera el mensaje CON_REQ . En la etapa 316, el cliente encripta, autentifica con la suma de comprobación tecleada y envía el mensaje CON_REQ a un servidor de aplicación, tal como el servidor 106 de aplicación (o un tercer servidor 140) . En la etapa 320, el servidor de aplicación desencripta el mensaje C0N_REQ y valida la solicitud basada en la suma de comprobación tecleada así como el acceso autorizado del cliente como se definió en la primera copia de los datos de autorización encontrados dentro del pase ST . En la etapa 322, el servidor de aplicación encripta y envía el contenido y/o servicios solicitados si el pase ST y los datos de autorización se verifican. En una modalidad, el servidor de aplicación envía y solicita el contenido en una pluralidad de paquetes diferentes tales que el contenido deseado completo no se incluye en un paquete sencillo sino en varios paquetes. En la etapa 324, el cliente recibe el contenido solicitado y procesa los datos. En la etapa 330, el cliente accesa la segunda copia de los datos de autorización que se han almacenado y determina si el cliente puede almacenar una copia del contenido y/o servicios. En la etapa 332, el cliente almacena el contenido y/o servicios si el cliente se autoriza para hacerlo. Sino, el cliente se le permite el acceso a los contenidos cuando se recibe la primera vez, y el proceso procede a la etapa 340 para buscar el contenido adicional. De otra manera, la etapa 334 se ingresa cuando el cliente determina si puede reproducir el contenido más de una vez. Si es si, la etapa 336 se ingresa donde el cliente pueda accesar y reproducir el contenido una o más veces. En la etapa 340, el proceso determina si existe contenido y/o servicios adicionales para recibirse. Si es si, el proceso 310 regresa a la etapa 324 para recibir el contenido y/o servicios adicionales. Si en la etapa 336, se determina que no hay datos y/o contenidos adicionales el proceso 310 termina. La presente invención proporciona un método, sistema, aparato, programa y producto de programa de computadora que permite a un cliente almacenar y accesar sus propias copias de datos de autorización. Esto se proporciona para mejorar la interfaz de usuario, errores reducidos, eficiencia y optimización mejoradas del contenido y/o suministro de servicios. Además, permite al cliente accesar su propia copia de los datos de autorización, permite al cliente hacer determinaciones acerca del procesamiento y utilización del contenido y/o servicios suministrados. Aún más, reduce la cantidad necesaria de comunicación y reduce el tráfico de red total. En una modalidad, la presente invención se implementa en un protocolo de corredor de seguridad electrónico (ESBroker) desarrollado por Motorola Inc., y como parte de un sistema de manejo de derecho IP también se desarrolla por Motorola Inc. Aunque la invención aquí descrita ha sido descrita por medio de las modalidades y especificaciones específicas de la misma, numerosas modificaciones y variaciones pueden hacerse a la misma por aquellos expertos en la técnica sin apartarse del alcance de la invención establecida en las reivindicaciones.