5G核心網(wǎng)安全認證和鑒權(quán)

  ICC訊 5G 引入了eMBB、uRLLC 和mMTC三大業(yè)務(wù)場景，實現(xiàn)的不僅僅是人與人之間的通信，更多地將用于實現(xiàn)人與物、物與物之間的通信。這就決定了5G在認證和鑒權(quán)方面將面臨新的安全需求，主要表現(xiàn)在以下3個方面。

  1.統(tǒng)一的認證框架

  在5G網(wǎng)絡(luò)下，接入網(wǎng)絡(luò)的終端除了手機終端，還包括大量的垂直行業(yè)終端。5G網(wǎng)絡(luò)的接入方式除了3GPP 接入，還包括各種類型的Non-3GPP 接入。不同接入技術(shù)擁有相互獨立的ID和獨立的鑒權(quán)方式，加上網(wǎng)關(guān)邊緣的各種認證和私密會話業(yè)務(wù)，造成每種無線接入中都有獨立的無線資源管理，不同接入技術(shù)之間難以進行互通。為了適應(yīng)上述變化，5G網(wǎng)絡(luò)引入了統(tǒng)一的UE認證框架，實現(xiàn)了對各種終端類型、各種接入方式的統(tǒng)一認證和鑒權(quán)，以及統(tǒng)一的密鑰層次結(jié)構(gòu)。5G網(wǎng)絡(luò)的統(tǒng)一認證框架為5G網(wǎng)絡(luò)安全奠定了堅實的基礎(chǔ)。

  2.基于歸屬網(wǎng)絡(luò)的認證加強

  在傳統(tǒng)認證機制中，拜訪地/歸屬地的兩級移動網(wǎng)絡(luò)架構(gòu)下的認證機制要求歸屬網(wǎng)絡(luò)無條件信任拜訪網(wǎng)絡(luò)的認證結(jié)果。但隨著網(wǎng)絡(luò)的發(fā)展，出現(xiàn)了越來越多的安全隱患，拜訪網(wǎng)絡(luò)和歸屬網(wǎng)絡(luò)之間的信任程度在不斷降低。例如，拜訪地運營商可以聲稱為某運營商的用戶提供接入服務(wù)而實際未提供，導(dǎo)致計費糾紛。對于5G網(wǎng)絡(luò)來說，相較于人與人之間的語音通信和數(shù)據(jù)交互，萬物互聯(lián)下的移動通信將會承載更多的設(shè)備測控類信息，因此對接入安全的要求更高。例如，5G系統(tǒng)會被垂直行業(yè)用于傳遞遠程操控的控制消息，這使5G認證還需要加強歸屬網(wǎng)絡(luò)對用戶終端的認證能力，使其擺脫對拜訪網(wǎng)絡(luò)的依賴，實現(xiàn)用戶在歸屬地/拜訪地等不同地點間的認證機制統(tǒng)一。

  3.基于垂直行業(yè)應(yīng)用的二次認證

  5G網(wǎng)絡(luò)將更多地為垂直行業(yè)提供服務(wù)，而垂直行業(yè)對5G網(wǎng)絡(luò)提出了更多的需求。例如，需要通過5G網(wǎng)絡(luò)切片來為垂直行業(yè)提供定制化的服務(wù)，包括為特定的業(yè)務(wù)提供數(shù)據(jù)通道建立前的認證機制。因此5G網(wǎng)絡(luò)引入了二次認證的概念，即在用戶接入網(wǎng)絡(luò)時進行認證后為接入特定業(yè)務(wù)建立數(shù)據(jù)通道而進行的認證。在該認證過程中，第一次使用了非運營商控制的信任狀要求。例如，當(dāng)5G網(wǎng)絡(luò)用于為高保障業(yè)務(wù)系統(tǒng)提供通信時，用戶通過接入認證后并不能直接與業(yè)務(wù)系統(tǒng)建立連接，而是利用業(yè)務(wù)相關(guān)的信任狀與用戶終端進行認證，并在認證通過的情況下允許5G網(wǎng)絡(luò)為用戶建立與業(yè)務(wù)系統(tǒng)間的通信鏈路，從而提升對業(yè)務(wù)系統(tǒng)的保護。

  (1)概述

  當(dāng)UE能夠連接到5GC和EPC，并且已經(jīng)連接到ng-eNB，可以連接到EPC和5GC時，UE能夠按照TS 24.501的要求，來選擇連接到哪個核心網(wǎng)絡(luò)。如果UE選擇EPC，則UE應(yīng)使用TS 33.401中的安全過程。如果UE選擇5GC，則UE 應(yīng)使用TS 33.501的安全過程。對于可以連接到EPC和5GC的ng-eNB，ng-eNB應(yīng)該基于UE選擇的核心網(wǎng)絡(luò)類型來選擇相應(yīng)的安全過程。

  (2) 初次認證和密鑰協(xié)議

  認證框架

  ① 一般要求

  初次認證和密鑰協(xié)商過程的目的是實現(xiàn)UE和網(wǎng)絡(luò)之間的相互認證，并提供可在UE和服務(wù)網(wǎng)絡(luò)之間的后續(xù)安全過程中使用的密鑰材料。由初次認證和密鑰協(xié)商過程生成的密鑰材料會產(chǎn)生一個被稱為錨密鑰的KSEAF。該錨密鑰由歸屬網(wǎng)絡(luò)的AUSF提供給服務(wù)網(wǎng)絡(luò)的SEAF?？梢詮腒SEAF 派生多個安全上下文的密鑰，而不需要新的身份驗證。例如，在3GPP接入網(wǎng)絡(luò)上運行的認證還可以提供密鑰，以在UE和不可信的non-3GPP 接入中使用的N3IWF之間建立安全連接。

  錨密鑰KSEAF是由中間密鑰KAUSF派生而來，歸屬運營商制訂了關(guān)于使用這種密鑰的策略，將KAUSF安全地存儲在AUSF 中時使用該策略。

  ② EAP 框架

  EAP 框架在RFC 3748中進行了規(guī)定，它定義了以下角色：對端，傳遞身份驗證器和后端認證服務(wù)器。后端認證服務(wù)器充當(dāng)EAP服務(wù)器，用于終止與對端的EAP認證方法。在5G系統(tǒng)中，當(dāng)使用EAP-AKA'時，可以通過以下方式來支持EAP 框架。UE作為對端的角色。

  SEAF作為傳遞身份驗證器的角色。AUSF作為后端認證服務(wù)器的角色。

  ③ 服務(wù)網(wǎng)絡(luò)名稱的構(gòu)建

  a. 服務(wù)網(wǎng)絡(luò)名稱

  服務(wù)網(wǎng)絡(luò)名稱用于導(dǎo)出錨密鑰。它有以下兩個目的。通過包含服務(wù)網(wǎng)絡(luò)標(biāo)識符(SN Id)將錨密鑰綁定到服務(wù)網(wǎng)絡(luò)。通過將服務(wù)代碼設(shè)置為“5G”，確保錨密鑰專用于5G 核心網(wǎng)絡(luò)和UE 之間的認證。

  在5G AKA 中，服務(wù)網(wǎng)絡(luò)名稱具有與將RES * 和XRES * 綁定到服務(wù)網(wǎng)絡(luò)的類似目的。服務(wù)網(wǎng)絡(luò)名稱由服務(wù)代碼和SN Id 組成，中間用分隔符“ ：”連接，服務(wù)代碼在SN Id之前。在服務(wù)網(wǎng)絡(luò)名稱中沒有像“接入網(wǎng)絡(luò)類型”這樣的參數(shù)，因為服務(wù)網(wǎng)絡(luò)名稱與5G核心網(wǎng)流程相關(guān)，而與訪問網(wǎng)絡(luò)類型無關(guān)。

  SN Id標(biāo)識了服務(wù)PLMN，具體定義可以參考TS 24.501。

  b. UE構(gòu)建服務(wù)網(wǎng)絡(luò)名稱

  UE按以下方式構(gòu)建服務(wù)網(wǎng)絡(luò)名稱。將服務(wù)代碼設(shè)置為“5G”。將網(wǎng)絡(luò)標(biāo)識符設(shè)置為其正在進行身份驗證的網(wǎng)絡(luò)的SN Id。將服務(wù)代碼和SN Id 用分隔符“ ：”連接。

  c. SEAF構(gòu)建服務(wù)網(wǎng)絡(luò)名稱

  SEAF按如下方式構(gòu)建服務(wù)網(wǎng)絡(luò)名稱。

  將服務(wù)代碼設(shè)置為“5G”。

  將網(wǎng)絡(luò)標(biāo)識符設(shè)置為AUSF，進而向其發(fā)送認證數(shù)據(jù)的服務(wù)網(wǎng)絡(luò)的SN Id。

  將服務(wù)代碼和SN Id用分隔符“ ：”連接。

  (2)啟動認證和認證方法的選擇

  初次認證過程和認證方法選擇如圖1所示。

  圖1 初次認證過程和認證方法選擇

  根據(jù)SEAF的策略，SEAF可以在與UE建立信令連接的任何過程中發(fā)起與UE 的認證。UE應(yīng)在注冊請求中使用SUCI或5G-GUTI。當(dāng)SEAF要啟動認證時，SEAF將通過向AUSF 發(fā)送Nausf_UEAuthentication_Authenticate 請求消息來調(diào)用Nausf_UEAuthentication服務(wù)。Nausf_UEAuthentication_Authenticate Request 消息應(yīng)包含SUCI 或者SUPI。

  如果SEAF 具有有效的5G-GUTI 并且對UE 進行重新認證，則SEAF應(yīng)在Nausf_UEAuthentication_Authenticate 請求消息中包含SUPI。否則，在Nausf_UEAuthentication_Authenticate 請求消息中應(yīng)包含SUCI。Nausf_UEAuthentication_Authenticate 請求消息還應(yīng)包含服務(wù)網(wǎng)絡(luò)名稱。

  當(dāng)接收到Nausf_UEAuthentication_Authenticate 請求消息時，AUSF 將通過比較服務(wù)網(wǎng)絡(luò)名稱和預(yù)期的服務(wù)網(wǎng)絡(luò)名稱來檢查服務(wù)網(wǎng)絡(luò)中的請求SEAF 是否有權(quán)使用Nausf_UEAuthentication_Authenticate 請求消息中的服務(wù)網(wǎng)絡(luò)名稱。AUSF 應(yīng)臨時存儲接收的服務(wù)網(wǎng)絡(luò)名稱。如果服務(wù)網(wǎng)絡(luò)未被授權(quán)使用服務(wù)網(wǎng)絡(luò)名稱，則AUSF 將在Nausf_UEAuthentication_Authenticate 響應(yīng)消息中返回“服務(wù)網(wǎng)絡(luò)未授權(quán)”。

  從AUSF發(fā)送到UDM 的Nudm_UEAuthentication_Get 請求消息包括以下信息。

  SUCI 或者SUPI。

  服務(wù)網(wǎng)絡(luò)名稱。

  在接收到Nudm_UEAuthentication_Get 請求消息時，如果接收到的是SUCI，則UDM將調(diào)用SIDF。

  在UDM 處理請求之前，SIDF 應(yīng)解除SUCI 以獲得SUPI?；赟UPI，UDM/ARPF 應(yīng)根據(jù)訂閱數(shù)據(jù)選擇認證方法。