何峣，喬雅莉，戴國華，王朝暉

（中國電信股份有限公司廣州研究院，廣東 廣州 510630）

1 引言

隨著移動互聯(lián)網(wǎng)的迅速發(fā)展，智能手機高度普及，智能手機在為用戶帶來便捷體驗的同時，其存在的各種安全問題如隱私泄露、惡意騷擾、耗費流量、病毒感染等逐漸呈現(xiàn)。特別是在斯諾登事件、蘋果iCloud“艷照門”等事件曝光后，智能手機的安全問題已經(jīng)引起相關(guān)政府部門、運營商和終端廠商的高度重視。

2 關(guān)鍵安全技術(shù)分析及存在的問題

本文選取具有代表性的、占據(jù)主要市場份額的兩大智能手機操作系統(tǒng)Android和iOS進行分析探討。

2.1 數(shù)據(jù)保護

（1）Android的全盤加密

Android 3.0開始引入全盤加密（Full Disk Encryption，F(xiàn)DE），這是個很重要的安全特性，尤其是在解決設(shè)備丟失后的數(shù)據(jù)安全問題方面。

全盤加密使用的主密鑰是通過鎖屏密碼或設(shè)備PIN碼來保護的，保護機制如圖1所示。

系統(tǒng)首先使用/dev/urandom隨機數(shù)產(chǎn)生工具，產(chǎn)生基于硬件的128位FDE主密鑰，以及用于PBKDF2算法的128位鹽值；然后系統(tǒng)使用PBKDF2算法、密碼或PIN碼+鹽值，經(jīng)過多次哈希計算得到32字節(jié)長的用于AES（高級加密標準）加密的密鑰和IV向量，其中AES密鑰長128位，初始IV向量長128位；最后系統(tǒng)以128位的AES對稱加密算法的CBC（加密分組鏈接模式）模式，使用AES密鑰和初始IV向量對FDE主密鑰明文進行加密，得到128位的主密鑰密文。經(jīng)過上述處理，大大增加了利用彩虹表進行攻擊的難度。具體的加密過程是透明的，也就是說用戶無感知、應(yīng)用無感知，但存儲在FLASH上的數(shù)據(jù)是加密的。FDE并非真的全盤加密，只是加密用戶數(shù)據(jù)分區(qū)。

圖1 FDE主密鑰保護機制

從以上對FDE主密鑰的保護機制可見，保護全依賴于屏保密碼或設(shè)備PIN碼，是純軟件的保護方式，一旦密碼或PIN碼被攻破，F(xiàn)DE主密鑰就被暴露。

全盤加密的安全性和密碼/PIN碼的強度息息相關(guān)，如果設(shè)置成弱口令，則全盤加密的安全性會大打折扣。

由于加密后的密鑰、鹽值等數(shù)據(jù)都是明文存在的，可以通過多種手段獲取。如擁有Root權(quán)限的用戶，可通過ADB工具讀取所有文件；Hashcat工具在730M主頻的芯片下，每秒可獲得20 000個PBKDF2計算出來的哈希值，即不到10秒就可恢復一個6位純數(shù)字的密碼，4小時就可恢復6位小寫字母的密碼。

Android 4.4的改進：用scrypt算法取代PBKDF2，提升了破解難度。scrypt不僅所需計算時間長，而且占用的內(nèi)存也多，使得并行計算多個摘要異常困難，因此利用彩虹表進行暴力攻擊更加困難。

Android 5.0缺省開啟全盤加密，只加密存儲中已使用的塊，縮短了加密時間。ext4和f2fs的文件系統(tǒng)支持快速加密。采用強制加密機制，用戶無需自行開啟，初次啟動時使用臨時密碼對密鑰進行加密，用戶設(shè)置密碼后，只需要重新加密密鑰，而無需對數(shù)據(jù)重新加密。即使用戶不設(shè)置PIN碼也是加密狀態(tài)，而且支持基于硬件方案存儲密鑰，如TEE或SE（具體如2.3節(jié)所述）。

（2）iOS的文件加密

iOS 終端出廠時，在AP 芯片的Secure Enclave協(xié)處理器內(nèi)置了2個用于AES 256-bit加解密的密鑰，這2個密鑰分別是標識設(shè)備唯一的UID，標識AP芯片類型的GID，2個密鑰都無法通過JTAG（聯(lián)合測試工作組）接口或其它調(diào)試接口獲得，成為硬件密鑰。在FLASH存儲與RAM之間的DMA通道上，部署了專用的AES 256位密碼引擎，大幅提升了文件的加密效率。

如圖2所示，iOS對文件系統(tǒng)的加密方式是為每一個文件生成一個文件密鑰，文件密鑰對文件內(nèi)容進行加密。文件密鑰則被類型密鑰加密，密文放在文件頭信息中，文件頭信息被文件系統(tǒng)密鑰加密。文件系統(tǒng)密鑰由存于硬件中的硬件密鑰生成。每個文件根據(jù)不同的加密類型，分到不同的類型中，每個類型對應(yīng)配備一個類型密鑰，有些類型密鑰由硬件密鑰加密保護，有些則由鎖屏密碼加密保護。由此可見，iOS對文件系統(tǒng)的加密方式與Android最大的不同在于密鑰衍生的層次中，根密鑰不只是鎖屏密碼，而且還有由硬件保護的硬件密鑰，因此具備了較高的安全性。

圖2 iOS文件加密機制

2.2 權(quán)限策略

（1）增強安全Linux系統(tǒng)SELinux

Android系統(tǒng)權(quán)限主要由應(yīng)用層權(quán)限和Linux內(nèi)核的文件系統(tǒng)權(quán)限組成，APP應(yīng)用通過在AndroidManifest.xml文件中聲明申請應(yīng)用層權(quán)限，Linux文件權(quán)限則明確了系統(tǒng)內(nèi)每個文件的讀、寫、執(zhí)行、擁有者和分組的權(quán)限。Android系統(tǒng)寬松的開放性為其帶來高速的發(fā)展，但同時也暴露出各種安全問題，從Android 4.3版本開始，在內(nèi)核集成了SELinux，增強操作系統(tǒng)的安全性。

SELinux 提供了一種靈活的強制訪問控制（MAC）系統(tǒng)，且內(nèi)嵌于Linux Kernel中。SELinux定義了系統(tǒng)中每個用戶、進程、應(yīng)用和文件的訪問和轉(zhuǎn)變的權(quán)限，然后它使用一個安全策略來控制這些實體（用戶、進程、應(yīng)用和文件）之間的交互，安全策略指定如何嚴格或?qū)捤傻剡M行檢查。只有同時滿足了“標準Linux訪問控制”和“SELinux訪問控制”時，主體才能訪問客體。

在SELinux中，通過事先定義每個進程的允許操作，來禁止其進行越軌的操作。集成了SELinux的Android系統(tǒng)沿襲了這一機制，通過限制各進程的操作權(quán)限，可以防止惡意軟件篡改系統(tǒng)。一般來說，攻擊漏洞的惡意軟件為了長久利用篡奪到的Root權(quán)限（系統(tǒng)超級權(quán)限），會在Android的系統(tǒng)區(qū)中埋設(shè)特點命令（如su切換用戶命令），而在SELinux中，通過事先設(shè)定不允許以Root權(quán)限執(zhí)行的各種進程改寫系統(tǒng)區(qū)和重復掛載，就可以有效回避此類攻擊。

Android 5.0之前的SELinux默認設(shè)置為Permissive模式，即對違規(guī)行為只作日志記錄，供事后審計，而5.0版本則默認設(shè)置為Enforcing模式，真正啟用SELinux，對違規(guī)行為進行拒絕并日志記錄。

由于Android系統(tǒng)的開源特性，開發(fā)者可對操作系統(tǒng)的內(nèi)核源碼進行修改，放寬SELinux策略檢查，向沒有鎖定Bootloader的終端設(shè)備刷入定制的內(nèi)核，以獲得不受限制的Root權(quán)限。

（2）用戶參與的權(quán)限管理

針對一些敏感的權(quán)限，iOS都會彈窗請求用戶的許可，如開啟GPS定位、網(wǎng)絡(luò)連接、撥打電話等，而對一些涉及隱私的權(quán)限，則不對第三方APP開放，如收發(fā)短信、聯(lián)系人管理等。由于iOS的封閉性對于權(quán)限管理機制有一定程度的保護，而且隨著iOS系統(tǒng)的不斷改進，越獄困難越來越大。

2.3 安全域隔離

（1）TEE隔離

iOS在推出TOUCH ID功能的同時也推出了Secure Enclave安全域，Secure Enclave是蘋果A7及以上主處理器的協(xié)處理器，其自身具有微操作系統(tǒng)，與主處理器共享加密RAM，通過中斷與主處理器通信，操作系統(tǒng)借助它實現(xiàn)指紋特征數(shù)據(jù)、UID和GID密鑰等需高安全級別關(guān)鍵數(shù)據(jù)的存儲，其在架構(gòu)上與TEE相似。

TEE系統(tǒng)架構(gòu)標準由智能卡及終端安全的標準組織Global Platform發(fā)布，它提出了在原有硬件和軟件的基礎(chǔ)上，隔離出可信執(zhí)行環(huán)境TEE（Trusted Execution Environment）和富執(zhí)行環(huán)境REE（Rich Execution Environment），其中TEE用于安裝、存儲和保護可信應(yīng)用（TA），而REE用于安裝、存儲其它的應(yīng)用。

TEE具有自身的操作系統(tǒng)，與REE環(huán)境中的操作系統(tǒng)（如iOS、Android）相隔離。REE中的授權(quán)應(yīng)用，通過代理驅(qū)動程序才能與TEE中的代理驅(qū)動程序通信，不可直接訪問TEE的資源。TEE還可具備可信用戶界面（TUI），為一些關(guān)鍵的屏幕顯示和交互提供了安全保障。圖3為TEE系統(tǒng)架構(gòu)示意圖。

圖3 TEE系統(tǒng)架構(gòu)

TEE在實際應(yīng)用中也存在一些問題與缺點：TEE的硬件隔離主要體現(xiàn)在對CPU資源的分時或分核隔離、RAM資源和存儲資源的尋址隔離等，物理器件上仍然與REE環(huán)境共享，實質(zhì)上只是芯片內(nèi)的軟件調(diào)度隔離，因此不具備較高的防篡改能力。同時，TEE仍存在認證的問題，CC（信息技術(shù)安全評價通用準則）組織的EAL（評估保證級別）等級認證仍在進行中。

針對TEE架構(gòu)的移動平臺攻擊包括：

1）芯片攻擊

◆利用JTAG調(diào)試接口對MMU（內(nèi)存管理單元）處理器單元重新編程，修改RAM及存儲的尋址范圍，以獲得相應(yīng)數(shù)據(jù)的訪問權(quán)限。

◆利用物理探針在SoC芯片的數(shù)據(jù)總線上進行信號竊聽。

2）共享資源攻擊

如果REE環(huán)境中的非法代碼能共享訪問與TEE相同的CPU或RAM資源，那么TEE就存在受到共享資源攻擊的風險。

3）系統(tǒng)漏洞攻擊

◆在智能手機設(shè)備上發(fā)現(xiàn)了TEE內(nèi)存訪問控制的漏洞。

◆Bootloader存在設(shè)計漏洞，可用于系統(tǒng)非法提權(quán)。

◆整數(shù)溢出會給TEE的運行帶來風險。

◆在安全啟動代碼中存在證書處理或簽名有效期的漏洞，允許黑客插入惡意代碼。

4）入侵式攻擊

◆篡改代碼簽名機制可允許黑客插入惡意代碼。

（2）SE隔離

SIMallicance組織提出了基于Java語言的Open Mobile API機卡通信接口，使得運行于智能手機操作系統(tǒng)上的應(yīng)用可通過操作系統(tǒng)提供Open Mobile API接口，使用ISO7816協(xié)議與SE安全單元中的Applet應(yīng)用通信，現(xiàn)主要應(yīng)用于Android系統(tǒng)。SE是具有防物理攻擊的高安全性的芯片，內(nèi)含獨立的CPU、RAM、FLASH和操作系統(tǒng)，SE可存儲密鑰等關(guān)鍵數(shù)據(jù)信息，SE中的Applet應(yīng)用可進行各種加解密算法的運算。主流SE芯片廠家通過了CC組織的EAL5+安全認證，這是目前較為安全的系統(tǒng)隔離方案。

由于SE自身不具備UI界面，需借助上層操作系統(tǒng)（即REE），用戶輸入的PIN碼等仍有被截獲的風險。由于Android系統(tǒng)的開源特性，黑客可對操作系統(tǒng)中安全規(guī)則檢查模塊代碼進行修改、編譯并向終端重新刷入更改的模塊，使得非授權(quán)應(yīng)用可直接與SE中的Applet通信，為終端安全帶來極大的風險。

3 安全解決方案建議

REE+TEE方案或REE+SE方案在一定程度上提升了終端系統(tǒng)的安全性，但仍然存在一定的缺陷，難以抵擋高級別的攻擊。以下針對運營商的具體情況給出一些建議：

（1）架構(gòu)方面：建議SE不直接與REE對接，而是與TEE的Trusted Kernal對接，REE對SE的訪問，可通過TEE進行，即REE+TEE+SE方案。

（2）關(guān)鍵信息存儲方面：原存儲于TEE中的密鑰、密碼等關(guān)鍵信息，可轉(zhuǎn)移放至SE中，借助SE的抗攻擊能力，對關(guān)鍵信息實施保護。

（3）關(guān)鍵運算載體：大數(shù)據(jù)量的加解密預算，如對稱加解密運算等，建議由TEE中TA應(yīng)用負責，借助TEE豐富的運算和內(nèi)存資源保障響應(yīng)性能；小數(shù)據(jù)量的加解密運算，如數(shù)字簽名等，建議由SE中的Applet應(yīng)用負責。

（4）實施建議：電信運營商的SIM卡是現(xiàn)成的SE資源，且具有成熟的TSM后臺對其管理，終端TEE可通過ISO7816接口與SIM卡SE進行對接，把SIM卡SE作為可信外圍設(shè)備，從而構(gòu)建出軟件+硬件的整套安全解決方案。

4 結(jié)束語

智能手機操作系統(tǒng)的安全問題，不可只從軟件層面去解決，還需要借助硬件本身的能力對其進行完善?？尚艌?zhí)行環(huán)境的架構(gòu)已逐漸被終端廠家采用，并且已有移動支付類的代表性應(yīng)用落地，相信在不久的將來，安全智能手機操作系統(tǒng)將會得到普及。

[1] GlobalPlatform Inc. TEE System Architecture V1.0[S]. 2011.

[2] Apple Inc. iOS Security Guide[S]. 2014.

[3] GlobalPlatform Inc. Secure Element Access Control V1.0[S]. 2012.

[4] Samsung Electronics Co., Ltd. Meet evolving enterprise mobility challenges with Samsung KNOX[Z]. 2014.

[5] SIMalliance. Open Mobile API specification V2.03[S]. 2012.