GTK：GTK是由GMK衍生出來的，經過壹段時間會配置給AP 去減少數據的暴露。
GTK會在下面的情況下進行更新：
a) The Authenticator might change the GTK on disassociation or deauthentication of a STA.
b) An event within the SME might trigger a Group Key Handshake.
圖1描述了如果經由GMK劍聖GTK，再由GTK產生TK，TK被MAC層使用用來保護是組播地址的交流。GTK被用在壹個獨立的Authenticator和所有的認證到這個Authenticator的所有station。當需要更新GTK時，Authenticator會發送新的GTK。
Group key握手是二次握手，流程是：
1.AP 使用Group Key 握手發送壹個新的GTK，並且如果管理幀保護被協商，壹個新的IGTK會被發送到station.
Message 1: Authenticator → Supplicant:
EAPOL-Key(1,1,1,0,G,0,Key RSC,0, MIC,GTK[N],IGTK[M])
Message 2: Supplicant → Authenticator: EAPOL-Key(1,1,0,0,G,0,0,0,MIC,0)
— Key RSC denotes the last frame sequence number sent using the GTK.
— GTK[N] denotes the GTK encapsulated with its key identifier as defined in 11.6.2 using the KEK
defined in 11.6.1.3 and associated IV.
— IGTK[M], when present, denotes the IGTK encapsulated with its key identifier as defined in 11.6.2
using the KEK defined in 11.6.1.3 and associated IV.
— The MIC is computed over the body of the EAPOL-Key frame (with the MIC field zeroed for the
computation) using the KCK defined in 11.6.1.3.
Station可以通過發送壹個EAPOL-KEY幀並且Group Key位的request bit被設置為1來出發壹次Group KEy的握手
所有的AP應該在Group key握手前先做四次握手。 AP不能做Group Key握手知道四次握手被完成。
11.6.7.2 Group Key Handshake Message 1
Message 1 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 11.6.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0
Key Type = 0 (Group/SMK)
SMK Message = 0
Install = 0
Key Ack = 1
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 1
Reserved = 0
Key Length = 0
Key Replay Counter = n+2
Key Nonce = 0
EAPOL-Key IV = 0 (Version 2) or random (Version 1)
Key RSC = last transmit sequence number for the GTK
Key MIC = MIC(KCK, EAPOL)
Key Data Length = Cipher-suite-specific; see Table 11-4
Key Data = encrypted, encapsulated
— GTK and the GTK’s key identifier (see 11.6.2)
— When present, IGTK, IGTK’s key identifier, and IPN (see 11.6.2)
The Authenticator sends Message 1 to the Supplicant.
On reception of Message 1, the Supplicant:
a) Verifies that the Key Replay Counter field value has not yet been seen before, i.e., its value is
strictly larger than that in any other EAPOL-Key frame received thus far during this session.
b) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no
data integrity error.
c) Uses the MLME-SETKEYS.request primitive to configure the temporal GTK and, when present,
IGTK into its IEEE 802.11 MAC.
d) Responds by creating and sending Message 2 of the Group Key Handshake to the Authenticator and
incrementing the replay counter.
NOTE—The Authenticator increments and uses a new Key Replay Counter field value on every Message 1
instance, even retries, because the Message 2 responding to an earlier Message 1 might have been lost. If the
Authenticator did not increment the replay counter, the Supplicant discards the retry, and no responding
Message 2 ever arrives.
11.6.7.3 Group Key Handshake Message 2
Message 2 uses the following values for each of the EAPOL-Key frame fields:
Descriptor Type = N – see 11.6.2
Key Information:
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap
with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other
cases 0 – same as Message 1
Key Type = 0 (Group/SMK) – same as Message 1
Install = 0
Key Ack = 0
Key MIC = 1
Secure = 1
Error = 0
Request = 0
Encrypted Key Data = 0
Reserved = 0
Key Length = 0
Key Replay Counter = n+2 – same as Message 1
Key Nonce = 0
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC(KCK, EAPOL)
Key Data Length = 0
Key Data = none required
On reception of Message 2, the Authenticator:
a) Verifies that the Key Replay Counter field value matches one it has used in the Group Key
Handshake.
b) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no
data integrity error.
如下圖2：