iFudanNG.1x WLAN网络协议分析实验

【实验目的】

对iFudanNG.1x所使用的WLAN协议进行分析。

【实验准备】

在以太网或者无线Wifi中，数据的接发都是由网卡完成，每个网卡都有一个唯一的MAC地址作为标识。网卡工作于数据链路层，当收到数据包时，会对数据包的目的MAC地址进行检查，并根据网卡驱动的设置对数据包进行过滤，判断是接收还是丢弃。在正常模式下，只接收目的MAC地址是自己的数据包，其他将一律丢弃。要实现嗅探得要将监听主机的网卡设置为混杂模式，因为在混杂模式下，网卡并不检查目的MAC地址，将收到的所有数据都传到上层，使得上层应用软件可以实现数据抓包和分析。

因为windows的网卡好像不能进入混杂模式，所以需要一个支持sniffer的外置USB网卡（在淘宝上买了一个支持抓802.11ac包的网卡）及对应的sniffer网卡驱动，抓包分析软件用的是omnipeek。（了解到这种技术叫做空口抓包）

【实验步骤】

1、获取已连接wifi的信息

首先通过netsh wlan show interfaces命令查看已经连接的WIFI的BSSID和SSID，如下图所示SSID是iFudanNG.1x，BSSID是44:1a:fa:2d:26:a3，协议类型802.11ac，在信道44上，采用CCMP加密。

2、设置抓包选项

在omnipeek新建capture，选中外置USB网卡。

根据之前cmd中显示的，把信道设为4-5220MHz(ac)，括号中表示802.11协议类型。

3、开始抓包

一开始断网，然后选择iFudanNG.1x连接，输入用户名和密码进行认证，在连接成功后停止抓包。

4、查看抓包结果

在左侧菜单栏中选中Wireless中的WLAN中查看结果。

可以看到iFudanNG.1x同一个SSID对应了很多不同的BSSID，在基础设施网络中，BSSID是BSS（Basic Service Set) 中AP的MAC地址。由于学校很大，一个BSS所覆盖的地理范围有限，所以用多个有着相同SSID的BSS组成ESS（Extend Service Set，扩展服务集）。由于使用相同的SSID，当设备在一个ESS中的BSS之间移动时，用户是感知不到的，如同接在同一个AP上一样，但是这对于终端设备是不透明的，因为有BSSID标识BSS。即当学生在校园内移动时，SSID不变，但BSSID随着切换到不同的无线AP在不断变化。

根据之前cmd显示的结果，找到自己设备关联上的AP的MAC地址。（奇怪的一点是本机被识别成了AP而不是STA，应该是和网卡相关）将所有源地址或目的地址是44:1a:fa:2d:26:a3的数据包过滤出来，其中将有关自己设备的mac地址58:a0:23:62:85:86的数据包额外标红。

5、分析数据包

以下是连接iFudanNG.1x的整个过程。

AP广播Beacon信标帧（被动扫描）

从图中可以看到AP会周期性地广播信标帧，使得无线主机得知网络的存在。

信标帧属于管理帧，以下是帧的部分内容。

Beacon Timestamp字段用来同步BSS中的无线主机，BSS的主计时器会定期发送目前已作用的微秒数。当计数器到达最大值时，便会从头开始计数。

Beacon interval字段被设定为100个时间单位，相当于每0.1s传送一次Beacon信号。

Beacon帧中的Capability Information字段表示网络具备的某种特殊功能，无线主机使用这些通稿数据来判断自己是否支持该BSS所有的功能。没有实现Capability Information字段中所有功能的无线主机就无法加入该BSS。从上图中可以看到其中有3位置为1，分别是：

Immediate Block Ack Allowed，Block Ack（BA，块确认）机制是在802.11n中出现的，其通过将多个ACK汇总到一个帧中，一次性回复多个帧的ACK来提高信道效率。其中又分为两类：
- immediate BA 立即应答：适用于高带宽，低时延业务（一般来说都是选用这一种）
- delayed BA 延迟应答：适用于时延可容忍业务
Privacy Enabled，说明有加密功能，即CCMP
ESS Type Network，说明是处于ESS中

Beacon帧中还有很多信息元素（information element，是管理帧的可变长组件），比如说SSID、Supported Rates等，接下来简单介绍一下：

SSID允许网管人员为服务集（service set）指定标识符。试图加入网络的无线主机可以扫描当前区域的所有网络，然后选择指定的SSID加加入。如之前所说，ESS中的所有基本服务区域BSS都会使用相同的SSID。
Supported Rates，802.11网络通过该信息元素来指定其所支持的速率。当移动式无线主机试图加入网络时，会先查看该网络所使用的数据速率。有些速率是强制性的，每个无线主机都必须支持，有些则是选择性的。802.11ac中是6，9，12，18，24，36，48，54Mbps。
Traffic Indication Map（TIM，传输指示映射），由于AP会为处于休睡状态的无线主机缓存帧。每隔一段时间，AP就会尝试传送这些缓存帧给休眠中的无线主机。TIM指示了有哪些无线主机需要接收待传数据。TIM的内容是虚拟位映射（virtual bitmap），这是由2008个位组成的逻辑结构。每个位分别绑定到一个关联标识符。当某个关联标识符有数据缓存时，相应的位就会设成1，否则会设成0。（图中没有数据缓存）
- DTIM Count：代表下一个DTIM（数据待传指示传递信息）帧发送前即将发送的Beacon帧数。这里count=0，说明发出的所有Beacon帧均为DTIM帧。
- DTIM Period：代表两个DTIM帧之间的Beacon interval数。
RSN，健壮安全网络（课上有提到过）。其中Group cipher OUI是00-0F-AC，代表为802.11工作组所拥有，Group cipher Type是4，代表CCMP（RSN中默认）。在Authentication and Key Management（身份验证与密钥管理组）中，count为1，suite list OUI为00-0F-AC-01代表身份验证使用的是802.1X，密钥管理是密钥衍生自预共享密钥（pre-shared key）。RSN Capabilities字段中全部置为0，说明AP不支持预先身份验证等功能。

HT Capability Info，高吞吐量功能信息；HT Operation info，高吞吐量操作信息
VHT Capabilities，802.11ac中加入的字段，用于管理ac的功能；VHT Operation，802.11ac中操作信息
WMM，Wi-Fi多媒体，是一种无线QoS协议，是802.11e协议的一个子集，用于保证高优先级的报文有优先的发送权利，从而保证语音、视频等应用在无线网络中有更好的质量。

无线主机广播Probe Request（主动扫描）

无线主机通过Probe Request（探测请求帧）来扫描所在区域内目前有哪些802.11网络。Probe Request帧中必须包含两个字段：SSID以及Supported Rates。收到Probe Request帧的AP会据此判断对方能否加入网络。

如果Probe Request帧所探查的网络与之兼容，该网络就会以Probe Response帧响应。（下图是抓到的别的无线主机收到的Probe Response）

认证(Authentication)

接下来的两个数据包和无线主机的身份认证相关。

这部分的认证需要和后面802.1X的认证区分开来。802.11要求无线主机在传送帧之前必须确认身份。起初，只要无线主机打算连接到网络，就必须进行802.11身份认证。但是这种认证并无法提供真正有意义的网络安全。因为没有传递或验证任何加密密钥（cryptographic secret），也没有进行相互认证过程。比较正确的看法是将802.11的低级身份验证视为无线主机连接到网络时的提手过程的起点，以及一种对网络表明身份的方式。

无线主机发起身份认证请求

无线主机会先发出身份验证管理帧（无线主机发出的第一个帧），由于网络上MAC地址是独一无二的，所以可以把MAC地址作为身份证明。在Management-Authentication中Auth Algorithm（身份验证算法标识）字段被设为0，代表使用开放系统认证方式。（如果为1说明是共享密钥身份验证）

Auth Seq Num字段被设为1，代表该帧实际上是事务序列中的第一个帧。状态码为0表示操作成功。

AP响应身份认证

AP处理无线主机的身份认证请求后返回结果。响应帧也是子类型为Authentication的管理帧。Management-Authentication字段中同样包含三个元素：Auth Algorithm字段设为0，代表使用开放系统认证方式；序列号+1，设为2；状态码为0表示操作成功，即身份验证成功。

无线主机收到该响应后会发回ACK包确认收到。

关联(Association)

一旦完成身份验证，无线主机就可以跟AP进行关联，以便获得网络的完全访问权。形成关联后AP必须为该无线主机在网络上注册，这样发往无线主机的帧才会转送到该AP。

无线主机向AP请求关联

无线主机向AP发送关联请求帧（Assoc Req）。其中Capability info（性能信息）字段用来指出无线主机所要加入的网络类型。在接受关联请求之前，AP会验证Capability info、SSID和后面的Supported Rated等字段是否匹配网络参数。并且AP会记录无线主机所使用的Listen Intervel（聆听间隔），当无线主机处于休眠状态时，AP需要为它缓存帧。休眠中的无线主机会定时醒来聆听往来消息，来判断是否有帧在AP缓存。Listen Intervel相当于是以Beacon interval为单位计算出的休眠时间。

可以看到后续还有Power Capability和Supported Channels这些性能字段，说明无线主机支持频率管理；有RSN字段说明支持安全访问。

当具备频谱管理能力的无线主机关联到AP时，首先必须在Power Capability信息元素中提供最小与最大的传输功率。AP可以将无线主机所提供的信息纳入关联过程中并且任意使用这些信息。AP可以拒绝传输功率性能太差的无线主机，因为这可能是个隐藏节点。功率过高以至于可能违反管理规定的无线主机也可能会被AP拒绝。【《802.11无线网络权威指南》这本书中说信标帧中会有Country信息元素，记录国家标识符和允许的最大传输功率等等，但是我抓到的信标帧中都没有看到】

然后再关注HT Capability Info（高吞吐量功能信息）：【和之后的Action帧相关】

其中红框的部分代表SM Power Save（spatial multiplexing power save）空间复用节能模式，是802.11n中引入的基于多天线的省电机制（因为我的外置网卡有两根天线）。SMPS基于的原理是：当业务量很少，负载不大时，选择关闭其中部分天线的收发功能来达到省电的目的。但是节点不能贸然关闭自己的天线，因为AP端可能是单流也可能是多流发送，发送流大于接收流的话，会造成无法正确接收。所以节点在SMPS的机制中需要跟AP有沟通，协商并配合完成通道关闭和激活。图中SMPS的标志是01，代表动态SMPS。(之后在Action中也会提到)

AP响应关联

AP对关联请求进行处理，接受关联与否。常见的方式是根据Listen Interval字段推算出帧缓存所需空间，来判断是否允许关联。Listen Interval越久，说明AP需要用更多的内存缓存帧，如果是资源密集的关联就可能被拒绝。

一旦关联请求获准，AP的响应报文中就会把状态码设为0，并且设置关联标识符Association ID。如果关联请求失败，就只会返回状态码并且中止整个过程。

无线主机收到AP的响应后同样会发ACK包进行确认：

无线主机向AP发送Action帧

Action帧的类别为7，代表高吞吐量，HT Action Field为1，代表SM Power Save，相当于是SMPS控制帧。

之前在无线主机向AP请求关联中提到了SMPS，无论是静态SMPS还是动态SMPS，当节点需要1根天线进行收发时，节点发送一个Action帧告诉AP要切换到单流进行发送帧（如果不通知AP的话可能会收不到数据）。

而静态SMPS和动态SMPS的主要区别在于恢复到多流的过程：

静态SMPS中需要发送一个SMPS 静态disable的ACTION帧给AP，来结束单条流的下行，从而恢复到多流。
动态SMPS中当节点发送一个动态模式的action frame后，AP切换到单流发送数据。期间如果节点收到了由AP发出的目的地址是自己的MAC地址的RTS帧，代表接下来将有多流数据传送，AP通知节点需要把天线都打开。节点打开天线后发回CTS帧，表示已经切入多流收发模式。然后AP传送多流数据。

（之前在课上将RTS/CTS预约机制的时候，是节点向AP发送RTS预约信道，但是在动态SMPS中是AP主动发送了一个RTS帧给节点，这让我觉得非常神奇。但是也很好理解，因为AP发送RTS的情况肯定不多见。只要用单播帧就可以有办法实现动态SMPS的恢复，比起再设置一个新的帧类型，用RTS帧是一个很好的办法。）

EAP身份验证

802.1X基于EAP（可扩展鉴别协议）来实现用户认证和密钥分发。802.1X为认证会话过程定义了三个组件：

申请者（supplicant）是寻求访问网络资源的用户机器。
网络访问由认证者（authenticator）控制，认证者只负责链路层的认证交换过程，并不维护任何用户信息。（其实就是AP）
任何认证请求均会被转送至认证服务器（例如RADIUS）进行实际的处理。

整个认证交换过程在逻辑上是通过申请者与认证服务器来完成的，认证者只是扮演中介的角色。申请者与认证者之间（即前端）使用由802.X所定义的EAPover LAN（简称EAPOL）协议，在后端则是通过RADIUS封包来传递EAP。

在802.11网络桑进行EAPOL交换的流程如下图：

其中在EAP-Success之前用户和认证者的细节如下图：

EAPoL-Start

申请者                     认证者                     认证服务器
-----------------------------------------------------------
|      EAPOL-Start ->        |                            |
-----------------------------------------------------------

当申请者需要访问外部网络时，打开802.1X客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求。这时，客户端程序主动发出了EAPOL-Start帧（认证请求报文），开始进行802.1X交换过程，不必等候来自认证者的质询信息。认证者会送出一个Request/Identity帧作为响应。

EAPOL交换和EAP的主要区别在于：申请者可以发出EAPOL-Start帧触发EAP交换，也可以在网络使用完毕后发出EAPOL-Logoff消息解除连接端口的授权。

EAP-PEAP第一阶段

EAP-Request/Identity & EAP-Response/Identity

EAP字段中code为1表示Request，code为2表示Response。

EAP Request中Type为1，代表Identity。当认证者收到EAPoL-Start后，将发出一个Identity类型的请求报文（EAP-Request/Identity）要求用户的客户端程序发送输入的用户名。这既启动了交换过程，也告诉用户在身份验证完成之前网络会丢弃任何传输数据。

EAP客户端会响应请求，发送Response/Identity报文，Type同样为1，Type-Data字段包含了用户名称，这里就是我的学号（总是以明文的形式显示）。认证者接收到后，把EAP-Response报文封装在RADIUS数据包中（RADIUS-Access-Request），转发给认证服务器进行处理。

EAP-Request/MD5-Challenge & EAP-Response/NAK

认证服务器收到认证者转发的用户名信息后，将该信息与数据库中的用户名列表中对比，找到该用户名对应的密码信息，用随机生成的一个MD5 Challenge对密码进行加密处理，同时将此MD5 Challenge放在EAP-Request报文中，再通过RADIUS Access-Challenge报文封装发送给认证者。认证者解封后把EAP-Request/MD5-Challenge转发给申请者。

从上图中看到，转发的EAP-Request中Type为4，代表Request/MD5-Challenge包。MD-5质询相当于RFC 1994所规范的CHAP协议。身份验证请求中包含了给客户端的质询。客户端只要能够成功响应质询，就可以证明它有共享密钥。

质询握手认证协议（Challenge Handshake Authentication Protocol，简称 CHAP) 使用CHAP进行认证时，认证服务器首先会发出质询信息给客户端，而客户端只要能够成功响应质询信息，就可以证明它的确提有共享密钥。 CHAP原本是设计来避免以明文方式传递密码之类的秘密。CHAP的缺点是连接双方都必须知道明文密码。在服务器方面，此密码要不是以明文方式存放，就是尽管经过加密但有办法加以解密，这样服务器软件才能将之还原为明文。无线环境通常不会使用CHAP，除非现有的用户数据库十分庞大，而且所使用的就是CHAP。

申请者收到由认证者传来的MD5 Challenge后，如果申请者支持这种认证方法的话，会用该Challenge对密码部分进行加密处理，生成EAP-Response/MD5 Challenge报文，并发送给设备者。

但是从抓到的response包中看到，Type=3，类型是NAK。NAK仅用于Response帧，表示否定确认，说明用了申请者不支持的认证方法发起请求。申请者把Auth Type设为25，代表支持的认证算法是EAP-PEAP，发送Response/NAK,PEAP包来通知更改认证算法。AP收到后打包成RADIUS-Access-Request报文发给认证服务器。

PEAP（Protected EAP）主要有两个阶段：

建立TLS安全隧道，Server向Client发送证书信息，实现Client对Server的认证
在TLS隧道内通过某种认证方法与PEAP共用，实现Server对Client的认证

EAP-Request/PEAP-start & EAP-Response/TLS-ClientHello

认证服务器收到包后解封，发现申请者不支持MD5质询，但是支持EAP-PEAP，根据配置确定使用EAP-PEAP认证，向认证者发送RADIUS-Access-Challenge报文，里面含有要发送给申请者的EAP-Request/PEAP-start报文，希望开始进行EAP-PEAP认证。AP解封后转发。下图中可以看到Type=25，代表PEAP，Flag中代表PEAP start的位置为1。

申请者收到EAP-Request/PEAP-start报文后，准备建立TLS安全隧道。申请者会发送Client Hello报文，产生一个4字节的Unix时间戳，Client28字节的随机数、客户端支持的加密算法列表、能接受的TLS协议最高版本（这里是1.2）、会话ID、以及压缩方法（目前均为NULL），封装在EAP-Response/TLS-clienthello报文中发送给认证者。认证者封装成RADIUS-Access-Request报文发送给认证服务器。

TLS握手流程如下图所示：

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                      Certificate
                                   <--------      ServerHelloDone
      ClientKeyExchange
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

EAP-Request/TLS-ServerHello & EAP-Response/TLS-ClientKeyexChange

认证服务器收到ClientHello报文后，会生成ServerHello、Certificate、ServerHelloDone报文响应，报文封装在一封EAP报文中，再用RADIUS-Access-Challenge报文封装后发给认证者。认证者解封后将EAP报文转发给申请者。

如下图中所示，ServerHello的部分包括：Server选择的TLS协议版本号（TLS1.0），4字节的Unix时间戳，Server28字节的随机数，选择的加密套件:TLS_RSA_WITH_AES_256_CBC_SHA（密钥交换算法和身份认证算法都是RSA，对称加密算法是AES_256_CBC，消息摘要算法是SHA），并且Server返回一个空的session_id标识会话将不再被缓存从而不会被恢复。

封装在同一个包内的还有ServerCertificate，认证服务器把它本地的RSA证书传给申请者，以便申请者和认证服务器之间可以进行非对称加密保证对称加密密钥的安全性。

RSA的证书有2个作用：

申请者可以对认证服务器的证书进行合法性进行校验。
对Client Key Exchange生成的PreMasterSecret进行公钥加密，保证只有服务端可以解密，确保对称加密密钥的安全性。

EAP-PEAP相较于EAP-TLS的好处就在于只有认证服务器需要使用证书。

可以从Hex view中看到证书：

抓下来的包也可以用wireshark打开，wireshark中可以看的更清楚：

一共给申请者发了2张证书（证书链），认证服务器的证书必须排列在第一位，排在后面的证书可以认证前面的证书。证书中包含RSA公钥，申请者利用该公钥进行后续的密码协商。【因为密钥协商用的是RSA，所以不需要Server Key Exchange这一步。】

最后发送了ServerHelloDone消息，用来表明ServerHello及其相关消息的结束。发送这个消息之后, Server将会等待Client发过来的响应。这个消息意味着Server发送完了所有支持密钥交换的消息，Client能继续它的密钥协商，证书校验等步骤。

【这里omnipeek和wireshark解析的结果有点点不一样。因为证书太长了，分成了3个EAP-Request包发送（前两个包的Flag中More fragments位都置为1），omnipeek应该是每个包单独解析的，并不会组合在一起解析，所以没有解析出后面2个包中TLS的内容，也就没有解析出ServerHelloDone】

因为一共拆分成了3个包，对于前两个包申请者都回一个没有数据的EAP-Response包：

当收到第三个包后，即收到了ServerHelloDone消息之后，申请者验证认证服务器提供的是否是有效的证书，即对网络进行认证，从而可以保证server的合法。

验证合法后，申请者发送ClientKeyExchange，ChangeCipherSpec和Finished，会把三个TLS报文一起封装在EAP-Response/TLS-ClientKeyexChange报文中发给验证者，验证者再封装成RADIUS-Access-Request发送给认证服务器。

ClientKeyExchange，client在本地计算48字节的预备主密钥PreMasterSecret，通过服务器证书中的RSA公钥加密后传输给认证服务器。

在RFC2246 TLS1.0中定义的PreMasterSecret结构如下。48字节中有2字节是ClientHello中发送的Client支持的最高TLS协议版本（防止回退攻击），另外46字节是随机数。Server拿到加密的PreMasterSecret以后，用自己的 RSA 私钥解密。解密以后还需要再次校验 PreMasterSecret中的ProtocolVersion和ClientHello中传递的ProtocolVersion是否一致。

   Structure of this message:
       struct {
           ProtocolVersion client_version;
           opaque random[46];
       } PreMasterSecret;
  
       client_version
           The latest (newest) version supported by the client. 
           This is used to detect version roll-back attacks. 
           Upon receiving the premaster secret, 
           the server should check that this value matches the value 
           transmitted by the client in the client hello message. 
  
       random
           46 securely-generated random bytes.
  
       struct {
           public-key-encrypted PreMasterSecret pre_master_secret;
       } EncryptedPreMasterSecret;

ChangeCipherSpec，ChangeCipherSpec消息由client和server都需要发送，以通知接收方后续记录将在新协商的CipherSpec和密钥下受到保护，消息由值1的单个字节组成。这里是client先发送。（提到的TLS步骤中，只有ChangeCipherSpec是属于改变密码标准协议，其他都是握手协议）
Finished，Finished消息一直会在一个ChangeCipherSpec消息后立即发送，以证明密钥交换和认证过程是成功的。
- Finished消息是第一个被刚刚协商的算法、密钥和机密保护的消息
- Client和Server本地通过Client随机数、Server随机数和PreMasterSecret进行运算处理，生成2个加密密钥，2个HMAC密钥，2个初始IV
- Finished消息的接收者必须验证内容是正确的。一旦一方已经发送了Finished消息且接收并验证了对端发送的Finished消息，就可以在连接上开始发送和接收应用数据
- 所以这要求ChangeCipherSpec消息必须在其它握手消息和结束消息之间被接收，否则无法解密Finished

EAP-Request/TLS-Finished & EAP-Response

认证服务器收到client发出的Finished后进行认证，在RFC2246 TLS1.0中定义的Finished结构如下：

       struct {
           opaque verify_data[12];
       } Finished;

       verify_data
           PRF(master_secret, finished_label, MD5(handshake_messages)
           + SHA-1(handshake_messages)) [0..11];

       finished_label
           For Finished messages sent by the client, the string 
           "client finished". For Finished messages sent 
           by the server, the string "server finished".

       handshake_messages
           All of the data from all handshake messages up to but not
           including this message. This is only data visible at the
           handshake layer and does not include record layer headers.

finished_label：对于由Client发送的结束消息，字符串是”client finished”。对于由Server发送的结束消息，字符串是”server finished”。
handshake_messages：所有本次握手过程的数据（不包括本条Finished，也不包括其他协议，比如改变密码标准协议）。这是只能在握手层中看见的数据且不包含记录层头。这是到目前为止所有在这一节中定义的握手结构体的关联。因为在所有的握手协议中，所有的子消息都没有加密和完整性保护，消息很容易被篡改，如果没有检验，就会出现攻击。为了避免握手期间存在消息被篡改的情况，所以Client和Server都需要校验一下对方的Finished子消息。

Client的Finished消息认证成功后，认证服务器也会发送Change Cipher Spec和Finished信息给Client，经过AP转发后，Client认证Server的Finished信息，认证成功发回无数据的EAP-Response包。

到此握手结束，TLS安全隧道建立好，完成了EAP-PEAP的第一阶段，然后申请者和认证服务器之间使用协商的密钥进行加密传输，然后进行用户身份验证。（需要注意：加密TLS隧道只会存在几毫秒，用于保护用户身份凭证，而不是用于加密802.11数据帧）

EAP-PEAP第二阶段

第二阶段全程都在TLS安全隧道中通信。而且因为认证者和认证服务器之间是通过有线连接，也没有办法抓到RADIUS包。所以这部分是进行了一些理论学习。

第二阶段的具体过程如下图所示：

认证服务器发送Request信息的标识给认证者，认证者提取radius报文中的EAP域，封装成EAP-Request/Identity报文发送给申请者
申请者收到报文后，用TLS生成的密钥对报文进行解密和校验，然后产生认证回应报文，用密钥进行加密和校验，最后封装成EAP-Response/Identity报文发送给认证者，认证者转发给认证服务器，并带上相关的RADIUS的属性，这样反复进行交互，直到认证完成。在认证过程中，认证服务器会下发PMK给申请者。（对于不同的认证方法交互流程不一致，通常的认证方法为：PEAP-MSCHAPV2或者SIM，图中以PEAP-MSCHAPV2为例）
服务器认证申请者成功后，会发送RADIUS-Access-Accept（认证通过报文）给认证者，允许对方访问网络，并包含认证服务器提供的MPPE属性（vendor specific）。
认证者收到RADIUS-Access-Accept报文，会提取MPPE属性中的密钥作为WPA加密用的PMK，然后发送EAP-SUCCESS报文给申请者，并将端口改为授权状态，允许用户通过该端口访问网络。（MPPE：Microsoft Point-to-Point Encryption，是厂商特有的RADIUS属性）

EAPOL-Key

802.1i的链路层加密协议使用了两种密钥。成对密钥（Pairwise Key）用于保护单播流量，即保护无线主机与AP之间往来的数据，产生自前面提到的身份验证信息；组密钥（Group Key）用于保护多播和广播流量，即保护AP至所关联无线主机之间的广播或组播数据，是由AP动态产生然后分配给各个无线主机的。

802.11i规范的派生密钥的机制中，不仅采用了主密钥并以它作为加密协议的输入项。为了防范重放攻击，密钥的交换使用了随机数并且需要经过握手。成对密钥与组密钥分别通过各自的握手加以更新，其中成对密钥是通过四次握手（Four-way Handshake）加以分配。

对于成对密钥，需要用预先定义好的伪随机函数将256位的PMK展开为成对临时密钥（pairwisetransient key，简称PTK)。为了使数据更随机，是根据PMK、申请者与认证者的MAC地址（SMAC和AMAC）、两个作为四次密钥交换握手中产生的随机nonce值（SNonce和ANonce）展开的。

四次握手

复习一下四次握手，四次握手均通过EAPOL-Key帧传送，EAPOL-Key实现了申请者和认证者之间的密钥协商，且该帧只有在认证成功之后才会传送，这样可以避免密钥信息外泄。EAPOL-Key帧也可以用来定期动态更新密钥。

在802.1X认证成功后，申请者与认证者均持有一个共享的成对主密钥PMK，可以开始四次握手。

由AP发起四次握手，认证者先将ANonce传给申请者。Nonce是用于防范重放攻击的随机值。消息本身并未经过确认，但并没有被篡改的危险。如果消息被中间人人更改，握手就会失败并重新执行。
- 至此，申请者已经拥有了PMK、SMAC、AMAC、SNonce、ANonce，所以可以将PMK展开成PTK。
- CCMP的PTK有384位（128*3），前两组128位块在分配过程中被用来保护临时密钥，最后一个128位块用于数据的加密和认证。其中：
  - 第一个是EAPOL密钥确认密钥（EAPOL Key Confirmation Key，即图中的EAPOLMICKey），用来校验密钥生成消息的完整性
  - 第二个是EAPOL密钥加密密钥 (EAPOL Key Encryption Key，即图中的EAPOLEncrKey)，用来加密密钥生成消息
一旦申请者创建好PTK，会立即响应一条EAPOL-Key消息给认证者，包含了SNonce和MIC（Message Integrity Check，消息完整性校验）。认证者收到后，取出SNonce生成自己的PTK，MIC是用来校验申请者发来的消息的完整性（处理第一次握手之外，后面的每个握手报文都会有MIC）。
至此握手双方的PTK均已就绪，这次握手主要是AP把组临时密钥（Group Transient Key，GTK）发送给申请者，并且告知申请者安装PTK和GTK，以便后续能够更新组密钥。GTK以EAPOL密钥加密密钥（EAPOLEncrKey）来加密，整个消息以密钥确认密钥（EAPOLMICKey）来认证。
- 认证者拥有组主密钥（Group master key，GMK）以作为组临时密钥GTK的基础。CCMP中通过伪随机函数，将GMK、认证者的MAC、认证者的Nouce，展开成下图中的组密钥层次结构。
申请者最后会送出确认消息给认证者，告诉认证者已经接收到密钥生成消息，可以开始使用这些密钥。此消息经过密钥确认密钥（EAPOLMICKey）的认证。

双方完成认证以后，认证者的控制端口将会被打开，这样802.11的数据帧将能够正常通过（DHCP配置设定通常会在此刻进行）。所有的单播数据帧将会被PTK保护，所有的组播数据以及广播数据将会被GTK保护。申请者和认证者就此完成密钥派生和组对，双方可以正常进行通信了。从下图中可以看到之后的data帧都是加密的。

当申请者不再需要访问网络，就会送出一个EAPOL-Logoff消息，使连接端口恢复成未授权状态。

完整的EAP-PEAP流程如下图所示：

6、其他抓包尝试

ifudan.stu5g

除了抓iFudanNG.1x的包之外，还抓了宿舍中ifudan.stu5g的包。

选择这个网络点击连接后，会跳转到复旦大学网络接入认证系统，需要输入手机号和对应的密码（如果办了校园卡之后运营商会提供密码），然后才会显示认证成功。

尝试抓了一下包，可以发现认证和关联都和之前一样，但是认证之后就会马上发送DHCP包分配IP地址，之后是通过网络包的形式进行身份认证。（看抓到的包感觉比较复杂，这一块不是很懂，在信标帧中也没有找到RSN信息元素）

然后去看了和网络接入认证系统的数据包，发现账号和密码是以明文的形式写在cookie里，而且这个网络接入认证系统是用http协议而不是https。（那岂不是可以抓到别人的登录包蹭号上网😮）

手机热点

首先看信标帧，区别于iFudanNG.1x中认证算使用的802.1x，这里使用的认证方式是PSK（Pre-shared Key，预共享密钥模式，又称为个人模式），每一个使用者必须输入密码来访问网络。

之后关联结束就直接通过EAPOL-Key进行四次握手：

在使用PSK认证方式中，PMK的产生方式区别于802.1X。在使用PSK认证方式时，PSK就是AP的密码，如果密码不足64位，则使用密码+SSID然后经过Hash得到64字节的PSK。PMK使用PSK前32字节，即256bit。然后重复上述的四次握手流程展开生成PTK。

当四次握手结束后，就可以正常通信，可以发现之后发送的数据包都是加密的了。

7、分析802.11ac

iFudanNG.1x用的协议是：802.11ac（VHT，Very High Throughput），这是基于5G频段的802.11n（HT, High Throughput）技术的演进版本，通过物理层、MAC层一系列技术更新实现对1Gbps以上传输速率的支持，它的最高速率可达6.9Gbps，并且支持诸如MU-MIMO这样高价值的技术。

看了一点点《802.11ac: A Survival Guide》这本书，书中提到802.11ac是从802.11n开始的演变，而不是一个革命性的背离。802.11ac使用了熟悉的技术，并将它们带到一个新的水平。802.11ac和802.11n的区别如图所示，主要的区别还是体现在物理层上：

由于802.11ac可以使用更大的频宽，即可用的信道数量非常有限，所以如何发现辅信道上存在的隐藏节点变得更加重要。所以在MAC层中，802.11ac协议定义了增强的RTS/CTS机制，用来检测任何一个辅信道是否被不同的数据传输所占用，即RTS和CTS支持“动态频宽”模式。在此模式下，假如部分频带已被占用则只在主用信道上回应CTS帧，发送RTS帧的无线主机则可以回落到一个较低的频宽模式。也就是说：如果接收端发现一些信道特别忙，那么将会告知发送者不要用这些信道，发送端动态地回落到低一级的频宽模式上，这将对降低隐藏节点的影响有所帮助。

【实验总结】

本次实验相当于是带我重温了有关802.11连接和安全的知识，在这过程中不断地在抓的包中遇到上课讲到的概念是一件很奇妙的事情（因为我总是觉得学到的知识和实际的应用有很大的差距）。尤其是在分析EAP-PEAP的时候，学的时候也有一点一知半解，在分析包的时候不仅复习了笔记，还查阅了很多资料，其中《802.11无线网络权威指南》这本书对我的帮助特别特别大。

Gast, M. (2006). 802.11 wireless networks : The definitive guide = 802.11无线网络权威指南 (第二版.. ed.). 南京: 东南大学出版社.

通过这本书更详细地了解到了802.11成帧细节、802.11x用户身份认证和RSN的运作方式。

在实验的过程中也解除到了以前不知道的东西，比如说Action帧等等。

然后是做实验的过程中产生的2个疑惑❓：

1、在EAP-PEAP建立TLS隧道的过程中可以发现认证服务器选用的是TLS1.0版本的协议。

但是从2020年3月起，Chrome、Edge、Safari和Firefox这四大Web浏览器厂商就决定停止支持TLS 1.1及TLS 1.0版本安全协议。TLS 1.0版其实是SSL3.0的升级版，于1999年诞生，距今已经20多年了。TLS 1.0版本协议使用的是过时的算法和加密系统，比如SHA-1和MD5，这些算法现在看来还是比较脆弱的。

至于为什么不升级，可能是因为学校里仍有一些机器不支持更高版本的TLS，所以协议一直都没有更新。

2、复旦网络接入认证系统用的是http协议，用户名密码直接以明文形式写在cookie里很不安全，最起码也应该要Hash一下。