这篇文章主要整理一下关于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管理派生密钥。
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的流程图：
接下来补充一些关于attributes各个数据位的含意
1.AP Setup Locked
这个置为1的时候，表示AP进入一种拒绝外部registrar使用AP的PIN码执行Registration Protocol的状态。一般来说，如果在60s内有3次PIN认证失败就会进入这种状态，锁住60s后自动解开，或者重新配置一下AP的设置也会解开。
2.Association State
这个值表示STA发送Discovery request时的当前配置和前面的关联状态
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的加密方式
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。
8.Configuration Error
9.Connection Type & Connection Type Flags
这个值用来表示Enrollee的属性，一般都是ESS
10.Credential
WLAN的接入凭证于以及相关配置信息
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里面。
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。
13.Message Type
指定消息类型
14.Network Key
Enrollee需要的无线网络加密密钥，这个属性里面不能补0
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也可作为搜索匹配条件。
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。
17. RF Bands
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。
最后简单回顾一下WSC的交互过程
发现阶段：其实发现阶段主要是对设备的兼容性以及两端的配置信息进行鉴定，以确认接下来的交互是否匹配。被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-256<em><span style="font-size:10px;">KDK</span></em><span style="font-size:12px;">(i||digest||640)</span><em><span style="font-size:10px;"></span></em>
}
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建立正常的连接。