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

约定不等于承诺〃 2022-09-21 04:54 977阅读 0赞

前面对WPS交互过程有了大概的了解，现在了解一下WPS交互时帧的格式以及每个帧所携带的信息。  
WPS使用802.1x和EAP传输in-band注册协议的交互信息，这些信息里面都会携带大端排序的attributes字段。这个协议都会和一个自定义的EAP method相对应。WPS不需要AP支持RADIUS，也不要求网络内包含一个认证服务器，事实上，很多具有WPS功能的AP只支持802.1x使用WPS将它配置成WPA2-Personal证书加密。同时使用自定义EAP method的WPS认证方式并不能保证Enrollee可以直接访问WLAN，EAP method 主要是给Enrollee配置一个证书，用于后面接入WLAN，比如一个AP只支持可分享PSK的WPA2-Personal加密，那么Enrollee将会运行802.1x交互去获取这个PSK，然后断开连接，最后使用这个PSK以WPA2-personal方式接入这个WLAN。当然，如果AP支持802.1x认证，Enrollee首先会尝试运行WPS EAP method去获取一个 shared secret Credential，然后用那个secret结合另外一种EAP method去接入这个WLAN。  
WPS EAP method也叫作EAP-WSC，这种算法可用于Registrar和Enrollee的发现，也可以用于Credential的建立。当一个Enrollee第一次接入一个新的WLAN时，它将会发送discovery信息并且执行EAP-WSC method。Enrollee会在Discovery message和M1中提供它自己的信息给WLAN，同时M2和M2D也会给Enrollee提供可用的registrar信息。当Enrollee首次发现并尝试和WLAN建立连接的时候，WLAN中的registrar可能还不知道Enrollee设备的password，这时registrar就会回复不带Enrollee password的M2D给Enrollee。虽然M2D message是没有认证的，但是它可以引导用户通过这个登记过程，也可以帮助信息较少的Enrollee选择一个更具体的registrar，比如选择和vendor拓展功能。  
Enrollee在扫描网络中的M2D消息的时候可能会发现没有一个AP有获取到它的device password，那么这时Enrollee需要提示用户去执行一个可靠的自引操作，比如通过out-of-band方式或手动输入设备password（PIN）给Registrar。如果用户将Enrollee的device password输入给了registrar，那么Enrollee可以再次和AP尝试连接；如果Enrollee没有提示用户输入password的接口，那么就可能需要registrar来完成这个提示了。Enrollee和registrar都会提供足够的信息给对方，让他们相互判断是否相互兼容，以保证能够顺利的通过认证。如果用户决定使用out-of-band的方式去交互，那么registrar就会默认的认为这种方式是安全的，然后在M2中将自己的网络配置信息发送给Enrollee。  
一、EAP消息帧  
AP在WLAN中也是扮演一个EAP认证者的角色，registrar是认证服务器，所以AP会产生EAP Request message，Enrollee和registrar会生成EAP Response。如果registrar独立于AP，那么它会使用UPnP（而不是RADIUS）和AP交互Registration Protocol messages。一个registrar在802.1x也可能扮演认证者的角色，而且这种模式在legacy APs网络中作用很大。  
下面将简单的介绍一下EAP-WSC，下面是EAP请求帧和回复帧的格式：  
![这里写图片描述][20160615112914973]  
code filed: 1–EAP request messages 2–EAP response  
Identifier field: 用来关联请求包和回复包  
length：EAP包的总长度  
Type: 指定EAP method的类型，我们知道EAP method有很多种类型，具体在交互中使用哪种类型，就靠它了，在WPS配置中将它设成254（expanded type）  
Vendor-Id：WFA SMI code 0x00372A  
Vendor-Type: 0x0000 0001 (SimpleConfig)  
Op-Code：这个字段很重要  
 0x01 : WSC\_Start  
 0x02 : WSC\_ACK  
 0x03 : WSC\_NACK  
 0x04 : WSC\_MSG  
 0x05 : WSC\_Done  
 0x06 : WSC\_FRAG\_ACK  
Flags field：  
 0x01 : more fragments (MF)  
 0x02 : Length field (LF)  
 0x04 – 0x80 : reserved  
Length field：在WSC消息中，总的WSC TLV attributes长度  
Message Data field：所有的WSC TLV attributes，WSC message可能会分段也可能放在不同的EAP包中  
1.分片和重组  
如果MF（multi fragment）置1，那么原本会被分片发送，如果没有多余的包需要发送，这个MF位不会被置1. 当收到所有带MF标志的包以后，接收端就会回复一个WSC\_FRAG\_ACK message，接收端会将每一个分片的Message Date组合成最原始的包。  
如果LF位置1，那么头部就会包含Message Length field以表明要发送的WSC message data字节大小，如果没有置1，Message Length field会被忽略。如果消息有分片，那么第一个包LF必须置1，后面的包不能设。

1.  EAP Identity  
    外部registrar必须使用EAP Identity “WFA-SimpleConfig-Registrar-1-0， Enrollee必须使用EAP Identity“WFA-SimpleConfig-Enrollee-1-0”。  
    二、EAP消息种类  
    在EAP-WSC中一共有6种EAP消息，下面来简单介绍。  
    WSC\_Start：  
    当AP收到一个包含NAI（network access Id）为“WFA-SimpleConfig-Enrollee-1-0”的EAP Response/Identity报文的时候，这个包的Message Data field是空的  
    WSC\_ACK：  
    如果Enrollee或registrar成功接收并处理了一个包但是没有消息回复的时候，就会发送一个WSC\_ACK包回去，比如Enrollee收到一个M2D包，它就会回复一个WSC\_ACK包  
    WSC\_NACK：  
    当认证或处理出错的时候会发这个包  
    WSC\_MSG：  
    supplicant和authenticator都会发送这个包，它用来负载MessageData，authenticator不会查询这个消息包里面的信息来决定状态机的状态，他们只是简单的传送给对方  
    WSC\_Done：  
    当Enrollee成功接收并处理了WSC M8报文以后，它会发送WSC\_Done报文以表明自己正确的获取到了WLAN的Credential  
    WSC\_FRAG\_ACK：  
    当supplicant或authenticator成功接收并处理了一个EAP消息分片并准备接收下一个分片的时候会发送这个包  
    三、Enrollee注册过程中，AP端的EAP状态机变化过程  
    下图是Enrollee接入AP时，AP的状态机变化过程，虚线表示AP发送的包，实线表示Enrollee发送的包，逗号分隔的表示其中一个，锁步机制在这个表中表示默认开启，只有执行了上一步才会执行下一步，比如发送了一个M5出去，那么只有收到M6以后，它才可能会发一个NACK消息。  
    ![这里写图片描述][20160615141936122]  
    接下来简单分析一下这个过程：  
    （1）当Enrollee决定运行EAP-WSC连接到网络的时候，它首先会和AP建立关联并且发送EAPol-Start消息给AP  
    （2）AP收到EAPol-Start消息以后，它会回复EAP-Request/Identity  
    （3）然后Enrollee会发送一个带有“WFA-SimpleConfig-Enrollee-1-0”的EAP-Response/Identity消息回去（A->B）  
    （4）AP开始运行EAP-WSC过程（B->C）  
    （5）然后开始8路握手过程，如果Enrollee正确的获取到了M8，它会发送一个EAP-Response/Done message给AP，AP会回复一个EAP-Failure message。Enrollee首先要假定它从M8中获取到的credentials是有用的再发送WSC\_Done message。Enrollee收到EAP-Failure message后会和AP disassociates然后用在M8 ConfigData中获取到的Credential进行重连。  
    （6）如果Enrollee接收到M2D消息，它应该回复一个ACK message，这样AP才可以继续将其他registrar的discovery messages继续转发下来。  
    （7）如果Enrollee收到一个EAP-Failure，那么Enrollee接下来只能做接下来两件事中的一种：  
    (a)和AP断开连接，一段时间以后重新发送EAPoL-Start message再进行一次EAP\_WSC 过程  
    (b)和AP保持连接同时重新发送一个EAPoL-Start message再次进行EAP-WSC  
    （8）如果Enrollee发送了M3，那么registrar和Enrollee都要进入锁步状态，直到失败或者成功（收到Done response message），如果Enrollee在解析过程中有任何错误发生，它就会发NACK message，然后切换到G状态以终止连接。这时就要求Enrollee计算一个新的device password用于下次认证，如果在不同的连接中使用了同一个的device password，很可能导致问题。  
    EAP State Machine for Adding an External Registrar这里就不简述了，因为我们讨论的都是standalone mode，AP和registrar都是整合在一起的，不存在将AP接入到外部registrar的问题。

四、版本协商  
在EAP\_WSC消息中包含使用的协议版本信息，以保证向后兼容以及向前扩展。1.0h版本并没有描述接收消息时，对版本特性的具体处理规则，为了避免发生问题，现在的消息中必须包含版本属性，并且固定值为value 0x10；一个新的子属性Version2用来表明这个协议遵守第二版本的规则，2.0或更新的版本都要包含Version2 subelement，如果没有包含，表示使用的是1.0h协议。  
如果收到一个版本号不匹配的消息，不应该马上把这个包丢弃掉。消息生成端有责任生成接收端能够支持的消息。

五、消息编码  
根据上面的描述，我们可以组出不同种类的包，但是要怎么合理的将它们组成二进制发送出去才是关键，Registration Protocol messages可以封装在不同的包里面发送，比如EAP和UPnP，所以有必要对这个做一个规定。  
attributes的排列顺序必须按照下面的表格来，R（require）表示必须的，O（optional）表示可选的，C（conditional）表示满足一定条件的。  
1. WPS TLV 数据格式  
attribute中的格式按照Type, Length, Value (TLV) format排列  
2. 802.11 管理帧  
在发现阶段，WSC设备是通过在管理帧里面携带802.11 IE来完成的，管理帧包括：Beacon，probe Request和probe Response。如果一个Enrollee需要建立一个网络连接，它就会初始化一个基于EAP注册协议的802.1x/EAP 连接， 在beacon包和probe Request包里面交换信息是不安全的，只能作为一种声明信息来看待。  
下面我们来了解一下WSC-IE的相关内容（Wi-Fi Simple Configuration Information Element）。  
WSC-IE通其他IE一样遵守802.11 IE格式，这个IE里面包含指定的数据，包括网络信息，性能和模式等，这些信息可用于配置Enrollee连接到一个网络，也可以让Enrollee在关联过程中出错时发送报告。下面是WSC\_IE的格式：  
![这里写图片描述][20160627121932454]  
在同一个802.11管理帧中可能携带多个WSC-IE，如果在一个帧中有发现多个WSC-IE，就需要将这些数据单元串联起来，在串联的时候，需要在原始包里面预留这些元素的顺序。  
AP必须在beacon包和probe Response包里面携带WSC-IE信息，以表明AP支持WSC；STA在probe Request包里面也必须携带WCS-IE以声明支持WSC。  
如果一个STA想要通过EAP-WSC的方法接入一个开启WPS功能的AP，那么除了需要携带802.11指定的IE外，STA在它的802.11 (re)association request包里面还必须携带WSC-IE。请注意，在WSC association过程中，Capability information域中的Privacy subfield，RSN IE和 WPA IE是不相干的，而且这些信息会被STA和AP忽略，但是STA和AP会继续遵守其他协议（比如WMM），所以如果(re)association request包里面携带了WSC IE信息，那么AP应该使用EAP-WSC加密方式和STA进行交互，而不应该尝试其他的加密握手交互。  
当STA和AP关联成功以后，STA会向AP发送一个EAPOL-Start包，然后等待AP回复EAP-Request/Identity包；当然，如果在AP收到的(re)association request包中携带WSC IE，而且WSC IE的版本在2.0以上，也允许AP在还没有收到EAPOL-Start前，先向STA发送EAP-Request/Identity；在STA接收到AP的EAPRequest/Identity，STA将回复EAP-Response/Identity以声明它在接下来的过程中扮演Enrollee的角色还是registrar。  
注意：为了兼容1.0版本，如果开启WSC功能的AP使用的是WPA2-Personal加密，那么在和STA关联交互的报文中可以不带RSN IE或者WPA IE，甚至可以不带WSC IE。而且AP只允许在接收到EAPOL-Start帧以后才开始交换EAP-WSC消息。在1.0版本中的association requests可能没有携带WSC IE信息。  
在WSC IE里面，Element ID的值是221，OUI的值是十六进制00 50 F2 04。  
发送端应该限制放入WSC IE里面的数据，以避免超出802.11帧规定的大小。  
WSC IE中，Data域的组织结构为一个或多个Attribute（属性）。Attribute的格  
式为TLV，即Type（长度为2字节）、Length（长度为2字节，代表后面Value的长  
度），Value（最大长度为0xFFFF字节）。  
WSC IE 的数据域里面有好多attributes组成， 下面来分析一下一些常用的attributes：  
**Version和Vendor Extension属性**  
Version属性表达了发送端使用的WSC版本信息。Version属性的Type字段取值为0x104a，Length字段长度为1字节。  
Version属性已经作废（Deprecated），但为了保持兼容性，规范要求WSC IE必须包含该属性，并且其Value字段需设为0x10。取代Version属性的是Version2属性，Version2属性并不能单独存在，而是作为Vendor Extension的子属性被包含在WSC IE中。  
![这里写图片描述][20160627200823288]  
Vendor Extension头部包含三个部分，分别是Type（值为0x1049）、Length（此处  
的值为9）、Vendor ID①（十进制值为14122，十六进制值为0x00372a）。  
Vendor Extension可包含多个子属性，Vendor Extension包含了Version2  
和Request to Enroll两个子属性。  
“Vendor Extension：00372a000120030101”一行代表的是Vendor Extension的  
Value。它是后面Vendor ID、Version2和Request to Enroll的所有内容。  
Request to Enroll子属性代表Enrollee希望开展后续的EAP-WSC流程。  
**Request Type和Response Type属性**  
![这里写图片描述][20160627201039620]  
如图所示为Request Type和Response Type两个属性的内容左图所示为Request Type，右图所示为Response Type.  
·Request Type属性必须包含于Probe/Association Request帧中，代表STA作为  
Enrollee想要发起的动作。该属性一般取值0x01（含义为Enrollee，open 802.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，故图的Response Type取值为0x03。  
**Configuration Methods和Primary Device Type属性**  
Configuration Methods属性用于表达Enrollee或Registrar支持的WSC配置方法。  
前文提到的PIN和PBC就属于WSC配置方法。考虑到支持Wi-Fi的设备类型很多，例如打  
印机、相机等，故WSC规范定义的WSC配置方法较多。下图所示为Configuration  
Methods属性。  
![这里写图片描述][20160627201254024]  
·Type字段取值为0x1008，Length字段取值为2，代表Value的内容长度为2字节。  
·Configuration Method的Value长度为2字节，共16位。每一位都代表Enrollee或  
Registrar支持的WSC配置方法。  
下图所示为Galaxy Note 2所支持的Method，它支持动态PIN码（即STA能动态生  
成随机PIN码，由Display位表达。静态PIN码由Label位表示）。  
![这里写图片描述][20160627204500710]  
注意Display还需细分为Physical Display或Virtual Display。二者区别是Physical  
Display表示PIN码能直接显示在设备自带的屏幕上，而Virtual Display只能通过其他方式来查看（由于绝大多数无线路由器都没有屏幕，所以用一般情况下，用户只能在浏览器中通过设备页面来查看）PIN码。Keypad表示可在设备中输入PIN码。另外，是否支持PushButton由Push Button位表达。同PIN码一样，它也分Physical Push Button和VirtualPush Button。由于Galaxy Note 2硬件上并没有专门的按钮（它只不过是在软件中实现了一个按钮用来触发Push Button，所以这里的设置为支持Virtual Push Button。  
Primary Device Type属性代表设备的主类型。在Discovery Phase阶段，交互的一方  
可指定要搜索的设备类型（需设置Requested Device Type属性，该属性的结构和取值与Primary Device Type一样）。这样，只有那些Primary Device Type和目标设备类型匹配的一方才会进行响应。  
**Device Password ID和RF Bands属性**  
Device Password ID属性用于标示设备Password的类型，默认值是PIN（值为  
0x0000），代表Enrollee使用PIN码（静态或动态PIN码都可以）。如图6-16所示。  
提示Device Password ID其他可取值包括0x0001（User-Specified）、  
0x0002（Machine-Specified）、0x0003（Rekey）、0x0004（PushButton）等。  
RF Bands代表设备所支持的无线频率，包括2.4G或5G，或者同时支持2.4G和5G。

下面将对不同的帧进行分析,R/O/C分别表示必选项/可选项/条件项。  
（1）beacon帧（ 条件项）  
如果AP开启了WSC功能，那么它的beacon帧里面肯定会携带WSC IE，而且WSC IE里面会包含下表中的attributes，如果AP PIN的功能锁住了（比如因为AP PIN的参数次数太多了），就会携带AP Setup Locked信息.  
![这里写图片描述][20160627134228701]  
![这里写图片描述][20160627134246147]  
Wi-Fi Simple Configuration State：这个属性用于描述AP或STA的WSC配置情况，这些配置包括SSID、加密方法等。值0x01表示“Not Configured”,值0x02表示“Configured”。很显然，为完成配置的STA中，给属性取值为0x01。而AP一般早就配置好了，所以AP取值为0x02.  
AP Setup Locked：这个值为TURE表示AP已经锁定，即不能开展RP协议。以PIN方法为例，如果三次PIN方法失败以后，AP将锁定60秒。如果PIN被锁定，则Beacon帧必须包含这个属性。  
Selected Registrar：该属性的作用是，当AP已选择合适的Registrar后，该属性值为0x01，否则为0x00。对于Standalone AP来说，如果其内部的Registrar组件启动，则设置该值为0x01。  
Device Password ID：该属性用于标示设备Password的类型，默认值是PIN（值为  
0x0000），代表Enrollee使用PIN码（静态或动态PIN码都可以）。Device Password ID其他可取值包括0x0001（User-Specified）、0x0002（Machine-Specified）、0x0003（Rekey）、0x0004（PushButton）等。  
Selected Registrar Configuration Methods：它表示registrar所使用的configure method，如果Selected Registrar设置了。必须包含这个值。  
UUID-E：STA的通用唯一标识符，enrollee的UUID-E，registrar的UUID-R  
AuthorizedMACs：包含在vendor extension属性里面，这个子属性列出了已经注册（表示Enrollee已经注册到registrar中）的STA MAC地址。只有那些在MAC地址列表中的STA才可以开展EAP-WSC流程。注意，已注册的STA MAC地址由Registrar设置给AP。如果registrar不支持该功能，则不能使用该属性。  
Registrar Configuration Methods：AP如果使用的是内部注册方式，这个属性表示AP所支持的配置方法，如果AP是一个NFC设备，那么应该包含Registrar配置方法的子元素。

（2）Association Request 和 Reassociation Request帧  
如果STA想要使用WSC，那么Association Request 和 Reassociation Request帧就会包含WSC IE。注意：1.0 版本中可能没有包含。  
![这里写图片描述][20160627134522666]  
·Request Type属性必须包含于Probe/Association Request帧中，代表STA作为  
Enrollee想要发起的动作。该属性一般取值0x01（含义为Enrollee，open 802.1X），代表该设备是Enrollee，并且想要开展WSC后续流程。它还有一个取值为0x00（含义为  
Enrollee，Info only），代表STA只是想搜索周围支持WSC的AP，而暂时还不想加入某  
个网络。

（3）Association Response 和 Reassociation Response帧  
![这里写图片描述][20160627135338518]  
·Response Type属性代表发送者扮演的角色。对于AP来说，其取值为0x03（含义为  
AP），对于Registrar来说，其取值为0x02，对于Enrollee来说，其取值可为  
0x00（Enrollee，Info only）和0x01（Enrollee，open 802.1X）。Standalone AP也  
属于AP，故图的Response Type取值为0x03。

（4）Probe Request (D-E or D-R) 帧  
![这里写图片描述][20160627135500674]  
![这里写图片描述][20160627135511742]

（5）Probe Response (D-AP/Registrar)帧  
![这里写图片描述][20160627135740043]  
![这里写图片描述][20160627135752379]

1.  Registration Protocol消息的定义  
    这个部分分析出现在Registration Protocol messages中和在AP管理接口中的属性  
    对于选择来in-band方式的用户，一般会要求输入设备的密码到Registrar中，这个密码一般可以从显示器或标签中获得，在等待输入密码的期间，Registrar会向enrollee发送包含有Registrar信息的M2D包，这样就可以让Enrollee支持多种用户接口一方便提示用户适当的信息，然后引导他们选择正确的Registrar。 M3-M7 RP消息通过逐步相互证实来获取对方的设备密码，如果对方都相互知道密码的时候，经过加密的配置数据就会发生交换。消息的加密保护是通过KDK（key derivation key）来实现的，KDK是由Diffie-Hellman secret, nonces, and Enrollee MAC address 计算所得。

注册的初始化过程可能在Enrollee刚上电的时候就发生，当然也有可能Enrollee不会选择尝试去注册，除非用户有明确的这方面的动作。每一个实体的RP消息都是通过nonces和Authenticator attributes来识别的，如果一个接受到的消息并没有携带有效的nonce，也没有携带正确的Authenticator attribute，那么这边消息会被丢弃。如果消息封装在EAP里面进行传输，那么只有IEEE 802.1x的认证服务器才有责任去重传这个消息，推荐的重传超时时间是：重传超时=5s, 个别消息处理超时时间=15s， 整个处理过程总时间=2min。

在使用in-band方法的时候，可能发生一种令人担忧的事情，入侵者可能一直发送请求来引导server分配可用的计算资源，抢占正常用户的服务。解决这种问题一般建议限制次数控制资源。  
M2中的Device Password ID可以和M1中的不同，这就意味着，registrar可能不使用Enrollee使用的Device Password。比如，一个Enrollee想要使用pushbutton的方式进行连接，并在M1消息中将Device Password ID设为pushbutton，但是registrar检测到多个Enrollee都在使用pushbutton的方式，然后决定使用PIN的方式更合适，那么registrar就会在M2中将Device Password ID设为PIN而不是pushbutton，告诉Enrollee在接下来使用PIN。现在的Enrollee中也还有另外一种做法，在发现阶段它会检测是否还有另外一个Enrollee也在使用相同的Device Password ID，如果有，就会让自己先停止，直到没有其他的相同Device Password ID设备时才继续进行，比如两个Enrollee同时按下pushbutton，那么后按的那个设备会停止wps。

WSC-EAP 计算式注释：  
·Description代表UUID、Manufacturer、MAC地址等信息。  
·PKE和PKR代表D-H算法的Enrollee方的Key以及Registrar方的Key。  
·M\*x代表没有包含HMAC-SHA-256结果的第X次消息内容。  
·HMACAuthenKey代表利用AuthenKey和HMAC-SHA-256算法进行计算。  
·ENCKeyWrapKey代表利用KeyWrapKey进行加密。  
·“\[…\]”中的内容为可选信息。  
·N1和N2分别代表Enrollee和Registrar的Nonce。  
||表示串联，不是“或”的关系

**M1**  
![这里写图片描述][20160627213447157]  
**Enrollee ->Registrar: M1 = Version || N1 || Description || PKE**  
M1消息是Enrollee发送给Registrar的，Version是版本信息  
N1：Enrollee生成的nonce信息，用于后面ConfigData的加密译码，每一个对象都会生成一个新的Nonce，同时它也看作一个session ID，每一次对话都用N1和N2进行确认。  
Decription：它表示Enrollee设备的描述信息，这些信息一般都是可读的，而且很有用，但是在EAP的加密交互时一般用不上，也就是在M1-M8 WSC-EAP消息中，这些信息主要是描述信息，包括设备信息（UUID, manufacturer, model number, MAC address, etc）和设备性能（supported algorithms, I/O channels, Registration Protocol role, etc）。  
PKE：Enrollee生成的[Diffie-Hellman公钥][Diffie-Hellman]，它是用这个式子生成的  
*b=g^i mod p, (0<=i<=p-1)*  
其中《Wi-Fi-Simple-Configuration-Technical-Specification-v2-0-x.pdf》有规定：  
The prime is（也就是式中*p*的值）: 2^1536 - 2^1472 - 1 + 2^64 \* \{ \[2^1406 pi\] + 741804 \}  
Its hexadecimal value is:  
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1  
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD  
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245  
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED  
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D  
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F  
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D  
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF  
The generator is(也就是*g*的值): 2.  
i是各自持有的私有秘钥，b是各自算出来的公开秘钥并交给对方， (YB)^XA modq = K =(YA)^XB modq, 这样计算出来的K是共享秘钥，K是最终结果，后面的加密过程就是用K来进行的。后面讨论的共享秘钥就用K\_tmp来表示。  
**M2**  
![这里写图片描述][20160627213607487]  
**Enrollee <- Registrar: M2 = Version || N1 || N2 || Description || PKR\[ || ConfigData \] || HMACAuthKey(M1 || M2\*)**  
N1： Enrollee生成的nonce，它是128位的随机数  
N2：Registrar指定的128位随机数，nonce  
Description：它表示registrar设备的描述信息  
PKR：Registrar生成的Diffie-Hellman公开密钥，Registrar收到PKE时可以算出K\_tmp, Enrollee接收到PKR后，也可以正确的算出共享秘钥K\_tmp的值， 所以Enrollee收到PKR后，基本可以认为双方都获取到了K\_tmp.  
\[ConfigData\]：中括号表示可选项，如果使用的out-of-band的方式，比如NFC，就可能在M2中携带ConfigData信息  
AuthKey: 它是认证服务器的key，由g^AB mod p, N1和N2，Enrollee的MAC地址派生而来。如果M1和M2信息都在同一个通道上传输，那么很难在这个传输过程中入侵，Enrollee的device password就可以在这个key的派生过程中省略，AuthKey主要用于对数据进行单向HMAC。  
HMACAuthKey(M1 || M2\*)：要弄清楚这条语句，要先了解[HMAC][] ，它是消息鉴定码，用来鉴定接收到的信息是否正确。HMAC的生成主要依靠两个输入，KEY（AuthKey）和消息（M1||M2）运用函数H (K XOR opad, H (K XOR ipad, Message))计算出鉴定码。它是一个Authenticator attribute，它是将AuthKey和括号中的内容经过HMAC算法运算后得出的hash值，并将计算好的鉴定码和消息一起发送给对方，用于校验消息的正确性。HMAC是256bit的hash值，为了减少消息的大小，一般只取前64位放在Authenticator attribute里面。再次声明HMAC算法只提供消息的完整性校验而不提供保密性，所以对于这个属性，将它看出CRC或者FCS类的东西更好理解。注意：KEY（AuthKey）不是共享秘钥K\_tmp。

**M2D**  
![这里写图片描述][20160627213754857]  
如果使用的是in-band方式，而且registrar不知道Enrollee的Device Password，它就会向Enrollee发送M2D消息。M2D是用来告诉Enrollee关于registrar的相关信息。Enrollee将会发送一个M3给registrar继续RP交互，直到收到来自registrar的M2消息。

**M3**  
![这里写图片描述][20160627213825123]  
**Enrollee -> Registrar: M3 = Version || N2 || E-Hash1 || E-Hash2 || HMACAuthKey(M2 || M3\*)**  
E-Hash1：E-Hash1 = HMACAuthKey(E-S1 || PSK1 || PKE || PKR)  
它由device password的前半部分（比如PIN方式是前4位，如PIN=12345670，PSK1 = first 128 bits of HMACAuthKey(1234)）和Enrollee生成的128位随机数（E-S1）作为输入，AuthKey作为参数key，结合PKE和PKR运用HMAC-SHA-256算法计算出的鉴定码  
E-Hash2：E-Hash2 = HMACAuthKey(E-S2 || PSK2 || PKE || PKR)  
由device password的后半部分（比如PIN方式是后4位，如PIN=12345670，PSK2 = first 128 bits of HMACAuthKey(5670)）和Enrollee生成的128位随机数（E-S2）作为输入，AuthKey作为参数key，结合PKE和PKR运用HMAC-SHA-256算法计算出的鉴定码  
HMACAuthKey(M2 || M3\*)： 使用M2||M3消息和Authkey生成的鉴定码，用于鉴定消息的正确传输

**M4**  
![这里写图片描述][20160627213925030]  
![这里写图片描述][20160627213958211]  
**Enrollee <- Registrar: M4 = Version || N1 || R-Hash1 || R-Hash2 || ENCKeyWrapKey(R-S1) || HMACAuthKey (M3 || M4\*)**  
R-Hash1：R-Hash1 = HMACAuthKey(R-S1 || PSK1 || PKE || PKR)  
它由device password的前半部分（比如PIN方式是前4位，如PIN=12345670，PSK1 = first 128 bits of HMACAuthKey(1234)）和registrar生成的128位随机数（R-S1）作为输入，AuthKey作为参数key，结合PKE和PKR运用HMAC-SHA-256算法计算出的鉴定码  
R-Hash2：R-Hash2 = HMACAuthKey(R-S2 || PSK2 || PKE || PKR)  
它由device password的前半部分（比如PIN方式是后4位，如PIN=12345670，PSK1 = first 128 bits of HMACAuthKey(1234)）和registrar生成的128位随机数（R-S1）作为输入，AuthKey作为参数key，结合PKE和PKR运用HMAC-SHA-256算法计算出的鉴定码  
ENCKeyWrapKey(R-S1)：这个式子是指使用KeyWrapKey作为秘钥，对R-S1进行对称加密的结果，加密算法是AES-CBC per FIPS 197, with PKCS\#5 v2.0 padding。如果了解TKIP，应该对AES加密算法也不会陌生。  
关于KeyWrapKey  
KDK = HMAC-SHA-256DHKey (N1 || EnrolleeMAC || N2)  
KeyWrapKey是用来进行双向数据加密的，它的长度是128位，用来对私有nonce或ConfigData进行加密，它的计算参数是K\_tmp，N1，Enrollee MAC和N2  
关于R-S1  
它是一个registrar生成的128位的随机数，Enrollee使用它结合R-Hash1可以确认device password的前半部分数字是否正确，也就是说根据式子  
R-Hash1 = HMACAuthKey(R-S1 || PSK1 || PKE || PKR)  
Enrollee知道AuthKey，PSK1，PKE，PKR和R-Hash1的条件下，同时收到Registrar发来的R-S1后，Enrollee就可以计算出一个新的R-Hash与R-Hash1进行比较，如果相等，就可以确认device password的前半部分是正确的；如果不相同，就会发出fail信息，并停止继续交互。

**M5**  
![这里写图片描述][20160627214024696]  
**Enrollee -> Registrar: M5 = Version || N2 || ENCKeyWrapKey(E-S1) || HMACAuthKey (M4 || M5\*)**  
ENCKeyWrapKey(E-S1)： 当Registrar收到E-S1后，根据等式 E-Hash1 = HMACAuthKey(E-S1 || PSK1 || PKE || PKR)  
Registrar就可以根据AuthKey, E-S1, PSK1, PKE, PKR计算出一个新的E-Hash与E-Hash1进行比较，如果相等，就可以确认device password的前半部分是正确的；如果不相同，就会发出fail信息，并停止继续交互。

其实M4和M5就是用来给Enrollee和Registrar相互确认device password的前半部分（PSK1 = first 128 bits of HMACAuthKey(1234)）是正确的。

**M6**  
![这里写图片描述][20160627214055124]  
**Enrollee <- Registrar: M6 = Version || N1 || ENCKeyWrapKey(R-S2) || HMACAuthKey (M5 || M6\*)**  
ENCKeyWrapKey(R-S2)： 当Enrollee收到R-S2后，根据等式 R-Hash2 = HMACAuthKey(R-S2 || PSK2 || PKE || PKR)  
Enrollee就可以根据AuthKey, R-S2, PSK2, PKE, PKR计算出一个新的R-Hash与R-HashR进行比较，如果相等，就可以确认device password的前半部分是正确的；如果不相同，就会发出fail信息，并停止继续交互。

**M7**  
![这里写图片描述][20160627214146484]  
![这里写图片描述][20160627214242277]  
![这里写图片描述][20160627214307794]  
**Enrollee -> Registrar: M7 = Version || N2|| ENCKeyWrapKey(E-S2 \[||ConfigData\]) ||HMACAuthKey (M6 || M7\*)**  
ENCKeyWrapKey(E-S2 \[||ConfigData\])：同理，对应等式  
E-Hash2 = HMACAuthKey(E-S2 || PSK2 || PKE || PKR)  
但是这里有些不同的是条件项\[||ConfigData\]的加入，如果当前的Enrollee是一个AP，就会在M7中携带这个attribute，但是我们一般用的都是standalone模式，不会出现这种情况。

其实M6和M7就是用来给Enrollee和Registrar相互确认device password的后半部分（PSK1 = first 128 bits of HMACAuthKey(5670)）是正确的。

**M8**  
![这里写图片描述][20160627214336794]  
![这里写图片描述][20160627214404436]  
![这里写图片描述][20160627214439157]  
**Enrollee <- Registrar: M8 = Version || N1 || \[ ENCKeyWrapKey(ConfigData) \] || HMACAuthKey (M7 || M8\*)**  
N1：可以看作session ID，避免发错对象  
\[ ENCKeyWrapKey(ConfigData) \]：用KeyWrapKey加密的配置信息，ConfigData就是我们最终需要获取的内容。

**WSC\_ACK Message**  
![这里写图片描述][20160627214525517]  
WSC\_ACK消息是由Enrollee or Registrar发送的，当成功处理了一个消息，但是没有对应的消息回复时就会发送这个信息，比如收到M2D消息，就会回复WSC\_ACK。

**WSC\_NACK Message**  
![这里写图片描述][20160627214553438]  
这个消息是由加入者或认证者发送的，当认证过程或消息处理过程出现了错误，就会向对方发送WSC\_NACK消息  
**WSC\_Done Message**  
![这里写图片描述][20160627214622502]  
这个消息是由Enrollee发送的，当它成功接收并处理了M8消息后会向Registrar发送这个消息，这时表明Enrollee成功获取到了改WLAN的网络接入凭证（Credential）。

**简述**  
M1和M2： 交换共享秘钥  
M3： Enrollee提供己端device password的前半部分和后半部分信息给Registrar （E-Hash1 || E-Hash2）  
M4： Registrar提供己端device password的前半部分和后半部分信息给Enrollee （R-Hash1 || R-Hash2），并提供验证随机数ENCKeyWrapKey(R-S1)给Enrollee  
M5： Enrollee验证Registrar端的device password前半部分正确，并提供ENCKeyWrapKey(E-S1)给Registrar  
M6 : Registrar验证Enrollee端的device password前半部分正确，并提供ENCKeyWrapKey(R-S2)给Enrollee  
M7 : Enrollee验证Registrar端的device password后半部分正确，并提供ENCKeyWrapKey(E-S2）给Registrar  
M8： Registrar验证Enrollee端的device password后半部分正确，并提供ConfigData给Enrollee  
WSC\_Done：Enrollee成功接收并获取ConfigData，回复Registrar WSC\_Done消息  
EAP-Fail： Registrar向Enrollee发送EAP-Fail消息  
Deauthentication： Registrar向Enrollee发送Deauth消息让Enrollee和AP断开关联

断断续续整理了一个多星期，算是把WSC的基本过程理清楚了！后面将对其中的一些细节简单整理一下，然后进行代码的分析。

[20160615112914973]: /images/20220721/fd4de5bc5ce8440c995f2addcb693879.png
[20160615141936122]: /images/20220721/f9628695ca6a4b4d955bf0296cc20235.png
[20160627121932454]: /images/20220721/fe3579bd16154e2db7a1aba7bfacca3f.png
[20160627200823288]: /images/20220721/8e40db6483bf4ac6b70e870239b01d13.png
[20160627201039620]: /images/20220721/0e84ca80beff46a5b0f439994b211627.png
[20160627201254024]: /images/20220721/159bfc5976774da0ac246e96e9a4d72a.png
[20160627204500710]: /images/20220721/5b1091a54f364e708ef70485fe30089f.png
[20160627134228701]: /images/20220721/be97e4f4ade04a8f9c757768aa68b15d.png
[20160627134246147]: /images/20220721/a58a1e71370e406592b05aed19245bda.png
[20160627134522666]: /images/20220721/be8c5434b26c4639bf3ed1c51a044a34.png
[20160627135338518]: /images/20220721/7fb6dccc551a41bc8ee32b08e56acc3e.png
[20160627135500674]: /images/20220721/4891d382cb244e9fafc7a292653c3a2d.png
[20160627135511742]: /images/20220721/994d8e0730b64f2d9b7c4d192c76b1d0.png
[20160627135740043]: /images/20220721/3438e216364c4829a7a13d7128304cc6.png
[20160627135752379]: /images/20220721/3d9d794e943a45a28d05825f428b075e.png
[20160627213447157]: /images/20220721/6a77084adde448e7845787ec971b1e3f.png
[Diffie-Hellman]: http://blog.csdn.net/lee244868149/article/details/51790397
[20160627213607487]: /images/20220721/927d3dc1f039451b97e46083490be935.png
[HMAC]: http://blog.csdn.net/lee244868149/article/details/51794088
[20160627213754857]: /images/20220721/b2e4537eb127406799ba76916b2e319a.png
[20160627213825123]: /images/20220721/e76cb582859240a09fc20d5581e4292f.png
[20160627213925030]: /images/20220721/910fd4c9ad23401f91693d406f2ef220.png
[20160627213958211]: /images/20220721/c786f42db5184e46b3d568930c3dbc61.png
[20160627214024696]: /images/20220721/ca4f3717e5f04ff0a2d5c6e9f27001e8.png
[20160627214055124]: /images/20220721/9eeb34d44cae4f6383d17642c1c0e961.png
[20160627214146484]: /images/20220721/26c7a69c5de3429584248ff2e69346f9.png
[20160627214242277]: /images/20220721/781fcc46560f4f4e9943204b4205eff5.png
[20160627214307794]: /images/20220721/d6328d37b2884432b364ad64ea903173.png
[20160627214336794]: /images/20220721/287091de6342433a8d536cf5bc3c2838.png
[20160627214404436]: /images/20220721/11b4d6db6ded4813b19cec13be01c455.png
[20160627214439157]: /images/20220721/f06bb24e13ee408aaa3679929d437b3a.png
[20160627214525517]: /images/20220721/20e24ccd320d4356bc97125c4016ae2d.png
[20160627214553438]: /images/20220721/476fcc41a2a746a390fa983e669b231c.png
[20160627214622502]: /images/20220721/e855d0a2548047d98c0e9058baa0c3ca.png