智能手機操作系統安全技術探討

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

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

1 引言

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

2 關鍵安全技術分析及存在的問題

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

2.1 數據保護

（1）Android的全盤加密

Android 3.0開始引入全盤加密（Full Disk Encryption，FDE），這是個很重要的安全特性，尤其是在解決設備丟失后的數據安全問題方面。

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

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

圖1 FDE主密鑰保護機制

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

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

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

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

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

（2）iOS的文件加密

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

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

圖2 iOS文件加密機制

2.2 權限策略

（1）增強安全Linux系統SELinux

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

SELinux 提供了一種靈活的強制訪問控制（MAC）系統，且內嵌于Linux Kernel中。SELinux定義了系統中每個用戶、進程、應用和文件的訪問和轉變的權限，然后它使用一個安全策略來控制這些實體（用戶、進程、應用和文件）之間的交互，安全策略指定如何嚴格或寬松地進行檢查。只有同時滿足了“標準Linux訪問控制”和“SELinux訪問控制”時，主體才能訪問客體。

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

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

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

（2）用戶參與的權限管理

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

2.3 安全域隔離

（1）TEE隔離

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

TEE系統架構標準由智能卡及終端安全的標準組織Global Platform發布，它提出了在原有硬件和軟件的基礎上，隔離出可信執行環境TEE（Trusted Execution Environment）和富執行環境REE（Rich Execution Environment），其中TEE用于安裝、存儲和保護可信應用（TA），而REE用于安裝、存儲其它的應用。

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

圖3 TEE系統架構

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

針對TEE架構的移動平臺攻擊包括：

1）芯片攻擊

◆利用JTAG調試接口對MMU（內存管理單元）處理器單元重新編程，修改RAM及存儲的尋址范圍，以獲得相應數據的訪問權限。

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

2）共享資源攻擊

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

3）系統漏洞攻擊

◆在智能手機設備上發現了TEE內存訪問控制的漏洞。

◆Bootloader存在設計漏洞，可用于系統非法提權。

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

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

4）入侵式攻擊

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

（2）SE隔離

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

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

3 安全解決方案建議

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

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

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

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

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

4 結束語

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

[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.