安全是无线网络技术中一个很重要的部分,它主要有三个保护点。
* ·数据的完整性(Integrity):用于检查数据在传输过程中是否被修改。
- 数据的机密性(Confidentiality):用于确保数据不会被泄露。
- 身份验证和访问控制(Authentication and Access Control):用于检查受访者的身份。
* * * * *
**提示** 身份验证和访问控制的问题在无线网络中尤为明显。因为Wi-Fi以空气作为传播媒介,这意味着任何人通过类似AirPcap这样的工具就能获取其周围的无线通信数据。而在以太网环境中,虽然网络数据也是通过广播方式发送,但用户需要把网线插到网口中才能监听数据。相信没有哪个公司能随随便便允许一个外人把网线插到其公司内部的网口上。由于无线网络天然就不存在有线网络中这种类似的物理隔离,所以身份验证和访问控制是无线网络中非常重要的一个问题。
* * * * *
无线网络安全技术也是随着技术发展而逐渐在演变,下面介绍其主要发展历程。
* 802.11规则首先提出了WEP(Wired Equivalent Privacy,有线等效加密)。如其名所示,它是为了达到和有线网络同样的安全性而设计的一套保护措施。
* 经过大量研究,人们发现WEP很容易破解。在802.11规范提出新解决方案之前,WFA提出了一个中间解决方案,即WPA(Wi-Fi Protected Access)。这个方案后来成为802.11i草案的一部分。
* 802.11i专门用于解决无线网络的安全问题。该规范提出的最终解决方案叫RSN(RobustSecurity Network,强健安全网络),而WFA把RSN称为WPA2。
本节先介绍WEP,然后介绍RSN中的数据加密,最后将介绍EAP、802.1X和RSNA密匙派生等内容。
* * * * *
**注意** 本书仅介绍数据加密及完整性校验的大致工作流程,而算法本身的内容请读者自行研究。另外,安全知识点中会经常见到Key(密钥)和Password(密码,也叫Passphrase)这两个词。它们本质意思都一样,只不过Password代表可读(human readable,如字符串、数字等)的Key,而Key一般指由算法生成的不可读(如二进制、十六进制数据等)的内容。
* * * * *
**1.WEP介绍**
WEP是802.11规范的元老,在1999年规范刚诞生时就存在了。但随着技术的发展,如今WEP已经无力应付复杂险恶网络环境中的安全问题了。先来介绍WEP中的数据加密。
(1)WEP中的数据加密[16][25][26]
保护数据Confidentiality的一个主要方法就是对所传输的数据进行加密,而WEP采用了流密码(Stream Cipher)对数据进行加密。这种加密方法的原理如图3-30所示。
:-: ![](https://box.kancloud.cn/60388b105f3ec87d2d60a830f16d426a_1111x285.jpg)
图3-30 流密码工作原理
流密码的工作原理如下。
* 源数据通过Key Stream(密钥流)进行加密,加密方式就是异或(XOR),得到密文。
* 接收端得到密文后,再用相同的Key Stream进行异或操作,这样就能得到目标数据。两次异或操作,Key Stream又一样,所以目标数据就是源数据。
* 整个过程中,只要Key Stream保证随机性,那么不知道Key Stream的人理论上就无法破解密文。
根据上述内容可知,流密码安全性完全依赖于Key Stream的随机性,那么怎么生成它呢?一般的做法是:用户输入一个Secret Key(即密码)到伪随机数生成器(PseudoRandom NumberGenerator,PRNG)中,而PRNG会根据这个Secret Key生成密钥流。
下面回到WEP,它的加密处理过程如图3-31所示。
:-: ![](https://box.kancloud.cn/00c5a4f4e3b00f48532b2335157d1a24_1344x577.jpg)
图3-31 WEP加密过程
WEP加密过程如下。
* 左上角PRNG的输入(即随机数种子),包括一个IV(Initialization Vector,初始向量,长24位)和WEP Key(Key长度有40、104和128位。位数越多,安全性越高)。IV的值由设备厂商负责生成。PRNG最终输出Key Stream。
* XOR(即加密)操作的一方是Key Stream,另一方是数据和ICV(Integrity Check Value,完整性校验值)。ICV长32位,其值由CRC-32方法对Data进行计算后得到。XOR操作后的数据即图3-29所示的Encrypted部分。可知Data和ICV都经过了加密。
* 最终的MAC帧数据(frame payload)包括IV以及加密后的Data以及ICV。
再来看WEP的解密过程,如图3-32所示。
:-: ![](https://box.kancloud.cn/e85e0c40211b46def14db3840e69b53c_974x405.jpg)
图3-32 WEP解密过程
WEP解密过程如下。
* 帧数据中的IV和WEP Key共同作为PRNG的输入以得到Key Stream。
* Key Stream和帧数据中的Cipher Text执行异或操作,得到明文(Plaintext)以及ICV。
* 接收端同时对自己解密得到的明文进行完整性校验,得到ICV′。如果ICV和ICV′一样,则数据正确。
* * * * *
**提醒** WEP弱点很多,其最主要的一个问题就是所有数据都使用同一个WEP Key进行加密。至于WEP存在的其他问题,读者可阅读参考资料[25]以获得更详细的信息。
* * * * *
(2)WEP中的身份验证[27][28]
WEP其实并没有考虑太多关于身份验证方面的事情,根据IEEE 802.11-2012规范,本节真正的名字应该叫"Pre-RSNA Authentication",即RSNA出现之前的身份验证。不过由于Pre-RSNA的认证方法和WEP有密切关系,所以一般就叫WEP身份验证。
WEP身份验证有以下两种。
* 开放系统身份验证(Open System Authentication):这种验证其实等同于没有验证,因为无论谁来验证都会被通过。那它有什么用呢?规范规定,如果想使用更先进的身份验证(如RSNA),则STA在发起Authentication请求时,必须使用开放系统身份验证。由于开放系统身份验证总是返回成功,所以STA将接着通过Association请求进入图3-29中的State 3然后开展RSNA验证。
* 共享密钥身份认证(Shared Key Authentication):Shared Key这个词以后还会经常碰到,它表示共享的密码。例如在小型办公及家庭网络(Small Office/Home Office,SOHO)环境中,AP的密码一般很多人(即很多STA)都知道。
* * * * *
**提示** 初看上去,共享密钥身份验证的安全性比开放系统要强,但实际却恰恰相反。因为使用了共享密钥身份验证就不能使用更为安全的RSNA机制。
* * * * *
由于笔者家庭网络就使用了共享密钥身份验证,故这里也简单向读者介绍一下其工作原理,如图3-33所示。
:-: ![](https://box.kancloud.cn/1b0393b543f061230a0318bd1b6910de_1111x479.jpg)
图3-33 共享密钥身份验证原理
由图3-33可知Shared Key验证的方法包括四次帧交互。
* STA(即图中的Client)发送Authentication请求给AP。
* AP收到请求后,通过Authentication Response发送一个质询明文(Challenge Text,长度为128字节)给STA。
* STA取出Challenge Text,通过图3-31所示的WEP加密方法利用自己设置的密钥对质询文进行加密,然后再次发送Authentication Request给AP。
* AP收到第二次Authentication Request帧后,会利用AP的密钥进行解密,同时还要验证数据完整性。如果ICV正确,并且解密后的译文等于之前发送的质询文,则可知STA拥有正确的密码,故STA身份验证通过。
* AP返回验证处理结果给STA。如果成功,STA后续将通过Association请求加入该无线网络。
WEP的介绍就到此为止,下面来介绍RSNA中的数据加密。
**2.RSN数据加密及完整性校验[29][30]**
RSN中数据加密及完整性校验算法有两种,分别是TKIP和CCMP。下面分别来介绍它们。
* * * * *
**规范阅读提示**
规范中还有一种广播/组播管理帧完整性校验的方法,叫BIP(Broadcast/Multicast Integrity Protocol)。请读者自行阅读规范11.4.4节以了解相关内容。
* * * * *
介绍TKIP前,先介绍WPA。WPA是802.11i规范正式发布前用于替代WEP的一个中间产物。相比WEP,WPA做了如下改动。
* WPA采用了新的MIC(Message Integrity Check,消息完整性校验)算法用于替代WEP中的CRC算法。新算法名为Michael。
* 采用TKIP(Temporal Key Integrity Protocol,临时密钥完整性协议)用于为每一个MAC帧生成不同的Key。这种为每帧都生成单独密钥的过程称为密钥混合(Key Mixing)。
(1)TKIP加密
下面简单介绍TKIP的加密过程,如图3-34所示。
:-: ![](https://box.kancloud.cn/90b9b0c5c21a8e4dca13ad7dda9287d4_1162x468.jpg)
图3-34 TKIP加密过程
* 左下角:用于数据完整性校验的Michael算法的输入包括两部分,一部分是MIC Key(由厂商负责实现),另一部分是MAC帧头中的DA、SA、Priority和MAC帧数据。Michael算法的输出为Data和MIC。它们将作为后续加密算法的输入(等同于图3-31中加密前的Data+ICV)。
* 左上角:TKIP的密钥计算分为两部分。首先是第一阶段的密钥混合,其输入有TA(Transmitter Address,32位)、TK(Temporal Key,128位)和TSC(TKIP Sequence Counter,序列号计数器。共48位,此处取其前32位)。此阶段密钥混合段的产物是TTAK(TKIP-mixed Transmit Address and Key,长80位)。注意,TK的来历见后文关于密匙派生的知识。
* 中间部分:Phase 2 key mixing属于密钥计算的第二部分。本阶段计算的输入有TTAK和TSC(取其后16位),其产物可用作后续加密计算的WEP种子(包括一个128位的ARC4密钥以及IV,可参考图3-31)。
* 最后一步:利用WEP的加密方法进行数据加密,其过程即先利用WEP种子和PRNG生成密钥流(由于每一个待加密的帧都会有不同的TSC,导致在进行PRNG前,每次输入都有不同的WEP Key),然后使用XOR操作对Data和MIC进行异或。
由上述内容可知,TKIP将为每一帧数据都使用不同的密钥进行加密,故其安全性比WEP要高。另外,由于生成密钥和计算完整性校验时会把MAC地址(如DA、SA、TA)等信息都考虑进去,所以它可以抵抗几种不同类型的网络攻击[30]。不过,从加密本身来考虑,TKIP和WEP一样都属于流密码加密。
(2)CCMP加密
CCMP出现在WPA2中,它比TKIP更安全,因为它采用了全新的加密方式CCMP(Counter Mode with CBC-MAC Protocol,计数器模块及密码块链消息认证码协议),这是一种基于AES(Advanced Encryption Standard,高级加密标准)的块的安全协议。
CCMP加密过程如图3-35所示。
:-: ![](https://box.kancloud.cn/683237c2c02e10115002ad4a366aef38_1182x407.jpg)
图3-35 CCMP加密过程
* 左下角:PN(Packet Number,帧编号,48位)和KeyId(Key Identifier,密钥标示符,每帧使用一个密钥)共同构成一个8字节的CCMP头(CCMP Header)。另外,每一帧的PN都会累加,所以图中有一个"Increment PN"处理框(注意,重传包的PN不累加)。
* 左上角:Plaintext MPDU(注意不是MSDU)意味着整个MAC帧(包括Head)都是输入参数。MPDU被拆分成三个部分,其中A2(Address 2字段)、Priority和PN共同构成Nonce(即临时的随机数,用一次后就丢弃不再使用)。MPDU中的MAC头信息将构成AAD(Additional Authentication Data,附加认证数据)。
* AAD、Nonce、MPDU中的MAC数据(Payload)以及TK(Temporary Key)共同作为加密算法的输入,最终得到加密后的数据及消息校验码(Message Integrity Check,MIC)。
* CCMP Header、MAC Header、加密后的Data以及MIC共同构成了MPDU包。
关于RSN中的加密算法TKIP及CCMP就介绍到此。由于加解密工作上由硬件来完成,读者仅需了解其中涉及的概念即可。
**3.EAP和802.1X介绍**
从本节开始,我们将重点关注安全主题中最后一个重要部分,即身份验证。首先介绍EAP,然后介绍802.1X。
* * * * *
**提示** wpa_supplicant很大一部分内容就是在处理身份验证,所以本节也将花费较多的笔墨来介绍相关内容。
* * * * *
(1)EAP[31][32][33]
目前身份验证方面最基础的安全协议就是EAP(Extensible Authentication Protocol),协议文档定义在RFC3748中。EAP是一种协议,更是一种协议框架。基于这个框架,各种认证方法都可得到很好的支持。下面来认识EAP协议。首先介绍其中涉及的几个基本概念。
* Authenticator(验证者):简单点说,Authenticator就是响应认证请求的实体(Entity)。对无线网络来说,Authenticator往往是AP。
* Supplicant(验证申请者①)发起验证请求的实体。对于无线网络来说,Supplicant就是智能手机。
* BAS(Backend Authentication Server,后端认证服务器):某些情况下(例如企业级应用)Authenticator并不真正处理身份验证,它仅仅将验证请求发给后台认证服务器去处理。正是这种架构设计拓展了EAP的适用范围。
* AAA(Authentication、Authorization and Accounting,认证、授权和计费):另外一种基于EAP的协议。实现它的实体属于BAS的一种具体形式,AAA包括常用的RADIUS服务器等。在RFC3748中,AAA和BAS的概念可互相替代。
* EAP Server:表示真正处理身份验证的实体。如果没有BAS,则EAP Server功能就在Authenticator中,否则该功能由BAS实现。
EAP架构如图3-36所示。
:-: ![](https://box.kancloud.cn/9d794bab916e6bb649a1e3dcad6ae604_816x480.jpg)
图3-36 EAP架构
由图3-36所示,Supplicant通过EAPOL(EAP Over LAN,基于LAN的扩展EAP协议)发送身份验证请求给Authenticator。图中的身份验证由后台验证服务器完成。如果验证成功,Supplicant就可正常使用网络了。
下面来认识EAP的协议栈,如图3-37所示。
:-: ![](https://box.kancloud.cn/54e4784ec3d2114f9a17308b7bbc1bd4_1134x397.jpg)
图3-37 EAP协议栈
由图3-37可知,EAP没有强制定义位于最底层(Lower Layer,LL)的传输层。目前支持EAP协议的网络有PPP、有线网(EAPOL,也就是802.1X协议)、无线网络(即802.11 WLAN)、TCP、UDP等。另外,LL本身的特性(例如以太网和无线网都支持数据重排及分片的特性)会影响其上一层EAP的具体实现。
* EAP Layer用于收发数据,同时处理数据重传及重复(Duplicate)包。
* EAP Supplicant/Authenticator Layer根据收到EAP数据包中Type字段(见下文介绍)的不同,将其转给不同的EAP Method处理。
* EAP Method属于具体的身份验证算法层。不同的身份验证方法有不同的Method Type。
EAP协议的格式非常简单,如图3-38所示。
:-: ![](https://box.kancloud.cn/2d53ef4cc63cd7693b101a202e34fff3_1054x242.jpg)
图3-38 EAP协议格式
* Code:EAP协议第一字节,目前仅有四种取值,分别为1(Request)、2(Response)、3(Success)、4(Failure)。
* Identifier:消息编号(ID),用于配对Request和Response。
* Length:2字节,用于表示EAP消息包长度(包括EAP头和数据的长度)。
* Data:EAP中具体的数据(Payload)。当Code为Request或Response的时候,Data字段还可细分为Type以及Type Data。Type就是图3-37中的EAP Method Type。
EAP Method Type取值如下。
* 1:代表Identity。用于Request消息中。其Type Data字段一般将携带申请者的一些信息。一般简写为EAP-Request/Identity或者Request/Identity。
* 2:代表Notification。Authenticator用它传递一些消息(例如密码已过期、账号被锁等)给Supplicant。一般简写为Request/Notification。
* 3:代表Nak,仅用于Response帧,表示否定确认。例如Authenticator用了Supplicant不支持的验证类型发起请求,Supplicant可利用Response/Nak消息以告知Authenticator其支持的验证类型。
* 4:代表身份验证方法中的MD5质询法。Authenticator将发送一段随机的明文给Supplicant。Supplicant收到该明文后,将其和密码一起做MD5计算得到结果A,然后将结果A返回给Authenticator。Authenticator再根据正确密码和MD5质询文做MD5计算得到结果B。A和B一比较就知道Supplicant使用的密码是否正确。
* 5:代表身份验证方法为OTP(One Time Password,一次性密码)。这是目前最安全的身份验证机制。相信网购过的读者都用过它,例如网银付费时系统会通过短信发送一个密码,这就是OTP。
* 6:代表身份验证方法为GTC(Generic Token Card,通用令牌卡)。GTC和OTP类似,只不过GTC往往对应一个实际的设备,例如许多国内银行都会给申请网银的用户一个动态口令牌。它就是GTC。
* 254:代表扩展验证方法(Expanded Types)。
* 255:代表其他试验性用途(Experimental Use)。
图3-39所示为一个简单的EAP交互。第三和第四步时,Authenticator要求使用MD5质询法进行身份验证,但Supplicant不支持,故其回复NAK消息,并通知Authenticator使用GTC方法进行身份验证。第六步中,如果Supplicant回复了错误的GTC密码时,Authenticator可能会重新发送Request消息以允许Supplicant重新尝试身份验证。一般认证失败超过3次才会回复Failure消息。
:-: ![](https://box.kancloud.cn/258a94e6004df0bc8e626c1d0e3d78ec_839x597.jpg)
图3-39 EAP交互
EAP的基本情况就介绍到此,读者可通过RFC3748了解它的详细情况。下面介绍802.1X。
* * * * *
**提示** 可阅读参考资料[32]以了解EAP的其他几种验证方法。
* * * * *
(2)802.1X[34][35]
802.1X是802.1规范家族中的一员。简单来说,802.1X详细讨论了EAP在Wired LAN上的实现,即EAPOL。先来认识802.1X中的两个重要概念,如图3-40所示。
由图3-40可知,802.1X定义了:Controlled Port和UnControlled Port(受控和非受控端口)。
Port是802.1X的核心概念,其形象和我们常见的以太网中网口很类似。Port的定义和图3-4中所述的定义一样。802.1X定义了两种Port,对于UnControlled Port来说,只允许少量类型的数据流通(例如用于认证的EAPOL帧)。Controlled Port在端口认证通过前(即Port处于Unauthorized状态),不允许传输任何数据。
803.802.1X身份验证通过后,Control Port转入Port Authorized状态。这时,双方就可通过Controlled Port传递任何数据了。
* * * * *
**提示**
802.1X-2010文档只有200来页,但难度不小,引用的参考资料也非常多。建议读者看完本节后再结合实际需求去阅读它。另外802.1X中还定义了一个很重要对象叫PAE(PortAccess Entity)。Entity的概念在3.3.1节曾介绍过,它代表封装了一组功能的模块。在802.1X中,PAE负责和PACP(Port Access Control Protocol)协议相关的算法及处理工作。PAE分为
Supplicant PAE和Authenticator PAE两种。
* * * * *
下面来看EAPOL的数据格式,如图3-41所示。
:-: ![](https://box.kancloud.cn/5adde21b3d817b35a05674818279c34e_643x502.jpg)
图3-40 802.1X中的Port
:-: ![](https://box.kancloud.cn/90cc342a8e8037729907590d4b0e1c18_600x301.jpg)
图3-41 EAPOL格式
由图3-41可知EAPOL消息格式如下。
* Protocol Version:占1字节,代表当前使用的802.1X版本号。值为0x03代表802.1X-2010,值为0x02则表示802.1X-2004,值为0x01表示802.1X-2001。
* Packet Type:EAPOL对EAP进行了扩展,该字段取值详细内容见表3-14。
* Packet Body Length:指明Packet Body的长度。
EAPOL消息中最重要的是Packet Type,目前规范定义的几种常见取值如表3-14所示。
:-: ![](https://box.kancloud.cn/625aba065eaa71988c9375b8c4108ebd_1267x317.jpg)
表3-14 EAPOL消息中Packet Type常见取值
EAPOL-Key用于交换身份验证过程中使用的密钥信息,其对应的Packet Body格式如图3-42所示。Descriptor Type表示后面Descriptor Body的类型。802.1X中,Descriptor Type值为2时,Descriptor Body的内容由802.11定义。此处给读者展示一个实际的例子,如图3-43所示。
:-: ![](https://box.kancloud.cn/a765984b6ddbcd60671aa09817409519_741x245.jpg)
图3-42 EAPOL-Key帧对应的Body格式
:-: ![](https://box.kancloud.cn/de56e10cd39b8c16f741a61b67d2abf7_753x628.jpg)
图3-43 EAPOL-Key帧实例
图3-43中:
* 0x888e代表EAPOL在802.11帧中的类型。
* Key Descriptor Type值为2,表示EAPOL RSN Key。
* Descriptor Body的内容就是大括号中所包含的信息。其细节请读者阅读802.11第11.6.2节。
最后,看看用MD5质询算法作为身份验证的EAPOL认证流程,如图3-44所示。
:-: ![](https://box.kancloud.cn/bd81b6972052780826755203f2da3545_890x689.jpg)
图3-44 EAPOL认证流程
* Supplicant主动向Authenticator发送EAPOL-Start消息来触发认证。注意,EAPOL-Start消息不是必需的。
* Authenticator收到EAPOL-Start消息后,将发出EAP-Request/Identity消息以要求Supplicant输入用户名。由于EAPOL-Start消息不是必需的,所以一个未经验证的Supplicant发送了其他数据包也将触发Authenticator发送EAP-Request/Identity消息。
* Supplicant将用户名信息通过EAP-Response/Identity消息发送给Authenticator。Authenticator再将它经过封包处理后(转换成RADIUS Access-Request消息)送给AS(Authenticator Server)进行处理。
* AS收到Authenticator转发的用户名信息后,将其与数据库中的用户名表对比,找到该用户名对应的密码信息。然后随机生成的一个MD5质询文并通过RADIUS Access-Challenge消息发送给Authenticator,最后再由Authenticator转发给Supplicant。
* Supplicant收到EAP-Request/MD5 Challenge消息后,将结合自己的密码对MD5质询文进行处理,处理结果最终通过EAP-Response/MD5 Challenge消息经由Authenticator返回给AS。
* AS将收到RADIUS Access-Request消息和本地经过加密运算后的密码信息进行对比,如果相同,则认为该Supplicant为合法用户,然后反馈认证成功消息(RADIUS Access-Accept和EAP-Success)。
* Authenticator收到认证通过消息后将端口改为授权状态,允许Supplicant访问网络。注意,有些Supplicant还会定期向Supplicant发送握手消息以检测Supplicant的在线情况。如果Supplicant状态异常,Authenticator将禁止其上线。
* Supplicant也可以发送EAPOL-Logoff消息给Authenticator以主动要求下线。
至此,我们对EAP和802.1X进行了简单介绍,EAP和802.1X的目前是为了进行身份验证,二者有自己的数据格式。如果没有特殊需要,掌握上述知识就可以了。
* * * * *
**提示** 后续分析wpa_supplicant时还将对802.1X进行更为详尽的介绍。
* * * * *
下面介绍安全部分最后一个内容,RSNA。
**4.RSNA介绍[36][37]**
RSNA(Robust Secure Network Association,强健安全网络联合)是802.11定义的一组保护无线网络安全的过程,是一套安全组合拳。这套组合拳包含的过程如图3-45所示。RSNA包括如下过程。
:-: ![](https://box.kancloud.cn/72809173507a2c4197d9ccc0d8d90bba_909x402.jpg)
图3-45 RSNA过程
1)RSNA网络发现阶段。当STA扫描无线网络时,需检查Beacon帧或Probe Response帧中是否有RSNE信息元素。如果有,STA根据RSNE处理原则选择合适的AP并完成802.11Authentication(设置认证类型为Open System Authentication)和Association。
2)上一步建立的安全保护机制非常弱,所以RSNA的第二步工作是开展802.1X认证。目的是利用802.1X认证机制实现有效安全的认证用户身份,同时还需要分配该次会话所需要的一系列密钥用于后续通信的保护。
3)RSNA通过4-Way Handshake和Group Key Handshake协议完成RSNA中的密钥管理工作。密钥管理工作主要任务是确认上一阶段分配的密钥是否存在,以及确认所选用的加密套件,并生成单播数据密钥和组播密钥用于保护数据传输。当上面三个步骤都完成后,RSNA网络就建立成功。由上所述,我们发现RSNA包括两个主要部分。
* 在数据加密和完整性校验方面,RSNA使用了前面章节提到的TKIP和CCMP。TKIP和CCMP中使用的TK(Temporary Key)则来自于RSNA定义的密钥派生方法。
* 密钥派生和缓存。RSNA基于802.1X提出了4-Way Handshake(四次握手协议,用于派生对单播数据加密的密钥)和Group Key Handshake(组密钥握手协议,用于派生对组播数据加密的密钥)两个新协议用于密钥派生。另外,为了加快认证的速度,RSNA还支持密钥缓存。密钥派生和缓存的详情见下文。
RSNA中,我们仅介绍涉及的密钥派生和缓存。
为什么要进行密钥派生呢?它涉及密码安全方面的问题,不过其目的并不难理解。在WEP中,所有STA都使用同一个WEP Key进行数据加密,其安全性较差。而RSNA中要求不同的STA和AP关联后使用不同的Key进行数据加密,这也就是RSNA中Pairwise(成对)概念的来历。
:-: ![](https://box.kancloud.cn/97e128f91988cccefb5e26ce0e8ed4e4_910x385.jpg)
图3-46 Pairwise的概念
图3-46展示了Pairwise Key的含义,不过该图是否表明AP需要为不同的STA设置不同的密码呢?这显然和现实情况是违背的。因为现实生活中,我们关联多个STA到同一个AP时使用的都是相同的密码。
如何解决不同STA使用不同密码的问题呢?原来,我们在STA中设置的密码叫PMK(Pairwise Master Key,成对主密钥),其来源有两种。
* 在SOHO网络环境中,PMK来源于预共享密钥(Pre-Shared Key,PSK)。Shared Key概念在3.3.7节介绍WEP身份验证时提到过,即在家用无线路由器里边设置的密码,无须专门的验证服务器,对应的设置项为"WPA/WPA2-PSK"。由于适用家庭环境,所以有些无线路由器设置界面中也叫"WPA/WPA2-个人"(WFA认证名为"WPA/WPA2-Personal")。
* 在企业级环境中,PMK和Authenticator Server(如RADIUS服务器)有关,需要通过EAPOL消息和后台AS经过多次交互来获取。这种情况多见于企业级应用。读者可在无线路由器设置界面中见到"WPA/WPA2-企业"(有时叫“WPA或WPA2”,WFA认证名为"WPA/WPA2-Enterprise")的安全类型选项,并且会要求设置RADIUS服务器地址。
Personal模式和Enterprise模式中PMK的来源如图3-47所示。
:-: ![](https://box.kancloud.cn/5f5d8752a9530e7f1386e2202089f983_1233x542.jpg)
图3-47 PMK来源
图3-47中:
* Personal模式不需要RADIUS服务器参与。AP和STA双方的Key属于PSK,即事先就配置好了。
* Enterprise模式下,STA、AP和RAIDUS的PMK通过多次EAPOL消息来获取。获取的方法和具体的EAP Method有关。显然,相比Personal模式,这种方式更加安全,但其耗费的时间也较长。
* STA和AP得到PMK后,将进行密匙派生以得到PTK。最后,PTK被设置到硬件中,用于数据的加解密。
* 由于AP和STA都需要使用PTK,所以二者需要利用EAPOL Key帧进行信息交换。这就是4-Way Handshake的作用。其详情见下文。
有了PMK后,AP和STA将进行密钥派生,正是在派生的过程中,AP和不同STA将生成独特的密钥。这些密钥用于实际的数据加解密。由于STA每次关联都需要重新派生这些Key,所以它们称为PTK(Pairwise Transient Key,成对临时Key),PTK如图3-47所示。
* * * * *
**提示** WFA要求目前生产的无线设备必须通过WPA2认证。
* * * * *
RSNA中,针对组播数据和单播数据有不同的派生方法,即单播数据和组播数据使用不同的Key进行加密。本书仅介绍单播数据密钥的派生方法,如图3-48所示。输入PMK长256位(如果用户设置的密钥过短,规范要求STA或AP将其扩展到256位),通过PRF(Pseudo RandomFunction,伪随机数函数)并结合S/A(Supplicant/Authenticator)生成的Nonce(这两个Nonce将通过4-Way Handshake协议进行交换)以及S/A MAC地址进行扩展,从而派生出TKIP和CCMP用的PTK。
:-: ![](https://box.kancloud.cn/e52361d2c3faba4914c9ce961f4348f0_900x373.jpg)
图3-48 单播数据密钥派生方法
图3-48中分别描述了TKIP PTK和CCMP PTK的组成。
* EAPOL KCK(Key Confirmation Key)用于计算密钥生成消息的完整性校验值。
* EAPOL KEK(Key Encryption Key)用来加密密钥生成消息。
这两个EAPOL Key将用于后续EAPOL Key帧中某些信息的加密。TKIP TK和CCMP TK就是TKIP和CCMP算法中用到的密钥。
明白密钥派生的作用了吗?简单来说,WEP中,网络中传输的是用同一个Key加密后的数据,其破解的可能性较大。而TKIP和CCMP则把PMK保存在AP和STA中,实际数据加密解密时只是使用PMK派生出来的Key,即PTK。
* * * * *
**提示** 关于TKIP PTK和CCMP PTK等其他信息,请读者阅读参考资料[30]。
* * * * *
由于密钥派生时需要STA和AP双方的Nonce等其他一些信息,所以二者还需通过4-WayHandshake以交换双方的信息,其过程如图3-49所示[24]。
:-: ![](https://box.kancloud.cn/79ce9fa930617b0d199f325b7c45d54d_759x674.jpg)
图3-49 4-Way Handshake流程
* * * * *
**注意** 4-Way Handshake除了用于交换STA和AP信息外,还可用于AP和STA之间相互判断对方是否有正确的PMK。
* * * * *
图3-49所示的4-Way Handshake工作过程如下。
1. Authenticator生成一个Nonce(ANonce),然后利用EAPOL-Key消息将其发给Supplicant。
2. Supplicant根据ANonce、自己生成的一个Nonce(SNonce)、自己所设置的PMK和Authenticator的MAC地址等信息进行密钥派生。Supplicant随后将SNonce以及一些信息通过第二个EAPOL-Key发送给Authenticator。Message 2还包含一个MIC值,该值会被图3-48中的KCK加密。接收端Authenticator取出Message 2中的SNonce后,也将进行和Supplicant中类似的计算来验证Supplicant返回的消息是否正确。如果不正确,这将表明Supplicant的PMK错误,于是整个握手工作就此停止。
3. 如果Supplicant密钥正确,则Authenticator也进行密钥派生。此后,Authenticator将发送第三个EAPOL-Key给Supplicant,该消息携带组临时密码(Group Transient Key,GTK,用于后续更新组密钥,该密钥用图3-48中的KEK加密)、MIC(用KCK加密)。Supplicant收到Message 3后也将做一些计算,以判断AP的PMK是否正确。注意,图中IGTK(Integrity GTK)用于加解密组播地址收发的管理帧,本书不讨论。
4. Supplicant最后发送一次EAPOL-Key给Authenticator用于确认。
5. 此后,双方将安装(Install)Key。Install的意思是指使用它们来对数据进行加密。
Supplicant和Authenticator就此完成密钥派生和组对,双方可以正常进行通信了。
* * * * *
**提示** 由于篇幅原因,请读者阅读参考资料[38]以了解GTK的产生和作用。另外,4.5.5节“EAPOL-Key交换流程分析”将结合wpa_supplicant的代码详细介绍4-Way Handshake相关的内容。
* * * * *
另外,802.11还支持“混合加密”,即单播和组播使用不同的加密方法,例如单播数据使用CCMP而组播数据使用TKIP进行加密。注意,有些加密方法不能混合使用,例如组播数据使用CCMP加密,单播数据就不能使用TKIP。详情见参考资料[39]。
* * * * *
**提示**
混合加密的主要目的是为了解决新旧设备的兼容性问题。它对应的应用场景如下。
1. AP支持TKIP和CCMP,属于新一代的设备。
2. 一些老的STA只支持TKIP,而一些新的STA支持TKIP和CCMP。
对于单播数据来说,AP和STA的密钥是成对的。所以对于老STA,AP和它们协商使用TKIP。对于新STA,AP和它们协商使用CCMP。而对于组播数据来说,所有STA、AP都使用同一个密钥,加解密方法也只能是一样的。在这种情况下,大家只能使用TKIP而不能使用CCMP对组播数据进行加解密了。
* * * * *
下面我们来介绍密钥缓存。
根据前述内容可知,PMK是密钥派生的源,如果认证前,STA没有PMK,它将首先利用图3-47右图所示的802.1X协商步骤以获取PMK(当然,对于SOHO环境中所使用的PSK而言,则不存在这种情况)。由于802.1X协商步骤涉及多次帧交换,故其所花费时间往往较长。在这种情况下,STA缓存这个得来不易的PMK信息就可消除以后再次进行802.1X协商步骤的必要,从而大大提升整个认证的速度。
根据802.11规范,PMK缓存信息的名称叫PMKSA(PMK Security Association),它包括AP的MAC地址、PMK的生命周期(lifetime),以及PMKID(PMK IDentifier,用于标示这个PMKSA,其值由PMK、AP的MAC地址、STA的MAC地址等信息用Hash计算得来)。
当STA和AP进行关联(或重关联)时:
* STA首先根据AP的MAC地址判断自己是否有缓存了的PMKSA,如果有则把PMKID放在RSNE中然后通过Association/Reassociation Request发送给AP。
* AP根据这个PMKID再判断自己是否也保持了对应的PMKSA。如果是,双方立即进入4-Way Handshake过程,从而避免802.1X协商步骤。
**5.无线网络安全相关知识总结**
本节对无线网络安全技术进行一个总体介绍,其中所涉及的概念、缩略词较多,这里给读者简单总结一下其中的逻辑关系。
无线网络安全要解决的是数据的Confidentiality和Integrity以及使用者的Authentication这三个问题。
* 规范最早定义的WEP本来目的是解决数据完整和机密性的问题,后来WEP中附带完成了Authentication检查。不过整体保护机制非常弱。
* 在802.11i正式出台前,WFA提供了安全机制比WEP强的TKIP。注意,TKIP本身只能解决数据完整和机密性问题。而802.11i出台后,又增加了一个更强健的加密算法CCMP(有时候也叫AES)。AES和TKIP都用于解决数据完整和机密性问题。
* 为了解决Authentication问题,规范借鉴802.1X,从而引出RSNA,它包括密钥派生、缓存等内容。
* * * * *
**提示**
无线网络安全的内容非常多,读者不妨阅读参考资料[37][38]以加深理解。区分
WPA/WPA2企业和个人用法的简单公式如下。
:-: WPA-企业=802.1X+EAP+TKIP
WPA2-企业=802.1X+EAP+CCMP
WPA-个人=PSK+TKIP
WPA2-个人=PSK+CCMP
* * * * *
① RFC3748中也叫Peer,不过本文统一用Supplicant表示。
- 前言
- 第1章 准备工作
- 1.1 Android系统架构
- 1.2 工具使用
- 1.2.1 Source Insight的使用
- 1.2.2 Eclipse的使用
- 1.2.3 BusyBox的使用
- 1.3 本书资源下载说明
- 第2章 深入理解Netd
- 2.1 概述
- 2.2 Netd工作流程
- 2.2.1 main函数分析
- 2.2.2 NetlinkManager分析
- 2.2.3 CommandListener分析
- 2.2.4 DnsProxyListener分析
- 2.2.5 MDnsSdListener分析
- 2.3 CommandListener中的命令
- 2.3.1 iptables、tc和ip命令
- 2.3.2 CommandListener构造函数和测试工具ndc
- 2.3.3 InterfaceCmd命令
- 2.3.4 IpFwd和FirewallCmd命令
- 2.3.5 ListTtysCmd和PppdCmd命令
- 2.3.6 BandwidthControlCmd和IdletimerControlCmd命令
- 2.3.7 NatCmd命令
- 2.3.8 TetherCmd和SoftapCmd命令
- 2.3.9 ResolverCmd命令
- 2.4 NetworkManagementService介绍
- 2.4.1 create函数详解
- 2.4.2 systemReady函数详解
- 2.5 本章总结和参考资料说明
- 2.5.1 本章总结
- 2.5.2 参考资料说明
- 第3章 Wi-Fi基础知识
- 3.1 概述
- 3.2 无线电频谱和802.11协议的发展历程
- 3.2.1 无线电频谱知识
- 3.2.2 IEEE 802.11发展历程
- 3.3 802.11无线网络技术
- 3.3.1 OSI基本参考模型及相关基本概念
- 3.3.2 802.11知识点导读
- 3.3.3 802.11组件
- 3.3.4 802.11 Service介绍
- 3.3.5 802.11 MAC服务和帧
- 3.3.6 802.11 MAC管理实体
- 3.3.7 无线网络安全技术知识点
- 3.4 Linux Wi-Fi编程API介绍
- 3.4.1 Linux Wireless Extensions介绍
- 3.4.2 nl80211介绍
- 3.5 本章总结和参考资料说明
- 3.5.1 本章总结
- 3.5.2 参考资料说明
- 第4章 深入理解wpa_supplicant
- 4.1 概述
- 4.2 初识wpa_supplicant
- 4.2.1 wpa_supplicant架构
- 4.2.2 wpa_supplicant编译配置
- 4.2.3 wpa_supplicant命令和控制API
- 4.2.4 git的使用
- 4.3 wpa_supplicant初始化流程
- 4.3.1 main函数分析
- 4.3.2 wpa_supplicant_init函数分析
- 4.3.3 wpa_supplicant_add_iface函数分析
- 4.3.4 wpa_supplicant_init_iface函数分析
- 4.4 EAP和EAPOL模块
- 4.4.1 EAP模块分析
- 4.4.2 EAPOL模块分析
- 4.5 wpa_supplicant连接无线网络分析
- 4.5.1 ADD_NETWORK命令处理
- 4.5.2 SET_NETWORK命令处理
- 4.5.3 ENABLE_NETWORK命令处理
- 4.6 本章总结和参考资料说明
- 4.6.1 本章总结
- 4.6.2 参考资料说明
- 第5章 深入理解WifiService
- 5.1 概述
- 5.2 WifiService的创建及初始化
- 5.2.1 HSM和AsyncChannel介绍
- 5.2.2 WifiService构造函数分析
- 5.2.3 WifiStateMachine介绍
- 5.3 加入无线网络分析
- 5.3.1 Settings操作Wi-Fi分析
- 5.3.2 WifiService操作Wi-Fi分析
- 5.4 WifiWatchdogStateMachine介绍
- 5.5 Captive Portal Check介绍
- 5.6 本章总结和参考资料说明
- 5.6.1 本章总结
- 5.6.2 参考资料说明
- 第6章 深入理解Wi-Fi Simple Configuration
- 6.1 概述
- 6.2 WSC基础知识
- 6.2.1 WSC应用场景
- 6.2.2 WSC核心组件及接口
- 6.3 Registration Protocol详解
- 6.3.1 WSC IE和Attribute介绍
- 6.3.2 802.11管理帧WSC IE设置
- 6.3.3 EAP-WSC介绍
- 6.4 WSC代码分析
- 6.4.1 Settings中的WSC处理
- 6.4.2 WifiStateMachine的处理
- 6.4.3 wpa_supplicant中的WSC处理
- 6.4.4 EAP-WSC处理流程分析
- 6.5 本章总结和参考资料说明
- 6.5.1 本章总结
- 6.5.2 参考资料说明
- 第7章 深入理解Wi-Fi P2P
- 7.1 概述
- 7.2 P2P基础知识
- 7.2.1 P2P架构
- 7.2.2 P2P Discovery技术
- 7.2.3 P2P工作流程
- 7.3 WifiP2pSettings和WifiP2pService介绍
- 7.3.1 WifiP2pSettings工作流程
- 7.3.2 WifiP2pService工作流程
- 7.4 wpa_supplicant中的P2P
- 7.4.1 P2P模块初始化
- 7.4.2 P2P Device Discovery流程分析
- 7.4.3 Provision Discovery流程分析
- 7.4.4 GO Negotiation流程分析
- 7.5 本章总结和参考资料说明
- 7.5.1 本章总结
- 7.5.2 参考资料说明
- 第8章 深入理解NFC
- 8.1 概述
- 8.2 NFC基础知识
- 8.2.1 NFC概述
- 8.2.2 NFC R/W运行模式
- 8.2.3 NFC P2P运行模式
- 8.2.4 NFC CE运行模式
- 8.2.5 NCI原理
- 8.2.6 NFC相关规范
- 8.3 Android中的NFC
- 8.3.1 NFC应用示例
- 8.3.2 NFC系统模块
- 8.4 NFC HAL层讨论
- 8.5 本章总结和参考资料说明
- 8.5.1 本章总结
- 8.5.2 参考资料说明
- 第9章 深入理解GPS
- 9.1 概述
- 9.2 GPS基础知识
- 9.2.1 卫星导航基本原理
- 9.2.2 GPS系统组成及原理
- 9.2.3 OMA-SUPL协议
- 9.3 Android中的位置管理
- 9.3.1 LocationManager架构
- 9.3.2 LocationManager应用示例
- 9.3.3 LocationManager系统模块
- 9.4 本章总结和参考资料说明
- 9.4.1 本章总结
- 9.4.2 参考资料说明
- 附录