［陳鑫 賀曉東 丁嘉嘉 馬幸暉］

1 引言

5G 網(wǎng)絡(luò)的快速普及，推動(dòng)了移動(dòng)互聯(lián)網(wǎng)服務(wù)和應(yīng)用數(shù)量急劇增長(zhǎng)，促使人們的生活、社交與互聯(lián)網(wǎng)深度融合。手機(jī)號(hào)碼已成為通往互聯(lián)網(wǎng)數(shù)字世界的身份通行證，人們通過手機(jī)號(hào)碼實(shí)現(xiàn)應(yīng)用、數(shù)據(jù)、服務(wù)的互聯(lián)互通，享受更便捷、更智能的互聯(lián)網(wǎng)生活。基于PGW/UPF 頭增強(qiáng)(以下簡(jiǎn)稱頭增強(qiáng)）手機(jī)號(hào)碼認(rèn)證技術(shù)具有安全、便捷、可信等優(yōu)勢(shì)。頭增強(qiáng)認(rèn)證在應(yīng)用過程中，用戶無需密碼，一鍵認(rèn)證大大提升了身份認(rèn)證的便捷性，認(rèn)證過程由電信運(yùn)營(yíng)商的核心網(wǎng)設(shè)備完成，保證了身份認(rèn)證的安全、可信性達(dá)到電信級(jí)。其人機(jī)交互友好，速度比傳統(tǒng)的短信認(rèn)證、賬號(hào)密碼認(rèn)證提升10 倍以上，且單次認(rèn)證成功率高達(dá)99%。因此頭增強(qiáng)認(rèn)證成為互聯(lián)網(wǎng)眾多APP 登錄認(rèn)證的首選項(xiàng)。但與此同時(shí)，頭增強(qiáng)技術(shù)在應(yīng)用過程中也受到了終端應(yīng)用場(chǎng)景限制、安全、多運(yùn)營(yíng)商融合等技術(shù)問題制約，影響其規(guī)模和發(fā)展。本文對(duì)頭增強(qiáng)認(rèn)證應(yīng)用關(guān)鍵技術(shù)進(jìn)行了研究分析，提出部署方案和建議，為后續(xù)的頭增強(qiáng)應(yīng)用建設(shè)提供參考。

2 頭增強(qiáng)認(rèn)證概述及應(yīng)用說明

核心網(wǎng)網(wǎng)關(guān)設(shè)備（PGW/UPF）通過DPI 功能模塊基于CN 隧道信息、網(wǎng)絡(luò)實(shí)例、QFI、IP 包過濾器集、應(yīng)用標(biāo)識(shí)符等對(duì)IPv4、IPv6 或IPv4/v6 PDU 會(huì)話的用戶數(shù)據(jù)報(bào)文進(jìn)行檢測(cè)和識(shí)別。如用戶報(bào)文特征與規(guī)則庫中的規(guī)則匹配，則對(duì)報(bào)文進(jìn)行拆包，拆包后在數(shù)據(jù)包中增加用戶相關(guān)信息用于認(rèn)證稱為頭增強(qiáng)認(rèn)證，如圖1 所示。

圖1 頭增強(qiáng)認(rèn)證流程示意圖

頭增強(qiáng)認(rèn)證技術(shù)業(yè)務(wù)應(yīng)用過程如下：

（1）客戶端APP 認(rèn)證數(shù)據(jù)流，經(jīng)過UPF/PGW 頭增強(qiáng)后轉(zhuǎn)發(fā)到認(rèn)證平臺(tái)獲取認(rèn)證授權(quán)碼accesscode；

（2）客戶端APP 將accesscode 參數(shù)值提交到APP 服務(wù)端；

（3）APP 服務(wù)端將accesscode 參數(shù)值提交運(yùn)營(yíng)商認(rèn)證平臺(tái)換取用戶信息（手機(jī)號(hào)碼）；

（4）APP 服務(wù)端再將認(rèn)證結(jié)果返回給APP 客戶端。

圖2 頭增強(qiáng)技術(shù)認(rèn)證業(yè)務(wù)流程圖

3 應(yīng)用關(guān)鍵技術(shù)及方案

3.1 https 協(xié)議頭增強(qiáng)關(guān)鍵技術(shù)

隨著國(guó)家《網(wǎng)絡(luò)安全法》的頒布，國(guó)內(nèi)對(duì)于信息安全的重視度已經(jīng)有了質(zhì)的改變，安全可靠的證書傳輸HTTPS協(xié)議得到了進(jìn)一步普及。HTTPS 協(xié)議頭增強(qiáng)比HTTP 協(xié)議頭增強(qiáng)在應(yīng)用過程中，具有更好的適用性、安全性和穿透性。

HTTPS 協(xié)議與HTTP 協(xié)議不同點(diǎn)在于報(bào)文是否加密。HTTPS 協(xié)議是由TLS 協(xié)議和HTTP 協(xié)議組成，經(jīng)由HTTP 進(jìn)行通信，中間利用SSL/TLS 來加密數(shù)據(jù)包。在HTTP 協(xié)議報(bào)文傳輸?shù)娜鞒讨?，?bào)文始終以明文形式暴露在鏈路上，因此PGW/UPF 可在其報(bào)文的頭部插入頭增強(qiáng)認(rèn)證相關(guān)信息。但HTTPS 協(xié)議報(bào)文在進(jìn)行傳輸時(shí)，請(qǐng)求和響應(yīng)信息的報(bào)文都已經(jīng)過加密，通信過程中的UPF/PGW 網(wǎng)關(guān)設(shè)備無法對(duì)已加密的信息進(jìn)行頭增強(qiáng)，原有基于HTTP 協(xié)議的明文頭增強(qiáng)方式已不再適用，因此需要從HTTPS 協(xié)議的特點(diǎn)入手，在握手過程中的client hello 信息中，進(jìn)行頭增強(qiáng)信息的插入，同時(shí)運(yùn)營(yíng)商認(rèn)證平臺(tái)服務(wù)端也需要在此階段進(jìn)行頭增強(qiáng)信息提取。HTTPS 協(xié)議的頭增強(qiáng)流程如圖3 所示。

圖3 HTTPS 協(xié)議頭增強(qiáng)流程圖

3.1.1 TLS 頭增強(qiáng)規(guī)則

（l）數(shù)據(jù)攜帶規(guī)則

在TLS 握手的client hello 消息中插入私有擴(kuò)展頭，擴(kuò)展頭格式類似server-name，支持一個(gè)extension里封裝多個(gè)擴(kuò)展頭數(shù)據(jù)列表，實(shí)現(xiàn)HTTPS 的頭增強(qiáng)數(shù)據(jù)攜帶。在extension字段中定義指定的extension_type名稱，例如運(yùn)營(yíng)商使用的字段名為17 965 的擴(kuò)展字段，并將用戶的手機(jī)號(hào)碼等增強(qiáng)的信息填入此字段。為進(jìn)一步增強(qiáng)該字段的擴(kuò)展性，可定義sub extension，支持靈活攜帶各種頭增強(qiáng)信息，便于后續(xù)攜帶其他擴(kuò)展信息，對(duì)齊HTTP 頭增強(qiáng)功能。

（2）數(shù)據(jù)存儲(chǔ)規(guī)則

規(guī)則定義對(duì)extension-type：設(shè)定為固定值（如：17 965），占2 個(gè)字節(jié)，total-length：該extension 總長(zhǎng)度，占2 個(gè)字節(jié)，用于后續(xù)擴(kuò)展頭數(shù)據(jù)sub extension 列表，可以多個(gè)sub extension并列。對(duì)于每個(gè)sub extension，包括1 個(gè)字節(jié)的type（數(shù)據(jù)類型），2 個(gè)字節(jié)的length，之后緊接的為具體data。在一個(gè)extension中，各sub extension的先后順序不影響插入數(shù)據(jù)的含義，也就是插入信息的前后順序可以任意。extension 字段數(shù)據(jù)結(jié)構(gòu)如圖4 所示。

圖4 extension 攜帶字段示意圖

頭增強(qiáng)策略應(yīng)用后，在運(yùn)營(yíng)商認(rèn)證服務(wù)端抓包效果如圖5 所示。

圖5 頭增強(qiáng)應(yīng)用效果圖

3.1.2 服務(wù)端數(shù)據(jù)提取方案

HTTPS 協(xié)議在TLS client hello 過程中通過網(wǎng)關(guān)設(shè)備UPF/PGW 頭增強(qiáng)后數(shù)據(jù)轉(zhuǎn)發(fā)到運(yùn)營(yíng)商認(rèn)證服務(wù)端，根據(jù)TLS 協(xié)議，HTTPS 應(yīng)用過程中服務(wù)端會(huì)將收到的頭增強(qiáng)的數(shù)據(jù)包生成MAC（message authentication code）和原包值校驗(yàn)，協(xié)議校驗(yàn)失敗會(huì)拋出Bad Record MAC 異常，如圖6 所示。

圖6 TLS 協(xié)議異常圖

Bad Record MAC 異常，TLS 協(xié)議識(shí)別為交互過程數(shù)據(jù)遭到篡改，服務(wù)端根據(jù)TLS 協(xié)議安全規(guī)則主動(dòng)中斷數(shù)據(jù)流連接，導(dǎo)致頭增強(qiáng)認(rèn)證流程無法進(jìn)行，因此需要在服務(wù)端TLS 協(xié)議MAC 校驗(yàn)階段進(jìn)行技術(shù)改造，主要技術(shù)方案如下：

（1）調(diào)整服務(wù)端的MAC 校驗(yàn)過程

在服務(wù)端OpenSSL 交互驗(yàn)證過程中，修改TLS 交互過程默認(rèn)MAC 校驗(yàn)通過，規(guī)避MAC 校驗(yàn)帶來中斷風(fēng)險(xiǎn)。但此方案涉及優(yōu)化調(diào)整的TLS 流程較多，會(huì)影響沒有頭增強(qiáng)的TLS 正常的MAC 校驗(yàn)，給系統(tǒng)的安全性帶來一定的風(fēng)險(xiǎn)。

（2）特定字段數(shù)據(jù)拆包方案

檢測(cè)到握手包中具有運(yùn)營(yíng)商特定標(biāo)識(shí)（如：17965）的擴(kuò)展字段時(shí)，對(duì)數(shù)據(jù)包進(jìn)行復(fù)制，再對(duì)復(fù)制包進(jìn)行拆解，刪除頭增強(qiáng)的信息并產(chǎn)生MAC，通過MAC 校驗(yàn)后，由于原包未修改，后續(xù)處理流程仍然使用具有頭增強(qiáng)信息的數(shù)據(jù)包。后續(xù)服務(wù)端數(shù)據(jù)提取模塊仍然可以解析到頭增強(qiáng)信息。配合網(wǎng)關(guān)的防欺詐功能，既保障功能點(diǎn)的完整性，又保障了安全性。通常情況下推薦該方案。

3.2 多運(yùn)營(yíng)商融合關(guān)鍵技術(shù)

為了解決用戶終端多運(yùn)營(yíng)商認(rèn)證問題，終端在應(yīng)用過程中需要支持三網(wǎng)融合認(rèn)證，認(rèn)證過程中根據(jù)終端應(yīng)用使用具體環(huán)境場(chǎng)景，推薦不同融合策略。

（1）客戶端三網(wǎng)融合策略

終端APP 融合三網(wǎng)運(yùn)營(yíng)商頭增強(qiáng)能力，APP應(yīng)用程序從終端系統(tǒng)獲取運(yùn)營(yíng)商類型，根據(jù)運(yùn)營(yíng)商類型來選擇相應(yīng)的運(yùn)營(yíng)商頭增強(qiáng)能力。

（2）服務(wù)端三網(wǎng)融合策略

終端APP 只需要集成單網(wǎng)運(yùn)營(yíng)商頭增強(qiáng)能力，就可借助認(rèn)證平臺(tái)側(cè)實(shí)現(xiàn)三網(wǎng)融合。流程中認(rèn)證服務(wù)端通過終端流量IP 歸屬，控制終端轉(zhuǎn)發(fā)到到對(duì)應(yīng)的運(yùn)營(yíng)商。參考中國(guó)電信統(tǒng)一賬號(hào)認(rèn)證平臺(tái)，三網(wǎng)融合大致實(shí)現(xiàn)流程如圖7 所示。

圖7 服務(wù)端三網(wǎng)融合流程示意圖

客戶端三網(wǎng)融合策略只適用于APP 應(yīng)用下頭增強(qiáng)認(rèn)證，服務(wù)端三網(wǎng)融合策略可適用于APP、小程序、H5 環(huán)境下頭增強(qiáng)認(rèn)證。在應(yīng)用過程中因客戶端三網(wǎng)融合策略交互流程短，可控性強(qiáng)，成功率相對(duì)較高。合作方可根據(jù)具體應(yīng)用場(chǎng)景選擇合適的三網(wǎng)融合策略。

4 安全加固關(guān)鍵技術(shù)

4.1 應(yīng)用過程安全策略

頭增強(qiáng)認(rèn)證過程中，為了確保應(yīng)用的安全性，結(jié)合頭增強(qiáng)認(rèn)證特點(diǎn)，利用頭增強(qiáng)優(yōu)勢(shì)對(duì)鏈路上各個(gè)環(huán)節(jié)進(jìn)行安全加固，以確保過程安全，主要應(yīng)用策略如下：

（1）頭增強(qiáng)加密策略

不同于HTTP 頭增強(qiáng)內(nèi)容加密，HTTPS 頭增強(qiáng)在原有綜合加密的基礎(chǔ)上面增加動(dòng)態(tài)混淆技術(shù)，確保每次頭增強(qiáng)數(shù)據(jù)內(nèi)容都不相同，杜絕對(duì)數(shù)據(jù)內(nèi)容窮舉的可能性，極大的提升了數(shù)據(jù)的安全性。

式中：C0、C1 (mg/L)分別代表吸附液的初始濃度和吸附測(cè)定時(shí)的濃度；V(L)代表吸附液的體積；m(g)表示投加吸附劑的量。

（2）頭增強(qiáng)覆蓋重寫策略

為了防止客戶端側(cè)偽造頭增強(qiáng)信息，核心網(wǎng)設(shè)備PGW/UPF 對(duì)數(shù)據(jù)拆包后，每次都會(huì)進(jìn)行頭增強(qiáng)信息重寫，覆蓋可能因?yàn)榭蛻舳烁脑旎蛘咛砑拥念愃祁^增強(qiáng)的相關(guān)信息，確保頭增強(qiáng)信息可信、防偽造。

（3）白名單IP 防控策略

根據(jù)PGW/UPF 設(shè)備部署的區(qū)域不同，認(rèn)證服務(wù)端根據(jù)獲取終端數(shù)據(jù)包的來源IP 進(jìn)行差異化鑒權(quán)。

（4）Oauth2 模式下非對(duì)稱加密策略

應(yīng)用過程中提供客戶端SDK 接入和服務(wù)端認(rèn)證API接入，全鏈路傳輸過程中使用https 加密，交互過程使用標(biāo)準(zhǔn)oauth2 的授權(quán)模式，賬號(hào)和密鑰不經(jīng)第三方，認(rèn)證成功后通過accessToken 調(diào)用能力接口。終端APP 發(fā)起預(yù)取號(hào)請(qǐng)求到認(rèn)證服務(wù)器，認(rèn)證服務(wù)器只返回臨時(shí)授權(quán)碼，而真實(shí)的用戶信息，認(rèn)證服務(wù)器只會(huì)通過對(duì)方在認(rèn)證平臺(tái)配置的公鑰進(jìn)行不對(duì)稱加密后返回給應(yīng)用的服務(wù)端。以確保應(yīng)用過程中數(shù)據(jù)的安全性。

4.2 終端應(yīng)用安全

4.2.1 防終端劫持策略

為確保頭增強(qiáng)認(rèn)證終端在認(rèn)證過程中未發(fā)生更換，規(guī)避認(rèn)證過程中存在終端劫持的風(fēng)險(xiǎn)。利用頭增強(qiáng)認(rèn)證的優(yōu)勢(shì)，認(rèn)證服務(wù)端在獲取用戶手機(jī)號(hào)碼過程中同時(shí)獲取私網(wǎng)IP，在后續(xù)取號(hào)過程中校驗(yàn)私網(wǎng)IP 是否發(fā)生變更。具體流程如圖8 所示。

圖8 防終端劫持策略流程圖

4.2.2 防熱點(diǎn)中間人策略

頭增強(qiáng)認(rèn)證應(yīng)用過程中，核心網(wǎng)關(guān)核心網(wǎng)設(shè)備PGW/UPF 對(duì)數(shù)據(jù)拆包后，在頭增強(qiáng)信息中插入數(shù)據(jù)包的TTL 值，認(rèn)證服務(wù)端根據(jù)終端特征和TTL 參數(shù)值綜合判斷終端是否借助了第三方中間人的熱點(diǎn)流量發(fā)起認(rèn)證請(qǐng)求。并根據(jù)判定結(jié)果執(zhí)行認(rèn)證策略，如圖9 所示。

圖9 防熱點(diǎn)中間人策略流程圖

5 結(jié)束語

PGW/UPF 頭增強(qiáng)認(rèn)證關(guān)鍵技術(shù)及方案的應(yīng)用推動(dòng)了頭增強(qiáng)認(rèn)證業(yè)務(wù)的廣泛使用，截止到2021 年12 月，基于頭增強(qiáng)認(rèn)證技術(shù)的中國(guó)電信統(tǒng)一賬號(hào)認(rèn)證平臺(tái)免密認(rèn)證產(chǎn)品，已經(jīng)接入應(yīng)用超過3 萬個(gè)，其中TOP 200 的應(yīng)用已經(jīng)有150 個(gè)，日調(diào)用次數(shù)近5 億次，高效的促進(jìn)了運(yùn)營(yíng)商移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)和用戶規(guī)模發(fā)展，提升了我國(guó)運(yùn)營(yíng)商核心競(jìng)爭(zhēng)力。頭增強(qiáng)認(rèn)證技術(shù)不僅可以為民眾提供高質(zhì)量移動(dòng)互聯(lián)網(wǎng)接入服務(wù)，而且極大提升了運(yùn)營(yíng)商基礎(chǔ)設(shè)施水平，為國(guó)家信息化做出重大貢獻(xiàn)。本文對(duì)PGW/UPF 頭增強(qiáng)相關(guān)應(yīng)用的關(guān)鍵技術(shù)及現(xiàn)網(wǎng)部署進(jìn)行了研究分析，可為運(yùn)營(yíng)商后續(xù)頭增強(qiáng)相關(guān)能力應(yīng)用提供參考和借鑒，以提升運(yùn)營(yíng)商創(chuàng)新產(chǎn)品的應(yīng)用能力和服務(wù)水平。