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

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

0 引言

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

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

1 用戶認證安全分析

1.1 5G消息體系結(jié)構(gòu)

5G 消息屬于RCS 業(yè)務(wù)，基于IMS 網(wǎng)絡(luò)來承載，通過4G/5G 及Wi-Fi 網(wǎng)絡(luò)來接入，RCS AS 處理消息業(yè)務(wù)邏輯，MaaP 平臺實現(xiàn)消息即平臺功能，對接行業(yè)應(yīng)用（見圖1）。

圖1 5G消息體系結(jié)構(gòu)圖

1.2 注冊認證安全分析

5G 消息業(yè)務(wù)屬于IMS 業(yè)務(wù)范疇，業(yè)務(wù)注冊時采用SIP 協(xié)議進行交互，使用AKA 方式進行認證。IMSAKA鑒權(quán)的主要流程如下。

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

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

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

d）S-CSCF 保存全部鑒權(quán)向量5 元組。將RAND、AUTH、XRES、CK 和IK 在SIP 4XX 應(yīng)答中發(fā)給ICSCF，由其轉(zhuǎn)發(fā)給P-CSCF。

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

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

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

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

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

1.3 HTTP業(yè)務(wù)認證安全分析

在5G 消息中，使用HTTP 協(xié)議進行交互的網(wǎng)元有DM 服務(wù)器、AS 中的HTTP 內(nèi)容服務(wù)器、MaaP 平臺的Chatbot 目錄服務(wù)器、Chatbot 信息服務(wù)器以及HTTP 內(nèi)容服務(wù)器。

1.3.1 DM交互

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

1.3.2 GBA認證

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

圖2 GBA認證流程圖

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

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

b）HTTP 或者HTTPS：UE 請求使用HTTP 還是HTTPS 方式不但決定了傳輸層協(xié)議是否安全，而且決定了NAF_ID 的取值方式，根據(jù)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鑒權(quán)具體實施的過程中采用HTTPS 方式保障了傳輸層面的安全性。

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

d）BIA消息的驗證方式：

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

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

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

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

1.4 系統(tǒng)認證角色分析

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

HTTP 服務(wù)器：HTTP 服務(wù)器是應(yīng)用的鑒權(quán)點，需要支持并開啟GBA 認證方式，并和BSF 進行BIR 以及BIA 消息交互，根據(jù)交互結(jié)果和終端側(cè)信息進行比較達到認證鑒權(quán)目的。

BSF 網(wǎng)元：BSF 網(wǎng)元是GBA 認證流程中重要的一環(huán)，它通過Ub 接口和終端進行交互，通過Zn 接口和NAF（HTTP 應(yīng)用服務(wù)器）交互，通過Dz 以及Zh 接口和HSS 進行交互，并可以作為GBA 鑒權(quán)的網(wǎng)絡(luò)能力開放網(wǎng)元，在物聯(lián)網(wǎng)等領(lǐng)域?qū)⒄J證能力對外開放（見圖3）。

圖3 BSF網(wǎng)元接口系統(tǒng)圖

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

2 Chatbot認證安全分析

2.1 MaaP平臺

消息即平臺（MaaP——Message as a Platform），是5G消息網(wǎng)絡(luò)中將消息能力開放給企業(yè)的核心網(wǎng)元，企業(yè)側(cè)應(yīng)用（Chatbot）通過MaaP 平臺以SIP或者HTTP 方式進行交互，南向?qū)覴CS AS 及終端，主要功能包括Chatbot 接入、Chatbot 目錄、Chatbot 信息、HTTP 內(nèi)容存儲，消息收發(fā)、消息審核、能力探測等。

2.2 Chatbot認證

2.2.1 Chatbot簽名

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

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

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

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

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

認證機構(gòu)簽名后將簽名信息以及Chatbot 信息發(fā)送至MaaP平臺。

2.2.2 Chatbot簽名核查流程

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

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

b）如果驗證簽名屬性與JSON 序列化中的JWS 不對應(yīng)，則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驗證應(yīng)被視為成功。

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

3 第三方認證機構(gòu)引入建議及展望

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

5G 消息的建設(shè)及發(fā)展需要終端、運營商網(wǎng)絡(luò)、業(yè)務(wù)平臺及行業(yè)應(yīng)用的相互協(xié)同和共同發(fā)展。相信借助5G消息完善的安全認證體系以及原生、互聯(lián)互通等OTT 應(yīng)用不具備的特征，一定會給政府政務(wù)、公共安全、旅游出行、金融零售、新聞教育、民生環(huán)保等領(lǐng)域帶來全新的交互體驗，創(chuàng)造更多的價值。