Generación de claves criptográficas.

Un método para generar una clave criptográfica (120) para proteger una comunicación móvil entre dos entidades(202,

204), en donde el método se lleva a cabo por la primera entidad (202, 302) como parte de un procedimientode Autentificación y Acuerdo de Claves (AKA) en base a un protocolo de AKA de UMTS iniciado por la segundaentidad (204, 304), el método que está caracterizado por los pasos de:

- proporcionar (306) al menos dos parámetros (106, 108), en donde el primer parámetro (106) comprende ose deriva de un conjunto de claves criptográficas (110, 112) que se han calculado por la primera entidad (202)ejecutando el procedimiento de AKA y el segundo parámetro comprende o se deriva de un testigo (116) quetiene un valor diferente cada vez que se inicia el procedimiento de AKA por la segunda entidad (204, 304)para la primera entidad (202, 302); y

- aplicar (308) una función de derivación de clave para generar una clave criptográfica (120) en base a losparámetros proporcionados (106, 108);

en donde el testigo (116) comprende un O exclusivo de un número de secuencia y una Clave deAnonimato , en donde el SQN indica el número de veces que el procedimiento de AKA se ha iniciado por lasegunda entidad (204, 304) para la primera entidad (202, 302), y

en donde la AK es una clave criptográfica producida por una función de generación de claves f5 que usa undesafío aleatorio conforme al protocolo de AKA de UMTS.

Generación de claves criptográficas

Campo técnico

La presente invención de manera general se refiere a una técnica para generar claves criptográficas. Particularmente, la invención se refiere a una técnica de generación de claves criptográficas que proporciona un alto nivel de seguridad.

Antecedentes El protocolo de Autentificación y Acuerdo de Claves (AKA) es un protocolo basado en desafío-respuesta que usa criptografía simétrica. Las metas principales de AKA incluyen autentificación mutua mediante dos entidades que comunican una con otra y el establecimiento de claves criptográficas para proteger la comunicación intercambiada entre medias. Una variante de AKA es la AKA de UMTS, incluida en la arquitectura de seguridad estandarizada por el 3GPP para redes de comunicación móvil de 3G en la Especificación Técnica TS 33.102 de 3G.

El concepto básico de AKA de UMTS se muestra en la Fig. 1. Con referencia a esta figura, el protocolo de AKA de UMTS se ejecuta entre un equipo de usuario (UE) y una entidad de red (NE) . La entidad de red inicia la AKA enviando una petición de autentificación de usuario al UE. Junto con la petición, un desafío aleatorio, o código aleatorio (RAND) , y un Testigo de Autentificación (AUTN) se envían al UE. Tras la recepción del RAND y el AUTN, el UE, entre otras cosas, calcula una Clave de Cifrado (CK) y una Clave de Integridad (IK) y entonces las usa para funciones de cifrado e integridad.

El 3GPP también está emprendiendo la estandarización de las denominadas redes de comunicación “más allá de 3G”. La Evolución de Arquitectura de Sistema (SAE) y la Evolución de Largo Plazo (LTE) son dos aspectos estrechamente relacionados de la red más allá de 3G. Comparado con las redes 3G convencionales, una red basada en SAE/LTE puede imponer mayores requisitos o/ de más seguridad. Por ejemplo, se pueden necesitar más claves criptográficas para asegurar la comunicación a diferentes niveles. El 3GPP ha recomendado, en otro documento relacionado con el estándar, el TR 33.821 del 3GPP, una jerarquía de claves para derivar más claves criptográficas para uso en SAE/LTE.

La Fig. 2 muestra esta jerarquía de claves. En lo más alto de la jerarquía está una clave K, una clave criptográfica de largo plazo compartida entre el Módulo Universal de Identidad de Abonado (USIM) del UE y el Centro de Autentificación (AuC) que reside en la red. Un nivel más abajo está un par de claves criptográficas CK e IK que se derivan por el UE, particularmente por el USIM del mismo, de una misma manera o similar que la operación de AKA del UMTS mencionada anteriormente. Más abajo en la jerarquía está una clave KASME que se deriva por el UE de la CK, IK, y, si es necesario, algunos otros parámetros. Una vez derivada, la KASME se transfiere desde el AuC a la red de acceso, particularmente a la Entidad de Gestión de Seguridad de Acceso (ASME) de la red SAE/LTE, y entonces se comparte entre el UE y la red. Cuando la red de acceso está basada en tecnología LTE, las funcionalidades de la ASME se manejan por una Entidad de Gestión de Movilidad (MME) .

La clave KASME, y las claves “por debajo” de ella en la jerarquía, se pueden derivar aplicando una cierta función criptográfica. Por ejemplo,

KASME = KDF (CK || IK, 0x02 || PLMN_ID || < otro_parámetro> )

donde KDF se basa en una función de derivación de clave (KDF) de Arquitectura de Inicialización Genérica (GBA) . Una KDF de GBA se especifica en la TS 33.220 de 3G.

La KDF de GBA puede hacer uso de funciones para generar claves criptográficas tales como las funciones para generar claves de Algoritmo de Generación de Claves Seguras (SHA) . Entre las muchas funciones de generación de claves SHA, SHA-256 es una variante altamente segura dado que se considera resistente a colisión y actúa como una función pseudoaleatoria. Como sugiere su nombre, SHA-256 es una función de generación de claves de Algoritmo de Generación de Claves Seguras con una longitud de resumen (salida) de 256 bits. El PLMN_ID es un identificador de la red que sirve al UE.

Se ha comprobado que, para lograr un alto nivel de seguridad, no es suficiente basar la función KDF de GBA principalmente en CK e IK solamente. La razón fundamental para esto es el riesgo de que un UE dado pudiera obtener la misma CK dos veces, o dos UE diferentes puedan obtener la misma CK. En tales casos, la “unicidad” de las entradas a la KDF es indeterminada, y puede ocurrir una colisión entre diferentes UE (que usan la misma KASME) .

Como observación general, mientras que es cierto que KDF (x) produce la misma clave que KDF (y) si x = y, lo inverso puede no mantenerse siempre. Es decir, incluso si x -y, puede ocurrir todavía que KDF (x) = KDF (y) . No obstante, este es un suceso improbable dado que la KDF se recomienda que esté basada en SHA-256 que, como se mencionó, se ha diseñado para ser resistente a colisiones. De esta manera, para la técnica descrita en la presente memoria, se puede suponer de manera segura que KDF (x) = KDF (y) sí y solo sí x = y. Esta suposición permite que la técnica descrita en la presente memoria esté centrada en asegurar la “unicidad” de las entradas a la KDF. El órgano de estandarización de la especificación de la KDF de GBA (ETSI/SAGE, el Grupo de Expertos de Algoritmo Especial) ha señalado el problema anterior y recomendado incluir la Identidad de Usuario Privado del UE (IMPI) en <otro_parámetro> para evitar colisiones entre diferentes UE. Como recomendación adicional, un código aleatorio tal como el RAND también se puede incluir en <otro_parámetro>. Esto se describe en una declaración de coordinación desde ETSI/SAGE a SA3 del 3GPP (en el número de documento S3 – 030219 del 3GPP) .

No obstante, se ha encontrado que las recomendaciones anteriores aún pueden no garantizar la “unicidad” de las entradas a la KDF. Esto se puede ver a partir del análisis de más delante de la propiedad de seguridad de la función KDF de GBA y su uso en SAE/LTE para uno y el mismo UE (por ejemplo una y la misma IMPI) .

En primer lugar, se considera la siguiente construcción básica:

KDF (CK, IMPI) .

Dado que se ha supuesto que IMPI = IMPI’ (cuando el UE está fijo) , esta construcción básica conducirá a colisión para dos entradas (CK, IMPI) , (CK’, IMPI’) si y solo sí CK = CK’.

En segundo lugar, se considera otra construcción, la cual es más cercana a la KDF de GBA real:

KDF (CK || IK, IMPI) .

No obstante, incluir IK dentro de las entradas no cambia la propiedad de colisión anterior como uno pudiera creer al principio. Es decir, KDF (CK || IK, IMPI) será igual a KDF (CK’ || IK’, IMPI) sí y solo sí CK = CK’. Para comprender por qué incluir IK no ayudaría, es necesario considerar cómo se producen CK e IK por el algoritmo criptográfico ejecutado en el UE.

El algoritmo criptográfico del lado de UE típico es el algoritmo Milenage el cual se muestra en la Fig. 9. En la Fig. 9, Ek indica el algoritmo Estándar de Cifrado Avanzado (AES) , también conocido como el algoritmo Rijndael, que usa la clave K (almacenada en el AuC y el USIM del UE) . Consideremos ahora qué ocurre si CK = CK’. Dado que el AES es una permutación (una asignación uno a uno) , esto implica que el valor intermedio (que ocurre en la flecha gruesa) se determina únicamente por la salida de f3 que pasa a ser CK. Pero esto implica que el valor de la fecha gruesa cuando se produce la CK debe ser el mismo que el valor que ocurre en el mismo lugar cuando CK’ fue producido. Esto a su vez significa que los valores que ocurren como entrada a f4 deben ser los mismos y consecuentemente, los mismos valores de f4 deben ocurrir. Como suele suceder, f4 es IK. De esta manera se ha mostrado que CK = CK’ sí y solo sí IK = IK’.

A continuación, una construcción “mejorada” según la recomendación del órgano de estandarización (SAGE) , es decir, que incluye el RAND en las entradas, se considera:

KDF (CK || IK, RAND || IMPI) .

Suponemos que CK = CK’ (y de esta manera IK = IK’) . Se espera que el uso de RAND garantizará la unicidad. No obstante, esto no es cierto. Consideremos de nuevo la parte “relevante” del algoritmo Milenage que produjo la CK e IK a partir del RAND: Como se muestra en la Fig. 9, hay una situación en la que el valor en la flecha gruesa que corresponde al RAND es el mismo que el que corresponde al RAND’. Pero de nuevo, AES (Ek) es una permutación de manera que las entradas deben ser iguales, es decir RAND = RAND’. (El hecho de que AES es dependiente de K no ayuda dado... [Seguir leyendo]

1. Un método para generar una clave criptográfica (120) para proteger una comunicación móvil entre dos entidades (202, 204) , en donde el método se lleva a cabo por la primera entidad (202, 302) como parte de un procedimiento de Autentificación y Acuerdo de Claves (AKA) en base a un protocolo de AKA de UMTS iniciado por la segunda entidad (204, 304) , el método que está caracterizado por los pasos de:

- proporcionar (306) al menos dos parámetros (106, 108) , en donde el primer parámetro (106) comprende o se deriva de un conjunto de claves criptográficas (110, 112) que se han calculado por la primera entidad (202) ejecutando el procedimiento de AKA y el segundo parámetro comprende o se deriva de un testigo (116) que tiene un valor diferente cada vez que se inicia el procedimiento de AKA por la segunda entidad (204, 304) para la primera entidad (202, 302) ; y

- aplicar (308) una función de derivación de clave para generar una clave criptográfica (120) en base a los parámetros proporcionados (106, 108) ;

en donde el testigo (116) comprende un O exclusivo de un número de secuencia <SQN> y una Clave de Anonimato <AK>, en donde el SQN indica el número de veces que el procedimiento de AKA se ha iniciado por la segunda entidad (204, 304) para la primera entidad (202, 302) , y

en donde la AK es una clave criptográfica producida por una función de generación de claves f5 que usa un desafío aleatorio conforme al protocolo de AKA de UMTS.

2. El método de la reivindicación 1, en donde el testigo es una concatenación de O exclusiva del SQN y la AK, un Campo de Autentificación y Gestión de Claves <AMF>, y un Código de Autentificación de Mensajes <MAC>.

3. El método de cualquiera de las reivindicaciones precedentes, en donde el conjunto de claves criptográficas (110, 112) comprendidas en el primer parámetro (106) o desde el que se deriva el primer parámetro (106) comprende

o se deriva de una Clave de Cifrado <CK> (110) y una Clave de Integridad <IK> (112) .

4. El método de cualquiera de las reivindicaciones precedentes, que además comprende el paso de:

- aplicar una o más funciones de derivación de clave adicionales para generar claves más criptográficas en base a la clave criptográfica (120) generada.

5. El método de la reivindicación 4, en donde las claves más criptográficas comprenden al menos uno de los siguientes:

- un conjunto de claves criptográficas para la protección de tráfico de Estrato de No Acceso <NAS>;

- un conjunto de claves criptográficas para la protección de tráfico de Control de Recursos Radio <RRC>;

- un conjunto de claves criptográficas para la protección de tráfico de Plano de Usuario <UP>; y

- una clave criptográfica intermedia <KeNB> para derivar las claves criptográficas para la protección de tráfico RRC y/o las claves criptográficas para la protección de tráfico de UP.

6. El método de cualquiera de las reivindicaciones precedentes, en donde la primera entidad (202, 302) es un equipo de usuario.

7. El método de cualquiera de las reivindicaciones precedentes, en donde la segunda entidad (204, 304) es una entidad de red.

8. El método de la reivindicación 7, en donde la segunda entidad (204, 304) reside en una red de Evolución de Arquitectura de Sistema <SAE>/Evolución de Largo Plazo <LTE>.

9. El método de la reivindicación 7 u 8, en donde la segunda entidad (204, 304) comprende un Centro de Autentificación <AuC>/Servidor de Abonado Residencial <HSS> y una Entidad de Gestión de Movilidad <MME>.

10. El método de cualquiera de las reivindicaciones precedentes, en donde el procedimiento de Autentificación y acuerdo de Claves se realiza de manera cooperativa por la primera (202, 302) y segunda (204, 304) entidades.

11. Un producto de programa de ordenador caracterizado por las partes de código de programa de ordenador para ejecutar los pasos del método según cualquiera de las reivindicaciones precedentes cuando el producto de programa de ordenador se ejecuta en un sistema informático.

12. El producto de programa de ordenador de la reivindicación 11, en donde el producto de programa de ordenador se almacena en un medio de grabación legible por ordenador.

13. Un dispositivo (100) adaptado para generar una clave criptográfica (120) para una entidad de comunicaciones móvil (202, 302) adaptada para ejecutar un procedimiento de Autentificación y Acuerdo de Claves en base a un protocolo de AKA de UMTS, el dispositivo (100) que se caracteriza por:

- un primer componente (102) adaptado para proporciona al menos dos parámetros (106, 108) , en donde el primer parámetro (106) comprende o se deriva de un conjunto de claves criptográficas (110, 112) que se han calculado por la entidad de comunicaciones móvil (202, 302) ejecutando el procedimiento de AKA, y el segundo parámetro (108) comprende o se deriva de un testigo (116) , los al menos dos parámetros proporcionados que tienen un valor diferente cada vez que se inicia el procedimiento de AKA para la entidad de comunicaciones móvil (202, 302) ; y

- un segundo componente (104) adaptado para ejecutar una función de derivación de clave para generar una clave criptográfica (120) en base a los parámetros proporcionados (106, 108) ;

en donde el testigo (116) comprende un O exclusivo de un número de secuencia <SQN> y una Clave de Anonimato (AK) , en donde el SQN indica el número de veces que el procedimiento de AKA se ha iniciado para la entidad de comunicaciones móvil (202, 302) , y en donde la AK es una clave criptográfica producida por una función de generación de claves f5 que usa un desafío aleatorio conforme al protocolo de AKA de UMTS.

14. El dispositivo (100) de la reivindicación 13, en donde el conjunto de claves criptográficas (110, 112) comprendido en el primer parámetro (106) o del que se deriva el primer parámetro (116) comprende o se deriva de una Clave Cifrada <CK> (110) y una Clave de Integridad <IK> (112) calculadas por la entidad de comunicaciones móvil (202, 302) como parte del procedimiento de Autentificación y Acuerdo de Claves.

15. El dispositivo (100) de cualquiera de las reivindicaciones 13 a 14, adaptado además para aplicar una o más funciones de derivación de clave adicionales para generar claves más criptográficas en base a la clave criptográfica (120) generada.

16. Un equipo de usuario (202) caracterizado por el dispositivo (100) según cualquiera de las reivindicaciones 13 a

15.

17. Un sistema que comprende el equipo de usuario (202, 302) de la reivindicación 16 y una entidad de red (304) .

18. El sistema de la reivindicación 17, en donde la entidad de red (304) es para uso en una red SAE/LTE.