hostapd wpa_supplicant madwifi详细分析（十一）——wps原理及实现三

左手的ㄟ右手 2022-09-22 15:54 764阅读 1赞

这篇文章主要整理一下关于WSC的边边角角，对一些比较重要且前面没有解释清楚的一些概念做点补充，如果对前面两篇文章理解比较清楚，可以略过。

**首先补充一下关于PBC的内容**

前面两篇文章分析的都是关于PIN，而且M3-M7消息的主要工作也就是确认Enrollee和Registrar各自手上的PIN都是相同的，然后用M8给Enrollee发送configdata。但是PBC的WPS连接方式却是一种极为偷懒的行为，它不仅不需要对方输入正确的PIN码，而且直接告诉大家我们交互时验证的PIN码就是“00000000”，可以说M3-M7的安全工作几乎是多余的，Enrollee的安全保证直接依靠

（1）.发现阶段的probe request和probe response的Description，以及2min的等待时间窗。使用PBC方式的时候，也就是假定我们约定的某个2min内进行PBC连接是安全的，这个时间段内不会有别人来入侵，如果检测到别人在入侵或有多个Enrollee在尝试连接，registrar就终止一切交互动作，并且等待一段时间后再允许尝试。

（2）.DH-key（K\_tmp）保密程度，因为在等式中KWK = HMAC-DHKey (N1 || EnrolleeMAC || N2)，括号中的内容都是可以通过监听无线WPS交互报文来获取的

其实PBC并不指简单的按一下WPS按钮，它是一个泛指，包括所有能够触发PBC method的条件都可以称为PBC，包括软件模拟触发，DTV和硬件按钮等等。由于PBC method并不是一个可靠的方式，所以不允许使用这种方式来管理AP配置，不管是通过M8消息或者管理接口都是不允许的，这也表示AP不支持使用PBC方式添加外部registrar，也不支持为后面的AP管理派生密钥。

![20160702100635253][]

PBC方式的使用要求用户在2min的时间轴内，Enrollee和registrar都要触发PBC运行。在两边都触发了以后，Enrollee如果发现了一个激活的Registrar，它并不会立即执行Registration Protocol，Enrollee首先会扫描所有它自己支持的802.11 channel以发现附近是否还有其他的Registrar有激活PBC模式。

Enrollee通过广播发送携带Device password ID(有置PBC标志位)的probe request然后收集probe response消息，如果Enrollee从收集的probe response消息里面发现有两个以上的Registrar在运行PBC模式，Enrollee就会终止连接，然后发送一个“session overlap”给用户，如果发生了“session overlap”错误，用户就会从UI上收到一个提示信息，指示用户等待一段时间再尝试。值得注意的是，在双频AP和双频STA环境中，STA可能会发现多个registrar有激活PBC模式，如果双频STA发现在双频AP的两个band上都有运行PBC，并且beacon包里面的UUID和probe response的相同，那么STA将不会把这中情况认为是session overlap事件。如果Enrollee扫描完以后，只发现一个registrar有激活PBC，那么Enrollee就会马上和这个registrar开始执行Registration Protocol。

当registrar激活PBC的时候，registrar就会开始检查接收到的probe request包是否来自多个Enrollee，同时也会检测是否在按下按钮后的120s以内接收到的probe request包。在这个120时间窗里面，如果registrar收到多个Enrollee发送的PBC probe request包，或者registrar接收到的M1报文里面的UUID-E和probe request里面的UUID-E不一样，那么registrar就会生“session overlap”错误，并提示用户。这时registrar就会退出PBC模式，直到同时满足下面两个中的条件时再执行：

（1）用户再次按下PBC按钮

（2）在新的2min时间窗里面，检测到只有一个Enrollee在运行PBC

如果Registrar在和Enrollee进行PBC Registration Protocol交互时发现另外一个Enrollee的probe request包或M1消息，那么registrar也会发生一个“session overla”错误。这时registrar将会在下次接收M1-M8消息时，回复一个WSC\_NACK消息回去。

如果在2min再按了一次button，相当于重新来过一次，重新以2min计时。

Registrar在运行PBC时，如果接收到M1 消息，它会先将M1中的UUID-E和probe request中的UUID-E进行比较，以确认是否下一步继续发送M2消息(i.e., if the UUID-E of the PBC M1 message does not match the UUID-E from the PBC probe request message, then the PBC M1 message shall be rejected by the Registrar with M2D using Configuration Error 12 - Multiple PBC sessions detected).  Enrollee在收到M3以后，就会用device password为00000000进行后面的M3-M8交互。

下图是使用外部Registrar时，PBC的流程图：

![20160702110429990][]

**接下来补充一些关于attributes各个数据位的含意**

**1.AP Setup Locked**

这个置为1的时候，表示AP进入一种拒绝外部registrar使用AP的PIN码执行Registration Protocol的状态。一般来说，如果在60s内有3次PIN认证失败就会进入这种状态，锁住60s后自动解开，或者重新配置一下AP的设置也会解开。

**2.Association State**

这个值表示STA发送Discovery request时的当前配置和前面的关联状态

![20160702171832635][]

**3.Authentication Type**

这个值从Authentication Types table里面来，如果Registrar和Enrollee都使用2.0或更高的WPS版本时，可以使用0x0022表示混合加密(both WPA-Personal and WPA2-Personal enabled).1.0h没有混合加密的描述，而且为了向后兼容，只有一个值0x0020 WPA2-Personal可以同时在新版本和旧版本里面使用，只有0x0022这种加密方式可以同时设两个，其他的加密方式都只能设一个。

**4.Authentication Type Flags**

这个值表示Authentication Type的加密方式

![20160702175421414][]

**5.Authenticator**

它是一个键控哈希数据，它的值依赖于处理的消息内容，WPS规范1.0和2.0都使用的是HMAC-SHA-256算法，在M1-M8的消息里面，HMAC算法使用的默认值都是AuthKey.如果默认KEY不可用，那么就会使用Key Identifier attribute里面指定的KEY。为了减少消息的负载大小，Authenticator attribute一般只取结果中256位的前64位。

这个值其实可以当作校验码来看待，它的作用主要是用来确认消息有正确发送。

**6.AuthorizedMACs**

这个是一张包含Enrollee MAC地址的一张表，用来登记有启动过WSC过程的Enrollee。这个表会在AP的beacon包和probe response包里面发送，用来告诉Enrollee是否以前有登记启动过WSC过程。

**7.Configuration Methods**

这个属性很重要，主要用来决定使用哪种方式进行WPS交互，平常用的比较多的是PBC和PIN

Display还需细分为Physical Display或Virtual Display。二者区别是Physical Display表示PIN码能直接显示在设备自带的屏幕上，而Virtual Display只能通过其他方式来查看（由于绝大多数无线路由器都没有屏幕，所以用一般情况下，用户只能在浏览器中通过设备页面来查看）PIN码。Keypad表示可在设备中输入PIN码。另外，是否支持Push Button由Push Button位表达。同PIN码一样，它也分Physical Push Button和Virtual Push Button。

![20160702181017374][]

**8.Configuration Error**

![20160702181356146][]

![20160702181514907][]

**9.Connection Type & Connection Type Flags**

这个值用来表示Enrollee的属性，一般都是ESS

![20160702181755214][]

**10.Credential**

WLAN的接入凭证于以及相关配置信息

![20160702182015018][]

**11.Device Password ID**

这个attribute主要是用来指定device password，有7个预定的值和7个保留值，默认值是PIN码，这个password可能来自label， display或者用户指定。Registrar-specified value表示从Registrar那里获取的device password，获取方式可能是display或者out-of-band方法，这个值将来可能添加到M1中的“Identity” attribute里面。

![20160702183149062][]

**12.Encryption Type & Encryption Type Flags**

指定一种加密类型，在WSC 2.0以上的标准可以支持混合加密(both WPA-Personal with TKIP and WPA2-Personal with AES enabled)，但是1.0h和2.0交叉时，只能用0x0008 AES。

![20160702183710527][]

**13.Message Type**

指定消息类型

![20160702183839246][]

**14.Network Key**

Enrollee需要的无线网络加密密钥，这个属性里面不能补0

![20160702184144528][]

**15.Primary Device Type**

Primary Device Type属性代表设备的主类型。在Discovery Phase阶段，交互的一方可指定要搜索的设备类型（需设置Requested Device Type属性，该属性的结构和取值与Primary Device Type一样）。这样，只有那些Primary Device Type和目标设备类型匹配的一方才会进行响应。

规范还定义了一个名为Secondary Device Type List的属性，该属性包含了设备支持的除主设备类型外的设备类型。具体的设备类型取值和Primary Device Type一样。Discovery Phase阶段中，Secondary Device Type List也可作为搜索匹配条件。

![20160702184410999][]

![20160702184432140][]

**16.Request Type & Response Type**

·Request Type属性必须包含于Probe/Association Request帧中，代表STA作为Enrollee想要发起的动作。该属性一般取值0x01（含义为Enrollee，open 802802.1X），代表该设备是Enrollee，并且想要开展WSC后续流程。它还有一个取值为0x00（含义为Enrollee，Info only），代表STA只是想搜索周围支持WSC的AP，而暂时还不想加入某个网络。

·Response Type属性代表发送者扮演的角色。对于AP来说，其取值为0x03（含义为AP），对于Registrar来说，其取值为0x02，对于Enrollee来说，其取值可为0x00（Enrollee，Info only）和0x01（Enrollee，open 802.1X）。Standalone AP也属于AP。

![20160702184926766][]![20160702184938391][]

**17. RF Bands**

![20160702185034047][]

**18.Wi-Fi Simple Configuration State**

对于STA来说，它发送的M1中，Wi-Fi Simple Configuration State标志位应该始终为'Not Configured' (0x01).

对于AP来说，它发送的beacon，probe response和M1中，Wi-Fi Simple Configuration State标志位用来表示AP是否已配置，如果AP刚恢复出厂，那么AP就处于“Not Configured” 状态，那么在满足下面的任意一个条件以后，AP会切换到已配置状态“Configured”（0x02）：

1.AP被外部registrar配置过后，也就是说AP向外部Registrar发送WSC\_Done消息后，AP会变成已配置状态

2.被内部registrar自动配置过，也就是说，AP在处理Enrollee Registration过程中，收到来自第一个Enrollee的WSC\_Done response消息后，AP会变成已配置状态。

3.AP被用户手动配置后，也就是说，只要用户修改过SSID，加密算法，认证算法，密码或密钥中的任意一个变量，都会让AP从未配置状态切换到已配置状态，但是当AP恢复出厂的时候，会变为未配置状态。

值得注意的是，不管AP是处于已配置状态或未配置状态都不会影响STA Enrollee Registration Protocol的继续执行，也就是说Enrollee会忽略AP的Wi-Fi Simple Configuration State attribute。

![20160702191132444][]

**最后简单回顾一下WSC的交互过程**

![20160703091131557][]

**发现阶段**：其实发现阶段主要是对设备的兼容性以及两端的配置信息进行鉴定，以确认接下来的交互是否匹配。被check的信息包括使用的WSC版本信息，请求类型，设备类型，RF band，Conguration Method，device password ID， 配置和关联结果等等。 对于Push button的方式还要检查UUID。

**认证和关联阶段**：这个过程在实际应用中，一般都不会出错，因为它并没有真正的检测认证密钥，它会忽略对应的RSN IE和WPA IE检测，直接回复Auth成功包

**身份确认阶段**：在STA和AP双方开展EAP-WSC流程前，AP需要确定STA的Identity以及使用的身份验证算法。该过程涉及三次EAP包交换（参考上图）。这三次包交换的内容分别如下。

·AP发送EAP-Request/Identity以确定STA的ID。

·对于打算使用WSC认证方法的STA来说，它需要在回复的EAP-Response/Identity包中设置Identity为"WFA-SimpleConfig-Enrollee-1-0"。

·AP确定STA的Identity为"WFA-SimpleConfig-Enrollee-1-0"后，将发送EAP-Request/WSC\_Start包以启动EAP-WSC认证流程。这个流程讲涉及M1～M8相关的知识。

**M1-M8**：具体请参考前文，这里简单回顾一下其间使用到的算法以及一些重要的密钥

（1）Diffie-Hellmen:它是一种密钥交换算法，并不是加密算法。对于正常数据包的加密传输，在双方交换密钥以后，可以使用这个共享密钥（D-HKey）配合一种加密算法对要发送的数据进行加密，对方接收到数据包以后就可以用共享密钥（D-HKey）进行解密。当然在M1-M8中并没有用D-HKey直接用于数据加密，而是用它计算出来一个派生密钥KDK。

（2）HMAC-SHA-256：HMAC是一种消息摘要算法，兼容了MD和SHA算法的特性，HMAC-SHA-256算法则是其中的一种，HMAC，主要是利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。所以在这个算法中，主要变量是密钥和消息。

（3）KDK：KDK = HMAC-SHA-256DHKey (N1 || EnrolleeMAC || N2)， 它是由D-HKey作为密钥，N1 || EnrolleeMAC || N2作为消息计算出来的鉴别码，KDK用于后面派生AuthKey, KeyWrapKey 和 EMSK， 这三个密钥各有各的用途，特别是AuthKey, KeyWrapKey对M3-M8的加密有关键的作用。

（4）AuthKey, KeyWrapKey 和 EMSK三个密钥的派生

派生出这三个密钥使用的算法是KDF函数：AuthKey || KeyWrapKey || EMSK = kdf(KDK, “Wi-Fi Easy and Secure Key Derivation”, 640)，下面简单介绍一下他们是怎么派生出来的。注：prf函数是一个可键控的HMAC-SHA-256函数

kdf(key, personalization\_string, total\_key\_bits) :  
result := “”  
iterations = (total\_key\_bits + prf\_digest\_size – 1)/prf\_digest\_size  
for i = 1 to iterations do  
result := result || prf(key, i || personalization\_string || total\_key\_bits)  
return 1st total\_key\_bits of result and destroy any bits left over

这个函数中，Key是256位的KDK，i和total\_key\_bits是32bit的整数，personalization\_string是不以空格结尾的UTF-8编码字符串，使用大端串联。

所以kdf(KDK, “Wi-Fi Easy and Secure Key Derivation”, 640）
 
 {
 
 char *digest=“Wi-Fi Easy and Secure Key Derivation”;
 
 char result[]="";
 
 iterations=(640 + strlen(digest) )/strlen(digest);
 
 for(int i=1; i <= iterations; i++)
 {
 result=result||HMAC-SHA-256KDK(i||digest||640)
 }
 return result的前640位
  }

就这样愉快的获取到来640位的计算结果。下面讲讲AuthKey, KeyWrapKey 和 EMSK吧。

 AuthKey (256 bits)：用来鉴定 Registration Protocol messages.  
 KeyWrapKey (128 bits)：用来加密nonces and ConfigData.  
 EMSK (256 bits)：它是一个 Extended Master Session Key ，它用来派生其他的key或用于其他应用.

不知道细心的你有没有发现256+128+256=？，没错！就是640，到这里应该不用解释AuthKey || KeyWrapKey || EMSK = kdf中，AuthKey, KeyWrapKey 和 EMSK三个值是怎么来的了吧？就是将这640位分成3段，256+128+256分别赋值给AuthKey, KeyWrapKey 和 EMSK。

也许将 “||” 看成“追加拼接”会更好理解。

（5）M1-M3中一些重要的参数计算：

ES1,ES2是Enrollee端生成的128位的随机数，它与N1，N2不同

RS1,RS2是Registrar端生成的128位随机数，它与N1，N2不同

E-Hash1 = HMAC-AuthKey( ES1 || PSK1 || PKE || PKR )

E-Hash2 = HMAC-AuthKey( ES2 || PSK2 || PKE || PKR )

R-Hash1 = HMAC-AuthKey( RS1 || PSK1 || PKE || PKR )

R-Hash2 = HMAC-AuthKey( RS2 || PSK2 || PKE || PKR )

ENC-KeyWrapKey(R-S1)

ENC-KeyWrapKey(E-S1)

ENC-KeWrapKey(R-S2)

ENC-KeyWrapKey(E-S2）

ENC-KeyWrapKey(ConfigData)

HMACAuthKey(Mx || Mx+1\*)

从这些表达式中应该看出AuthKey, KeyWrapKey在M3-M8消息中有多么重要的作用了。

**断开关联**：获取到WLAN的接入凭证以后，就需要和AP断开关联，Enrollee用获取到的信息重新和AP建立正常的连接。

[20160702100635253]: /images/20220721/88cc4bfac2fe48b4994ab8c8bd958879.png
[20160702110429990]: /images/20220721/7226c8c4c3da468a9044477780a80eef.png
[20160702171832635]: /images/20220721/9b0ba4f6fd504b1eba01ca76818eb3a0.png
[20160702175421414]: /images/20220721/3aa72da3cad4499e8cdf87c014cf70a2.png
[20160702181017374]: /images/20220721/2b2d1ec6df874819911fbf255ec88161.png
[20160702181356146]: /images/20220721/4fa7c4b69ed14ce8a7903315530f5dd4.png
[20160702181514907]: /images/20220721/ad5abb70c62747a69bc2a03830a3f501.png
[20160702181755214]: /images/20220721/86ad56a85cae4f36a763136a5dc1d38d.png
[20160702182015018]: /images/20220721/59c8226f852747dcbbbf6e0c5f0eea47.png
[20160702183149062]: /images/20220721/46933877aa534d61a251749347330ffe.png
[20160702183710527]: /images/20220721/23bf596463d145f2a889938ca7376e5c.png
[20160702183839246]: /images/20220721/57d4581b4c6545a8b22d0040505ac792.png
[20160702184144528]: /images/20220721/dcd16d4a151d4ef4b224deb26e8da878.png
[20160702184410999]: /images/20220721/7704038743854283973e391a02062017.png
[20160702184432140]: /images/20220721/fd05d6b96720416d8fc43131a41444cd.png
[20160702184926766]: https://img-blog.csdn.net/20160702184926766
[20160702184938391]: /images/20220721/f3a1d58e9c274b9e95277be08cd629dd.png
[20160702185034047]: /images/20220721/b439acb6ee654d0ea6b20abfba5566fd.png
[20160702191132444]: /images/20220721/4118dd5050b14e158690e9b415596932.png
[20160703091131557]: /images/20220721/02121d00b322437284ec585dad4e57a0.png