一、wifi认证简介

wifi认证在理解上可以简化为两个阶段：获取PMK，然后通过四次握手，把PMK派生成PTK，建立加密通道，后续使用的密钥从PTK上拆分。
wifi认证，个人及企业的密钥生成及分发流程是一致的，区别在于PMK的生成逻辑不一样，以WPA2为例，WPA2-PSK(个人）的PMK是以密码为输入的一个确定性算法（PBKDF2-SHA1）计算出来的，而WPA2-Enterprise是通过EAP协议认证过程中的上下文信息计算出PMK的。当拿到PMK后，后面的流程完全相同。

1、personal

个人版认证方式，通常的使用形式，就是设置一个wifi密码，路由器上设置一个，终端需要接入时，也需要提供相同的密码。通常家庭或一些小型公共场所会提供这种wifi接入方式。目前主流的认证协议为WPA2-PSK/WPA3-SAE。WPA2-PSK认证双方可以直接计算出PMK，而WPA3-SAE通过SAE密钥协商算法计算出PMK。SAE属于PAKE（Password-authenticated key exchange）算法，是Dragonfly算法的一个变种。SAE是安全的PAKE算法，可具有前向安全性，协商过程可以防止中间人攻击。WPA2与WPA3在获得PMK后，使用相同的4次握手流程，但是WPA3要求强度更高的密码学算法。

2、Enterprise

企业级认证主要目的就是支持多用户接入，每个用户都有独立的账号。使用EAP协议进行账号认证。常用的认证方式有：EAP-PEAP,EAP-TLS,EAP-TTLS，其他还有各种不常用的认证方式。EAP-PEAP与EAP-TTLS只是构建了个加密隧道，在加密隧道内进行实际的认证。

3、其他

最常见的方式为开放式+Web认证，提供一个开放式网络，终端连接上网络后，会尝试访问一个地址检测是否可以访问Internet，此时如果终端未经过认证，则重定向到认证地址。类似此种方式安全性很差，不能用于企业级认证。不在此讨论范围内。

二、Enterprise认证协议

1.EAP-TLS

EAP-TLS是目前最安全也是最简单的认证协议，本质上就是一个TLS的双向认证。如图

上图中EAP Server只是为了简化进行的抽象，实际上可能是一个设备，也可能会把其中的认证服务拆分到单独的服务器。常见的，由RADIUS服务来进行实际的认证。这里抽象成EAP Server不影响安全性讨论，后面其实协议也使用相同的抽象方式。

EAP-TLS的主要问题在于，需要企业有自己的PKI，为每个需要登录的员工颁发一张独立的证书。对于没有能力自建PKI的企业，则不能用此种方案，而对于能自建PKI的企业，维护运维一个PKI也是一个不小的开销。

2. EAP-PEAP

PEAP本身不只是一个单向认证，Supplicant对EAP Server进行认证，用于建立一个TLS隧道，在隧道中使用内层的认证协议进行EAP Server对Supplicant的认证。EAP-PEAP支持EAP-MSCHAPv2和EAP-TLS作为内层认证协议。EAP-MSCHAPv2协议是用户密码认证，而在PEAP里面再套一个EAP-TLS显得意义不大，不如直接使用EAP-TLS，没有必要在EAP-TLS外套一层安全性相对较差的EAP-PEAP，所以EAP-PEAP的内置认证算法几乎清一色的是EAP-MSCHAPv2。MSCHAPv2是一个不安全的认证算法，虽然已经使用EAP-PEAP事先构造了加密隧道，但是MSCHAPv2本身使用的算法会造成一些密码存储上的安全问题，具体后面详述。EAP-PEAP规范中，建立TLS隧道使用的是TLS1.0，安全性较差。在微软24年最新的协议文档中，仍然明确写着使用TLS1.0建立隧道。所以，目前不推荐使用EAP-PEAP。

3.EAP-TTLS

EAP-TTLS与EAP-PEAP区别相当小，原理也一模一样，主要还是设计者不同造成的差异。两者最大的区别在于EAP-TTLS支持比EAP-PEAP更多的内层认证协议（如：PAP,CHAP,MSCHAP,MSCHAPv2），包括非EAP协议，还包含EAP协议(如：EAP-MSCHAv2,EAP-TLS)。从总体上来看，EAP-TTLS相比EAP-PEAP差别不大，但是EAP-PEAP没有更新TLS版本，还在使用TLS1.0，而且只有draft版本的RFC，导致安全性不够。EAP-TTLS一直在更新，目前使用最新规范已经弃用了TLS1.0及TLS1.1，支持TLS1.2及TLS1.3。目前，使用TLS1.2及TLS1.3版本的EAP-TTLS，可以建议安全的TLS隧道。如果使用用户名密码认证，使用EAP-TTLS+EAP-MSCHAPv2在安全性会优于EAP-PEAP+EAP-MSCHAPv2.

4.共性问题

以上协议都有一个共同的问题，就是Supplicant认证EAP Server的证书的名称不是强制的，绝大部分企业不会要求用户配置这个信息，同时，Supplicant是否配置都不会影响证书正确时的认证结果。Supplicant不认证EAP Server的证书名称，MITM以及伪造wifi热点有了理论上的可能性。

三、用户名密码认证协议

1.PAP协议

就是简单的明文用户名+密码的认证协议

2.CHAP协议

CHAP协议可以简化为了以下三步：

• 认证服务器向Supplicant发送一个id+随机数的质询（Challenge，也叫挑战)
• Supplicant计算MD5(id+密码+随机数）的响应
• 认证服务器使用Supplicant相同的算法，计算出响应，并与Supplicant发送过来和响应比较

从中可以看出，认证服务器需要维护所有的Supplicant的明文密码在自己的数据库中，这对认证服务器的安全性提出了很高的要求

3.MSCHAPv2

相关算法说明：

3.1PeerResponse

PaddedPasswordHash=MD4(Password)||\0x00\0x00\0x00\0x00\0x00

ChallengeHash=SHA1(PeerChallenge || ServerChallenge|| UserName)[0..7]

PeerResponse=DesEncrypt(ChallengeHash,Key=PaddedPasswordHash[0..6])||DesEncrypt(ChallengeHash,Key=PaddedPasswordHash[7..13])||DesEncrypt(ChallengeHash,Key=PaddedPasswordHash[14..20])

3.2ServerResponse

PasswordHashHash = MD4(MD4(Password))

Magic1[39] = {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74} Magic2[41] = {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 0x6E}

ServerResponse =

"S=" || Hex(SHA1(SHA1(PasswordHashHash||PeerResponse||Magic1)||ChallengeHash||Magic2))

其中，ChallengeHash同3.1

根据上述算法，可以发现攻击者只要拿到ChallengeHash，或者PeerChallenge 、ServerChallenge和UserName以及PeerResponse即可进行暴破，而且第三次Des加密部分，实际有效密钥长度为2个字节，很容易就能计算出PasswordHash的后两个字节，为后续的暴破增加了不少便利。所以，MSCHAPv2同样是一个不安全的算法，不能在不安全信道中使用。

同时也可以看出，认证服务器必须保存所有Supplicant的用户名及密码（明文或者密码的MD4）。虽然数据库可以保存密码的MD4，但不能回加盐，如果数据泄露，也很容易被暴破。也CHAP类似，也对认证服务器的安全性提出很高的要求。

四、省流

企业认证最安全的是EAP-TLS，但是需要企业建PKI设施，成本高，如果无法使用EAP-TLS，则可以使用EAP-TTLS+EAP-MSCHAPv2的方式，但是需要对服务端数据库进行高规格的安全加固。不推荐使用EAP-PEAP，因为其规范太老，没有更新。同时，企业需要通过流程要求接入终端配置需要验证的证书名称。

本文作者：一乐@涂鸦智能安全实验室

漏洞悬赏计划：涂鸦智能安全响应中心（https://src.tuya.com）欢迎白帽子来探索。