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

0 引言

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

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

1 用戶認(rèn)證安全分析

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 平臺實(shí)現(xiàn)消息即平臺功能，對接行業(yè)應(yīng)用（見圖1）。

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

1.2 注冊認(rèn)證安全分析

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

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

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

c）由于用戶當(dāng)前沒有在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的擴(kuò)展將用做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 認(rèn)證鑒權(quán)通過，可以享受服 務(wù)。S-CSCF 向HSS 設(shè) 置Registration Flag（registered），并從HSS 中獲取用戶屬性和業(yè)務(wù)信息。最后向UE發(fā)送SIP 2XX注冊完成響應(yīng)。

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

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

在5G 消息中，使用HTTP 協(xié)議進(jìn)行交互的網(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 卡歸屬的運(yùn)營商構(gòu)建出DM 設(shè)備標(biāo)準(zhǔn)域名（如http：//config.rcs.mnc.mcc.pub.3gppnetwork.org），并向該域名發(fā)起HTTP（HTTPS）請求，該請求不涉及到用戶操作，采用Token或者Session的方式進(jìn)行認(rèn)證。

1.3.2 GBA認(rèn)證

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

圖2 GBA認(rèn)證流程圖

GBA 認(rèn)證有效利用AKA 鑒權(quán)的特性對非SIP 請求進(jìn)行認(rèn)證，對于GBA 鑒權(quán)中涉及到的主要關(guān)鍵點(diǎ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)具體實(shí)施的過程中采用HTTPS 方式保障了傳輸層面的安全性。

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

d）BIA消息的驗(yàn)證方式：

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

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

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

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

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

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

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

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

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

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

2 Chatbot認(rèn)證安全分析

2.1 MaaP平臺

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

2.2 Chatbot認(rèn)證

2.2.1 Chatbot簽名

認(rèn)證機(jī)構(gòu)通過JWS（JSON Web Signature）的方式對Chatbot進(jìn)行簽名，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)容使用私鑰進(jìn)行加密，并以Base64 編碼進(jìn)行呈現(xiàn)。

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

2.2.2 Chatbot簽名核查流程

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

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

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

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

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

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

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

g）如果Payload 中的Iconfingerpirnt 信息與Chatbot 詳情信息中的圖標(biāo)指紋信息不匹配，則Chatbot 將被視為未驗(yàn)證。

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

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

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

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

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