Wifi 四次握手认证过程介绍

本文作者:98(信安之路作者团队成员)

如今大家都非常熟悉 WiFi 密码常见的破解手法,可是破解的原理你懂吗?我想很多人都是不知道的,所以今天就来简单的讲解一下。

WiFi 的四次握手是干什么的?

这是 WiFi 身份认证的一个过程,如果没有你的设备没有通过他的身份验证就不能加入他的局域网当中。

WiFi 的四次握手跟破解 WiFi 有什么关系?

我们的 WiFi 跑包就是利用这个进行暴力破解的,抓取握手过程的密钥进行暴力破解

正文开始

我们先看看攻击者在破解一个 WiFi 的流程图(注:此图不分主动扫描和被动扫描)

我们都知道在攻击一个无线信号时,常常需要使用一些专业的设备,而对于 Wifi 的攻击则不需要,因为对于 Wifi 的 "攻击设备" 就是 WiFi 802.11 协议中的管理帧,具体的可以去看我的 《wifi 杀手》文章

WAP/WAP2 算法

WPA = 802.1x + EAP + TKIP +MIC = Pre-shared Key + TKIP + MIC

802.11i(WPA2) = 802.1x + EAP + AES + CCMP = Pre-shared Key + AES + CCMP

想要理解上面的公式,我们需要了解一些其中的专业名词,如下:

(Supplicant 请求者): 任何企图接入 APs 服务集的设备

PSK(Pre-Shared Key, 预共享密钥):PSK 是预共享密钥,是用于验证 L2TP/IPSec 连接的 Unicode 字符串

PMK(Pairwise Master Key, 成对主密钥):认证者用来生成组临时密钥(GTK)的密钥,通常是认证者生成的一组随机数。

GTK(Group Transient Key,组临时密钥):由组主密钥(GMK)通过哈希运算生成,是用来保护广播和组播数据的密钥。

MIC(message integrity code,消息完整性校验码)。针对一组需要保护的数据计算出的散列值,用来防止数据遭篡改。

Nonce: 一个随机生成的值,只使用一次。

PTK(Pairwise Transient Key, 成对临时密钥): 最终用于加密单播数据流的加密密钥。

GTK (Group Temporal Key, 组临时密钥):最终用于加密广播和组播数据流的加密密钥。

知道了这些术语之后,再对比之前的图片,相信你就可以理解了,WAP/WAP2 的四次握手过程通过一系列的密钥交换来实现的。

PTK 包含 3 个部分,KCK(Key Confirmation Key),KEK(Key Encryption Key),TK(Temporal Key)。如图:

当使用不同加密模式的时候所产生的字节是不一样的

当加密方式是 TKIP 时,PTK 长 512 位,按顺序分别为 KCK 占 128 位,KEK 占 128 位,TK 占 128 位, MIC key 占 128 位。

当加密模式是 CCMP 时,KCK128 位,KEK128 位,TK128 位。KEK 和 KCK 是给 EAPOL-Key 加密验证用的,TK 是给后面数据加密用的。

第一个是 EAPOL 密钥确认密钥(简称 KCK),用来计算密钥生成的消息的完整性校验值。第二个 EAPOL 密钥加密密钥(简称 KEK)用来加密密钥生成的消息。

组密钥:

GMK 主组密钥 (group master key) 以作为临时密钥的基础和成对密钥一样扩展获得 GTK (groupTransient Key)

公式如下:

GTK = PRF-X ( GMK,"Group key expansion",AA||GN)

GN - Authenticator 生成的 Nonce

AA - Authenticator MAC 地址

注意和成对密钥扩展不同的是没有 supplicant 的 AA,AN, 如图

其实就是利用主密钥作为临时密钥的基础,通过伪随机函数,组主密钥会被展开成组密钥层次结构。在此并没有产生密钥加密(key encryption)或者密钥确定(key confirmation),因为密钥交换是以成对的 EAPOL 密钥(pairwise EAPOLkey)来进行配密钥的

四次握手过程图:

(资料来自 CWSP 无线认证的书里面,由于 CWSP 全英版本在 CSDA 作者原来可以该名上面找到部分翻译所以就直接借用了)

4-Way Handshake Message 1

首先 Authenticator 向 Supplicant 发送一个携带 ANonce 的 EAPOL-Key frame,

4-Way Handshake Message 2

Supplicant 将获得的 ANonce 和 AA,这个时候 Supplicant 已经拥有 PMK,AA 和 SPA,所以可以通过下面的函数计算出 PTK

PTK = PRF (PMK + ANonce + SNonce + AA + SPA)

Supplicant 根据 ANonce、 自己生成的一个 Nonce( SNonce) 、 自己所设置的 PMK 和 Authenticator 的 MAC 地址等信息进行密钥派生。(MAC(AA)无线网卡 MAC(SPA) AP 产生的随机值(ANonce) WiFi 随机尝试的值(SNonce)PRF(pseudo-random-function))

Supplicant 随后将 SNonce 以及一些信息通过第二个 EAPOL-Key 发送给 Authenticator。 Message 2 还包含一个 MIC 值,该值会被 KCK 加密。 接收端 Authenticator 取出 Message 2 中的 SNonce 后, 也将进行和 Supplicant 中类似的计算来验证 Supplicant 返回的消息是否正确。 如果不正确,这将表明 Supplicant 的 PMK 错误, 于是整个握手工作就此停止。

4-Way Handshake Message 3

如果 Supplicant 密钥正确, 则 Authenticator 也进行密钥派生。 此后, Authenticator 将发送第三个 EAPOL-Key 给 Supplicant, 该消息携带组临时密码( Group Transient Key, GTK, 用于后续更新组密钥, 该密钥用KEK 加密) 、 MIC( 用 KCK 加密) 。 Supplicant 收到 Message 3 后也将做一些计算, 以判断 AP 的 PMK 是否正确。 注意, IGTK( Integrity GTK) 用于加解密组播地址收发的管理帧。

4-Way Handshake Message 4

Supplicant 最后发送一次 EAPOL-Key 给 Authenticator 用于确认,如果认证成功, 双方将安装( Install) Key。 Install 的意思是指使用它们来对数据进行加密。

Controlled Port Unlocked

双方完成认证以后,authenticator 的控制端口将会被打开,这样 802.11 的数据帧将能够正常通过,而且所有的单播数据帧将会被 PTK 保护,所有的组播数据以及广播数据将会被 GTK 保护。

Supplicant 和 Authenticator 就此完成密钥派生和组对, 双方可以正常进行通信了。

由于 PTK 是有 PMK 使用所以他的加密过程是 MAC(AA)+ 无线网卡 MAC(SPA) +AP 产生的随机值(ANonce)+ WiFi 随机产生的值(SNonce)+ 你输入的密码

这个公式是由哈希和 MD5 进行计算得到的,即使你知道 4 个答案你都不能使用这个些答案进行逆推出密码,每次进行认证都是在使用不同的随机的产生的值进行运算

PTK = PRF (PMK + ANonce + SNonce + AA + SPA)

(这个公式还有一些函数不是变量就没有写出来)

当然 PTK 和 PMK 是可以进行转换的公式如下:

PTK ← PRF-X(PMK, “Pairwise key expansion”, Min(AA,SPA) || Max(AA,SPA) ||Min(ANonce,SNonce) || Max(ANonce,SNonce))*

(这个以作者的水平解释不了,希望有大佬解释一下。)

MIC 的算法:

MIC Key=PTK 前 16 个字节。是在第二次握手的时候 ,提取这个 PTK 前 16 个字节组成一个 MIC KEY。在第三次握手的时候提取这个 PTK 前 16 个字节组成一个 MICKEY 使用以下算法产生 MIC 值用这个 MIC KEY 和一个 802.1x data 数据帧使用以下算法得到 MIC 值:

MIC = HMAC_MD5(MIC Key,16,802.1x data)

(我们在握手包里面会知道一些其他的值,但是跟WiFi密码有关的就是这个 MIC)(SSID,AP_MAC,STATION_MAC,SNonce,ANonce,802.1xdata(数据))就是这些值都是我们知道的)

MIC的派生过程(来自百度)

l PSK=PMK=pdkdf2_SHA1(passphrase, SSID, SSID length,4096)

l PTK=SHA1_PRF(PMK, Len(PMK),"Pairwise key expansion",MIN(AA,SA) || Max(AA,SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

l MIC KEY=提取PTK 的前16 个字节

l MIC = HMAC_MD5(MIC Key,16,802.1x data)

以上部分为专业知识和协议所以看起来比较枯燥毕竟是协议不能修改和解释。

暴力破解呢?

别急接下来就是介绍,当我们大概知道上面的四次握手过程我们就可以知道了暴力破解是利用了上面的什么东西进行暴力破解了

暴力破解 WiFi 其实就是利用取消身份认证这个帧进行攻击让客户端在连接 WiFi 的时候会自己断开连接,然后手机会自己再重新连接这个 WiFi,就是在重新连接这个 WiFi 的过程中(手机进行身份验证)攻击者截取到一些有用的密钥进行暴力破解。

原理:

这是一个 CAP 的数据包

里面有非常多的数据,而这个数据包是加密的所以一些重要的信息基本是看不出来的

而 WiFi 密码就在这个数据包里面但是需要验证

字典破解的原理:

以上的图都是作者画的有点丑,但是这样会比只说文字来的实在一些还明白一些。

用我们字典中的 PSK+ssid 先生成 PMK(此步最耗时,是目前破解的瓶颈所在),然后结合握手包中的客户端 MAC,AP 的 BSSID,A-NONCE(随机值),S-NONCE(随机值)计算 PTK,再加上原始的报文数据算出 MIC(MIC 计算是有:pdkdf2_SHA1, SHA1_PRF, HMAC_MD5 这些算法生成的)并与 AP 发送的 MIC 比较,如果一致,那么该 PSK 就是密钥。

总结:

还有说的不好的地方或者解释的不清楚的地方还请大家能在评论区指出来,能让作者看到以改进。作者也只能尽自己最大的努力来解释这个些枯燥的协议,但是协议是协议我们不能随意的修改他。所以作者尽力的给大家画图解释这样会让很多小白能看的懂一些。觉得好就点赞呀!

原文发布于微信公众号 - 信安之路(xazlsec)

原文发表时间:2018-06-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JetpropelledSnake

SNMP学习笔记之SNMPv3报文认证和加密

安全参数存在于snmp消息中的msgSecurityParameters字段,以ASN.1语法定义如下:

2373
来自专栏IT技术精选文摘

非对称加密与安全证书看这一篇就懂了

前几日做支付对接时,被对方文档中的加密方式搞晕乎了一会。意识到证书加密方面的理解不够深入,事后查阅参考资料补习一波。本文是根据期间的学习,以及长期以来的实践做出...

3423
来自专栏吴伟祥

非对称加密与安全证书看这一篇就懂了 转

前几日做支付对接时,被对方文档中的加密方式搞晕乎了一会。意识到证书加密方面的理解不够深入,事后查阅参考资料补习一波。本文是根据期间的学习,以及长期以来的实践做出...

1982
来自专栏Golang语言社区

Go和HTTPS -2

F为签名函数。CA自己的私钥是唯一标识CA签名的,因此CA用于生成数字证书的签名函数一定要以自己的私钥作为一个输入参数。在RSA加密 系统中,发送端的解密函数就...

4337
来自专栏大闲人柴毛毛

聊聊对称/非对称加密在HTTPS中的应用

目前常用的加密算法主要分成三类: 对称加密算法 非对称加密算法 消息摘要算法 在互联网中,信息防护主要涉及两个方面:信息窃取和信息篡改。对称/非对称加密算法能够...

4595
来自专栏小工匠技术圈

【小工匠聊密码学】--密码学--综述

1242
来自专栏安恒网络空间安全讲武堂

jarvisoj-Crypto

jarvisoj-Crypto Medium RSA 题目到手后给了一个公钥和一个密文 ? ? 我们对这个公钥提取信息: ? 可以得到 N = 0xC2636A...

1.2K6
来自专栏空帆船w

Android APK 签名原理

Android APK 签名原理涉及到密码学的加密算法、数字签名、数字证书等基础知识,这里做个总结记录。

3773
来自专栏安智客

GP TEE需支持的加解密算法

GP TEE规范规定了TEE所需支持的加解密算法标准,一张图表示如下(点击看大图) ? 密码学博大精深,而且在不断发展研究我们今天只是简要介绍一下,后期会有针对...

2526
来自专栏CDN及云技术分享

Tls v1.3的里程碑发展

TLS v1.3在TLS v1.2的基础上,吸收了之前的设计,并且做了大量的改进。相对于TLS v1.2,协议更简洁、更安全、性能也更好。以下是对比TLS v....

99921

扫码关注云+社区

领取腾讯云代金券