移動(dòng)平臺(tái)典型應(yīng)用的身份認(rèn)證問題研究

張效林，谷大武，張馳

移動(dòng)平臺(tái)典型應(yīng)用的身份認(rèn)證問題研究

張效林1,2，谷大武1,2，張馳1

（1. 上海交通大學(xué)電子信息與電氣工程學(xué)院，上海 200240；2. 西安電子科技大學(xué)網(wǎng)絡(luò)與信息安全學(xué)院，陜西 西安 710126）

近年來的研究表明，針對USIM卡的攻擊手段日益增多，在5G環(huán)境下攻擊者也能使用復(fù)制的USIM卡繞過某些正常應(yīng)用的身份認(rèn)證，進(jìn)而獲取用戶信息。在USIM可被復(fù)制的條件下，研究了移動(dòng)平臺(tái)上典型應(yīng)用的身份認(rèn)證流程，通過分析用戶登錄、重置密碼、執(zhí)行敏感操作的應(yīng)用行為給出身份認(rèn)證樹。在此基礎(chǔ)上，測試了社交通信、個(gè)人健康等7類58款典型應(yīng)用，發(fā)現(xiàn)有29款認(rèn)證時(shí)僅需USIM卡接收的SMS驗(yàn)證碼便可通過認(rèn)證。針對該問題，建議應(yīng)用開啟兩步驗(yàn)證，并結(jié)合USIM防偽等手段完成認(rèn)證。

移動(dòng)應(yīng)用；USIM復(fù)制；SMS；身份認(rèn)證；移動(dòng)應(yīng)用測試

1 引言

1.1 研究背景

USIM（全球用戶識(shí)別模塊）[1]作為UMTS（通用移動(dòng)通信系統(tǒng)）網(wǎng)絡(luò)中用戶身份的標(biāo)識(shí)模塊廣泛用于各類移動(dòng)設(shè)備，為用戶提供認(rèn)證服務(wù)、短信息服務(wù)等。與SIM（用戶身份識(shí)別模塊）相比，USIM卡在應(yīng)用支持與安全性上進(jìn)行了升級，USIM卡在支持3G/4G服務(wù)的同時(shí)，能向下兼容SIM卡所支持的2G網(wǎng)絡(luò)。在日漸成熟的5G網(wǎng)絡(luò)中，USIM卡將在實(shí)體認(rèn)證、信息交換等方面發(fā)揮更重要的作用。

移動(dòng)設(shè)備的推廣和移動(dòng)應(yīng)用的發(fā)展相輔相成，互為促進(jìn)。截至2019年第三季度，國家統(tǒng)計(jì)局?jǐn)?shù)據(jù)顯示，我國4G移動(dòng)電話用戶數(shù)同比增長10.1%，移動(dòng)互聯(lián)網(wǎng)接入流量同比增長34.9%[2]；同時(shí)，5G基站已投入建成13萬座，5G通信技術(shù)及商業(yè)化迎來高速發(fā)展。而在全球范圍內(nèi)，2018年世界各地用戶共計(jì)下載了1 940億次手機(jī)應(yīng)用（App），涵蓋金融支付類、社交通信類、出行類、娛樂影音類應(yīng)用等，其中在線金融支付類應(yīng)用發(fā)展迅速，用戶下載量較2017年相比增長了27.8%[3-4]，隨之而來的數(shù)據(jù)隱私風(fēng)險(xiǎn)不斷增大。搭載USIM卡的移動(dòng)設(shè)備及其中的應(yīng)用程序已成為人們生活的一部分，而這些應(yīng)用往往擁有用戶敏感信息的操作權(quán)限，并對登錄用戶的身份進(jìn)行認(rèn)證。在實(shí)現(xiàn)身份認(rèn)證時(shí)，SMS驗(yàn)證碼作為一種低成本、易實(shí)現(xiàn)、用戶學(xué)習(xí)門檻低的驗(yàn)證方式得到了極為廣泛的應(yīng)用。USIM卡作為接收SMS驗(yàn)證碼的必要載體，一旦出現(xiàn)可被復(fù)制或偽造等安全問題，將會(huì)直接威脅所有USIM設(shè)備的安全性，也必然會(huì)對設(shè)備中App的身份認(rèn)證過程與用戶隱私產(chǎn)生巨大威脅。

1.2 SIM/USIM安全研究現(xiàn)狀

用戶使用移動(dòng)設(shè)備通信時(shí)，設(shè)備中的SIM/USIM卡需先與網(wǎng)絡(luò)完成認(rèn)證并接入。研究表明，盡管USIM卡使用MILENAGE算法實(shí)現(xiàn)雙向認(rèn)證，SIM卡使用A3/A8算法實(shí)現(xiàn)單向認(rèn)證，但都面臨被復(fù)制的可能。

1.2.1 SIM/USIM卡復(fù)制攻擊

Liu等[5]針對USIM認(rèn)證過程中的功耗信號差異，提出了一種可行的差分功耗分析（DPA）的側(cè)信道攻擊方法，該方法針對3G/4G AKA協(xié)議[6]中基于AES的MILENAGE算法，通過選擇其中的5函數(shù)進(jìn)行差分功耗分析，借助Person相關(guān)系數(shù)[7]可推算出認(rèn)證參數(shù)運(yùn)算所用的輪密鑰及OPc的期望值。基于此，攻擊者僅通過使用示波器、智能卡分析儀以及個(gè)人計(jì)算機(jī)即可在若干分鐘內(nèi)完成對原USIM卡的復(fù)制，實(shí)現(xiàn)與AuC（認(rèn)證中心）的認(rèn)證并正常通信。

除此以外，Anwar等[8]對基于COMP128的A3/A8算法進(jìn)行研究，結(jié)合A3認(rèn)證算法的SRES響應(yīng)數(shù)對AuC所用的偽隨機(jī)數(shù)發(fā)生器進(jìn)行破解，可提取AuC與SIM卡的客戶認(rèn)證密鑰，進(jìn)而實(shí)現(xiàn)了SIM卡的復(fù)制。Singh等[9]考慮到GSM（全球移動(dòng)通信系統(tǒng)）所用COMP128認(rèn)證算法可使攻擊者成功利用暴力破解提取SIM的認(rèn)證密鑰，提出了針對SIM卡實(shí)施OTA復(fù)制的基本流程與常見方法。Rao等[10]提出了一種稱為分區(qū)攻擊的側(cè)信道攻擊方法，該攻擊方法能對COMP128中劃分后的查找表結(jié)構(gòu)實(shí)施快速功耗分析，從而提取認(rèn)證密鑰。對于CDMA技術(shù)，Zhang等[11]對CAVE協(xié)議中的查找表以及AKA協(xié)議中循環(huán)移位操作進(jìn)行分析，分別設(shè)計(jì)了不同的功耗分析方法，在8位微處理器以及SIM卡上花費(fèi)很短時(shí)間即可成功實(shí)現(xiàn)認(rèn)證密鑰的提取。

在5G網(wǎng)絡(luò)環(huán)境中，USIM所采取的AKA認(rèn)證協(xié)議在NSA模式下與3G/4G AKA協(xié)議的主要流程和算法參數(shù)一致[12]。因此，3G/4G環(huán)境下USIM卡的安全分析方法與破解手段在5G網(wǎng)絡(luò)中依然有效[13-14]。上述研究表明，國內(nèi)外市場上大量存在和使用著容易被復(fù)制的USIM卡，攻擊者僅需花費(fèi)幾分鐘的功耗數(shù)據(jù)采集時(shí)間，即可實(shí)現(xiàn)對目標(biāo)用戶USIM卡的離線破解和復(fù)制，而且這種破解和復(fù)制使用個(gè)人PC只需幾分鐘到幾十分鐘的時(shí)間即可完成。

為了應(yīng)對USIM卡被上述攻擊方法破解的風(fēng)險(xiǎn)，國內(nèi)外許多芯片設(shè)計(jì)企業(yè)已經(jīng)開始研究各種芯片防護(hù)方法，并將防護(hù)技術(shù)應(yīng)用到新設(shè)計(jì)和流片的USIM芯片中。但與軟件漏洞的修復(fù)相比，芯片安全問題的解決往往需要對芯片進(jìn)行重新設(shè)計(jì)開發(fā)和流片，這無疑是一個(gè)較長的時(shí)間，而且對于USIM芯片而言，即使已經(jīng)生產(chǎn)出具有抗攻擊能力的USIM卡，這些芯片要得到廣泛使用，仍需要運(yùn)營商對已發(fā)行的USIM芯片進(jìn)行大規(guī)模的召回或強(qiáng)制更換，這顯然是不可行的。這在客觀上造成現(xiàn)實(shí)中必然存在大量可被復(fù)制的USIM卡長期且廣泛地被使用。

1.2.2 SMS驗(yàn)證碼的應(yīng)用及安全

SMS驗(yàn)證碼已經(jīng)廣泛用于登錄移動(dòng)平臺(tái)上的應(yīng)用程序或重置密碼等認(rèn)證環(huán)節(jié)，作為USIM卡向App傳遞信息的載體與橋梁，它代表了特定USIM卡和設(shè)備持有人之間的聯(lián)系。SMS驗(yàn)證碼實(shí)質(zhì)是一種基于時(shí)間的一次性密碼（TOTP，time-based one time password）[15]，其架構(gòu)如圖1所示。

圖1 SMS一般架構(gòu)

Figure 1 Overall structure of short message service (SMS)

MSC（移動(dòng)交換中心）到UE的認(rèn)證與消息傳遞往往基于GSM或者UMTS網(wǎng)絡(luò)，實(shí)際中針對SMS的攻擊行為多發(fā)生在設(shè)備與基站的認(rèn)證過程中或者用戶收到SMS消息后。Dmitrienko等[16]分析各類SMS攻擊向量，指出在設(shè)備上安裝惡意軟件竊取數(shù)據(jù)是針對SMS安全的常見攻擊手段。Alecu[17]則實(shí)現(xiàn)了一種無須用戶許可就能使設(shè)備發(fā)送SMS消息并讓該設(shè)備無法收到消息的攻擊手段。當(dāng)攻擊者使用復(fù)制USIM卡接入基站后，可代替原用戶接收SMS驗(yàn)證碼，并完成App中的認(rèn)證流程。

1.3 本文的主要工作和結(jié)果

為避免USIM卡被復(fù)制而可能導(dǎo)致的App應(yīng)用的安全漏洞或潛在危害，目前可行的辦法是通過升級App或者安全補(bǔ)丁的方式，從軟件層面及時(shí)彌補(bǔ)因使用復(fù)制的USIM所帶來的安全風(fēng)險(xiǎn)。在該背景下，本文通過對典型App的詳細(xì)分析和測試，指出哪些App在USIM被復(fù)制的情況下是存在安全問題的，從而給這些App的更新?lián)Q代和技術(shù)升級敲響警鐘。

本文針對移動(dòng)應(yīng)用身份認(rèn)證的一般流程總結(jié)了認(rèn)證的一般模型，重點(diǎn)分析了在復(fù)制USIM卡的環(huán)境中身份認(rèn)證策略可能存在的安全問題。在模擬USIM卡被攻擊者復(fù)制的環(huán)境下，本文研究了移動(dòng)終端平臺(tái)上的58款典型應(yīng)用的身份認(rèn)證環(huán)節(jié)，并進(jìn)行真機(jī)測試，重點(diǎn)觀察應(yīng)用登錄、重置密碼、執(zhí)行敏感操作的認(rèn)證流程，對應(yīng)用的登錄數(shù)據(jù)與跳轉(zhuǎn)流程展開分析，研究這些應(yīng)用在身份認(rèn)證過程中的請求響應(yīng)數(shù)據(jù)格式與代碼執(zhí)行過程，最后記錄了各類安全服務(wù)（如SMS驗(yàn)證碼）在復(fù)制USIM卡環(huán)境中的使用與表現(xiàn)。

測試結(jié)果發(fā)現(xiàn)在58款應(yīng)用中有29款的身份認(rèn)證服務(wù)在復(fù)制USIM卡的環(huán)境下可被直接繞過。其中有9款A(yù)pp在密碼重置和登錄時(shí)可被直接繞過，有10款A(yù)pp僅在密碼重置時(shí)可直接被繞過，剩余10款A(yù)pp僅在登錄時(shí)可直接被繞過。本文的測試結(jié)果表明，針對復(fù)制USIM卡攻擊而產(chǎn)生身份認(rèn)證問題的應(yīng)用而言，移動(dòng)App開發(fā)者與安全廠商應(yīng)當(dāng)至少采用兩步認(rèn)證等軟件防護(hù)手段才能避免USIM卡復(fù)制攻擊對移動(dòng)應(yīng)用帶來的安全風(fēng)險(xiǎn)。

2 移動(dòng)應(yīng)用的一般認(rèn)證流程

應(yīng)用在用戶執(zhí)行功能前需要驗(yàn)證其身份，而各類App提供的身份認(rèn)證接口通常存在于用戶登錄、用戶重置密碼、用戶執(zhí)行敏感操作，本節(jié)分析移動(dòng)應(yīng)用身份認(rèn)證的一般模式，并總結(jié)用戶身份的驗(yàn)證樹。

2.1 身份認(rèn)證的功能情景

用戶登錄認(rèn)證：當(dāng)用戶接入應(yīng)用時(shí)，App需要鑒別并認(rèn)證該用戶身份。用戶登錄通常要求填寫匹配的用戶名與口令。而常見的用戶名類型通常為用戶自定義字符串、用戶郵箱、用戶手機(jī)號等；口令與用戶名匹配后會(huì)允許當(dāng)前用戶登錄，一般的用戶登錄認(rèn)證流程如圖2所示。

用戶重置密碼認(rèn)證：實(shí)際中用戶忘記口令的行為時(shí)有發(fā)生，應(yīng)用也會(huì)提供找回密碼功能。用戶提供正確的用戶名后，需結(jié)合其他信息驗(yàn)證用戶名的真實(shí)性。用戶名類型決定了重置密碼時(shí)認(rèn)證身份的流程。使用郵箱地址或手機(jī)號作為用戶名時(shí)，應(yīng)用會(huì)發(fā)送驗(yàn)證郵件或短信驗(yàn)證碼，只有用戶接收到驗(yàn)證信息并執(zhí)行對應(yīng)操作后才會(huì)允許重置口令，部分應(yīng)用還會(huì)采取兩步驗(yàn)證等手段。重置密碼認(rèn)證流程如圖3所示。

圖2 App用戶登錄認(rèn)證

Figure 2 Procedure of authentication for App users logging in

圖3 App用戶重置密碼認(rèn)證流程

Figure 3 Procedure of authentication for App users resetting passwords

電子郵箱與手機(jī)作為日常生活的重要組成部分，私人郵箱信件與短信驗(yàn)證碼通常為個(gè)人所有，因此應(yīng)用廠商將其作為身份認(rèn)證的必要信息是合理的，但部分應(yīng)用未采取額外驗(yàn)證手段確保當(dāng)前用戶身份的正確性，僅保證驗(yàn)證手段的必要性。一旦外部攻擊者設(shè)法提供正確的驗(yàn)證信息，同樣可重置密碼，擁有原用戶的操作權(quán)限，達(dá)成攻擊目的。

用戶執(zhí)行敏感操作認(rèn)證：用戶登錄后若執(zhí)行某些敏感操作，如轉(zhuǎn)賬或查看操作歷史，某些應(yīng)用會(huì)要求用戶進(jìn)行額外認(rèn)證，通常為要求用戶輸入PIN碼、短信驗(yàn)證碼或生物驗(yàn)證等。用戶執(zhí)行敏感操作認(rèn)證的流程如圖4所示。

這一措施可更好地保護(hù)業(yè)務(wù)核心數(shù)據(jù)，個(gè)人金融類App涉及銀行業(yè)務(wù)時(shí)往往建議用戶開啟操作認(rèn)證，保護(hù)個(gè)人財(cái)產(chǎn)安全。

2.2 應(yīng)用的用戶身份驗(yàn)證樹

根據(jù)應(yīng)用中3種常見身份驗(yàn)證流程，本文可總結(jié)移動(dòng)應(yīng)用中常見的用戶身份驗(yàn)證樹，如圖5所示。

圖4 App用戶執(zhí)行敏感操作認(rèn)證流程

Figure 4 Procedure of authentication for App users performing sensitive tasks

圖5 App用戶身份驗(yàn)證樹

Figure 5 Tree model of authentication process in mobile application

在驗(yàn)證過程中，為實(shí)現(xiàn)登錄應(yīng)用，攻擊者可針對用戶登錄認(rèn)證與重置密碼認(rèn)證實(shí)施攻擊。用戶登錄認(rèn)證過程中，可利用應(yīng)用潛在的邏輯漏洞發(fā)起攻擊；而在重置密碼過程中，所涉及的認(rèn)證方式較多，這也導(dǎo)致攻擊者擁有更多攻擊發(fā)起點(diǎn)，如針對USIM卡的SMS驗(yàn)證碼安全、郵件安全等攻擊手段。同時(shí)，由于存在部分應(yīng)用未開發(fā)重置密碼時(shí)的二次驗(yàn)證流程，攻擊者面臨的攻擊難度進(jìn)一步降低。如圖5所示，一旦攻擊者成功登錄應(yīng)用，且該應(yīng)用未對敏感操作實(shí)施再次驗(yàn)證，則攻擊者能夠獲取應(yīng)用權(quán)限，竊取用戶信息。

3 移動(dòng)終端平臺(tái)的應(yīng)用測試

本節(jié)采取實(shí)地測試的方法，考察不同應(yīng)用在認(rèn)證過程中的行為表現(xiàn)，并對移動(dòng)應(yīng)用的常見測試類型以及測試技術(shù)等進(jìn)行介紹。

3.1 移動(dòng)應(yīng)用的測試分析技術(shù)

常見測試類型：移動(dòng)應(yīng)用的各類測試有助于提高軟件質(zhì)量，以保證軟件版本的長期穩(wěn)定迭代。移動(dòng)應(yīng)用的測試方法在測試目標(biāo)和測試方法上的主要分類結(jié)果如圖6所示。

圖6 移動(dòng)應(yīng)用測試分類

Figure 6 Classification of mobile applications

其中，功能測試考察應(yīng)用的基本服務(wù)、用戶交互以及靈活性。安全測試、流量測試、耗電量測試等近年來成為必要的測試環(huán)節(jié)[18]。自動(dòng)化測試常使用基于黑盒（白盒）的自動(dòng)化框架，對產(chǎn)品的模塊單元進(jìn)行動(dòng)態(tài)或靜態(tài)的分析。為適應(yīng)產(chǎn)品的快速發(fā)展與迭代，廠商大多采取自動(dòng)或半自動(dòng)化的測試方法。

測試分析技術(shù)：文獻(xiàn)[19-20]中的GUI自動(dòng)化框架API為移動(dòng)平臺(tái)的基礎(chǔ)系統(tǒng)功能提供了通用接口，作為其他測試功能的基礎(chǔ)。測試人員通過這些API編寫腳本，利用斷言語句測試狀態(tài)信息。基于記錄重放（R＆R）的測試方案如“Reran”[21]、“Versatile”[22]等或可替代手動(dòng)編寫測試腳本，而且這類方法可提供細(xì)粒度的捕獲和重放。而輸入自動(dòng)生成（AIG）技術(shù)[23]自動(dòng)化了測試用例的生成過程，可提高代碼覆蓋率，檢測更多錯(cuò)誤，減少測試方案規(guī)模。此外，還有錯(cuò)誤異常的報(bào)告工具[24]、設(shè)備流測試工具等[25]。

典型應(yīng)用的行為測試：Wang等[26]研究了移動(dòng)應(yīng)用中常見的單次登錄（SSO，single sign-on）模型的安全性，對瀏覽器中繼消息（BRM，browser relayed messages）的字段與傳遞過程進(jìn)行黑盒測試與溯源。作者對Google、Facebook等應(yīng)用測試后發(fā)現(xiàn)，攻擊者可控制Google中的openid.ext1. required等字段實(shí)現(xiàn)身份冒用。攻擊者也能替換Facebook中BRM的部分字段來欺騙服務(wù)端進(jìn)行授權(quán)。Gan等[27]則從內(nèi)容、社交、娛樂的角度對微信與微博用戶行為的頻率和類型對比分析，指出微信能給用戶提供更高等級的保密以及應(yīng)用控制。Dmitrienko等[28]對Google Authenticator等主流驗(yàn)證工具的OTP進(jìn)行了統(tǒng)計(jì)分析，試圖從數(shù)值分布上尋找OTP生成算法的規(guī)律，還指出幾種實(shí)際中2FA驗(yàn)證框架的可能缺陷以及利用手段。

以上研究者對幾款典型應(yīng)用在傳統(tǒng)測試環(huán)境中的數(shù)據(jù)交互流程與交互策略進(jìn)行了分析，而這些應(yīng)用均未在復(fù)制USIM卡的環(huán)境中進(jìn)行測試與研究。本文彌補(bǔ)這一缺陷，提出在該環(huán)境下對各類App的行為與流程進(jìn)行測試，從而給出這些應(yīng)用的身份認(rèn)證中的安全問題和缺陷，并給出解決思路。

3.2 典型應(yīng)用的身份認(rèn)證流程測試

本節(jié)在攻擊者已擁有復(fù)制USIM卡環(huán)境下，研究并測試USIM設(shè)備中App的身份認(rèn)證問題，通過執(zhí)行不同App的身份認(rèn)證樹，分析身份認(rèn)證流程跳轉(zhuǎn)過程中的數(shù)據(jù)請求與響應(yīng)結(jié)果，觀察并記錄App的行為，分析可能被攻擊者繞過的環(huán)節(jié)。

表1 測試應(yīng)用組成

3.2.1 測試條件

測試對象：應(yīng)用所含信息價(jià)值是影響攻擊者選取攻擊對象的主要因素之一，本測試選取更易被攻擊者針對的應(yīng)用，這些應(yīng)用通常占據(jù)主流市場，能對大量用戶的個(gè)人生活產(chǎn)生深刻影響。根據(jù)移動(dòng)數(shù)據(jù)分析領(lǐng)域著名企業(yè)App Annie[29]與市場權(quán)威調(diào)研機(jī)構(gòu)Statista[30]的App數(shù)據(jù)統(tǒng)計(jì)結(jié)果，Business of Apps與Buildfire分別發(fā)布了2019年App下載與使用報(bào)告[3-4]，報(bào)告指出，就App下載數(shù)、使用程度和卸載數(shù)而言，社交通信類、視頻類、外賣類、金融支付類以及游戲類等是移動(dòng)應(yīng)用市場中重要的幾種應(yīng)用。結(jié)合專業(yè)互聯(lián)網(wǎng)產(chǎn)業(yè)研究公司iResearch的App指數(shù)分析[31]以及國內(nèi)移動(dòng)大數(shù)據(jù)服務(wù)商QuestMobile發(fā)布的2019年移動(dòng)App增長報(bào)告[32]可以看出，短視頻、綜合電商、移動(dòng)支付等應(yīng)用發(fā)展迅猛。這些應(yīng)用的用戶黏度高，與用戶生活結(jié)合緊密，可接觸到個(gè)人隱私等數(shù)據(jù)，會(huì)受到攻擊者的研究與針對，而這些應(yīng)用的潛在安全漏洞也將導(dǎo)致較為嚴(yán)重的數(shù)據(jù)泄露事件。因此，為提高測試結(jié)果的代表性，結(jié)合上述App分析數(shù)據(jù)，本文對社交通信類、金融支付類、出行外賣類、健康醫(yī)療類、文件云盤類、娛樂視頻類和信息檢索類共7類應(yīng)用展開測試，每類應(yīng)用依照下載量與使用量排名選取共58款典型應(yīng)用，詳情如表1所示。

以上58款應(yīng)用能接觸到用戶的通信交流內(nèi)容、財(cái)產(chǎn)狀況、地理位置與出行軌跡、生理健康狀況、私人文件以及檢索信息。這些信息與用戶隱私直接相關(guān)，這些信息的泄露會(huì)危害用戶數(shù)據(jù)安全，造成嚴(yán)重的個(gè)人信息安全風(fēng)險(xiǎn)，一旦這些應(yīng)用無法保證用戶身份驗(yàn)證的安全性，則會(huì)對用戶生活造成較大的潛在威脅。

測試環(huán)境：本文所采取的測試機(jī)型信息如表2所示。

Apple iOS與Google Android為移動(dòng)設(shè)備系統(tǒng)的主要類型，除iCloud所代表的Apple驗(yàn)證機(jī)制，其余57款應(yīng)用在iOS與Android上具備相同的認(rèn)證流程。因此，本次測試所用設(shè)備對58款應(yīng)用的測試結(jié)果與結(jié)論符合不同測試系統(tǒng)下的測試結(jié)果。基于以上測試條件，在測試前需給出以下前提。

表2 測試機(jī)型信息

1) 復(fù)制后的USIM卡與原USIM卡在收發(fā)消息時(shí)對基站而言是相同的。

2) 目標(biāo)用戶的用戶名與USIM卡的手機(jī)號是易獲取的。

根據(jù)如上測試條件，可提出測試的一般方法。

3.2.2 測試方法

本節(jié)根據(jù)移動(dòng)應(yīng)用的驗(yàn)證樹進(jìn)行真機(jī)測試，下載各應(yīng)用后使用目標(biāo)手機(jī)號或郵箱進(jìn)行注冊，完成新用戶的一般注冊過程。之后退出登錄模擬攻擊者行為，在登錄頁面測試重置密碼功能，關(guān)注不同步驟的響應(yīng)結(jié)果及需要SMS驗(yàn)證碼的環(huán)節(jié)，記錄應(yīng)用在密碼重置及其他環(huán)節(jié)是否可繞過。在測試過程中使用Stream抓取App登錄過程中的Http/Https數(shù)據(jù)請求與響應(yīng)，分析數(shù)據(jù)包字段與控制方法，結(jié)合App實(shí)際行為表現(xiàn)給出測試結(jié)果。測試基本流程如圖7所示。

圖7 一般測試流程

Figure 7 General procedure of authentication test

其他測試要求如下。

1) 對于可使用手機(jī)號或郵箱注冊登錄的應(yīng)用而言，優(yōu)先使用手機(jī)注冊登錄。

2) 對于使用SSO服務(wù)的應(yīng)用而言，其認(rèn)證邏輯與身份提供方（IdP，identity provider）相同，優(yōu)先選擇不使用SSO服務(wù)進(jìn)行測試。

3) 對于默認(rèn)不開啟二次驗(yàn)證的應(yīng)用而言，保持原始設(shè)置進(jìn)行測試。若應(yīng)用強(qiáng)制開啟兩步驗(yàn)證，測試時(shí)不關(guān)閉該功能。

本文選取“是否需要短信驗(yàn)證碼”“是否需要密保信息”“是否需要郵箱驗(yàn)證”“是否對當(dāng)前設(shè)備進(jìn)行驗(yàn)證”作為密碼重置過程中的測試指標(biāo)。結(jié)合測試過程中應(yīng)用的Http/Https數(shù)據(jù)字段以及頁面代碼中的控制函數(shù)，如果用戶僅需短信驗(yàn)證碼且無須設(shè)備環(huán)境驗(yàn)證就能完成密碼重置，則可認(rèn)為攻擊者在復(fù)制USIM卡環(huán)境下是可以直接繞過應(yīng)用的身份驗(yàn)證環(huán)節(jié)，即該應(yīng)用是不安全的。

3.3 典型應(yīng)用身份認(rèn)證中的數(shù)據(jù)分析

在測試過程中，本文對應(yīng)用的請求數(shù)據(jù)與響應(yīng)結(jié)果進(jìn)行捕獲和分析，本節(jié)以微信與支付寶這兩款典型應(yīng)用為例，分析其重置密碼過程中請求與響應(yīng)數(shù)據(jù)的格式與跳轉(zhuǎn)流程，并結(jié)合應(yīng)用行為，給出二者在復(fù)制USIM環(huán)境下的測試結(jié)果。

3.3.1 微信登錄中的數(shù)據(jù)捕獲與分析

根據(jù)3.2.2節(jié)中的要求，本節(jié)需測試微信（WeChat）找回密碼時(shí)認(rèn)證流程，由于微信可直接使用手機(jī)號碼與短信驗(yàn)證碼完成登錄，因此在用戶選擇“找回密碼”功能時(shí)，微信會(huì)令用戶嘗試使用手機(jī)號直接登錄。在此過程中，利用Stream 1.0.4 捕獲并分析Http網(wǎng)絡(luò)流量。微信登錄過程中的主要請求數(shù)據(jù)如表3所示。

表3 登錄微信時(shí)的部分Https數(shù)據(jù)請求

對服務(wù)端響應(yīng)數(shù)據(jù)解析后可知，以上3個(gè)請求數(shù)據(jù)依次對應(yīng)客戶端找回密碼時(shí)“請求找回密碼”“請求手機(jī)驗(yàn)證碼登錄”“請求登錄應(yīng)用”的3個(gè)階段，以下結(jié)合請求中的關(guān)鍵字段與響應(yīng)頁面的代碼執(zhí)行過程對微信登錄階段的身份認(rèn)證流程展開說明。

請求找回密碼：當(dāng)用戶在微信登錄頁面申請找回密碼時(shí)，客戶端會(huì)向support.weixin.qq.com發(fā)起請求，通過GET方法將查詢字段t、lang、rid傳遞給服務(wù)器驗(yàn)證身份，3個(gè)字段分別表明要請求頁面的URL、客戶端語言類型以及客戶端身份標(biāo)識(shí)。驗(yàn)證通過后，服務(wù)器進(jìn)行響應(yīng)，客戶端跳轉(zhuǎn)至找回密碼的提示信息頁面。此時(shí)微信會(huì)提示用戶進(jìn)行手機(jī)登錄。響應(yīng)數(shù)據(jù)中包括該頁面的控制代碼，選取“能接收短信”的功能按鈕，對應(yīng)代碼中的ican函數(shù)將實(shí)現(xiàn)下一頁面的跳轉(zhuǎn)，如圖8所示。在下一頁面中確認(rèn)后，則由go函數(shù)構(gòu)造手機(jī)驗(yàn)證碼登錄應(yīng)用的請求。

請求手機(jī)驗(yàn)證碼登錄：當(dāng)用戶可用短信驗(yàn)證碼登錄時(shí)，根據(jù)提示將跳轉(zhuǎn)至使用SMS驗(yàn)證碼登錄頁面，頁面前端代碼如圖9所示。其中，go函數(shù)將1與2字段置1，并將rid賦給p10字段，以上字段拼接并作為reportData數(shù)據(jù)，該數(shù)據(jù)作為登錄請求的一部分在下一階段傳遞給服務(wù)器。而在此階段，客戶端將會(huì)構(gòu)造一ap_msg字段，包含當(dāng)前設(shè)備的網(wǎng)絡(luò)環(huán)境與系統(tǒng)參數(shù)等信息，并以GET方法請求服務(wù)端發(fā)送驗(yàn)證碼登錄頁面。

請求登錄應(yīng)用：當(dāng)用戶使用短信驗(yàn)證碼登錄時(shí)中需輸入6位SMS驗(yàn)證碼，客戶端認(rèn)證通過后，reportFunc函數(shù)利用Javascript的Image對象的特性，通過更改對象的源鏈接屬性實(shí)現(xiàn)對服務(wù)器資源的靜態(tài)訪問。最終，消息中的reportData字段可告知服務(wù)端用戶的身份以及使用何種方式登錄應(yīng)用，用GET方法發(fā)送給服務(wù)端完成登錄，該部分的Https數(shù)據(jù)請求與響應(yīng)如圖10所示。

綜上，在微信找回密碼與登錄過程中，客戶端通過scan與go等函數(shù)實(shí)現(xiàn)了根據(jù)用戶已有身份憑證完成應(yīng)用身份認(rèn)證的過程。在客戶端，當(dāng)攻擊者在重置密碼環(huán)節(jié)選取用短信驗(yàn)證碼登錄應(yīng)用時(shí)，可使用復(fù)制USIM卡直接獲取短信驗(yàn)證碼完成登錄。

圖8 找回密碼界面的部分html語句與ican函數(shù)

Figure 8 An html and javascript code segment for retrieving password and ican function

圖9 確認(rèn)請求的部分html語句和go函數(shù)

Figure 9 An html and javascript code segment for confirming requests and go function

圖10 請求登錄應(yīng)用的Https數(shù)據(jù)請求（上）與響應(yīng)（下）

Figure 10 Captured raw data of Https request (top) and response (bottom) when successfully logging into WeChat

3.3.2 支付寶重置密碼中的數(shù)據(jù)分析

使用與3.3.1節(jié)中相同的方法分析支付寶（AliPay）的重置密碼過程分析。在登錄支付寶賬號時(shí)，本文選取重置密碼而非SMS驗(yàn)證碼登錄。使用Stream捕獲支付寶找回密碼中的Https數(shù)據(jù)，主要請求如表4所示。

以上請求數(shù)據(jù)包分別對應(yīng)客戶端請求找回密碼、發(fā)送SMS驗(yàn)證碼、發(fā)送重置密碼。而在支付寶重置密碼時(shí)，客戶端會(huì)向loggw.alipay.com的主機(jī)反復(fù)發(fā)送包含有手機(jī)型號、網(wǎng)絡(luò)環(huán)境、運(yùn)營商類型等設(shè)備環(huán)境參數(shù)的數(shù)據(jù)，并由服務(wù)端返回的狀態(tài)碼判定當(dāng)前設(shè)備是否能繼續(xù)下一步操作。由于該環(huán)節(jié)Https流量數(shù)據(jù)較多，下面僅對表4中的3個(gè)請求響應(yīng)過程展開說明。

請求找回密碼：當(dāng)使用找回密碼功能時(shí)，客戶端以GET方法將用戶服務(wù)類型、臨時(shí)Token、應(yīng)用版本等字段傳遞給域名為clientsc.alipay.com的服務(wù)器。服務(wù)器端則會(huì)返回包含頁面控制代碼的響應(yīng)頁面供用戶選擇找回密碼的方式。與微信類似，支付寶也是通過javascript代碼來控制用戶找回密碼的身份認(rèn)證流程，如圖11所示。用戶輸入手機(jī)號并確認(rèn)可收到SMS驗(yàn)證碼后，會(huì)由anima-yocto觸發(fā)canGetAckCode并告知用戶驗(yàn)證碼已發(fā)送。

當(dāng)用戶獲知服務(wù)端發(fā)送驗(yàn)證碼后，客戶端將顯示p_validateMobile頁面提示用戶輸入驗(yàn)證碼，并由支付寶客戶端構(gòu)造新的請求數(shù)據(jù)，如圖12所示。

表4 支付寶找回密碼時(shí)的部分Https數(shù)據(jù)請求

接收并輸入SMS驗(yàn)證碼：當(dāng)用戶收到驗(yàn)證碼后，在p_validateMobile頁可以輸入4位短信驗(yàn)證碼。與微信不同之處在于支付寶的SMS驗(yàn)證碼值將被包含在請求數(shù)據(jù)中由服務(wù)端進(jìn)行檢查。故此處客戶端調(diào)用sendAckCode方法完成傳輸預(yù)認(rèn)證，再調(diào)用checkAckCode方法將輸入的驗(yàn)證碼作為ackcode字段值，并以明文POST的方法向clientsc.alipay.com主機(jī)中的checkAckCode.json資源發(fā)起請求，由服務(wù)器檢查ackcode的正確性。當(dāng)驗(yàn)證碼輸入正確，服務(wù)端的響應(yīng)字段stat被置為“ok”后，客戶端由checkAckCode方法請求服務(wù)端發(fā)送重置密碼頁面。

圖11 找回密碼提示頁面的部分html語句和yocto觸發(fā)操作

Figure 11 A code segment for retrieving password and yocto operation

圖12 客戶端發(fā)送驗(yàn)證碼的HTTPS數(shù)據(jù)請求（上）與響應(yīng)（下）

Figure 12 Captured raw data of https request (top) and response (bottom) when send authentication code in Alipay client

發(fā)送重置密碼：重置密碼頁的前端代碼如圖13所示。當(dāng)客戶端提示用戶輸入新密碼時(shí)，由yocto捕捉頁面的newPassword字段，并觸發(fā)saveNewQueryPwdBtnClickCb與reset QueryPwd方法實(shí)現(xiàn)新密碼的重置與發(fā)送。后者將用戶新密碼封裝到請求數(shù)據(jù)中的newPassword字段，并以POST方法請求clientsc.alipay.com中的resetQueryPwd.json資源確認(rèn)新密碼。當(dāng)服務(wù)端的響應(yīng)字段stat被置為“ok”后，客戶端將跳轉(zhuǎn)至支付寶應(yīng)用界面，完成密碼重置。

綜上，在客戶端發(fā)送收到的SMS驗(yàn)證碼以及重置密碼過程中，支付寶客戶端均先請求特定的安全服務(wù)包括Google的URL檢查服務(wù)safebrowsing和loggw.alipay.com中的設(shè)備環(huán)境驗(yàn)證服務(wù)。因此，在復(fù)制USIM卡環(huán)境下，攻擊者無法繞過服務(wù)端對用戶終端設(shè)備參數(shù)環(huán)境的檢查與驗(yàn)證環(huán)節(jié)，則僅使用手機(jī)號碼與SMS驗(yàn)證碼實(shí)現(xiàn)口令重置是困難的。

圖13 resetQueryPwd的封裝部分與服務(wù)器響應(yīng)主體

Figure 13 A glance of resetQueryPwd function and response body

4 典型應(yīng)用的身份認(rèn)證測試結(jié)果與分析

根據(jù)第3節(jié)中的測試要求與測試方法，通過對測試應(yīng)用的登錄與找回密碼等身份認(rèn)證功能的流程觀察與記錄，本節(jié)給出測試結(jié)果與分析。

4.1 測試結(jié)果概述

根據(jù)記錄，在重置密碼時(shí)，測試用的58款應(yīng)用有19款可直接通過短信驗(yàn)證碼重置密碼完成登錄，其余39款由于額外要求的密保信息、郵箱驗(yàn)證以及設(shè)備驗(yàn)證等手段使攻擊者無法繞過。

如圖14所示，在這39款應(yīng)用中，有18款不可被繞過是因?yàn)樵搼?yīng)用僅提供郵箱驗(yàn)證而未提供短信驗(yàn)證功能。除Apple旗下的App store以及icloud，其他測試應(yīng)用的驗(yàn)證手段均為短信驗(yàn)證或郵箱驗(yàn)證。在21款執(zhí)行二次驗(yàn)證的應(yīng)用中4款采取了額外的密保信息，4款采取了額外的郵箱驗(yàn)證，13款應(yīng)用會(huì)對當(dāng)前設(shè)備環(huán)境進(jìn)行檢測，提醒或警告原登錄用戶當(dāng)前攻擊者的行為，防止攻擊者直接繞過。這21款應(yīng)用中部分應(yīng)用同時(shí)借助了多種驗(yàn)證手段確保產(chǎn)品安全。密碼重置時(shí)無法被繞過的39款應(yīng)用測試指標(biāo)關(guān)系如圖15所示。

圖14 測試結(jié)果組成

Figure 14 Overall experimental results

圖15 不可繞過應(yīng)用的測試項(xiàng)目關(guān)系

Figure 15 Relations of Apps whose authentication process can not be bypassed

測試還發(fā)現(xiàn)，當(dāng)攻擊者可獲取發(fā)往用戶設(shè)備的SMS驗(yàn)證碼時(shí)，有9款應(yīng)用在密碼重置和正常登錄時(shí)均可被繞過，有10款應(yīng)用僅在密碼重置時(shí)易被繞過，有另外10款應(yīng)用僅在正常登錄時(shí)可被繞過，如圖16所示。

圖16 被繞過結(jié)果關(guān)系

Figure 16 Relations of Apps whose authentication process can be directly bypassed

其中，各指標(biāo)所包含應(yīng)用名稱如表5所示。

當(dāng)額外采取至少一種驗(yàn)證手段時(shí)，攻擊者很難竊取用戶信息。但正常登錄時(shí)攻擊者可利用用戶手機(jī)號進(jìn)行登錄，這使各應(yīng)用默認(rèn)當(dāng)前異地登錄者為原合法用戶，從而不進(jìn)行額外驗(yàn)證。

4.2 應(yīng)用分類與指標(biāo)測試結(jié)果

對于各測試指標(biāo)而言，有38款應(yīng)用提供了短信驗(yàn)證重置密碼的接口，僅有4款應(yīng)用要求用戶提供密保信息，如歷史訂單、購買過的產(chǎn)品名稱等。對于郵箱驗(yàn)證，有4款應(yīng)用在要求短信驗(yàn)證的情況下仍需要額外的郵箱驗(yàn)證，而有22款則僅需要郵箱驗(yàn)證，還有16款應(yīng)用會(huì)進(jìn)行新登錄設(shè)備的環(huán)境檢測等。

如圖17(b)所示，對于測試的7類應(yīng)用而言，金融類應(yīng)用被直接繞過的比例最少，僅為20%。而在社交類、健康類以及娛樂類共20款應(yīng)用中，有11款可被繞過。在全球移動(dòng)應(yīng)用市場中，直接涉及用戶個(gè)人財(cái)產(chǎn)安全的應(yīng)用具有相對安全的保護(hù)措施，而提供娛樂消遣以及個(gè)人健康信息等間接涉及用戶隱私的應(yīng)用仍具有較簡單的身份認(rèn)證策略，易被攻擊者繞過。

表5 可繞過應(yīng)用組成

圖17 應(yīng)用測試指標(biāo)結(jié)果

Figure 17 Detailed results under different authentication requirements and App categories

4.3 測試結(jié)果分析與研究

本節(jié)結(jié)合測試結(jié)果，從應(yīng)用流程的特點(diǎn)、應(yīng)用類型與認(rèn)證流程的關(guān)系等角度對移動(dòng)應(yīng)用的身份認(rèn)證流程現(xiàn)狀以及特點(diǎn)進(jìn)行分析。

4.3.1 國內(nèi)外SMS驗(yàn)證服務(wù)的差異

在測試過程中注意到大多數(shù)中國區(qū)應(yīng)用實(shí)現(xiàn)了該服務(wù)入口，而較多國外應(yīng)用僅使用郵箱及用戶名進(jìn)行認(rèn)證。進(jìn)一步分析發(fā)現(xiàn)，國內(nèi)的17款應(yīng)用全部提供了短信驗(yàn)證重置密碼服務(wù)，有6款被認(rèn)定為可直接繞過，而國外應(yīng)用中有21款提供了短信驗(yàn)證，13款可被繞過，如圖18所示。

移動(dòng)互聯(lián)網(wǎng)企業(yè)與相關(guān)部門大規(guī)模推行SMS驗(yàn)證碼服務(wù)的原因不僅在于短信驗(yàn)證碼的成本低、操作難度小，更在于實(shí)現(xiàn)對移動(dòng)應(yīng)用的有效監(jiān)管。測試還發(fā)現(xiàn)，國外的App并未強(qiáng)制要求綁定手機(jī)號，甚至少部分App無手機(jī)號注冊入口。

圖18 國內(nèi)外應(yīng)用對比

Figure 18 Comparsion between domestic and foreign Apps

4.3.2 密保信息的缺失

對于各指標(biāo)的測試結(jié)果而言，僅有6.9%的應(yīng)用使用密保信息作為第二步驗(yàn)證手段。對于不同類型的密保信息而言，獨(dú)有性過高可能增大用戶的操作難度，而獨(dú)有性較低則會(huì)在各類社會(huì)工程學(xué)手段面前顯得十分脆弱。

圖19(a)表明應(yīng)用所要求的密保信息為用戶以往訂單中隨機(jī)一條商家單號的后四位，該操作對于不經(jīng)常使用移動(dòng)智能手機(jī)的用戶而言有一定難度。而圖19(b)應(yīng)用則要求填寫歷史訂單中任意一位收貨人姓名，而該信息易被各種釣魚及檢索手段泄露。因此，用戶操作難度低，但獨(dú)有性高的密保信息的設(shè)計(jì)應(yīng)成為未來App用戶身份驗(yàn)證體系應(yīng)用中需要考慮的問題。

圖19 兩測試用App密保信息界面

Figure 19 Front page of “Password Proection Information Query” in two testing Apps

4.3.3 應(yīng)用信息類型的價(jià)值差異

對于不同種類應(yīng)用而言，具有較低的繞過比例僅說明在復(fù)制USIM卡環(huán)境下有較好的安全表現(xiàn)，但無法說明其在保護(hù)用戶信息上具有較強(qiáng)的防護(hù)程度。較多零售類以及少部分支付類應(yīng)用在注冊時(shí)并不需要額外的身份綁定，而且二次驗(yàn)證功能非強(qiáng)制開啟?？梢哉J(rèn)為，在用戶和移動(dòng)互聯(lián)網(wǎng)企業(yè)的信息價(jià)值評價(jià)體系中，與個(gè)人在線資產(chǎn)（如所有財(cái)產(chǎn)、云文件等）相比，個(gè)人興趣愛好、健康狀況以及社交內(nèi)容體現(xiàn)出的敏感程度不高，使娛樂、健康醫(yī)療、社交這類應(yīng)用所擁有較單一的驗(yàn)證手段，從而導(dǎo)致這3類應(yīng)用有較高的可繞過比例。

4.3.4 設(shè)備驗(yàn)證手段的完善

測試發(fā)現(xiàn)，重置密碼時(shí)有27.6%的應(yīng)用會(huì)對用戶的設(shè)備型號、所處環(huán)境進(jìn)行檢測，如對當(dāng)前網(wǎng)絡(luò)IP地址、地理位置、機(jī)器的硬件參數(shù)等進(jìn)行抓取，通過與原設(shè)備常用登錄信息比對等識(shí)別當(dāng)前試圖登錄的用戶或提醒原設(shè)備用戶。

目前對新設(shè)備驗(yàn)證的手段主要有短信驗(yàn)證、設(shè)備檢測及環(huán)境檢測這3種。

設(shè)備檢測環(huán)節(jié)則是Google等應(yīng)用檢測到新設(shè)備登錄時(shí)采取的兩步驗(yàn)證手段之一。當(dāng)攻擊者試圖在某設(shè)備重置密碼時(shí)，原設(shè)備登錄的應(yīng)用會(huì)提示用戶是否允許該操作的發(fā)生。只有用戶在原設(shè)備賬戶中完成認(rèn)證，才能實(shí)現(xiàn)其他設(shè)備重置密碼的請求。例如，當(dāng)攻擊者試圖在某設(shè)備對目標(biāo)Apple ID進(jìn)行重置密碼操作時(shí)，Apple要求該ID登錄其他設(shè)備先行驗(yàn)證。此舉可以有效防止攻擊者利用復(fù)制的USIM卡登錄應(yīng)用。

5 結(jié)束語

本文主要研究移動(dòng)應(yīng)用的身份認(rèn)證問題，首先介紹移動(dòng)應(yīng)用的認(rèn)證流程并總結(jié)移動(dòng)應(yīng)用的一般驗(yàn)證樹，以指明身份認(rèn)證策略中存在問題的環(huán)節(jié)；然后在各類移動(dòng)應(yīng)用認(rèn)證用戶身份時(shí)，登錄應(yīng)用、重置密碼以及執(zhí)行敏感操作涉及的認(rèn)證方式可能不同，而SMS驗(yàn)證碼以及郵件驗(yàn)證等方式則廣泛應(yīng)用于重置密碼以及登錄認(rèn)證的過程。USIM卡復(fù)制攻擊使攻擊者獲取發(fā)往原用戶設(shè)備的SMS驗(yàn)證碼成為可能，從而能以驗(yàn)證樹中重置密碼以及應(yīng)用登錄為攻擊起點(diǎn)，繞過認(rèn)證登錄應(yīng)用后，竊取用戶信息。

本文采用真機(jī)測試，模擬攻擊者成功實(shí)施USIM卡復(fù)制攻擊后各類應(yīng)用的密碼重置與登錄認(rèn)證的安全缺陷。分析身份認(rèn)證過程中的Https流量數(shù)據(jù)并結(jié)合應(yīng)用行為后發(fā)現(xiàn)，在58款應(yīng)用中共有29款面臨可被復(fù)制USIM卡直接繞過的安全風(fēng)險(xiǎn)，其中有9款應(yīng)用在密碼重置和登錄時(shí)可被直接繞過，有10款應(yīng)用僅在密碼重置時(shí)可直接被繞過，剩余10款應(yīng)用僅在登錄時(shí)可直接被繞過。其中，社交通信類以及娛樂類應(yīng)用最易被繞過。移動(dòng)應(yīng)用開發(fā)者與安全人員應(yīng)對當(dāng)前產(chǎn)品的認(rèn)證邏輯進(jìn)行完善與改進(jìn)，采用兩步認(rèn)證或雙因子認(rèn)證等手段防御USIM卡復(fù)制攻擊，實(shí)現(xiàn)用戶數(shù)據(jù)安全防護(hù)手段的有效部署。

致謝：

本文工作得到了上海交通大學(xué)螞蟻金服安全科技聯(lián)合研究中心和上海交通大學(xué)智巡密碼安全測評聯(lián)合實(shí)驗(yàn)室的支持，特此致謝。

[1] 3GPP specification:31.102. Characteristics of the Universal Subscriber Identity Module (USIM) application[S].

[2] 國家統(tǒng)計(jì)局. 電信業(yè)務(wù)統(tǒng)計(jì)數(shù)據(jù)[EB].

[3] DOGTIEV A. App download and usage statistics (2018), business of App (2018)[EB].

[4] BLAIR I. Mobile App download and usage statistics, BuildFire. [EB].

[5] LIU J R, YU Y, STANDAERT F, et al. Small tweaks do not help: differential power analysis of milenage implementations in 3G/4G USIM cards[C]//The 20th European Symposium on Computer Security. 2015: 468-480.

[6] BRIER E, CLAVIER C, OLIVIER F. Correlation power analysis with a leakage model[C]//Cryptographic Hardware and Embedded Systems. 2014: 16-29.

[7] 3GPP specication: 35.206. Specification of the MILENAGE algorithm set[S].

[8] ANWAR N, RIADI I, LUTHFI A. Analisis SIM card cloning terhadap algoritma random number Generator[J]. Buana Inform, 2016, 7(2): 143-150.

[9] SINGH J, RUHL R, LINDSKOG D, et al. GSM OTA SIM cloning attack and cloning resistance in EAP-SIM and USIM[C]//Proc Soc 2013: 1005-1010.

[10] RAO J R, ROHATGI P, SCHERZER H, et al. Partitioning attacks: or how to rapidly clone some GSM cards[C]//Proc IEEE Symp Secur Priv, 2002: 31-41.

[11] ZHANG C, LIU J R, GU D W, et al. Side-channel analysis for the authentication protocols of CDMA cellular networks[J]. J Comput Sci Technol, 2019: 1079-1095.

[12] 3GPP specication: 33.501. Security architecture and procedures for 5G System[S].

[13] BASIN D, RADOMIROVIC S, DREIER J, et al. A formal analysis of 5G authentication[C]//Proceedings of the ACM Conference on Computer and Communications Security. 2018: 1383-1396.

[14] LoCCS GoCE, 抱緊你的SIM卡—5G物理安全初探[EB]. LoCCS GoCE, hold your SIM card tight—a glance at 5G physical security[EB].

[15] KOOT L. Security of mobile TAN on smartphones a risk analysis for the iOS and Android smartphone platforms[D]. The Netherlands: Radboud University Nijmegen, 2012.

[16] DMITRIENKO A, LIEBCHEN C, ROSSOW C, et al. Security analysis of mobile two-factor authentication schemes[J] Intel Technol J, 2014: 138-161.

[17] ALECU B. SMS Fuzzing-SIM Toolkit attack[R]. 2013.

[18] KIM H K, YEO H, HWANG H J, et al. Effective mobile applications testing strategies[R]. 2016.

[19] Google. Esspresso testing android-framework, Github[EB].

[20] Apple. Apple ui-automation documentation, Apple[EB].

[21] GOMEZ L, NEAMTIU I, AZIM T, et al. Reran: timing-and touch-sensitive record and replay for android[C]//35th International Conference on Software Engineering (ICSE). 2013: 72-81.

[22] HU Y, AZIM T, NEAMTIU I. Versatile yet lightweight record-and-replay for android[C]//Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. 2015: 349-366.

[23] MACHIRY A, TAHILIANI R, NAIK M. Dynodroid: an input generation system for android Apps[C]//Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering. 2013: 224-234.

[24] Appsee. App mobile analytics platform[EB].

[25] OpenSTF. Smartphone test farm, Github[EB].

[26] WANG R, CHEN S, WANG X F. Signing me onto your accounts through facebook and google: a traffic-guided security study of commercially deployed single-sign-on web services[C]//2012 IEEE Symposium on Security and Privacy. 2012: 365-379.

[27] GAN C, WANG W. Uses and gratifications of social media: a comparison of microblog and WeChat[J]. Journal of Systems and Information Technology, 2015(4): 351-363.

[28] DMITRIENKO A, LIEBCHEN C, ROSSOW C, et al. On the (in) security of mobile two-factor authentication[C]//International Conference on Financial Cryptography and Data Security. 2014: 365-383.

[29] AppAnnie. The App analytics and App industry standard[EB].

[30] Statista. Global business data platform[EB].

[31] iresearch. App指數(shù)分析[EB]. Iresearch. App index Analysis[EB].

[32] QuestMobile. 2019移動(dòng)App半年增長報(bào)告[EB]. QuestMobile. Mobile App semi-annual growth report of 2019[EB].

Issues of identity verification of typical applications over mobile terminal platform

ZHANG Xiaolin1,2, GU Dawu1,2, ZHANG Chi1

1. School of Electronic Information and Electrical Engineering, Shanghai Jiaotong University, Shanghai 200240, China 2. School of Cyber Engineering, Xidian University, Xi’an 710126, China

Recent studies have shown that attacks against USIM card are increasing, and an attacker can use the cloned USIM card to bypass the identity verification process in some applications and thereby get the unauthorized access. Considering the USIM card being cloned easily even under 5G network, the identity verification process of the popular mobile applications over mobile platform was analyzed. The application behaviors were profiled while users were logging in, resetting password, and performing sensitive operations, thereby the tree model of application authentication was summarized. On this basis, 58 popular applications in 7 categories were tested including social communication, healthcare, etc. It found that 29 of them only need SMS verification codes to get authenticated and obtain permissions. To address this issue, two-step authentication was suggested and USIM anti-counterfeiting was applied to assist the authentication process.

mobile application, USIM cloning, SMS, authentication, mobile app testing

Security Protection Technology of Embedded Components and Control Units in Power System Terminal (2019GW?12)

TP311.1

A

10.11959/j.issn.2096?109x.2020081

張效林（1998–），男，山西臨汾人，上海交通大學(xué)碩士生，主要研究方向?yàn)樾畔踩c密碼學(xué)。

谷大武（1970– ），男，河南漯河人，博士，上海交通大學(xué)教授、博士生導(dǎo)師，主要研究方向?yàn)槊艽a學(xué)與系統(tǒng)安全。

張馳（1991– ），男，山西太原人，上海交通大學(xué)博士生，主要研究方向?yàn)橛布踩?、基于機(jī)器學(xué)習(xí)的側(cè)信道分析。

論文引用格式：張效林, 谷大武, 張馳. 移動(dòng)平臺(tái)典型應(yīng)用的身份認(rèn)證問題研究[J]. 網(wǎng)絡(luò)與信息安全學(xué)報(bào), 2020, 6(6): 137-151.

ZHANG X L, GU D W, ZHANG C. Issues of Identity Verification of Typical Applications over Mobile Terminal Platform[J]. Chinese Journal of Network and Information Security, 2020, 6(6): 137-151.

2020?02?28；

2020?07?03

谷大武dwgu@sjtu.edu.cn

國家電網(wǎng)有限公司總部科技項(xiàng)目（2019GW?12）