從加密碼密鑰失配中快速恢復(fù)的制作方法
【專利說明】從加密碼密鑰失配中快速恢復(fù)
[0001]相關(guān)申請的交叉引用
[0002]本申請要求于2013年12月23日提交的美國臨時專利申請61/920，218的權(quán)益，其公開內(nèi)容通過引用而結(jié)合于此。
技術(shù)領(lǐng)域
[0003]本公開內(nèi)容一般性地涉及無線通信，并且更具體地，涉及用于從加密碼密鑰失配中恢復(fù)的方法和系統(tǒng)。
【背景技術(shù)】
[0004]由第三代合作伙伴計劃(3GPP)規(guī)定的通用移動通信系統(tǒng)(UMTS)標(biāo)準(zhǔn)定義了在UMTS設(shè)備的無線電鏈路控制(RLC)層中執(zhí)行的加密碼(ciphering)機制。RLC層被定義在例如 “Universal Mobile Telecommunicat1ns System (UMTS) ；Rad1 LinkControl (RLC)Protocol Specificat1n (Release 11)，，3GPP TS 25.322, vers1n11.0.0, September, 2012，其通過引用而結(jié)合于此。UMTS中的加密碼被定義在例如 “3G Security ；Security architecture (Release 11)，，3GPP TS33.102, vers1n11.0.0, September, 2011，其通過引用而結(jié)合于此。
[0005]美國專利8，582，768(其公開內(nèi)容通過引用而結(jié)合于此)描述了一種接收機中的方法，該方法包括從發(fā)射機接收通信分組序列。傳送數(shù)據(jù)以加密方案進(jìn)行加密。加密方案取決于計數(shù)器值，該計數(shù)器值由發(fā)射機和接收機中的每一個獨立地遞增。使用不同的、相應(yīng)的計數(shù)器值來嘗試多次解密所接收的分組的數(shù)據(jù)，以產(chǎn)生多個相應(yīng)的解密輸出。在其中數(shù)據(jù)已經(jīng)被正確解密的解密輸出被標(biāo)識，計數(shù)器值被校正，并且所接收的分組的數(shù)據(jù)從所標(biāo)識的解密輸出中被恢復(fù)。
[0006]以上描述僅被給出為本領(lǐng)域的相關(guān)技術(shù)的總體概述，并且不應(yīng)當(dāng)被認(rèn)為是承認(rèn)其包含的任何信息構(gòu)成了相對于本專利申請的現(xiàn)有技術(shù)。

【發(fā)明內(nèi)容】

[0007]本文中所描述的一個實施例提供了一種在接收機中的方法，該方法包括在接收機中標(biāo)識涉及由接收機使用的加密碼密鑰的替換的事件。響應(yīng)于該事件，使用替換的加密碼密鑰來解密由接收機接收的互聯(lián)網(wǎng)協(xié)議(IP)分組的有效載荷的至少一部分。驗證在IP分組的經(jīng)解密的部分中被期望指定IP分組的IP版本的預(yù)定義位置是否確實指定有效IP版本。在檢測到該位置不指定有效IP版本時，發(fā)起恢復(fù)過程，該恢復(fù)過程從加密碼密鑰的不恰當(dāng)替換中進(jìn)行恢復(fù)。
[0008]在一些實施例中，IP的驗證和恢復(fù)過程的發(fā)起在接收機的無線電鏈路控制(RLC)層執(zhí)行。在一個實施例中，解密該部分包括標(biāo)識緊隨著事件之后的并且包含IP分組的起始部分的協(xié)議數(shù)據(jù)單元(rou)、并且對從標(biāo)識的rou中提取的IP分組的起始部分進(jìn)行解密。在一個示例實施例中，標(biāo)識PDU包括驗證F1DU的序列編號是零。
[0009]在一個實施例中，發(fā)起恢復(fù)過程包括即使攜帶IP分組的該部分的協(xié)議數(shù)據(jù)單元(PDU)由接收機所接收、也從接收機發(fā)送針對rou的否定確認(rèn)(NACK)消息。在另一個實施例中，發(fā)起恢復(fù)過程包括使得無線電鏈路控制(RLC)層被重設(shè)。
[0010]在又一個實施例中，IP版本的驗證響應(yīng)于檢測到IP分組的未加密報頭不能實現(xiàn)加密碼密鑰的不恰當(dāng)替換的檢測而被執(zhí)行。在再一個實施例中，解密該部分包括解密IP分組的起始部分。
[0011]根據(jù)本發(fā)明的實施例，另外還提供了一種裝置，該裝置包括前端和處理電路。該前端被配置為接收攜帶互聯(lián)網(wǎng)協(xié)議(IP)分組的信號。該處理電路被配置為標(biāo)識涉及用于對IP分組進(jìn)行加密碼的加密碼密鑰的替換的事件，響應(yīng)于該事件而使用替換的加密碼密鑰來解密接收的互聯(lián)網(wǎng)協(xié)議(IP)分組的有效載荷的至少一部分，驗證在接收的IP分組的經(jīng)解密的部分中被期望指定IP分組的IP版本的預(yù)定義位置是否確實指定有效IP版本，以及在檢測到該位置不指定有效IP版本時發(fā)起恢復(fù)過程，該恢復(fù)過程恢復(fù)加密碼密鑰的不恰當(dāng)替換。
[0012]在一些實施例中，一種移動通信終端包括所公開的裝置。在一些實施例中，一種用于在移動通信終端中處理信號的芯片組包括所公開的裝置。
[0013]本公開內(nèi)容將根據(jù)其實施例的以下詳細(xì)描述結(jié)合附圖而被更加完全地理解，其中:
【附圖說明】
[0014]圖1是根據(jù)本文中所描述的實施例的示意性圖示了采用從加密碼密鑰失配中快速恢復(fù)的移動通信終端的框圖；以及
[0015]圖2是根據(jù)本文中所描述的實施例的示意性圖示了用于從加密碼密鑰失配中快速恢復(fù)的方法的流程圖。
【具體實施方式】
[0016]本文中所描述的實施例提供了用于標(biāo)識和恢復(fù)發(fā)射機與接收機之間的加密碼密鑰失配的改進(jìn)方法和系統(tǒng)。本文中所描述的實施例主要涉及UMTS基站(NodeB)與終端(用戶設(shè)備一一UE)之間的通信，但是所公開的技術(shù)可應(yīng)用至其他適當(dāng)類型的發(fā)射機和接收機并且可應(yīng)用至其他適當(dāng)?shù)耐ㄐ艆f(xié)議。
[0017]在一些實施例中，接收機在如下的層中進(jìn)行操作，這些層至少包括無線電鏈路控制(RLC)層、媒體訪問控制(MAC)層和傳輸控制協(xié)議(TCP)層。接收機從發(fā)射機接收遵循互聯(lián)網(wǎng)協(xié)議的TCP(TCP-over-1nternet_Protocol，TCP/IP)分組，該分組傳送經(jīng)加密的數(shù)據(jù)。MAC層將接收的數(shù)據(jù)格式化在協(xié)議數(shù)據(jù)單元(PDU)中，該協(xié)議數(shù)據(jù)單元的有效載荷包含經(jīng)加密的數(shù)據(jù)。RLC層解密PDU的有效載荷、將來自多個PDU的經(jīng)解密的數(shù)據(jù)聚合到IP分組中、并且將分組轉(zhuǎn)發(fā)至TCP層以供后續(xù)的處理。IP分組也被稱為服務(wù)數(shù)據(jù)單元(SDU)。術(shù)語“IP分組”、“TCP分組”、“分組”和“SDU”在本文中互換地使用。
[0018]在一個實施例中，發(fā)射機和接收機中的RLC層從計數(shù)器值導(dǎo)出它們各自的加密碼密鑰，該計數(shù)器值在鏈路的每一端處單獨地遞增、并且不通過空中傳輸。例如，在UMTS中，該計數(shù)器值被稱為超幀編號(Hyper-Frame Number, HFN)。在發(fā)射機與接收機之間的HFN的任何失配導(dǎo)致必須解密錯誤，該解密錯誤必須要被恢復(fù)。涉及加密碼密鑰的替換的事件、諸如RLC重設(shè)或重建之類的特別易于加密碼密鑰失配。
[0019]在一些實際情況中，難以在RLC層中標(biāo)識加密碼密鑰失配。例如，在一些UMTS配置中，RLC PDU的報頭完全未被加密，而RLCPDU的經(jīng)加密的有效載荷僅包含TCP數(shù)據(jù)。在這樣的情況中，將檢測加密碼密鑰失配的任務(wù)推脫給更高的TCP層在原理上是可能的。然而，TCP層的錯誤檢測和恢復(fù)非常緩慢并且降低了性能和用戶體驗。
[0020]在本文中所描述的一些實施例中，接收機的RLC層通過在解密之后檢查PDU有效載荷中的數(shù)據(jù)來檢測加密碼密鑰失配。如以上注意到的，PDU有效載荷常規(guī)上由RLC層透明地處置并且旨在于僅由TCP層處理。通過特意地檢查目的地在于不同的層的數(shù)據(jù)，RLC層能夠快速且以最小的服務(wù)破壞來檢測和從加密碼密鑰失配中恢復(fù)。
[0021]在示例檢測和恢復(fù)過程中，接收機的RLC層標(biāo)識涉及加密碼密鑰替換的事件，例如RLC重設(shè)或重建。RLC層推斷在該事件之后要被接收的下一個PDU是在新的IP分組中的第一 H)U。RLC層解密該PDU的有效載荷的至少一部分，并且驗證在經(jīng)解密的有效載荷中的被期望指定IP分組的IP版本的預(yù)定義位置是否確實指定有效的IP版本(例如，分別對應(yīng)于IPv4和IPv6的0x4或0x6)。如果不是，RLC層推斷加密碼密鑰失配已經(jīng)發(fā)生并且通過例如發(fā)出針對所討論的I3DU的否定確認(rèn)(NACK)來發(fā)起恢復(fù)過程。
[0022]圖1是根據(jù)本文中所描述的實施例的示意性圖示了移動通信終端20的框圖。在各種實施例中，終端20包括例如移動電話、智能電話、支持無線的計算設(shè)備、或者任何其他適當(dāng)類型的終端。
[0023]在本示例中，終端20根據(jù)UMTS規(guī)范、例如以上記載的TS 25.322和TS 33.102進(jìn)行操作。根據(jù)UMTS術(shù)語，終端20也被稱為用戶設(shè)備(UE)。在備選的實施例中，終端20可以根據(jù)任何其他適當(dāng)?shù)耐ㄐ艠?biāo)準(zhǔn)或協(xié)議來進(jìn)行操作。
[0024]在圖1的實施例中，UE 20包括至少一個天線24、前端28和處理電路32。前端28被配置為從UE與其進(jìn)行通信的基站接收射頻(RF)信號并且將RF信號經(jīng)由天線24傳輸至基站。前端28通常將接收的RF信號下變頻至基帶，并且將要從基帶被傳輸?shù)男盘柹献冾l至RF。處理電路32被配置為執(zhí)行該終端的各種數(shù)字和基帶處理任務(wù)。
[0025]出于清楚起見，以下描述主要涉及處理電路32的下行鏈路接收功能。因此，在本專利申請的上下文中和在權(quán)利要求書中，處理電路32也簡單地被稱為接收機。
[0026]在一個實施例中，電路32中的處理在以下層中被執(zhí)行，這些層包括例如控制其他層(例如物理、MAC和RLC)的無線電資源控制(RRC)層、控制物理無線電資源的物理層(PHY)、媒體訪問控制(MAC)層、執(zhí)行鏈路級控制的無線電鏈路控制(RLC)層、以及執(zhí)行傳輸層功能一一例如傳輸控制協(xié)議(TCP)/IP處理一一的TCP層。據(jù)此，處理電路32包括RRC層單元34、MAC層單元36、RLC層單元40和TCP層單元44，每個單元執(zhí)行與相應(yīng)的層有關(guān)的任務(wù)。
[0027]在本示例中，RLC層單元40包括解密模塊48和互聯(lián)網(wǎng)協(xié)議(IP)版本驗證模塊56，它們的功能在以下進(jìn)一步詳細(xì)地解釋?？刂颇K52管理RLC層單元40的操作。
[0028]在圖1中示出的UE 20和處理電路32的配置是示例配置，僅為了清楚起見，這些配置以高度簡化的方式被描繪。在備選實施例中，也可以使用任何其他適當(dāng)?shù)腢E和處理電路配置。為了清除起見，對于理解所公開的技術(shù)而言并非必要的UE和處理電路元件、諸如與上行鏈路傳輸有關(guān)的元件已經(jīng)從圖中被省略。
[0029]在各種實施例中，UE 20的元件中的一些或所有元件、包括前端28和處理電路32以硬件來實施，諸如使用一個或多個射頻集成電路(RFIC)來實施該前端的元件，或者使用一個或多個現(xiàn)場可編程門陣列(FPGA)或?qū)Ｓ眉呻娐?ASIC)來實施該處理電路。在備選實施例中，UE 20的某些元件以軟件來實施，或者使用硬件和軟件元件的組合來實施。
[0030]在一些實施例中，某些UE元件、諸如處理電路32的某些元件以可編程處理器來實施，其以軟件來編程，用于執(zhí)行本文中所描述的功能。例如，該軟件可以通過網(wǎng)絡(luò)以電子形式被全部或者部分地