5G消息安全認證體系研究

李雨汝，宋玉磊，蔣 璇（.國家無線電監測中心檢測中心，北京 0004；.中訊郵電咨詢設計院有限公司鄭州分公司，河南鄭州 450007；.中訊郵電咨詢設計院有限公司，北京 00048）

0 引言

5G 消息是RCS 業務在5G 時代的落地應用。終端的普及、創新應用的豐富、用戶體驗的提升將會驅動5G消息滲透至千行百業。終端原生、以手機號碼作為用戶體系唯一標識的特點讓即時通信回歸到了可信聯系的本質；A2P通知由于其消息即服務的特點，前向賦能企業和其用戶之間連接服務的智能化再升級，后向構建了認證、支付、大數據、ASR、NLP、搜索、卡片合成、視頻客服、應用制作等能力及內容服務生態。

5G 消息相比OTT 廠商公眾號能提供更安全、更便捷、更高效、更高觸達率的交互式應用，安全是5G消息的基礎能力底座，也是政府政務、金融保險等對安全等級要求比較高的行業應用的關鍵業務訴求。認證是5G 消息安全體系中的重要環節，包括用戶認證和Chatbot應用認證兩大環節。

1 用戶認證安全分析

1.1 5G消息體系結構

5G 消息屬于RCS 業務，基于IMS 網絡來承載，通過4G/5G 及Wi-Fi 網絡來接入，RCS AS 處理消息業務邏輯，MaaP 平臺實現消息即平臺功能，對接行業應用（見圖1）。

圖1 5G消息體系結構圖

1.2 注冊認證安全分析

5G 消息業務屬于IMS 業務范疇，業務注冊時采用SIP 協議進行交互，使用AKA 方式進行認證。IMSAKA鑒權的主要流程如下。

a）P-CSCF 的地址通過P-CSCF 發現過程獲得。需要注冊的歸屬域名從ISIM 中獲得，攜帶IMPI 和IMPU進行注冊嘗試。

b）此時，P-CSCF 收到的消息沒有一致性安全保護。P-CSCF 根據Request-URI 將注冊消息路由到用戶歸屬域的接口I-CSCF。I-CSCF 從用戶歸屬的HSS中獲取能夠為用戶服務的S-CSCF 信息，并將注冊消息轉發給該S-CSCF。

c）由于用戶當前沒有在S-CSCF 中注冊，所以需要向HSS 設置Registration Flag（pending），指示正在注冊。S-CSCF 以用戶的IMPI 為關鍵字，向HSS 索取鑒權向量5元組，包括RAND、AUTH、XRES、CK和IK。

d）S-CSCF 保存全部鑒權向量5 元組。將RAND、AUTH、XRES、CK 和IK 在SIP 4XX 應答中發給ICSCF，由其轉發給P-CSCF。

e）P-CSCF 收到該SIP 4XX 應答之后，保存CK 和IK，將其余部分轉發給UE。CK和IK的擴展將用做IPsec ESP 傳輸模式下安全聯盟需要的保密密鑰和一致性密鑰。

f）UE 獲得AUTH 后，提取MAC 和SQN，并自行利用共享密鑰IK計算XMAC，判斷XMAC是否和MAC一致，SQN是否在合理數值范圍，以辨別IMS網絡是否合法。UE 利用共享密鑰和RAND 計算鑒權響應RES，并重新發起注冊過程。

新的注冊過程使用的IP 地址不變，但端口號須與SA 中協商的一致。選擇的P-CSCF 和S-CSCF 必須與初始注冊過程一樣。

g）S-CSCF 比較從UE 獲得的RES 和曾從HSS 獲得的XRES，如果一致，則UE 認證鑒權通過，可以享受服 務。S-CSCF 向HSS 設 置Registration Flag（registered），并從HSS 中獲取用戶屬性和業務信息。最后向UE發送SIP 2XX注冊完成響應。

5G 消息采用五元組進行認證，使用手機號碼構建IMPU 以及IMPI 進行注冊，相比于APP、小程序等OTT應用采用用戶名、密碼、短信驗證碼的方式進行驗證無論從流程還是對外信息暴露方面均具有較高的安全性。

1.3 HTTP業務認證安全分析

在5G 消息中，使用HTTP 協議進行交互的網元有DM 服務器、AS 中的HTTP 內容服務器、MaaP 平臺的Chatbot 目錄服務器、Chatbot 信息服務器以及HTTP 內容服務器。

1.3.1 DM交互

5G 消息業務中，終端根據用戶SIM 卡歸屬的運營商構建出DM 設備標準域名（如http：//config.rcs.mnc.mcc.pub.3gppnetwork.org），并向該域名發起HTTP（HTTPS）請求，該請求不涉及到用戶操作，采用Token或者Session的方式進行認證。

1.3.2 GBA認證

當用戶通過HTTP 方式上傳下載多媒體信息以及通過HTTP 方式去獲取Chatbot 列表以及Chatbot 詳細信息時，采用GBA 方式對用戶進行認證。GBA 認證的詳細流程如圖2所示。

圖2 GBA認證流程圖

GBA 認證有效利用AKA 鑒權的特性對非SIP 請求進行認證，對于GBA 鑒權中涉及到的主要關鍵點分析如下。

a）NAF地址：NAF地址通過DM配置文件獲取，格式為域名或者IP 地址形式，由于IP 地址易變更，基本采用域名方式。

b）HTTP 或者HTTPS：UE 請求使用HTTP 還是HTTPS 方式不但決定了傳輸層協議是否安全，而且決定了NAF_ID 的取值方式，根據3GPP 定義，NAF_ID=FQDN of the NAF||Ua security protocol identifier。若為HTTP 方 式，Ua security protocol identifier 為（0x01，0x00，0x00，0x00，0x00）；若為HTTPS 方式，則Ua security protocol identifier 為（0x01，0x00，0x01，yy，zz），其中”yy，zz”為HTTPS中CipherSuite Code值。在GBA鑒權具體實施的過程中采用HTTPS 方式保障了傳輸層面的安全性。

c）BSF 網元：BSF 網元的域名需要終端根據SIM卡信息導出，其標準格式為：bsf.mnc.mcc.pub.3gppnetwork.org。目前VoLTE網絡中終端也根據上述域名去查找Ut 服務器，因此建議BSF 網元和Ut服務器合設。

d）BIA消息的驗證方式：

（a）檢驗BSF 返回的USS 信息中的認證方式（GBA-ME、GBA-U 等）是否與UE 攜帶的認證方式（基于請求消息中的realm）一致，如果一致，則進行后續操作；如果不一致，則給UE返回401認證失敗消息。

（b）NAF 根據用戶的USS 信息，驗證UE 傳送過來的身份信息IMPU，如果一致，則進行后續操作；如果不一致，則給UE返回401認證失敗消息。

（c）利用B-TID（用戶名）和Ks_NAF（口令）進行HTTP Digest 計算response，并與請求消息頭域Authorization 中的response 值比對，如果一致，則通過認證，繼續后續操作；如果不一致，則給UE 返回401 認證失敗消息。

對于OTT 應用，其在通過HTTP 訪問應用時，無法對用戶的身份進行認證。在5G 消息里，當用戶通過HTTP 訪問應用服務器時，采用GBA 方式則保障了應用訪問的安全合規性。

1.4 系統認證角色分析

終端：5G 消息是一款要求原生終端支持的應用，終端是認證系統的發起點，對于SIP 應用，要求支持AKA 鑒權方式；對于HTTP 應用，則要求支持GBA 認證，并要求該功能和應用服務器側保持一致，終端開啟了GBA認證，若應用側不支持，對于HTTP Get請求，終端側可以忽略GBA 鑒認證要求，但是對于Post 請求，若應用側不支持GBA 鑒權方式，則會導致業務交互失敗。

HTTP 服務器：HTTP 服務器是應用的鑒權點，需要支持并開啟GBA 認證方式，并和BSF 進行BIR 以及BIA 消息交互，根據交互結果和終端側信息進行比較達到認證鑒權目的。

BSF 網元：BSF 網元是GBA 認證流程中重要的一環，它通過Ub 接口和終端進行交互，通過Zn 接口和NAF（HTTP 應用服務器）交互，通過Dz 以及Zh 接口和HSS 進行交互，并可以作為GBA 鑒權的網絡能力開放網元，在物聯網等領域將認證能力對外開放（見圖3）。

圖3 BSF網元接口系統圖

IMS 核心網：對于SIP 認證，IMS 核心網P-CSCF、S-CSCF、HSS 需要參與并支持AKA 認證方式，對于HTTP 認證，HSS 需要通過Zh 接口和BSF 交互返回鑒權認證向量。

2 Chatbot認證安全分析

2.1 MaaP平臺

消息即平臺（MaaP——Message as a Platform），是5G消息網絡中將消息能力開放給企業的核心網元，企業側應用（Chatbot）通過MaaP 平臺以SIP或者HTTP 方式進行交互，南向對接RCS AS 及終端，主要功能包括Chatbot 接入、Chatbot 目錄、Chatbot 信息、HTTP 內容存儲，消息收發、消息審核、能力探測等。

2.2 Chatbot認證

2.2.1 Chatbot簽名

認證機構通過JWS（JSON Web Signature）的方式對Chatbot進行簽名，JWS主要包括如下信息。

a）Payload：包括Chatbot Service ID、Chatbot Name以及Iconfingerpirnt信息，并以Base64編碼呈現。

b）Protected：至少包括加密算法Alg 以及Crit Header，其中Crit 包含botvfexpires 值表明簽名的到期日期，以Base64編碼呈現。

c）Header（Unprotected）：包括Kid 屬性，用來指示加密算法的公鑰值，以Base64編碼呈現。

d）Signature：對Payload、Portected、Header 等3 個部分內容使用私鑰進行加密，并以Base64 編碼進行呈現。

認證機構簽名后將簽名信息以及Chatbot 信息發送至MaaP平臺。

2.2.2 Chatbot簽名核查流程

MaaP平臺對簽名核查流程如下。

a）如果Chatbot 詳情信息不包含verification-signatures簽名信息，則Chatbot將被視為未認證。

b）如果驗證簽名屬性與JSON 序列化中的JWS 不對應，則Chabot將被視為未驗證。

c）解碼Base64 后，驗證簽名的有效荷載不包含Chatbot ID 以及Chabot 名稱，則Chatbot 將被視為未驗證。

d）如果JWS 中Protected 的Alg 算法不屬于［RFC7518］的推薦算法，則Chatbot將被視為未驗證。

e）如果JWS 中Protected 的Crit 對象不包括botvfexpires屬性，則Chatbot將被視為未驗證。

f）如果Header 中未包括公鑰Kid 值，則Chatbot 將被視為未驗證。

g）如果Payload 中的Iconfingerpirnt 信息與Chatbot 詳情信息中的圖標指紋信息不匹配，則Chatbot 將被視為未驗證。

h）若以上步驟順利驗證完成，則JWS簽名信息驗證完畢，若Chatbot 詳情信息不包含圖標的信息，則Chatbot 認證成功，若Chatbot 詳情信息中圖標包含指紋信息，當“指紋”屬性的值與Chatbot 信息中圖標的URL所指文件的SHA-256散列相匹配時，Chatbot驗證應被視為成功。

當MaaP 平臺對Chatbot 認證成功后，verificationinfo 中的bot-verification 字段將設置為True；終端得到該信息后將向客戶展示認證機構以及認證到期時間；至此，Chatbot認證流程完整結束。

3 第三方認證機構引入建議及展望

5G 消息的普及必將會帶來千萬級別的Chatbot 應用，對Chatbot 應用的管理和認證將是一項新的任務，哪些Chatbot值得信任需要公平公正客觀的評價體系，建議引入第三方權威認證機構進行認證，運營商按照Chatbot 認證規則對認證進行校驗，為行業應用創造良好的生態，讓有價值的應用能夠快速地得到認可和普及，讓用戶也更方便地找到可信任的應用。

5G 消息的建設及發展需要終端、運營商網絡、業務平臺及行業應用的相互協同和共同發展。相信借助5G消息完善的安全認證體系以及原生、互聯互通等OTT 應用不具備的特征，一定會給政府政務、公共安全、旅游出行、金融零售、新聞教育、民生環保等領域帶來全新的交互體驗，創造更多的價值。