《WiMAX入網(wǎng)過程PPT課件》由會員分享，可在線閱讀，更多相關《WiMAX入網(wǎng)過程PPT課件（65頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、wimax入網(wǎng)入網(wǎng)過過程程Jade 2013目錄概述免認證入網(wǎng)認證入網(wǎng)Wimax網(wǎng)絡架構PSTN:PublicSwitchedTelephoneNetwork公共交換電話網(wǎng)絡AAA:Authentication、Authorization、Accounting認證鑒權計費服務器ASN:AccessServiceNetwork接入網(wǎng)(BS/MS/ASNGW)BS:BasestationSS:SubscriberstationAAA ServerAAA ServerPSTNIP CorePortalPortalPortalPortalSSSSSSPCMCIAASN GWBSBSWimax網(wǎng)絡參考模

2、型ASN:AccessServiceNetwork;CSN:ConnectivityServiceNetwork/CoreNetworkASP:ApplicationServiceProviderNSP:NetworkServiceProviderNAP:NetworkAccessProviderHomeNSP:HomeNetworkServiceProvider(可理解為用戶所屬的運營商)VisitedNSP:VisitedNSP(用戶漫游到和HomeNSP有漫游協(xié)議的NSP)Bearerplane:承載平面，用戶承載業(yè)務數(shù)據(jù)流Controlplane:控制平面，用戶邏輯實體間的信令交互O&

3、Mplane：管理平面，用于邏輯實體操作維護信息的交互網(wǎng)絡參考模型定義各個邏輯功能實體的功能/以及他們直接按的參考接口各個邏輯功能實體可能對應實際物理組網(wǎng)中一個或多個設備從左圖可以看到主要邏輯功能實體有ASN/CSN/MS(MS也可算ASN的一部分)實際組網(wǎng)過程中，可能涉及終端用戶/網(wǎng)絡接入服務商/網(wǎng)絡服務提供商/應用服務提供商NAP/NSP/ASP等在wimax出現(xiàn)前已存在，wimax重點在于ASN進一步請參考：WMF-T32-002-R010v05_Network-Stage2-Part1ASN參考模型BS:basestation,按照協(xié)議實現(xiàn)wimaxMAC/PHY層的邏輯實體，功能包括

4、但不限于對無線空口上下行資源的調(diào)度/管理，和ASN-GW業(yè)務連接的管理等。ASN-GW:ASN網(wǎng)絡對外接口功能實體，在網(wǎng)絡上具有承上啟下的作用，對內(nèi)完成無線資源管理；對外完成相關控制面信令的承載/轉(zhuǎn)發(fā)和業(yè)務面承載。關于ASN側(cè)完成的邏輯功能在BS和ASN-GW間的分解/分配請參考WMF-T32-003-R010v05_Network-Stage2-Part2中8.ASNProfileIntroduction章節(jié)。ASN網(wǎng)絡由BS/ASN-GW/MS等實體組成典型的MS初始接入涉及的接口為R1/R6口，R3/R4接口可能涉及，但不需重點關注R1口為空口，為wimax協(xié)議的重中之重進一步請參考WM

5、F-T32-002-R010v05_Network-Stage2-Part1接口協(xié)議棧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物理層最根本的區(qū)別在于前者在上行和下行均支持子信道化,后者僅在上行方向支持子信道化并且OFDMA在空口資源上分配方式更加靈活（右圖）Wimax標準定義了R1口的MAC層和PHY層MAC層：包括CSCPSSS三個子層：CS執(zhí)行外部網(wǎng)絡數(shù)據(jù)的轉(zhuǎn)換或映射到CP

7、S子層；CPS執(zhí)行MAC核心功能，包括系統(tǒng)接入帶寬分配連接建立與維護；SS子層主要完成安全相關功能，包括鑒權密鑰交換加密。PHY層：隨著協(xié)議的演進，協(xié)議規(guī)定了3類主要的物理層技術：WirelessMAN-SCWirelessMAN-OFDMWirelessMAN-OFDMA差別在于支持的頻段是否支持移動空口性能，目前主流是支持移動的OFDMA技術更多細節(jié)請參考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworksPart16:AirInterfaceforFixedandMobileBroadbandWireles

8、sAccessSystems目錄概述免認證入網(wǎng)流程認證入網(wǎng)免認證入網(wǎng)流程MSBSASN-GWDCDUCDDL-MAPUL-MAP偵聽周期廣播CDMAcodeRNG-RSP(status:Continue)loopCDMAcodeRNG-RSP(status:Success)碼調(diào)整測距RNG-REQRNG-RSPSBC-REQSBC-RSP3.基本能力協(xié)商REG-REQREG-RSPDSA-REQDSA-RSPDSA-ACKloop4.注冊5.建立業(yè)務流連接DHCP獲取IPMS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_AckMS

9、_Attachment_ReqMS_Attachment_RsqMS_Attachment_AckRR_ReqRR_RspRR_Ack入網(wǎng)的5個步驟：1.MS與BS取得同步2.初始測距3.基本能力協(xié)商（PHY層能力安全能力參數(shù)等等）4.注冊（高層能力協(xié)商）5.建立業(yè)務流連接message注釋：D/DL代表DownlinkU/UL代表UplinkRNG:RangingDCD:DLchanneldescriptorUCD:ULchanneldescriptorSBC:SSbasiccapabilityDSA:Dynamicserviceflowadd可選的認證流程1.MS偵聽下行廣播MS偵聽BS下

10、行廣播信息目的：和和BS取得物理取得物理層層同步同步MS開機后掃描可能的連續(xù)下行頻帶，直到找到一個正確的下行信道，和BS取得時間和頻率上同步和和BS取得下行取得下行MAC層層同步同步-Obtain DL parametersMS和BS取得物理層同步后，嘗試搜索DL-MAP和DCD消息，能夠連續(xù)解出這2個消息將保持MAC同步狀態(tài)取得上行通道參數(shù)取得上行通道參數(shù)-Obtain UL parameters取得下行MAC層同步后，搜索UL-MAP和UCD消息，獲取上行發(fā)射參數(shù)，能夠連續(xù)解出這2條消息將保持同步狀態(tài)Ms和BS取得MAC層同步后，具備了發(fā)起Ranging的條件。進一步參考IEEEStd80

11、2.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中節(jié)MSDCD（DIUC檢索表/BSEIRP/TTG/RTG等）UCD（UIUC檢索表/上行接入的ranging相關信息等）DL-MAP（物理幀symbol數(shù)/PHY同步信息/DCDcount/BSID/DL_MAPIE等）UL-MAP（物理幀symbol數(shù)/UCDcount/UL_MAPIE等）BS圖示說明：DIUC:DL interval usage codeUIUC:UL interval usage codeUIUC/DIUC分分別對應別對應上下行不同的上下行不同的調(diào)調(diào)制

12、制/編碼編碼方式索引方式索引EIRP：有效全向：有效全向輻輻射功率射功率TTG：transmit/receive transition gapRTG：receive/transmit transition gap2.cdma碼調(diào)整測距測距目的不斷調(diào)整SS的Timingoffset/Freqoffset/poweroffset，使得SS的發(fā)射和接收達到最優(yōu)過程要點初始測距是一個反復的過程，Ms在上行ranging時機隨機選擇CDMAcode，測量出MS的時偏/頻偏/功率偏差等信道參數(shù)，然后響應RNG-RSP，告訴MS應該如何調(diào)整信道參數(shù)，如此反復，直到信道參數(shù)達到最優(yōu)，在最后的RNG-RSP中攜

13、帶給MS分配的相關資源MS在得到分配的資源后，可以繼續(xù)后續(xù)的接入流程如果MS已經(jīng)入過網(wǎng)且所在位置未變/BS側(cè)配置未變時，MS復位，初始測距可能不需反復，一次可以成功（MS將相關信息記錄到了FALSH中）更多信息可參考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)MSBSRNG-REQ/CDMAcodeRNG-RSP(status:Continue)loopRNG-REQ/CDMAcodeRNG-RSP(status:Success)RNG-REQRNG-RSPCDMAcode為一個特殊的消息序列，且

14、任意2個序列之間不具有相關性3.基本能力協(xié)商目的匹配MS和BS間的基本能力，包括PHY能力/安全能力過程說明MS將自身的基本支持能力通過SBC-REQ上報BSBS向ASN-GW發(fā)送消息（可攜帶需要到GW協(xié)商的能力），通知GW該MS入網(wǎng)ASN-GW響應BS，BS將MS上報的支持能力和網(wǎng)絡側(cè)的支持能力取交集下發(fā)MS更多信息可參考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)MSBSASN-GWSBC-REQSBC-RSP

15、MS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_Ack4.注冊目的匹配MS和網(wǎng)絡側(cè)高層支持能力，包括CS支持能力/移動性參數(shù)/切換支持能力等過程MS通過REG-REQ攜帶自身的高層支持能力向BS發(fā)起注冊請求BS向ASN-GW發(fā)送消息（可攜帶需要到GW協(xié)商的能力），通知GW該MS發(fā)起注冊，GW側(cè)準備發(fā)起業(yè)務流建立ASN-GW響應BS，BS將MS上報的支持能力和網(wǎng)絡側(cè)的支持能力取交集下發(fā)MS更多信息可參考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetwo

16、rks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)MSBSASN-GWREG-REQREG-RSPMS_Attachment_ReqMS_Attachment_RsqMS_Attachment_Ack5.業(yè)務流建立目的建立預配置業(yè)務流，即建立端到端的業(yè)務承載通道過程ASN-GW側(cè)在收到MS的REG-REQ時，主動發(fā)起預配置業(yè)務流建立，攜帶業(yè)務流相關參數(shù)向BS下發(fā)RR_REQ消息BS向MS下發(fā)DSA_REQ消息將業(yè)務流信息通知MSMS通過DSA_RSP響應BS，并向MS返回DSA_ACKBS向ASN-GW返回RR_RSP完成業(yè)務流建立業(yè)務流建立完成后

17、，可以進行業(yè)務，隨后發(fā)起的DHCP過程即使用第一條預配置業(yè)務流（ISF）來承載第一條建立的預置業(yè)務流成為初始業(yè)務流(ISF),用來承載對于時延不敏感的業(yè)務，比如隨后的DHCP過程ISF只有一條，除ISF外的預置業(yè)務流可以有多條MSBSASN-GWDSA-REQDSA-RSPDSA-ACKloop通過預配置業(yè)務流承載DHCP協(xié)議獲取IPRR_ReqRR_Rsp更多信息可參考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)

18、目錄概述免認證入網(wǎng)認證入網(wǎng)認證基礎-EAP概述EAP：ExtensibleAuthenticationProtocol是一個認證框架，在此框架上可以支持或者說承載多種認證協(xié)議方法，比如EAP-TLSEAP-TTLS交互方式采用lock-step，同時只能有一個報文在傳輸，等到對方響應后才可以發(fā)送下一個報文一般是request/response1，nsuccess/failure1支持重傳，但是不支持分片和重組認證由server發(fā)起，而不是client2.通用包格式定義Code：1byte,目前只有4種定義：1Request2Response3Success4FailureIdentifier:

19、1byte，認證雙方通信時用的transId，匹配一個Request和ResponseLength:2byte,報文長度，從Code字段開始。Data：報文內(nèi)容，根據(jù)Code取值不同，需要進一步擴展。認證消息交互基本框架認證基礎-EAP消息格式Request和Response報文格式進一步請參考RFC3748 Extensible Authentication ProtocolType定義:Type字段可以由EAP承載的認證協(xié)議擴展，比如EAP-TTLS，Type字段為21；EAP-TLS，Type取值為13.Nak用于接收方向發(fā)送方反饋，接收方不支持發(fā)送方指定的type，同時攜帶接收方支持的

20、type通知發(fā)送方可以用這些type（下文設備認證將看到此應用）Success和Failure報文格式認證基礎-EAP-TTLS概述EAP-TTLS：ExtensibleAuthenticationProtocolTunneledTransportLayerSecurityAuthenticatedProtocolVersion0(EAP-TTLSv0)是EAP承載的一種方法，其封裝了TLS協(xié)議，認證過程劃分為2個階段：Phase1：Handshake，完成client和server的雙向認證，或者只是完成server到client的認證，同時協(xié)商出2階段tunnel使用的ciphersuit

21、e，保障tunnel階段數(shù)據(jù)的安全傳輸。Phase2：Tunnel，通過TLSrecordlayer建立的隧道在client和server間傳輸任意數(shù)據(jù)，完成特定的功能。包括client到server的認證，在Tunnel承載的認證協(xié)議可以是PAP,CHAP,MS-CHAP,orMS-CHAP-V2，MD5等。CPE使用用戶認證方式時，采用EAP-TTLS協(xié)議，第一階段完成server到CPE的認證，第二階段使用指定的認證承載協(xié)議（可配置為PAPCHAPMS-CHAPMS-CHAP-V2MD5）完成CPE到server的認證2.協(xié)議分層模型進一步參考RFC5281 EAP-TTLSAVP，at

22、tribute-value pairs，類似TLV認證基礎-EAP-TTLS消息格式包格式進一步參考RFC5281 EAP-TTLSCode(Request/Response)IdentifierLengthType(21)見EAP協(xié)議；FlagsData認證基礎-EAP-TTLS密鑰(MSK)生成KeyDerivation進一步參考RFC5281 EAP-TTLSEAP-TTLS協(xié)商完畢后，將按如上算法生成MSKEMSK，此值將用于后續(xù)的密鑰生成。TLSPRF(pseudo-randomfunction)function參考rfc5216/rfc2246.認證基礎-EAP-TLSEAP承載的

23、認證方法支持client和server間基于證書的相互認證密鑰生成流程基本同EAP-TTLS，相比EAP-TTLS少了tunnel階段，安全性略差，由于只支持基于證書的相互認證，CPE設備認證可以采用該協(xié)議，用戶認證需要使用EAP-TTLS協(xié)議進一步請參考RFC5216 EAP-TLS左圖為典型的交互流程：包含identify證書交換密鑰（premastersecret）交換等過程進一步參考RFC5281 EAP-TTLS認證基礎-TLS概述TLS:TransportLayerSecurity提供Internet網(wǎng)絡的傳輸安全，對于client和server間的數(shù)據(jù)傳輸提供了防竊聽，防篡改，防

24、偽造功能。包括2層：theTLSRecordProtocolandtheTLSHandshakeProtocol.TLSRecordLayer用于封裝各種高層協(xié)議（例如可以封裝TLSHandshakeProtocol），安全性說明：TLSRecordLayer通過對稱加密算法保證傳輸數(shù)據(jù)的私密性通過MAC（messageauthenticationcode）保證傳輸數(shù)據(jù)的完整性，將待傳輸數(shù)據(jù)（壓縮（可選）后加密前）聯(lián)合密鑰通過HASH算法（MD5/SHA）生成MACcode，供接收方校驗完整性TLSHandshake用于服務器和客戶端相互認證和協(xié)商應用層協(xié)議的加密算法和加密密鑰進一步參考認證基

25、礎-TLS安全參數(shù)安全參數(shù)生成加密算法：rc4,rc2,des,3des,des40,idea,aes可以為null加密算法類型：block方式流方式MAC算法：md5,sha壓縮算法，可以為空雙方共知的48bytesecretclient端randomserver端ramdom進一步參考block加密使用，non-exportblockciphers方式通過此方式生成，exportableblockciphers方式需要進一步算法生成認證基礎-TLS通用包格式TLSRecordLayer包格式進一步參考Type：承載的協(xié)議類型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：后續(xù)數(shù)據(jù)長度fragment：協(xié)議報文當fragment經(jīng)過壓縮/加密后，格式路略有變化，具體參考協(xié)議認證基礎-TLS通用包格式TLSRecordLayer包格式進一步參考Type：承載的協(xié)議類型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：后續(xù)數(shù)據(jù)長度fragment：協(xié)議報文當fragment經(jīng)過壓縮/加密后，格式路略有變化，具體參考協(xié)議認證基礎-TLSHandshakeProtocolTLSHandshakeProtocol用于雙方協(xié)商安全參數(shù)相互認證包含3個子協(xié)議：Changecipherspecprotocol用于在安全參數(shù)協(xié)商過后，通知對方隨后的交互將使用之前剛剛協(xié)商的安全參數(shù)進行加密處理該子

28、協(xié)議只包含change_cipher_spec(1)這1條消息Alertprotocol傳遞告警信息Handshakeprotocol見下頁進一步參考Handshake過程：協(xié)商加密算法/交換random交換信息雙方生成一致的premaster secret交換證書和加密信息并認證生成Master secret給record layer提供加密參數(shù)驗證雙方生成了相同的安全參數(shù)認證基礎-TLSHandshakeProtocol包格式Handshakeprotocol用于協(xié)商安全參數(shù)包格式定義：進一步參考包含的消息類型認證基礎-TLShellomessageHandshaketype之hellom

29、essage包括hellorequest/clienthello/serverhello三個消息，這3個消息用于雙方協(xié)商安全能力：加密能力/壓縮能力Hellorequest只用于server請求client發(fā)送clienthello消息，即server要求client發(fā)起協(xié)商Clienthello用于client主動向server發(fā)起協(xié)商流程消息中包含random值（32byte（4byteGMTTIME+28byterandom）client支持的CipherSuitelistclient支持的壓縮算法Serverhelloserver對client的hello消息的響應消息中包含rando

30、m值/server選擇的CipherSuite/server選擇的壓縮算法以及分配的sessionid進一步參考認證基礎-TLSServercertificateHandshaketype之ServercertificateServer發(fā)送證書給client證書格式參考證書的key和簽名必須和hello協(xié)商的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請求證書（可選）目前認證流程不涉及，進一步信息參考協(xié)議進一步參考認證基礎-TLSServerhellodoneHandshaketype之ServerhellodoneTheserverhellodonemessageissentbytheservertoindicatetheendoftheserverhe

33、lloandassociatedmessages.目前認證流程不涉及，進一步信息參考協(xié)議進一步參考認證基礎-TLSClientcertificateHandshaketype之Clientcertificate發(fā)送client端證書證書格式參考進一步參考認證基礎-TLSClientkeyexchangemessageHandshaketype之ClientkeyexchangemessageWiththismessage,thepremastersecretisset,eitherthoughdirecttransmissionoftheRSA-encryptedsecret,orbythet

34、ransmissionofDiffie-Hellmanparameterswhichwillalloweachsidetoagreeuponthesamepremastersecret.用于client通知server客戶端的premastersecret，比如密鑰交換算法選擇RSA時，client用server段下發(fā)證書中的publickey將自身產(chǎn)生的48byte的premastersecret加密，發(fā)給server；采用密鑰交換算法采用DH時，client和server互換DH計算參數(shù)，從而雙方生成一致的premastersecret進一步參考認證基礎-TLSCertificatever

35、ifymessageHandshaketype之CertificateverifyThismessageisusedtoprovideexplicitverificationofaclientcertificate.Whensent,itwillimmediatelyfollowtheclientkeyexchangemessage.包格式進一步參考認證基礎-TLSFinishedmessageHandshaketype之FinishedAfinishedmessageisalwayssentimmediatelyafterachangecipherspecmessagetoverifytha

36、tthekeyexchangeandauthenticationprocessesweresuccessful.Thefinishedmessageisthefirstprotectedwiththejust-negotiatedalgorithms,keys,andsecrets.Recipientsoffinishedmessagesmustverifythatthecontentsarecorrect.進一步參考認證基礎-TLSHandshakemessage總結(jié)Handshaketype之Finished原則上述消息必須按照上文描述的順序發(fā)送，只有2個例外：theCertificate

37、messageisusedtwiceinthehandshake(fromservertoclient,thenfromclienttoserver),butdescribedonlyinitsfirstposition.TheonemessagewhichisnotboundbytheseorderingrulesintheHelloRequestmessage,whichcanbesentatanytime,butwhichshouldbeignoredbytheclientifitarrivesinthemiddleofahandshake.進一步參考認證基礎-MS-CHAP-V2MS-

38、CHAP-V2:MicrosoftPPPCHAPExtensions,Version2.MS基于PPPCHAP協(xié)議的擴展增強版本，主要增強了用戶認證功能通過3-wayhandshake驗證peer的身份：1.authenticators發(fā)送生成并發(fā)送challengecode（隨機數(shù)），消息中攜帶了用戶名2.Client根據(jù)16-octetchallengeValueusernamepassword經(jīng)過一定算法生成RADOM值（24byte），發(fā)送給authenticator3.authenticator經(jīng)過同樣算法計算得到Hash值，與Client發(fā)來的RADOM值比較成功時，返回Succe

39、ssCPE采用用戶認證方式時，由CPE發(fā)起Challenge，在該消息中，CPE根據(jù)CPEchallenge值usernamepasspeerchallenge值經(jīng)過一定算法成生24byte的RADOM值，連同CPEchallenge值usernamepeerchallenge值一并發(fā)給server；server根據(jù)Challenge中的username獲取到對應的密碼，根據(jù)同樣的算法生成RADOM值，和CPE發(fā)送來的RADOM比較，一致返回success，否則返回失敗。進一步參考RFC1994 CHAPRFC2433 MS-CHAPRFC2759 MS-CHAP-V2CPE認證分類認證的目的

40、在于雙方互相判斷對方是否合法，同時協(xié)商加密信息，用于后續(xù)報文的安全傳輸。認證分類：免認證用戶認證CPE認證AAAbasedonX.509certificateAAA認證CPE基于用戶名密碼CPE和AAA間基于EAP-TTLS認證協(xié)議設備認證CPE和AAA相互認證basedonX.509certificateCPE和AAA間基于EAP-TLS認證協(xié)議認證協(xié)議棧進一步請參考：參考WMF-T32-001-R015v02_Network-Stage2-Base節(jié)參考RFC5281EAP-TTLS從協(xié)議棧可以看出，認證過程在MS和AAA間完成，中間網(wǎng)絡節(jié)點提供EAP通道在R1口EAP通過PKMV2（wi

41、max定制）承載EAP屬于一個認證流程的處理框架，其上可以承載多種具體的安全協(xié)議/認證協(xié)議CPE采用用戶認證時，可以配置EAP具體承載的認證協(xié)議來安全的傳輸CPE的用戶名和密碼信息給AAA，支持如下5種協(xié)議：MS-CHAP/MS-CHAPV2CHAP(ChallengeAuth.Protocol)MD5PAP(PasswordAuth.Protocol)CPE采用設備認證時，由于AAA使用證書認證CPE，不需傳遞用戶名/密碼，所以不需配置認證協(xié)議。(用用戶認證戶認證)/EAP-TLS()/EAP-TLS(設備認證設備認證）設備認證不需要安全子層PKM：privacykeymanagement進

42、一步請參考P80216Rev_037節(jié)Trafficdata.:業(yè)務面加解密/業(yè)務面分包認證MessageAuthenticationProcessing：控制面分包認證(HMAC/CMAC/short-HMACs)ControlMessageProcessing:PKM消息分發(fā)處理PKMControlManagement：SS控制管理層，密鑰生成分發(fā)RSA-basedAuthentication：基于RSA的數(shù)字證書的認證處理Authorization/SAControl:認證狀態(tài)機和業(yè)務加密密鑰狀態(tài)機控制EAPEncapsulation/Decapsulation:EAP接口處理層EAP參

43、考前文認證基礎PKMv1providessupportforonlyDeviceAuthenticationwhereasPKMv2providesaflexiblesolutionthatsupportsdeviceanduserauthenticationbetweenMSandhomeCSN.WIMAX密鑰體系一進一步請參考P80216Rev_037節(jié)MSK：經(jīng)過EAP認證后網(wǎng)絡側(cè)和MS都生成了同樣的MSK(Mastersessionkey)PMK：取MSK的160bit作為PMK(pairwisemasterkey)PMK聯(lián)合SSIDBSIDPMK生成AK(authorizationk

44、ey)，AK用于進一步派生其他密鑰WIMAX密鑰體系二進一步請參考P80216Rev_037節(jié)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)用于業(yè)務面加密，MAC消息中通用頭不加密，只有payload才會加密，

45、由BS負責生成，下發(fā)MS。其他非重要KEY參見協(xié)議CPE認證配置說明1.業(yè)務面加密配置：業(yè)務面加密選項，wimax協(xié)議上有四種：DES-CBCASE-CCMAES-CBCASE-CTR，從配置上看，只能配置2種，具體使用哪種由BS配置給MSAES：advancedencryptionstandardCTR：countermodeencryptionCBC：cipherblockchainingCBC-MAC：cipherblockchainingmessageauthenticationcodeCCM：CTRmodewithCBC-MACECB：electroniccodebook2.密鑰交換

46、配置：AES-KeyWrap：是否使能AESkeywrapalgorithm，BS發(fā)送給CPE的業(yè)務面key將經(jīng)過該算法處理，MS根據(jù)相同算法還原該keyAES-ECB：BS發(fā)送給CPE的業(yè)務面KEY是否經(jīng)過AESECB加密上述是TEK配置給MS時，BS側(cè)采用的加密方式，協(xié)議上支持4種：3-DESRSAAES-ECBAES-KeyWrap，具體采用哪種由BS配置給MS。EAPMode：認證承載協(xié)議InternalMode:認證方法（用戶認證時使用）AnonymousID:NAI（Networkaccessidentifier）,用于認證時CPE上報AAA，幫助中繼設備轉(zhuǎn)發(fā)到合適的服務器。3.證

47、書配置：用于CPE驗證AAA下發(fā)的AAA證書是否合法進一步參考WMF-T32-001-R015v02_Network-Stage2-Base7節(jié)321CPE認證配置說明1.業(yè)務面加密配置：業(yè)務面加密選項AES：advancedencryptionstandardCTR：countermodeencryptionCBC：cipherblockchainingCBC-MAC：cipherblockchainingmessageauthenticationcodeCCM：CTRmodewithCBC-MACECB：electroniccodebook2.密鑰交換配置：AES-KeyWrap：是否使能

48、AESkeywrapalgorithm，BS發(fā)送給CPE的業(yè)務面key將經(jīng)過該算法處理，MS根據(jù)相同算法還原該keyAES-ECB：BS發(fā)送給CPE的業(yè)務面KEY是否經(jīng)過AESECB加密EAPMode：認證承載協(xié)議InternalMode:認證方法（用戶認證時使用）,可以是PAP/CHAP/MSCHAPV2/MD5。AnonymousID:NAI（Networkaccessidentifier）,用于認證時CPE上報AAA，幫助中繼設備轉(zhuǎn)發(fā)到合適的服務器。3.證書配置：用于CPE驗證AAA下發(fā)的AAA證書是否合法進一步參考WMF-T32-001-R015v02_Network-Stage2-B

49、ase7節(jié)321wimax認證整體流程CPE和AAAServer雙向認證階段：雙向認證完畢后，CPE和AAASERVER將生成相同的MSK和EMSKSA生成階段：CPE和GW根據(jù)MSK，各自生成相同的PMK，再由PMK聯(lián)合MSIDBSID生AK和AK上下文,AK由GW下發(fā)BS密鑰下發(fā)階段：通過3次握手（6）完成SAAK驗證以及PrimarySA的分配；同時通過（7）完成每個SA關聯(lián)的2個TEK(trafficencryptionkey)的生成和下發(fā)CPE進一步參考 7.3.10 和 PART16中節(jié)wimax認證流程-雙向認證進一步信息參考前文TLS協(xié)議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基本能力協(xié)商后，ASN-GW發(fā)起EAPIdentify流程，MS將響應EAPIdentify/NAI,ASN-GW根據(jù)NAI指定

52、的域名將消息轉(zhuǎn)發(fā)AAA，隨后后續(xù)的流程實際上都是經(jīng)過GW透傳給MS和AAA通過TLS完成AAA到MS的認證（采用數(shù)字證書方式），同時完成了PREMSK的交換（通過DH或RSA）2.左圖為用戶認證方式，如果為設備認證時MS側(cè)也需要將自己的證書發(fā)送發(fā)送AAA完成MS到AAA的認證3.經(jīng)過此步后，AAA和MS可以生成的MSK/EMSK,AAA會將MSK下發(fā)給GW，GW進一步生成PMK/AK，并下發(fā)BS1.當認證方式為用戶認證時，進一步通過認證協(xié)議完成MS到AAA的認證（認證協(xié)議可以是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是第一條使用剛剛協(xié)商后的加密參數(shù)加密的消息wimax認證流程-設備認證雙向認證實例由于設備認證時，認證EAP-TLS，所以CPE響應Nak,告知AAA側(cè)要使用EAP-TLS協(xié)議，后續(xù)流程全部用EAP-

55、TLSserver發(fā)送證書/Serverhello/Serverkeyexchange/ServerhellodoneCPE發(fā)送證書/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下發(fā)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個人的名字命名，原理說明：離散對數(shù)問題：若p是素數(shù)，p已知，考慮方程y=gxmodp，給定g,x求y是簡單的，但給定y,g求x，即求x=logg,pymodp，在計算上是不可行的。DH密鑰交換算法的描述如下：已知公開的素數(shù)p和p的本原根1.用戶A選擇秘密的Xap，計算Ya=Xamodp，將其

61、發(fā)送給B。2.用戶B選擇秘密的Xbp，計算Yb=Xbmodp，將其發(fā)送給A。3.A和B分別計算Ka=(Yb)Xamodp和Kb=(Ya)Xbmodp，就同時得到了共享的密鑰K=Ka=Kb，然后就可以用K進行加密傳輸了。DH密鑰交換算法的優(yōu)點在于：雙方在通信前不需要知道任何共享的密鑰，而是通過公開的p和協(xié)商出一個密鑰來進行加密通信。先看一下算法的正確性，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，由離散對數(shù)問題，從Ya,Yb求出Xa,Xb在計算上是不可行的，就保證了算法的安全性。參考自百度百科附錄2：RSA公鑰加密算法RSA公鑰加密算法是1977年由RonRivest、AdiShamirh和LenAdleman在（美國麻省理工學院）開發(fā)的。RSA取名來自開發(fā)他們?nèi)叩拿?。RSA是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被ISO推薦為公鑰數(shù)據(jù)加密標準。RSA算法基于一個十分簡單的數(shù)論事實：將兩個大素數(shù)相乘十分容易，但那時想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為

63、加密密鑰。RSA公開密鑰密碼體制。所謂的公開密鑰密碼體制就是使用不同的加密密鑰與解密密鑰，是一種“由已知加密密鑰推導出解密密鑰在計算上是不可行的”密碼體制。非對稱加密密碼算法，用公鑰加密，必須用密鑰解密；反過來，用密鑰加密，必須用公鑰解密應用場景：加解密server分發(fā)公鑰給client，自己保留密鑰，client用公鑰加密后的數(shù)據(jù)只能有server解密數(shù)字簽名server將用密鑰加密的簽名和原始簽名發(fā)送給client，client用公鑰解密簽名，和原始簽名一致時，認為數(shù)字簽名有效，可以認證該server。參考自百度百科附錄3：CBCcipherblockchaining密碼段連接（CBC）是

64、一種操作分段密碼的方式（在一段bit序列加密成一個單獨的單元或分成一個密鑰提供給整個部分）。密碼段連接使用一定長度初始化向量（IV）。他的一個主要特點是他完全依靠前面的密碼文段來譯碼后面的內(nèi)容。因此，整個過程的正確性決定于前面的部分。各部分的順序也必須保持正確。在面段連接中，每個文件部分先用前面的部分XOR化（參看XOR），然后加密。如果各部分順序沒變，使用相同的密鑰和初始化向量，只有同樣的密碼部分可以起作用。因為XOR過程隱藏了原文，密碼段連接要優(yōu)于電子密碼書模式。理論上，兩條信息使用相同的密鑰加密會產(chǎn)生不同的初始化向量。所以初始化向量不需要保密，這將極大方便某些場合的應用。參考自百度百科附

65、錄4：SHASecureHashAlgorithmSHA是一種數(shù)據(jù)加密算法，該算法經(jīng)過加密專家多年來的發(fā)展和改進已日益完善，現(xiàn)在已成為公認的最安全的散列算法之一，并被廣泛使用。該算法的思想是接收一段明文，然后以一種不可逆的方式將它轉(zhuǎn)換成一段（通常更?。┟芪?，也可以簡單的理解為取一串輸入碼（稱為預映射或信息），并把它們轉(zhuǎn)化為長度較短、位數(shù)固定的輸出序列即散列值（也稱為信息摘要或信息認證代碼）的過程。散列函數(shù)值可以說時對明文的一種“指紋”或是“摘要”所以對散列值的數(shù)字簽名就可以視為對此明文的數(shù)字簽名。散列是信息的提煉，通常其長度要比信息小得多，且為一個固定長度。加密性強的散列一定是不可逆的，這就意

66、味著通過散列結(jié)果，無法推出任何部分的原始信息。任何輸入信息的變化，哪怕僅一位，都將導致散列結(jié)果的明顯變化，這稱之為雪崩效應。散列還應該是防沖突的，即找不出具有相同散列結(jié)果的兩條信息。具有這些特性的散列結(jié)果就可以用于驗證信息是否被修改。單向散列函數(shù)一般用于產(chǎn)生消息摘要，密鑰加密等，常見的有：lMD5（MessageDigestAlgorithm5）：是RSA數(shù)據(jù)安全公司開發(fā)的一種單向散列算法。lSHA（SecureHashAlgorithm）：可以對任意長度的數(shù)據(jù)運算生成一個160位的數(shù)值；應用：MAC（信息認證代碼）就是一個散列結(jié)果，其中部分輸入信息是密碼，只有知道這個密碼的參與者才能再次計算和驗證MAC碼的合法性。參考自百度百科附錄5：AESAdvancedEncryptionStandard密碼學中的高級加密標準（AdvancedEncryptionStandard，AES），又稱Rijndael加密法，是美國聯(lián)邦政府采用的一種區(qū)塊加密標準。這個標準用來替代原先的DES（DataEncryptionStandard），已經(jīng)被多方分析且廣為全世界所使用。經(jīng)過五年的甄選流程，高級加密標