WiMAX入网过程PPT课件

《WiMAX入网过程PPT课件》由会员分享，可在线阅读，更多相关《WiMAX入网过程PPT课件（65页珍藏版）》请在装配图网上搜索。

1、wimax入网入网过过程程Jade 2013目录概述免认证入网认证入网Wimax网络架构PSTN:PublicSwitchedTelephoneNetwork公共交换电话网络AAA:Authentication、Authorization、Accounting认证鉴权计费服务器ASN:AccessServiceNetwork接入网(BS/MS/ASNGW)BS:BasestationSS:SubscriberstationAAA ServerAAA ServerPSTNIP CorePortalPortalPortalPortalSSSSSSPCMCIAASN GWBSBSWimax网络参考模

2、型ASN:AccessServiceNetwork;CSN:ConnectivityServiceNetwork/CoreNetworkASP:ApplicationServiceProviderNSP:NetworkServiceProviderNAP:NetworkAccessProviderHomeNSP:HomeNetworkServiceProvider(可理解为用户所属的运营商)VisitedNSP:VisitedNSP(用户漫游到和HomeNSP有漫游协议的NSP)Bearerplane:承载平面，用户承载业务数据流Controlplane:控制平面，用户逻辑实体间的信令交互O&

3、Mplane：管理平面，用于逻辑实体操作维护信息的交互网络参考模型定义各个逻辑功能实体的功能/以及他们直接按的参考接口各个逻辑功能实体可能对应实际物理组网中一个或多个设备从左图可以看到主要逻辑功能实体有ASN/CSN/MS(MS也可算ASN的一部分)实际组网过程中，可能涉及终端用户/网络接入服务商/网络服务提供商/应用服务提供商NAP/NSP/ASP等在wimax出现前已存在，wimax重点在于ASN进一步请参考：WMF-T32-002-R010v05_Network-Stage2-Part1ASN参考模型BS:basestation,按照协议实现wimaxMAC/PHY层的逻辑实体，功能包括

4、但不限于对无线空口上下行资源的调度/管理，和ASN-GW业务连接的管理等。ASN-GW:ASN网络对外接口功能实体，在网络上具有承上启下的作用，对内完成无线资源管理；对外完成相关控制面信令的承载/转发和业务面承载。关于ASN侧完成的逻辑功能在BS和ASN-GW间的分解/分配请参考WMF-T32-003-R010v05_Network-Stage2-Part2中8.ASNProfileIntroduction章节。ASN网络由BS/ASN-GW/MS等实体组成典型的MS初始接入涉及的接口为R1/R6口，R3/R4接口可能涉及，但不需重点关注R1口为空口，为wimax协议的重中之重进一步请参考WM

5、F-T32-002-R010v05_Network-Stage2-Part1接口协议栈samedifferentdifferentConvergenceSublayer(CS)TheIEEEStd802.16definesmultipleconvergencesublayers.ThenetworkarchitectureframeworkSHALLsupportthefollowingCStypes:EthernetCSandIPv4/IPv6overEthernetCS,IPv4CS,IPv6CS.请参考WMF-T32-003-R010v05_Network-Stage2-Part1/Pa

6、rt2R1接口参考模型SAP:ServiceAccessPointC-SAP:ControlSAPM-SAP:ManagementSAPOFDM:orthogonalfrequencydivisionmultiplexingOFDMA:orthogonalfrequencydivisionmultiplexaccessOFDMA物理层和OFDM物理层最根本的区别在于前者在上行和下行均支持子信道化,后者仅在上行方向支持子信道化并且OFDMA在空口资源上分配方式更加灵活（右图）Wimax标准定义了R1口的MAC层和PHY层MAC层：包括CSCPSSS三个子层：CS执行外部网络数据的转换或映射到CP

7、S子层；CPS执行MAC核心功能，包括系统接入带宽分配连接建立与维护；SS子层主要完成安全相关功能，包括鉴权密钥交换加密。PHY层：随着协议的演进，协议规定了3类主要的物理层技术：WirelessMAN-SCWirelessMAN-OFDMWirelessMAN-OFDMA差别在于支持的频段是否支持移动空口性能，目前主流是支持移动的OFDMA技术更多细节请参考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworksPart16:AirInterfaceforFixedandMobileBroadbandWireles

8、sAccessSystems目录概述免认证入网流程认证入网免认证入网流程MSBSASN-GWDCDUCDDL-MAPUL-MAP侦听周期广播CDMAcodeRNG-RSP(status:Continue)loopCDMAcodeRNG-RSP(status:Success)码调整测距RNG-REQRNG-RSPSBC-REQSBC-RSP3.基本能力协商REG-REQREG-RSPDSA-REQDSA-RSPDSA-ACKloop4.注册5.建立业务流连接DHCP获取IPMS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_AckMS

9、_Attachment_ReqMS_Attachment_RsqMS_Attachment_AckRR_ReqRR_RspRR_Ack入网的5个步骤：1.MS与BS取得同步2.初始测距3.基本能力协商（PHY层能力安全能力参数等等）4.注册（高层能力协商）5.建立业务流连接message注释：D/DL代表DownlinkU/UL代表UplinkRNG:RangingDCD:DLchanneldescriptorUCD:ULchanneldescriptorSBC:SSbasiccapabilityDSA:Dynamicserviceflowadd可选的认证流程1.MS侦听下行广播MS侦听BS下

10、行广播信息目的：和和BS取得物理取得物理层层同步同步MS开机后扫描可能的连续下行频带，直到找到一个正确的下行信道，和BS取得时间和频率上同步和和BS取得下行取得下行MAC层层同步同步-Obtain DL parametersMS和BS取得物理层同步后，尝试搜索DL-MAP和DCD消息，能够连续解出这2个消息将保持MAC同步状态取得上行通道参数取得上行通道参数-Obtain UL parameters取得下行MAC层同步后，搜索UL-MAP和UCD消息，获取上行发射参数，能够连续解出这2条消息将保持同步状态Ms和BS取得MAC层同步后，具备了发起Ranging的条件。进一步参考IEEEStd80

11、2.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中节MSDCD（DIUC检索表/BSEIRP/TTG/RTG等）UCD（UIUC检索表/上行接入的ranging相关信息等）DL-MAP（物理帧symbol数/PHY同步信息/DCDcount/BSID/DL_MAPIE等）UL-MAP（物理帧symbol数/UCDcount/UL_MAPIE等）BS图示说明：DIUC:DL interval usage codeUIUC:UL interval usage codeUIUC/DIUC分分别对应别对应上下行不同的上下行不同的调调制

12、制/编码编码方式索引方式索引EIRP：有效全向：有效全向辐辐射功率射功率TTG：transmit/receive transition gapRTG：receive/transmit transition gap2.cdma码调整测距测距目的不断调整SS的Timingoffset/Freqoffset/poweroffset，使得SS的发射和接收达到最优过程要点初始测距是一个反复的过程，Ms在上行ranging时机随机选择CDMAcode，测量出MS的时偏/频偏/功率偏差等信道参数，然后响应RNG-RSP，告诉MS应该如何调整信道参数，如此反复，直到信道参数达到最优，在最后的RNG-RSP中携

13、带给MS分配的相关资源MS在得到分配的资源后，可以继续后续的接入流程如果MS已经入过网且所在位置未变/BS侧配置未变时，MS复位，初始测距可能不需反复，一次可以成功（MS将相关信息记录到了FALSH中）更多信息可参考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章节MSBSRNG-REQ/CDMAcodeRNG-RSP(status:Continue)loopRNG-REQ/CDMAcodeRNG-RSP(status:Success)RNG-REQRNG-RSPCDMAcode为一个特殊的消息序列，且

14、任意2个序列之间不具有相关性3.基本能力协商目的匹配MS和BS间的基本能力，包括PHY能力/安全能力过程说明MS将自身的基本支持能力通过SBC-REQ上报BSBS向ASN-GW发送消息（可携带需要到GW协商的能力），通知GW该MS入网ASN-GW响应BS，BS将MS上报的支持能力和网络侧的支持能力取交集下发MS更多信息可参考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章节WMF-T33-001-R015v03_Network-Stage3-Base中节MSBSASN-GWSBC-REQSBC-RSP

15、MS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_Ack4.注册目的匹配MS和网络侧高层支持能力，包括CS支持能力/移动性参数/切换支持能力等过程MS通过REG-REQ携带自身的高层支持能力向BS发起注册请求BS向ASN-GW发送消息（可携带需要到GW协商的能力），通知GW该MS发起注册，GW侧准备发起业务流建立ASN-GW响应BS，BS将MS上报的支持能力和网络侧的支持能力取交集下发MS更多信息可参考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetwo

16、rks中的章节WMF-T33-001-R015v03_Network-Stage3-Base中节MSBSASN-GWREG-REQREG-RSPMS_Attachment_ReqMS_Attachment_RsqMS_Attachment_Ack5.业务流建立目的建立预配置业务流，即建立端到端的业务承载通道过程ASN-GW侧在收到MS的REG-REQ时，主动发起预配置业务流建立，携带业务流相关参数向BS下发RR_REQ消息BS向MS下发DSA_REQ消息将业务流信息通知MSMS通过DSA_RSP响应BS，并向MS返回DSA_ACKBS向ASN-GW返回RR_RSP完成业务流建立业务流建立完成后

17、，可以进行业务，随后发起的DHCP过程即使用第一条预配置业务流（ISF）来承载第一条建立的预置业务流成为初始业务流(ISF),用来承载对于时延不敏感的业务，比如随后的DHCP过程ISF只有一条，除ISF外的预置业务流可以有多条MSBSASN-GWDSA-REQDSA-RSPDSA-ACKloop通过预配置业务流承载DHCP协议获取IPRR_ReqRR_Rsp更多信息可参考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章节WMF-T33-001-R015v03_Network-Stage3-Base中节

18、目录概述免认证入网认证入网认证基础-EAP概述EAP：ExtensibleAuthenticationProtocol是一个认证框架，在此框架上可以支持或者说承载多种认证协议方法，比如EAP-TLSEAP-TTLS交互方式采用lock-step，同时只能有一个报文在传输，等到对方响应后才可以发送下一个报文一般是request/response1，nsuccess/failure1支持重传，但是不支持分片和重组认证由server发起，而不是client2.通用包格式定义Code：1byte,目前只有4种定义：1Request2Response3Success4FailureIdentifier:

19、1byte，认证双方通信时用的transId，匹配一个Request和ResponseLength:2byte,报文长度，从Code字段开始。Data：报文内容，根据Code取值不同，需要进一步扩展。认证消息交互基本框架认证基础-EAP消息格式Request和Response报文格式进一步请参考RFC3748 Extensible Authentication ProtocolType定义:Type字段可以由EAP承载的认证协议扩展，比如EAP-TTLS，Type字段为21；EAP-TLS，Type取值为13.Nak用于接收方向发送方反馈，接收方不支持发送方指定的type，同时携带接收方支持的

20、type通知发送方可以用这些type（下文设备认证将看到此应用）Success和Failure报文格式认证基础-EAP-TTLS概述EAP-TTLS：ExtensibleAuthenticationProtocolTunneledTransportLayerSecurityAuthenticatedProtocolVersion0(EAP-TTLSv0)是EAP承载的一种方法，其封装了TLS协议，认证过程划分为2个阶段：Phase1：Handshake，完成client和server的双向认证，或者只是完成server到client的认证，同时协商出2阶段tunnel使用的ciphersuit

21、e，保障tunnel阶段数据的安全传输。Phase2：Tunnel，通过TLSrecordlayer建立的隧道在client和server间传输任意数据，完成特定的功能。包括client到server的认证，在Tunnel承载的认证协议可以是PAP,CHAP,MS-CHAP,orMS-CHAP-V2，MD5等。CPE使用用户认证方式时，采用EAP-TTLS协议，第一阶段完成server到CPE的认证，第二阶段使用指定的认证承载协议（可配置为PAPCHAPMS-CHAPMS-CHAP-V2MD5）完成CPE到server的认证2.协议分层模型进一步参考RFC5281 EAP-TTLSAVP，at

22、tribute-value pairs，类似TLV认证基础-EAP-TTLS消息格式包格式进一步参考RFC5281 EAP-TTLSCode(Request/Response)IdentifierLengthType(21)见EAP协议；FlagsData认证基础-EAP-TTLS密钥(MSK)生成KeyDerivation进一步参考RFC5281 EAP-TTLSEAP-TTLS协商完毕后，将按如上算法生成MSKEMSK，此值将用于后续的密钥生成。TLSPRF(pseudo-randomfunction)function参考rfc5216/rfc2246.认证基础-EAP-TLSEAP承载的

23、认证方法支持client和server间基于证书的相互认证密钥生成流程基本同EAP-TTLS，相比EAP-TTLS少了tunnel阶段，安全性略差，由于只支持基于证书的相互认证，CPE设备认证可以采用该协议，用户认证需要使用EAP-TTLS协议进一步请参考RFC5216 EAP-TLS左图为典型的交互流程：包含identify证书交换密钥（premastersecret）交换等过程进一步参考RFC5281 EAP-TTLS认证基础-TLS概述TLS:TransportLayerSecurity提供Internet网络的传输安全，对于client和server间的数据传输提供了防窃听，防篡改，防

24、伪造功能。包括2层：theTLSRecordProtocolandtheTLSHandshakeProtocol.TLSRecordLayer用于封装各种高层协议（例如可以封装TLSHandshakeProtocol），安全性说明：TLSRecordLayer通过对称加密算法保证传输数据的私密性通过MAC（messageauthenticationcode）保证传输数据的完整性，将待传输数据（压缩（可选）后加密前）联合密钥通过HASH算法（MD5/SHA）生成MACcode，供接收方校验完整性TLSHandshake用于服务器和客户端相互认证和协商应用层协议的加密算法和加密密钥进一步参考认证基

25、础-TLS安全参数安全参数生成加密算法：rc4,rc2,des,3des,des40,idea,aes可以为null加密算法类型：block方式流方式MAC算法：md5,sha压缩算法，可以为空双方共知的48bytesecretclient端randomserver端ramdom进一步参考block加密使用，non-exportblockciphers方式通过此方式生成，exportableblockciphers方式需要进一步算法生成认证基础-TLS通用包格式TLSRecordLayer包格式进一步参考Type：承载的协议类型change_cipher_spec:20alert:21hand

26、shake:22application_data:23version:版本号目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到华为wimax是0301，对应1.0(RFC2246),由于TSL基于演变而来，所以消息编码为（0301）。length：后续数据长度fragment：协议报文当fragment经过压缩/加密后，格式路略有变化，具体参考协议认证基础-TLS通用包格式TLSRecordLayer包格式进一步参考Type：承载的协议类型change_cipher_spec:20alert:21handshake:22application_data:23

27、version:版本号目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到华为wimax是0301，对应1.0(RFC2246),由于TSL基于演变而来，所以消息编码为（0301）。length：后续数据长度fragment：协议报文当fragment经过压缩/加密后，格式路略有变化，具体参考协议认证基础-TLSHandshakeProtocolTLSHandshakeProtocol用于双方协商安全参数相互认证包含3个子协议：Changecipherspecprotocol用于在安全参数协商过后，通知对方随后的交互将使用之前刚刚协商的安全参数进行加密处理该子

28、协议只包含change_cipher_spec(1)这1条消息Alertprotocol传递告警信息Handshakeprotocol见下页进一步参考Handshake过程：协商加密算法/交换random交换信息双方生成一致的premaster secret交换证书和加密信息并认证生成Master secret给record layer提供加密参数验证双方生成了相同的安全参数认证基础-TLSHandshakeProtocol包格式Handshakeprotocol用于协商安全参数包格式定义：进一步参考包含的消息类型认证基础-TLShellomessageHandshaketype之hellom

29、essage包括hellorequest/clienthello/serverhello三个消息，这3个消息用于双方协商安全能力：加密能力/压缩能力Hellorequest只用于server请求client发送clienthello消息，即server要求client发起协商Clienthello用于client主动向server发起协商流程消息中包含random值（32byte（4byteGMTTIME+28byterandom）client支持的CipherSuitelistclient支持的压缩算法Serverhelloserver对client的hello消息的响应消息中包含rando

30、m值/server选择的CipherSuite/server选择的压缩算法以及分配的sessionid进一步参考认证基础-TLSServercertificateHandshaketype之ServercertificateServer发送证书给client证书格式参考证书的key和签名必须和hello协商的Ciphersuite指定加密方式一致进一步参考认证基础-TLSServerkeyexchangemessageHandshaketype之ServerkeyexchangemessageTheserverkeyexchangemessageissentbytheserveronlywhe

31、ntheservercertificatemessage(ifsent)doesnotcontainenoughdatatoallowtheclienttoexchangeapremastersecret.Thismessageconveyscryptographicinformationtoallowtheclienttocommunicatethepremastersecret：eitheranRSApublickeytoencryptthepremastersecretwith,oraDiffie-Hellmanpublickeywithwhichtheclientcancomplete

32、akeyexchange帮助client计算server的premaster值进一步参考RFC2246 TLS1.0 和附录1 DH密钥交换算法认证基础-TLSCertificaterequestHandshaketype之Certificaterequest用于server向client请求证书（可选）目前认证流程不涉及，进一步信息参考协议进一步参考认证基础-TLSServerhellodoneHandshaketype之ServerhellodoneTheserverhellodonemessageissentbytheservertoindicatetheendoftheserverhe

33、lloandassociatedmessages.目前认证流程不涉及，进一步信息参考协议进一步参考认证基础-TLSClientcertificateHandshaketype之Clientcertificate发送client端证书证书格式参考进一步参考认证基础-TLSClientkeyexchangemessageHandshaketype之ClientkeyexchangemessageWiththismessage,thepremastersecretisset,eitherthoughdirecttransmissionoftheRSA-encryptedsecret,orbythet

34、ransmissionofDiffie-Hellmanparameterswhichwillalloweachsidetoagreeuponthesamepremastersecret.用于client通知server客户端的premastersecret，比如密钥交换算法选择RSA时，client用server段下发证书中的publickey将自身产生的48byte的premastersecret加密，发给server；采用密钥交换算法采用DH时，client和server互换DH计算参数，从而双方生成一致的premastersecret进一步参考认证基础-TLSCertificatever

35、ifymessageHandshaketype之CertificateverifyThismessageisusedtoprovideexplicitverificationofaclientcertificate.Whensent,itwillimmediatelyfollowtheclientkeyexchangemessage.包格式进一步参考认证基础-TLSFinishedmessageHandshaketype之FinishedAfinishedmessageisalwayssentimmediatelyafterachangecipherspecmessagetoverifytha

36、tthekeyexchangeandauthenticationprocessesweresuccessful.Thefinishedmessageisthefirstprotectedwiththejust-negotiatedalgorithms,keys,andsecrets.Recipientsoffinishedmessagesmustverifythatthecontentsarecorrect.进一步参考认证基础-TLSHandshakemessage总结Handshaketype之Finished原则上述消息必须按照上文描述的顺序发送，只有2个例外：theCertificate

37、messageisusedtwiceinthehandshake(fromservertoclient,thenfromclienttoserver),butdescribedonlyinitsfirstposition.TheonemessagewhichisnotboundbytheseorderingrulesintheHelloRequestmessage,whichcanbesentatanytime,butwhichshouldbeignoredbytheclientifitarrivesinthemiddleofahandshake.进一步参考认证基础-MS-CHAP-V2MS-

38、CHAP-V2:MicrosoftPPPCHAPExtensions,Version2.MS基于PPPCHAP协议的扩展增强版本，主要增强了用户认证功能通过3-wayhandshake验证peer的身份：1.authenticators发送生成并发送challengecode（随机数），消息中携带了用户名2.Client根据16-octetchallengeValueusernamepassword经过一定算法生成RADOM值（24byte），发送给authenticator3.authenticator经过同样算法计算得到Hash值，与Client发来的RADOM值比较成功时，返回Succe

39、ssCPE采用用户认证方式时，由CPE发起Challenge，在该消息中，CPE根据CPEchallenge值usernamepasspeerchallenge值经过一定算法成生24byte的RADOM值，连同CPEchallenge值usernamepeerchallenge值一并发给server；server根据Challenge中的username获取到对应的密码，根据同样的算法生成RADOM值，和CPE发送来的RADOM比较，一致返回success，否则返回失败。进一步参考RFC1994 CHAPRFC2433 MS-CHAPRFC2759 MS-CHAP-V2CPE认证分类认证的目的

40、在于双方互相判断对方是否合法，同时协商加密信息，用于后续报文的安全传输。认证分类：免认证用户认证CPE认证AAAbasedonX.509certificateAAA认证CPE基于用户名密码CPE和AAA间基于EAP-TTLS认证协议设备认证CPE和AAA相互认证basedonX.509certificateCPE和AAA间基于EAP-TLS认证协议认证协议栈进一步请参考：参考WMF-T32-001-R015v02_Network-Stage2-Base节参考RFC5281EAP-TTLS从协议栈可以看出，认证过程在MS和AAA间完成，中间网络节点提供EAP通道在R1口EAP通过PKMV2（wi

41、max定制）承载EAP属于一个认证流程的处理框架，其上可以承载多种具体的安全协议/认证协议CPE采用用户认证时，可以配置EAP具体承载的认证协议来安全的传输CPE的用户名和密码信息给AAA，支持如下5种协议：MS-CHAP/MS-CHAPV2CHAP(ChallengeAuth.Protocol)MD5PAP(PasswordAuth.Protocol)CPE采用设备认证时，由于AAA使用证书认证CPE，不需传递用户名/密码，所以不需配置认证协议。(用用户认证户认证)/EAP-TLS()/EAP-TLS(设备认证设备认证）设备认证不需要安全子层PKM：privacykeymanagement进

42、一步请参考P80216Rev_037节Trafficdata.:业务面加解密/业务面分包认证MessageAuthenticationProcessing：控制面分包认证(HMAC/CMAC/short-HMACs)ControlMessageProcessing:PKM消息分发处理PKMControlManagement：SS控制管理层，密钥生成分发RSA-basedAuthentication：基于RSA的数字证书的认证处理Authorization/SAControl:认证状态机和业务加密密钥状态机控制EAPEncapsulation/Decapsulation:EAP接口处理层EAP参

43、考前文认证基础PKMv1providessupportforonlyDeviceAuthenticationwhereasPKMv2providesaflexiblesolutionthatsupportsdeviceanduserauthenticationbetweenMSandhomeCSN.WIMAX密钥体系一进一步请参考P80216Rev_037节MSK：经过EAP认证后网络侧和MS都生成了同样的MSK(Mastersessionkey)PMK：取MSK的160bit作为PMK(pairwisemasterkey)PMK联合SSIDBSIDPMK生成AK(authorizationk

44、ey)，AK用于进一步派生其他密钥WIMAX密钥体系二进一步请参考P80216Rev_037节MAC(messageauthenticationcode)模式:CMAC/HMAC分别是基于加密和基于hash方式生成MAC值CMAC_PREKEY_U/D用于在CMAC模式生成MAC值HMAC_KEY_U/D用于在HMAC模式生成MAC值KEK(keyencryptionkey)用于加密其他密钥，比如TEK(Trafficencryptionkey)/GTEK(groupTEK)TEK(Trafficencryptionkey)用于业务面加密，MAC消息中通用头不加密，只有payload才会加密，

45、由BS负责生成，下发MS。其他非重要KEY参见协议CPE认证配置说明1.业务面加密配置：业务面加密选项，wimax协议上有四种：DES-CBCASE-CCMAES-CBCASE-CTR，从配置上看，只能配置2种，具体使用哪种由BS配置给MSAES：advancedencryptionstandardCTR：countermodeencryptionCBC：cipherblockchainingCBC-MAC：cipherblockchainingmessageauthenticationcodeCCM：CTRmodewithCBC-MACECB：electroniccodebook2.密钥交换

46、配置：AES-KeyWrap：是否使能AESkeywrapalgorithm，BS发送给CPE的业务面key将经过该算法处理，MS根据相同算法还原该keyAES-ECB：BS发送给CPE的业务面KEY是否经过AESECB加密上述是TEK配置给MS时，BS侧采用的加密方式，协议上支持4种：3-DESRSAAES-ECBAES-KeyWrap，具体采用哪种由BS配置给MS。EAPMode：认证承载协议InternalMode:认证方法（用户认证时使用）AnonymousID:NAI（Networkaccessidentifier）,用于认证时CPE上报AAA，帮助中继设备转发到合适的服务器。3.证

47、书配置：用于CPE验证AAA下发的AAA证书是否合法进一步参考WMF-T32-001-R015v02_Network-Stage2-Base7节321CPE认证配置说明1.业务面加密配置：业务面加密选项AES：advancedencryptionstandardCTR：countermodeencryptionCBC：cipherblockchainingCBC-MAC：cipherblockchainingmessageauthenticationcodeCCM：CTRmodewithCBC-MACECB：electroniccodebook2.密钥交换配置：AES-KeyWrap：是否使能

48、AESkeywrapalgorithm，BS发送给CPE的业务面key将经过该算法处理，MS根据相同算法还原该keyAES-ECB：BS发送给CPE的业务面KEY是否经过AESECB加密EAPMode：认证承载协议InternalMode:认证方法（用户认证时使用）,可以是PAP/CHAP/MSCHAPV2/MD5。AnonymousID:NAI（Networkaccessidentifier）,用于认证时CPE上报AAA，帮助中继设备转发到合适的服务器。3.证书配置：用于CPE验证AAA下发的AAA证书是否合法进一步参考WMF-T32-001-R015v02_Network-Stage2-B

49、ase7节321wimax认证整体流程CPE和AAAServer双向认证阶段：双向认证完毕后，CPE和AAASERVER将生成相同的MSK和EMSKSA生成阶段：CPE和GW根据MSK，各自生成相同的PMK，再由PMK联合MSIDBSID生AK和AK上下文,AK由GW下发BS密钥下发阶段：通过3次握手（6）完成SAAK验证以及PrimarySA的分配；同时通过（7）完成每个SA关联的2个TEK(trafficencryptionkey)的生成和下发CPE进一步参考 7.3.10 和 PART16中节wimax认证流程-双向认证进一步信息参考前文TLS协议MSBSEAPrequest/Ident

50、ifyASN-GWAAAEAPresponse/Identify-NAIEAP-reponse/identifyoverAAAEAPrequest/TTLS-StartEAP-request/TTLS-StartoverAAAEAPresponse/TTLS/TLS:ClienthelloEAPrequest/TTLS/TLS:Serverhello/certificateServerkeyexchange/ServerhellodoneEAPoverAAAEAPoverAAAEAPresponse/TTLS/TLS:Clientkeyexchange/Changecipherspec/fin

51、ishedEAPoverAAAEAPoverAAAEAPrequest/TTLS/TLS:Changecipherspec/finishedEAPresponse/TTLS/TLS:Peerresponse/challengeEAPrequest/TTLS/TLS:success/AuthenticatorresponseEAPresponse/TTLS(nodata)EAPoverAAAEAPoverAAAEAPSuccessEAPoverAAAEAPoverAAA基本能力协商后，ASN-GW发起EAPIdentify流程，MS将响应EAPIdentify/NAI,ASN-GW根据NAI指定

52、的域名将消息转发AAA，随后后续的流程实际上都是经过GW透传给MS和AAA通过TLS完成AAA到MS的认证（采用数字证书方式），同时完成了PREMSK的交换（通过DH或RSA）2.左图为用户认证方式，如果为设备认证时MS侧也需要将自己的证书发送发送AAA完成MS到AAA的认证3.经过此步后，AAA和MS可以生成的MSK/EMSK,AAA会将MSK下发给GW，GW进一步生成PMK/AK，并下发BS1.当认证方式为用户认证时，进一步通过认证协议完成MS到AAA的认证（认证协议可以是mschapv2/mschap/chap/md5/pap）,当设备认证时，不含此步骤wimax认证流程-用户认证双向认

53、证实例MSBSEAPrequest/IdentifyASN-GWEAPresponse/Identify-NAIEAPrequest/TTLS-StartEAPresponse/TTLS/TLS:ClienthelloEAPrequest/TTLS/TLS:Serverhello/certificateServerkeyexchange/ServerhellodoneEAPresponse/TTLS/TLS:Clientkeyexchange/Changecipherspec/finishedEAPrequest/TTLS/TLS:Changecipherspec/finishedEAPres

54、ponse/TTLS/TLS:Peerresponse/challengeEAPrequest/TTLS/TLS:success/AuthenticatorresponseEAPresponse/TTLS(nodata)EAPSuccessserver的证书较长，再加上Serverhello/Serverkeyexchange/Serverhellodone等消息，需要2条消息交互Finished是第一条使用刚刚协商后的加密参数加密的消息wimax认证流程-设备认证双向认证实例由于设备认证时，认证EAP-TLS，所以CPE响应Nak,告知AAA侧要使用EAP-TLS协议，后续流程全部用EAP-

55、TLSserver发送证书/Serverhello/Serverkeyexchange/ServerhellodoneCPE发送证书/clientkeyexchange/证书验证/changecipherspecwimax认证流程-PKMV2三次握手MSPKMV2/SA-TEKChallengeBSPKMV2/SA-TEKRequestPKMV2/SA-TEKResponseThe BS transmits the PKMv2 SA_TEK_Challenge message as a first step in the PKMv2 three-way handshake at initial

56、 network entry and at reauthentication.It identifies an AK to be used for the Security Association,and includes a unique challenge,i.e.,BS Random,that can either be a random number or a counter.The MS responds with the PKMv2 SA_TEK_Req message after receipt and successful CMAC verification of aPKMv2

57、 SA_TEK_Challenge from the BS.The PKMv2 SA_TEK_Req message contains the number,called MS-Random,which can also be either a random number or a counter.The PKMv2 SA_TEK_Req proves liveliness o f the Security Association in the MS and its possession of the valid AK.Since this message is being generated

58、 during initial network entry,it constitutes a request for S A-Descriptors identifying the primary and static SAs,an d GSAs the requesting SS is authorized to access,and their particular propertiesAfter the successful completion of PKMv2 three-way handshake,the MS and the BS shall start using the ne

59、wly acquired AK for MAC management messages protection(by CMAC)as per IEEE 802.16e specification.进一步参考 7.3.10 和Wimax认证流程-PKMV2TEK下发MSPKMV2/KeyRequestBSPKMV2/KeyResponseFor each SA,the MS requests two TEKs from the BS.The TEKs are randomly created by the BS,encrypted using the KEK as the symmetric se

60、cret key,and are transferred to the MS.This step is repeated for each SA.进一步参考 7.3.10 和附录1：DH密钥交换算法原理由WhitfieldDiffie和MartinHellman在1976年公布的一种密钥一致性算法，算法用2个人的名字命名，原理说明：离散对数问题：若p是素数，p已知，考虑方程y=gxmodp，给定g,x求y是简单的，但给定y,g求x，即求x=logg,pymodp，在计算上是不可行的。DH密钥交换算法的描述如下：已知公开的素数p和p的本原根1.用户A选择秘密的Xap，计算Ya=Xamodp，将其

61、发送给B。2.用户B选择秘密的Xbp，计算Yb=Xbmodp，将其发送给A。3.A和B分别计算Ka=(Yb)Xamodp和Kb=(Ya)Xbmodp，就同时得到了共享的密钥K=Ka=Kb，然后就可以用K进行加密传输了。DH密钥交换算法的优点在于：双方在通信前不需要知道任何共享的密钥，而是通过公开的p和协商出一个密钥来进行加密通信。先看一下算法的正确性，Ka=Kb是否成立：Ka=(Yb)Xa=(Xb)Xa=Xa*Xb(modp)Kb=(Ya)Xb=(Xa)Xb=Xa*Xb(modp)Bingo!Ka和Kb是相同的。再来看一下算法的安全性，就是能否从公开的信息推导出K来：由于密钥是K=Xa*Xb，

62、那么攻击者必须知道Xa和Xb才能得到共享的密钥K，而公开的信息只有Ya和Yb，由离散对数问题，从Ya,Yb求出Xa,Xb在计算上是不可行的，就保证了算法的安全性。参考自百度百科附录2：RSA公钥加密算法RSA公钥加密算法是1977年由RonRivest、AdiShamirh和LenAdleman在（美国麻省理工学院）开发的。RSA取名来自开发他们三者的名字。RSA是目前最有影响力的公钥加密算法，它能够抵抗到目前为止已知的所有密码攻击，已被ISO推荐为公钥数据加密标准。RSA算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为

63、加密密钥。RSA公开密钥密码体制。所谓的公开密钥密码体制就是使用不同的加密密钥与解密密钥，是一种“由已知加密密钥推导出解密密钥在计算上是不可行的”密码体制。非对称加密密码算法，用公钥加密，必须用密钥解密；反过来，用密钥加密，必须用公钥解密应用场景：加解密server分发公钥给client，自己保留密钥，client用公钥加密后的数据只能有server解密数字签名server将用密钥加密的签名和原始签名发送给client，client用公钥解密签名，和原始签名一致时，认为数字签名有效，可以认证该server。参考自百度百科附录3：CBCcipherblockchaining密码段连接（CBC）是

64、一种操作分段密码的方式（在一段bit序列加密成一个单独的单元或分成一个密钥提供给整个部分）。密码段连接使用一定长度初始化向量（IV）。他的一个主要特点是他完全依靠前面的密码文段来译码后面的内容。因此，整个过程的正确性决定于前面的部分。各部分的顺序也必须保持正确。在面段连接中，每个文件部分先用前面的部分XOR化（参看XOR），然后加密。如果各部分顺序没变，使用相同的密钥和初始化向量，只有同样的密码部分可以起作用。因为XOR过程隐藏了原文，密码段连接要优于电子密码书模式。理论上，两条信息使用相同的密钥加密会产生不同的初始化向量。所以初始化向量不需要保密，这将极大方便某些场合的应用。参考自百度百科附

65、录4：SHASecureHashAlgorithmSHA是一种数据加密算法，该算法经过加密专家多年来的发展和改进已日益完善，现在已成为公认的最安全的散列算法之一，并被广泛使用。该算法的思想是接收一段明文，然后以一种不可逆的方式将它转换成一段（通常更小）密文，也可以简单的理解为取一串输入码（称为预映射或信息），并把它们转化为长度较短、位数固定的输出序列即散列值（也称为信息摘要或信息认证代码）的过程。散列函数值可以说时对明文的一种“指纹”或是“摘要”所以对散列值的数字签名就可以视为对此明文的数字签名。散列是信息的提炼，通常其长度要比信息小得多，且为一个固定长度。加密性强的散列一定是不可逆的，这就意

66、味着通过散列结果，无法推出任何部分的原始信息。任何输入信息的变化，哪怕仅一位，都将导致散列结果的明显变化，这称之为雪崩效应。散列还应该是防冲突的，即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。单向散列函数一般用于产生消息摘要，密钥加密等，常见的有：lMD5（MessageDigestAlgorithm5）：是RSA数据安全公司开发的一种单向散列算法。lSHA（SecureHashAlgorithm）：可以对任意长度的数据运算生成一个160位的数值；应用：MAC（信息认证代码）就是一个散列结果，其中部分输入信息是密码，只有知道这个密码的参与者才能再次计算和验证MAC码的合法性。参考自百度百科附录5：AESAdvancedEncryptionStandard密码学中的高级加密标准（AdvancedEncryptionStandard，AES），又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES（DataEncryptionStandard），已经被多方分析且广为全世界所使用。经过五年的甄选流程，高级加密标