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

0 引言

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

5G 消息相比OTT 廠商公眾號(hào)能提供更安全、更便捷、更高效、更高觸達(dá)率的交互式應(yīng)用，安全是5G消息的基礎(chǔ)能力底座，也是政府政務(wù)、金融保險(xiǎn)等對(duì)安全等級(jí)要求比較高的行業(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ò)來(lái)承載，通過(guò)4G/5G 及Wi-Fi 網(wǎng)絡(luò)來(lái)接入，RCS AS 處理消息業(yè)務(wù)邏輯，MaaP 平臺(tái)實(shí)現(xiàn)消息即平臺(tái)功能，對(duì)接行業(yè)應(yīng)用（見(jiàn)圖1）。

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

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

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

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

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

c）由于用戶當(dāng)前沒(méi)有在S-CSCF 中注冊(cè)，所以需要向HSS 設(shè)置Registration Flag（pending），指示正在注冊(cè)。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計(jì)算XMAC，判斷XMAC是否和MAC一致，SQN是否在合理數(shù)值范圍，以辨別IMS網(wǎng)絡(luò)是否合法。UE 利用共享密鑰和RAND 計(jì)算鑒權(quán)響應(yīng)RES，并重新發(fā)起注冊(cè)過(guò)程。

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

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

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

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

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

1.3.1 DM交互

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

1.3.2 GBA認(rèn)證

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

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

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

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

b）HTTP 或者HTTPS：UE 請(qǐng)求使用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í)施的過(guò)程中采用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)證方式（基于請(qǐng)求消息中的realm）一致，如果一致，則進(jìn)行后續(xù)操作；如果不一致，則給UE返回401認(rèn)證失敗消息。

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

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

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

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

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

HTTP 服務(wù)器：HTTP 服務(wù)器是應(yīng)用的鑒權(quán)點(diǎn)，需要支持并開(kāi)啟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)，它通過(guò)Ub 接口和終端進(jìn)行交互，通過(guò)Zn 接口和NAF（HTTP 應(yīng)用服務(wù)器）交互，通過(guò)Dz 以及Zh 接口和HSS 進(jìn)行交互，并可以作為GBA 鑒權(quán)的網(wǎng)絡(luò)能力開(kāi)放網(wǎng)元，在物聯(lián)網(wǎng)等領(lǐng)域?qū)⒄J(rèn)證能力對(duì)外開(kāi)放（見(jiàn)圖3）。

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

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

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

2.1 MaaP平臺(tái)

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

2.2 Chatbot認(rèn)證

2.2.1 Chatbot簽名

認(rèn)證機(jī)構(gòu)通過(guò)JWS（JSON Web Signature）的方式對(duì)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 屬性，用來(lái)指示加密算法的公鑰值，以Base64編碼呈現(xiàn)。

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

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

2.2.2 Chatbot簽名核查流程

MaaP平臺(tái)對(duì)簽名核查流程如下。

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

b）如果驗(yàn)證簽名屬性與JSON 序列化中的JWS 不對(duì)應(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 對(duì)象不包括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散列相匹配時(shí)，Chatbot驗(yàn)證應(yīng)被視為成功。

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

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

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

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