ES2589112T3 - Gestión de claves para comunicación segura - Google Patents
Gestión de claves para comunicación segura Download PDFInfo
- Publication number
- ES2589112T3 ES2589112T3 ES07852199.4T ES07852199T ES2589112T3 ES 2589112 T3 ES2589112 T3 ES 2589112T3 ES 07852199 T ES07852199 T ES 07852199T ES 2589112 T3 ES2589112 T3 ES 2589112T3
- Authority
- ES
- Spain
- Prior art keywords
- key
- seat
- information
- party
- management functionality
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Abstract
Un método para establecer una comunicación segura entre partes de una red de comunicación, en el que cada parte es capaz de realizar un procedimiento de arranque en función de credenciales locales, donde el arranque crea una clave compartida entre cada parte y una función de arranque asociada caracterizada por las etapas de: - recibir en la parte iniciadora la primera información de clave, en función de dicho procedimiento de arranque, y un asiento como respuesta a la solicitud de sesión enviada a una primera funcionalidad de gestión de claves; - almacenar dicha primera información de clave en dicha primera funcionalidad de gestión de clave, en donde se hace referencia a dicha información de clave con un identificador incluido en dicho asiento; - generar, a partir de la primera información de clave, una primera clave de sesión; - enviar el asiento a al menos una parte respondedora; - reenviar de la al menos una parte respondedora el asiento o partes del mismo a una segunda funcionalidad de gestión de claves; comunicar a la segunda funcionalidad de gestión de claves con dicha primera funcionalidad de gestión de claves para resolver el asiento en la segunda información de clave, en donde dicha comunicación incluye recuperar, en la primera funcionalidad de gestión de clave, la primera información de clave mediante el uso del identificador, y proporcionar a la segunda funcionalidad de gestión de claves información basada en la primera información de clave; - recibir en la al menos una parte respondedora, la segunda funcionalidad de gestión de claves, dicha segunda información de clave, y generar a partir de esta una segunda clave de sesión; el uso, de la parte emisora y al menos una parte respondedora, de la primera y segunda claves de sesión para una comunicación segura.
Description
5
10
15
20
25
30
35
40
45
50
55
DESCRIPCION
Gestion de claves para comunicacion segura Campo de la invencion
La invencion se encuentra en el campo de establecer una comunicacion segura entre puntos finales. En particular, la invencion elimina el requisito de que ambos puntos finales utilicen el mismo tipo de credenciales basicas.
Antecedentes de la invencion
Muchas tecnologfas de acceso tales como GSM, WCDMA, WLAN, WiMAX proporcionan una seguridad basica para el primer salto, es decir, la comunicacion entre el dispositivo de usuario y un punto de acceso de la red. La comunicacion puede utilizar la capa 2 o la capa 3 de la pila de protocolos. SRTP (RFC3711) y MIKEY (RFC3830) son ejemplos de protocolos para la seguridad de medios y la gestion de claves. MIKEY puede basarse tanto en claves previamente compartidas como en PKI. Adicionalmente, MIKEY puede integrarse en una senalizacion de configuracion de sesion (SIP o RTSP) mediante el uso de RFC4567.
No obstante, la seguridad basica proporcionada por estas tecnologfas de acceso no siempre puede considerarse lo suficientemente segura. De hecho, algunas tecnologfas de acceso no proporcionan ninguna seguridad basica, p. ej., 802.3/Ethernet o DSL.
Por lo tanto, hay una necesidad de proporcionar mecanismos de seguridad adicionales o mejorados en muchas tecnologfas de acceso.
Un problema con los abordajes existentes a la gestion de claves se refiere a la presuncion de que ambos puntos finales utilizan el mismo tipo de credenciales basicas. No obstante, esta presuncion no siempre resulta acertada, como es el caso en, p. ej., la convergencia fijo-movil (FMC, por sus siglas en ingles). En la FMC, uno de los usuarios puede ser un suscriptor de 3GPP que utiliza una credencial basada en SIM, p. ej., SIM, USIM, ISIM y el otro puede ser, p. ej., un usuario de acceso por cable que implementa credenciales basadas en PKI.
Tambien hay determinados problemas con la integracion de la gestion de claves en los protocolos de senalizacion conocidos.
Otro ejemplo que presenta un problema se refiere a "medios previos", lo que significa que los medios pueden empezar a fluir desde el respondedor antes de haber finalizado las operaciones de gestion de claves segun, p. ej., MIKEY a traves de SIP. Por lo tanto, si bien MIKEY puede llevarse a cabo dentro de la banda con SIP, puede no haber ninguna clave disponible para proteger los primeros paquetes. La alternativa, el uso de la gestion de claves de medios dentro de la banda resolvena este problema, pero es desfavorable, p. ej., desde el punto de vista del firewall transversal. Ademas, no coincide con la practica de la ingeniena de sonido el transporte de senalizacion en la via de los medios.
Otro problema con los metodos conocidos para la gestion de claves se refiere a la “bifurcacion”, donde el iniciador, p. ej., de una llamada de telefoma multimedia (MMTEL) puede no estar seguro de que terminal utilizara para contestar el otro punto final. Aunque todas las terminales para contestar la llamada tengan una PKI activada, las terminales diferentes pueden utilizar distintas claves publicas y, por lo tanto, el iniciador puede no saber que clave utilizar para una solicitud de invitacion. Mas precisamente, segun metodos conocidos, la gestion de claves no puede iniciarse hasta que el respondedor haya contestado y tampoco puede determinarse una clave publica adecuada hasta entonces. Tal como se menciono anteriormente, la gestion de claves de medios dentro de la banda puede paliar el problema, pero es desfavorable, como ya se menciono.
Aun otro problema con metodos conocidos de gestion de claves es que algunos servicios de IMS son entre pares (P2P) mientras que otros proporcionan servicios grupales, p. ej., pulsa y habla por celular (PoC). Exigir que los usuarios gestionen claves grupales genera problemas y, de hecho, un usuario ni siquiera puede estar seguro de que todos los miembros del grupo contesten a una invitacion y participen en la sesion. Por lo tanto, en este caso, es necesario realizar una distincion entre miembros que podnan encontrarse en una sesion grupal y los miembros que participan de la sesion grupal, dado que, p. ej., puede ser favorable distribuir claves de sesion solamente a los miembros que de hecho participan.
Un problema adicional con la tecnica previa es que algunos servicios, p. ej., mensajena, pueden gestionarse de formas distintas, dependiendo de si el respondedor se encuentra en lmea o no. Por ejemplo, un mensaje instantaneo (IM, por sus siglas en ingles) puede convertirse automaticamente en un mensaje diferido (DM, por sus siglas en ingles) para una entrega posterior, si el usuario no se encuentra en lmea. El remitente puede no saber si la otra parte se encuentra en lmea y, por lo tanto, puede no saber que gestion de claves es adecuada al momento de enviar el mensaje. Las soluciones basadas en S/MIME podnan paliar la situacion, pero S/MIME no es adecuado para medios en tiempo real tales como MMTEL. Por lo tanto, el abordaje de gestion de claves puede pasar a depender del servicio de IMS que se utilice, lo que no es deseable. Ademas, S/MIME carece de soporte para claves compartidas previamente (p. ej., SIM) y no proporciona proteccion contra la reproduccion debido al hecho de que no hay ningun
5
10
15
20
25
30
35
40
45
50
55
concepto de sesion en el que puedan correlacionarse dos mensajes protegidos por S/MIME.
US-2007/0101122-A1 describe un abordaje para la generacion de claves de sesion de aplicaciones dentro de un modulo seguro de una terminal de usuario. Se describe la arquitectura generica de arranque (GBA, por sus siglas en ingles) en 3GPP2.
WO-2005/078988 describe el establecimiento de una clave de sesion secreta compartida entre dos elementos de red, es decir, no terminales de usuario, para una comunicacion segura entre st
Compendio
Un objetivo general de la invencion es superar las deficiencias de los metodos conocidos de establecer una comunicacion segura entre una parte iniciador y una parte respondedora mediante el establecimiento de claves compartidas entre los puntos finales que podnan utilizarse de forma directa para la proteccion de medios o formar la base del establecimiento de claves de extremo a extremo.
Es un objeto establecer claves para la comunicacion segura entre la parte iniciante y respondedora que proporcionen una independencia del tipo de credenciales utilizado por la parte respectiva para la gestion de seguridad.
Segun la invencion, un servidor de gestion de claves, KMS (por sus siglas en ingles), con la capacidad de establecer una clave compartida con un dispositivo de usuario, proporciona al usuario un asiento e informacion de generacion de claves como respuesta a una solicitud de clave. Habiendo recibido dicha informacion, un primer usuario calcula una clave de sesion y transmite el asiento a una segunda parte en una solicitud de comunicacion. Como respuesta a la recepcion del asiento, la segunda parte establece una comunicacion segura con la misma entidad de KMS u otra, y proporciona el asiento. Como respuesta a esto, el mismo KMS u otro devuelve informacion de generacion de claves. En funcion de dicha informacion de generacion de claves, tanto la primera como la segunda parte generan una clave de sesion en comun.
La integridad del asiento se encuentra protegida, de manera favorable, por la entidad de KMS emisora y puede incluir ademas metadatos, por ejemplo, identidades de partes implicadas, momento de creacion, numero de secuencia, tiempo de validez, tipo de uso, tal como pulsa y habla por celular o telefoma, tipo de comunicacion, p. ej., entre pares o comunicacion grupal. Ademas, el asiento puede incluir copias de claves de sesion y otra informacion que requiera encriptarse, por ejemplo, para proteger la privacidad.
En una realizacion de la invencion, la capacidad de establecer una clave compartida se basa en el procedimiento de GBA donde una funcionalidad de BSF de red y usuario se proporcionan con un secreto compartido basico, p. ej., un secreto basado en SIM/USIM/ISIM. La entidad de KMS, de acuerdo con esta realizacion, actua como una entidad de NAF hacia la entidad de BSF.
Segun otra realizacion, las claves de sesion generadas por la primera y segunda partes respectivas son distintas, y mediante estas se dispone una parte intermediaria para generar ambas claves para una comunicacion segura con cada una de la primera y segunda parte, donde la parte intermediaria es capaz de procesar un mensaje de la primera a la segunda parte, primero, al decodificar el mensaje y, luego del procesamiento, volver a encriptar el mensaje. En particular, la generacion de claves en la parte intermediaria se basa en un asiento recibido de la primera parte que, luego de la generacion de la clave, se reenvfa a la segunda parte para una generacion correspondiente de una clave de sesion.
En aun otra realizacion, la segunda parte se ve representada por un grupo de segundas partes y la parte intermediaria, mediante el uso de un asiento, genera primero una clave maestra y, en base a la clave maestra, genera claves de sesion individuales y asientos para cada miembro del grupo de segundas partes. La parte intermediaria, luego de la generacion de la clave, reenvfa el asiento a cada una de las segundas partes, y cada una de ellas, luego, genera claves individuales correspondientes de sesion. El grupo de segundas partes puede obtenerse en la parte intermediaria al resolver una identidad de grupo o identificar un grupo predefinido tal como lo especifico la primera parte.
En aun otra realizacion, la parte intermediaria no procesa informacion recibida de la primera parte y, por lo tanto, no precisa generar claves separadas para la comunicacion con cada una de la primera y segunda partes. En esta realizacion, la parte intermediaria reenvfa el asiento recibido de la primera parte a cada una de las segundas partes del grupo, mediante lo cual la primera y cada una de las segundas partes pueden generar una clave de sesion compartida para una comunicacion segura de extremo a extremo. Con la finalidad de eliminar la posibilidad de interceptar el asiento en una parte intermediaria y utilizar el asiento interceptado para solicitar una funcionalidad de KMS para resolver el asiento en una clave de sesion, se proporciona a la entidad de KMS una funcionalidad para verificar que un usuario, para el cual se resuelve un asiento, es un miembro del grupo.
Un mensaje de la primera parte destinado a una segunda parte puede almacenarse en una entidad de red para una entrega diferida. Por ejemplo, la parte intermediaria puede descubrir que al menos una segunda parte no esta registrada en la red y puede, por lo tanto, almacenar un mensaje para una entrega posterior, junto con un asiento.
5
10
15
20
25
30
35
40
45
50
Una vez registrada la al menos una segunda parte, la entidad de red que almacena temporalmente un mensaje puede continuar el protocolo tal como se describio anteriormente y finalmente empujar el mensaje y asiento asociado hacia la parte destinataria.
Segun una realizacion, la invencion se implementa en un entorno de IMS 3GPP.
Segun un aspecto, se proporciona un metodo para establecer una comunicacion segura entre partes de una red de comunicacion, en el que cada parte es capaz de realizar un procedimiento de arranque en funcion de credenciales locales, donde el arranque crea una clave compartida entre cada parte y una funcion de arranque asociada. El metodo comprende las etapas de:
- recibir en la parte iniciadora la primera informacion de clave, en funcion de un procedimiento de arranque inicial, y un asiento como respuesta a la solicitud de una primera funcionalidad de gestion de claves;
- almacenar dicha primera informacion de clave en dicha primera funcionalidad de gestion de clave y hacer referencia a dicha primera informacion de clave con un identificador incluido en dicho asiento;
- generar, a partir de la primera informacion de clave, la primera clave de sesion;
- enviar el asiento a al menos una parte respondedora;
- reenviar de la al menos una parte respondedora el asiento o partes del mismo a la segunda funcionalidad de gestion de claves;
- comunicar a la segunda funcionalidad de gestion de claves con la primera funcionalidad de gestion de claves para resolver el asiento en la segunda informacion de clave, donde dicha comunicacion incluye recuperar, en la primera funcionalidad de gestion de clave, la primera informacion de clave mediante el uso del identificador, y proporcionar a la segunda funcionalidad de gestion de claves informacion basada en la primera informacion de clave;
- recibir en la al menos una parte respondedora, de la segunda funcionalidad de gestion de claves, una segunda informacion de clave, y generar a partir de esta una segunda clave de sesion;
- el uso, de la parte emisora y al menos una parte respondedora, de la primera y segunda claves de sesion para una comunicacion segura.
Segun otro aspecto de la invencion, se proporciona un aparato de gestion de claves. El aparato de gestion de claves brinda soporte a la generacion de claves de sesion para una comunicacion segura entre partes de una red de comunicaciones. El aparato tiene medios de procesamiento y comprende:
- medios para generar una primera informacion de clave y un asiento como respuesta a una solicitud de una primera parte, donde se hace referencia a la primera informacion de clave mediante un identificador incluido en el asiento;
- medios para la comunicacion del asiento a la primera parte,
- medios para almacenar la primera informacion de clave y el identificador,
- medios para comunicarse con un segundo aparato de gestion de claves para resolver un asiento recibido en una segunda informacion de gestion de claves, donde dicha comunicacion incluye recuperar la primera informacion de clave mediante el uso del identificador, y proporcionar a la segunda funcionalidad de gestion de claves informacion basada en la primera informacion de clave.
Descripcion detallada.
La siguiente descripcion establece detalles espedficos, tales como realizaciones, procedimientos, tecnicas, etc. particulares, con fines explicativos y no taxativos. En algunas instancias, se omiten descripciones detalladas de metodos, interfaces, circuitos y dispositivos conocidos, a fin de no complicar la descripcion con detalles innecesarios. Adicionalmente, se muestran bloques individuales en algunos de los dibujos. Podra observarse que las funciones de dichos bloques pueden implementarse mediante el uso de circuitos individuales de hardware, mediante el uso de programas de software y datos, junto con un microprocesador digital programado de manera adecuada o computadora de uso general, mediante el uso de circuitos integrados espedficos de la aplicacion y/o mediante el uso de uno o mas procesadores de senal digital.
Con la finalidad de ilustrar la gestion de claves de seguridad, se utiliza la arquitectura 3GPP GBA/GAA. No obstante, se aprecia facilmente a partir de la descripcion que puede utilizarse cualquier otro metodo para gestionar claves de seguridad que proporcione la generacion de una clave compartida entre un UE de usuario y un servidor de aplicacion, p. ej., NAF 160. Por ejemplo, un UE que soporta credenciales basadas en PKI podna utilizar TLS para crear una clave compartida con el servidor de la aplicacion. En una arquitectura a base de nombre de
5
10
15
20
25
30
35
40
45
50
55
usuario/contrasena, podna utilizarse el estandar PKCS#5 para establecer una clave compartida, etc.
La Figura 1 ilustra el despliegue de la tecnica previa de GBA/GAA a traves de un proxy de autenticacion 160 que actua como una funcion de aplicacion de red nAf (por sus siglas en ingles) contra la infraestructura GBA/GAA. Una funcion generica de servidor de arranque 110 BSF y un equipo de usuario 101 UE autentican de forma manual mediante el uso del protocolo AKA de UMTS. El UE se comunica con la BSF a traves de una interfaz 120 Ub. El UE y un sistema de suscriptor domestico 130 (HSS, por sus siglas en ingles) comparten una clave que es la base del HSS para generar un vector de autenticacion proporcionado a la BSF a traves de la interfaz 170 Zh. Segun el protocolo AKA, la BSF envfa al UE un desaffo y el Ue devuelve una respuesta a la BSF. La autenticacion se verifica mediante de la comparacion por parte de la BSF de la respuesta del UE con una respuesta esperada que proporciono el HSS. Se inicia en la BSF una autenticacion exitosa y se genera en el UE una clave compartida Ks. La BSF almacena la clave Ks y el B-TID de referencia asociado. El B-TID de referencia y otros datos, tales como la vida util de la clave, se proporcionan despues al UE en un mensaje de terminacion. La BSF realiza una consulta en la funcion de localizador del suscriptor 140 SLF (por sus siglas en ingles) a traves de la interfaz 191 Dz junto con la operacion de la interfaz Zh para obtener el nombre del HSS que contiene los datos espedficos requeridos del suscriptor. El UE puede conectarse simultaneamente a al menos un servidor de aplicacion As 150_n a traves de un proxy de autenticacion de la funcion de aplicacion de red NAF 160. La conexion comprende una primera etapa de autenticacion entre el UE y la NAF. Por lo tanto, el UE proporciona el B-TID de referencia al NAF que, mediante el uso del B-TID, solicita una clave (Ks_NAF) de la BSF a traves de la interfaz 190 Zn. La clave Ks_NAF se deriva de la clave Ks. La misma clave puede derivarse en el UE. Luego se produce la autenticacion, en funcion de la clave derivada Ks_NAF. La comunicacion entre el UE y la NAF es a traves de una interfaz Ua 180.
A fines ilustrativos, se utiliza en la siguiente descripcion una senalizacion basada en SIP segun IMS de 3GPP. No obstante, como comprende el experto en la tecnica, la invencion puede utilizar otros protocolos que sean capaces de cargar metadatos necesarios para la configuracion de la sesion.
La Figura 2 ilustra elementos basicos de un subsistema de red principal CN (por sus sigas en ingles) de IMS y la conexion al servidor de la aplicacion 210. Si bien la Figura 2 indica un servidor de aplicacion ubicado dentro de una red domestica, debe entenderse que la plataforma de servicio tambien puede ubicarse fuera de la red domestica.
El subsistema de red principal multimedia IP (IM CN) permite que los operadores de lmea fija y PLMN ofrezcan a sus suscriptores servicios multimedia basados y construidos sobre servicios, protocolos y aplicaciones de internet. La intencion es que dichos servicios sean desarrollados por operadores de PLMN y otros proveedores terciarios, inclusive aquellos en el espacio de Internet que utilizan los mecanismos proporcionados por la Internet y el sistema de IMS. El sistema de IMS habilita la convergencia de las tecnologfas de base web y de datos, mensajena, video y voz y el acceso a estas, para el usuario inalambrico y de lmea fija.
El Proxy-CSCF (P-CSCF) 220 es el primer punto de contacto dentro del sistema de IMS que responde al mensaje SIP INVITE del UE. Su direccion puede ser descubierta por el UE 101 mediante el uso de un mecanismo de descubrimiento. El P-CSCF se comporta como un Proxy, es decir, acepta solicitudes y los revisa de forma interna o los reenvfa hacia la servidora de CSCF, S-CSCF 230. La S-CSCF enruta la solicitud de SIP hacia el servidor de aplicacion de red domestica 210.
A continuacion se describe una primera realizacion con referencia a la Figura 3. En la Figura 3, los numeros similares corresponden a las entidades de las Figuras 1 y 2. Se muestra en la Figura 3 dos entidades de usuario UE_A y UE_B capaces de realizar un arranque segun el metodo de GBA/GAA con las funciones respectivas de arranque BSF_A, 110_A y BSF_B 110_B. No obstante, como comprende el experto en la tecnica, puede utilizarse cualquier otro medio disponible para la creacion de una clave compartida con un servidor de este tipo. Por lo tanto, el arranque puede basarse en una credencial de identificacion, p. ej., SIM, USIM, ISIM o PKI, o nombre de usuario/contrasena. El arranque produce que cada UE y BSF asociada puedan determinar una clave compartida Ks_A, respectivamente Ks_B. Los usuarios A y B desean establecer una comunicacion ilustrada en 320. Segun la invencion, un servidor de gestion de claves KMS_A y KMS_B, indicado mediante 310_A y 310_B, respectivamente, soporta a cada UE.
Segun la invencion, los usuarios A y B pueden basar su gestion de seguridad respectiva en credenciales distintas, p. ej., basada en una tarjeta de identidad tal como una tarjeta *SIM (SIM, USIM, ISIM), usuario/contrasena, clave publica PKI o contrasena.
La senalizacion de redes entre dominios entre las entidades de gestion de claves KMS, que se indica en 330, puede asegurarse mediante el uso, p. ej., de TLS o IPsec. La senalizacion puede encriptarse y/o puede tener una proteccion de integridad.
Las interfaces usuales de GBA/GAA Ua, Ub, Zn se indican en la Figura 3 que se corresponde con la Figura 1.
Se hace referencia ahora a la Figura 4, que muestra un diagrama de senales segun una realizacion de la invencion. En la Figura 4, las entidades de la estructura de IMS y la estructura de GBA/GAA se indican tal como se explico con respecto a las Figuras 1-3. A fines de simplicidad, el usuario A tambien se denota como UE_A de manera intercambiable.
5
10
15
20
25
30
35
40
45
50
A continuacion, (x)k denota la proteccion de x mediante la clave K. Por proteccion se entiende proteccion de la integridad y/o confidencialidad, y dicha proteccion de confidencialidad puede aplicarse unicamente a partes de un mensaje x.
Se realizan ahora las etapas 1 y 2 segun la tecnica previa.
En la etapa 1, el usuario A se registra en IMS.
En la etapa 2, el usuario A realiza un arranque de GBA, mediante el cual se genera una clave Ks_A y se comparte entre A y BSF_A. En esta etapa, BSF_A proporciona A con una B-TID_A de referencia. La etapa 2 incluye la subetapa 2:1 en la cual KMS_A recibe de A la B-TID de referencia que se utiliza luego para capturar de BSF_A una clave KA = Ks_KMS_A derivada de Ks_A. El usuario A calcula la misma clave sabiendo Ks_A y otra informacion ingresada en la derivacion. Por lo tanto, A y KMS_A comparten una clave KA que puede utilizarse para una comunicacion segura.
Se realizan etapas correspondientes del lado B indicadas en la Figura 4 con los mismos numeros de referencia, donde se generan las entidades correspondientes, es decir, Ks_B, B-TID_B y KB = Ks_KMS_B.
Cabe destacar que B, como usuario, puede tener varios dispositivos, cada uno de los cuales puede utilizarse para la comunicacion. No obstante, la clave KB es valida unicamente para un dispositivo en particular que realizo un arranque segun las etapas 1 y 2. El caso de que B pueda utilizar varios dispositivos puede llevar a un problema de bifurcacion que se trata adicionalmente en una realizacion alternativa. Para la presente primera realizacion, se asume que B responde a una invitacion de comunicacion mediante el uso de un solo dispositivo.
En 3, el usuario A decide comunicarse con el usuario B.
En la etapa 4, A envfa una solicitud de clave al servidor de gestion de claves KMS_A segun la invencion. La clave generada en esta etapa se utiliza posteriormente para una comunicacion segura de extremo a extremo con B. La solicitud de clave tiene el formato:
GET key info = (ld_A, ld_B, key_type, param.....)ka, B-TID_A
En donde Id_A e Id_B son entidades que identifican a los usuarios A y B respectivamente, key_type es el tipo de clave solicitada, p. ej., una clave para la comunicacion de punto a punto o una clave para comunicacion grupal. Id_A puede tener la forma de un identificador global, por ejemplo, Id_A = A®op.com. Finalmente, param denota cualquier otro parametro que pueda incluirse en el mensaje. El mensaje se encripta mediante la clave KA generada anteriormente. Ademas, se incluye la B-TID de referencia en el mensaje, lo que permite que KMS_A obtenga la clave KA de BSF_A segun el procedimiento de GBA/GAA. De manera alternativa, en un abordaje no basado en GBA del arranque, podna utilizarse algun otro identificador de clave si Id_A no determina la clave KA de forma unica. Cabe destacar que nada se menciona en la presente sobre el tipo de credencial que utiliza el receptor B y, por lo tanto, el metodo segun la invencion no depende del tipo de credencial en el remitente A o receptor B.
En 5, KMS_A responde a A con el mensaje “RETURN key info” de la forma:
RETURN key info = (Key_info_A, VOUCHER)ka
En donde Key_info_A comprende una clave Kab o material de generacion de claves que permite que A calcule, en la etapa 6, una clave Kab. La entidad VOUCHER (asiento), segun la invencion, comprende informacion que habilita a KMS_B volver a generar, posteriormente, la misma clave Kab que permite que A y B se comuniquen de forma segura. Para que KMS_B sepa sobre KMS_A, el asiento incluye Id_A.
Ademas, la integridad del asiento esta protegida y al menos partes de este pueden encriptarse. Por ejemplo, pueden derivarse de la clave KA claves de integridad y confidencialidad.
La clave Kab, por ejemplo, puede generarse como una funcion criptografica de KA y las identidades de A y B y/o un nonce. En este caso, Key_info_A contendna dicho nonce. De manera alternativa, Kab puede ser una clave completamente aleatoria, en cuyo caso Key_info_A comprende la clave Kab en sf.
Segun la presente realizacion, la informacion del asiento incluye un puntero, por ejemplo B-TID, para la recuperacion de la clave Kab o material de claves almacenado en KMS_A. Puede incluirse otra informacion en el asiento, tal como, p. ej., la informacion de tipo de clave, tal como comunicacion entre pares o grupal, identidad de las partes involucradas, emisor del asiento, es decir, identidad de KMS_A, momento de emision o numero de secuencia, tiempo de validez, tipo de uso, tal como pulsar por celular (PoC) o telefoma multimedia (MMTEL).
En la etapa 7, A dirige una INVITACION de SIP al usuario B que, segun la infraestructura de IMS, pasa P-CSCF, S- CSCF que da servicio a A y llega a S-CSCF que da servicio a B. En la etapa 8, el mensaje de invitacion se reenvfa al usuario B. El mensaje de invitacion incluye al menos el asiento. Otra informacion de este mensaje puede incluir informacion del tipo de clave.
5
10
15
20
25
30
35
40
45
50
En la etapa 9, el usuario B reenvfa el asiento en un mensaje de "GET key info" a KMS_B para la regeneracion, a partir de este, de la clave Kab, donde el mensaje, por ejemplo, tiene la forma:
GET key info = VOUCHER, B-TID_B
Aqm, B-TID_B es la referencia de GBA/GAA para autenticar al usuario B y establecer una clave KB para una comunicacion segura entre el usuario B y KMS_B de la misma forma que se menciono anteriormente con respecto a la etapa 4.
En la etapa 9:1 se produce la comunicacion entre KMS_A y KMS_B, en donde KMS_A soporta a KMS_B en la generacion de la clave Kab. Segun la primera realizacion, el asiento incluye un puntero generado por KMS_A en la etapa 5 y la habilitacion de KMS_A para que recupere material de claves, el mismo que se devolvio en la etapa 5 al usuario A. Dicho puntero puede incluirse en una solicitud de clave comunicada en la etapa 9:1 con la forma:
Aqm, el puntero se extrae del asiento en KMS_B y se utiliza para recuperar material de claves en KMS_A. Id_B es un identificador del usuario B. La inclusion de Id_B en la solicitud de clave, mediante KMS_B, permite que KMS_A determine que es el usuario B deseado quien solicita una clave, es decir, que nadie mas intercepto el asiento con la finalidad de obtener una clave para una comunicacion segura con el usuario A, pretendiendo ser el usuario B.
Como respuesta a la solicitud de clave, KMS_A devuelve la informacion de claves Key_info_B que comprende la clave Kab o la informacion de clave que, luego, reenvfa KMS_B en la etapa 10 al usuario B para la generacion de la clave Kab en la etapa 11. La informacion de claves de la etapa 10 se encripta mediante el uso de la clave KB, por ejemplo, generada en la etapa 9. Si se entrega solamente material de claves en la etapa 10, se lleva a cabo una generacion de clave en la etapa 11 y se genera una clave Kab.
La etapa 11 implica que el usuario B devuelva una resputa OK de SIP 200 a la senal de invitacion 7, tras la cual inicia la sesion entre Ay B.
De manera favorable, segun la primera realizacion, el puntero mencionado anteriormente comprende la entidad B- TID_A.
Si la informacion de tipo de clave especifica una comunicacion de punto a punto, la clave que se devuelve a KMS_B en la etapa 9:1 es suficiente y no es necesario un procesamiento posterior de claves.
Se conoce a partir del estandar de GBA/GAA que la B-TID de referencia puede tener una vida util. Por lo tanto, en una realizacion alternativa, el KMS_A mantiene el estado al almacenar al menos una B-TID utilizada anteriormente y el material de clave correspondiente con la finalidad de gestionar el caso en que el usuario A haya realizado un nuevo arranque y generado una nueva B-TID.
Con respecto a la Figura 5, se describe una segunda realizacion con respecto al caso de que la informacion de claves (info de claves) indique que se solicita una clave grupal. En la Figura 5, se inserta un intermediario entre los lados A y B. Preferiblemente, el intermediario se divide en un intermediario de parte A IM_A y un intermediario de parte B IM_B. Por ejemplo, la parte respectiva puede comprender un servidor de pulsar para hablar por celular, denotado servidor de PoC. En la Figura 5, la anotacion B de la parte receptora representa ahora un grupo de usuarios donde cada uno tiene una identidad individual ID_Bk. Ademas, a fines de simplicidad, se asume que cada usuario en el lado B se conecta a la misma BSF_B y al mismo KMS_B, aunque cada usuario puede utilizar funcionalidades separadas de BSF y KMS.
En la Figura 5, las referencias a senales similares indican senales similares de la Figura 4, aunque las partes del mensaje de la senal pueden ser ligeramente distintas, tal como se explica en mayor detalle mas adelante.
Las etapas 1,2, 2:1 y 3 son identicas a las etapas correspondientes segun la primera realizacion, con la excepcion de que en la etapa 3, la denominada parte B ahora representa a un grupo identificado con una identidad grupal Gid.
En la etapa 4, el mensaje GET ahora incluye Gid. En la etapa 5 se devuelve un asiento y material de claves, p. ej., una clave maestra K, para la generacion, en la etapa 6, de una clave de sesion Kima; de manera alternativa, la clave de sesion se incluye en el mensaje devuelto. Cabe destacar que dicha clave de sesion sera utilizada posteriormente por A para la comunicacion con el intermediario, p. ej., IM_A, en vez de directamente con los participates del grupo. La clave maestra y otra informacion pueden protegerse con la clave KA generada en las etapas de arranque 2, 2:1.
En la etapa 7:1, similar a la etapa 7 de la Figura 4, se envfa al grupo un mensaje de INVITE a traves del intermediario o, de manera alternativa, a la parte IM_A del intermediario. El mensaje de invitacion incluye el asiento y otra informacion que comprende al menos Gid.
En la etapa 8:1, el intermediario IM_A, al reconocer que ID_A del asiento es una clave grupal, reenvfa el asiento a KMS_A y solicita material de claves, tras lo cual KMS_A devuelve a IM_A dicha clave maestra K. Adicionalmente, la clave de sesion Kima se devuelve o se genera en IM_A a partir de la clave maestra.
En la etapa 8:2, IM_A resuelve la identidad del grupo proporcionada en el mensaje de invitacion en un grupo de
5
10
15
20
25
30
35
40
45
50
identidades de usuario ID_Bk y genera, a partir de la clave maestra K, una clave de sesion individual Kimb para cada miembro del grupo. Se entiende que se genera una clave individual Kimb para cada Bk. Ademas, de no recibirse desde KMS_A, la clave de sesion Kima se genera a partir de la clave maestra K. Cabe destacar que el intermediary puede precisar soporte de un servidor de gestion de grupos asociado, que no se muestra, para recuperar los miembros individuales del grupo de la ID grupal.
La clave individual Kimb puede calcularse como Kimb = F(K, "X") en donde "X" denota algun identificador caractenstico de la parte X que representa al grupo Bk.
Las claves de sesion Kima y Kimb se utilizan luego para proteger los enlaces de comunicacion A - intermediario, respectivamente, intermediario - B.
En la etapa 7, el intermediario IM_A envfa un mensaje INVITE de SIP a todos los miembros del grupo que incluyen el asiento. Segun la infraestructura de IMS, el mensaje pasa S-CSCF y luego, en la etapa 8, a traves P_CSCF hacia la red que da servicio al receptor Bk. El mensaje 7 corresponde a dicho mensaje de la Figura 4, aunque, en la presente realizacion, el remitente es el intermediario en vez del usuario A.
En la etapa 9, que corresponde a la etapa 9 de la Figura 4, cada receptor Bk entra en contacto con un KMS_B de servicio para resolver el asiento en claves adecuadas.
En la etapa 9:1, similar a la primera realizacion, se produce una comunicacion entre KMS_A y KMS_B, en donde KMS_A devuelve la clave Kimb o, de manera alternativa, la clave maestra K, a KMS_B y de ah se reenvfa, en la etapa 10, a cada miembro del grupo, protegida con la clave del miembro individual del grupo KBk indicada, a fines de simplicidad, como la clave KB en la Figura 5. El mensaje 10 corresponde al mismo mensaje de la Figura 4. Debena entenderse que la etapa 10 se repite para todos los miembros del grupo Bk. Las claves KB se calculan de forma correspondiente a KA y se asume que cada Bk llevo a cabo un arranque con una funcionalidad BSF asociada. En el caso en que KMS_A devuelva la clave maestra K, cada Bk calcula a partir de la clave correspondiente Kimb.
En la etapa 11 se devuelve una senal OK 200 como respuesta a las senales respectivas de invitacion 7:1, 7 y 8, tras lo cual puede iniciar la sesion entre A - IM - Bk (k = 1, 2, ...).
Ahora, A puede comunicarse con los miembros del grupo Bk, tras lo cual A encripta la comunicacion mediante el uso de la clave Kima hacia el intermediario, donde el mensaje de decodifica y posiblemente se procesa, p. ej., se transcodifica antes de reenviarse, se vuelve a encriptar con la clave Kimb, individualmente para todos los Bk.
De manera alternativa, Kima = Kimb.
Segun una alternativa de la segunda realizacion, la etapa 8:1 no incluye la clave Kima ni la clave maestra K. Por lo tanto, en esta realizacion, el intermediario no puede decodificar la comunicacion de la parte iniciadora A para su procesamiento. Por consiguiente, la etapa de reencripcion de la comunicacion con la clave Kimb no es pertinente. Por lo tanto, el intermediario, en este caso, actua basicamente para resolver una identidad grupal en miembros individuales de un grupo respondedor para proporcionar un mensaje de INVITE a cada miembro y, posteriormente, para reenviar la comunicacion de A a cada Bk sin ningun procesamiento posterior de la informacion.
Una alternativa de la segunda realizacion comprende calcular claves separadas para un vinculo superior, hacia el intermediario, respectivamente un vinculo inferior, en direccion del intermediario hacia los usuarios A y B. Dicha clave maestra K puede ser la base para la generacion de claves.
Segun una realizacion alternativa de la segunda realizacion, el tipo de clave indica una clave grupal ad hoc mediante la cual, en la etapa 8:1, IM_A solicita el material de claves K y genera, en la etapa 8:2, un grupo de identidades de usuario ID_Bk a partir de la enumeracion de las partes proporcionada en el mensaje de invitacion 7:1 de A. Finalmente, IM_A genera, a partir de la clave maestra K, una clave individual KBk para cada miembro del grupo ad hoc especificado por el usuario A.
Segun aun otra alternativa de la segunda realizacion, cada miembro del grupo obtiene una clave individual que puede ademas ser distinta para un vinculo superior, en direccion del usuario B hacia el intermediario IM_A, y un vinculo inferior, en direccion del intermediario IM_A al usuario B. Por ejemplo, IM_A puede realizar una personalizacion de claves segun el esquema:
Aqrn, "Bk" denota algunos datos caractensticos para el individuo Bk y K es la clave maestra definida anteriormente. Con la finalidad de que cada Bk genere la misma clave correspondiente, la senal de invitacion de las etapas 7 y 8 incluye, de preferencia, la informacion caractenstica "Bk" incluida adicionalmente in el mensaje de solicitud 10 a KMS_B, en donde, luego de esto, se realiza la personalizacion. La clave personalizada se proporciona finalmente al usuario Bk en la senal 10.
Segun una alternativa de la realizacion anterior, el intermediario se comunica con el grupo de Bk a traves de multidifusion. En este caso, todos los usuarios Bk debenan utilizar la misma clave grupal para recibir informacion de vinculo inferior. Por lo tanto, no se realiza en este caso ninguna personalizacion de vinculo inferior y todos los
5
10
15
20
25
30
35
40
45
50
55
usuarios Bk reciben la misma clave de vrnculo inferior de KMS_A.
Segun otra alternativa de la segunda realizacion, el intermediary no se encuentra incluido en el procesamiento, p. ej., transcodificacion, de la comunicacion del usuario A y, por lo tanto, no se le proporciona una capacidad de decodificar la carga comunicada por el usuario A. En este caso, por lo tanto, se omiten las etapas 8:1 y 8:2 y, en las etapas 7 y 8, el asiento simplemente se reenvfa al grupo identificado por el intermediary IM_A mediante la resolucion del identificador grupal. Se utiliza entonces del lado del receptor el mismo mecanismo de resolucion de claves de la primera realizacion. Eficazmente, esto significa que los lados A y B se comunican de extremo a extremo sin la interferencia del intermediario.
Puede aparecer un problema general, p. ej., mas probablemente en el caso de la multidifusion, y es que un usuario no autorizado que haya interceptado el vinculo de senalizacion o intermediario y haya obtenido el asiento podna reenviarlo a la funcionalidad kMs y solicitar que se resuelva. Por lo tanto, de preferencia, la funcionalidad KMS debena ser capaz de verificar que los usuarios para los cuales resuelve los asientos sean miembros autorizados del grupo. Por lo tanto, segun esta realizacion alternativa, se incluye un identificador aleatorio unico de usuario, u otro identificador unico, en la senalizacion de SIP del intermediario con el asiento. Debido a la proteccion de la senalizacion de SIP, el identificador esta protegido ante una parte externa que logra acceder al asiento y al identificador. La funcionalidad de KMS puede verificar que un identificador aleatorio no fue presentado ya por algun otro usuario.
Como alternativa, el identificador tambien puede ingresarse en la derivacion de clave para los usuarios individuales.
Segun la primera y segunda realizaciones, el material de claves obtenido en la senal de solicitud 4 puede incluir una o mas claves de sesion Kab o Kima. La una o mas claves de sesion recibidas pueden utilizarse de forma directa o indirecta, p. ej., mediante el uso del protocolo MIKEY, para asegurar los datos de carga.
No obstante, en una alternativa de la primera y segunda realizaciones, la senal 5 puede incluir uno o mas nonces de los cuales pueden derivarse las claves de sesion correspondientes, p. ej., de KA = Ks_KMS_A. El transporte de estos nonces, p. ej., incluido en el asiento, no precisa encriptarse.
Puede ocurrir un problema si el usuario A se desconecta o realiza un nuevo arranque, mediante el cual la clave anterior KA = Ks_KMS_A puede ya no ser valida, ya que puede producirse una clave KA' a partir del nuevo arranque. Cuando KMS_A recibe el asiento, la informacion de este no sena util en la recreacion de la clave de sesion Kab o Kima.
Por lo tanto, en una alternativa de la primera y segunda realizaciones, KMS_A mantiene el estado y guarda las claves utilizadas anteriormente KA.
En aun otra alternativa, el asiento puede incluir una copia de la clave KA, en un campo de asiento protegido por una clave que solo conoce KMS_A. En el ultimo caso, solo precisan mantenerse las claves secretas y no hay necesidad de mantener el estado de usuario individual mediante KMS_A.
Segun otra alternativa de la primera y segunda realizaciones, el S-CSCF de la etapa 7 de las Figuras 4 y 5, puede llevar a cabo las etapas 9 y 10 de las Figuras 4 y 5, en nombre del usuario B o, en el caso del grupo, cada usuario Bk, y reemplazar el asiento por la informacion de generacion de clave e incluirla directamente en el mensaje de SIP reenviado en la etapa 8. De manera alternativa, la etapa 8 se lleva a cabo mediante algun otro metodo, p. ej., insercion de GBA, mediante la cual S-CSCF finaliza la senalizacion de SIP el enviar la senal 12.
En el caso particular de que cualquiera de B o Bk pueda responder a la senal INVITE de SIP 8 en cualquiera de varios dispositivos disponibles, deben tomarse algunas precauciones. En este caso, un dispositivo respondedor genero una clave particular KB' o KBk' a partir de las etapas de arranque 1 y 2. Por lo tanto, la S-CSCF, sin saber que dispositivo se utilizara para responder al mensaje de invitacion, debe incluir todas las posibilidades al llevar a cabo la etapa 9 y repetir la etapa 9 para generar todas las claves individuales posibles K'imb. Por lo tanto, cuando la S-CSCF recibe finalmente la respuesta a la solicitud de INVITE de SIP 8, se prepara una clave adecuada K'imb y esta lista para ser utilizada en la etapa 10.
Cabe destacar que las realizaciones alternativas descritas requieren un modelo de confianza distinto, en el sentido de que la S-CSCf sabe que debe confiarse en las claves para la proteccion de la comunicacion del operador del centro de SIP. No obstante, esto es normalmente una presuncion valida.
Otra alternativa de la primera y segunda realizaciones se refiere al servicio de mensajena, es decir, el usuario A envfa un mensaje a B o a cada uno de Bk en el caso del grupo. El mensaje puede incluirse en el mensaje de invitacion 7 o 7:1. Si la S-CSCF determina que al menos un recipiente no esta registrado en la red, un mensaje de A puede almacenarse en un nodo de la red, por ejemplo, en el nodo de red S_CSCF, junto con el asiento, hasta que se registre como activo el receptor B o Bk. Luego, cuando B se registra en la red, la S-CSCF puede proseguir con el protocolo e insertar el asiento en B o Bk, por ejemplo, mediante el uso de insercion de GBA, e informar a B o Bk donde encontrar el mensaje. Este abordaje es generalmente valido para cualquier servicio que pueda tratarse como un servicio diferido. Dado que A puede haberse desconectado y/o realizado un arranque nuevo, pueden utilizarse
5
10
15
20
25
30
mecanismos similares a los mencionados anteriormente para verificar que KMS_A sea capaz de recuperar la informacion correcta de generacion de claves.
Si bien la Figura 3 indica interfaces espedficas entre funcionalidades implicadas en el metodo segun la invencion, se comprende facilmente que las interfaces pueden disponerse de forma distinta de varias formas, p. ej., tal como se indica en la Figura 6. En la Figura 6, las interfaces T_A y T_B1 corresponden a la interfaz conocida Ua segun el metodo GBA. La interfaz T_B2 es una alternativa a T_B1, donde el usuario B se comunica con KMS_A en vez de con KMS_B.
K_AB1 indica una interfaz entre las funcionalidades de KMS necesarias para resolver un asiento.
K_AB2 es una interfaz de gestion de claves entre dominios entre KMS en el dominio de B y BSF en el dominio de A. KMS en el dominio de B puede utilizar esta interfaz para obtener ayuda en la resolucion de un asiento en una clave.
K_AB3 es una interfaz de gestion de claves entre dominios entre el KMS en el dominio de A y BSF en el dominio de B.
Se comprende facilmente que tanto la primera como la segunda realizacion proporcionan una intercepcion legal en la funcionalidad de KMS. Una autoridad que conoce la clave KA puede generar la clave de sesion Kab o, en la segunda realizacion, la clave Kima, lo que permite que la autoridad intercepte la comunicacion de A hacia B o el intermediario.
Se ilustra en la Figura 7 un aparato segun la invencion que soporta la generacion de claves de sesion para una comunicacion segura entre partes en una red de comunicaciones.
En la Figura 7, en 710, se muestra una unidad de entrada/salida. El medio 710 puede comunicar informacion de clave con otras unidades de soporte o usuarios finales, por ejemplo, recibir del usuario final una solicitud de informacion de clave o un asiento para resolverlo en informacion de clave. El medio 710 proporciona ademas comunicacion con una funcionalidad de arranque de soporte para recibir material de claves generado en un procedimiento de arranque.
El medio 720 proporciona la generacion de informacion de claves tal como la derivacion del material de claves a partir de informacion de arranque, por ejemplo, recibida de una funcionalidad de arranque.
El medio 730 procesa un asiento recibido para recuperar informacion de claves almacenada del almacenamiento 740. El medio 730 puede ademas resolver, posiblemente en comunicacion con unidades de red de soporte, una identidad de grupo de usuarios en miembros individuales del grupo.
En 750, el medio de procesamiento general proporciona el control necesario de los diversos procesos.
La invencion descrita a modo de ejemplo no taxativo puede comprenderse facilmente para proporcionar numerosas variaciones, p. ej., para implementar entidades funcionales, interfaces de comunicacion y senalizacion.
Claims (14)
- 51015202530354045REIVINDICACIONES1. Un metodo para establecer una comunicacion segura entre partes de una red de comunicacion, en el que cada parte es capaz de realizar un procedimiento de arranque en funcion de credenciales locales, donde el arranque crea una clave compartida entre cada parte y una funcion de arranque asociada caracterizada por las etapas de:- recibir en la parte iniciadora la primera informacion de clave, en funcion de dicho procedimiento de arranque, y un asiento como respuesta a la solicitud de sesion enviada a una primera funcionalidad de gestion de claves;- almacenar dicha primera informacion de clave en dicha primera funcionalidad de gestion de clave, en donde se hace referencia a dicha informacion de clave con un identificador incluido en dicho asiento;- generar, a partir de la primera informacion de clave, una primera clave de sesion;- enviar el asiento a al menos una parte respondedora;- reenviar de la al menos una parte respondedora el asiento o partes del mismo a una segunda funcionalidad de gestion de claves;comunicar a la segunda funcionalidad de gestion de claves con dicha primera funcionalidad de gestion de claves para resolver el asiento en la segunda informacion de clave, en donde dicha comunicacion incluye recuperar, en la primera funcionalidad de gestion de clave, la primera informacion de clave mediante el uso del identificador, y proporcionar a la segunda funcionalidad de gestion de claves informacion basada en la primera informacion de clave;- recibir en la al menos una parte respondedora, la segunda funcionalidad de gestion de claves, dicha segunda informacion de clave, y generar a partir de esta una segunda clave de sesion;el uso, de la parte emisora y al menos una parte respondedora, de la primera y segunda claves de sesion para una comunicacion segura.
- 2. El metodo de la reivindicacion 1, caracterizado por que el arranque se realiza segun el metodo de GBA.
- 3. El metodo de la reivindicacion 1, en donde la al menos una informacion de clave comprende una clave de sesion, mediante la cual se elimina la etapa de generacion correspondiente.
- 4. El metodo de la reivindicacion 1, caracterizado por que las etapas de recibir implican la proteccion de la informacion recibida mediante una clave que se deriva de dicha clave compartida creada durante el arranque de la parte respectiva con la funcion de arranque asociada.
- 5. El metodo de la reivindicacion 1, caracterizado por que dicho almacenamiento comprende, ademas, almacenar la primera informacion de clave obtenida de al menos un procedimiento de arranque antes del inicial.
- 6. El metodo de la reivindicacion 1, caracterizado por que dicho identificador comprende un nonce.
- 7. El metodo de la reivindicacion 1, caracterizado por que dicho identificador comprende una direccion de referencia.
- 8. El metodo de la reivindicacion 1, caracterizado por que la primera informacion de clave comprende una clave maestra y que al menos una parte respondedora comprende un intermediario que es el receptor en la etapa del envfo y en las etapas posteriores antes de la etapa del reenvfo:- el reenvfo del intermediario de al menos partes del asiento a la primera funcionalidad de gestion de claves;- la recuperacion en la primera funcionalidad de gestion de claves, mediante el uso del asiento, de la clave maestra K y el calculo, a partir de esta, de la segunda informacion de clave para la al menos una parte respondedora;- la recepcion, en el intermediario, de una respuesta de la primera funcionalidad de gestion de claves que inicia el envfo del asiento a la al menos una parte respondedora;y adicionalmente el avance de dicha comunicacion segura a lo largo de una via desde la parte emisora hacia el intermediario, y desde este a la al menos una parte respondedora.
- 9. El metodo de la reivindicacion 8, caracterizado por que el envfo desde el intermediario se dirige a un grupo de al menos una parte respondedora determinada a partir de una identidad grupal proporcionada en el asiento.
- 10. El metodo de la reivindicacion 8, caracterizado por que dicha respuesta incluye la clave maestra K que habilita al intermediario a generar claves de sesion para las partes emisora y respondedora.
- 11. El metodo de la reivindicacion 10, caracterizado por que el intermediary decodifica, mediante el uso de la clave de sesion de la parte emisora, el procesamiento de la comunicacion, seguido por la reencripcion de la comunicacion mediante el uso de la clave de sesion para cada una de las partes respondedoras.
- 12. El metodo de la reivindicacion 9, caracterizado por que la primera funcionalidad de gestion de claves realiza 5 una verificacion de que un usuario, para el cual resuelve un asiento, es un miembro del grupo.
- 13. El metodo de cualquiera de las reivindicaciones que anteceden, caracterizado por que la entidad de red determina que al menos una parte respondedora no esta registrada en la red, mediante lo cual se interrumpe el procesamiento y dicha entidad de red almacena informacion comunicada desde la parte emisora y el asiento pertinente hasta que se detecte un registro, tras lo cual dicha entidad de red continua el procesamiento e inserta el10 asiento hacia la al menos una parte respondedora.
- 14. Un aparato de gestion de claves que brinda soporte a la generacion de claves de sesion para una comunicacion segura entre partes de una red de comunicaciones, en donde el aparato tiene medios de procesamiento y se caracteriza por:- medios para generar una primera informacion de clave y un asiento como respuesta a una solicitud de una 15 primera parte, donde se hace referencia a la primera informacion de clave mediante un identificador incluido en elasiento;- medios para la comunicacion del asiento a la primera parte,- medios para almacenar la primera informacion de clave y el identificador,- medios para comunicarse con un segundo aparato de gestion de claves para resolver un asiento recibido en una 20 segunda informacion de gestion de claves, donde dicha comunicacion incluye recuperar la primera informacion declave mediante el uso del identificador, y proporcionar a la segunda funcionalidad de gestion de claves informacion basada en la primera informacion de clave.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/SE2007/050927 WO2009070075A1 (en) | 2007-11-30 | 2007-11-30 | Key management for secure communication |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2589112T3 true ES2589112T3 (es) | 2016-11-10 |
Family
ID=40678809
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES07852199.4T Active ES2589112T3 (es) | 2007-11-30 | 2007-11-30 | Gestión de claves para comunicación segura |
Country Status (6)
Country | Link |
---|---|
US (2) | US9178696B2 (es) |
EP (2) | EP3079298B1 (es) |
JP (1) | JP5496907B2 (es) |
ES (1) | ES2589112T3 (es) |
NZ (1) | NZ585054A (es) |
WO (1) | WO2009070075A1 (es) |
Families Citing this family (67)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20090036335A (ko) * | 2007-10-09 | 2009-04-14 | 삼성전자주식회사 | 휴대 방송 시스템에서 효율적인 키 제공 방법 및 그에 따른시스템 |
WO2009124583A1 (en) * | 2008-04-07 | 2009-10-15 | Nokia Siemens Networks Oy | Apparatus, method, system and program for secure communication |
KR101514840B1 (ko) * | 2008-06-11 | 2015-04-23 | 삼성전자주식회사 | 휴대 방송 시스템에서의 암호화 키 분배 방법 및 이를 위한시스템 |
WO2010031600A1 (en) | 2008-09-16 | 2010-03-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Key management in a communication network |
US8181030B2 (en) * | 2008-12-02 | 2012-05-15 | Electronics And Telecommunications Research Institute | Bundle authentication system and method |
WO2010090569A1 (en) | 2009-02-05 | 2010-08-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Apparatuses and a method for protecting a bootstrap message in a network |
US8571550B2 (en) * | 2009-02-09 | 2013-10-29 | Qualcomm Incorporated | Managing access control to closed subscriber groups |
JP4715937B2 (ja) * | 2009-03-06 | 2011-07-06 | ブラザー工業株式会社 | 端末装置とコンピュータプログラム |
US20110237250A1 (en) * | 2009-06-25 | 2011-09-29 | Qualcomm Incorporated | Management of allowed csg list and vplmn-autonomous csg roaming |
CN101729536B (zh) * | 2009-06-29 | 2012-07-18 | 中兴通讯股份有限公司 | 一种ip多媒体子***延迟媒体信息传输方法及*** |
CN102055747B (zh) * | 2009-11-06 | 2014-09-10 | 中兴通讯股份有限公司 | 获取密钥管理服务器信息的方法、监听方法及***、设备 |
US8935529B2 (en) * | 2009-11-30 | 2015-01-13 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and systems for end-to-end secure SIP payloads |
US8625787B2 (en) * | 2010-01-14 | 2014-01-07 | Alcatel Lucent | Hierarchical key management for secure communications in multimedia communication system |
US8873746B2 (en) * | 2010-01-28 | 2014-10-28 | Intel Corporation | Establishing, at least in part, secure communication channel between nodes so as to permit inspection, at least in part, of encrypted communication carried out, at least in part, between the nodes |
GB201015324D0 (en) * | 2010-09-14 | 2010-10-27 | Vodafone Ip Licensing Ltd | Secure association |
SG10201602471QA (en) * | 2011-04-01 | 2016-04-28 | Ericsson Telefon Ab L M | Methods and apparatuses for avoiding damage in network attacks |
US8769288B2 (en) * | 2011-04-22 | 2014-07-01 | Alcatel Lucent | Discovery of security associations |
US9154527B2 (en) | 2011-06-30 | 2015-10-06 | Verizon Patent And Licensing Inc. | Security key creation |
US8943318B2 (en) * | 2012-05-11 | 2015-01-27 | Verizon Patent And Licensing Inc. | Secure messaging by key generation information transfer |
US8990554B2 (en) | 2011-06-30 | 2015-03-24 | Verizon Patent And Licensing Inc. | Network optimization for secure connection establishment or secure messaging |
US9270453B2 (en) | 2011-06-30 | 2016-02-23 | Verizon Patent And Licensing Inc. | Local security key generation |
US9608971B2 (en) * | 2011-09-08 | 2017-03-28 | Telefonaktiebolaget Lm Ericcson (Publ) | Method and apparatus for using a bootstrapping protocol to secure communication between a terminal and cooperating servers |
KR20140095523A (ko) * | 2011-10-31 | 2014-08-01 | 노키아 코포레이션 | 외부 코드에 대한 보안 메커니즘 |
JP5310824B2 (ja) | 2011-11-10 | 2013-10-09 | 株式会社リコー | 伝送管理装置、プログラム、伝送管理システムおよび伝送管理方法 |
WO2013104072A1 (en) * | 2012-01-12 | 2013-07-18 | Research In Motion Limited | System and method of lawful access to secure communications |
WO2013104071A1 (en) | 2012-01-12 | 2013-07-18 | Research In Motion Limited | System and method of lawful access to secure communications |
US9083509B2 (en) * | 2012-01-12 | 2015-07-14 | Blackberry Limited | System and method of lawful access to secure communications |
GB201202058D0 (en) | 2012-02-07 | 2012-03-21 | Ericsson Telefon Ab L M | Lawful interception of encrypted communications |
EP2815623B1 (en) * | 2012-02-14 | 2018-08-29 | Nokia Technologies Oy | Device to device security using naf key |
GB2500720A (en) * | 2012-03-30 | 2013-10-02 | Nec Corp | Providing security information to establish secure communications over a device-to-device (D2D) communication link |
CN103813309B (zh) * | 2012-11-15 | 2019-03-29 | 中兴通讯股份有限公司 | 一种基于sip的mtc设备间安全通信方法、装置及*** |
US8874898B2 (en) * | 2012-12-14 | 2014-10-28 | Intel Corporation | Power line based theft protection of electronic devices |
US10015144B2 (en) * | 2013-01-31 | 2018-07-03 | Schedule1 Inc. | Method and system for protecting data using data passports |
EP2785011A1 (en) * | 2013-03-27 | 2014-10-01 | Gemalto SA | Method to establish a secure voice communication using generic bootstrapping architecture |
FR3004041B1 (fr) | 2013-03-28 | 2015-04-17 | Commissariat Energie Atomique | Procede et dispositif d'etablissement de cles de session |
KR20150139602A (ko) * | 2013-04-05 | 2015-12-11 | 인터디지탈 패튼 홀딩스, 인크 | 보안화 피어-투-피어 및 그룹 통신들 |
CN104581704B (zh) * | 2013-10-25 | 2019-09-24 | 中兴通讯股份有限公司 | 一种实现机器类通信设备间安全通信的方法及网络实体 |
CN104661171B (zh) * | 2013-11-25 | 2020-02-28 | 中兴通讯股份有限公司 | 一种用于mtc设备组的小数据安全传输方法和*** |
JP5746774B2 (ja) * | 2014-01-06 | 2015-07-08 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | セキュアな通信のための鍵管理 |
JP6508688B2 (ja) * | 2014-10-31 | 2019-05-08 | コンヴィーダ ワイヤレス, エルエルシー | エンドツーエンドサービス層認証 |
US10110595B2 (en) | 2015-03-16 | 2018-10-23 | Convida Wireless, Llc | End-to-end authentication at the service layer using public keying mechanisms |
US9338147B1 (en) | 2015-04-24 | 2016-05-10 | Extrahop Networks, Inc. | Secure communication secret sharing |
JP6577999B2 (ja) * | 2015-04-30 | 2019-09-18 | 日本電信電話株式会社 | データ送受信方法及びシステム |
GB2538774A (en) * | 2015-05-28 | 2016-11-30 | Vodafone Ip Licensing Ltd | Setting a password on a device |
US9641509B2 (en) * | 2015-07-30 | 2017-05-02 | Ca, Inc. | Enterprise authentication server |
RU2699403C1 (ru) * | 2015-08-11 | 2019-09-05 | Хуавей Текнолоджиз Ко., Лтд. | Способ и аппаратура для аутентификации доступа |
US10129229B1 (en) * | 2016-08-15 | 2018-11-13 | Wickr Inc. | Peer validation |
US10476673B2 (en) | 2017-03-22 | 2019-11-12 | Extrahop Networks, Inc. | Managing session secrets for continuous packet capture systems |
US10567165B2 (en) * | 2017-09-21 | 2020-02-18 | Huawei Technologies Co., Ltd. | Secure key transmission protocol without certificates or pre-shared symmetrical keys |
US9967292B1 (en) | 2017-10-25 | 2018-05-08 | Extrahop Networks, Inc. | Inline secret sharing |
US10389574B1 (en) | 2018-02-07 | 2019-08-20 | Extrahop Networks, Inc. | Ranking alerts based on network monitoring |
US10038611B1 (en) | 2018-02-08 | 2018-07-31 | Extrahop Networks, Inc. | Personalization of alerts based on network monitoring |
US10270794B1 (en) | 2018-02-09 | 2019-04-23 | Extrahop Networks, Inc. | Detection of denial of service attacks |
US10411978B1 (en) | 2018-08-09 | 2019-09-10 | Extrahop Networks, Inc. | Correlating causes and effects associated with network activity |
US10594718B1 (en) | 2018-08-21 | 2020-03-17 | Extrahop Networks, Inc. | Managing incident response operations based on monitored network activity |
CN109361508B (zh) * | 2018-10-11 | 2022-11-18 | 联洋国融(北京)科技有限公司 | 数据传输方法、电子设备及计算机可读存储介质 |
US10965702B2 (en) * | 2019-05-28 | 2021-03-30 | Extrahop Networks, Inc. | Detecting injection attacks using passive network monitoring |
US11165814B2 (en) | 2019-07-29 | 2021-11-02 | Extrahop Networks, Inc. | Modifying triage information based on network monitoring |
US11388072B2 (en) | 2019-08-05 | 2022-07-12 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US10742530B1 (en) | 2019-08-05 | 2020-08-11 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US10742677B1 (en) | 2019-09-04 | 2020-08-11 | Extrahop Networks, Inc. | Automatic determination of user roles and asset types based on network monitoring |
US11165823B2 (en) | 2019-12-17 | 2021-11-02 | Extrahop Networks, Inc. | Automated preemptive polymorphic deception |
US11463466B2 (en) | 2020-09-23 | 2022-10-04 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11310256B2 (en) | 2020-09-23 | 2022-04-19 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11349861B1 (en) | 2021-06-18 | 2022-05-31 | Extrahop Networks, Inc. | Identifying network entities based on beaconing activity |
US11296967B1 (en) | 2021-09-23 | 2022-04-05 | Extrahop Networks, Inc. | Combining passive network analysis and active probing |
US11843606B2 (en) | 2022-03-30 | 2023-12-12 | Extrahop Networks, Inc. | Detecting abnormal data access based on data similarity |
Family Cites Families (49)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5535276A (en) * | 1994-11-09 | 1996-07-09 | Bell Atlantic Network Services, Inc. | Yaksha, an improved system and method for securing communications using split private key asymmetric cryptography |
GB2313749B (en) | 1996-05-31 | 1998-05-13 | I Co Global Communications | Secure communications |
US6041123A (en) * | 1996-07-01 | 2000-03-21 | Allsoft Distributing Incorporated | Centralized secure communications system |
JP2002051036A (ja) * | 2000-08-01 | 2002-02-15 | Advanced Mobile Telecommunications Security Technology Research Lab Co Ltd | キーエスクロー方式 |
US7395549B1 (en) * | 2000-10-17 | 2008-07-01 | Sun Microsystems, Inc. | Method and apparatus for providing a key distribution center without storing long-term server secrets |
EP1329051A2 (en) * | 2000-10-18 | 2003-07-23 | Koninklijke Philips Electronics N.V. | Generation of a common encryption key |
US7243370B2 (en) * | 2001-06-14 | 2007-07-10 | Microsoft Corporation | Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication |
US7421411B2 (en) * | 2001-07-06 | 2008-09-02 | Nokia Corporation | Digital rights management in a mobile communications environment |
US7194543B2 (en) * | 2001-11-12 | 2007-03-20 | Mci, Llc | System and method for creating and managing survivable, service hosting networks |
GB2384406B (en) * | 2002-01-21 | 2004-05-12 | Hyun Ku Yeun | Cryptosystem |
US7418596B1 (en) * | 2002-03-26 | 2008-08-26 | Cellco Partnership | Secure, efficient, and mutually authenticated cryptographic key distribution |
US7240366B2 (en) * | 2002-05-17 | 2007-07-03 | Microsoft Corporation | End-to-end authentication of session initiation protocol messages using certificates |
DE10223248A1 (de) * | 2002-05-22 | 2003-12-04 | Siemens Ag | Verfahren zum Registrieren eines Kommunikationsendgeräts |
US20040030918A1 (en) * | 2002-08-07 | 2004-02-12 | Karamchedu Murali M. | Enterprise based opaque message archives |
US7213143B1 (en) * | 2003-01-27 | 2007-05-01 | Nortel Networks Limited | Security over a network |
GB0322891D0 (en) * | 2003-09-30 | 2003-10-29 | Nokia Corp | Communication method |
DE10355418B4 (de) * | 2003-11-27 | 2008-04-03 | Siemens Ag | Sicherheitsmodul zum Verschlüsseln eines Telefongesprächs |
US7353388B1 (en) * | 2004-02-09 | 2008-04-01 | Avaya Technology Corp. | Key server for securing IP telephony registration, control, and maintenance |
CN100592678C (zh) * | 2004-02-11 | 2010-02-24 | 艾利森电话股份有限公司 | 用于网络元件的密钥管理 |
US7549048B2 (en) * | 2004-03-19 | 2009-06-16 | Microsoft Corporation | Efficient and secure authentication of computing systems |
US7646872B2 (en) * | 2004-04-02 | 2010-01-12 | Research In Motion Limited | Systems and methods to securely generate shared keys |
US8582567B2 (en) * | 2005-08-09 | 2013-11-12 | Avaya Inc. | System and method for providing network level and nodal level vulnerability protection in VoIP networks |
CN100574185C (zh) * | 2005-01-07 | 2009-12-23 | 华为技术有限公司 | 在ip多媒体业务子***网络中保障媒体流安全性的方法 |
US7628322B2 (en) * | 2005-03-07 | 2009-12-08 | Nokia Corporation | Methods, system and mobile device capable of enabling credit card personalization using a wireless network |
US7975140B2 (en) * | 2005-04-08 | 2011-07-05 | Nortel Networks Limited | Key negotiation and management for third party access to a secure communication session |
FI20050384A0 (fi) * | 2005-04-14 | 2005-04-14 | Nokia Corp | Geneerisen todentamisarkkitehtuurin käyttö Internet-käytäntöavainten jakeluun matkaviestimissä |
US7558957B2 (en) * | 2005-04-18 | 2009-07-07 | Alcatel-Lucent Usa Inc. | Providing fresh session keys |
US20060288423A1 (en) * | 2005-06-17 | 2006-12-21 | Nokia Corporation | Method, system and network elements for establishing media protection over networks |
US20080215888A1 (en) * | 2005-07-07 | 2008-09-04 | Telefonaktiebolaget Lm Ericsson | Method and Arrangement For Authentication and Privacy |
US8184641B2 (en) * | 2005-07-20 | 2012-05-22 | Verizon Business Global Llc | Method and system for providing secure communications between proxy servers in support of interdomain traversal |
WO2007017884A1 (en) * | 2005-08-05 | 2007-02-15 | Hewlett-Packard Development Company L.P. | System, method and apparatus to obtain a key for encryption/decryption/data recovery from an enterprise cryptography key management system |
GB0517592D0 (en) * | 2005-08-25 | 2005-10-05 | Vodafone Plc | Data transmission |
US20070101122A1 (en) | 2005-09-23 | 2007-05-03 | Yile Guo | Method and apparatus for securely generating application session keys |
US7835528B2 (en) * | 2005-09-26 | 2010-11-16 | Nokia Corporation | Method and apparatus for refreshing keys within a bootstrapping architecture |
US8122240B2 (en) * | 2005-10-13 | 2012-02-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for establishing a security association |
US20070101112A1 (en) * | 2005-10-27 | 2007-05-03 | Inventec Corporation | Embedded device detecting system and related method |
WO2007062689A1 (en) * | 2005-12-01 | 2007-06-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for distributing keying information |
JP5123209B2 (ja) * | 2006-01-24 | 2013-01-23 | ▲ホア▼▲ウェイ▼技術有限公司 | モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタ |
US7925023B2 (en) * | 2006-03-03 | 2011-04-12 | Oracle International Corporation | Method and apparatus for managing cryptographic keys |
EP1865656A1 (en) | 2006-06-08 | 2007-12-12 | BRITISH TELECOMMUNICATIONS public limited company | Provision of secure communications connection using third party authentication |
US8214635B2 (en) * | 2006-11-28 | 2012-07-03 | Cisco Technology, Inc. | Transparent proxy of encrypted sessions |
US8769284B2 (en) * | 2006-12-29 | 2014-07-01 | Nokia Corporation | Securing communication |
US8756422B2 (en) * | 2006-12-29 | 2014-06-17 | Ceelox Patents, LLC | System and method for secure and/or interactive dissemination of information |
US7992198B2 (en) * | 2007-04-13 | 2011-08-02 | Microsoft Corporation | Unified authentication for web method platforms |
US8875236B2 (en) * | 2007-06-11 | 2014-10-28 | Nokia Corporation | Security in communication networks |
US20090126001A1 (en) * | 2007-11-08 | 2009-05-14 | Microsoft Corporation | Techniques to manage security certificates |
US7984486B2 (en) * | 2007-11-28 | 2011-07-19 | Nokia Corporation | Using GAA to derive and distribute proxy mobile node home agent keys |
US8539564B2 (en) * | 2009-03-04 | 2013-09-17 | Telefonaktiebolaget L M Ericsson (Publ) | IP multimedia security |
US8301883B2 (en) * | 2009-08-28 | 2012-10-30 | Alcatel Lucent | Secure key management in conferencing system |
-
2007
- 2007-11-30 ES ES07852199.4T patent/ES2589112T3/es active Active
- 2007-11-30 US US12/744,986 patent/US9178696B2/en active Active
- 2007-11-30 WO PCT/SE2007/050927 patent/WO2009070075A1/en active Application Filing
- 2007-11-30 JP JP2010535908A patent/JP5496907B2/ja not_active Expired - Fee Related
- 2007-11-30 NZ NZ585054A patent/NZ585054A/xx not_active IP Right Cessation
- 2007-11-30 EP EP16169833.7A patent/EP3079298B1/en active Active
- 2007-11-30 EP EP07852199.4A patent/EP2215769B1/en active Active
-
2015
- 2015-10-30 US US14/927,834 patent/US9628271B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US20160056959A1 (en) | 2016-02-25 |
JP2011508991A (ja) | 2011-03-17 |
EP2215769B1 (en) | 2016-06-29 |
WO2009070075A1 (en) | 2009-06-04 |
EP2215769A4 (en) | 2013-10-30 |
US9628271B2 (en) | 2017-04-18 |
JP5496907B2 (ja) | 2014-05-21 |
US9178696B2 (en) | 2015-11-03 |
US20100268937A1 (en) | 2010-10-21 |
EP2215769A1 (en) | 2010-08-11 |
EP3079298A1 (en) | 2016-10-12 |
EP3079298B1 (en) | 2018-03-21 |
NZ585054A (en) | 2013-08-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2589112T3 (es) | Gestión de claves para comunicación segura | |
ES2706540T3 (es) | Sistema de credenciales de equipos de usuario | |
JP5118048B2 (ja) | セキュリティ・アソシエーションを確立するための方法および装置 | |
ES2424119T3 (es) | Gestión segura de claves en sistema de conferencia | |
US8850203B2 (en) | Secure key management in multimedia communication system | |
CN100592731C (zh) | 端到端加密数据电信的合法侦听 | |
US8855315B2 (en) | Method and system for realizing secure forking call session in IP multimedia subsystem | |
WO2008030571A2 (en) | Method and system for establishing real-time authenticated and secured communication channels in a public network | |
JP5342818B2 (ja) | 管理装置、登録通信端末、非登録通信端末、ネットワークシステム、管理方法、通信方法、及びコンピュータプログラム。 | |
CN110035083A (zh) | 基于会话密钥的通信方法、设备及计算机可读存储介质 | |
JP5746774B2 (ja) | セキュアな通信のための鍵管理 | |
CN101719894B (zh) | 一种安全发送延迟媒体的实现***及方法 | |
ES2400527T3 (es) | Procedimiento de autenticación remota de un abonado de red telefónica |