專(zhuān)利名稱(chēng)：一種rrc信令解密裝置及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動(dòng)通訊領(lǐng)域，尤其是涉及通信網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析技術(shù)應(yīng)用領(lǐng)域。
背景技術(shù)：
作為3G (Third Generation)的演進(jìn)技術(shù)，LTE不僅可以提供更高的數(shù)據(jù)速率和容量、更大的覆蓋范圍，還可以降低業(yè)務(wù)的延遲以及系統(tǒng)的運(yùn)營(yíng)成本，有利于運(yùn)營(yíng)商推出更多實(shí)時(shí)性、高速率業(yè)務(wù)，從而吸引更多的高端用戶(hù)。而相對(duì)于UMTS系統(tǒng)，LTE系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)和協(xié)議也發(fā)生了很大的變化，其LTE網(wǎng)絡(luò)結(jié)構(gòu)示意圖如下。如圖I所示，LTE系統(tǒng)的無(wú)線(xiàn)接入部分由eNodeB —種節(jié)點(diǎn)組成，核心網(wǎng)部分主要
由MME實(shí)體、S-GW (ServingGateway)實(shí)體、PDNGateway實(shí)體及PCRF實(shí)體等組成，HSS為所有移動(dòng)網(wǎng)絡(luò)的共享實(shí)體。和本發(fā)明的技術(shù)方案相關(guān)的接口和協(xié)議如以下所述Sl-MME接口，eNodeB實(shí)體和MME實(shí)體之間的接口，該接口上傳輸?shù)氖荢lAP協(xié)議。LTE-Uu空中接口，為UE和eNodeB實(shí)體之間的接口，需要解密的RRC協(xié)議消息就在該接口上傳輸。在LTE網(wǎng)絡(luò)系統(tǒng)中，UE和eNodeB實(shí)體之間的RRC協(xié)議的主要功能是實(shí)現(xiàn)傳輸廣播信息，建立和維護(hù)UE和EPC之間的業(yè)務(wù)，業(yè)務(wù)質(zhì)量QoS控制，傳輸指定控制消息等，因此在監(jiān)測(cè)分析LTE網(wǎng)絡(luò)協(xié)議的技術(shù)應(yīng)用中，對(duì)RRC協(xié)議的監(jiān)測(cè)分析是至關(guān)重要的。但是在LTE網(wǎng)絡(luò)中，UE和eNodeB實(shí)體之間經(jīng)過(guò)接入層安全激活啟動(dòng)加密保護(hù)后，RRC消息會(huì)被加密傳輸，如果對(duì)監(jiān)測(cè)到的RRC消息不進(jìn)行解密，LTE協(xié)議監(jiān)測(cè)分析系統(tǒng)是無(wú)法實(shí)現(xiàn)對(duì)RRC消息的正確解碼和分析的?，F(xiàn)有技術(shù)方案是UMTS網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析系統(tǒng)中對(duì)Iub接口上的RRC消息的解密方法。如圖2為UMTS網(wǎng)絡(luò)結(jié)構(gòu)的簡(jiǎn)單示意圖，其中Uu接口和Iub接口上的RRC消息是加密傳輸?shù)?，而在Iu接口上傳輸?shù)南⑹遣患用艿模贗ub接口上進(jìn)行監(jiān)測(cè)分析協(xié)議RRC消息時(shí)可直接從Iu接口上的消息提取出RRC消息加解密密鑰，然后對(duì)其加密的RRC消息進(jìn)行解密。這樣的技術(shù)方案應(yīng)用于LTE網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析時(shí)的缺陷是由于LTE網(wǎng)絡(luò)系統(tǒng)相對(duì)UMTS網(wǎng)絡(luò)系統(tǒng)，其網(wǎng)絡(luò)結(jié)構(gòu)、接口、協(xié)議都發(fā)生了很大的變化，不能簡(jiǎn)單的從一個(gè)接口上提取信息就能實(shí)現(xiàn)消息的解密，主要體現(xiàn)在LTE網(wǎng)絡(luò)中，取消了 RNC實(shí)體，其功能有eNodeB和MME實(shí)現(xiàn)，而RRC消息也只在空口上進(jìn)行傳輸；而且LTE網(wǎng)絡(luò)系統(tǒng)比UMTS網(wǎng)絡(luò)系統(tǒng)在安全機(jī)制上更加完善，因此現(xiàn)有的近似方案是無(wú)法實(shí)現(xiàn)LTE網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析時(shí)對(duì)加密的RRC消息解密。

發(fā)明內(nèi)容
為了解決現(xiàn)有技術(shù)中存在的問(wèn)題，本發(fā)明提出一種方法和裝置，在不改動(dòng)LTE網(wǎng)絡(luò)部署及配置情況下，從相關(guān)的網(wǎng)絡(luò)接口捕獲監(jiān)測(cè)消息，提取相關(guān)信息，在LTE網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析系統(tǒng)中實(shí)現(xiàn)針對(duì)UE非切換時(shí)所捕獲到的RRC消息進(jìn)行解密，使監(jiān)測(cè)系統(tǒng)對(duì)RRC協(xié)議正確解碼和分析。本發(fā)明中所要解決的主要技術(shù)難題是對(duì)RRC消息進(jìn)行解密而需要的KeNB、加密算法標(biāo)識(shí)等相關(guān)安全參數(shù)的獲取、計(jì)算推導(dǎo)維護(hù)加解密密鑰Krrcenc。對(duì)RRC消息進(jìn)行解密所需要的安全參數(shù)要從LTE網(wǎng)絡(luò)多個(gè)接口上不同協(xié)議消息中獲取，并根據(jù)相關(guān)參數(shù)進(jìn)行計(jì)算推導(dǎo)出必要的密鑰。本發(fā)明中所有解決的從屬技術(shù)問(wèn)題有對(duì)Sl-MME接口上特定的SlAP協(xié)議消息中的安全參數(shù)分析提取，LTE-Uu空中接口上特定的RRC消息中的安全參數(shù)分析提取。具體地，本發(fā)明提出了一種RRC信令解密方法，包括以下步驟S101、從Sl-MME接口，及LTE-Uu空中接口上的與UE接入層安全相關(guān)的消息中提取RRC解密參數(shù)及UE標(biāo)識(shí)信息，其中所述RRC解密參數(shù)包括KeNB密鑰參數(shù)和RRC消息解密算法標(biāo)識(shí)cipheringAlgorithm信息； S102、利用步驟SlOl中的所述UE標(biāo)識(shí)信息建立該UE對(duì)應(yīng)的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)；S103利用步驟SlOl中所述的RRC解密參數(shù)對(duì)該UE的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值，并根據(jù)相關(guān)RRC解密參數(shù)推導(dǎo)出RRC解密需要的密鑰信息；S104、利用與需要解密的RRC消息對(duì)應(yīng)的UE標(biāo)識(shí)信息查找到該UE對(duì)應(yīng)的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)，利用所述數(shù)據(jù)結(jié)構(gòu)中密鑰信息及承載該RRC消息的rocp協(xié)議PDU中SN信息、RRC消息的承載信息、RRC消息傳輸方向信息對(duì)加密RRC消息進(jìn)行解密。根據(jù)本發(fā)明的另一方面，其中SlOl具體包括在UE非切換時(shí)，需要從Sl-MME接口上的SlAP協(xié)議消息Initial Context SetupRequest或Ue Context Modify Request中提取KeNB密鑰參數(shù)，從LTE-Uu空中接口上的RRC 消息 SecurityModeCo_and 或 RRCConnectionReconf iguration 上提取加密算法標(biāo)識(shí)cipheringAlgorithm 信息。根據(jù)本發(fā)明的另一方面，其中S103進(jìn)一步包括第一步，查看RRC消息解密參數(shù)推導(dǎo)維護(hù)模塊中是否存在該KeNB參數(shù)對(duì)應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)的實(shí)例，如果存在則執(zhí)行第三步，否則執(zhí)行第二步；第二步，在RRC消息解密參數(shù)推導(dǎo)維護(hù)模塊中建立該KeNB參數(shù)對(duì)應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)的實(shí)例；第三步，用提取的KeNB參數(shù)對(duì)解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值。根據(jù)本發(fā)明的另一方面，其中S103進(jìn)一步包括第一步,從所述RRC消息SecurityModeCommand中提取出RRC消息的加密算法標(biāo)識(shí) cipheringAlgorithm 參數(shù)；第二步，用提取的cipheringAlgorithm參數(shù)對(duì)相應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第三步,利用解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員KeNB、cipheringAlgorithm信息及密鑰推導(dǎo)函數(shù)KDF (KEY DERIVED FUNCTION)計(jì)算出RRC消息的解密密鑰Krrcenc ；根據(jù)本發(fā)明的另一方面，其中S103進(jìn)一步包括第一步，從所述RRC 消息 RRCConnectionReconf iguration 中提取keyChangeIndicator 參數(shù)；
第二步，判斷keyChangelndicator參數(shù)是否等于True ;如果不等于,則結(jié)束過(guò)程；否則判斷消息中是否含有cipheringAlgorithm參數(shù),沒(méi)有則執(zhí)行第五步,有則執(zhí)行第三
I K
少；第三步，從消息RRCConnectionReconf iguration 中提取 cipheringAlgorithm 參數(shù)；第四步,用提取的cipheringAlgorithm參數(shù)對(duì)相應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第五步,利用解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員KeNB、cipheringAlgorithm信息及密鑰推導(dǎo)函數(shù)KDF (KEY DERIVED FUNCTION)計(jì)算出RRC消息的解密密鑰Krrcenc。
·
根據(jù)本發(fā)明的另一方面，其中步驟S102中的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)具體為以下形式Struct RRC_Decryption_Para{unsigned char KeNB[32];unsigned int cipheringAlgorithm;unsigned int SRB1_DL_PDCP_C0UNT;unsigned int SRB1_UL_PDCP_C0UNT;unsigned int SRB2_DL_PDCP_C0UNT;unsigned int SRB2_UL_PDCP_C0UNT;unsigned char Krrcenc[16];};其中，KeNB為密鑰參數(shù)，cipheringAlgorithm為RRC解密算法標(biāo)識(shí)；SRB 1_DL_PDCP_C0UNT :下行方向承載SRBI上的RRC消息計(jì)數(shù)；SRB 1_UL_PDCP_C0UNT 上行方向承載SRBI上的RRC消息計(jì)數(shù)；SRB2_DL_PDCP_C0UNT;下行方向承載SRB2上的RRC消息計(jì)數(shù)；SRB2_UL_PDCP_C0UNT;上行方向承載SRB2上的RRC消息計(jì)數(shù)；Krrcenc :對(duì)加密的RRC消息進(jìn)行解密的密鑰。根據(jù)本發(fā)明的另一方面，其中S104具體為第一步，根據(jù)所述RRC消息，及該RRC消息對(duì)應(yīng)承載信息、傳輸方向、RRC消息技術(shù)信息及解密參數(shù)數(shù)據(jù)結(jié)構(gòu)中的對(duì)應(yīng)的RRC消息計(jì)數(shù)信息重新計(jì)算出該消息RRC消息計(jì)數(shù)值；第二步，判斷該RRC消息是否需要解密，即該RRC消息是否在UE的接入層安全激活后收到的；否則執(zhí)行第四步，是則執(zhí)行第三步；第三步，利用該消息的承載信息、RRC消息計(jì)數(shù)值、消息傳輸方向、數(shù)據(jù)結(jié)構(gòu)成員Krrcenc密鑰、及數(shù)據(jù)結(jié)構(gòu)成員cipheringAlgorithm對(duì)應(yīng)的算法實(shí)現(xiàn)對(duì)RRC消息的解密；第四步，判斷該RRC消息是否是解密參數(shù)提取模塊需要的RRC消息，是則輸入到RRC消息解密參數(shù)提取模塊，否則結(jié)束過(guò)程。此外，本發(fā)明還提出了一種RRC信令解密裝置，包括以下模塊RRC消息解密參數(shù)提取模塊用于從Sl-MME接口上與UE接入層安全相關(guān)的SIAP消息，及LTE-Uu空中接口上與UE接入層安全相關(guān)的RRC消息中提取RRC消息解密參數(shù)信息，其中該RRC消息解密參數(shù)包括RRC消息解密所需要的密鑰以及解密算法標(biāo)識(shí)；RRC消息解密參數(shù)的推導(dǎo)與維護(hù)模塊用于對(duì)輸入的所述RRC消息解密參數(shù)進(jìn)行存儲(chǔ)維護(hù)，并根據(jù)RRC消息解密相關(guān)參數(shù)進(jìn)行推導(dǎo)計(jì)算出RRC解密密鑰信息；RRC消息解密執(zhí)行模塊當(dāng)UE的接入層安全激活啟動(dòng)后，該模塊利用從RRC解密參數(shù)推導(dǎo)與維護(hù)模塊輸出的參數(shù)以及承載RRC消息的下層協(xié)議中的信息實(shí)現(xiàn)對(duì)輸入的加密RRC消息的解密。本發(fā)明提出的RRC信令解密裝置和方法中，需要從Sl-MME、LTE-Uu空中接口上的特定消息提取和UE接入層安全相關(guān)的信息，并利用提取的參數(shù)計(jì)算出RRC消息解密必須的密鑰等相關(guān)參數(shù)，可以不需要改變LTE網(wǎng)絡(luò)的相關(guān)配置、以及對(duì)LTE網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析系統(tǒng)預(yù)先進(jìn)行和UE解密相關(guān)數(shù)據(jù)的配置，就可以實(shí)現(xiàn)協(xié)議監(jiān)測(cè)分析系統(tǒng)對(duì)捕獲的加密RRC消息 進(jìn)行解密操作。


下面結(jié)合附圖及具體實(shí)施例對(duì)本發(fā)明再作進(jìn)一步詳細(xì)的說(shuō)明。圖I是LTE網(wǎng)絡(luò)結(jié)構(gòu)示意圖；圖2是UMTS網(wǎng)絡(luò)結(jié)構(gòu)示意圖；圖3是RRC消息解密裝置方框圖；圖4是本發(fā)明提出的RRC消息解密方法流程圖；圖5是本發(fā)明提出KeNB密鑰參數(shù)的提取過(guò)程流程圖；圖6 是本發(fā)明提出的 SecurityModeCommand 中的 cipheringAlgorithm 參數(shù)提取過(guò)程流程圖；圖 7 是本發(fā)明提出的 RRCConnectionReconf iguration 中的 cipheringAlgorithm等參數(shù)提取過(guò)程流程圖；圖8是本發(fā)明提出的RRC信令解密方法的解密執(zhí)行過(guò)程流程圖。
具體實(shí)施例方式為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點(diǎn)更加清楚明白，以下結(jié)合附圖及實(shí)施例，對(duì)本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說(shuō)明。應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。在LTE協(xié)議監(jiān)測(cè)分析時(shí)，本技術(shù)方案可實(shí)現(xiàn)在UE非切換時(shí)對(duì)抓取的移動(dòng)終端UE和eNodeB實(shí)體之間交互的RRC信令的解密功能，其解密的RRC信令包括上行和下行方向的所有加密RRC信令。如圖3所示，方框中的部分為本發(fā)明裝置的組成結(jié)構(gòu)圖，描述如下；方塊以外部分是LTE網(wǎng)絡(luò)結(jié)構(gòu)示意圖，圖中箭頭描述的是本發(fā)明裝置及組成模塊的輸入與輸出。本發(fā)明裝置有三部分組成RRC消息解密參數(shù)提取模塊、RRC消息解密參數(shù)的推導(dǎo)與維護(hù)模塊以及對(duì)加密的RRC消息解密執(zhí)行模塊。其中各模塊功能如下RRC消息解密參數(shù)提取模塊用于從Sl-MME接口上與UE接入層安全相關(guān)的SIAP消息，及LTE-Uu空中接口上與UE接入層安全相關(guān)的RRC消息中提取RRC消息解密參數(shù)信息，其中該RRC消息解密參數(shù)包括RRC消息解密所需要的密鑰以及解密算法標(biāo)識(shí)；RRC消息解密參數(shù)的推導(dǎo)與維護(hù)模塊用于對(duì)輸入的所述RRC消息解密參數(shù)進(jìn)行存儲(chǔ)維護(hù)，并根據(jù)RRC消息解密相關(guān)參數(shù)進(jìn)行推導(dǎo)計(jì)算出RRC解密密鑰信息；RRC消息解密執(zhí)行模塊當(dāng)UE的接入層安全激活啟動(dòng)后，該模塊利用從RRC解密參數(shù)推導(dǎo)與維護(hù)模塊輸出的參數(shù)以及承載RRC消息的下層協(xié)議中的信息實(shí)現(xiàn)對(duì)輸入的加密RRC消息的解密。此外，本發(fā)明提出的一種LTE協(xié)議監(jiān)測(cè)分析中針對(duì)UE非切換時(shí)的RRC信令解密方法主要包括以下步驟S101、W Sl-MME接口，及LTE-Uu空中接口上的與UE接入層安全相關(guān)的消息中提取RRC解密參數(shù)及UE標(biāo)識(shí)信息；其中所述RRC解密參數(shù)包括KeNB密鑰參數(shù)和RRC消息解密算法標(biāo)識(shí)cipheringAlgorithm信息； S102、利用步驟SlOl中的所述UE標(biāo)識(shí)信息在RRC解密參數(shù)推導(dǎo)維護(hù)模塊中查找或建立該UE的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)，S103利用步驟SlOl中所述的RRC解密參數(shù)對(duì)該UE的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值，并根據(jù)相關(guān)RRC解密參數(shù)推導(dǎo)出RRC解密需要的密鑰信息； S104、利用與需要解密的RRC消息對(duì)應(yīng)的UE標(biāo)識(shí)信息在RRC解密參數(shù)推導(dǎo)維護(hù)模塊中查找到該UE對(duì)應(yīng)的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)，利用所述數(shù)據(jù)結(jié)構(gòu)中密鑰信息及承載該RRC消息的rocp協(xié)議rou中SN信息、rrc消息的承載信息、rrc消息傳輸方向信息對(duì)加密RRC消息進(jìn)行解密。步驟S102中，下面將針對(duì)RRC消息解密參數(shù)存儲(chǔ)方式進(jìn)行詳細(xì)描述。在LTE系統(tǒng)內(nèi)對(duì)RRC協(xié)議消息進(jìn)行解密的參數(shù)不是固定的，而是隨著RRC信令的交互動(dòng)態(tài)變化的，因此需要相應(yīng)的數(shù)據(jù)結(jié)構(gòu)實(shí)時(shí)記錄存儲(chǔ)RRC協(xié)議解密需要的參數(shù)。對(duì)RRC協(xié)議解密需要的參數(shù)進(jìn)行存儲(chǔ)的相應(yīng)數(shù)據(jù)結(jié)構(gòu)如下用C++描述如下Struct RRC_Decryption_Para{unsigned char KeNB[32];unsigned int cipheringAlgorithm;unsigned int SRB1_DL_PDCP_C0UNT;unsigned int SRB1_UL_PDCP_C0UNT;unsigned int SRB2_DL_PDCP_C0UNT;unsigned int SRB2_UL_PDCP_C0UNT;unsigned char Krrcenc[16];};KeNB :密鑰參數(shù)，需要基于此參數(shù)推導(dǎo)計(jì)算出RRC解密需要的密鑰Krrcenc ；cipheringAlgorithm RRC 加解密算法標(biāo)識(shí)；SRB 1_DL_PDCP_C0UNT :下行方向承載SRBI上的RRC消息計(jì)數(shù)；SRB 1_UL_PDCP_C0UNT 上行方向承載SRBI上的RRC消息計(jì)數(shù)；SRB2_DL_PDCP_C0UNT;下行方向承載SRB2上的RRC消息計(jì)數(shù)；
SRB2_UL_PDCP_C0UNT;上行方向承載SRB2上的RRC消息計(jì)數(shù)；Krrcenc :對(duì)加密的RRC消息進(jìn)行解密的密鑰；在使用時(shí)，每個(gè)UE都有一個(gè)該數(shù)據(jù)結(jié)構(gòu)實(shí)例，記錄UE接入層安全信息；參見(jiàn)圖5，將對(duì)RRC信令解密方法的參數(shù)提取及推導(dǎo)維護(hù)過(guò)程進(jìn)行詳細(xì)描述。在UE非切換時(shí)，需要從Sl-MME接口上的SlAP協(xié)議消息Initial Context SetupRequest或Ue Context Modify Request中提取KeNB密鑰等安全參數(shù),從LTE-Uu空中接口上的 RRC 消息 SecurityModeCommand 或 RRCConnectionReconf iguration 上提取加密算法標(biāo)識(shí)cipheringAlgorithm等信息。對(duì)各個(gè)消息的處理過(guò)程描述如下I.對(duì)KeNB密鑰參數(shù)的提取過(guò)程
如圖5所示具體描述如下第一步，從輸入SlAP 協(xié)議消息 Initial Context Setup Request 或 UeContextModify Request中提取出密鑰KeNB參數(shù)；第二步，查看RRC消息解密參數(shù)推導(dǎo)維護(hù)模塊中是否存在該KeNB參數(shù)對(duì)應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)的實(shí)例；如果存在則執(zhí)行第四步，否則執(zhí)行第三步；第三步，在RRC消息解密參數(shù)推導(dǎo)維護(hù)模塊中建立該KeNB參數(shù)對(duì)應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)的實(shí)例；第四步，用提取的KeNB參數(shù)對(duì)解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第五步，結(jié)束過(guò)程。參見(jiàn)圖6,下面將對(duì) RRC 消息 SecurityModeCommand 中的 cipheringAlgorithm 參數(shù)提取過(guò)程進(jìn)行詳細(xì)描述。具體描述如下第一步,從輸入的RRC消息SecurityModeCommand中提取出RRC消息的加密算法標(biāo)識(shí) cipheringAlgorithm 參數(shù)；第二步，用提取的cipheringAlgorithm參數(shù)對(duì)相應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第三步,利用解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員KeNB、cipheringAlgorithm信息及密鑰推導(dǎo)函數(shù)KDF (KEY DERIVED FUNCTION)計(jì)算出RRC消息的解密密鑰Krrcenc ；第四步，結(jié)束過(guò)程；參見(jiàn)圖7,下面對(duì) RRC 消息 RRCConnectionReconf iguration 中的cipheringAlgorithm等參數(shù)提取過(guò)程進(jìn)行詳細(xì)描述。該過(guò)程具體描述如下第一步，從輸入的RRC 消息 RRCConnectionReconf iguration 中提取keyChangelndicator 參數(shù)；第二步,判斷keyChangelndicator參數(shù)是否等于True ;如果不等于,則結(jié)束過(guò)程；否則判斷消息中是否含有cipheringAlgorithm參數(shù),沒(méi)有則執(zhí)行第五步,有則執(zhí)行第三
I K
少；第三步，從消息RRCConnectionReconf iguration 中提取 cipheringAlgorithm 參數(shù)；第四步，用提取的cipheringAlgorithm參數(shù)對(duì)相應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第五步,利用解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員KeNB、cipheringAlgorithm信息及密鑰推導(dǎo)函數(shù)KDF (KEY DERIVED FUNCTION)計(jì)算出RRC消息的解密密鑰Krrcenc ；第六步,結(jié)束過(guò)程；參見(jiàn)圖8，下面將對(duì)RRC信令解密方法的解密執(zhí)行過(guò)程進(jìn)行詳細(xì)描述。該過(guò)程主要是利用輸入的RRC消息的承載、消息計(jì)數(shù)、傳輸方向信息以及RRC解密參數(shù)數(shù)據(jù)結(jié)構(gòu)中的成員對(duì)加密的RRC消息實(shí)現(xiàn)解密。過(guò)程如下所示過(guò)程具體描述如下第一步，輸入RRC消息，及該消息對(duì)應(yīng)承載信息、傳輸方向、消息計(jì)數(shù)信息，并根據(jù) 承載信息、消息計(jì)數(shù)信息、傳輸方向及解密參數(shù)數(shù)據(jù)結(jié)構(gòu)中的rocp count信息重新計(jì)算出該消息rocp count值；第二步，判斷該RRC消息是否需要解密，即該RRC消息是否在UE的接入層安全激活后收到的；否則執(zhí)行第四步，是則執(zhí)行第三步；第三步，利用該消息的承載信息、PDCP COUNT值、消息傳輸方向、數(shù)據(jù)結(jié)構(gòu)成員Krrcenc密鑰、及數(shù)據(jù)結(jié)構(gòu)成員cipheringAlgorithm對(duì)應(yīng)的算法實(shí)現(xiàn)對(duì)RRC消息的解密；第四步，判斷該RRC消息是否是解密參數(shù)提取模塊需要的RRC消息，是則輸入到RRC消息解密參數(shù)提取模塊，否則結(jié)束過(guò)程；本發(fā)明采用在本發(fā)明的技術(shù)方案中，需要從Sl-MME、LTE-Uu空中接口上的特定消息提取和UE接入層安全相關(guān)的信息，并利用提取的參數(shù)計(jì)算出RRC消息解密必須的密鑰等相關(guān)參數(shù)，可以不需要改變LTE網(wǎng)絡(luò)的相關(guān)配置、以及對(duì)LTE網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析系統(tǒng)預(yù)先進(jìn)行和UE解密相關(guān)數(shù)據(jù)的配置，就可以實(shí)現(xiàn)協(xié)議監(jiān)測(cè)分析系統(tǒng)對(duì)捕獲的加密RRC消息進(jìn)行解密操作。此外，在本發(fā)明還設(shè)計(jì)了 RRC解密參數(shù)的數(shù)據(jù)結(jié)構(gòu)，可正確記錄RRC解密需要的各種參數(shù)。綜上所述，雖然本發(fā)明已以?xún)?yōu)選實(shí)施例披露如上，然而其并非用以限定本發(fā)明。本發(fā)明所屬技術(shù)領(lǐng)域的普通技術(shù)人員，在不脫離本發(fā)明的精神和范圍內(nèi)，可作各種變動(dòng)與修飾。因此，本發(fā)明的保護(hù)范圍當(dāng)視所附的權(quán)利要求所界定的范圍為準(zhǔn)。
權(quán)利要求
1.一種LTE協(xié)議監(jiān)測(cè)分析中針對(duì)UE非切換時(shí)的RRC信令解密方法，包括以下步驟 5101、從Sl-MME接口，及LTE-Uu空中接口上的與UE接入層安全相關(guān)的消息中提取RRC解密參數(shù)及UE標(biāo)識(shí)信息，其中所述RRC解密參數(shù)包括KeNB密鑰參數(shù)和RRC消息解密算法標(biāo)識(shí) cipheringAlgorithm 信息； 5102、利用步驟SlOl中的所述UE標(biāo)識(shí)信息建立該UE對(duì)應(yīng)的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)； S103利用步驟SlOl中所述的RRC解密參數(shù)對(duì)該UE的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值，并根據(jù)相關(guān)RRC解密參數(shù)推導(dǎo)出RRC解密需要的密鑰信息； S104、利用與需要解密的RRC消息對(duì)應(yīng)的UE標(biāo)識(shí)信息查找到該UE對(duì)應(yīng)的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)，利用所述數(shù)據(jù)結(jié)構(gòu)中密鑰信息及承載該RRC消息的HXP協(xié)議PDU中SN信息、RRC消息的承載信息、RRC消息傳輸方向信息對(duì)加密RRC消息進(jìn)行解密。
2.如權(quán)利要求I所述的方法，其中SlOl具體包括 在UE非切換時(shí)，需要從Sl-MME接口上的SlAP協(xié)議消息Initial Context SetupRequest或Ue Context Modify Request中提取KeNB密鑰參數(shù)，從LTE-Uu空中接口上的RRC 消息 SecurityModeCommand 或 RRCConnectionReconf iguration 上提取加密算法標(biāo)識(shí)cipheringAlgorithm 信息。
3.如權(quán)利要求2所述的方法，其中S103進(jìn)一步包括 第一步，查看RRC消息解密參數(shù)推導(dǎo)維護(hù)模塊中是否存在該KeNB參數(shù)對(duì)應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)的實(shí)例，如果存在則執(zhí)行第三步，否則執(zhí)行第二步； 第二步，在RRC消息解密參數(shù)推導(dǎo)維護(hù)模塊中建立該KeNB參數(shù)對(duì)應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)的實(shí)例； 第三步，用提取的KeNB參數(shù)對(duì)解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值。
4.如權(quán)利要求2所述的方法，其中S103進(jìn)一步包括 第一步，從所述RRC消息SecurityModeCo_and中提取出RRC消息的加密算法標(biāo)識(shí)cipheringAlgorithm 參數(shù)； 第二步，用提取的cipheringAlgorithm參數(shù)對(duì)相應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第三步，利用解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員KeNB、cipheringAlgorithm信息及密鑰推導(dǎo)函數(shù)KDF (KEY DERIVED FUNCTION)計(jì)算出 RRC 消息的解密密鑰 Krrcenc。
5.如權(quán)利要求2所述的方法，其中S103進(jìn)一步包括 第一步，從所述 RRC 消息 RRCConnectionReconf iguration 中提取 keyChange Indicator參數(shù)；第二步，判斷keyChangelndicator參數(shù)是否等于True ;如果不等于,則結(jié)束過(guò)程；否則判斷消息中是否含有cipheringAlgorithm參數(shù),沒(méi)有則執(zhí)行第五步,有則執(zhí)行第三步；第三步,從消息 RRCConnectionReconf iguration 中提取 cipheringAlgorithm 參數(shù)；第四步，用提取的cipheringAlgorithm參數(shù)對(duì)相應(yīng)的解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值；第五步，利用解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員KeNB、cipheringAlgorithm信息及密鑰推導(dǎo)函數(shù)KDF (KEY DERIVED FUNCTION)計(jì)算出 RRC 消息的解密密鑰 Krrcenc。
6.如權(quán)利要求I所述的方法，其中步驟S102中的RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)具體為以下形式Struct RRC_Decryption_Para{unsigned char KeNB[32];unsigned int cipheringAlgorithm;unsigned int SRB1_DL_PDCP_C0UNT;unsigned int SRB1_UL_PDC P_C0UNT; unsigned int SRB2_DL_PDCP_C0UNT;unsigned int SRB2_UL_PDCP_C0UNT;unsigned char Krrcenc[16]; }； 其中，KeNB為密鑰參數(shù)，cipheringAlgorithm為RRC解密算法標(biāo)識(shí)； SRB1_DL_PDCP_C0UNT :下行方向承載SRBl上的RRC消息計(jì)數(shù)； SRB1_UL_PDCP_C0UNT :上行方向承載SRBl上的RRC消息計(jì)數(shù)； SRB2_DL_PDCP_C0UNT;下行方向承載SRB2上的RRC消息計(jì)數(shù)； SRB2_UL_PDCP_C0UNT;上行方向承載SRB2上的RRC消息計(jì)數(shù)； Krrcenc :對(duì)加密的RRC消息進(jìn)行解密的密鑰。
7.如權(quán)利要求1-6任一所述的方法，其中S104具體為 第一步，根據(jù)所述RRC消息，及該RRC消息對(duì)應(yīng)承載信息、傳輸方向、RRC消息技術(shù)信息及解密參數(shù)數(shù)據(jù)結(jié)構(gòu)中的對(duì)應(yīng)的RRC消息計(jì)數(shù)信息重新計(jì)算出該消息RRC消息計(jì)數(shù)值；第二步，判斷該RRC消息是否需要解密，即該RRC消息是否在UE的接入層安全激活后收到的；否則執(zhí)行第四步，是則執(zhí)行第三步； 第三步，利用該消息的承載信息、RRC消息計(jì)數(shù)值、消息傳輸方向、數(shù)據(jù)結(jié)構(gòu)成員Krrcenc密鑰、及數(shù)據(jù)結(jié)構(gòu)成員cipheringAlgorithm對(duì)應(yīng)的算法實(shí)現(xiàn)對(duì)RRC消息的解密；第四步，判斷該RRC消息是否是解密參數(shù)提取模塊需要的RRC消息，是則輸入到RRC消息解密參數(shù)提取模塊，否則結(jié)束過(guò)程。
8.—種LTE協(xié)議監(jiān)測(cè)分析中針對(duì)UE非切換時(shí)的RRC信令解密裝置，包括以下模塊 RRC消息解密參數(shù)提取模塊用于從Sl-MME接口上與UE接入層安全相關(guān)的SIAP消息，及LTE-Uu空中接口上與UE接入層安全相關(guān)的RRC消息中提取RRC消息解密參數(shù)信息，其中該RRC消息解密參數(shù)包括RRC消息解密所需要的密鑰以及解密算法標(biāo)識(shí)； RRC消息解密參數(shù)的推導(dǎo)與維護(hù)模塊用于對(duì)輸入的所述RRC消息解密參數(shù)進(jìn)行存儲(chǔ)維護(hù)，并根據(jù)RRC消息解密相關(guān)參數(shù)進(jìn)行推導(dǎo)計(jì)算出RRC解密密鑰信息； RRC消息解密執(zhí)行模塊當(dāng)UE的接入層安全激活啟動(dòng)后，該模塊利用從RRC解密參數(shù)推導(dǎo)與維護(hù)模塊輸出的參數(shù)以及承載RRC消息的下層協(xié)議中的信息實(shí)現(xiàn)對(duì)輸入的加密RRC消息的解密。
全文摘要
公開(kāi)一種RRC信令解密方法和裝置，該方法包括以下步驟從與UE接入層安全相關(guān)的消息中提取RRC解密參數(shù)及UE標(biāo)識(shí)信息；利用UE標(biāo)識(shí)信息建立RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)；對(duì)RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)成員賦值，并推導(dǎo)出RRC解密需要的密鑰信息；利用UE標(biāo)識(shí)信息查找到RRC消息解密參數(shù)數(shù)據(jù)結(jié)構(gòu)，利用數(shù)據(jù)結(jié)構(gòu)中密鑰信息及承載該RRC消息的PDCP協(xié)議PDU中SN信息、RRC消息的承載信息、RRC消息傳輸方向信息對(duì)加密RRC消息進(jìn)行解密。根據(jù)本發(fā)明，不需要改變LTE網(wǎng)絡(luò)的相關(guān)配置、以及對(duì)LTE網(wǎng)絡(luò)協(xié)議監(jiān)測(cè)分析系統(tǒng)預(yù)先進(jìn)行和UE解密相關(guān)數(shù)據(jù)的配置，就可以實(shí)現(xiàn)協(xié)議監(jiān)測(cè)分析系統(tǒng)對(duì)捕獲的加密RRC消息進(jìn)行解密操作。
文檔編號(hào)H04W76/00GK102892112SQ201210333330
公開(kāi)日2013年1月23日 申請(qǐng)日期2012年9月10日 優(yōu)先權(quán)日2012年9月10日
發(fā)明者劉元?jiǎng)P, 賈宇航, 張立, 王升平, 李春林 申請(qǐng)人:北京中創(chuàng)信測(cè)科技股份有限公司