话不多说，直接开始。

一. 联网流程

wpa3也是在rsn ie中体现其加密类型的，下面用张图说明wpa/wpa2-psk和wpa3-sae的区别：

可以看到，AKMP中00-FC-AC-02表示是wpa-psk，00-FC-AC-08表示是wpa3-sae。

当联网使用wpa3-sae时，整个联网流程如下图：

可以看到auth过程变得和wep shared类似，这是因为sae会在联网最开始用auth帧协商出pmk：sta 发送auth alg 3 seq 1，ap回复auth seq2，sta继续发送auth seq 3，ap回复auth seq 4，如无失败，则pmk协商成功，就可以进行下一步关联。

本文不会提及去看看哪本协议，我相信跑来网上找资料的朋友基本上是不会去看协议原文的，所以对此过程auth交互代码实现感兴趣的朋友，可以去看看wpa_supplicant中的sae.c文件，开始入口函数为sme_external_auth_trigger，收到auth帧处理入口函数为sme_external_auth_mgmt_rx。

关联时asso req帧的rsn ie中只会填sae：

关联成功之后，就会进入四次握手的密钥协商流程，此过程不再介绍，sta代码可参考wpa_supplicant中的wpa.c文件，三个入口函数为wpa_supplicant_process_1_of_4、wpa_supplicant_process_3_of_4和wpa_supplicant_process_1_of_2，softap的代码可读性较差不建议阅读。

二. PMK caching

我们可以发现，正常的sae连接过程共需要4个auth帧，而且这个阶段需要进椭圆曲线计算，也比较耗时，那么有没有什么机制加速一下这个过程呢？

当然是有的。

AP可以保存PMK，当sta下次连接AP时就可以和wpa-psk一样，直接发送alg=0的auth帧，AP也回复一次auth帧即可，

然后sta发送的关联帧（或重关联帧）的rsn ie中只要携带pmkid，

那么关联之后同样也就进入了四次握手协商密钥的阶段，这样就能节省sae协商pmk的环节。

至于AP保存的PMK具有多久的时效我目前没有研究明白，我也没有从协议中看到明确说明，如果有人了解这个不妨告诉我。根据我的测试，在某些AP下，sta发送disasso帧，AP不会清除PMK；sta发送deauth帧，ap会清除PMK；也有AP始终不清除，直到自己掉电……

如果关联时携带了pmkid，而AP回复的asso resp帧的status为53，则直接表示pmkid无效，当然也会有例外，有些AP会用status为40表示pmkid无效或自己不支持此功能。

为了兼容性，根据我的观察，当sta使用pmkid联网被AP拒绝后，应该不携带pmkid再次尝试联网一次或许就可以了。

对于PMK caching，wpa_supplicant也是做了实现的，其代码可参考pmksa_cache.c。

三. 管理帧保护

有些资料称之为pmf，也有地方称之为mfp，本文用mfp表示。

在wpa2年代，mfp仅仅是可选，但是在使用wpa3时则mfp是强制要用，此要求可在rsn ie体现：

MFPC为1则说明ap支持mfp功能，为0则说明ap不支持mfp；MFPR为1则说明mfp需要要用，为0则说明可用可不用。

mfp用来加密关键管理帧，关键管理帧包括deauth、disassoc和部分action帧。这里我列出当前协议规定的需要加密的action帧，category如下表：

mfp要求sta和ap都对关键管理帧进行加密，如果某一方收到对方非加密的关键管理帧，则需要发送一个加密的sa query帧（action帧的一种）鉴定对方是否有效，对方需要在一定的时间内回复一个加密的sa query resp帧，所以对于假冒者发送的管理帧会因为sa query交互失败而被忽略，从而保证了安全。

这里需要强调，单播的管理帧也是使用ptk进行加解密的。但是广播管理帧有点不同：

在组密钥协商时除了得到一个gtk，还会得到一个igtk。ap发送广播管理帧时并不会使用gtk加密此报文，而是使用igtk将管理帧内容用aes-128-cmac算法进行计算得出一个64 bit的mic，然后将此mic值添加到管理帧的一个叫做管理帧mic的ie中（ie号为76），最后将此广播管理帧明文发出。当sta收到广播管理帧后，需要自己使用igtk对报文内容计算出mic，和报文mgmt ie中携带的mic进行比较是否一致，如果一致则说明是ap发送的管理帧，否则就是假冒的。

加密的广播管理帧如下图所示：

我理解使用igtk是因为同一个ap下的sta的gtk都是相同的，所以为了防止同一个ap下的某些sta故意模仿ap恶意广播管理帧做得保护。

写到这里本文基本上就写完了想要介绍的东西，最后我谈一点有意思的事情。

似乎使用了mfp就非常安全，之前那种模拟ap不停发送deauth帧做的断网神器就不太可能了。然而我举个例子，比如sta已经连上了ap，并且使用了mfp，这时此sta直接掉电重启，然后发个明文deauth，然后从auth开始联网，这时就可以很顺利重新连上网了。所以mfp机制确实是安全的，但是在实际的ap实现中，ap厂商可能也为了兼容性，他们在实现上并没有严格的遵守协议的某些要求，甚至有的路由器连action sa query机制都没，所以就会出现这种漏子。