ES2573257T3 - Métodos y aparato para implementar seguridad de estrato de no acceso (NAS) en un dispositivo inalámbrico de la Evolución a largo plazo - Google Patents

Métodos y aparato para implementar seguridad de estrato de no acceso (NAS) en un dispositivo inalámbrico de la Evolución a largo plazo Download PDF

Info

Publication number
ES2573257T3
ES2573257T3 ES08796196.7T ES08796196T ES2573257T3 ES 2573257 T3 ES2573257 T3 ES 2573257T3 ES 08796196 T ES08796196 T ES 08796196T ES 2573257 T3 ES2573257 T3 ES 2573257T3
Authority
ES
Spain
Prior art keywords
nas
message
wtru
rrc
security
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
ES08796196.7T
Other languages
English (en)
Inventor
Rajat P. Mukherjee
Peter S. Wang
Mohammed Sammour
Shankar Somasundaram
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.)
InterDigital Technology Corp
Original Assignee
InterDigital Technology 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 InterDigital Technology Corp filed Critical InterDigital Technology Corp
Application granted granted Critical
Publication of ES2573257T3 publication Critical patent/ES2573257T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

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)

Abstract

Método para llevar a cabo un procedimiento de seguridad de estrato de no acceso, NAS en comunicaciones inalámbricas, comprendiendo el método: recibir (305), en una unidad de transmisión / recepción, WTRU, un mensaje de NAS que comprende un número de secuencia de NAS, SN de NAS, (410) y una cabecera de protocolo (400); efectuar una comprobación de integridad (310) en el mensaje de NAS utilizando un valor de RECUENTO como dato de entrada a un algoritmo de integridad, en el que el valor de RECUENTO comprende un SN de NAS (410) y un HFN de NAS que puede ser un contador que se incrementa en uno por cada número predeterminado de incrementos de SN de NAS; en repuesta al mensaje de NAS recibido (315), fallar la comprobación de integridad (310), ignorando el mensaje de NAS; y en respuesta al mensaje de NAS recibido, borrar la comprobación de integridad (310), procesando (360) el mensaje de NAS.

Description

5
10
15
20
25
30
35
40
45
50
55
DESCRIPCION
Metodos y aparato para implementar seguridad de estrato de no acceso (NAS) en un dispositivo inalambrico de la Evolucion a largo plazo
Campo tecnologico
El metodo y aparato se refieren a las comunicaciones inalambricas. Mas particularmente, el metodo y aparato se refieren a las comunicaciones seguras en un dispositivo inalambrico segun la Evolucion a largo plazo.
Antecedentes
Los actuales objetivos para el programa Evolucion a largo plazo (LTE - Long Term Evolution, en ingles) del Proyecto de asociacion de tercera generacion (3GPP - Third Generation Partnership Project, en ingles) van a proporcionar nueva tecnologfa, nueva arquitectura y nuevos metodos a los ajustes y configuraciones de la LTE, con el fin de proporcionar una mayor eficiencia espectral y una menor latencia, para una mejor utilizacion de los recursos de radio para experiencias de usuario mas rapidas y mejores aplicaciones y servicios con un menor coste.
Como parte de este proceso de evolucion, el grupo del 3GPP utilizara arquitecturas de seguridad en LTE diferentes de las utilizadas en el Sistema de telefoma movil universal (UMTS - Universal Mobile Telephone System, en ingles) y el Sistema Global para comunicaciones mediante telefoma movil (GSM - Global System for Mobile Communications, en ingles). Para comparar, los procedimientos de Autenticacion y Codificacion (AKA - Authentication and Key, en ingles) de UMTS en el dominio de paquetes conmutados (PS - Packet Switched, en ingles) seran la base para los nuevos procedimientos de LTE propuestos.
La figura 1 muestra una pila de protocolo de estrato de acceso 100 de UMTS. Los procedimientos de AKA y cifrado de UMTS se extienden sobre multiples capas de protocolo y utilizan senalizacion tanto de estrato de no acceso (NAS - Non-Access Stratum, en ingles) como de control de recursos de radio (RRC - Radio Resource Control, en ingles) para alcanzar sus objetivos. Generalmente, la identificacion y la autenticacion de la unidad de transmision recepcion inalambrica (WTRU - Wireless Transmit Receive Unit, en ingles) se consigue mediante senalizacion de NAS. Una vez que la autenticacion a nivel de NAS se ha efectuado, se activa el cifrado y/o la proteccion en integridad por parte de la red utilizando la Orden de modo de seguridad, que es un mensaje del RRC. Una vez que la seguridad se ha activado utilizando la Orden de modo de seguridad en la capa de RRC, la WTRU pasa las claves de cifrado e integridad (CK - Ciphering Key e IK - Integrity Key, en ingles) al estrato de acceso (AS - Access Stratum, en ingles) utilizando la primitiva GMMAS-SECURITY-RES sobre el gMmAS-SAP (definido entre Gestion de movilidad de GPRS (GMM - GPRS Mobility Management, en ingles) y el AS). Tras recibir estas claves, el RRC 110 las pasa al controlador del enlace de radio (RLC - Radio Link Controller, en ingles) 120 y al control del acceso al medio (MAC - Medium Access Control, en ingles) 130 utilizando la primitiva CRLC-cOnFIG (sobre el C-SAP entre el RRC y el RLC) y la primitiva CMAC-CONFIG (sobre el C-SAP entre el RRC y el MAC). El C-SAP (no mostrado) es un Punto de acceso a servicios para la senalizacion de plano-C entre el RRC y las capas inferiores. La proteccion de cifrado e integridad actual se realiza normalmente en el RLC 120, pero se realiza en el MAC 130 en caso de trafico en modo de RLC transparente. Las capas inferiores (es decir, MAC / RLC) son responsables de asegurar que los mensajes previstos para las capas superiores (por ejemplo, los mensajes de NAS de Capa 3) han sido protegidos en integridad y/o cifrados correctamente. De lo contrario, las capas inferiores ignoran / borran el mensaje. Una vez que la seguridad ha sido activada, la seguridad de todos los plano-C y plano-U se realiza en el RLC o el MAC.
Para LTE, se ha propuesto una arquitectura radicalmente diferente para mejorar la seguridad. La principal diferencia es que en lugar de una unica capa de seguridad (es decir, en el MAC / RLC) existen tres capas de seguridad: seguridad de NAS, seguridad de RRC y seguridad de plano-U. Cada capa tiene sus propias claves. La seguridad de NAS termina en la entidad de gestion de movilidad (MME - Mobility Management Entity, en ingles) y se realiza en la capa de NAS. La seguridad de RRC termina en el Nodo B evolucionado (e-NB - evolved Node B, en ingles) y se realiza en el Protocolo de convergencia de datos en paquetes (PDCP - Packet Data Convergence Protocol, en ingles). La seguridad de plano-U consiste en solo cifrado (ninguna proteccion en integridad) y se realiza tambien en el PDCP. Dicho de manera corta, los procedimientos de AKA se completan en el NAS y se obtienen las claves de seguridad de NAS. Los parametros de seguridad de RRC / Plano-U se obtienen de una manera separada criptograficamente a partir de las claves de NAS. El conocimiento de las claves de RRC / Plano-U no permiten a un atancante determinar las claves de NAS. El fundamento principal para esta decision era que en LTE sena posible tener diferentes e-NB en ubicaciones vulnerables, tal como en un hogar. RRC, y por lo tanto la seguridad, termina en el e-NB, de manera que esto se consideraba un riesgo en seguridad. Por ello, se adoptaron dos niveles de seguridad para el estandar.
La figura 2 es un diagrama de bloques de jerarqrna de claves en LTE 200. Como se muestra en la figura 2, el USIM (en la unidad de transmision / recepcion inalambrica (WTRU)) y el centro de autenticacion (AuC - Authentication Centre, en ingles) 205 comparten una K secreta 210. Como parte de una senalizacion de autenticacion y codificacion (AKA) (similar a los procedimientos de AKA de UMTS actuales) el USIM y el AuC / HSS obtienen una clave de cifrado (CK) 215 y una clave de integridad (IK) 220. El procedimiento para obtener la CK 215 y la IK 220 es similar al de UMTS, en el que AuC / HSS obtiene un Vector de autenticacion y envfa una pregunta de seguridad a la
5
10
15
20
25
30
35
40
45
50
WTRU en un mensaje de NAS al que la WTRU responde y que el HSS / AuC verifica. A diferencia del UMTS, no obstante, en el que Ck 215 e IK 220 son proporcionadas a las capas de MAC / RLC para efectuar el cifrado y/o la proteccion en integridad, en LTE la CK 215 y la IK 220 se utilizan para obtener las claves restantes en la jerarqma de claves que empieza con una clave maestra - la llamada clave Kasme 225. Las claves restantes se obtienen a partir de la clave Kasme utilizando diferentes funciones de obtencion de clave (KDF - Key Derivation Functions, en ingles) y realizando un truncado.
La KeNB 230 es una clave obtenida por medio de la WTRU y la MME a partir de la Kasme 225 o por medio de la WTRU y el eNB de objetivo a partir de la KeNB* durante una transferencia de eNB. La KeNB 230 se utiliza para la obtencion de claves para trafico de RRC y la obtencion de claves para trafico ascendente o para obtener una clave de transicion KeNB* durante una transferencia de eNB.
La Knas int 235 es una clave que se utiliza para la proteccion en integridad de la senalizacion de NAS con un algoritmo de integridad particular. Esta clave es obtenida por la WTRU y la MME 237 a partir de la Kasme 225, asf como un identificador para el algoritmo de integridad que utiliza una KDF.
La KNASenc 240 es una clave que se utiliza para el cifrado de la senalizacion de NAS con un algoritmo de encriptacion particular. Esta clave es obtenida por la WTRU y la MME 237 a partir de la Kasme 225, asf como un identificador para el algoritmo de encriptacion que utiliza una KDF.
La Kup enc 245 es una clave que se utiliza para el cifrado del trafico ascendente con un algoritmo de encriptacion particular. Esta clave es obtenida por la WTRU y el eNB 247 a partir de la KeNB 230, asf como de un identificador para el algoritmo de encriptacion que utiliza una KDF.
La Krrc int 250 es una clave que se utiliza para la proteccion en integridad del trafico de RRC con un algoritmo de integridad particular. La Krrc int 250 es obtenida por la WTRU y el eNB 247 a partir de la KeNB 230, asf como un identificador para el algoritmo de encriptacion que utiliza una KDF.
La Krrc enc 255 es una clave que se utiliza para el cifrado de la senalizacion de RRC con un algoritmo de encriptacion particular. La Krrc enc 255 es obtenida por la WTRU y el eNB 247 a partir de la KeNB 230, asf como un identificador para el algoritmo de encriptacion que utiliza una KDF.
Las claves de RRC y del plano-U pueden ser obtenidas con el C-RNTI como dato de entrada.
En la arquitectura de seguridad de UTRAN existente, una comprobacion para un correcto cifrado y/o proteccion en integridad se realiza en el RLC o el MAC. El unico escenario de manejo de fallo en seguridad actualmente en el NAS es si falla la autenticacion. No obstante, con un procedimiento de cifrado y proteccion en integridad separado en el NAS, sena deseable definir procedimientos de NAS en respuesta a escenarios en los cuales se recibe un mensaje de NAS sin estar correctamente protegido en cifrado y/o en integridad.
El NAS se basa en el AS, es decir, el RLC o el MAC, para verificar que cualquier mensaje de Capa-3 (L3 - Layer 3, en ingles) recibido tiene las credenciales de seguridad correctas, es decir, estaban cifrados y adecuadamente protegidos en integridad. Dado que la nueva arquitectura de LTE que tiene seguridad de capa de NAS independiente de la seguridad de AS, y que el NAS verifica la seguridad de los mensajes de L3, este planteamiento resulta inadecuado, dado que la comprobacion de la seguridad de NAS se efectua como parte de los procedimientos definidos en el comportamiento de NAS. Asf, resultana deseable la definicion de acciones para el NAS en caso de fallo.
Dado que las claves de NAS son independientes de las claves de RRC / plano-U (a continuacion, en esta memoria, claves de AS) es posible iniciar / reconfigurar el cifrado de NAS independientemente del cifrado y de la proteccion en integridad del AS. Resultana deseable tener nuevos mensajes y procedimientos para este proceso. Asimismo, la expiracion de la clave puede estar ligada al estado del NAS / RRC de la WTRU. Resultana deseable disponer de procedimientos para el manejo de las claves de la WTRU.
El RRC tipicamente recibe las nuevas CK e IK del NAS y las pasa al MAC y al RLC, donde se realiza el cifrado / proteccion en integridad. No obstante, en LTE, el cifrado de AS y la proteccion en integridad seran efectuados por el PDCP. De este modo, resultana deseable disponer de nuevos procedimientos de capas cruzadas y primitivas para un adecuado funcionamiento de la seguridad.
El alcance del “3rd Generation Partnership Project; Technical Specification Group \ Services and System Aspects; Rationale and track of security decisions in Long Term Evolved (LTE) RAN / 3GPP System Architecture Evolution (SAE) (Release 8)”, 3GPP TR 33.821 V0.4.0, es la base y seguimiento de las decisiones en una RAN evolucionada a largo plazo (de LTE) y de Evolucion de arquitectura del sistema (SAE - System Architecture Evolution, en ingles) del 3GPP para la version 8.
5
10
15
20
25
30
35
40
45
Compendio
Un metodo y aparato tal como se define en las reivindicaciones 1 y 9 se refieren a un sistema de comunicacion inalambrica que incluye una unidad de transmision / recepcion (WTRU) configurada para recibir mensajes no cifrados y cifrados. Los mensajes no cifrados pueden incluir solicitudes de identidad, solicitudes de autenticacion, ordenes de modo de seguridad de estrato de no acceso (NAS) y respuestas de actualizacion del area de seguimiento. Los mensajes cifrados pueden proceder del NAS y del controlador de recursos de radio (RRC). Los mensajes preferiblemente estan cifrados utilizando claves de seguridad.
Breve descripcion de los dibujos
Es preciso tener una compresion mas detallada a partir de la descripcion siguiente, dada a modo de ejemplo, y que se comprendera junto con los dibujos que se acompanan, en los cuales:
la figura 1 es una pila de protocolo de estrato de acceso de acuerdo con la tecnica anterior;
la figura 2 es un diagrama de bloques de la jerarqma de claves en LTE de acuerdo con la tecnica anterior;
la figura 3 es un diagrama de bloques de una realizacion en la que el agente puede ser la capa equivalente de Gestion de Movilidad en NAS de LTE o una nueva sub-capa para la seguridad o algun otro agente, y los parametros de seguridad definidos para un mensaje dado son incorrectos;
la figura 4 es un diagrama de bloques de una cabecera de protocolo de capa 3 mejorada que incluye un numero de secuencia de NAS;
la figura 5 es un diagrama de bloques que ilustra procedimientos de manejo de claves en una WTRU tras la transicion del modo EMM_Conectado al modo de EMM_Reposo;
la figura 6 es un diagrama de bloques de una pila de protocolo de estrato de acceso para LTE; y
la figura 7 es un diagrama de bloques de un sistema de comunicacion inalambrica configurado para el intercambio de mensajes cifrados y no cifrados en LTE.
Descripcion detallada
Cuando se nombra a continuacion en esta memoria, la terminologfa “unidad de transmision / recepcion inalambrica (WTRU)” incluye, pero no esta limitada a un equipo de usuario (UE - User Equipment, en ingles), una estacion de telefoma movil, una unidad de abonado fijo o movil, un localizador, un telefono celular, un asistente digital personal (PDA - Personal Digital Assistant, en ingles), un ordenador, o cualquier otro tipo de dispositivo de usuario capaz de operar en un entorno inalambrico. Cuando se nombra a continuacion en esta memoria, la terminologfa “estacion de base” incluye, pero no esta limitada a un Nodo B, Nodo B mejorado (eNB), un controlador de sitio, un punto de acceso (AP - Access Point, en ingles), o cualquier otro tipo de dispositivo de interfaz con capacidad de operacion en un entorno inalambrico.
Manejo del fallo de seguridad en el NAS
Los procedimientos que se explican a continuacion pueden ser utilizados si existen problemas con la seguridad en alguna otra capa, por ejemplo, en la capa de PDCP que efectua cifrado / proteccion en integridad de RRC. Un procedimiento para el manejo del fallo en seguridad en el NAS es proporcionar un grupo de mensajes de NAS que pueden ser recibidos por una WTRU sin cifrado y/o proteccion en integridad en el NAS que esta activado. Tal lista solo existe para los mensajes de NAS de UTRAN, que son diferentes de los mensajes de NAS de LTE, y pueden ser recibidos sin que este activado el cifrado de RLC / MAC. El grupo de mensajes de NAS que pueden ser recibidos por una WTRU sin cifrado y/o proteccion en integridad en el NAS activado puede incluir, pero no estar limitado a.
solicitud de identidad;
solicitud de autenticacion;
orden de modo de seguridad de NAS (esta solo puede ser recibida si al menos la proteccion en integridad en NAS esta activada); y
respuesta de actualizacion de area de seguimiento.
En la MME es posible recibir los siguientes mensajes sin cifrado y/o proteccion en integridad:
respuesta de identidad;
respuesta de autenticacion; y
solicitud de actualizacion de area de seguimiento.
5
10
15
20
25
30
35
40
45
50
Ademas, se puede obligar a que mientras los mensajes anteriores puedan ser recibidos sin cifrado y/o proteccion en integridad activados, si el cifrado y/o la proteccion en integridad han sido ya activados, entonces estos mensajes deban estar cifrados y/o con proteccion en integridad.
Algunos otros mensajes de NAS solo pueden ser enviados si la seguridad tanto de NAS como de RRC ha sido activada. Algunos mensajes de NAS pueden ser enviados si la seguridad de NAS ha sido activada (independiente de la seguridad de RRC).
La figura 3 es un diagrama de bloques 300 de una realizacion en la que el agente puede ser la capa equivalente de gestion de movilidad en NAS de LTE, o una nueva sub-capa para seguridad, o algun otro agente. Una vez que un mensaje de NAS se ha recibido 305, el agente responsable de la comprobacion del estado de la seguridad del mensaje de NAS comprobara si los parametros de seguridad para el mensaje son apropiados 310. Si los parametros de seguridad definidos para un mensaje dado son incorrectos 315, es decir, las comprobaciones de seguridad fallan o el mensaje no esta cifrado, o si un mensaje (dependiendo de los campos de discriminador de protocolo y de tipo de mensaje en la cabecera) debena haber sido recibido cifrado y/o con proteccion en integridad, pero no lo fue, la capa de NAS, sub-capa o el agente, pueden tomar alguna o todas las acciones siguientes en cualquier secuencia. Las acciones tomadas pueden depender del tipo de mensaje cuyos parametros de seguridad han fallado. Los procedimientos que se definen a continuacion, pueden ser utilizados tambien si existen problemas con la seguridad en alguna otra capa (por ejemplo, la seguridad de RRC falla):
las acciones del agente pueden ser definidas mediante implementacion 320;
el agente puede ignorar y/o borrar el mensaje 325;
el agente puede informar del fallo a alguna otra capa de protocolo (por ejemplo, RRC), entidad en la red WTRU (por ejemplo, USIM / UICC) 330. Si el agente comprueba la seguridad y encuentra un error puede activar, por ejemplo, un mensaje a la red informando a la red del error. El informe puede incluir la razon para el fallo. Si alguna otra capa de protocolo / entidad ha sido informada de tal fallo, su respuesta puede ser similar a las descritas aqrn;
el agente puede iniciar una reautenticacion con la red 335;
el agente puede moverse al modo de gestion de movilidad (EMM_Reposo) del sistema de paquetes evolucionado (EPS) o al estado EMM_Eliminado del registro 340;
el agente puede guardar un recuento del numero de fallos y realizar algunas acciones tras fallos 345 repetidos. Estas acciones pueden ser las mismas que las definidas en esta memoria.
El agente puede intentar la reconexion a la red 350; o
el agente puede borrar algunos o todos los protocolos de seguridad (claves / numeros de secuencia / identificadores de conjunto de claves) que estan almacenados, o puede senalar la entidad en la WTRU, bien directamente o a traves de un intermediario, que almacena / gestiona los parametros de seguridad para hacerlo 355.
Si los parametros de seguridad son correctos, el mensaje de NAS puede ser procesado como se define para el protocolo espedfico y el tipo de mensaje 360. Como ejemplo, este agente puede ser la capa equivalente de gestion de movilidad en NAS de lTe o una nueva sub-capa para seguridad o algun otro agente.
Impactos del protocolo de capa 3
La cabecera del protocolo de L3 existente no contiene un numero de secuencia. La cabecera de un mensaje de L3 estandar esta compuesta por dos octetos. La cabecera esta estructurada en tres partes principales, el discriminador de protocolo (1/2 octeto), un octeto de tipo mensaje y medio octeto. El medio octeto se utiliza en algunos casos como identificador de transaccion, en algunos otros casos como sub-discriminador de protocolo y se denomina en caso contrario indicador de salto. Por ejemplo, si el discriminador de protocolo esta ajustado a GMM, entonces puede ser utilizado como indicador de salto. Si el discriminador de protocolo esta ajustado a SM, entonces puede ser utilizado como un TI o como un sub-discriminador de protocolo. Si se utiliza como indicador de salto, significa que para los mensajes de GMM los primeros 4 bits no tienen significado y son 'saltados'.
El discriminador de protocolo distingue entre mensajes de gestion de movilidad (MM), de gestion de movilidad de GPRS (GMM), de gestion de sesion (SM - Session Management, en ingles) y otros. Aunque el tipo de mensaje indica la clase de mensaje, por ejemplo, solicitud de conexion o activacion de contexto de PDP, el identificador de la transaccion permite a las entidades de transferencia en la WTRU y en la red distinguir hasta 16 flujos de mensajes bidireccionales diferentes para un discriminador de protocolo dado y un punto de acceso a servicio (SAP - Service Access Point, en ingles) dado. Tal flujo de mensajes se denomina transaccion. Se define asimismo un mecanismo de extension para un Identificador de transaccion (TI - Transaction Identifier, en ingles). Este mecanismo permite distinguir hasta 256 flujos de mensajes bidireccionales diferentes para un discriminador de protocolo y un SAP dados. Por ejemplo, cuando la WTRU intenta obtener una direccion de IP, existe una entidad de SM en la WTRU y
5
10
15
20
25
30
35
40
45
50
55
en la red. Si la WTRU intenta entonces obtener otra direccion de IP, se crea otro par de entidades de SM en la WTRU y en la red. El TI identifica a que transaccion, es decir, par, esta dirigido un mensaje de SM particular.
La figura 4 es un diagrama de bloques de una cabecera de protocolo de L3 400 mejorada que incluye un numero de secuencia de NAS 410. Como la cabecera de protocolo de L3 existente, la cabecera mejorada esta compuesta por dos octetos, y estructurada en tres partes principales. Las tres partes principales son el discriminador de protocolo 420 (1/2 octeto), un octeto de tipo mensaje y medio octeto utilizado en algunos casos como identificador de transaccion 430, en algunos otros casos como sub-discriminador de protocolo, y se denomina de lo contrario indicador de salto. Por ejemplo, si el discriminador de protocolo esta ajustado a GMM, entonces puede ser utilizado como un indicador de salto. Si el discriminador de protocolo esta ajustado a SM, entonces puede ser utilizado como TI o como sub-discriminador de protocolo. Si se utiliza como indicador de salto, significa que para los mensajes de GMM los primeros 4 bits no tienen significado y son 'saltados'. La cabecera mejorada incluye un numero de secuencia para un mensaje de NAS 410, denominado a continuacion en esta memoria SN de NAS. Puede estar incluido en la cabecera de protocolo de un mensaje de NAS o como elemento de informacion (IE - Information Element, en ingles) en su contenido. El identificador de transaccion puede funcionar asimismo como numero de secuencia. El SN de NAS puede tener un periodo de incremento predefinido o negociado. Como ejemplo, podna ser por cada PDU de NAS (es decir, mensaje). La capa de NAS puede ser capaz de realizar una deteccion duplicada sobre la base del numero de secuencia o utilizando cualquier otro numero que se incrementa utilizando el SN de NAS, donde las PDU de NAS duplicadas recibidas son ignoradas.
El SN de NAS puede ser guardado para cada portador de radio de senalizacion de AS o por SAP, independientemente del discriminador de protocolo o del tipo de mensaje. Es posible guardarlo tambien por cada TI.
Es posible utilizar un valor de RECUENTO en la capa de NAS. Incrementar el valor de RECUENTO de manera predefinida / negociada, por ejemplo, en cada mensaje de L3, puede proteger frente a ataques de reproduccion o suplantacion. Esto es factible con cifrado a nivel de NAS. Es posible definir un unico RECUENTO-C para cifrado y un unico RECUENTO-I para proteccion en integridad, para todos los SAP. Es posible definir una combinacion de RECUENTO-C y/o RECUENTO-I y/o valores de RECUENTO unicos para los SAP. El RECUENTO puede consistir en dos parametros; un numero de secuencia de NAS (SN) que se incrementa de una manera regular predefinida / negociada, por ejemplo, por cada unidad de datos de protocolo (PDU) de NAS o por cada PDU de NAS en un SAP dado, y un numero de hiper-trama de NAS (NAS HFN - NAS Hyper-Frame Number, en ingles). El HFN de NAS puede ser un contador que se incrementa en uno por cada x numeros de incrementos de SN de NAS. El parametro RECUENTO, en todo o en parte, puede ser inicializado sobre la base de un valor de INICIO durante el acceso inicial / obtencion de clave / autenticacion / transicion de reposo a activo. El parametro RECUENTO puede ser utilizado como dato de entrada a los algoritmos de comprobacion de cifrado / descifrado, proteccion en integridad / integridad para asegurar la seguridad.
El valor de RECUENTO puede precisar ser establecido antes de la activacion de la seguridad de NAS. La longitud del parametro RECUENTO-C podna ser 32 bits, o podna ser reducido a un valor menor, puesto que para mensajes de NAS podna no ser necesario un valor de SN elevado. Asimismo, la longitud del campo de SN y del propio campo del HFN podna ser modificada dentro del parametro RECUENTO-C para optimizarla para procedimientos a nivel de NAS. Es posible utilizar motores de cifrado de la tecnica anterior para NAS. Se debe realizar un cambio adecuado al motor de cifrado para que contenga un valor de RECUENTO-C menor o un cambio en el valor del campo del SN y del HFN.
De manera alternativa, el valor de RECUENTO de NAS puede ser el SN de NAS, dado que el SN de NAS puede ser protegido mediante el encriptado del RRC, de manera que no esta abierto y por lo tanto un HFN oculto no es absolutamente necesario. La seguridad de NAS puede ser activada no antes de que la seguridad de NAS y el SN de NAS puedan ser reiniciados tras la activacion de la seguridad de NAS. Ademas, es posible duplicar la deteccion en el NAS utilizando el valor RECUENTO de NAS.
Sena preciso definir parametros adicionales en lugar de la longitud del mensaje o del ID de portador, que son datos de entrada al motor de cifrado, o sena preciso definir procedimientos adicionales en el NAS para extraer estos parametros cuando la seguridad de NAS encripta el mensaje.
De manera alternativa en el lado de la WTRU en lugar de tener 2 motores de cifrado separados para RRC y NAS, es posible utilizar un motor de cifrado que puede funcionar con parametros tanto de RRC como de NAS.
Otro cifrado de mensajes a nivel de NAS puede ser opcional, y la WTRU puede indicar en su informacion de capacidad si soporta o no cifrado a nivel de NAS.
Manejo de claves en la WTRU tras la transicion desde el modo EMM conectado al modo EMM en reposo
Tfpicamente, cuando una WTRU pasa del modo EMM_Conectado al modo EMM_Reposo la conexion del RRC se libera. En las transiciones de activo a reposo, un eNB tfpicamente no almacena informacion de estado acerca de la WTRU correspondiente. El eNB tfpicamente borra las claves actuales de su memoria.
5
10
15
20
25
30
35
40
45
50
55
Para esta realizacion en particular, en las transiciones de activo a reposo, el eNB puede borrar al menos una de KeNB, Krrc enc y Krrc int y Kup enc. No obstante, la MME puede almacenar Kasme.
La figura 5 es un diagrama de bloques que ilustra procedimientos de manejo de claves 500 en una WTRU tras la transicion del modo EMM_Conectado al modo EMM_Reposo. Hasta ahora, los procedimientos de WTRU no han sido definidos en respuesta a esta transicion. Un procedimiento posible sena que tras la transicion al modo EMM_Reposo 510, la WTRU pudiese proporcionar una indicacion de la transicion a la entidad que almacena las claves de seguridad 520 en la WTRU, tal como UICC, USIM o Equipo de telefoma movil. Otro posible procedimiento sena que es posible que la WTRU proporcione 520 una indicacion a la entidad de almacenamiento cuando el e-NB de servicio cambia mientras esta en modo EMM_Reposo 530, tal como durante la reseleccion de una celula para diferente e-NB. La indicacion de la WTRU a la entidad de almacenamiento puede incluir la identidad del e-NB de manera que se puedan obtener nuevas claves de e-NB, RRC y plano-U. A modo de ejemplo, las indicaciones pueden ser proporcionadas por el NAS y/o el AS. Con este proposito, es posible definir primitivas predeterminadas, que incluyen mensajes, IE, interfaces y SAP entre capas de protocolo de la entidad indicadora y/o entre la entidad indicadora y la entidad de almacenamiento. Se comprendera que las primitivas predeterminadas incluyen primitivas tanto nuevas como existentes que es posible utilizar. Tras la recepcion de tal indicacion de transicion, la entidad de almacenamiento dentro de la WTRU preferiblemente borrara las claves apropiadas 540, por ejemplo, al menos una de KeNB, KRRC enc, Krrc int y Dup enc. Puede elegir guardar o borrar las claves de seguridad de NAS y las claves de ASME 550.
La entidad de almacenamiento puede borrar la Krrc enc, la Krrc int y la Kup enc tras la recepcion de una indicacion de transicion de activo a reposo, y borrar la KeNB cuando se recibe una indicacion de un cambio en el e-NB de servicio, tal como durante la reseleccion para un e-NB diferente. Puede elegir guardar o borrar las claves de seguridad de NAS u las claves de ASME. Tras la reseleccion a una celula que pertenece a un e-NB diferente, lo que se determina leyendo la identificacion del e-NB en el canal de emision, la WTRU puede generar una nueva K*eNB utilizando la KeNB y un “identificador de siguiente salto”.
La entidad de almacenamiento no puede borrar ninguna clave tras la transicion de activo a reposo o tras la transicion a un nuevo e-NB en modo de reposo mientras que puede borrar claves tras la transicion de reposo a activo.
La entidad de almacenamiento no puede borrar ninguna clave tras la transicion de activo a reposo o tras la transicion a un nuevo e-NB en modo reposo. Por el contrario, puede borrarlas cuando se van a generar nuevas claves, por ejemplo, cuando un eNB recibe una solicitud de conexion de RRC o se asigna un nuevo C-RNTI.
Un cambio en el ID de la celula de servicio / C-RNTI puede ser indicado 560 a la entidad de almacenamiento. Esta indicacion puede ser proporcionada por el NAS y/o el AS. De manera alternativa, las claves pueden ser almacenadas con un valor de temporizador 570 asociado. Cuando una WTRU pasa de reposo a activo o de activo a reposo, el tiempo puede controlar cuanto tiempo puede seguir siendo valida una clave antes de ser eventualmente borrada.
Impactos a la capa de PDCP debido a la arquitectura de cifrado propuesta
Tfpicamente, el cifrado para el trafico de RRC y del plano-U puede ser realizado en la capa de PDCP. Esto impone muchos cambios de arquitectura en el PDCP.
En esta realizacion, la capa de PDCP tiene la capacidad de recibir las claves de seguridad del RRC y las claves de seguridad del plano-U de capas superiores. Las primitivas se pueden definir segun las necesidades. Espedficamente el RRC o el NAS o el USIM pueden proporcionar al PDCP las claves de cifrado requeridas y los valores de INICIO o RECUENTO o HFN o SN requeridos. La capa de PDCP puede asimismo tener la capacidad de calcular estos valores por sf misma, basandose en la informacion de la cabecera del RRC.
Con referencia a la figura 1, el trafico del plano-C no pasa a traves del PDCP. Dado que es posible fijar diferentes portadores de radio utilizando diferentes parametros RECUENTO, es preferible que la capa de PDCP pueda distinguir entre diferentes clases de trafico. Para ello, las SDU entrantes o las primitivas que transportan las SDU pueden tener informacion explfcita relativa a las portadoras de radio destinadas. La capa de PDCP puede determinarlo por sf misma y cifrar / proteger la integridad de acuerdo con ello.
La figura 6 es un diagrama de bloques de una pila de protocolo de estrato de acceso para LTE 600. Con referencia a la figura 6, el trafico del plano-C pasa a traves de la capa de PDCP 610. La capa de PDCP 610 comprueba la seguridad de las PDU de PDCP entrantes. Si la capa de PDCP 610 observa que los parametros de seguridad de una PDU entrante (que va a ser mapeada bien a un portador de radio de datos o a un portador de radio de senalizacion) son incorrectos (es decir, si, por ejemplo, la comprobacion de la integridad de la PDU del PDCP falla) puede efectuar al menos una de las acciones que siguen en cualquier secuencia. Las acciones realizadas pueden depender del tipo de mensaje cuyos parametros de seguridad han fallado. Los procedimientos definidos a continuacion pueden ser asimismo utilizados si existen problemas con la seguridad en alguna otra capa, por ejemplo, si la seguridad de NAS falla:
las acciones del PDCP pueden ser definidas mediante implementacion;
5
10
15
20
25
30
35
40
45
50
el PDCP puede ignorar y/o borrar el mensaje;
puede informar del fallo a alguna otra capa de protocolo, tal como la entidad de RRC en la WTRU; otra capa de protocolo puede ser informada de tal fallo;
puede guardar un recuento del numero de fallos y tomar realizar acciones tras fallos repetidos (por ejemplo, X numero de fallos en Y mensajes o unidades de tiempo) tal como las definidas en esta memoria o algunas otras acciones;
puede borrar algunos o todos los parametros de seguridad, tal como claves y numeros de secuencia, que estan almacenados o puede senalar la entidad en la WTRU, directa o indirectamente, que almacena o gestiona los parametros de seguridad para hacerlo; y
un informe del fallo a otras capas de protocolo puede incluir la razon del fallo.
El HFN de PDCP puede ser utilizado para constituir un valor de RECUENTO. Este valor de RECUENTO puede ser utilizado en los algoritmos de cifrado y/o de proteccion en integridad del PDCP 510 y puede ser inicializado mediante un valor de INICIO. Pueden existir multiples valores de RECUENTO para cada portador de radio que el PDCP puede proteger. El RRC 620 y las capas de PDCP 610 pueden ser capaces de intercambiar informacion relativa al valor de RECUENTO o a sus constituyentes.
La capa de PDCP 610 puede comprobar la proteccion en integridad de un mensaje. Esto esta en lmea con la asuncion de que la proteccion en integridad esta en el PDCP 610. No obstante, actualmente la palabra de codigo de autenticacion de mensaje (MAC) adjunta al mensaje para certificar su integridad se calcula en el RRC 620 adjunto al mensaje de RRC y se baja al RLC 630 / control de acceso al medio (MAC) 640. El mensaje completo, incluida la palabra de MAC, esta cifrado. Asimismo, la capa de PDCP 610 puede no ser capaz de determinar si un mensaje de RRC necesita proteccion.
En el lado de transmision, la capa de RRC 620 puede indicar a la capa de PDCP 610 si un mensaje de RRC dado requiere o no requiere proteccion en integridad y/o cifrado. La capa de PDCP 610 puede utilizar esta indicacion para determinar si efectuar un cifrado y/o proteccion en integridad en los mensajes de RRC para ser enviados a las PDU de PDCP.
Esta indicacion puede ser una indicacion explfcita proporcionada por el RRC a la capa de PDCP en cada mensaje de RRC enviado por el RRC al PDCP utilizando nuevos bits. Alternativa o adicionalmente, la indicacion puede ser implfcita, por ejemplo, cifrado y/o proteccion en integridad en el PDCP siempre estara activado a menos que se indique, o siempre estara desactivado a menos que se indique otra cosa por parte del RRC. Como ejemplo, sena posible utilizar un indicador de 2 bits por parte de la capa de RRC 620 para indicar cualquier combinacion de cifrado y proteccion en integridad que este activa. Tal indicacion puede ser enviada con cada mensaje del RRC pasado al PDCP o puede aplicar a todos los mensajes de RRC y es preferible, puesto que algunos mensajes de RRC pueden no estar cifrados y/o protegidos en integridad.
De manera alternativa o, ademas, la capa de RRC 620 puede indicar a la capa de PDCP 610 que todos los mensajes de RRC que empiezan con un mensaje de RRC dado estaran protegidos en integridad.
De manera alternativa o, ademas, la capa de RRC 620 puede indicar a la capa de PDCP 610 que todos los mensajes de RRC que empiezan con un mensaje de RRC dado estaran cifrados.
De manera alternativa o, ademas, la capa de RRC 620 puede indicar a la capa de PDCP 610 que todos los mensajes de RRC que empiezan con un mensaje de RRC dado estaran cifrados y protegidos en integridad.
De manera alternativa o, ademas, la capa de RRC 620 puede proporcionar una lista de mensajes de RRC genericos a la capa de PDCP 610 y sus parametros de seguridad asociados. La lista puede incluir mensajes que pueden ser recibidos sin cifrar y/o sin proteccion en integridad, tal como, por ejemplo, un Restablecimiento de conexion de RRC. La lista puede incluir mensajes que pueden ser recibidos con cifrado y/o con proteccion de integridad.
De manera alternativa o, ademas, es posible definir una marca de comprobacion de cifrado y/o de integridad, opcionalmente por parte de la capa de RRC 620, que, si esta establecida, la capa de PDCP 610 cifrara y/o comprobara la integridad de todos los mensajes de RRC. La capa de PDCP 610 comprobara de este modo esta marca antes de la comprobacion del cifrado y la integridad. Pueden existir marcas separadas ajustadas para cifrado y proteccion de integridad.
Para todos los mecanismos de indicacion diferentes anteriores la indicacion puede ser facilitada por cada portador de radio de senalizacion (SRB - Signaling Radio Bearer, en ingles), es decir, la capa de RRC 620 puede indicar a la capa de PDCP 610 que la indicacion para el cifrado y/o la proteccion en integridad aplica a los mensajes de RRC mapeados por la capa de PDCP 610 al SRB espedfico.
Para que un mensaje sea transmitido, la capa de PDCP 610 puede en primer lugar proteger en integridad y despues cifrar o puede cifrar primero y despues proteger en integridad. Antes de cualquier operacion, puede rellenar el
5
10
15
20
25
30
35
40
45
50
mensaje con el fin de conseguir una longitud optima para el cifrado y/o la proteccion en integridad. Antes de la operacion de seguridad la capa de PDCP 610 puede asignar un SN. El SN puede ser un SN de PDCP, o puede reutilizar un SN de RRC, o puede utilizar otro numero de secuencia, tal como, por ejemplo, un numero de secuencia comun. Antes de la operacion de seguridad, la capa de PDCP 610 puede efectuar una compresion de cabecera para el trafico del plano-U.
La palabra de MAC para proteccion en integridad puede ser calculada sobre los datos de texto no cifrado, los datos cifrados y/o toda o parte de la cabecera de PDCP.
El cifrado puede ser realizado sobre todo el mensaje, incluyendo una palabra de MAC y/o el mensaje del texto no cifrado y/o sus partes.
El cifrado puede ser realizado asimismo sobre toda o parte de la cabecera de PDCP, por ejemplo, excluyendo el SN.
Se puede incluir una indicacion de si la carga util ha sido cifrada y/o protegida en integridad. Por ejemplo, la capa de PDCP 610 en el lado de transmision puede incluir un IE indicando la presencia de informacion de comprobacion de integridad y/o que el cifrado esta activado. Esta indicacion puede estar cifrada. Esta indicacion puede indicar la posicion de la palabra de MAC dentro del mensaje para que la capa de PDCP la compruebe. La capa de PDCP 610 en el lado de recepcion puede utilizar esta indicacion para decidir si descifrar y/o comprobar la integridad.
La capa de PDCP 610 y el protocolo pueden incluir una palabra de MAC para la comprobacion de la integridad en una posicion predefinida dentro de la cabecera de PDCP / mensaje para el receptor. De manera alternativa, la posicion de una palabra de MAC puede ser indicada a la capa de PDCP 610 de recepcion. Tal indicacion puede ser, como ejemplo, un campo de desfase en la cabecera.
Dependiendo del orden de la operacion de seguridad en el lado de transmision, el PDCP de recepcion descifrara un mensaje entrante en primer lugar y, a continuacion, comprobara su integridad, o primero comprobara la integridad y a continuacion descifrara el mensaje. Las operaciones de seguridad en la unidad de recepcion son en el orden inverso al de la unidad de transmision. La posicion de la palabra de MAC dentro de la cabecera de PDCP / mensaje puede ser asistida mediante un campo de indicacion.
La capa de PDCP 610 puede decidir si el cifrado y/o la proteccion en integridad no es satisfactoria para un mensaje particular. Esto significa que el PDCP determinara si el mensaje ha sido o no cifrado y/o protegido en integridad correctamente.
La capa de PDCP 610 puede indicar a la capa de RRC el estado de seguridad del mensaje que esta pasando a la capa de RRC 620, por ejemplo, si el mensaje es recibido con cifrado y/o proteccion en integridad. O, como ejemplo adicional, si la comprobacion de proteccion en integridad tuvo o no exito. La indicacion puede ser impffcita, es decir, solo proporcionada cuando existe un error, por ejemplo, si la comprobacion de la proteccion en integridad falla. La capa de RRC 620 puede entonces decidir si la proteccion para un mensaje particular es aceptable. El comportamiento del RRC cuando se le notifica un error puede ser tal como se define para el PDCP en el parrafo [0064]. De manera alternativa o, ademas, la capa de RRC puede notificar a la red el fallo de la comprobacion de integridad anadiendo un elemento de informacion (al mensaje de RRC que envfa a la red) que informa a la red del fallo.
En caso de error, la capa de PDCP 610 puede llevar a cabo las etapas descritas en los escenarios de manejo del fallo presentados anteriormente. Si el mensaje del RRC es ASN.1 codificado y la palabra de MAC esta incluida en la capa de RRC 620, la capa de PDCP 610 puede mirar en la capa de RRC y comprobar la palabra de MAC. Puede hacer eso si la marca que indica proteccion en integridad esta establecida.
Procedimientos de seguridad transversal
La capa de RRC / PDCP puede recibir las claves de eNB / RRC / plano-U de la capa de NAS o de la USIM. De manera alternativa, el RRC / PDCP puede generar sus propias claves. Como ejemplo, la capa de RRC puede generar las claves e-NB / RRC / plano-U utilizando parametros recibidos desde la red en la senalizacion de RRC y el ASME recibido desde el NAS y otros parametros recibidos desde otras capas de protocolo (por ejemplo, la identidad de celula ffsica de la celula en la cual la WTRU se encuentra actualmente o cuyo acceso es posible obtener a partir de la capa ffsica). Estas claves de seguridad se pueden pasar entre el NAS y el RRC / PDCP, o entre el RRC y el PDCP utilizando primitivas predeterminadas, incluyendo primitivas nuevas o existentes, sobre SAP nuevos o existentes. Cada capa puede tener la capacidad de indicar un error, es decir, un fallo de seguridad, a las capas superiores / inferiores.
La figura 7 es un diagrama de bloques de un sistema de comunicacion inalambrico 700 configurado para intercambio de mensajes cifrados y no cifrados en LTE. El sistema incluye una estacion de base 705 y una unidad de transmision / recepcion inalambrica (WTRU) 710. La estacion de base 705 y la WTRU 710 se comunican a traves de un enlace de comunicaciones inalambrico.
Como se muestra en la figura 7, la WTRU 710 incluye un transmisor 720, un receptor 730 y un procesador 740. El procesador 740 esta unido a una memoria temporal 750 y a una memoria 760. El procesador 740 esta configurado para procesar mensajes de NAS que contienen parametros de seguridad utilizando al menos una tecnica descrita anteriormente.
5 Tambien mostrada en la figura 7 se encuentra la estacion de base 705 que incluye un transmisor 765, un receptor 770 y un procesador 780. El procesador 780 esta unido a una memoria temporal 790 y a una memoria 795. El procesador 780 esta configurado para procesar mensajes de NAS que contienen parametros de seguridad que utilizan al menos una tecnica descrita anteriormente.
Aunque las caractensticas y elementos se describen en combinaciones particulares, cada caractenstica o elemento 10 puede ser utilizado solo sin ninguna otra caractenstica ni elemento, o en varias combinaciones con o sin otras caractensticas y elementos. Los metodos o diagramas de flujo proporcionados pueden ser implementados en un programa informatico, software o firmware realizado de manera tangible en un medio de almacenamiento legible por ordenador, para su ejecucion mediante un ordenador de proposito general o un procesador. Ejemplos de medios de almacenamiento legibles por ordenador incluyen una memoria de solo lectura (ROM - Read Only Memory, en 15 ingles), una memoria de acceso aleatorio (RAM - Random Access Memory, en ingles), un registro, una memoria oculta, dispositivos de memoria de semiconductores, medios magneticos tales como discos duros internos y discos desmontables, medios opto-magneticos y medios opticos tales como discos de CD-ROM, y discos versatiles digitales (DVD - Digital Versatile Disk, en ingles).
Procesadores adecuados incluyen, a modo de ejemplo, un procesador de proposito general, un procesador de 20 proposito especial, un procesador convencional, un procesador de senal digital (DSP - Digital Signal Processor, en ingles), una pluralidad de microprocesadores, uno o mas procesadores en asociacion con un nucleo de DSP, un controlador, un microcontrolador, circuitos integrados espedficos para una aplicacion (ASIC - Application Specific Integrated Circuits, en ingles), circuitos de matrices de puertas programables en campo (FPGA - Field Programmable Gate Array, en ingles) y otro tipo de circuito integrado (IC - Integrated Circuit, en ingles) y/o una 25 maquina de estados.
Un procesador en asociacion con software puede ser utilizado para implementar un transceptor de radiofrecuencia para su utilizacion en una unidad de transmision / recepcion (WTRU), un equipo de usuario (UE), un terminal, una estacion de base, un controlador de red de radio (RNC) o cualquier ordenador anfitrion. La WTRU puede ser utilizada junto con modulos, implementados en hardware y/o software, tal como una camara, un modulo de camara 30 de video, un videotelefono, un altavoz, un dispositivo de vibracion, un altavoz, un microfono, un transceptor de television, unos cascos inalambricos, un teclado, un modulo de Bluetooth®, una unidad de radio de frecuencia modulada (FM), una unidad de visualizacion de pantalla de cristal lfquido (LCD - Liquid Crystal Display, en ingles), una unidad de visualizacion de diodos emisores de luz organicos (OLED - Organic Light-Emitting Diode, en ingles), un reproductor de musica digital, un reproductor de medios, un modulo reproductor de videojuegos, un navegador 35 por Internet y/o un modulo de red de area local inalambrica (WLAN - Wireless Local Area Network, en ingles).
Realizaciones
1. Una unidad de transmision / recepcion (WTRU) configurada para implementar seguridad en las comunicaciones inalambricas de evolucion a largo plazo (LTE), comprendiendo la WTRU:
un receptor configurado para recibir un mensaje de estrato de no acceso (NAS), conteniendo el mensaje de NAS 40 parametros de seguridad; y
un procesador configurado para:
determinar si los parametros de seguridad son correctos; y
llevar a cabo un procedimiento de seguridad basado en la determinacion.
2. La WTRU de la realizacion 1, en la que el procesador comprende:
45 un motor controlador de recursos de radio (RRC) de cifrado; y
un motor de NAS de cifrado.
3. La WTRU de cualquiera de las realizaciones 1 -2, en el que el procesador comprende: un motor de cifrado configurado para operar con parametros tanto del RRC como de NAS.
4. La WTRU de la realizacion 1, en la que el procedimiento de seguridad incluye al menos uno de lo siguiente: 50 ignorar el mensaje, borrar el mensaje, informar de un fallo a otra capa de protocolo, iniciar una reautenticacion,
pasar al modo de gestion de movilidad (EMM_Reposo) del sistema de paquetes evolucionado (EPS), pasar al estado EMM_Eliminado del registro, guardar el recuento del numero de fallos, proceder a una reconexion a una red y borrar los parametros de seguridad.
5
10
15
20
25
30
35
40
45
5. Un metodo para implementar seguridad en un dispositivo inalambrico de la evolucion a largo plazo (LTE), comprendiendo el metodo:
recibir un mensaje de estrato de no acceso (NAS), conteniendo el mensaje de NAS parametros de seguridad;
determinar si los parametros de seguridad son correctos; y
llevar a cabo un procedimiento de seguridad basado en la determinacion.
6. El metodo de la realizacion 5, en el que el procedimiento de seguridad incluye al menos uno de lo siguiente: ignorar el mensaje, borrar el mensaje, informar de un fallo a otra capa de protocolo, iniciar una reautenticacion, pasar al modo de gestion de movilidad (EMM_Reposo) del sistema de paquetes evolucionado (EPS), pasar al estado EMM_Eliminado del registro, guardar el recuento del numero de fallos, proceder a una reconexion a una red y borrar los parametros de seguridad.
7. El metodo de cualquiera de las realizaciones 5 - 6, en el que el mensaje de NAS contiene una cabecera de protocolo que incluye un numero de secuencia de NAS.
8. El metodo de cualquiera de las realizaciones 5 - 7, que comprende, ademas: efectuar una deteccion duplicada basada en el numero de secuencia de NAS.
9. El metodo de cualquiera de las realizaciones 5 - 8, en el que el numero de secuencia de NAS funciona como un identificador de transaccion.
10. El metodo de cualquiera de las realizaciones 5 - 8, en el que el numero de secuencia de NAS contiene un periodo de incremento predefinido.
11. El metodo de cualquiera de las realizaciones 5 - 8, en el que el numero de secuencia de NAS contiene un penodo de incremento negociado.
12. El metodo de cualquiera de las realizaciones 5 - 11, en el que el mensaje de NAS esta correlacionado con un valor de RECUENTO.
13. El metodo de la realizacion 12, en el que el valor de RECUENTO esta cifrado (RECUENTO-C).
14. El metodo de cualquiera de las realizaciones 11 - 12, en el que el valor de RECUENTO es para proteccion en integridad (RECUENTO-I).
15. El metodo de cualquiera de las realizaciones 11 - 14, en el que el valor de RECUENTO es una combinacion de un RECUENTO-C y un RECUENTO-I.
16. El metodo de cualquiera de las realizaciones 11 - 15, en el que el valor de RECUENTO comprende: un numero de secuencia de NAS (SN); y
un numero de hipertrama de NAS (HFN).
17. El metodo de cualquiera de las realizaciones 11 - 16, en el que el HFN de NAS es un contador.
18. El metodo de cualquiera de las realizaciones 12 - 17, en el que el valor de RECUENTO se utiliza como dato de entrada a un algoritmo de proteccion en integridad de cifrado.
19. El metodo de la realizacion 12 - 18, en el que el valor de RECUENTO se utiliza como dato de entrada a un algoritmo de proteccion en integridad de descifrado.
20. El metodo de cualquiera de las realizaciones 12 - 19, en el que el valor de RECUENTO se configura antes de la activacion de la seguridad de NAS.
21. El metodo de cualquiera de las realizaciones 12 - 20, en el que el valor de RECUENTO es 32 bits o menos.
22. El metodo de cualquiera de las realizaciones 16 - 21, en el que el SN y el HFN son configurables.
23. El metodo de cualquiera de las realizaciones 12 - 22, en el que el valor de RECUENTO es el numero de secuencia de NAS (SN) y la deteccion duplicada se efectua utilizando el valor de RECUENTO.
24. El metodo de cualquiera de las realizaciones 5 - 23, en el que el mensaje de NAS indica informacion de capacidad de unidad de transmision / recepcion inalambrica (WTRU).
25. El metodo de la realizacion 24, en el que la informacion de capacidad de WTRU indica soporte para el cifrado a nivel de NAS.
5
10
15
20
25
30
35
40
26. Un metodo para implementar seguridad en un dispositivo inalambrico de evolucion a largo plazo (LTE), comprendiendo el metodo:
recibir una unidad de datos de protocolo (PDU) del protocolo de convergencia de datos en paquetes (PDCP), incluyendo la PDU de PDCP parametros de seguridad;
determinar si los parametros de seguridad son correctos; y
llevar a cabo un procedimiento de seguridad basado en la determinacion.
27. El metodo de la realizacion 26, que comprende, ademas:
enviar una indicacion desde la capa del controlador de recursos de radio (RRC) a una capa de PDCP indicando si un mensaje de RRC requiere al menos uno de proteccion en integridad y cifrado.
28. El metodo de cualquiera de las realizaciones 26 -27, que comprende, ademas:
enviar una indicacion desde la capa de RRC a la capa de PDCP indicando que el mensaje de RRC que se va a transmitir no requiere al menos uno de proteccion en integridad y cifrado.
29. El metodo de cualquiera de las realizaciones 27 -28, que comprende, ademas:
indicar a una capa de PDCP que todos los mensajes de RRC seran cifrados o protegidos en integridad.
30. El metodo de cualquiera de las realizaciones 27 -29, que comprende, ademas:
indicar a una capa de PDCP que todos los mensajes de RRC que empiezan con un mensaje de RRC predeterminado estaran cifrados y con proteccion en integridad.
31. El metodo de cualquiera de las realizaciones 27 -30, que comprende, ademas:
establecer una marca de comprobacion de cifrado o de integridad en el RRC para cifrar o comprobar en integridad los mensajes de RRC.
32. El metodo de la realizacion 31, que comprende, ademas:
cifrar los mensajes de RRC en la capa de PDCP antes de transmitirlos como PDU de PDCP y descifrar todas las PDU de PDCP recibidas correspondientes a mensajes de RRC si la marca de cifrado esta configurada, y no realizar cifrado y descifrado si la marca de cifrado no esta configurada.
33. El metodo de cualquiera de las realizaciones 31 - 32, que comprende, ademas:
adjuntar un codigo de autenticacion de mensaje en las PDU de PDCP correspondientes a los mensajees de RRC transmitidos y realizar una comprobacion de integridad en todas las PDU de PDCP recibidas que mapean a los mensajes de RRC si la marca de comprobacion de integridad esta establecida, y no adjuntar ni comprobar la integridad si la marca no esta establecida.
34. El metodo de cualquiera de las realizaciones 27 - 33, que comprende, ademas:
establecer una marca de cifrado y de comprobacion de integridad en el RRC para cifrar y comprobar en integridad los mensajes de RRC.
35. El metodo de la realizacion 34, que comprende, ademas:
cifrar los mensajes de RRC antes de transmitirlos como PDU de PDCP, descifrar las PDU de PDCP recibidas correspondientes a los mensajes de RRC, adjuntar un codigo de autenticacion de mensaje en las PDU de PDCP correspondientes a los mensajes de RRC transmitidos y efectuar una comprobacion de integridad en todas las PDU de PDCP recibidas que mapean a los mensajes de rRc si la marca de cifrado y comprobacion de integridad esta establecida, y no realizar cifrado, descifrado, adicion y comprobacion de integridad si la marca no esta establecida.
36. El metodo de cualquiera de las realizaciones 27 - 35, que comprende, ademas: proporcionar una lista de mensajes de RRC genericos y sus parametros asociados al PDCP.
37. El metodo de cualquiera de las realizaciones 27 - 36, en el que la capa de PDCP no realiza al menos un cifrado o proteccion en integridad de mensajes de RRC a menos que el RRC le indique que lo haga.
38. El metodo de cualquiera de las realizaciones 27 - 37, que comprende, ademas: cifrar el mensaje de RRC; y
5
10
15
20
25
30
35
40
proteger en integridad el mensaje de RRC.
39. El metodo de cualquiera de las realizaciones 27 - 38, en el que el mensaje de RRC es rellenado para conseguir una longitud optima para el cifrado o la proteccion en integridad.
40. El metodo de cualquiera de las realizaciones 26 - 39, que comprende, ademas:
calcular una palabra de codigo de autenticacion de mensaje (MAC) para la proteccion en integridad sobre datos de texto no cifrado, datos cifrados, una cabecera de PDCP parcial o una cabecera de PDCP completa.
41. El metodo de cualquiera de las realizaciones 26 - 40, en el que el cifrado se efectua sobre datos de texto no cifrado parciales.
42. El metodo de cualquiera de las realizaciones 26 - 41, que comprende, ademas: indicar si una carga util ha sido cifrada o protegida en integridad.
43. El metodo de cualquiera de las realizaciones 26 -42, que comprende, ademas:
predefinir una palabra de codigo de autenticacion de mensaje (MAC) en una posicion dentro de la PDU de PDCP, incluyendo la PDU de PDCP una cabecera.
44. El metodo de la realizacion 43, en el que la posicion de la palabra de MAC predefinida es en la cabecera de la PDU de PDCP.
45. El metodo de cualquiera de las realizaciones 26 - 44, en el que el procedimiento de seguridad incluye al menos uno de lo siguiente: ignorar un mensaje de RRC, borrar el mensaje, informar de un fallo en un informe de fallo, guardar el recuento del numero de fallos y borrar los parametros de seguridad.
46. El metodo de la realizacion 45, en el que el informe de fallos incluye la razon del fallo.
47. El metodo de cualquiera de las realizaciones 26 -46, que comprende, ademas: utilizar un numero de hipertrama de PDCP (HFN) para constituir un valor de RECUENTO.
48. Un metodo para implementar seguridad en un dispositivo inalambrico de la evolucion a largo plazo (LTE), comprendiendo el metodo:
recibir un mensaje en una capa de protocolo de convergencia de datos de protocolo (PDCP); descifrar el mensaje; y
efectuar una comprobacion de integridad del mensaje recibido.
49. El metodo de la realizacion 48, en el que la comprobacion de integridad del mensaje recibido se efectua antes del descifrado del mensaje.
50. El metodo de cualquiera de las realizaciones 48 -49, que comprende, ademas:
determinar la posicion de una palabra de codigo de autenticacion del mensaje (MAC) dentro del mensaje recibido.
51. El metodo de cualquiera de las realizaciones 48 - 50, que comprende, ademas: determinar si el cifrado y la proteccion en integridad son satisfactorios.
52. El metodo de cualquiera de las realizaciones 48 - 51, que comprende, ademas:
indicar el estado de seguridad del mensaje recibido a una capa de controlador de recursos de radio (RRC).
53. El metodo de cualquiera de las realizaciones 48 - 52, que comprende, ademas:
enviar una indicacion desde la capa de PDCP a una capa de controlador de recursos de radio (RRC) indicando si la comprobacion de la integridad ha fallado en un mensaje de RRC recibido.
54. El metodo de cualquiera de las realizaciones 48 - 53, que comprende, ademas:
enviar una indicacion desde la capa de PDCP a una capa de controlador de recursos de radio (RRC) indicando si la comprobacion de la integridad ha tenido exito en un mensaje de RRC recibido.
55. El metodo de cualquiera de las realizaciones 48 - 54, que comprende, ademas:
5
10
15
20
25
30
35
40
enviar una indicacion desde la capa de PDCP a la capa de RRC de que la comprobacion de la integridad ha fallado solo si se produce un numero de fallos predeterminado en un intervalo de tiempo predeterminado o numero de mensajes de RRC recibidos.
56. El metodo de cualquiera de las realizaciones 48 - 55, que comprende, ademas:
comprobar una palabra de codigo de autenticacion de mensaje (MAC) en una capa de controlador de recursos de radio (RRC) del PDCP cuando el mensaje recibido es un mensaje codificado ASN.1.
57. El metodo de cualquiera de las realizaciones 48 - 56, en el que implementar seguridad incluye al menos uno de lo siguiente: ignorar el mensaje, borrar el mensaje, informar de un fallo en un informe de fallos, guardar el recuento del numero de fallos y borrar los parametros de seguridad.
58. El metodo de la realizacion 57, en el que el informe de fallos incluye una razon para el fallo.
59. Un metodo para el manejo de claves en una unidad de transmision / recepcion (WTRU) tras la transicion del modo EMM_Conectado al modo EMM_Reposo, comprendiendo el metodo:
indicar la transicion a una entidad de almacenamiento en la WTRU; y borrar un primer conjunto de claves.
60. El metodo de la realizacion 59, que comprende, ademas: guardar las claves de seguridad de NAS y las claves de ASME.
61. El metodo de cualquiera de las realizaciones 59 - 60, que comprende, ademas: borrar las claves de seguridad de NAS y las claves de ASME.
62. El metodo de cualquiera de las realizaciones 59 - 61, en el que la indicacion se proporciona mediante un estrato de no acceso (NAS).
63. El metodo de cualquiera de las realizaciones 59 - 62, en el que la indicacion se proporciona mediante un estrato de acceso (AS).
64. El metodo de cualquiera de las realizaciones 59 - 63, en el que la indicacion se proporciona utilizando primitivas predeterminadas.
65. El metodo de cualquiera de las realizaciones 59 - 65, en el que la indicacion se proporciona cuando un e-NB de servicio cambia mientras se encuentra en modo EMM_Reposo.
66. El metodo de cualquiera de las realizaciones 59 - 66, en el que el primer conjunto de claves incluye al menos una de las siguiente: KeNB, Krrc enc, KRRCint y Kup enc.
67. El metodo de cualquiera de las realizaciones 59 - 67, en el que la entidad de almacenamiento borra Krrc enc, Krrc int y Kup enc tras la recepcion de la indicacion.
68. El metodo de cualquiera de las realizaciones 59 - 68, en el que la entidad de almacenamiento borra KeNB tras la recepcion de la indicacion.
69. El metodo de cualquiera de las realizaciones 59 -69, que comprende, ademas: generar un segundo conjunto de claves tras la recepcion de la indicacion.
70. El metodo de cualquiera de las realizaciones 59 - 70, en el que la indicacion indica un cambio en la celula de servicio.
71. El metodo de cualquiera de las realizaciones 59 - 71, en el que el primer conjunto de claves incluye un valor de temporizador.
72. El metodo de cualquiera de las realizaciones 5 - 72, que comprende, ademas: recibir claves desde una capa de NAS o desde un USIM.
73. El metodo de la realizacion 72, en el que las claves recibidas son pasadas entre la capa (NAS) a un RRC / PDCP utilizando primitivas predeterminadas.
74. El metodo de cualquiera de las realizaciones 73 - 75, en el que las claves recibidas son el PDCP utilizando primitivas predeterminadas.
de estrato de no acceso pasadas entre el RRC y

Claims (16)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    REIVINDICACIONES
    1. Metodo para llevar a cabo un procedimiento de seguridad de estrato de no acceso, NAS en comunicaciones inalambricas, comprendiendo el metodo:
    recibir (305), en una unidad de transmision / recepcion, WTRU, un mensaje de NAS que comprende un numero de secuencia de NAS, SN de NAS, (410) y una cabecera de protocolo (400);
    efectuar una comprobacion de integridad (310) en el mensaje de NAS utilizando un valor de RECUENTO como dato de entrada a un algoritmo de integridad, en el que el valor de RECUENTO comprende un SN de NAS (410) y un HFN de NAS que puede ser un contador que se incrementa en uno por cada numero predeterminado de incrementos de SN de NAS;
    en repuesta al mensaje de NAS recibido (315), fallar la comprobacion de integridad (310), ignorando el mensaje de NAS; y
    en respuesta al mensaje de NAS recibido, borrar la comprobacion de integridad (310), procesando (360) el mensaje de NAS.
  2. 2. El metodo de la reivindicacion 1, en el que el mensaje de NAS incluye ademas una cabecera (400) que incluye ademas un discriminador de protocolo (420), un octeto de tipo de mensaje, un identificador de transaccion, TI (430) y un sub-discriminador de protocolo.
  3. 3. El metodo de la reivindicacion 1, en el que el SN de NAS (410) se encuentra en la cabecera de protocolo recibida (400) del mensaje de NAS.
  4. 4. El metodo de la reivindicacion 1, en el que el SN de NAS (410) se recibe como contenido de un elemento de informacion, IE.
  5. 5. El metodo de la reivindicacion 2, en el que el TI (430) funciona como el SN de NAS (410).
  6. 6. El metodo de la reivindicacion 1, en el que el SN de NAS (410) tiene un periodo de incremento predefinido o un periodo de incremento negociado.
  7. 7. El metodo de la reivindicacion 1, en el que el valor de RECUENTO se incrementa de manera predefinida o de manera negociada.
  8. 8. El metodo de la reivindicacion 1, en el que ignorar el mensaje de NAS incluye al menos uno de: ignorar (325) el mensaje de NAS, borrar (325) el mensaje de NAS, informar (330) de un fallo a otra capa de protocolo, iniciar (335) una reautenticacion, pasar (340) al modo de EMM_Reposo de gestion de movilidad del sistema de paquetes evolucionado, EPS, pasar (340) al estado EMM_Eliminado del registro, guardar (345) un recuento del numero de fallos, proceder a la reconexion (350) a una red, y borrar (355) el SN de NAS.
  9. 9. Una unidad de transmision / recepcion inalambrica, WTRU (710) configurada para llevar a cabo un procedimiento de seguridad de estrato de no acceso, NAS en comunicaciones inalambricas, comprendiendo la WTRU (710):
    un receptor (730) configurado para recibir (305) un mensaje de NAS que comprende un numero de secuencia de NAS, sN de NAS, (410) y una cabecera de protocolo (400);
    un procesador (740) configurado para efectuar una comprobacion de integridad (310) en el mensaje de NAS utilizando un valor de RECUENTO como dato de entrada a un algoritmo de integridad, en el que el valor de RECUENTO incluye un SN de NAS (410), y un HFN de NAS que puede ser un contador que se incrementa en uno por cada numero predeterminado de incrementos del SN de nAS;
    en respuesta al mensaje de NAS (315) de fallo en la comprobacion de integridad (310), el procesador (740) esta configurado ademas para ignorar el mensaje de NAS; y
    en respuesta al mensaje de NAS de borrar la comprobacion de integridad (310), el procesador (740) esta configurado ademas para procesar (360) el mensaje de NAS.
  10. 10. La WTRU de la reivindicacion 9, en la que el mensaje de NAS incluye ademas una cabecera de mensaje (400) que comprende un discriminador de protocolo (420), un octeto de tipo de mensaje, un identificador de transaccion, TI (430) y un discriminador de protocolo.
  11. 11. La WTRU de la reivindicacion 9, en la que el SN de NAS (410) esta en la cabecera del protocolo recibida (400) del mensaje de NAS.
  12. 12. La WTRU de la reivindicacion 9, en la que el SN de NAS (410) se recibe como contenido de un elemento de informacion, IE.
  13. 13. La WTRU de la reivindicacion 10, en la que el TI (430) funciona como el SN de NAS (410).
  14. 14. La WTRU de la reivindicacion 11, en la que el SN de NAS (410) tiene un periodo de incremento predefinido o un periodo de incremento negociado.
  15. 15. La WTRU de la reivindicacion 9, en la que el valor de RECUENTO se incrementa de manera predefinida o de 5 manera negociada.
  16. 16. La WTRU de la reivindicacion 9, en la que ignorar el mensaje de NAS incluye al menos uno de: ignorar (325) el mensaje de NAS, borrar (325) el mensaje de NAS, informar (330) de un fallo a otra capa de protocolo, iniciar (335) una reautenticacion, pasar (340) al modo EMM_Reposo de Gestion de movilidad del sistema de paquetes evolucionado, EPS, pasar (340) al estado EMM_Eliminado del registro, guardar (345) un registro del numero de
    10 fallos, proceder a la reconexion (350) a una red, y borrar (355) el SN de NAS.
ES08796196.7T 2007-07-18 2008-07-16 Métodos y aparato para implementar seguridad de estrato de no acceso (NAS) en un dispositivo inalámbrico de la Evolución a largo plazo Active ES2573257T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US95048607P 2007-07-18 2007-07-18
US950486P 2007-07-18
PCT/US2008/070115 WO2009012281A2 (en) 2007-07-18 2008-07-16 Method and apparatus to implement non-access stratum (mas) security in a long term evolution wireless device

Publications (1)

Publication Number Publication Date
ES2573257T3 true ES2573257T3 (es) 2016-06-06

Family

ID=40260345

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08796196.7T Active ES2573257T3 (es) 2007-07-18 2008-07-16 Métodos y aparato para implementar seguridad de estrato de no acceso (NAS) en un dispositivo inalámbrico de la Evolución a largo plazo

Country Status (16)

Country Link
US (2) US8699711B2 (es)
EP (2) EP2172069B1 (es)
JP (2) JP2010534959A (es)
KR (4) KR101468352B1 (es)
CN (2) CN101755469B (es)
AR (1) AR067595A1 (es)
AU (1) AU2008276061B2 (es)
BR (1) BRPI0812675B1 (es)
CA (1) CA2693185C (es)
ES (1) ES2573257T3 (es)
HK (1) HK1143267A1 (es)
IL (1) IL203345A (es)
MY (1) MY152794A (es)
RU (1) RU2446626C2 (es)
TW (3) TWI520539B (es)
WO (1) WO2009012281A2 (es)

Families Citing this family (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PT2087634T (pt) * 2006-11-01 2016-10-26 ERICSSON TELEFON AB L M (publ) Sistemas de telecomunicações e cifragem de mensagens de controlo em sistemas deste tipo
KR101486352B1 (ko) 2007-06-18 2015-01-26 엘지전자 주식회사 무선 통신 시스템의 단말에서의 상향링크 동기 상태 제어방법
KR101341515B1 (ko) 2007-06-18 2013-12-16 엘지전자 주식회사 무선 통신 시스템에서의 반복 전송 정보 갱신 방법
KR101490253B1 (ko) 2007-08-10 2015-02-05 엘지전자 주식회사 무선 통신 시스템에서의 제어정보 전송 및 수신 방법
KR101392697B1 (ko) * 2007-08-10 2014-05-19 엘지전자 주식회사 이동통신 시스템에서의 보안 오류 검출방법 및 장치
EP2028890B1 (en) * 2007-08-12 2019-01-02 LG Electronics Inc. Handover method with link failure recovery, wireless device and base station for implementing such method
CN101378591B (zh) 2007-08-31 2010-10-27 华为技术有限公司 终端移动时安全能力协商的方法、系统及装置
CN102916808B (zh) 2007-09-17 2015-11-18 爱立信电话股份有限公司 电信系统中的方法和设备
KR101591824B1 (ko) 2007-09-18 2016-02-04 엘지전자 주식회사 무선 통신 시스템에서의 폴링 과정 수행 방법
KR101513033B1 (ko) 2007-09-18 2015-04-17 엘지전자 주식회사 다중 계층 구조에서 ＱｏＳ를 보장하기 위한 방법
CN101399767B (zh) 2007-09-29 2011-04-20 华为技术有限公司 终端移动时安全能力协商的方法、系统及装置
WO2009043622A1 (en) * 2007-10-02 2009-04-09 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for security activation detection in a telecommunication system
US8532614B2 (en) 2007-10-25 2013-09-10 Interdigital Patent Holdings, Inc. Non-access stratum architecture and protocol enhancements for long term evolution mobile units
CN105450663B (zh) 2007-12-06 2019-01-29 艾利森电话股份有限公司 用于在移动通信网络中更新ue能力信息的方法
KR101594359B1 (ko) 2008-01-31 2016-02-16 엘지전자 주식회사 랜덤 접속에서 백오프 정보를 시그널링하는 방법
WO2009096731A2 (en) 2008-01-31 2009-08-06 Lg Electronics Inc. Method for signaling back-off information in random access
US8737294B2 (en) * 2008-08-11 2014-05-27 Via Telecom Co., Ltd. Apparatus and method for handling RLC retransmission failure according to activation status of security mode
EP2315373B1 (en) * 2008-08-15 2020-10-07 Samsung Electronics Co., Ltd. Non-access stratum protocol operation supporting method in a mobile telecommunication system, and the system thereof
JP4505528B2 (ja) * 2008-09-22 2010-07-21 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法
US9232452B2 (en) * 2008-10-31 2016-01-05 Htc Corporation Method of handling an inter rat handover in wireless communication system and related communication device
KR101475349B1 (ko) * 2008-11-03 2014-12-23 삼성전자주식회사 이동 통신 시스템에서 단말 보안 능력 관련 보안 관리 방안및 장치
US8611306B2 (en) * 2009-01-12 2013-12-17 Qualcomm Incorporated Context fetching after inter-system handover
KR20110119785A (ko) 2009-02-16 2011-11-02 텔레폰악티에볼라겟엘엠에릭슨(펍) 비-암호화 망 동작 해결책
JP5304345B2 (ja) * 2009-03-11 2013-10-02 富士通株式会社 コンテンツ処理装置、コンテンツ処理システム、およびコンテンツ処理プログラム
CN101931951B (zh) * 2009-06-26 2012-11-07 华为技术有限公司 密钥推演方法、设备及系统
GB2472580A (en) 2009-08-10 2011-02-16 Nec Corp A system to ensure that the input parameter to security and integrity keys is different for successive LTE to UMTS handovers
US20110055013A1 (en) * 2009-08-28 2011-03-03 Ayman Hammad Secure alert system and method
CN102025685B (zh) 2009-09-21 2013-09-11 华为技术有限公司 认证处理方法及装置
KR101831448B1 (ko) * 2010-02-02 2018-02-26 엘지전자 주식회사 이동 통신 시스템에서 ｐｄｃｐ 기능을 선택적으로 적용하는 방법
JP2012044325A (ja) * 2010-08-16 2012-03-01 Ntt Docomo Inc 移動通信方法及び無線基地局
US9179303B2 (en) * 2010-11-17 2015-11-03 Qualcomm Incorporated Methods and apparatus for transmitting and receiving secure and non-secure data
WO2012078092A2 (en) * 2010-12-10 2012-06-14 Telefonaktiebolaget L M Ericsson (Publ) Enabling and disabling integrity protection for data radio bearers
US9265087B2 (en) 2011-03-31 2016-02-16 Lg Electronics Inc. Method for user equipment setting security with network in wireless communication system and apparatus for same
KR101948348B1 (ko) 2011-04-01 2019-02-14 인터디지탈 패튼 홀딩스, 인크 네트워크에 대한 연결성을 제어하는 방법 및 장치
KR101929307B1 (ko) 2011-04-11 2018-12-17 삼성전자 주식회사 Ｃｓｇ 셀에서 단말이 셀 재선택 우선 순위를 효율적으로 제어하는 방법 및 장치
KR101240552B1 (ko) * 2011-09-26 2013-03-11 삼성에스디에스 주식회사 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법
KR20140116090A (ko) * 2011-12-08 2014-10-01 인터디지탈 패튼 홀딩스, 인크 하이 레이트 이중 대역 셀룰러 통신
EP2688328B1 (en) 2012-07-17 2018-10-03 Google Technology Holdings LLC Security in wireless communication system and device
US9119062B2 (en) * 2012-10-19 2015-08-25 Qualcomm Incorporated Methods and apparatus for providing additional security for communication of sensitive information
US20150319621A1 (en) * 2012-10-29 2015-11-05 Nokia Solutions And Networks Oy Method, Apparatus and Computer Program Product for Allocation of a Shared Resource
US10117224B2 (en) 2013-09-20 2018-10-30 Qualcomm Incorporated MAC subheader for D2D broadcast communication for public safety
CN104798320B (zh) * 2013-11-11 2018-11-09 华为技术有限公司 数据传输方法及装置
EP3108679B1 (en) * 2014-02-21 2017-05-10 Telefonaktiebolaget LM Ericsson (publ) Method and devices for protection of control plane functionality
US9338646B2 (en) 2014-04-22 2016-05-10 Electronics And Telecommunications Research Institute Method for transmitting and receiving fake communication data and terminal performing the same
CN104125570B (zh) * 2014-07-02 2018-03-27 大唐移动通信设备有限公司 一种信令消息完整性检查的方法及装置
KR102202894B1 (ko) * 2014-08-28 2021-01-14 삼성전자 주식회사 이동 통신 네트워크에서 패킷 손실 관리 방법
US9843946B2 (en) * 2015-01-28 2017-12-12 Mediatek Inc. Apparatuses and methods for reducing call recovery time associated with a cell update procedure
US20160316373A1 (en) * 2015-04-27 2016-10-27 Qualcomm Incorporated Techniques for managing security mode command (smc) integrity failures at a user equipment (ue)
US9992810B2 (en) * 2015-08-26 2018-06-05 Samsung Electronics Co., Ltd Method for providing integrity protection in a dual SIM dual standby device
CN117354802A (zh) 2015-11-02 2024-01-05 瑞典爱立信有限公司 无线通信
US10623990B2 (en) 2015-12-15 2020-04-14 Lg Electronics Inc. User equipment and method for transmitting data, and network node and method for receiving data
US10028307B2 (en) 2016-01-13 2018-07-17 Qualcomm Incorporated Configurable access stratum security
CN105629425A (zh) * 2016-03-28 2016-06-01 福建福光光电科技有限公司 高分辨率、低畸变日夜两用定焦镜头
US10243929B2 (en) * 2016-03-30 2019-03-26 Qualcomm Incorporated Uplink control channel scheduling for jamming resilience
JP6278054B2 (ja) * 2016-03-31 2018-02-14 富士通株式会社 無線通信システム、無線局および基地局
JP6679751B2 (ja) * 2016-04-01 2020-04-15 アイディーエーシー ホールディングス インコーポレイテッド サービススライス選択および分離のための方法
US10334435B2 (en) 2016-04-27 2019-06-25 Qualcomm Incorporated Enhanced non-access stratum security
EP3453199B1 (en) 2016-05-02 2021-07-07 Telefonaktiebolaget LM Ericsson (PUBL) Authenticating a message in a wireless communication system
US20170013651A1 (en) * 2016-09-22 2017-01-12 Mediatek Singapore Pte. Ltd. NAS Security And Handling Of Multiple Initial NAS Messages
JP7085534B2 (ja) * 2016-10-30 2022-06-16 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおけるｅｍｍモードを決定する方法、及びこのための装置
US11064555B2 (en) * 2016-11-09 2021-07-13 Lg Electronics Inc. Method for transmitting RRC message and wireless device
CN113630773B (zh) * 2017-01-24 2023-02-14 华为技术有限公司 安全实现方法、设备以及系统
CN110313164B (zh) * 2017-03-19 2022-07-26 上海朗帛通信技术有限公司 一种用于上行传输的方法和装置
US10171993B2 (en) * 2017-05-05 2019-01-01 Nokia Technologies Oy Identity request control for user equipment
WO2018230974A1 (en) 2017-06-14 2018-12-20 Samsung Electronics Co., Ltd. Method and user equipment for handling of integrity check failures of pdcp pdus
CN109246705B (zh) * 2017-06-15 2020-10-23 维沃移动通信有限公司 一种数据无线承载完整性保护配置方法、终端及网络设备
US11997738B2 (en) * 2017-06-16 2024-05-28 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for the handling of data radio bearer integrity protection failure in NR
KR101988849B1 (ko) * 2017-08-30 2019-06-13 에스케이텔레콤 주식회사 네트워크장치 및 네트워크장치의 메시지 무결성 체크 방법
CN109803263A (zh) * 2017-11-17 2019-05-24 华为技术有限公司 一种安全保护的方法及装置
CN107948972B (zh) * 2017-12-27 2021-03-09 Oppo广东移动通信有限公司 数据业务的恢复方法及相关产品
US10813161B2 (en) * 2018-03-06 2020-10-20 Mediatek Singapore Pte. Ltd. Apparatuses and methods for protection of an initial non-access stratum (NAS) message
CN110536415B (zh) * 2018-05-23 2020-11-20 大唐移动通信设备有限公司 一种nas消息的处理方法、集群终端和集群核心网
CN110830421B (zh) * 2018-08-10 2022-07-29 华为技术有限公司 数据传输方法和设备
CN108990096B (zh) * 2018-09-03 2021-07-06 四川酷比通信设备有限公司 移动终端的nas消息处理方法、系统及移动终端
WO2020049812A1 (ja) 2018-09-07 2020-03-12 日本電気株式会社 分散ユニット、無線端末、及びこれらの方法
WO2020060871A1 (en) * 2018-09-19 2020-03-26 Intel Corporation Protection of initial non-access stratum protocol message in 5g systems
EP3846519B1 (en) * 2019-04-26 2022-07-06 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method or device for integrity protection
WO2021142808A1 (zh) * 2020-01-17 2021-07-22 Oppo广东移动通信有限公司 设备会话密钥标识字段的填充方法及相关产品
US11310661B2 (en) * 2020-02-14 2022-04-19 Mediatek Inc. Security key synchronization method and associated communications apparatus

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI107486B (fi) * 1999-06-04 2001-08-15 Nokia Networks Oy Autentikaation ja salauksen järjestäminen matkaviestinjärjestelmässä
DE10008148A1 (de) * 2000-02-22 2001-08-23 Bosch Gmbh Robert Verfahren zum Betreiben eines Mobilfunknetzes
FR2808948B1 (fr) * 2000-05-12 2006-03-03 Ibm Corp Internat Business Mac Systeme et methode pour authentifier de maniere unique chaque reproduction d'un groupe de documents electroniques
FI111423B (fi) * 2000-11-28 2003-07-15 Nokia Corp Järjestelmä kanavanvaihdon jälkeen tapahtuvan tietoliikenteen salauksen varmistamiseksi
FI112995B (fi) * 2001-01-16 2004-02-13 Nokia Corp Virheellisen datan käsittely pakettivälitteistä tiedonsiirtoa tarjoavassa tietoliikennejärjestelmässä
FI112138B (fi) 2001-02-09 2003-10-31 Nokia Corp Kehittynyt menetelmä ja järjestely tiedon siirtämiseksi pakettiradiopalvelussa
US7246233B2 (en) * 2001-12-05 2007-07-17 International Business Machines Corporation Policy-driven kernel-based security implementation
AU2003259050A1 (en) 2002-08-09 2004-02-25 Interdigital Technology Corporation Efficient memory allocation in a wireless transmit/receiver unit
KR20050056164A (ko) * 2002-10-03 2005-06-14 마쯔시다덴기산교 가부시키가이샤 키 이벤트 제어 장치
US7251227B2 (en) * 2002-10-04 2007-07-31 M-Stack Limited Access stratum manager
KR100802619B1 (ko) * 2002-11-07 2008-02-13 엘지전자 주식회사 무선 링크 제어 프로토콜에 따르는 수신기에서의 알엘씨데이터 수신 윈도우 처리 방법
CA2428236A1 (en) * 2003-05-08 2004-11-08 M-Stack Limited Apparatus and method of handling universal terrestrial radio access network radio resource control connecting messages in universal mobile telecommunications system user equipment
US6987985B2 (en) 2003-06-06 2006-01-17 Interdigital Technology Corporation Wireless communication components and methods for multiple system communications
ES2304496T3 (es) * 2003-07-31 2008-10-16 Nokia Siemens Networks Gmbh Procedimiento de gestion de recursos de radio comun en una red telefonica celular multi-rat.
WO2005046263A1 (en) 2003-10-30 2005-05-19 Interdigital Technology Corporation Architecture for implementation of radio access bearer manager (rabm) and packet data convergence protocol (pdcp) process
WO2005055501A2 (en) 2003-12-01 2005-06-16 Interdigital Technology Corporation Method and apparatus for notifying unavailability of broadcast/multicast services
US20050176431A1 (en) * 2004-02-11 2005-08-11 Telefonaktiebolaget L M Ericsson (Publ) Method for handling key sets during handover
US20050286526A1 (en) * 2004-06-25 2005-12-29 Sood Sanjeev H Optimized algorithm for stream re-assembly
JP2006217100A (ja) 2005-02-02 2006-08-17 Nec Corp 復号処理システム及びその方法並びにそれを用いた移動通信システム
US7929410B2 (en) 2005-06-29 2011-04-19 Interdigital Technology Corporation Protocol engine for processing data in a wireless transmit/receive unit
TW200818806A (en) 2005-06-29 2008-04-16 Interdigital Tech Corp Protocol engine for processing data in a wireless transmit/receive unit
KR101213285B1 (ko) 2006-01-04 2012-12-17 삼성전자주식회사 이동통신 시스템에서 아이들모드 단말기의 세션 설정 프로토콜 데이터를 전송하는 방법 및 장치
WO2007108660A1 (en) * 2006-03-22 2007-09-27 Lg Electronics Inc. Asymmetric cryptography for wireless systems
US9106409B2 (en) * 2006-03-28 2015-08-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for handling keys used for encryption and integrity
US20080051084A1 (en) * 2006-08-23 2008-02-28 Alessio Casati Telecommunications system and method for early transmission of data

Also Published As

Publication number Publication date
WO2009012281A2 (en) 2009-01-22
BRPI0812675B1 (pt) 2020-04-14
JP2010534959A (ja) 2010-11-11
BRPI0812675A2 (pt) 2014-12-23
TWI497965B (zh) 2015-08-21
KR20100049076A (ko) 2010-05-11
US8699711B2 (en) 2014-04-15
KR101560848B1 (ko) 2015-10-20
CN104105091A (zh) 2014-10-15
US9420468B2 (en) 2016-08-16
AU2008276061B2 (en) 2012-11-08
AR067595A1 (es) 2009-10-14
EP2172069B1 (en) 2016-03-30
HK1143267A1 (en) 2010-12-24
KR101605297B1 (ko) 2016-03-21
US20140181899A1 (en) 2014-06-26
CN101755469A (zh) 2010-06-23
CN101755469B (zh) 2014-07-23
TW200920053A (en) 2009-05-01
RU2446626C2 (ru) 2012-03-27
KR20130114258A (ko) 2013-10-16
KR20100043267A (ko) 2010-04-28
EP2172069A2 (en) 2010-04-07
CA2693185C (en) 2013-11-05
JP2013225863A (ja) 2013-10-31
MY152794A (en) 2014-11-28
RU2010105685A (ru) 2011-08-27
AU2008276061A1 (en) 2009-01-22
TW201244434A (en) 2012-11-01
KR20150041166A (ko) 2015-04-15
EP2579635A2 (en) 2013-04-10
WO2009012281A3 (en) 2009-07-09
US20090025060A1 (en) 2009-01-22
KR101102708B1 (ko) 2012-01-05
KR101468352B1 (ko) 2014-12-03
TW201608861A (zh) 2016-03-01
TWI520539B (zh) 2016-02-01
EP2579635A3 (en) 2013-08-07
CA2693185A1 (en) 2009-01-22
IL203345A (en) 2015-01-29

Similar Documents

Publication Publication Date Title
ES2573257T3 (es) Métodos y aparato para implementar seguridad de estrato de no acceso (NAS) en un dispositivo inalámbrico de la Evolución a largo plazo
JP6240233B2 (ja) Ｌｔｅモバイル装置において非アクセス層（ｎａｓ）セキュリティを可能にする方法および装置
AU2013200612A1 (en) Method and apparatus to implement security in a long term evolution wireless device.