GTK e IGTK
GTK e IGTK se crearon al mismo tiempo. IGTK es la clave utilizada para la protección de la integridad y GTK es la clave utilizada para el cifrado. La clave de protección de integridad se refiere a agregar una clave para el cifrado al realizar el algoritmo de integridad. Esta clave es IGTK para evitar que se altere el mensaje de verificación de integridad. GTK se utiliza para cifrar mensajes de difusión.
GTK: GTK se deriva de GMK y se configurará en AP después de un período de tiempo para reducir la exposición de los datos.
GTK se actualizará en las siguientes circunstancias:
a) El Autenticador podría cambiar el GTK al disociarse o desautenticarse una STA.
b) Un evento dentro de la SME podría desencadenar un protocolo de enlace de clave de grupo.
La Figura 1 muestra el TK generado por GTK a través de GMK Juggernaut GTK es utilizado por la capa MAC para proteger el intercambio de direcciones de multidifusión. GTK se utiliza en un único Autenticador y realiza toda la autenticación en todas las estaciones de este Autenticador. Cuando sea necesario actualizar el GTK, el Autenticador enviará el nuevo GTK.
El protocolo de enlace de clave de grupo es un protocolo de enlace de dos pasos. El proceso es:
1. El AP utiliza el protocolo de enlace de clave de grupo para enviar un nuevo GTK, y si la protección del marco de administración es. negociado, se enviará un nuevo IGTK a la estación.
Mensaje 1: Autenticador → Suplicante:
EAPOL-Key(1,1,1,0,G,0,Key RSC,0, MIC, GTK[N],IGTK[M])
Mensaje 2: Solicitante → Autenticador: EAPOL-Key(1,1,0,0,G,0,0,0, MIC,0)
— La clave RSC indica el último número de secuencia de cuadro enviado utilizando el GTK.
— GTK[N] indica el GTK encapsulado con su identificador de clave como se define en 11.6. 2 utilizando la KEK
definida en 11.6.1.3 y el IV asociado.
— IGTK[M], cuando está presente, denota la IGTK encapsulada con su identificador de clave como se define en 11.6.2
utilizando la KEK definida en 11.6.1.3 y el IV asociado.
— El MIC se calcula sobre el cuerpo del marco EAPOL-Key (con el campo MIC puesto a cero para el
cálculo) utilizando el KCK definido en 11.6.1.3.
La estación puede iniciar un protocolo de enlace de clave de grupo enviando una trama EAPOL-KEY con el bit de solicitud del bit de clave de grupo establecido en 1.
Todos los AP deben realizar un protocolo de enlace de cuatro vías antes del protocolo de enlace de clave de grupo. El AP no puede realizar el protocolo de enlace de clave de grupo hasta que se complete el protocolo de enlace de cuatro vías.
11.6.7.2 Mensaje 1 de protocolo de enlace de clave de grupo
El mensaje 1 utiliza los siguientes valores para cada uno de los campos del marco clave EAPOL:
Tipo de descriptor = N – consulte 11.6.2
Información clave:
Versión del descriptor de clave = 1 (cifrado ARC4 con HMAC-MD5) o 2 (ajuste de clave NIST AES
con HMAC -SHA1-128) o 3 (ajuste de clave NIST AES con AES-128-CMAC), en todos los demás
casos 0
Tipo de clave = 0 (Grupo/SMK)
Mensaje SMK = 0
Instalación = 0
Confirmación de clave = 1
Clave MIC = 1
Seguro = 1
Error = 0
Solicitud = 0
Datos clave cifrados = 1
Reservado = 0
Longitud de clave = 0
Contador de repetición de clave = n+2
Nonce de clave = 0
EAPOL-Key IV = 0 (Versión 2) o aleatorio (Versión 1)
Clave RSC = último número de secuencia de transmisión para GTK
Clave MIC = MIC(KCK, EAPOL)
Longitud de datos de clave = cifrado específico de la suite; consulte la Tabla 11-4
Datos clave = cifrado, encapsulado
— GTK y el identificador de clave del GTK (consulte 11.6.2)
— Cuando está presente, IGTK, el identificador de clave de IGTK e IPN (ver 11.6.2)
El Autenticador envía el Mensaje 1 al Solicitante.
Al recibir el Mensaje 1, el Solicitante:
a) Verifica que el valor del campo Key Replay Counter aún no se haya visto antes, es decir, su valor es
estrictamente mayor que el de cualquier otra trama EAPOL-Key recibida hasta el momento durante esta sesión.
b) Verifica que el MIC sea válido, es decir, utiliza el KCK que forma parte del PTK para verificar que no
da
ta error de integridad.
c) Utiliza la primitiva MLME-SETKEYS.request para configurar el GTK temporal y, cuando esté presente,
IGTK en su MAC IEEE 802.11.
d) Responde creando y enviando el Mensaje 2 del protocolo de enlace de clave de grupo al Autenticador e
incrementando el contador de repetición.
NOTA: El Autenticador incrementa y utiliza una nueva repetición de clave Valor del campo contador en cada instancia del Mensaje 1
, incluso los reintentos, porque el Mensaje 2 que responde a un Mensaje 1 anterior podría haberse perdido si el
Autenticador no incrementó el contador de repetición. , el solicitante descarta el reintento y nunca llega ningún mensaje
2.
11.6.7.3 Mensaje 2 de protocolo de enlace de clave de grupo
El mensaje 2 utiliza los siguientes valores para cada uno de los campos del marco clave EAPOL:
Tipo de descriptor = N – consulte 11.6.2
Información clave:
Versión del descriptor clave = 1 (ARC4 cifrado con HMAC-MD5) o 2 (ajuste de claves NIST AES
con HMAC-SHA1-128) o 3 (ajuste de claves NIST AES con AES-128-CMAC), en todos los demás
casos 0 – igual que el Mensaje 1
Tipo de clave = 0 (Grupo/SMK) – igual que el Mensaje 1
Instalar = 0
Confirmación de clave = 0
Clave MIC = 1
Seguro = 1
Error = 0
Solicitud = 0
Cifrado Datos clave = 0
Reservado = 0
Longitud de clave = 0
Contador de repetición de clave = n+2 – igual que el mensaje 1
Clave Nonce = 0
EAPOL-Clave IV = 0
Clave RSC = 0
Clave MIC = MIC(KCK, EAPOL)
Longitud de datos clave = 0
Datos clave = n
uno requerido
Al recibir el Mensaje 2, el Autenticador:
a) Verifica que el valor del campo Contador de reproducción de clave coincide con uno que ha utilizado en la Clave de grupo
Handshake.
b) Verifica que el MIC sea válido, es decir, utiliza el KCK que forma parte del PTK para verificar que no haya ningún
error de integridad de datos.
p>
Como se muestra en la Figura 2 a continuación: