[go: up one dir, main page]

ES3037810T3 - Method, device, and system for anchor key generation and management in a communication network for encrypted communication with service applications - Google Patents

Method, device, and system for anchor key generation and management in a communication network for encrypted communication with service applications

Info

Publication number
ES3037810T3
ES3037810T3 ES20887115T ES20887115T ES3037810T3 ES 3037810 T3 ES3037810 T3 ES 3037810T3 ES 20887115 T ES20887115 T ES 20887115T ES 20887115 T ES20887115 T ES 20887115T ES 3037810 T3 ES3037810 T3 ES 3037810T3
Authority
ES
Spain
Prior art keywords
key
network
anchor key
authentication
akma
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
ES20887115T
Other languages
English (en)
Inventor
Shilin You
Jiyan Cai
Jin Peng
Wantao Yu
Yuze Liu
Zhaoji Lin
Yuxin Mao
Jigang Wang
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.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Application granted granted Critical
Publication of ES3037810T3 publication Critical patent/ES3037810T3/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
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

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)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Esta divulgación se refiere generalmente a la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio a través de una red de comunicaciones. Dicha comunicación cifrada puede basarse en varios niveles jerárquicos de claves de cifrado generadas y gestionadas por la red de comunicaciones. Dicha comunicación cifrada y la gestión de claves pueden ser proporcionadas por la red de comunicaciones a los dispositivos terminales como un servicio al que pueden suscribirse. Los distintos niveles de claves de cifrado pueden gestionarse para mejorar la flexibilidad de la red de comunicaciones y reducir posibles brechas de seguridad. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método, dispositivo y sistema para generación y gestión de clave de anclaje en una red de comunicación para comunicación cifrada con aplicaciones de servicio
Campo técnico
Esta divulgación está dirigida a la generación y gestión de clave de anclaje y clave de aplicación para comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en redes de comunicación.
Antecedentes
En una red de comunicación, pueden establecerse una sesión de comunicación y trayectorias de datos para soportar la transmisión de flujos de datos entre un dispositivo terminal y una aplicación de servicio. La transmisión de tales flujos de datos puede protegerse mediante claves de cifrado/descifrado. La generación y gestión de validez de diversos niveles de claves de cifrado/descifrado puede proporcionarse mediante esfuerzos colaborativos de diversas funciones de red o nodos de red en la red de comunicación durante procedimientos de registro para autenticar el dispositivo terminal en la red de comunicación y durante sesiones de comunicación activas entre el terminal dispositivo y la aplicación de servicio.
3GPP TR 33.835 V2.0.0, Mohsin et al: "Privacy Preserving AKMA in 5G" (11-11-2019) páginas 45-56 ISBN:978-1-4503-6832, y 3GPP TS 33.535 V0.2.0 (02-01-2020) son documentos relacionados de la técnica anterior.
Sumario
La invención se especifica por las reivindicaciones independientes. Se definen realizaciones preferidas en las reivindicaciones dependientes. En la siguiente descripción, aunque numerosas características pueden designarse como opcionales, se reconoce, no obstante, que ninguna de las características comprendidas en las reivindicaciones independientes ha de interpretarse como opcional. Esta divulgación se refiere a la generación y gestión de clave de anclaje y clave de aplicación para comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en redes de comunicación.
En algunas implementaciones, se divulga un método para la generación de una clave de anclaje en un dispositivo de red en una red de comunicación para habilitar la transmisión de datos cifrados con una aplicación de servicio registrada con la red de comunicación. El método puede realizarse por el dispositivo de red y puede incluir: obtener un paquete de datos de suscripción asociado con una suscripción de un módulo de red de usuario a un servicio de gestión de claves de anclaje proporcionado por la red de comunicación; extraer del paquete de datos de suscripción un conjunto de datos de suscripción relacionado con la aplicación de servicio; generar una clave de autenticación base tras la finalización con éxito de un proceso de autenticación para registrar el módulo de red de usuario con la red de comunicación; generar la clave de anclaje basándose en la clave de autenticación base y el conjunto de datos de suscripción; y habilitar la comunicación cifrada entre un equipo de usuario asociado con el módulo de red de usuario y la aplicación de servicio a través de una clave de cifrado de aplicación generada basándose en la clave de anclaje. En algunas implementaciones, el dispositivo de red anterior puede incluir un equipo de usuario o un nodo de red de autenticación en la red de comunicación.
En una cualquiera de las implementaciones anteriores, el conjunto de datos de suscripción puede incluir un identificador de un nodo de red de gestión de clave de aplicación en la red de comunicación que está asociado con la aplicación de servicio. Además, en una cualquiera de las implementaciones anteriores, generar la clave de anclaje puede incluir generar la clave de anclaje basándose en la clave de autenticación base y al menos uno del identificador del nodo de red de gestión de clave de aplicación, un identificador del módulo de red de usuario, un tipo del módulo de red de usuario, y un conjunto de datos de autenticación generado durante el proceso de autenticación para registrar el equipo de usuario con la red de comunicación.
En algunas otras implementaciones, se divulga un dispositivo de red. El dispositivo de red principal incluye uno o más procesadores y una o más memorias, en donde el uno o más procesadores están configurados para leer código informático de la una o más memorias para implementar uno cualquiera de los métodos anteriores.
En algunas otras implementaciones más, se divulga un producto de programa informático. El producto de programa informático puede incluir un medio de programa legible por ordenador no transitorio con código informático almacenado en el mismo, haciendo el código informático, cuando es ejecutado por uno o más procesadores, que el uno o más procesadores implementen uno cualquiera de los métodos anteriores.
Las realizaciones anteriores y otros aspectos y alternativas de sus implementaciones se explican con mayor detalle en los dibujos, las descripciones y las reivindicaciones que siguen.
Breve descripción de los dibujos
La Figura 1 muestra una red de comunicación de ejemplo que incluye dispositivos terminales, una red de portadora, red de datos y aplicaciones de servicio.
La Figura 2 muestra funciones de red o nodos de red de ejemplo en una red de comunicación.
La Figura 3 muestra funciones de red o nodos de red de ejemplo en una red comunicación inalámbrica. La Figura 4 muestra una implementación de ejemplo para autenticación de usuario y generación de clave de anclaje de aplicación en una red de comunicación inalámbrica.
La Figura 5 muestra una vista funcional de ejemplo de diversos nodos de red y funciones de red para la generación de claves en diversos niveles para posibilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 6 muestra un flujo lógico de ejemplo para la generación de diversos niveles de claves de cifrado para posibilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 7 muestra una vista arquitectónica de ejemplo y diversos nodos de red y funciones de red para suscripción a un servicio de gestión de claves de aplicación y generación de claves en diversos niveles para posibilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 8 muestra un flujo lógico de ejemplo para la suscripción a un servicio de gestión de claves de aplicación, autenticación de usuario y generación de clave de anclaje de aplicación para habilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 9 muestra un flujo lógico de ejemplo para la suscripción a un servicio de gestión de claves de aplicación, autenticación de usuario y generación de diversos niveles de claves de cifrado para habilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 10 muestra otro flujo lógico de ejemplo para la suscripción a un servicio de gestión de claves de aplicación, autenticación de usuario y generación de diversos niveles de claves de cifrado para habilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 11 muestra otro flujo lógico de ejemplo para la suscripción a un servicio de gestión de claves de aplicación, autenticación de usuario y generación de diversos niveles de claves de cifrado para habilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 12 muestra otro flujo lógico de ejemplo más para la suscripción a un servicio de gestión de claves de aplicación, autenticación de usuario y generación de diversos niveles de claves de cifrado para habilitar la comunicación cifrada entre dispositivos terminales y aplicaciones de servicio en una red de comunicación inalámbrica.
La Figura 13 muestra un flujo lógico de ejemplo para actualizar claves de anclaje de aplicación o claves de aplicación no válidas en una red de comunicación inalámbrica.
La Figura 14 muestra un flujo lógico de ejemplo para re-autenticación/registro en diversas situaciones en las que las claves de cifrado en diversos niveles se vuelven no válidas.
Descripción detallada
Una red de comunicación de ejemplo, mostrada como 100 en la Figura 1, puede incluir dispositivos terminales 110 y 112, una red de portadora 102, diversas aplicaciones de servicio 140 y otras redes de datos 150. La red de portadora 102, por ejemplo, puede incluir redes de acceso 120 y una red central 130. La red de portadora 102 puede configurarse para transmitir voz, datos y otra información (denominada colectivamente tráfico de datos) entre los dispositivos terminales 110 y 112, entre los dispositivos terminales 110 y 112 y las aplicaciones de servicio 140, o entre los dispositivos terminales 110 y 112 y las otras redes de datos 150. Pueden establecerse y configurarse sesiones de comunicación y trayectorias de datos correspondientes para tal transmisión de datos. Las redes de acceso 120 pueden configurarse para proporcionar a los dispositivos terminales 110 y 112 acceso de red a la red central 130. La red central 130 puede incluir diversos nodos de red o funciones de red configuradas para controlar las sesiones de comunicación y realizar gestión de acceso de red y encaminamiento de tráfico de datos. Las aplicaciones de servicio 140 pueden alojarse por diversos servidores de aplicaciones que son accesibles por los dispositivos terminales 110 y 112 a través de la red central 130 de la red de portadora 102. Una aplicación de servicio 140 puede desplegarse como una red de datos fuera de la red central 130. Análogamente, las otras redes de datos 150 pueden ser accesibles por los dispositivos terminales 110 y 112 a través de la red central 130 y pueden aparecer como destino de datos o fuente de datos de una sesión de comunicación particular instanciada en la red de portadora 102.
La red central 130 de la Figura 1 puede incluir diversos nodos de red o funciones distribuidas geográficamente e interconectadas para proporcionar cobertura de red de una región de servicio de la red de portadora 102. Estos nodos o funciones de red pueden implementarse como elementos de red de hardware especializados. Como alternativa, estos nodos o funciones de red pueden virtualizarse e implementarse como máquinas virtuales o como entidades de software. Un nodo de red puede configurarse cada uno con uno o más tipos de funciones de red. Estos nodos de red o funciones de red pueden proporcionar colectivamente las funcionalidades de aprovisionamiento y encaminamiento de la red central 130. La expresión "nodos de red" y "funciones de red" se usan indistintamente en esta divulgación.
La Figura 2 muestra además una división de ejemplo de funciones de red en la red central 130 de una red de comunicación 200. Aunque en la Figura 2 únicamente se ilustran instancias únicas de nodos o funciones de red, los expertos en la materia entienden que cada uno de estos nodos de red puede ser instanciado como múltiples instancias de nodos de red que se distribuyen a través de toda la red central 130. Como se muestra en la Figura 2, la red central 130 puede incluir, pero sin limitación, nodos de red tales como el nodo de red de gestión de acceso (AMNN) 230, el nodo de red de autenticación (AUNN) 260, el nodo de red de gestión de datos de red (NDMNN) 270, el nodo de red de gestión de sesión (SMNN) 240, el nodo de red de encaminamiento de datos (DRNN) 250, el nodo de red de control de políticas (PCNN) 220 y el nodo de red de gestión de datos de aplicación (ADMNN) 210. La señalización y el intercambio de datos de ejemplo entre los diversos tipos de nodos de red a través de diversas interfaces de comunicación se indican mediante las diversas líneas de conexión de línea continua en la Figura 2. Tal señalización e intercambio de datos puede transportarse mediante señalización o mensajes de datos siguiendo formatos o protocolos predeterminados.
Las implementaciones descritas anteriormente en las Figuras 1 y 2 pueden aplicarse a sistemas de comunicación tanto inalámbricos como alámbricos. La Figura 3 ilustra una red de comunicación inalámbrica celular 300 de ejemplo basada en la implementación general de la red de comunicación 200 de la Figura 2. La Figura 3 muestra que la red de comunicación inalámbrica 300 puede incluir el equipo de usuario (UE) 310 (que funciona como el dispositivo terminal 110 de la Figura 2), la red de acceso por radio (RAN) 320 (que funciona como la red de acceso 120 de la Figura 2), las aplicaciones de servicio 140, la red de datos (DN) 150 y la red central 130 que incluyen la función de gestión de acceso (AMF) 330 (que funciona como la AMNN 230 de la Figura 2), la función de gestión de sesión (SMF) 340 (que funciona como la SMNN 240 de la Figura 2), la función de aplicación (AF) 390 (que funciona como la ADMNN 210 de la Figura 2), la función de plano de usuario (UPF) 350 (que funciona como la DRNN 250 de la Figura 2), la función de control de políticas 322 (que funciona como la PCN<n>220 de la Figura 2), la función de servidor de autenticación (AUSF) 360 (que funciona como la AUNN 260 de la Figura 2), y la función de gestión de datos universal (UDM) 370 (que funciona como la UDMNN 270 de la Figura 2). De nuevo, aunque en la Figura 3 únicamente se ilustran instancias únicas para algunas funciones de red o nodos de la red de comunicación inalámbrica 300 (la red central 130 en particular), los expertos en la materia entienden que cada uno de estos nodos o funciones de red puede tener múltiples instancias que se distribuyen a través de toda la red de comunicación inalámbrica 300.
En la Figura 3, el UE 310 puede implementarse como diversos tipos de dispositivos móviles que están configurados para acceder a la red central 130 a través de la RAN 320. El U<e>310 puede incluir, pero sin limitación, teléfonos móviles, ordenadores portátiles, tabletas, dispositivos de Internet de las Cosas (IoT), nodos de red de sensores distribuidos, dispositivos llevables y similares. La RAN 320, por ejemplo, puede incluir una pluralidad de estaciones base de radio distribuidas a través de todas las áreas de servicio de la red de portadora. La comunicación entre el UE 310 y la RAN 320 puede transportarse en interfaces de radio por el aire (OTA) como se indica por 311 en la Figura 3.
Continuando con la Figura 3, la UDM 370 puede formar un almacenamiento o base de datos permanente para datos de contrato y suscripción de usuario. La UDM puede incluir además una función de repositorio y procesamiento de credenciales de autenticación (ARPF, como se indica en 370 de la Figura 3) para el almacenamiento de credenciales de seguridad a largo plazo para la autenticación de usuario, y para usar tales credenciales de seguridad a largo plazo como entrada para realizar el cálculo de claves de cifrado como se describe con más detalle a continuación. Para evitar la exposición no autorizada de datos de UDM/ARPF, la UDM/ARPF 370 puede ubicarse en un entorno de red seguro de un operador de red o un tercero.
La AMF/SEAF 330 puede comunicarse con la RAN 320, la SMF 340, la AUSF 360, la UDM/ARPF 370 y la PCF 322 a través de interfaces de comunicación indicadas por las diversas líneas continuas que conectan estos nodos o funciones de red. La AMF/SEAF 330 puede ser responsable de la gestión de señalización del estrato sin acceso (NAS) del UE, y para aprovisionar el registro y el acceso del UE 310 a la red central 130, así como la asignación de la SMF 340 para soportar la necesidad de comunicación de un UE particular. La AMF/SEAF 330 puede ser responsable adicional de la gestión de movilidad de UE. La AMF también puede incluir una función de anclaje de seguridad (SEAF, como se indica en 330 de la Figura 3) que, como se describe con más detalle a continuación, interactúa con la AUSF 360 y el UE 310 para la autenticación de usuario y la gestión de diversos niveles de claves de cifrado/descifrado. La AUSF 360 puede terminar solicitudes de registro/autenticación/generación de clave de usuario desde la AMF/SEAF 330 e interactuar con la UDM/ARPF 370 para completar tal registro/autenticación/generación de clave de usuario.
La SMF 340 puede asignarse por la AMF/SEAF 330 para una sesión de comunicación particular instanciada en la red de comunicación inalámbrica 300. La SMF 340 puede ser responsable de asignar la UPF 350 para soportar la sesión de comunicación y los flujos de datos en la misma en un plano de datos de usuario y para aprovisionar/regular la UPF 350 asignada (por ejemplo, para formular reglas de detección y reenvío de paquetes para la UPF 350 asignada). Como alternativa a ser asignada por la SMF 340, la UPF 350 puede ser asignada por la AMF/SEAF 330 para la sesión de comunicación y los flujos de datos particulares. La UPF 350 asignada y aprovisionada por la SMF 340 y la AMF/SEAF 330 puede ser responsable del encaminamiento y reenvío de datos y de notificar el uso de red por la sesión de comunicación particular. Por ejemplo, la UPF 350 puede ser responsable de encaminar flujos de datos de extremo a extremo entre el UE 310 y la DN 150, entre el UE 310 y las aplicaciones de servicio 140. La DN 150 y las aplicaciones de servicio 140 pueden incluir, pero sin limitación, red de datos y servicios proporcionados por el operador de la red de comunicación inalámbrica 300 o por proveedores de servicios y red de datos de terceros.
Las aplicaciones de servicio 140 pueden gestionarse y aprovisionarse por la AF 390 a través de, por ejemplo, funciones de exposición de red proporcionadas por la red central 130 (no mostrada en la Figura 3, pero se muestra en la Figura 7 que se describe a continuación). La SMF 340, al gestionar una sesión de comunicación particular que implica una aplicación de servicio 140 (por ejemplo, entre el UE 310 y la aplicación de servicio 140), puede interactuar con la AF 390 asociada con la aplicación de servicio 140 a través de una interfaz de comunicación indicada por 313.
La PCF 322 puede ser responsable de gestionar y proporcionar diversos niveles de políticas y reglas aplicables a una sesión de comunicación asociada con el UE 310 a la A<m>F/SEAF 330 y la SMF 340. Como tal, la AMF/SEAF 330, por ejemplo, puede asignar la SMF 340 para la sesión de comunicación de acuerdo con políticas y reglas asociadas con el u E 310 y obtenidas de la PCF 322. Análogamente, la SMF 340 puede asignar la UPF 350 para manejar el encaminamiento y reenvío de datos de la sesión de comunicación de acuerdo con políticas y reglas obtenidas de la PCF 322.
Mientras que las Figuras 2-14 y las diversas implementaciones de ejemplo descritas a continuación se basan en redes de comunicación inalámbrica celular, el alcance de esta divulgación no está tan limitado y los principios subyacentes son aplicables a otros tipos de redes de comunicación inalámbricas y alámbricas.
La identidad de red y seguridad de datos en la red de comunicación inalámbrica 300 de la Figura 3 puede gestionarse<a través de procesos de autenticación de usuario proporcionados por la AMF/SEAF 330, la AUSF>360<y la UDM/ARPF>370. En particular, el UE 310 puede comunicarse en primer lugar con la AMF/SEAF 330 para registro de red y puede a continuación autenticarse por la AUSF 360 de acuerdo con datos de contrato y suscripción de usuario en la UDM/ARPF 370. Las sesiones de comunicación establecidas para el UE 310 después de la autenticación de usuario a la red de comunicación inalámbrica 300 pueden protegerse a continuación por los diversos niveles de claves de cifrado/descifrado. La generación y gestión de las diversas claves puede orquestarse por la AUSF 360 y otras funciones de red en la red de comunicación.
La autenticación del UE 310 a la red de comunicación inalámbrica 300 puede basarse en la verificación de identidad de red asociada con el UE 310. En algunas implementaciones, el UE 310 puede incluir un módulo de identificación además de un equipo móvil principal (ME). El ME, por ejemplo, puede incluir el dispositivo terminal principal que tiene capacidades de procesamiento de información (uno o más procesadores y una o más memorias) y está instalado con un sistema operativo móvil y otros componentes de software para proporcionar necesidades de comunicación y procesamiento para el UE 310. El módulo de identidad puede incluirse con el UE 310 para identificar y autenticar al usuario a la red de comunicación, y para asociar el usuario con el ME. El módulo de identidad puede implementarse como diversas generaciones de un módulo de identificación de abonado (SIM). Por ejemplo, el módulo de identidad puede implementarse como un módulo de identidad de abonado universal (USIM) o tarjeta de circuito integrado universal (UICC). El módulo de identidad puede incluir una identificación de usuario o un derivado de la misma. La identificación de usuario puede asignarse por el operador de la red de comunicación cuando el usuario se suscribe inicialmente a la red de comunicación inalámbrica 300.
La identificación de usuario puede incluir, por ejemplo, un identificador permanente de suscripción (SUPI) asignado por el operador de la red de comunicación inalámbrica al usuario. En algunas implementaciones, el SUPI puede incluir un número de identificación de abonado móvil internacional (IMSI) o un identificador de acceso de red (NAI). Como alternativa a SUPI, la identificación de usuario puede proporcionarse en forma de una identificación oculta tal como identificador oculto de suscripción (SUCI). En un SUCI, la identificación del usuario puede ocultarse y protegerse mediante cifrado. Por ejemplo, un SUCI puede incluir: 1) un tipo de SUPI que puede ocupar un número predeterminado de bits de información (por ejemplo, tres bits para el valor 0-7, donde el valor 0 puede indicar que la identificación de usuario es de tipo de IMSI, el valor 1 puede indicar que la identificación de usuario es del tipo de NAI, y pueden reservarse otros valores para otros posibles tipos); 2) identificador de red doméstica para la red inalámbrica a la que se suscribe el usuario, que puede incluir un código de país móvil (MCC) y un código de red móvil (MNC) para el operador de la red de comunicación inalámbrica 300 cuando el SUPI para el usuario es de tipo de IMSI, y puede incluir, como alternativa, un identificador especificado en, por ejemplo, la sección 2.2 de IETF RFC 7542, cuando el SUPI para el usuario es del tipo de NAI; 3) indicador de encaminamiento (RID) asignado por el operador de la red de comunicación inalámbrica 300, que junto con el identificador de red doméstica anterior determina la AUSF y la UDM asociadas con el UE 310; 4) identificador de esquema de protección (PSI) para indicar una elección entre sin protección (esquema nulo) o con protección (esquema no nulo); 5) identificador de clave pública de red doméstica para especificar un identificador para una clave pública proporcionada por la red doméstica para proteger el SUPI (este valor de identificador puede establecerse como cero cuando el<p>S<i>anterior indica esquema nulo); y 6) una salida de esquema que puede incluir una porción de número de identificación de abonado móvil (MSIN) del IMSI o el NAI cifrado por la clave pública de red doméstica usando, por ejemplo, una cifrado de curva elíptica cuando el PSI anterior indica un esquema no nulo, y puede incluir el MSIN o NAI (sin cifrado) cuando la PSI anterior indica un esquema nulo. Como un ejemplo para el SUCI, cuando la IMSI es 234150999999999, es decir, MCC = 234, MNC = 15 y MSIN = 0999999999, y suponiendo que el RID es 678 y que el identificador de clave pública de red doméstica es 27, un SUCI desprotegido puede incluir {0, (234, 15), 678, 0, 0 y 0999999999}, y un SUCI protegido puede incluir {0, (234, 15), 678, 1, 27, < cifrado de curva elíptica de 0999999999 usando la clave pública indicada por el identificador de clave pública 27>}.
Debido a que porciones de las trayectorias de datos de las sesiones de comunicación entre el UE 310 con otros UE, el DN 150 o las aplicaciones de servicio 140 a través de la red central 130 pueden estar fuera de un entorno de comunicación seguro dentro, por ejemplo, de la red central 130, la identidad de usuario y los datos de usuario transmitidos en estas trayectorias de datos, por lo tanto, pueden estar expuestos a un entorno de red no seguro y pueden estar sometidos a brechas de seguridad. Como tal, puede preferirse proteger además los datos transmitidos en las sesiones de comunicación usando diversos niveles de claves de cifrado/descifrado. Como se ha indicado anteriormente, estas claves pueden gestionarse por la AUSF 360 junto con el proceso de autenticación de usuario a la red de comunicación inalámbrica 300. Estas claves de cifrado/descifrado pueden organizarse en múltiples niveles y de una manera jerárquica. Por ejemplo, puede generarse una clave base de primer nivel por la AUSF 360 para el UE 310 tras la suscripción inicial al servicio de la red de comunicación inalámbrica 300. Una clave base de segundo nivel puede configurarse para el UE 310 tras cada registro y autenticación a la red de comunicación inalámbrica. Una clave base de segundo nivel de este tipo puede ser válida durante una sesión de registro para el UE 310 y puede usarse como una clave base para generar otras claves de nivel superior. Un ejemplo de tales claves de nivel superior puede incluir, una clave de anclaje que puede usarse para derivar claves de niveles incluso más altos para su uso como claves de cifrado/descifrado reales para transmitir datos en sesiones de comunicación.
Tal esquema de clave de múltiples niveles puede ser particularmente útil para sesiones de comunicación que implican el UE 310 y las aplicaciones de servicio 140. En particular, puede generarse una clave de anclaje de aplicación basándose en una clave base y gestionarse como un anclaje de seguridad para comunicaciones entre el Ue 310 y múltiples aplicaciones de servicio. Diferentes sesiones de comunicación con diferentes aplicaciones de servicio 140 para el UE 310 pueden usar diferentes claves de cifrado/descifrado de datos. Cada una de estas diferentes claves de cifrado/descifrado de datos puede generarse y gestionarse independientemente basándose en la clave de anclaje.
En algunas implementaciones, la red central 130 puede configurarse para abarcar una arquitectura especial para autenticación y gestión de claves para aplicaciones de servicio (AKMA). La red de comunicación inalámbrica 300, por ejemplo, puede incluir además funciones de anclaje de AKMA (AAnF) o nodos de red en su red central 130. Una AAnF 380 de ejemplo se ilustra en la Figura 3. La AAnF 380 puede ser responsable de la generación y gestión de claves de cifrado/descifrado de datos para diversas aplicaciones de servicio en colaboración con la AUSF 360 y diversas AF 390 asociadas con las diversas aplicaciones de servicio. La AAnF 380 puede ser responsable además del mantenimiento del contexto de seguridad para el UE 310. Por ejemplo, la funcionalidad de la AAnF 380 puede ser similar a la función de servidor de arranque (BSF) en la arquitectura de arranque general (GBA). Múltiples AAnF 380 pueden desplegarse en la red central 130 y cada AAnF 380 puede asociarse con y ser responsable de la gestión de claves de una o más aplicaciones de servicio y correspondientes AF 390.
Las Figuras 4 y 5 ilustran implementaciones de ejemplo para la AKMA jerárquica anterior. Por ejemplo, la Figura 4 ilustra una implementación 400 para la generación de una clave base y una clave de anclaje para sesiones de comunicación que implican una aplicación de servicio. Específicamente, la implementación 400 puede incluir el procedimiento de autenticación de usuario 402 y el procedimiento de generación de clave de anclaje 404. El procedimiento de autenticación de usuario 402, por ejemplo, puede implicar acciones desde el UE 310, la AMF/SEAF 330, la AUSF 360 y la UDM/ARPF 370. Por ejemplo, el UE 310, tras entrar en la red de comunicación inalámbrica, puede comunicar una solicitud de registro y autenticación de red a la AMF/SEAF 330. Tal solicitud puede reenviarse por la AMF/SEAF 330 a la AUSF 360 para su procesamiento. Durante el proceso de autenticación, la AUSF 360 puede obtener contrato de usuario e información de suscripción desde la UDM/ARPF 370. El proceso de autenticación para un sistema inalámbrico 5G, por ejemplo, puede basarse en el protocolo 5G-AKA (autenticación y acuerdo de clave) o EAP-AKA (protocolo de autenticación extendido-AKA). Tras una autenticación con éxito, puede generarse un vector de autenticación por la UDM/ARPF 370 y tal vector de autenticación puede transmitirse a la AUSF 360. Después del procedimiento de autenticación de usuario con éxito 402, puede generarse una clave base tanto en el lado del UE 310 como en la AUSF 360 en el lado de la red. Una clave base de este tipo puede denominarse K<ausf>.
Como se muestra adicionalmente por 410 y 420 en la Figura 4, se puede derivar una clave de anclaje basándose en la clave base K<ausf>tanto en el UE 310 como en la AUSF 360 en el procedimiento de generación de clave de anclaje 404. Una clave de anclaje de este tipo puede denominarse K<akma>. Como se muestra además por 412 y 422 en la Figura 4, un identificador para la clave de anclaje K<akma>puede generarse en el UE 310 y la AUSF 360. Un identificador de este tipo puede denominarse K<id>.
La Figura 5 ilustra además una implementación 500 de ejemplo para la generación de una clave de aplicación 506 para comunicación cifrada entre el UE y una aplicación de servicio, además de la generación de la clave base K<ausf>502 y la clave de anclaje K<akma>504. Como se muestra en la Figura 5, la clave de aplicación 506, indicada como K<af>, puede generarse tanto en el lado de la red como en el lado del UE basándose en la clave de anclaje K<akma>504. Particularmente, en el lado de red, mientras que la clave de anclaje K<akma>504 puede generarse por la AUSF 360 basándose en la clave base K<ausf>502, la generación de la clave de aplicación K<af>506 puede implicar la AAnF 380. En el lado del UE de la Figura 5, la generación de la clave de anclaje K<akma>504 y clave de aplicación K<af>506 se ilustra como realizada por la porción de ME (equipo móvil) 510 del UE. En particular, tal generación de claves en el lado de UE puede implicar principalmente utilizar la potencia y capacidad de procesamiento del ME después de que se complete el procedimiento de autenticación de usuario 402 que implica el módulo de identidad (por ejemplo, SIM) dentro del UE.
En el esquema de gestión de claves de aplicación ilustrado en las Figuras 4 y 5, una o más AAnF 380 pueden estar distribuidas en la red central y cada una de las una o más AAnF 380 puede estar asociada con una o más AF 390. Como tal, cada una de la una o más AAnF 380 puede asociarse con una o más aplicaciones de servicio y puede ser responsable de la generación y gestión de claves de aplicación para comunicación cifrada que implica estas aplicaciones de servicio. Aunque todas las claves de aplicación para una de estas aplicaciones de servicio pueden generarse basándose en la misma clave de anclaje K<akma>504, estas claves de aplicación, en el lado de red, pueden generarse independientemente por la correspondiente AAnF 380.
La Figura 6 ilustra además un flujo lógico 600 de ejemplo para la generación de una clave de aplicación asociada con una aplicación de servicio para habilitar la comunicación cifrada entre el UE 310 y la correspondiente AF 390. En la etapa 601-1, el UE 310 puede registrarse y autenticarse en primer lugar satisfactoriamente por la AMF/SEAF 330, la AUSF 360 y la UDM/ARPF 370 (similar a 402 en la Figura 4). Después del registro y autenticación de UE, puede generarse la clave base K<ausf>. En la etapa 601-2, puede generarse la clave de anclaje K<akma>y el correspondiente identificador K<id>tanto en el lado del UE como en el lado de la red (similar a 410, 412, 420 y 422 de la Figura 4). En la etapa 602, el UE 310 inicia una sesión de comunicación con la aplicación de servicio asociada con la AF 390 enviando un mensaje de solicitud de comunicación. La solicitud puede incluir el identificador K<id>generado en la etapa 601-2 y asociado con la clave de anclaje K<akma>generada en la etapa 601-1. En la etapa 603, la AF 390 puede enviar un mensaje de solicitud de clave a la AAnF 380, donde el mensaje de solicitud de clave incluye el identificador de clave de anclaje K<id>y un identificador de la AF 390, AF<id>. En la etapa 604, la AAnF 380 determina si la clave de anclaje K<akma>asociada con el identificador de clave de anclaje K<id>se puede ubicar en AAnF 380. Si se encuentra K<akma>en la AAnF 380, el flujo lógico 600 continúa a la etapa 607. De lo contrario, la AAnF 380 puede enviar una solicitud de clave de anclaje a la AUSF 360 en la etapa 604 que transporta el identificador de clave de anclaje K<id>y recibir la clave de anclaje K<akma>desde la AUSF 360 en la etapa 605 después de que la AUSF 360 identifica la clave de anclaje K<akma>de acuerdo con el identificador de clave de anclaje K<id>en una respuesta a la solicitud de clave de anclaje desde la AAnF 380. En la etapa 606, la AAnF 380 deriva la clave de aplicación K<af>basándose en la clave de anclaje K<akma>si la K<af>no se ha derivado previamente en la AAnF 380 todavía o ya ha expirado. La K<akma>derivado puede asociarse con un periodo de tiempo de validez de clave de aplicación (o tiempo de expiración). En la etapa 607, la AAnF 380 puede enviar la clave de aplicación K<af>y el tiempo de expiración correspondiente a la AF 390. Después de obtener la K<akma>desde la AAnF 380, la AF puede responder finalmente a la solicitud de comunicación enviada desde el UE 310 en la etapa 602. La respuesta en la etapa 608, por ejemplo, puede incluir el tiempo de expiración para K<af>y tal tiempo de expiración puede registrarse y almacenarse por el UE 310.
La Figura 7 ilustra otra vista arquitectónica 700 de ejemplo para las implementaciones de AKMA por las diversas funciones de red divulgadas anteriormente. Las diversas funciones tales como AMF/SEAF 330, AUSF 360, AF 390, UDM/ARPF 370, UE 310 y AAnF 380 se ilustran para interactuar entre sí de acuerdo con las implementaciones de ejemplo descritas anteriormente a través de las diversas interfaces asociadas con estas funciones de red, tal como la interfaz Namf para la AMF/SEAF 330, la interfaz Nausf para la AUSF 360, la interfaz Naf de la AF 390, la interfaz Nudm para la UDM/ARPF 370 y la interfaz Naanf para la AAnF 380, como se indica en la Figura 7. La Figura 7 muestra además la función de exposición de red (NEF) 702 como una puerta de enlace para proporcionar exposición de capacidad de la red central a la AF 390 asociada con las aplicaciones de servicio. En la vista arquitectónica 700 de ejemplo de la Figura 7, el UE 310 puede comunicarse con la AF 390 a través de la interfaz Ua, y la AMF/SEAF 330 a través de la interfaz N1. La comunicación desde el UE 310 a la red central se retransmite por la RAN 320.
En las implementaciones descritas anteriormente, la AUSF, la UDM, la AUSF y la AAnF pertenecen a la red doméstica del UE 310. Pueden ubicarse dentro de un entorno de red seguro proporcionado por el operador o un tercero autorizado y pueden no estar expuestas a acceso de red no autorizado. En un escenario de itinerancia, la UDM doméstica y la AUSF proporcionan información de autenticación para el UE, mantienen la ubicación de itinerancia del UE y suministran información de suscripción a la red visitada.
La generación de clave de aplicación y el cifrado/descifrado de los datos transmitidos en las sesiones de comunicación con las aplicaciones de servicio pueden implicar un procesamiento de datos sustancial que requiere un nivel significativo de capacidad informática y consumo de energía. Algunos UE de extremo inferior que son incapaces de tal nivel de cálculo pueden no ser capaces de comunicarse con las aplicaciones de servicio si el cifrado/descifrado de datos descrito anteriormente se hace obligatorio. En algunas implementaciones adicionales descritas a continuación, pueden proporcionarse opciones de tal manera que un UE puede comunicarse con las aplicaciones de servicio con los flujos de datos en las mismas protegidos o desprotegidos por claves de aplicación. Como tal, un UE de extremo inferior que puede no ser capaz de realizar oportunamente la generación de claves de aplicación y el cifrado/descifrado de datos puede, sin embargo, tener la opción de solicitar una sesión de comunicación desprotegida con las aplicaciones de servicio, evitando de esta manera tener que realizar cualquier generación de clave compleja y cifrado/descifrado de datos.
Tales opciones pueden proporcionarse a través de un mecanismo de suscripción de servicio. Por ejemplo, AKMA puede proporcionarse como un servicio al que pueden suscribirse los UE. Por ejemplo, un UE puede suscribirse o no suscribirse al servicio de AKMA. Cuando el UE se suscribe al servicio de AKMA, el UE puede solicitar una sesión de comunicación protegida con una aplicación de servicio. El UE y las diversas funciones de red (tal como la AAnF 380) pueden llevar a cabo de manera correspondiente la generación de clave de aplicación necesaria para el cifrado/descifrado de datos. De lo contrario, cuando el UE no tiene suscripción al servicio de AKMA, el UE puede solicitar únicamente una sesión de comunicación no protegida con una aplicación de servicio y puede no ser necesaria clave de aplicación ni cifrado/descifrado de datos.
Para otro ejemplo, en lugar de suscribirse al servicio de AKMA en su totalidad, un UE puede suscribirse al servicio de AKMA para ninguna, algunas o todas las aplicaciones de servicio disponibles y registradas con la red de comunicación a través de las funciones de exposición de red. Cuando el UE tiene suscripción al servicio de AKMA para una aplicación de servicio particular, el UE puede solicitar una sesión de comunicación protegida con esa aplicación de servicio. El UE y las diversas funciones de red (tal como la AAnF 380) pueden llevar a cabo de manera correspondiente la generación de clave de aplicación necesaria para el cifrado/descifrado de datos. De lo contrario, cuando el UE no tiene suscripción al servicio de AKMA para una aplicación de servicio particular, el UE únicamente puede solicitar una sesión de comunicación no protegida con esa aplicación de servicio y puede no ser necesaria ninguna clave de aplicación y cifrado/descifrado de datos para comunicación con esa aplicación de servicio particular.
La información de suscripción de UE del servicio de AKMA para las aplicaciones de servicio puede gestionarse en el lado de red por la UDM/ARPF 370. En particular, la UDM/<a>R<p>F 370 puede realizar un seguimiento de la información de suscripción de servicio de AKMA para cada UE. La UDM/ARPF 370 puede configurarse para proporcionar una interfaz para otras funciones de red de la red de comunicación, tal como la AUSF 360, para solicitar información de suscripción de servicio de AKMA de un UE particular. La UDM/ARPF 370, por ejemplo, puede entregar información de suscripción de servicio de AKMA de UE a la AUSF 360 a través de la interfaz de Nudm ilustrada en la Figura 7 tras solicitud. En estas implementaciones, la UDM/ARPF 370 está configurada esencialmente para actuar como un repositorio de la información de suscripción de servicio de AKMA además de otras funcionalidades de gestión de datos de usuario. Como alternativa, funciones de red especializada separadas de y distintas de la UDM/ARPF 370 pueden incluirse en la red central y configurarse para gestionar la suscripción de servicio de AKMA.
Tal información de suscripción puede registrarse en diversas formas en la UDM/ARPF 370. La información de suscripción puede indexarse por el UE. Por ejemplo, cada suscripción de servicio de AKMA puede estar asociada con un identificador de UE. Cada suscripción de servicio de AKMA puede incluir además uno o más de (1) un indicador de si el UE se suscribe al servicio de AKMA, (2) identificadores para una o más AAnF asociadas con la suscripción del UE, y (3) los periodos de tiempo de validez (o tiempo de expiración) de las claves de anclaje K<akma>correspondientes a las AAnF. El identificador para una AAnF puede proporcionarse en forma de una dirección de red de la AAnF. Como alternativa, el identificador de la AAnF puede proporcionarse en forma de un nombre de dominio totalmente calificado (FQDN) de la AAnF. Cada UE puede corresponder a una o más AAnF a las que se suscribe.
En correspondencia, el módulo de identidad del UE (por ejemplo, un Módulo de Identidad de Abonado Universitario (USIM) o Tarjeta de Identidad Integrada Universal (UICC)) puede incluir la información de suscripción de servicio de AKMA para el UE. Tal información de suscripción puede incluir uno o más de (1) un indicador de si el UE se suscribe al servicio de AKMA, (2) identificadores de una o más AAnF asociadas con la suscripción de servicio de AKMA del UE, (3) los períodos de tiempo de validez de las claves de anclaje K<akma>correspondientes a las AAnF, y (4) identificadores de AF correspondientes a servicios de aplicación suscritos por el UE. De nuevo, el identificador para una AAnF puede proporcionarse en forma de una dirección de red de la AAnF. Como alternativa, el identificador de una AAnF puede proporcionarse en forma de un FQDN de la AAnF. Cada UE puede corresponder a una o más AAnF suscritas. Análogamente, el identificador para una AF puede proporcionarse en forma de la dirección de red de la AF. Como alternativa, el identificador de la A<f>puede proporcionarse en forma de un FQDN de la AF. Cada UE puede corresponder a una o más AF. En algunas implementaciones, pueden asociarse múltiples AF con una misma AAnF, pero cada AF puede asociarse únicamente con una AAnF.
La Figura 8 muestra flujos lógicos 800, 850 y 860 de ejemplo para autenticación de usuario y generación de la clave de anclaje K<akma>cuando el UE se ha suscrito al servicio de AKMA. El flujo lógico 800 ilustra un procedimiento de registro y autenticación de UE de ejemplo, mientras que el flujo lógico 850 ilustra un proceso de ejemplo para la generación de la clave de anclaje K<akma>y el flujo lógico 860 ilustra otro proceso de ejemplo para la generación de la clave de anclaje K<akma>alternativa al flujo lógico 850. Como se muestra por 840, el UE 310 puede suscribirse al servicio de AKMA y la información de suscripción de servicio de AKMA correspondiente al UE 310 puede registrarse en el UE 310. Tal información de suscripción puede incluir una o más combinaciones de: un indicador de si el UE 310 se ha suscrito al servicio de AKMA; uno o más identificadores de AAnF; uno o más identificadores de AF; y periodos de tiempo de validez de clave de anclaje de AKMA. Como se indica además por 842, la correspondiente información de suscripción de usuario registrada en la UDM/ARPF 370 puede incluir uno o más de: un indicador de si el UE 310 se ha suscrito al servicio de AKMA; uno o más identificadores de AAnF; y el periodo de tiempo de validez de la clave de anclaje de AKMA. Durante el procedimiento de registro y autenticación de UE, la UDM/a Rp F 370 puede transmitir la información de suscripción de servicio de AKMA a la AUSF 360. Tras un registro y autenticación de UE con éxito, la AUSF 360 puede derivar la clave de anclaje de AKMA basándose en la información de suscripción de servicio de AKMA recibida desde la UDM/ARPF 370. Mientras tanto, el UE 310 también puede derivar la clave de anclaje de AKMA basándose en la información de suscripción de servicio de AKMA almacenada en el UE 310.
Las etapas de ejemplo específicas para el registro/autenticación de UE y la generación de clave de anclaje de AKMA se ilustran mediante las etapas 801 a 810 en la Figura 8. En la etapa 801, el UE 310 envía un mensaje de solicitud a la AMF/SEAF 330 para iniciar un registro/autenticación del UE 310 a la red. La AMF/SEAF 330 puede proporcionarse por la red doméstica del UE o por una red visitante en la situación en el que el UE está en itinerancia. El mensaje de solicitud puede incluir un identificador de usuario del UE 310, tal como SUCI o Identidad de UE Temporal Globalmente Única de 5G (5G-GUTI). En la etapa 802, la AMF/SEAF 330 envía una solicitud de autenticación de AUSF a la AUSF 360 (por ejemplo, una solicitud Nausf_UEAuthentication_Authenticate). Tal solicitud de AUSF puede incluir el SUCI o SUPI del UE 310. En el caso de que la solicitud de registro/autenticación en la etapa 801 incluya 5G-GUTI, la AMF/SEAF 330 puede obtener en primer lugar SUPI desde la AMF doméstica del UE. Si eso falla, la AMF/SEAF 330 puede obtener SUCI desde el UE 310. La solicitud de AUSF puede incluir además la identidad o nombre de la red de servicio (SN) para el UE 310. En la etapa 803, después de que la AUSF 360 (la AUSF doméstica para el UE) determina que el nombre de SN es válido, la AUSF 360 inicia un mensaje de solicitud de autenticación de usuario (por ejemplo, una solicitud Nudm_UEAuthentication_Get) a la UDM/ARPF 370. Tal mensaje de solicitud de autenticación de usuario puede incluir SUCI o SUPI del UE 310, y puede incluir además el nombre de SN.
Continuando con la Figura 8 en la etapa 804, la UDM/ARPF 370 recibe el mensaje de solicitud de autenticación de usuario de la etapa 803, y puede descifrar el SUCI contenido en el mensaje para obtener SUPI. La UDM/ARPF 370 determina a continuación el tipo de autenticación de usuario (por ejemplo, 5G-AKA o EAP-AKA) y genera un vector de autenticación. La UDM/ARPF 370 consulta además su repositorio de datos de suscripción para determinar si el UE 310 se ha suscrito al servicio de AKMA, y, en caso afirmativo, obtener información de suscripción de servicio de AKMA para el UE 310. La UDM/ARPF 370 responde a continuación al mensaje de solicitud de autenticación de usuario de la etapa 803 mediante un mensaje de retorno que incluye el vector de autenticación, el SUPI descifrado del SUCI y/o la información de suscripción de servicio de AKMA para el UE 310 (por ejemplo, la respuesta Nudm_UEAuthentication_Get) a la AUSF 360. El vector de autenticación generado por la<u>D<m>/A<r>PF 370 e incluido en el mensaje de retorno puede incluir, por ejemplo, un testigo de autenticación (AUTN), un número aleatorio (RAND) y/o diversas claves de autenticación. La información de suscripción de servicio de AKMA para el UE puede incluir, por ejemplo, identificadores para una o más AAnF, y/o periodo de tiempo de validez de la clave de anclaje de AKMA.
Además, en la etapa 805, la AUSF 360 verifica el vector de autenticación enviado desde la UDM/ARPF 370 en la etapa 804 e inicia el procedimiento de autenticación principal. Tal procedimiento de autenticación, por ejemplo, puede basarse en 5G-AKA o EAP-AKA. Después de completar con éxito el procedimiento de autenticación principal, tanto el UE 310 como la AUSF 360 habrían generado la clave base K<ausf>. El UE 310 y AMF/SEAF 330 habrían generado además claves de acceso de estrato y de no de estrato.
El flujo lógico 850 que sigue a la etapa 805 en la Figura 8 ilustra una implementación de ejemplo para la generación de claves de anclaje. Específicamente, en la etapa 806, después de que el flujo lógico de autenticación principal de UE 850 tenga éxito, el UE 310 y la AUSF 360 pueden generar la clave de anclaje de AKMA K<akma>= KDF (K<ausf>, tipo de AKMA, RAND, SUPI, identificador de AAnF). El término "KDF" representa un algoritmo de generación de claves de ejemplo que implica HMAC-SHA-256 (código de autenticación de mensaje basado en función de troceo de 256 bits para algoritmo de función de troceo seguro). K<ausf>representa la clave base. El parámetro "tipo de AKMA" representa diversos tipos de AKMA, por ejemplo, la AKMA puede basarse en el ME (la porción de ME del UE es responsable de la generación de clave y el cálculo de cifrado/descifrado). Para otro ejemplo, la AKMA puede basarse en UICC, donde la capacidad de procesamiento en la UICC del UE se usa para generación de clave y cifrado/descifrado. El parámetro "RAND' representa el número aleatorio en el vector de autenticación generado por la UDM/ARPF 370 en la etapa 804 anterior. Los identificadores de AAnF pueden incluir direcciones de red de las AAnF o los FQDN de las AAnF. Aunque el cálculo de KDF de ejemplo anterior enumera todos los parámetros analizados anteriormente, no todos estos parámetros necesitan incluirse en el cálculo. Cualquier combinación de cualquiera de estos parámetros puede usarse para el cálculo de KDF y para la generación de K<akma>. En algunas implementaciones, el parámetro de K<ausf>puede hacerse obligatorio y los otros parámetros pueden hacerse opcionales. En algunas otras implementaciones, el parámetro K<ausf>y la al menos parte de la información de suscripción de AKMA (por ejemplo, tipo de AKMA, identificador de AAnF) pueden hacerse obligatorios y los otros parámetros pueden hacerse opcionales.
En la etapa 807, el UE 310 y la AUSF 360 pueden generar un identificador para la clave de anclaje de AKMA como, por ejemplo, K<id>=RAND@ identificador de AAnF, o K<id>= base64encode (RAND)@identificador de AAnF. En este punto, RAND es el número aleatorio en el vector de autenticación obtenido a partir de la UDM/ARPF 370 anterior, y el identificador de AAnF incluye la dirección de red de AAnF o la dirección de FQDN. El método de codificación de ejemplo definido por "base64encode" se especifica, por ejemplo, en el protocolo IEFT RFC 3548. Además, en la etapa 808, la AUSF 360, después de calcular la clave de anclaje de AKMA en la etapa 806 y el identificador de clave de anclaje de AKMA en la etapa 807, puede transmitir un mensaje de inserción a la AAnF 380. El mensaje de inserción, por ejemplo, puede incluir la clave de anclaje K<akma>, el identificador de clave de anclaje K<id>, el mensaje de inserción puede incluir además el período de tiempo de validez para la clave de anclaje K<akma>. La AAnF 380 puede almacenar a continuación la clave de anclaje K<akma>e identificador de clave de anclaje K<id>. La AAnF 380 puede identificar además un periodo de tiempo de validez local para la clave de anclaje K<akma>determinado de acuerdo con estrategias de gestión de claves locales en la AAnF 380. La AAnF 380 puede comparar el periodo de tiempo de validez local para la clave de anclaje y el periodo de tiempo de validez para la clave de anclaje recibida desde la AUSF 360 en la etapa 808 y usar el valor más pequeño como periodo de tiempo de validez real para la clave de anclaje. Si el periodo de tiempo de validez para la clave de anclaje no está en el mensaje enviado desde la AUSF 360 a la AAnF 380 en la etapa 808, la AAnF 380 puede usar a continuación el periodo de tiempo de validez local como periodo de tiempo de validez real para la clave de anclaje. Si no se encuentra ningún periodo de tiempo de validez local para la clave de anclaje en la AAnF 380, entonces el periodo de tiempo de validez recibido desde la AUSF 360 en la etapa 808 puede usarse como el periodo de tiempo de validez real para la clave de anclaje. Además, en la etapa 809, la AAnF 380 transmite respuesta a la AUSF 360 tras la transmisión con éxito del mensaje de inserción desde la AUSF 360 a la AAnF 380 en la etapa 808.
El flujo lógico 860 ilustra además una implementación de ejemplo para la generación de clave de anclaje alternativa al flujo lógico 850 anterior. Las etapas 806A, 807A, 808A y 809A del flujo lógico 860 corresponden a las etapas 806, 807, 808 y 809, respectivamente. El flujo lógico 860 es similar al flujo lógico 850 excepto que el identificador K<id>para la clave de anclaje K<akma>se genera por la AAnF 380 en lugar de la AUSF 360 en el lado de red (como se muestra por la etapa 808A realizada por la AAnF 380). En correspondencia, el mensaje de inserción enviado desde la AUSF 360 a la AAnF 380 puede incluir el parámetro RAND, que puede usarse como uno de los componentes para la generación de K<id>por la AAnF 380 en la etapa 808A. Los detalles para las diversas otras etapas en el flujo lógico 860 pueden encontrarse en la descripción anterior para el flujo lógico 850.
Después de una generación con éxito de la clave de anclaje de acuerdo con el flujo lógico 850 u 860 anterior, el UE 310 puede iniciar la comunicación con la AF 390, como se describe con más detalle a continuación. Finalmente, para la Figura 8, como se muestra por la etapa 810, la AMF/SEAF 330 puede enviar un mensaje de respuesta al UE 310 que indica una finalización con éxito de la solicitud de registro/autenticación de la etapa 801 y una finalización con éxito de la generación de clave de anclaje para AAnF suscrita. En algunas otras implementaciones alternativas, la etapa 810 puede realizarse antes de la etapa 806 para indicar una finalización con éxito de la solicitud de registro/autenticación de la etapa 801.
En las implementaciones anteriores para la Figura 8, el servicio de AKMA se ofrece como una opción en lugar de ser obligatorio y se proporciona al UE para suscripción. La información de suscripción puede almacenarse y gestionarse por la UDM/ARPF 370 en el lado de la red doméstica y en el UE 310. Como tal, al UE 310 se le proporcionan opciones de suscribirse al servicio de AKMA o no suscribirse al servicio de AKMA. En el caso de que el UE no se suscriba al servicio de AKMA (cuando, por ejemplo, el UE carece de la capacidad para manejar la generación de claves y el cifrado de datos), el UE puede renunciar al proceso de generación de claves de anclaje de aplicación y puede comunicarse con los servidores de aplicación sin usar ninguna clave de aplicación. En el caso de que el UE se suscriba al AKMA, la información de suscripción puede usarse opcionalmente, como se muestra por el parámetro opcional ID de AAnF y tipo de AKMA en la etapa 806, 806A, 807 y 807A, para la generación de la clave de anclaje de AKMA y su identificador.
La clave de anclaje de aplicación K<akma>, una vez generada como se ha descrito anteriormente en la Figura 8, puede usarse a continuación como una base para la generación de clave de aplicación para comunicación cifrada entre el UE 310 y una aplicación de servicio a la que el UE 310 se ha suscrito al servicio de AKMA. Como se ha ilustrado anteriormente con respecto a la Figura 8, pueden usarse parámetros tales como el número aleatorio RAND en el vector de autenticación generado por la UDM/ARPF 370 para construir K<id>(véanse, por ejemplo, las etapas 807 y 808 de la Figura 8). El identificador K<id>puede usarse además como índice de búsqueda para identificar la clave de anclaje de AKMA correspondiente durante cada comunicación entre el UE 310 y las aplicaciones de servicio. La transmisión frecuente de estos parámetros, tal como el parámetro RAND a través de la trayectoria de datos fuera del entorno seguro de la red central, puede conducir a una brecha de seguridad o fuga de estos parámetros. Las implementaciones de ejemplo de generación de clave de aplicación para comunicación cifrada con una aplicación de servicio como se ilustra en los flujos lógicos de las Figuras 9-12 y descritas a continuación pueden proporcionar esquemas para reducir el riesgo de seguridad de estos parámetros.
En las Figuras 9-12, después del registro y autenticación principal del UE 310 y la generación de la clave de anclaje de aplicación después, por ejemplo, de las etapas de autenticación y generación de clave de anclaje 801-806 como se ilustra en la Figura 8, el UE 310 puede generar una clave de aplicación inicial y enviar una solicitud de comunicación a la AF asociada con la aplicación de servicio. La AF puede obtener la clave de aplicación inicial desde la AAnF. Mientras tanto, la AAnF puede generar un nuevo número aleatorio (NewRAND) o un nuevo identificador de clave de anclaje y enviar el NewRAND o el nuevo identificador de clave de anclaje al UE 310 a través de la AF. El UE puede generar a continuación una nueva clave de aplicación basándose en el NewRAND o el nuevo identificador de clave de anclaje, y usar la nueva clave de aplicación para solicitar y establecer una sesión de comunicación real con la aplicación de servicio. El NewRAND y el nuevo identificador de clave de anclaje usados para generar la nueva clave de aplicación pueden denominarse como una semilla de clave para la generación de la nueva clave de aplicación.
Como se muestra por 840 en las Figuras 9-12, se supone que el UE 310 se ha suscrito al servicio de AKMA y que la información de suscripción de servicio de AKMA almacenada en el UE 310 puede incluir una o más combinaciones de: un indicador de si el UE se ha suscrito al servicio de AKMA; uno o más identificadores de AAnF; uno o más identificadores de AF; y periodo de tiempo de validez de clave de anclaje de AKMA. Como se indica además por 842, en las Figuras 9-12, la correspondiente información de suscripción de usuario registrada en la UDM/ARPF 370 puede incluir uno o más de: un indicador de si el UE se ha suscrito al servicio de AKMA; uno o más identificadores de AAnF; y el periodo de tiempo de validez de la clave de anclaje de AKMA. El identificador para una AAnF puede proporcionarse en forma de una dirección de red de la AAnF. Como alternativa, el identificador de una AAnF puede proporcionarse en forma de un FQDN de la AAnF. Cada UE puede corresponder a una o más AAnF suscritas. Análogamente, el identificador para una AF puede proporcionarse en forma de la dirección de red de la AF. Como alternativa, el identificador de la AF puede proporcionarse en forma de un FQDN de la AF. Cada UE puede corresponder a una o más AF. En algunas implementaciones, pueden asociarse múltiples AF con una misma AAnF, pero cada AF puede asociarse únicamente con una AAnF.
Volviendo al flujo lógico 900 de la Figura 9 y como se muestra en 901, el UE 310, la AMF/SEAF 330, la AUSF 360 y la UDM/ARPF 370 pueden realizar en primer lugar el registro y la autenticación principales del UE 310 y la generación de la clave de anclaje de AKMA después de las etapas de autenticación y generación de clave de anclaje 801-806 como se ilustra en la Figura 8. Los detalles para la autenticación principal y la generación de clave de anclaje de AKMA se han descrito anteriormente con respecto a la Figura 8. En la etapa 907, el UE 310 y la AUSF 360 generan un identificador inicial para la clave de anclaje de AKMA como, por ejemplo, K<id>=RANd @ID de AAnF, o K<id>= base64encode (RAND)@ID de AAnF. Tras el registro y la autenticación de UE con éxito, en la etapa 908, la AMF/SEAF 330 comunica un mensaje de respuesta al UE 310 para indicar que el registro y la autenticación fueron con éxito. La etapa 908 puede realizarse en otros momentos. Por ejemplo, la etapa 908 puede realizarse antes de la etapa 806 entre el procedimiento 901.
Continuando con la Figura 9, en la etapa 909, el UE 310 puede generar una clave de aplicación inicial Kin-AF= KDF (K<akma>, RAND, ID de AF), donde KDF representa el algoritmo de generación de claves de ejemplo descrito con respecto a la etapa 806 de la Figura 8. En la etapa 910, el UE 310 envía una solicitud de comunicación inicial a la AF 390 asociada con la aplicación de servicio. La solicitud de comunicación inicial, por ejemplo, puede incluir el identificador para la clave de anclaje de AKMA, K<id>. Además, en la etapa 911, la AF 390 recibe la solicitud de comunicación inicial desde el UE 310 y envía una solicitud para la clave de aplicación inicial Kin-AF a la AAnF 380 de acuerdo con el ID de AAnF incluido en K<id>. La solicitud de la clave de aplicación inicial Kin-AF desde la AF 390, por ejemplo, puede incluir K<id>y el identificador para la AF, AF<id>. La AAnF 380 puede consultar la clave de anclaje de AKMA K<akma>de acuerdo con K<id>enviado desde la AF 390 en la etapa 911. Si la AAnF 380 encuentra la clave de anclaje de AKMA K<akma>, el flujo lógico 900 puede continuar a 914. Si la AAnF 380 no encuentra la clave de anclaje de AKMA K<akma>, puede enviar una solicitud de clave de anclaje de AKMA a la AUSF 360 en la etapa 912. Tal solicitud puede incluir K<id>. Tras recibir la solicitud de la etapa 912, la AUSF 360 puede identificar la clave de anclaje de AKMA solicitada K<akma>de acuerdo con K<id>, y responder a la AAnF 380 con la K<akma>y su periodo de tiempo de validez en la etapa 913. En la etapa 914, la AAnF 380 puede almacenar la clave de anclaje K<akma>y su período de tiempo de validez. La AAnF 380 puede identificar además un periodo de tiempo de validez local para la clave de anclaje K<akma>determinado de acuerdo con estrategias de gestión de claves locales en la AAnF 380. La AAnF 380 puede comparar el periodo de tiempo de validez local para la clave de anclaje y el periodo de tiempo de validez para la clave de anclaje recibida desde la AUSF 360 en la etapa 808 y usar el valor más pequeño como periodo de tiempo de validez real para la clave de anclaje. Si el periodo de tiempo de validez para la clave de anclaje no se incluye en el mensaje enviado desde la<AUSF>360<a la AAnF 380 en la etapa 808, la AAnF 380 puede usar a continuación el periodo de tiempo de validez>local como periodo de tiempo de validez real para la clave de anclaje. Si no se encuentra ningún periodo de tiempo de validez local para la clave de anclaje en la AAnF 380, entonces el periodo de tiempo de validez recibido desde la AUSF 360 en la etapa 808 puede usarse como el periodo de tiempo de validez real para la clave de anclaje. Además, en la etapa 914, la AAnF 380 puede generar la Kin-AF basándose en Kin-AF =KDF(K<akma>, RAND, AF<id>). El algoritmo de KDF de cálculo de clave de ejemplo se describió previamente con respecto a la etapa 909 de la Figura 9 y la etapa 806 en la Figura 8.
Continuando con la Figura 9, en la etapa 915, la AAnF 380 puede generar un nuevo número aleatorio indicado como NewRAND. La AAnF 380 puede generar adicionalmente un nuevo identificador para la clave de anclaje de AKMA como KiD-New=NewRAND@ID de AAnF, o KiD-Nuevo=Base64Encode (NewRAND)@ID de AAnF. En la etapa 916, la AAnF 308 envía una respuesta a la solicitud de la Kin-AF inicial en la etapa 911. Una respuesta de este tipo puede incluir la clave de aplicación inicial Kin-AF, el NewRAND, KiD-New, y/o el período de tiempo de validez para KiD-Nuevo. En algunas implementaciones, el período de tiempo de validez para KiD-Nuevo puede no ser más largo que el período de tiempo de validez para la clave de anclaje de AKMA. Si la etapa 917 (véase la descripción a continuación) se realiza antes de la etapa 916, la respuesta en la etapa 916 puede incluir además la nueva K<af>generada en la etapa 917 a continuación.
En la etapa 917, la AAnF 380 genera una nueva clave de aplicación KAF-Nueva como KAF-Nueva=KDF(KAKMA, NewRAND, AF<id>). El algoritmo de KDF es similar a los ya descritos anteriormente. La etapa 917 puede realizarse, como alternativa, antes de la etapa 916. En la etapa 918, la AF 390 puede registrar el par de KAF-Nueva y KiD-Nuevo. La AF 390 puede responder además a la solicitud de la etapa 910 y enviar el mensaje de respuesta al UE 310. Tal mensaje de respuesta puede incluir el nuevo número aleatorio NewRAND y/o el nuevo identificador de clave de anclaje de AKMA KID-Nuevo. El mensaje de respuesta puede incluir además un período de tiempo de validez para KAF-Nueva. En algunas implementaciones, la transmisión de este mensaje de respuesta puede cifrarse usando la Kin-AF. En otras palabras, los diversos componentes transmitidos de la respuesta en la etapa 918 pueden cifrarse usando Kin-AF. Posteriormente, la AF 390 puede retirar la Kin-AF inicial.
En la etapa 919, el UE 310 recibe la respuesta de la etapa 918. Si la respuesta se cifra con Kin-AF, el UE 310 puede descifrar la respuesta usando Kin-AF que deriva en la etapa 909. Si la respuesta incluye NewRAND, el UE 310 puede obtener el componente NewRAND incluido en la respuesta después del descifrado. El UE 310 puede generar a continuación el nuevo identificador para el anclaje de AKMA ken KID-Nuevo como Ken-AF=NewRAND@ID de AAnF. Si el KID-Nuevo cifrado ya está incluido en la respuesta de la etapa 918, el UE 310 puede descifrar la respuesta para obtener el KID-Nuevo directamente.
En la etapa 920, el UE 310 puede generar la nueva clave de aplicación KAF-Nueva como KAF-Nueva = KDF (K<akma>, newRAND, ID de AF), donde KDF es un algoritmo de generación de claves descrito anteriormente con respecto a la etapa 806 de la Figura 8. El UE 310 puede almacenar el nuevo ID de clave de anclaje de AKMA KID-Nuevo y la nueva clave de aplicación KAF-Nueva. Si el período de tiempo de validez para la nueva clave de aplicación KAF-Nueva se incluyó en la respuesta de la etapa 918, el UE 310 también puede descifrar la respuesta para obtener el período de tiempo de validez para KAF-Nueva y almacenarlo localmente.
En la etapa 921, el UE 310 puede iniciar otra solicitud de comunicación a la AF 390. El mensaje de solicitud puede incluir el nuevo identificador para la clave de anclaje de AKMA KID-Nueva, y el mensaje de solicitud puede cifrarse además por el UE 310 usando la nueva clave de aplicación KAF-Nueva. En la etapa 922, la AF 390 recibe la solicitud de comunicación de la etapa 921, y puede determinar en primer lugar si la nueva clave de aplicación KAF-Nueva existen localmente. Si KAF-Nueva existe localmente, entonces la AF 290 puede usar tal KAF-New para descifrar la solicitud de comunicación desde el UE 310 en la etapa 921. Si la AF 390 no puede encontrar la KAF-Nueva, a continuación, puede enviar un mensaje de solicitud a la AAnF 380 para la nueva clave de aplicación KAF-Nueva. El mensaje de solicitud puede incluir el nuevo identificador para la clave de anclaje de AKMA KID-Nueva y AF<id>. En la etapa 923, la AAnF 380 recibe el mensaje de solicitud desde la etapa 922 y consulta la nueva clave de aplicación KAF-Nueva basándose en KiD-Nuevo y devuelve la KAF-Nueva a la AF 390 en respuesta. Si la etapa 916 no incluyera ningún periodo de tiempo de validez para KAF-Nueva, tal período de tiempo de validez puede incluirse en el mensaje de respuesta a la AF 390 en la etapa 923. Finalmente, en la etapa 924, la AF 390 puede usar la KAF-Nueva para descifrar la solicitud de comunicación enviada desde el UE 310 en la etapa 921, y responder al UE 310 para establecer comunicación con el UE 310. Tal respuesta puede incluir un período de tiempo de validez para la nueva clave de aplicación KAF-Nueva.
La Figura 10 muestra el flujo lógico 1000 como una implementación alternativa a la Figura 9. El flujo lógico 1000 es similar al flujo lógico 900 de la Figura 9 (como se muestra por el etiquetado idéntico en las Figuras 9 y 10), excepto que la etapa 907 de la Figura 9 se retira de la Figura 10 (como se muestra por 1002). Como tal, la AUSF 360 en la Figura 10 puede no necesitar generar el identificador inicial para la clave de anclaje de AKMA, K<id>. Por consiguiente, en la etapa 1012 en la Figura 10 (mostrada como una etapa subrayada) se reemplaza la Etapa 912 de la Figura 9. Específicamente, debido a que no se genera K<id>inicial en la AUSF 360, la solicitud desde la AAnF 380 a la AUSF 360 para la información de clave de anclaje de AKMA puede consultarse bajo RAND en lugar de K<id>. La AAnF 380 puede derivar el parámetro RAND desde el K<id>que recibe desde la AF 390 en la etapa 911 de la Figura 10.
La Figura 11 muestra otro flujo lógico 1100 alternativo a los flujos lógicos 900 y 1000 de las Figuras 9 y 10. El flujo lógico 1100 es similar al flujo lógico 900 de la Figura 9 (como se muestra por el etiquetado idéntico en las Figuras 9 y 10) con diferencias con respecto a la Figura 9 anotadas en la Figura 11. Por ejemplo, las etapas 1102 y 1104 (las etapas subrayadas en la Figura 11) se añaden en el flujo lógico 1100. En particular, en la etapa 1102, la clave de anclaje de AKMA se inserta de manera proactiva desde la AUSF 360 a la AAnF 380 una vez que se genera por la AUSF 360 en lugar de ser solicitada pasivamente por la AAnF 380 desde la AUSF 360, como se implementó en las etapas 912 y 913 de la Figura 9 (que se retiran de la implementación de la Figura 11, como se muestra por 1106). En la etapa 1104, la AAnF 380 proporciona una respuesta a la AUSF 360 si la clave de anclaje de AKMA se recibe con éxito por la AAnF 380. Además, la etapa 914 de la Figura 11, en comparación con la misma etapa en la Figura 10, puede modificarse como se indica en la Figura 11 por la razón de que la AAnF 380 ya tendría la clave de anclaje de AKMA como resultado de la inserción proactiva desde la AUSF 360 en la etapa 1102.
La Figura 12 muestra un flujo lógico 1200 alternativo más a los flujos lógicos 900, 1000 y 1100 de las Figuras 9, 10 y 11. El flujo lógico 1200 sigue las implementaciones tanto del flujo lógico 1000 de la Figura 10 como del flujo lógico 1100 de la Figura 11 en que las etapas 907, 912 y 913 de la Figura 9 se retiran, como se muestra por 1201 y 1206, las etapas 914 se modifican de la Figura 9, como se indica en la Figura 11, y se añaden las etapas de inserción 1202 y 1204. Como tal, en la implementación de la Figura 12, la clave de anclaje de AKMA se inserta de manera proactiva desde la AUSF 360 a la AAnF 380, tal como la implementación en la Figura 11. Además, no hay necesidad de generar ningún K<id>inicialen la AUSF 360 porque no es necesario dirigir ninguna solicitud posteriormente a la AUSF 360 para consultar la clave de anclaje de AKMA como resultado de la inserción de información en la etapa 1202 y 1204.
En las implementaciones ilustradas en las Figuras 9-12, se genera un nuevo número aleatorio por la AAnF 380 y se usa para la generación de una nueva clave de aplicación y un nuevo identificador para la clave de anclaje de AKMA. El RAND original generado como parte del vector de autenticación por la<u>D<m>/ARPF 370 únicamente puede transmitirse entre las diversas funciones de red de una manera limitada y, por lo tanto, puede estar menos expuesto a brechas de seguridad. El nuevo número aleatorio puede generarse para cada comunicación entre el UE 310 y la AF 390 y, por lo tanto, la brecha de seguridad de un nuevo número aleatorio puede no plantear un riesgo para una sesión de comunicación separada. Por lo tanto, la seguridad de la comunicación se mejora en las implementaciones de las Figuras 9-12.
Como se ha descrito anteriormente, para mejorar además la seguridad de la comunicación, las diversas claves implicadas en la comunicación cifrada entre el Ue 310 y una aplicación de servicio pueden asociarse con periodos de tiempo de validez (o tiempo de expiración). En otras palabras, estas claves únicamente son válidas dentro de tales periodos de tiempo de validez. En particular, cuando estas claves se vuelven no válidas, la comunicación entre el UE 310 y las aplicaciones de servicio puede no estar protegida por cifrado. Como tal, estas claves pueden necesitar actualizarse cuando se vuelven no válidas. Las Figuras 13-14 descritas a continuación muestran diversas implementaciones para actualizar las diversas claves (incluyendo, por ejemplo, la clave de anclaje de AKMA y la clave de aplicación) cuando son no válidas o se vuelven no válidas.
La Figura 13 ilustra una implementación iniciada por UE 1300 para actualizar claves no válidas. El procedimiento de autenticación de usuario 402 y las etapas 410, 412, 420, 422 son idénticas a las correspondientes etapas descritas con respecto a la Figura 4. La descripción de la Figura 4 anterior se aplica a estas etapas en la Figura 13. Después de estas etapas, puede generarse la clave de anclaje de AKMA. En la etapa 1301, el UE 310 determina que la clave de anclaje de AKMA o la clave de aplicación de AKMA es o se vuelve no válida. El UE 310 a continuación borra la clave de anclaje de AKMA o clave de aplicación no válida, los periodos de tiempo de validez correspondientes y el identificador para la clave de anclaje de AKMA no válida.
En la etapa 1302, cuando el UE está en un estado en reposo, el UE puede iniciar un mensaje de solicitud de registro a la red inalámbrica (a funciones de red tales como AMF/SEAF 330 o AUSF 360). Tal mensaje de solicitud de registro puede incluir el SUCI, o 5G-GUTI y un ngKSI (índice de contexto de seguridad) de, por ejemplo, 7, que indica que el contexto de seguridad de UE no es válido. Cuando el UE 310 está en un estado activo manejando servicios que no son de emergencia o servicios que no son de alta prioridad, y el UE 310 entra en un estado en reposo, el UE puede iniciar la solicitud de registro a la red. Cuando el UE 310 está en un estado activo manejando servicios de emergencia o servicios de alta prioridad, el UE puede esperar hasta la finalización de los servicios de emergencia o de alta prioridad y a continuación entrar en el estado en reposo e iniciar la solicitud de registro a la red. En algunas otras implementaciones, cuando el UE está en un estado activo, el UE puede esperar a que se completen los servicios activos y a continuación iniciar la solicitud de registro a la red independientemente de la emergencia o prioridad de los servicios activos.
En la etapa 1303, el UE puede pasar a través de autenticación y registro principal con la red y a continuación generar nueva clave de anclaje de AKMA y/o clave de aplicación, y determinar periodos de tiempo de validez e identificadores para estas nuevas claves. El UE y la red registran ambos estas claves, periodos de tiempo de validez e identificadores.
La Figura 14 muestra una actualización iniciada por la red de claves de AKMA no válidas. En la Figura 14, el UE puede haberse suscrito al servicio de AKMA. En 840 de la Figura 14, la información de suscripción de servicio de AKMA correspondiente al UE puede registrarse en el UE. Tal información de suscripción puede incluir una o más combinaciones de: un indicador de si el UE se ha suscrito al servicio de AKMA; uno o más identificadores de AAnF; uno o más identificadores de AF; y periodo de tiempo de validez de clave de anclaje de AKMA. En 842 de la Figura 14, la correspondiente información de suscripción de usuario registrada en la UDM/ARPF 370 puede incluir uno o más de: un indicador de si el UE se ha suscrito al servicio de AKMA; uno o más identificadores de AAnF; y el periodo de tiempo de validez de la clave de anclaje de AKMA. Durante el procedimiento de registro y autenticación de UE, la UDM/ARPF 370 puede transmitir la información de suscripción de servicio de AKMA a la AUSF 360.
En la etapa 1401 de la Figura 14, el UE y la red completan el procedimiento de autenticación principal y generan la clave de anclaje de AKMA K<akma>y el correspondiente identificador K<id>, la clave de aplicación de AKMA K<af>y periodos de tiempo de validez para estas claves. Estas claves pueden no ser válidas por diversas razones. En la Figura 14, el flujo lógico 1460, 1470 y 1480 ilustra actualizaciones de clave en diversas situaciones de ejemplo en las que al menos una de estas claves se vuelve no válida.
Para el flujo lógico 1460 de ejemplo, la clave de anclaje de AKMA puede no ser válida. En la etapa 1402, el UE 310 puede iniciar una solicitud de comunicación a la AF 390. La solicitud de comunicación puede incluir el identificador para la clave de anclaje de AKMA, K<id>. En la etapa 1403, la AF 390 puede enviar un mensaje de solicitud de clave de aplicación inicial que incluye K<id>y AF<id>a la AAnF 380 de acuerdo con el identificador de AAnF en el K<id>. En la etapa<1404, la AAnF>380<puede consultar la clave de anclaje de AKMA Kakma de acuerdo con Kid. Si la AAnF 380 no>encuentra la clave de anclaje de AKMA K<akma>, puede enviar un mensaje de solicitud de clave de anclaje de AKMA a la AUSF 360. El mensaje de solicitud puede incluir K<id>. En la etapa 1405, la AUSF 360 puede consultar una clave de anclaje de AKMA válida de acuerdo con K<id>y es posible que no pueda encontrar una clave de anclaje de AKMA válida. La AUSF 360 puede responder a continuación con un mensaje de fallo a la AAnF 380 que indica que no se encontró ninguna clave de anclaje de AKMA válida. En la etapa 1406, la AAnF 380 responde a la AF 390 con un mensaje de fallo que indica que no se encontró ninguna clave de anclaje de AKMA válida. En la etapa 1407, la AF 390 puede responder con un mensaje de fallo al UE 310 que indica que no se encontró ninguna clave de anclaje de AKMA válida. En la etapa 1408, el UE 310 inicia otra solicitud de registro a la red. Tal mensaje de solicitud de registro puede incluir el SUCI del UE, o 5G-GUTI del UE y un ngKSI (índice de contexto de seguridad) de, por ejemplo, 7, que indica que el contexto de seguridad del UE no es válido. En la etapa 1409, después de que el UE 310 y la red completen la otra autenticación y registro principales, puede generarse una nueva clave de anclaje de AKMA y/o clave de aplicación de AKMA, sus identificadores y/o sus periodos de tiempo de validez. El UE 310 y la red pueden guardar estas claves, periodos de tiempo de validez e identificadores.
Para el flujo lógico 1470 de ejemplo, la clave de aplicación puede haber expirado. En la etapa 1410, el UE 310 puede iniciar una solicitud de comunicación a la AF 390. La solicitud de comunicación puede incluir el identificador para la clave de anclaje de AKMA, K<id>. En la etapa 1411, la AF 390 puede determinar que la clave de aplicación ha expirado. En la etapa 1412, la AF 390 puede responder con un mensaje de fallo al UE 310 que indica que la clave de aplicación ha expirado. En la etapa 1413, el UE 310 inicia otra solicitud de registro a la red. Tal mensaje de solicitud de registro puede incluir el SUCI del UE, o 5G-GUTI del UE y un ngKSI (índice de contexto de seguridad) de, por ejemplo, 7, que indica que el contexto de seguridad del UE no es válido. En la etapa 1414, después de que el UE 310 y la red completen otra autenticación y registro principales, puede generarse una nueva clave de anclaje de AKMA y/o clave de aplicación de AKMA, sus identificadores y/o sus periodos de tiempo de validez. El UE 310 y la red pueden guardar estas claves, periodos de tiempo de validez e identificadores.
Para el flujo lógico 1480 de ejemplo, la clave de anclaje de AKMA puede haber expirado. En la etapa 1415, el UE 310 puede iniciar una solicitud de comunicación a la AF 390. La solicitud de comunicación puede incluir el identificador para la clave de anclaje de AKMA, K<id>. En la etapa 1416, la AF 390 puede enviar un mensaje de solicitud de clave de aplicación que incluye K<id>y AF<id>a la AAnF 380 de acuerdo con el identificador de AAnF en el K<id>. En la etapa 1417, la AAnF 380 puede determinar que la clave de anclaje de AKMA K<akma>ha expirado. En la etapa 1418, la AAnF 380 responde a la AF 390 con un mensaje de fallo que indica que la clave de anclaje de AKMA ha expirado. En la etapa 1419, la AF 390 puede responder con un mensaje de fallo al UE 310 que indica que la clave de anclaje de AKMA ha expirado. En la etapa 1420, el UE 310 inicia otra solicitud de registro a la red. Tal mensaje de solicitud de registro puede incluir el SUCl del UE, o 5G-GUTI del UE y un ngKSI (índice de contexto de seguridad) de, por ejemplo, 7, que indica que el contexto de seguridad del UE no es válido. En la etapa 1421, después de que el UE 310 y la red completen otra autenticación y registro principales, puede generarse una nueva clave de anclaje de AKMA y/o clave de aplicación de AKMA, sus identificadores y/o sus periodos de tiempo de validez. El UE 310 y la red pueden guardar estas claves, periodos de tiempo de validez e identificadores.
Las implementaciones descritas anteriormente para las Figuras 1-14 proporcionan por lo tanto una arquitectura para que una red de comunicación ofrezca un servicio de clave de aplicación al que pueden suscribirse dispositivos terminales. Estas implementaciones proporcionan además diversos esquemas para generación, gestión y actualización de diversos niveles jerárquicos de claves para posibilitar comunicación cifrada entre los dispositivos terminales y aplicaciones de servicio a través de la red de comunicación. Las implementaciones divulgadas facilitan la flexibilidad en la comunicación con las aplicaciones de servicio y reducen el riesgo de brechas de seguridad.
Los dibujos adjuntos y la descripción anterior proporcionan realizaciones e implementaciones de ejemplo específicas. Sin embargo, la materia objeto descrita puede incorporarse en una diversidad de formas diferentes y, por lo tanto, se pretende que la materia objeto cubierta o reivindicada se interprete como no limitada a ninguna realización de ejemplo expuesta en el presente documento. Se pretende un alcance razonablemente amplio para la materia objeto reivindicada o cubierta. Entre otras cosas, por ejemplo, la materia objeto puede incorporarse como métodos, dispositivos, componentes, sistemas o medios no transitorios legibles por ordenador para almacenar códigos informáticos. Por consiguiente, por ejemplo, las realizaciones pueden tomar la forma de hardware, software, firmware, medios de almacenamiento o cualquier combinación de los mismos. Por ejemplo, las realizaciones de método descritas anteriormente pueden implementarse mediante componentes, dispositivos o sistemas que incluyen memoria y procesadores que ejecutan códigos informáticos almacenados en la memoria.
A lo largo de toda la memoria descriptiva y las reivindicaciones, los términos pueden tener significados matizados sugeridos o implicados en el contexto más allá de un significado expuesto explícitamente. Análogamente, la expresión "en una realización/implementación" como se usa en el presente documento no se refiere necesariamente a la misma realización y la expresión "en otra realización/implementación" como se usa en el presente documento no se refiere necesariamente a una realización diferente. Se pretende, por ejemplo, que la materia objeto reivindicada incluya combinaciones de realizaciones de ejemplo en su totalidad o en parte.
En general, la terminología puede entenderse, al menos en parte, a partir de su uso en el contexto. Por ejemplo, términos tales como "y", "o" o "y/o", como se usan en el presente documento, pueden incluir una diversidad de significados que pueden depender, al menos en parte, del contexto en el que se usan tales términos. Típicamente, "o", si se usa para asociar una lista, tal como A, B o C, pretende significar A, B y C, usado en el presente caso en el sentido inclusivo, así como A, B o C, usado en el presente caso en el sentido exclusivo. Además, la expresión "uno o más" como se usa en el presente documento, dependiendo al menos en parte del contexto, puede usarse para describir cualquier rasgo, estructura o característica en un sentido en singular o puede usarse para describir combinaciones de rasgos, estructuras o características en un sentido en plural. De forma similar, se puede entender que los términos tales como "un", "una" o "el/la" transmiten un uso singular o transmiten un uso plural, dependiendo al menos en parte del contexto. Además, se puede entender que la expresión "basándose en" no está necesariamente destinada a transmitir un conjunto exclusivo de factores y puede, en cambio, prever la existencia de factores adicionales, no necesariamente descritos de forma expresa, dependiendo de nuevo, al menos en parte, del contexto.
La referencia a lo largo de toda esta memoria descriptiva a características, ventajas o lenguaje similar no implica que todas las características y ventajas que pueden obtenerse con la presente solución debieran incluirse o se incluyan en ninguna implementación individual de la misma. Más bien, se entiende que un lenguaje que hace referencia a las características y ventajas significa que un rasgo, ventaja o característica específico descrito en relación con una realización se incluye en al menos una realización de la presente solución. Por tanto, los análisis de las características y ventajas, y lenguaje similar, a lo largo de toda la memoria descriptiva, pueden referirse, aunque no necesariamente, a la misma realización.
Además, los rasgos, ventajas y características descritos de la presente solución pueden combinarse de cualquier forma adecuada en una o más realizaciones. Un experto en la materia pertinente reconocerá, en vista de la descripción en el presente documento, que la presente solución puede ponerse en práctica sin una o más de las características o ventajas específicas de una realización particular. En otros casos, pueden reconocerse características y ventajas adicionales en ciertas realizaciones que pueden no estar presentes en todas las realizaciones de la presente solución.

Claims (12)

REIVINDICACIONES
1. Un método para generación de una clave de anclaje en un dispositivo de red en una red de comunicación, realizándose el método por el dispositivo de red y que comprende:
obtener un paquete de datos de suscripción asociado con una suscripción de seguridad de aplicación de un módulo de red de usuario a un servicio de gestión de claves de anclaje, proporcionándose el servicio de gestión de claves de anclaje como un servicio al que está suscrito un equipo de usuario asociado con el módulo de red de usuario; extraer del paquete de datos de suscripción un conjunto de datos de suscripción, en donde el conjunto de datos de suscripción comprende un identificador de un nodo de red de gestión de clave de aplicación en la red de comunicación que está asociado con una aplicación de servicio;
enviar un mensaje de solicitud de autenticación que incluye un identificador permanente de suscripción, SUPI, del equipo de usuario asociado con el módulo de red de usuario;
generar una clave de autenticación base tras la finalización con éxito de un proceso de autenticación para registrar el módulo de red de usuario con la red de comunicación;
generar la clave de anclaje basándose en la clave de autenticación base y el SUPI:
generar un identificador único para la clave de anclaje basándose en el identificador del nodo de red de gestión de clave de aplicación; y
en donde la clave de anclaje se usa para que el equipo de usuario asociado con el módulo de red de usuario y la aplicación de servicio generen una clave de cifrado de aplicación para comunicación cifrada entre los mismos.
2. El método de la reivindicación 1, en donde el dispositivo de red comprende el equipo de usuario, y en donde el conjunto de datos de suscripción se almacena en el equipo de usuario durante la suscripción del módulo de red de usuario al servicio de gestión de claves de anclaje.
3. El método de la reivindicación 2, en donde generar la clave de anclaje se basa además en al menos uno de un tipo del módulo de red de usuario, y un conjunto de datos de autenticación generado durante el proceso de autenticación para registrar el equipo de usuario con la red de comunicación.
4. El método de la reivindicación 3, en donde:
el conjunto de datos de autenticación comprende un número aleatorio generado en el proceso de autenticación para registrar el módulo de red de usuario con la red de comunicación; y
generar la clave de anclaje comprende generar la clave de anclaje basándose en la clave de autenticación base, el SUPI y el número aleatorio.
5. El método de la reivindicación 4, en donde generar el identificador único para la clave de anclaje comprende generar el identificador único para la clave de anclaje basándose en el número aleatorio y el identificador del nodo de red de gestión de clave de aplicación.
6. El método de la reivindicación 1, en donde el dispositivo de red comprende un nodo de red de autenticación en la red de comunicación, y en donde:
el paquete de datos de suscripción se obtiene desde un nodo de red de gestión de datos de usuario de la red de comunicación separado del nodo de red de autenticación; y
el nodo de red de gestión de datos de usuario está configurado para almacenar información de suscripción de usuario.
7. El método de la reivindicación 6, en donde generar la clave de anclaje se basa además en al menos uno de un tipo del módulo de red de usuario, y un conjunto de datos de autenticación generado durante el proceso de autenticación para registrar el equipo de usuario con la red de comunicación.
8. El método de la reivindicación 7, en donde el conjunto de datos de autenticación se genera por el nodo de red de gestión de datos de usuario, y en donde:
el conjunto de datos de autenticación comprende un número aleatorio generado por el nodo de red de gestión de datos de usuario en el proceso de autenticación para registrar el módulo de red de usuario con la red de comunicación; y
generar la clave de anclaje comprende generar la clave de anclaje basándose en la clave de autenticación base, el SUPI y el número aleatorio.
9. El método de la reivindicación 8, en donde el identificador único para la clave de anclaje comprende el número aleatorio y el identificador del nodo de red de gestión de clave de aplicación, y el método comprende además transmitir la clave de anclaje y el número aleatorio al nodo de red de gestión de clave de aplicación; y en donde
generar el identificador único para la clave de anclaje comprende recibir el identificador único para la clave de anclaje generada por el nodo de red de gestión de clave de aplicación tras recibir el número aleatorio desde el nodo de red de autenticación.
10. El método de la reivindicación 7, en donde generar el identificador único para la clave de anclaje comprende generar por el nodo de red de autenticación el identificador único para la clave de anclaje, y el método comprende además transmitir la clave de anclaje y el identificador único para la clave de anclaje a un nodo de red de gestión de clave de aplicación.
11. El método de la reivindicación 1, en donde generar la clave de anclaje se basa además en procesar la clave de autenticación base y el conjunto de datos de suscripción usando un algoritmo de función de troceo seguro.
12. Un dispositivo que comprende uno o más procesadores y una o más memorias, en donde el uno o más procesadores están configurados para leer código informático desde la una o más memorias para implementar el método de la reivindicación 1.
ES20887115T 2020-01-16 2020-01-16 Method, device, and system for anchor key generation and management in a communication network for encrypted communication with service applications Active ES3037810T3 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/072444 WO2021093162A1 (en) 2020-01-16 2020-01-16 Method, device, and system for anchor key generation and management in a communication network for encrypted communication with service applications

Publications (1)

Publication Number Publication Date
ES3037810T3 true ES3037810T3 (en) 2025-10-07

Family

ID=75911692

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20887115T Active ES3037810T3 (en) 2020-01-16 2020-01-16 Method, device, and system for anchor key generation and management in a communication network for encrypted communication with service applications

Country Status (8)

Country Link
US (1) US12328305B2 (es)
EP (2) EP4622314A3 (es)
JP (1) JP7453388B2 (es)
KR (1) KR102797871B1 (es)
CN (2) CN116546491A (es)
CA (1) CA3159134A1 (es)
ES (1) ES3037810T3 (es)
WO (1) WO2021093162A1 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113225176B (zh) * 2020-02-04 2022-09-16 华为技术有限公司 密钥获取方法及装置
WO2021167399A1 (en) * 2020-02-19 2021-08-26 Samsung Electronics Co., Ltd. Apparatus and method of generating application specific keys using key derived from network access authentication
EP4066436A4 (en) * 2020-03-31 2022-12-07 ZTE Corporation Parameters for application communication establishment
US12375910B2 (en) * 2020-12-29 2025-07-29 Samsung Electronics Co., Ltd. Method and system of enabling AKMA service in roaming scenario
US20240080674A1 (en) * 2021-01-15 2024-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and system to support authentication and key management for applications (akma) using an allowability indication
WO2023282656A1 (en) * 2021-07-08 2023-01-12 Samsung Electronics Co., Ltd. System and method for key generation in authentication and key management for applications (akma)
CN115706992A (zh) * 2021-08-09 2023-02-17 中国移动通信有限公司研究院 安全通道建立方法、装置、相关设备及存储介质
CN115706663A (zh) * 2021-08-09 2023-02-17 中国移动通信有限公司研究院 更新方法、网络侧设备、终端和计算机可读存储介质
US12143812B2 (en) * 2021-10-29 2024-11-12 Lenovo (Singapore) Pte. Ltd. Enabling roaming with authentication and key management for applications
CN118975187A (zh) * 2022-03-22 2024-11-15 Oppo广东移动通信有限公司 生成密钥的方法及装置
WO2025065974A1 (en) * 2023-09-29 2025-04-03 Huawei Technologies Co., Ltd. Method and apparatus for communication
WO2025235891A1 (en) * 2024-05-09 2025-11-13 Interdigital Patent Holdings, Inc. Application function based user specific authentication and activation

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020062451A1 (en) 1998-09-01 2002-05-23 Scheidt Edward M. System and method of providing communication security
JP4654498B2 (ja) * 2000-08-31 2011-03-23 ソニー株式会社 個人認証システム、個人認証方法、および情報処理装置、並びにプログラム提供媒体
TW200423675A (en) 2002-11-08 2004-11-01 Gen Instrument Corp Certificate renewal in a certificate authority infrastructure
JP4569464B2 (ja) * 2005-12-20 2010-10-27 沖電気工業株式会社 マルチホップネットワークにおける鍵更新システム，鍵管理装置，通信端末および鍵情報構築方法
CN101267309B (zh) 2008-03-29 2012-11-21 华为技术有限公司 一种网络授权认证方法、装置和系统
US8397062B2 (en) 2009-04-21 2013-03-12 University Of Maryland, College Park Method and system for source authentication in group communications
CN101998332B (zh) 2009-08-17 2013-08-07 中兴通讯股份有限公司 一种寻呼紧急业务用户的方法和系统
CN101848425A (zh) 2010-04-23 2010-09-29 深圳市戴文科技有限公司 Ptt数据处理方法、终端、ptt服务器及ptt系统
KR101257761B1 (ko) * 2011-03-21 2013-04-24 주식회사 잉카인터넷 이미지 기반 인증시스템 및 방법
EP2689599B1 (en) 2011-03-23 2017-05-03 InterDigital Patent Holdings, Inc. User equipment and method for securing network communications
US8713314B2 (en) 2011-08-30 2014-04-29 Comcast Cable Communications, Llc Reoccuring keying system
PL3018850T3 (pl) 2013-01-30 2017-10-31 Ericsson Telefon Ab L M Generowanie klucza bezpieczeństwa dla połączeń podwójnych
KR102039908B1 (ko) 2013-04-01 2019-11-04 삼성전자주식회사 단말간 통신을 위한 상태 천이 방법 및 장치
GB2518254B (en) 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
KR20150053663A (ko) * 2013-11-08 2015-05-18 김주한 이동통신단말기를 이용한 다채널 인증과 금융 이체 방법 및 시스템
US9918225B2 (en) * 2014-11-03 2018-03-13 Qualcomm Incorporated Apparatuses and methods for wireless communication
CN104917618B (zh) * 2015-06-02 2018-08-14 北京航空航天大学 基于层次身份基的认证密钥协商方法和系统
EP3338472B1 (en) 2015-08-17 2020-07-15 Telefonaktiebolaget LM Ericsson (PUBL) Method and apparatus for direct communication key establishment
EP3133766B8 (en) * 2015-08-19 2020-08-12 Rohde & Schwarz SIT GmbH Communication device and method for performing encrypted communication in multipoint networks
WO2017035268A1 (en) 2015-08-24 2017-03-02 Ricardo Richard Frederick Data obfuscation method and service using unique seeds
DE102015225270A1 (de) 2015-12-15 2017-06-22 Siemens Aktiengesellschaft Verfahren und Sicherheitsmodul zum Bereitstellen einer Sicherheitsfunktion für ein Gerät
RU2702506C1 (ru) 2016-01-25 2019-10-08 Телефонактиеболагет Лм Эрикссон (Пабл) Управление ключами
TWI815443B (zh) 2016-12-30 2023-09-11 美商英特爾公司 用於物聯網之非暫時性機器可讀取媒體
KR101877333B1 (ko) * 2017-01-02 2018-08-09 주식회사 코인플러그 블록체인 기반의 모바일 아이디를 이용하여 사용자를 비대면 인증하는 방법, 단말 및 이를 이용한 서버
JP6635315B2 (ja) * 2017-01-20 2020-01-22 日本電信電話株式会社 Ｉｄベース認証鍵交換システム、端末、ｉｄベース認証鍵交換方法、プログラム
US10841084B2 (en) * 2017-02-03 2020-11-17 Qualcomm Incorporated Session management authorization token
EP3580889B1 (en) 2017-02-08 2020-12-16 Nokia Solutions and Networks Oy Enhancing integrity of data center specific information
JPWO2018169071A1 (ja) * 2017-03-17 2020-04-16 日本電気株式会社 認証装置、ネットワーク装置、及び認証方法
KR20180106998A (ko) 2017-03-21 2018-10-01 한국전자통신연구원 등록 지역을 최적화하는 통신 시스템 및 상기 통신 시스템에서의 등록 방법
WO2018194971A1 (en) 2017-04-17 2018-10-25 Intel Corporation Group based context and security for massive internet of things devices
CN109874139B (zh) 2017-05-05 2020-02-07 华为技术有限公司 锚密钥生成方法、设备以及系统
US10841302B2 (en) 2017-05-24 2020-11-17 Lg Electronics Inc. Method and apparatus for authenticating UE between heterogeneous networks in wireless communication system
DK3890382T3 (da) 2017-07-25 2022-10-03 Ericsson Telefon Ab L M Abonnementskjult identifikator
CN113473646B (zh) 2017-11-21 2022-04-12 华为技术有限公司 一种通信方法及装置
EP3506552A1 (en) 2017-12-29 2019-07-03 Nagravision S.A. Secure installation of application keys
WO2019213946A1 (en) 2018-05-11 2019-11-14 Apple Inc. Subscriber identity privacy protection against fake base stations
CN109194473B (zh) 2018-09-25 2021-06-11 北京金山安全软件有限公司 一种数据传输方法、系统、装置、终端及存储介质
EP3909275A1 (en) 2019-01-11 2021-11-17 NEC Corporation A method and a device for enabling key re-usage in a communication network
EP3915288A1 (en) 2019-01-21 2021-12-01 Telefonaktiebolaget LM Ericsson (publ) Key revocation for the authentication and key management for applications feature in 5g
CN113574829B (zh) 2019-03-12 2025-01-10 诺基亚技术有限公司 与第三方应用共享通信网络锚定加密密钥
CN111865569B (zh) 2019-04-28 2022-08-26 华为技术有限公司 一种密钥协商方法及装置
US11297680B2 (en) 2019-06-17 2022-04-05 Samsung Electronics Co., Ltd. Method and apparatus for handling emergency services in a wireless network
EP4016950A4 (en) 2019-08-18 2022-08-10 Huawei Technologies Co., Ltd. COMMUNICATION METHOD, DEVICE AND SYSTEM
CN110635905B (zh) 2019-09-30 2022-04-08 重庆小雨点小额贷款有限公司 一种密钥管理方法、相关设备及计算机可读存储介质
US11456867B2 (en) 2019-10-25 2022-09-27 International Business Machines Corporation Trust-anchoring of cryptographic objects
WO2021115614A1 (en) * 2019-12-13 2021-06-17 Huawei Technologies Duesseldorf Gmbh Network node and method for anonymization of user sensitive data in a communication network

Also Published As

Publication number Publication date
EP4622314A2 (en) 2025-09-24
EP4622314A3 (en) 2025-11-26
WO2021093162A1 (en) 2021-05-20
JP7453388B2 (ja) 2024-03-19
EP4091351A1 (en) 2022-11-23
US20220368684A1 (en) 2022-11-17
CN116546491A (zh) 2023-08-04
CN115004742A (zh) 2022-09-02
EP4091351A4 (en) 2023-10-04
CA3159134A1 (en) 2021-05-20
KR20220128993A (ko) 2022-09-22
US12328305B2 (en) 2025-06-10
KR102797871B1 (ko) 2025-04-17
JP2023514040A (ja) 2023-04-05
EP4091351B1 (en) 2025-07-16

Similar Documents

Publication Publication Date Title
ES3037810T3 (en) Method, device, and system for anchor key generation and management in a communication network for encrypted communication with service applications
US20220345307A1 (en) Method, Device, and System for Updating Anchor Key in a Communication Network for Encrypted Communication with Service Applications
JP7326521B2 (ja) 加入秘匿化識別子
US12316757B2 (en) Method, device, and system for application key generation and management in a communication network for encrypted communication with service applications
US11751051B2 (en) Authentication method based on GBA, and device thereof
US10931644B2 (en) Methods, network nodes, mobile entity, computer programs and computer program products for protecting privacy of a mobile entity
ES2896733T3 (es) Funcionamiento relacionado con un equipo de usuario que utiliza un identificador secreto
JP7762156B2 (ja) サブスクリプションデータ更新方法ならびに装置、ノードおよび記憶媒体
KR102783803B1 (ko) 등록 절차를 위한 무선 통신 방법
US11330428B2 (en) Privacy key in a wireless communication system
US12363076B2 (en) Network exposure function (NEF) for SUCI-based UE-initiated service authorization
RU2801267C1 (ru) Способ, устройство и система для обновления привязочного ключа в сети связи для зашифрованной связи с приложениями предоставления услуг