[發(fā)明專利]用于蜂窩物聯(lián)網(wǎng)的安全性過程

在審

• 申請?zhí)枺?/td>: 201680048347.0
• 申請日: 2016-08-16
• 公開（公告）號: CN107925869A
• 公開（公告）日: 2018-04-17
• 發(fā)明（設計）人: G.霍爾恩
• 申請（專利權）人: 諾基亞通信公司
• 主分類號: H04W8/20
• 分類號: H04W8/20;H04W12/04;H04W12/06;H04L29/06
• 代理公司: 中國專利代理(香港)有限公司72001
• 代理人: 張健,劉春元

相關申請的交叉引用：

本申請涉及并要求于2015年8月17日提交的美國臨時專利申請?zhí)?2/205,774的權益和優(yōu)先權，其由此通過引用并入本文。

技術領域

各種通信系統(tǒng)可以受益于適當?shù)陌踩源胧＠纾涓C物聯(lián)網(wǎng)可以受益于合適的安全性過程。

背景技術

蜂窩物聯(lián)網(wǎng)（CIoT）是第三代合作伙伴計劃（3GPP）的領域，并且涉及各種3GPP工作組，特別是全球移動通信系統(tǒng)（GSM）用于GSM演進的增強數(shù)據(jù)速率（EDGE）無線電接入網(wǎng)絡（GERAN）、RAN2、SA2和SA3，包括安全性。

3GPP關于用于CIoT的安全性的工作分成兩個流：一個涉及關于通用分組無線業(yè)務（GPRS）安全性進行改進，并且另一個涉及提供設備和歸屬網(wǎng)絡中的CIoT服務器之間的用于CIoT的端到中（end-to-middle：e2m）安全性。歸屬網(wǎng)絡中的CIoT服務器可以被稱為歸屬公用陸地移動網(wǎng)絡（HPLMN）安全性端點（HSE）。

在技術報告（TR）草案（即3GPP TR 33.863 v0.2.0“Study on battery efficient security for very low throughput Machine Type Communication Devices；（版本13）”，其可在http://www.3gpp.org/DynaReport/33863.htm處獲得，其全部內容通過引用并入本文）中捕獲了針對用于CIoT的e2m安全性的討論的目前狀態(tài)。

電池高效安全性可以涉及若干問題。第一個問題涉及GPRS接入網(wǎng)絡中的加密策略。3GPP TR 33.863 v0.2.0包含要求GGSN和SGSN的升級的條款，包括目前的GPRS基礎結構的升級。

特別地，3GPP TR 33.863 v0.2.0描述了“SGSN/MME已經(jīng)向H-PLMN指示了所支持的GERAN/E-UTRAN的安全性配置，即所使用的機密性算法和完整性保護算法（例如，對于GERAN：GEA4在使用中，例如對于LTE，128-EEA2和128-EIA2在使用中）。這樣的指示在SGSN和HLR之間的接口上通常不可用。

此外，當為用戶平面保證e2m安全性時，則用戶平面是否通過UE和SGSN之間的接入另外被加密可能并不重要。另外，可能不需要UE和SGSN之間的強信令保護，因為e2m安全性的終止點HSE可以控制是否建立所期望的e2m安全性關聯(lián)。由HSE的這種控制可以排除在2G中可能的中間人攻擊。

其次，描述3GPP TR 33.863 v0.2.0的指示可能無助于SGSN從歸屬網(wǎng)絡的觀點來學習哪個加密算法必須被應用于該UE。

此外，如果不能信任托管SGSN或MME的拜訪網(wǎng)絡，則不存在歸屬網(wǎng)絡將信任來自SGSN的該指示的明顯原因。此外，對于LTE，該指示可能沒有意義，因為在LTE中安裝好強大的加密算法。

第二個問題涉及拜訪網(wǎng)絡中的認證和密鑰使用策略。3GPP文稿S3-151367（其可以在ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_79_Nanjing/Docs/處找到）規(guī)定了需要HLR/HSS驅動的認證策略，因為H-PLMN比V-PLMN更好地被通知關于將最大化UE的電池容量的最佳認證策略。此外，同一文檔規(guī)定了HLR/HSS應提供用于認證向量的期滿時間，并且具體規(guī)定：“當?shù)竭_期滿時間時，SGSN/MME應使用所存儲的、未使用的和未期滿的AV或向HLR/HSS請求新的AV”。S3-151367由此通過引用并入本文。然而，不存在將這樣的策略傳送給SGSN或MME的常規(guī)方式。

第三個問題涉及e2m安全性的使用。3GPP TR 33.863 v0.2.0描述了用于在UE和HSE之間建立e2m安全性的機制。為此目的，在HLR或HSS的支持下建立加密密鑰。然而，并不是所有的UE都可能需要e2m安全性。例如，只有某些CIoT UE可能需要e2m安全性。

此外，S3-151367提到了要在導出用于e2m安全性的密鑰中使用的認證管理字段（AMF）。AMF是認證中心（AuC）中生成的認證向量中的16位字段。然而，不存在使AuC知道是否必須設置與用于CIoT的e2m安全性相關的AMF中的位的常規(guī)方式。另外，3GPP TR 33.863 v0.2.0和S3-151367均未指示HLR或HSS如何可以知道對于特定訂閱是否需要用于建立e2m安全性的密鑰。