ES2589112T3 - Gestión de claves para comunicación segura - Google Patents

Gestión de claves para comunicación segura Download PDF

Info

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
Application number
ES07852199.4T
Other languages
English (en)
Inventor
Rolf Blom
Yi Cheng
Fredrik Lindholm
John Mattsson
Mats NÄSLUND
Karl Norrman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2589112T3 publication Critical patent/ES2589112T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    REIVINDICACIONES
    1. 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. 2. El metodo de la reivindicacion 1, caracterizado por que el arranque se realiza segun el metodo de GBA.
  3. 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. 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. 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. 6. El metodo de la reivindicacion 1, caracterizado por que dicho identificador comprende un nonce.
  7. 7. El metodo de la reivindicacion 1, caracterizado por que dicho identificador comprende una direccion de referencia.
  8. 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. 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. 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. 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. 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. 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 el
    10 asiento hacia la al menos una parte respondedora.
  14. 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 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 20 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.
ES07852199.4T 2007-11-30 2007-11-30 Gestión de claves para comunicación segura Active ES2589112T3 (es)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

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