WiMAX入網(wǎng)過程PPT課件

下載文檔

下載文檔到電腦，查找使用更方便還剩頁(yè)未讀，繼續(xù)閱讀>>

侵權(quán)申訴舉報(bào)

1 / 65

此文檔下載收益歸作者所有下載文檔

版權(quán)提示

文本預(yù)覽

常見問題

wimax入網(wǎng)入網(wǎng)過過程程Jade 2013目錄概述免認(rèn)證入網(wǎng)認(rèn)證入網(wǎng)Wimax網(wǎng)絡(luò)架構(gòu)PSTN:PublicSwitchedTelephoneNetwork公共交換電話網(wǎng)絡(luò)AAA:Authentication、Authorization、Accounting認(rèn)證鑒權(quán)計(jì)費(fèi)服務(wù)器ASN:AccessServiceNetwork接入網(wǎng)(BS/MS/ASNGW)BS:BasestationSS:SubscriberstationAAA ServerAAA ServerPSTNIP CorePortalPortalPortalPortalSSSSSSPCMCIAASN GWBSBSWimax網(wǎng)絡(luò)參考模型ASN:AccessServiceNetwork;CSN:ConnectivityServiceNetwork/CoreNetworkASP:ApplicationServiceProviderNSP:NetworkServiceProviderNAP:NetworkAccessProviderHomeNSP:HomeNetworkServiceProvider(可理解為用戶所屬的運(yùn)營(yíng)商)VisitedNSP:VisitedNSP(用戶漫游到和HomeNSP有漫游協(xié)議的NSP)Bearerplane:承載平面，用戶承載業(yè)務(wù)數(shù)據(jù)流Controlplane:控制平面，用戶邏輯實(shí)體間的信令交互O&Mplane：管理平面，用于邏輯實(shí)體操作維護(hù)信息的交互網(wǎng)絡(luò)參考模型定義各個(gè)邏輯功能實(shí)體的功能/以及他們直接按的參考接口各個(gè)邏輯功能實(shí)體可能對(duì)應(yīng)實(shí)際物理組網(wǎng)中一個(gè)或多個(gè)設(shè)備從左圖可以看到主要邏輯功能實(shí)體有ASN/CSN/MS(MS也可算ASN的一部分)實(shí)際組網(wǎng)過程中，可能涉及終端用戶/網(wǎng)絡(luò)接入服務(wù)商/網(wǎng)絡(luò)服務(wù)提供商/應(yīng)用服務(wù)提供商N(yùn)AP/NSP/ASP等在wimax出現(xiàn)前已存在，wimax重點(diǎn)在于ASN進(jìn)一步請(qǐng)參考：WMF-T32-002-R010v05_Network-Stage2-Part1ASN參考模型BS:basestation,按照協(xié)議實(shí)現(xiàn)wimaxMAC/PHY層的邏輯實(shí)體，功能包括但不限于對(duì)無線空口上下行資源的調(diào)度/管理，和ASN-GW業(yè)務(wù)連接的管理等。

ASN-GW:ASN網(wǎng)絡(luò)對(duì)外接口功能實(shí)體，在網(wǎng)絡(luò)上具有承上啟下的作用，對(duì)內(nèi)完成無線資源管理；對(duì)外完成相關(guān)控制面信令的承載/轉(zhuǎn)發(fā)和業(yè)務(wù)面承載關(guān)于ASN側(cè)完成的邏輯功能在BS和ASN-GW間的分解/分配請(qǐng)參考WMF-T32-003-R010v05_Network-Stage2-Part2中8.ASNProfileIntroduction章節(jié)ASN網(wǎng)絡(luò)由BS/ASN-GW/MS等實(shí)體組成典型的MS初始接入涉及的接口為R1/R6口，R3/R4接口可能涉及，但不需重點(diǎn)關(guān)注R1口為空口，為wimax協(xié)議的重中之重進(jìn)一步請(qǐng)參考WMF-T32-002-R010v05_Network-Stage2-Part1接口協(xié)議棧samedifferentdifferentConvergenceSublayer(CS)TheIEEEStd802.16definesmultipleconvergencesublayers.ThenetworkarchitectureframeworkSHALLsupportthefollowingCStypes:EthernetCSandIPv4/IPv6overEthernetCS,IPv4CS,IPv6CS.請(qǐng)參考WMF-T32-003-R010v05_Network-Stage2-Part1/Part2R1接口參考模型SAP:ServiceAccessPointC-SAP:ControlSAPM-SAP:ManagementSAPOFDM:orthogonalfrequencydivisionmultiplexingOFDMA:orthogonalfrequencydivisionmultiplexaccessOFDMA物理層和OFDM物理層最根本的區(qū)別在于前者在上行和下行均支持子信道化,后者僅在上行方向支持子信道化并且OFDMA在空口資源上分配方式更加靈活（右圖）Wimax標(biāo)準(zhǔn)定義了R1口的MAC層和PHY層MAC層：包括CSCPSSS三個(gè)子層：CS執(zhí)行外部網(wǎng)絡(luò)數(shù)據(jù)的轉(zhuǎn)換或映射到CPS子層；CPS執(zhí)行MAC核心功能，包括系統(tǒng)接入帶寬分配連接建立與維護(hù)；SS子層主要完成安全相關(guān)功能，包括鑒權(quán)密鑰交換加密。

PHY層：隨著協(xié)議的演進(jìn)，協(xié)議規(guī)定了3類主要的物理層技術(shù)：WirelessMAN-SCWirelessMAN-OFDMWirelessMAN-OFDMA差別在于支持的頻段是否支持移動(dòng)空口性能，目前主流是支持移動(dòng)的OFDMA技術(shù)更多細(xì)節(jié)請(qǐng)參考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworksPart16:AirInterfaceforFixedandMobileBroadbandWirelessAccessSystems目錄概述免認(rèn)證入網(wǎng)流程認(rèn)證入網(wǎng)免認(rèn)證入網(wǎng)流程MSBSASN-GWDCDUCDDL-MAPUL-MAP偵聽周期廣播CDMAcodeRNG-RSP(status:Continue)loopCDMAcodeRNG-RSP(status:Success)碼調(diào)整測(cè)距RNG-REQRNG-RSPSBC-REQSBC-RSP3.基本能力協(xié)商REG-REQREG-RSPDSA-REQDSA-RSPDSA-ACKloop4.注冊(cè)5.建立業(yè)務(wù)流連接DHCP獲取IPMS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_AckMS_Attachment_ReqMS_Attachment_RsqMS_Attachment_AckRR_ReqRR_RspRR_Ack入網(wǎng)的5個(gè)步驟：1.MS與BS取得同步2.初始測(cè)距3.基本能力協(xié)商（PHY層能力安全能力參數(shù)等等）4.注冊(cè)（高層能力協(xié)商）5.建立業(yè)務(wù)流連接message注釋：D/DL代表DownlinkU/UL代表UplinkRNG:RangingDCD:DLchanneldescriptorUCD:ULchanneldescriptorSBC:SSbasiccapabilityDSA:Dynamicserviceflowadd可選的認(rèn)證流程1.MS偵聽下行廣播MS偵聽BS下行廣播信息目的：和和BS取得物理取得物理層層同步同步MS開機(jī)后掃描可能的連續(xù)下行頻帶，直到找到一個(gè)正確的下行信道，和BS取得時(shí)間和頻率上同步和和BS取得下行取得下行MAC層層同步同步-Obtain DL parametersMS和BS取得物理層同步后，嘗試搜索DL-MAP和DCD消息，能夠連續(xù)解出這2個(gè)消息將保持MAC同步狀態(tài)取得上行通道參數(shù)取得上行通道參數(shù)-Obtain UL parameters取得下行MAC層同步后，搜索UL-MAP和UCD消息，獲取上行發(fā)射參數(shù)，能夠連續(xù)解出這2條消息將保持同步狀態(tài)Ms和BS取得MAC層同步后，具備了發(fā)起Ranging的條件。

進(jìn)一步參考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中節(jié)MSDCD（DIUC檢索表/BSEIRP/TTG/RTG等）UCD（UIUC檢索表/上行接入的ranging相關(guān)信息等）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分分別對(duì)應(yīng)別對(duì)應(yīng)上下行不同的上下行不同的調(diào)調(diào)制制/編碼編碼方式索引方式索引EIRP：有效全向：有效全向輻輻射功率射功率TTG：transmit/receive transition gapRTG：receive/transmit transition gap2.cdma碼調(diào)整測(cè)距測(cè)距目的不斷調(diào)整SS的Timingoffset/Freqoffset/poweroffset，使得SS的發(fā)射和接收達(dá)到最優(yōu)過程要點(diǎn)初始測(cè)距是一個(gè)反復(fù)的過程，Ms在上行ranging時(shí)機(jī)隨機(jī)選擇CDMAcode，測(cè)量出MS的時(shí)偏/頻偏/功率偏差等信道參數(shù)，然后響應(yīng)RNG-RSP，告訴MS應(yīng)該如何調(diào)整信道參數(shù)，如此反復(fù)，直到信道參數(shù)達(dá)到最優(yōu)，在最后的RNG-RSP中攜帶給MS分配的相關(guān)資源MS在得到分配的資源后，可以繼續(xù)后續(xù)的接入流程如果MS已經(jīng)入過網(wǎng)且所在位置未變/BS側(cè)配置未變時(shí)，MS復(fù)位，初始測(cè)距可能不需反復(fù)，一次可以成功（MS將相關(guān)信息記錄到了FALSH中）更多信息可參考IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)MSBSRNG-REQ/CDMAcodeRNG-RSP(status:Continue)loopRNG-REQ/CDMAcodeRNG-RSP(status:Success)RNG-REQRNG-RSPCDMAcode為一個(gè)特殊的消息序列，且任意2個(gè)序列之間不具有相關(guān)性3.基本能力協(xié)商目的匹配MS和BS間的基本能力，包括PHY能力/安全能力過程說明MS將自身的基本支持能力通過SBC-REQ上報(bào)BSBS向ASN-GW發(fā)送消息（可攜帶需要到GW協(xié)商的能力），通知GW該MS入網(wǎng)ASN-GW響應(yīng)BS，BS將MS上報(bào)的支持能力和網(wǎng)絡(luò)側(cè)的支持能力取交集下發(fā)MS更多信息可參考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)MSBSASN-GWSBC-REQSBC-RSPMS_PreAttachment_ReqMS_PreAttachment_RspMS_PreAttachment_Ack4.注冊(cè)目的匹配MS和網(wǎng)絡(luò)側(cè)高層支持能力，包括CS支持能力/移動(dòng)性參數(shù)/切換支持能力等過程MS通過REG-REQ攜帶自身的高層支持能力向BS發(fā)起注冊(cè)請(qǐng)求BS向ASN-GW發(fā)送消息（可攜帶需要到GW協(xié)商的能力），通知GW該MS發(fā)起注冊(cè)，GW側(cè)準(zhǔn)備發(fā)起業(yè)務(wù)流建立ASN-GW響應(yīng)BS，BS將MS上報(bào)的支持能力和網(wǎng)絡(luò)側(cè)的支持能力取交集下發(fā)MS更多信息可參考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)MSBSASN-GWREG-REQREG-RSPMS_Attachment_ReqMS_Attachment_RsqMS_Attachment_Ack5.業(yè)務(wù)流建立目的建立預(yù)配置業(yè)務(wù)流，即建立端到端的業(yè)務(wù)承載通道過程ASN-GW側(cè)在收到MS的REG-REQ時(shí)，主動(dòng)發(fā)起預(yù)配置業(yè)務(wù)流建立，攜帶業(yè)務(wù)流相關(guān)參數(shù)向BS下發(fā)RR_REQ消息BS向MS下發(fā)DSA_REQ消息將業(yè)務(wù)流信息通知MSMS通過DSA_RSP響應(yīng)BS，并向MS返回DSA_ACKBS向ASN-GW返回RR_RSP完成業(yè)務(wù)流建立業(yè)務(wù)流建立完成后，可以進(jìn)行業(yè)務(wù)，隨后發(fā)起的DHCP過程即使用第一條預(yù)配置業(yè)務(wù)流（ISF）來承載第一條建立的預(yù)置業(yè)務(wù)流成為初始業(yè)務(wù)流(ISF),用來承載對(duì)于時(shí)延不敏感的業(yè)務(wù)，比如隨后的DHCP過程ISF只有一條，除ISF外的預(yù)置業(yè)務(wù)流可以有多條MSBSASN-GWDSA-REQDSA-RSPDSA-ACKloop通過預(yù)配置業(yè)務(wù)流承載DHCP協(xié)議獲取IPRR_ReqRR_Rsp更多信息可參考:IEEEStd802.16e-2005,IEEEStandardforLocalandmetropolitanareanetworks中的章節(jié)WMF-T33-001-R015v03_Network-Stage3-Base中節(jié)目錄概述免認(rèn)證入網(wǎng)認(rèn)證入網(wǎng)認(rèn)證基礎(chǔ)-EAP概述EAP：ExtensibleAuthenticationProtocol是一個(gè)認(rèn)證框架，在此框架上可以支持或者說承載多種認(rèn)證協(xié)議方法，比如EAP-TLSEAP-TTLS交互方式采用lock-step，同時(shí)只能有一個(gè)報(bào)文在傳輸，等到對(duì)方響應(yīng)后才可以發(fā)送下一個(gè)報(bào)文一般是request/response1，nsuccess/failure1支持重傳，但是不支持分片和重組認(rèn)證由server發(fā)起，而不是client2.通用包格式定義Code：1byte,目前只有4種定義：1Request2Response3Success4FailureIdentifier:1byte，認(rèn)證雙方通信時(shí)用的transId，匹配一個(gè)Request和ResponseLength:2byte,報(bào)文長(zhǎng)度，從Code字段開始。

Data：報(bào)文內(nèi)容，根據(jù)Code取值不同，需要進(jìn)一步擴(kuò)展認(rèn)證消息交互基本框架認(rèn)證基礎(chǔ)-EAP消息格式Request和Response報(bào)文格式進(jìn)一步請(qǐng)參考RFC3748 Extensible Authentication ProtocolType定義:Type字段可以由EAP承載的認(rèn)證協(xié)議擴(kuò)展，比如EAP-TTLS，Type字段為21；EAP-TLS，Type取值為13.Nak用于接收方向發(fā)送方反饋，接收方不支持發(fā)送方指定的type，同時(shí)攜帶接收方支持的type通知發(fā)送方可以用這些type（下文設(shè)備認(rèn)證將看到此應(yīng)用）Success和Failure報(bào)文格式認(rèn)證基礎(chǔ)-EAP-TTLS概述EAP-TTLS：ExtensibleAuthenticationProtocolTunneledTransportLayerSecurityAuthenticatedProtocolVersion0(EAP-TTLSv0)是EAP承載的一種方法，其封裝了TLS協(xié)議，認(rèn)證過程劃分為2個(gè)階段：Phase1：Handshake，完成client和server的雙向認(rèn)證，或者只是完成server到client的認(rèn)證，同時(shí)協(xié)商出2階段tunnel使用的ciphersuite，保障tunnel階段數(shù)據(jù)的安全傳輸。

Phase2：Tunnel，通過TLSrecordlayer建立的隧道在client和server間傳輸任意數(shù)據(jù)，完成特定的功能包括client到server的認(rèn)證，在Tunnel承載的認(rèn)證協(xié)議可以是PAP,CHAP,MS-CHAP,orMS-CHAP-V2，MD5等CPE使用用戶認(rèn)證方式時(shí)，采用EAP-TTLS協(xié)議，第一階段完成server到CPE的認(rèn)證，第二階段使用指定的認(rèn)證承載協(xié)議（可配置為PAPCHAPMS-CHAPMS-CHAP-V2MD5）完成CPE到server的認(rèn)證2.協(xié)議分層模型進(jìn)一步參考RFC5281 EAP-TTLSAVP，attribute-value pairs，類似TLV認(rèn)證基礎(chǔ)-EAP-TTLS消息格式包格式進(jìn)一步參考RFC5281 EAP-TTLSCode(Request/Response)IdentifierLengthType(21)見EAP協(xié)議；FlagsData認(rèn)證基礎(chǔ)-EAP-TTLS密鑰(MSK)生成KeyDerivation進(jìn)一步參考RFC5281 EAP-TTLSEAP-TTLS協(xié)商完畢后，將按如上算法生成MSKEMSK，此值將用于后續(xù)的密鑰生成。

TLSPRF(pseudo-randomfunction)function參考rfc5216/rfc2246.認(rèn)證基礎(chǔ)-EAP-TLSEAP承載的認(rèn)證方法支持client和server間基于證書的相互認(rèn)證密鑰生成流程基本同EAP-TTLS，相比EAP-TTLS少了tunnel階段，安全性略差，由于只支持基于證書的相互認(rèn)證，CPE設(shè)備認(rèn)證可以采用該協(xié)議，用戶認(rèn)證需要使用EAP-TTLS協(xié)議進(jìn)一步請(qǐng)參考RFC5216 EAP-TLS左圖為典型的交互流程：包含identify證書交換密鑰（premastersecret）交換等過程進(jìn)一步參考RFC5281 EAP-TTLS認(rèn)證基礎(chǔ)-TLS概述TLS:TransportLayerSecurity提供Internet網(wǎng)絡(luò)的傳輸安全，對(duì)于client和server間的數(shù)據(jù)傳輸提供了防竊聽，防篡改，防偽造功能包括2層：theTLSRecordProtocolandtheTLSHandshakeProtocol.TLSRecordLayer用于封裝各種高層協(xié)議（例如可以封裝TLSHandshakeProtocol），安全性說明：TLSRecordLayer通過對(duì)稱加密算法保證傳輸數(shù)據(jù)的私密性通過MAC（messageauthenticationcode）保證傳輸數(shù)據(jù)的完整性，將待傳輸數(shù)據(jù)（壓縮（可選）后加密前）聯(lián)合密鑰通過HASH算法（MD5/SHA）生成MACcode，供接收方校驗(yàn)完整性TLSHandshake用于服務(wù)器和客戶端相互認(rèn)證和協(xié)商應(yīng)用層協(xié)議的加密算法和加密密鑰進(jìn)一步參考認(rèn)證基礎(chǔ)-TLS安全參數(shù)安全參數(shù)生成加密算法：rc4,rc2,des,3des,des40,idea,aes可以為null加密算法類型：block方式流方式MAC算法：md5,sha壓縮算法，可以為空雙方共知的48bytesecretclient端randomserver端ramdom進(jìn)一步參考block加密使用，non-exportblockciphers方式通過此方式生成，exportableblockciphers方式需要進(jìn)一步算法生成認(rèn)證基礎(chǔ)-TLS通用包格式TLSRecordLayer包格式進(jìn)一步參考Type：承載的協(xié)議類型change_cipher_spec:20alert:21handshake:22application_data:23version:版本號(hào)目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到華為wimax是0301，對(duì)應(yīng)1.0(RFC2246),由于TSL基于演變而來，所以消息編碼為（0301）。

length：后續(xù)數(shù)據(jù)長(zhǎng)度fragment：協(xié)議報(bào)文當(dāng)fragment經(jīng)過壓縮/加密后，格式路略有變化，具體參考協(xié)議認(rèn)證基礎(chǔ)-TLS通用包格式TLSRecordLayer包格式進(jìn)一步參考Type：承載的協(xié)議類型change_cipher_spec:20alert:21handshake:22application_data:23version:版本號(hào)目前有1.0(RFC2246)/1.1(RFC4346)/1.2(RFC?)，抓包看到華為wimax是0301，對(duì)應(yīng)1.0(RFC2246),由于TSL基于演變而來，所以消息編碼為（0301）length：后續(xù)數(shù)據(jù)長(zhǎng)度fragment：協(xié)議報(bào)文當(dāng)fragment經(jīng)過壓縮/加密后，格式路略有變化，具體參考協(xié)議認(rèn)證基礎(chǔ)-TLSHandshakeProtocolTLSHandshakeProtocol用于雙方協(xié)商安全參數(shù)相互認(rèn)證包含3個(gè)子協(xié)議：Changecipherspecprotocol用于在安全參數(shù)協(xié)商過后，通知對(duì)方隨后的交互將使用之前剛剛協(xié)商的安全參數(shù)進(jìn)行加密處理該子協(xié)議只包含change_cipher_spec(1)這1條消息Alertprotocol傳遞告警信息Handshakeprotocol見下頁(yè)進(jìn)一步參考Handshake過程：協(xié)商加密算法/交換random交換信息雙方生成一致的premaster secret交換證書和加密信息并認(rèn)證生成Master secret給record layer提供加密參數(shù)驗(yàn)證雙方生成了相同的安全參數(shù)認(rèn)證基礎(chǔ)-TLSHandshakeProtocol包格式Handshakeprotocol用于協(xié)商安全參數(shù)包格式定義：進(jìn)一步參考包含的消息類型認(rèn)證基礎(chǔ)-TLShellomessageHandshaketype之hellomessage包括hellorequest/clienthello/serverhello三個(gè)消息，這3個(gè)消息用于雙方協(xié)商安全能力：加密能力/壓縮能力Hellorequest只用于server請(qǐng)求client發(fā)送clienthello消息，即server要求client發(fā)起協(xié)商Clienthello用于client主動(dòng)向server發(fā)起協(xié)商流程消息中包含random值（32byte（4byteGMTTIME+28byterandom）client支持的CipherSuitelistclient支持的壓縮算法Serverhelloserver對(duì)client的hello消息的響應(yīng)消息中包含random值/server選擇的CipherSuite/server選擇的壓縮算法以及分配的sessionid進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSServercertificateHandshaketype之ServercertificateServer發(fā)送證書給client證書格式參考證書的key和簽名必須和hello協(xié)商的Ciphersuite指定加密方式一致進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSServerkeyexchangemessageHandshaketype之ServerkeyexchangemessageTheserverkeyexchangemessageissentbytheserveronlywhentheservercertificatemessage(ifsent)doesnotcontainenoughdatatoallowtheclienttoexchangeapremastersecret.Thismessageconveyscryptographicinformationtoallowtheclienttocommunicatethepremastersecret：eitheranRSApublickeytoencryptthepremastersecretwith,oraDiffie-Hellmanpublickeywithwhichtheclientcancompleteakeyexchange幫助client計(jì)算server的premaster值進(jìn)一步參考RFC2246 TLS1.0 和附錄1 DH密鑰交換算法認(rèn)證基礎(chǔ)-TLSCertificaterequestHandshaketype之Certificaterequest用于server向client請(qǐng)求證書（可選）目前認(rèn)證流程不涉及，進(jìn)一步信息參考協(xié)議進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSServerhellodoneHandshaketype之ServerhellodoneTheserverhellodonemessageissentbytheservertoindicatetheendoftheserverhelloandassociatedmessages.目前認(rèn)證流程不涉及，進(jìn)一步信息參考協(xié)議進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSClientcertificateHandshaketype之Clientcertificate發(fā)送client端證書證書格式參考進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSClientkeyexchangemessageHandshaketype之ClientkeyexchangemessageWiththismessage,thepremastersecretisset,eitherthoughdirecttransmissionoftheRSA-encryptedsecret,orbythetransmissionofDiffie-Hellmanparameterswhichwillalloweachsidetoagreeuponthesamepremastersecret.用于client通知server客戶端的premastersecret，比如密鑰交換算法選擇RSA時(shí)，client用server段下發(fā)證書中的publickey將自身產(chǎn)生的48byte的premastersecret加密，發(fā)給server；采用密鑰交換算法采用DH時(shí)，client和server互換DH計(jì)算參數(shù)，從而雙方生成一致的premastersecret進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSCertificateverifymessageHandshaketype之CertificateverifyThismessageisusedtoprovideexplicitverificationofaclientcertificate.Whensent,itwillimmediatelyfollowtheclientkeyexchangemessage.包格式進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSFinishedmessageHandshaketype之FinishedAfinishedmessageisalwayssentimmediatelyafterachangecipherspecmessagetoverifythatthekeyexchangeandauthenticationprocessesweresuccessful.Thefinishedmessageisthefirstprotectedwiththejust-negotiatedalgorithms,keys,andsecrets.Recipientsoffinishedmessagesmustverifythatthecontentsarecorrect.進(jìn)一步參考認(rèn)證基礎(chǔ)-TLSHandshakemessage總結(jié)Handshaketype之Finished原則上述消息必須按照上文描述的順序發(fā)送，只有2個(gè)例外：theCertificatemessageisusedtwiceinthehandshake(fromservertoclient,thenfromclienttoserver),butdescribedonlyinitsfirstposition.TheonemessagewhichisnotboundbytheseorderingrulesintheHelloRequestmessage,whichcanbesentatanytime,butwhichshouldbeignoredbytheclientifitarrivesinthemiddleofahandshake.進(jìn)一步參考認(rèn)證基礎(chǔ)-MS-CHAP-V2MS-CHAP-V2:MicrosoftPPPCHAPExtensions,Version2.MS基于PPPCHAP協(xié)議的擴(kuò)展增強(qiáng)版本，主要增強(qiáng)了用戶認(rèn)證功能通過3-wayhandshake驗(yàn)證peer的身份：1.authenticators發(fā)送生成并發(fā)送challengecode（隨機(jī)數(shù)），消息中攜帶了用戶名2.Client根據(jù)16-octetchallengeValueusernamepassword經(jīng)過一定算法生成RADOM值（24byte），發(fā)送給authenticator3.authenticator經(jīng)過同樣算法計(jì)算得到Hash值，與Client發(fā)來的RADOM值比較成功時(shí)，返回SuccessCPE采用用戶認(rèn)證方式時(shí)，由CPE發(fā)起Challenge，在該消息中，CPE根據(jù)CPEchallenge值usernamepasspeerchallenge值經(jīng)過一定算法成生24byte的RADOM值，連同CPEchallenge值usernamepeerchallenge值一并發(fā)給server；server根據(jù)Challenge中的username獲取到對(duì)應(yīng)的密碼，根據(jù)同樣的算法生成RADOM值，和CPE發(fā)送來的RADOM比較，一致返回success，否則返回失敗。

進(jìn)一步參考RFC1994 CHAPRFC2433 MS-CHAPRFC2759 MS-CHAP-V2CPE認(rèn)證分類認(rèn)證的目的在于雙方互相判斷對(duì)方是否合法，同時(shí)協(xié)商加密信息，用于后續(xù)報(bào)文的安全傳輸認(rèn)證分類：免認(rèn)證用戶認(rèn)證CPE認(rèn)證AAAbasedonX.509certificateAAA認(rèn)證CPE基于用戶名密碼CPE和AAA間基于EAP-TTLS認(rèn)證協(xié)議設(shè)備認(rèn)證CPE和AAA相互認(rèn)證basedonX.509certificateCPE和AAA間基于EAP-TLS認(rèn)證協(xié)議認(rèn)證協(xié)議棧進(jìn)一步請(qǐng)參考：參考WMF-T32-001-R015v02_Network-Stage2-Base節(jié)參考RFC5281EAP-TTLS從協(xié)議棧可以看出，認(rèn)證過程在MS和AAA間完成，中間網(wǎng)絡(luò)節(jié)點(diǎn)提供EAP通道在R1口EAP通過PKMV2（wimax定制）承載EAP屬于一個(gè)認(rèn)證流程的處理框架，其上可以承載多種具體的安全協(xié)議/認(rèn)證協(xié)議CPE采用用戶認(rèn)證時(shí)，可以配置EAP具體承載的認(rèn)證協(xié)議來安全的傳輸CPE的用戶名和密碼信息給AAA，支持如下5種協(xié)議：MS-CHAP/MS-CHAPV2CHAP(ChallengeAuth.Protocol)MD5PAP(PasswordAuth.Protocol)CPE采用設(shè)備認(rèn)證時(shí)，由于AAA使用證書認(rèn)證CPE，不需傳遞用戶名/密碼，所以不需配置認(rèn)證協(xié)議。

用用戶認(rèn)證戶認(rèn)證)/EAP-TLS()/EAP-TLS(設(shè)備認(rèn)證設(shè)備認(rèn)證）設(shè)備認(rèn)證不需要安全子層PKM：privacykeymanagement進(jìn)一步請(qǐng)參考P80216Rev_037節(jié)Trafficdata.:業(yè)務(wù)面加解密/業(yè)務(wù)面分包認(rèn)證MessageAuthenticationProcessing：控制面分包認(rèn)證(HMAC/CMAC/short-HMACs)ControlMessageProcessing:PKM消息分發(fā)處理PKMControlManagement：SS控制管理層，密鑰生成分發(fā)RSA-basedAuthentication：基于RSA的數(shù)字證書的認(rèn)證處理Authorization/SAControl:認(rèn)證狀態(tài)機(jī)和業(yè)務(wù)加密密鑰狀態(tài)機(jī)控制EAPEncapsulation/Decapsulation:EAP接口處理層EAP參考前文認(rèn)證基礎(chǔ)PKMv1providessupportforonlyDeviceAuthenticationwhereasPKMv2providesaflexiblesolutionthatsupportsdeviceanduserauthenticationbetweenMSandhomeCSN.WIMAX密鑰體系一進(jìn)一步請(qǐng)參考P80216Rev_037節(jié)MSK：經(jīng)過EAP認(rèn)證后網(wǎng)絡(luò)側(cè)和MS都生成了同樣的MSK(Mastersessionkey)PMK：取MSK的160bit作為PMK(pairwisemasterkey)PMK聯(lián)合SSIDBSIDPMK生成AK(authorizationkey)，AK用于進(jìn)一步派生其他密鑰WIMAX密鑰體系二進(jìn)一步請(qǐng)參考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è)務(wù)面加密，MAC消息中通用頭不加密，只有payload才會(huì)加密，由BS負(fù)責(zé)生成，下發(fā)MS。

其他非重要KEY參見協(xié)議CPE認(rèn)證配置說明1.業(yè)務(wù)面加密配置：業(yè)務(wù)面加密選項(xiàng)，wimax協(xié)議上有四種：DES-CBCASE-CCMAES-CBCASE-CTR，從配置上看，只能配置2種，具體使用哪種由BS配置給MSAES：advancedencryptionstandardCTR：countermodeencryptionCBC：cipherblockchainingCBC-MAC：cipherblockchainingmessageauthenticationcodeCCM：CTRmodewithCBC-MACECB：electroniccodebook2.密鑰交換配置：AES-KeyWrap：是否使能AESkeywrapalgorithm，BS發(fā)送給CPE的業(yè)務(wù)面key將經(jīng)過該算法處理，MS根據(jù)相同算法還原該keyAES-ECB：BS發(fā)送給CPE的業(yè)務(wù)面KEY是否經(jīng)過AESECB加密上述是TEK配置給MS時(shí)，BS側(cè)采用的加密方式，協(xié)議上支持4種：3-DESRSAAES-ECBAES-KeyWrap，具體采用哪種由BS配置給MSEAPMode：認(rèn)證承載協(xié)議InternalMode:認(rèn)證方法（用戶認(rèn)證時(shí)使用）AnonymousID:NAI（Networkaccessidentifier）,用于認(rèn)證時(shí)CPE上報(bào)AAA，幫助中繼設(shè)備轉(zhuǎn)發(fā)到合適的服務(wù)器。

3.證書配置：用于CPE驗(yàn)證AAA下發(fā)的AAA證書是否合法進(jìn)一步參考WMF-T32-001-R015v02_Network-Stage2-Base7節(jié)321CPE認(rèn)證配置說明1.業(yè)務(wù)面加密配置：業(yè)務(wù)面加密選項(xiàng)AES：advancedencryptionstandardCTR：countermodeencryptionCBC：cipherblockchainingCBC-MAC：cipherblockchainingmessageauthenticationcodeCCM：CTRmodewithCBC-MACECB：electroniccodebook2.密鑰交換配置：AES-KeyWrap：是否使能AESkeywrapalgorithm，BS發(fā)送給CPE的業(yè)務(wù)面key將經(jīng)過該算法處理，MS根據(jù)相同算法還原該keyAES-ECB：BS發(fā)送給CPE的業(yè)務(wù)面KEY是否經(jīng)過AESECB加密EAPMode：認(rèn)證承載協(xié)議InternalMode:認(rèn)證方法（用戶認(rèn)證時(shí)使用）,可以是PAP/CHAP/MSCHAPV2/MD5AnonymousID:NAI（Networkaccessidentifier）,用于認(rèn)證時(shí)CPE上報(bào)AAA，幫助中繼設(shè)備轉(zhuǎn)發(fā)到合適的服務(wù)器。

3.證書配置：用于CPE驗(yàn)證AAA下發(fā)的AAA證書是否合法進(jìn)一步參考WMF-T32-001-R015v02_Network-Stage2-Base7節(jié)321wimax認(rèn)證整體流程CPE和AAAServer雙向認(rèn)證階段：雙向認(rèn)證完畢后，CPE和AAASERVER將生成相同的MSK和EMSKSA生成階段：CPE和GW根據(jù)MSK，各自生成相同的PMK，再由PMK聯(lián)合MSIDBSID生AK和AK上下文,AK由GW下發(fā)BS密鑰下發(fā)階段：通過3次握手（6）完成SAAK驗(yàn)證以及PrimarySA的分配；同時(shí)通過（7）完成每個(gè)SA關(guān)聯(lián)的2個(gè)TEK(trafficencryptionkey)的生成和下發(fā)CPE進(jìn)一步參考 7.3.10 和 PART16中節(jié)wimax認(rèn)證流程-雙向認(rèn)證進(jìn)一步信息參考前文TLS協(xié)議MSBSEAPrequest/IdentifyASN-GWAAAEAPresponse/Identify-NAIEAP-reponse/identifyoverAAAEAPrequest/TTLS-StartEAP-request/TTLS-StartoverAAAEAPresponse/TTLS/TLS:ClienthelloEAPrequest/TTLS/TLS:Serverhello/certificateServerkeyexchange/ServerhellodoneEAPoverAAAEAPoverAAAEAPresponse/TTLS/TLS:Clientkeyexchange/Changecipherspec/finishedEAPoverAAAEAPoverAAAEAPrequest/TTLS/TLS:Changecipherspec/finishedEAPresponse/TTLS/TLS:Peerresponse/challengeEAPrequest/TTLS/TLS:success/AuthenticatorresponseEAPresponse/TTLS(nodata)EAPoverAAAEAPoverAAAEAPSuccessEAPoverAAAEAPoverAAA基本能力協(xié)商后，ASN-GW發(fā)起EAPIdentify流程，MS將響應(yīng)EAPIdentify/NAI,ASN-GW根據(jù)NAI指定的域名將消息轉(zhuǎn)發(fā)AAA，隨后后續(xù)的流程實(shí)際上都是經(jīng)過GW透?jìng)鹘oMS和AAA通過TLS完成AAA到MS的認(rèn)證（采用數(shù)字證書方式），同時(shí)完成了PREMSK的交換（通過DH或RSA）2.左圖為用戶認(rèn)證方式，如果為設(shè)備認(rèn)證時(shí)MS側(cè)也需要將自己的證書發(fā)送發(fā)送AAA完成MS到AAA的認(rèn)證3.經(jīng)過此步后，AAA和MS可以生成的MSK/EMSK,AAA會(huì)將MSK下發(fā)給GW，GW進(jìn)一步生成PMK/AK，并下發(fā)BS1.當(dāng)認(rèn)證方式為用戶認(rèn)證時(shí)，進(jìn)一步通過認(rèn)證協(xié)議完成MS到AAA的認(rèn)證（認(rèn)證協(xié)議可以是mschapv2/mschap/chap/md5/pap）,當(dāng)設(shè)備認(rèn)證時(shí)，不含此步驟wimax認(rèn)證流程-用戶認(rèn)證雙向認(rèn)證實(shí)例MSBSEAPrequest/IdentifyASN-GWEAPresponse/Identify-NAIEAPrequest/TTLS-StartEAPresponse/TTLS/TLS:ClienthelloEAPrequest/TTLS/TLS:Serverhello/certificateServerkeyexchange/ServerhellodoneEAPresponse/TTLS/TLS:Clientkeyexchange/Changecipherspec/finishedEAPrequest/TTLS/TLS:Changecipherspec/finishedEAPresponse/TTLS/TLS:Peerresponse/challengeEAPrequest/TTLS/TLS:success/AuthenticatorresponseEAPresponse/TTLS(nodata)EAPSuccessserver的證書較長(zhǎng)，再加上Serverhello/Serverkeyexchange/Serverhellodone等消息，需要2條消息交互Finished是第一條使用剛剛協(xié)商后的加密參數(shù)加密的消息wimax認(rèn)證流程-設(shè)備認(rèn)證雙向認(rèn)證實(shí)例由于設(shè)備認(rèn)證時(shí)，認(rèn)證EAP-TLS，所以CPE響應(yīng)Nak,告知AAA側(cè)要使用EAP-TLS協(xié)議，后續(xù)流程全部用EAP-TLSserver發(fā)送證書/Serverhello/Serverkeyexchange/ServerhellodoneCPE發(fā)送證書/clientkeyexchange/證書驗(yàn)證/changecipherspecwimax認(rèn)證流程-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 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 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 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 newly acquired AK for MAC management messages protection(by CMAC)as per IEEE 802.16e specification.進(jìn)一步參考 7.3.10 和Wimax認(rèn)證流程-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 secret key,and are transferred to the MS.This step is repeated for each SA.進(jìn)一步參考 7.3.10 和附錄1：DH密鑰交換算法原理由WhitfieldDiffie和MartinHellman在1976年公布的一種密鑰一致性算法，算法用2個(gè)人的名字命名，原理說明：離散對(duì)數(shù)問題：若p是素?cái)?shù)，p已知，考慮方程y=gxmodp，給定g,x求y是簡(jiǎn)單的，但給定y,g求x，即求x=logg,pymodp，在計(jì)算上是不可行的。

DH密鑰交換算法的描述如下：已知公開的素?cái)?shù)p和p的本原根1.用戶A選擇秘密的Xap，計(jì)算Ya=Xamodp，將其發(fā)送給B2.用戶B選擇秘密的Xbp，計(jì)算Yb=Xbmodp，將其發(fā)送給A3.A和B分別計(jì)算Ka=(Yb)Xamodp和Kb=(Ya)Xbmodp，就同時(shí)得到了共享的密鑰K=Ka=Kb，然后就可以用K進(jìn)行加密傳輸了DH密鑰交換算法的優(yōu)點(diǎn)在于：雙方在通信前不需要知道任何共享的密鑰，而是通過公開的p和協(xié)商出一個(gè)密鑰來進(jìn)行加密通信先看一下算法的正確性，Ka=Kb是否成立：Ka=(Yb)Xa=(Xb)Xa=Xa*Xb(modp)Kb=(Ya)Xb=(Xa)Xb=Xa*Xb(modp)Bingo!Ka和Kb是相同的再來看一下算法的安全性，就是能否從公開的信息推導(dǎo)出K來：由于密鑰是K=Xa*Xb，那么攻擊者必須知道Xa和Xb才能得到共享的密鑰K，而公開的信息只有Ya和Yb，由離散對(duì)數(shù)問題，從Ya,Yb求出Xa,Xb在計(jì)算上是不可行的，就保證了算法的安全性參考自百度百科附錄2：RSA公鑰加密算法RSA公鑰加密算法是1977年由RonRivest、AdiShamirh和LenAdleman在（美國(guó)麻省理工學(xué)院）開發(fā)的。

RSA取名來自開發(fā)他們?nèi)叩拿諶SA是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被ISO推薦為公鑰數(shù)據(jù)加密標(biāo)準(zhǔn)RSA算法基于一個(gè)十分簡(jiǎn)單的數(shù)論事實(shí)：將兩個(gè)大素?cái)?shù)相乘十分容易，但那時(shí)想要對(duì)其乘積進(jìn)行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰RSA公開密鑰密碼體制所謂的公開密鑰密碼體制就是使用不同的加密密鑰與解密密鑰，是一種“由已知加密密鑰推導(dǎo)出解密密鑰在計(jì)算上是不可行的”密碼體制非對(duì)稱加密密碼算法，用公鑰加密，必須用密鑰解密；反過來，用密鑰加密，必須用公鑰解密應(yīng)用場(chǎng)景：加解密server分發(fā)公鑰給client，自己保留密鑰，client用公鑰加密后的數(shù)據(jù)只能有server解密數(shù)字簽名server將用密鑰加密的簽名和原始簽名發(fā)送給client，client用公鑰解密簽名，和原始簽名一致時(shí)，認(rèn)為數(shù)字簽名有效，可以認(rèn)證該server參考自百度百科附錄3：CBCcipherblockchaining密碼段連接（CBC）是一種操作分段密碼的方式（在一段bit序列加密成一個(gè)單獨(dú)的單元或分成一個(gè)密鑰提供給整個(gè)部分）密碼段連接使用一定長(zhǎng)度初始化向量（IV）他的一個(gè)主要特點(diǎn)是他完全依靠前面的密碼文段來譯碼后面的內(nèi)容。

因此，整個(gè)過程的正確性決定于前面的部分各部分的順序也必須保持正確在面段連接中，每個(gè)文件部分先用前面的部分XOR化（參看XOR），然后加密如果各部分順序沒變，使用相同的密鑰和初始化向量，只有同樣的密碼部分可以起作用因?yàn)閄OR過程隱藏了原文，密碼段連接要優(yōu)于電子密碼書模式理論上，兩條信息使用相同的密鑰加密會(huì)產(chǎn)生不同的初始化向量所以初始化向量不需要保密，這將極大方便某些場(chǎng)合的應(yīng)用參考自百度百科附錄4：SHASecureHashAlgorithmSHA是一種數(shù)據(jù)加密算法，該算法經(jīng)過加密專家多年來的發(fā)展和改進(jìn)已日益完善，現(xiàn)在已成為公認(rèn)的最安全的散列算法之一，并被廣泛使用該算法的思想是接收一段明文，然后以一種不可逆的方式將它轉(zhuǎn)換成一段（通常更?。┟芪?，也可以簡(jiǎn)單的理解為取一串輸入碼（稱為預(yù)映射或信息），并把它們轉(zhuǎn)化為長(zhǎng)度較短、位數(shù)固定的輸出序列即散列值（也稱為信息摘要或信息認(rèn)證代碼）的過程散列函數(shù)值可以說時(shí)對(duì)明文的一種“指紋”或是“摘要”所以對(duì)散列值的數(shù)字簽名就可以視為對(duì)此明文的數(shù)字簽名散列是信息的提煉，通常其長(zhǎng)度要比信息小得多，且為一個(gè)固定長(zhǎng)度加密性強(qiáng)的散列一定是不可逆的，這就意味著通過散列結(jié)果，無法推出任何部分的原始信息。

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

點(diǎn)擊閱讀更多內(nèi)容