維護手機資訊安全 TrustZone軟硬兼施

2010-09-25
在前一期的「手機資訊安全介紹–ARM TrustZone簡介及應用(I)」中,針對手機上常見的安全議題和以TrustZone為平台基礎的安全機制做了簡單的介紹,接下來本文將從軟體的 角度深入探討TrustZone架構,並針對如何使用TZ應用程式介面(TrustZone Application Programming Interface)所提供的介面來實現一個應用程式的控制流程部分。
TrustZone架構優勢顯而易見  

簡單來說,安謀國際(ARM)利用兩個硬體相 當的平台作為一個可平行處理的兩個區域。安謀國際稱其一個即是安全的世界(Secured World 、Secure Domain),另一個即為一般的世界(Normal World、Non-Secure Domain)。由圖1可知,須要保護的資料如處理使用者身分模組(SIM)卡中的安全性鑰匙,就會安全地在Secured World被處理,這在一般的作業系統中是無法實現的一個機制。除此之外,還有如下的其他優勢:

圖1 TrustZone兩平行安全區域示意圖

安全資料處理的效能
  TrustZone提供一個直接記憶體存取(Direct Memroy Access, DMA)的記憶體匯流排,當有大量資料須要處理時,不必經過編碼的訊息(Encoded Message)來傳遞資料,只要將應用程式中的一個緩衝記憶體透過特定應用程式介面(API)實現記憶體映射(Memroy Mapping)作為共享記憶體,而資料得以直接共享在兩個區域中。

解決方案的彈性設計
  由於包含了軟硬體元件的解決方案,使得TrustZone提供相當大的彈性來符合客製化的需求,甚至在系統單晶片(SoC)硬體設計底定後仍能透過升級方式達到所需的安全系統。

減少研發過程的風險及經費
  基於彈性的硬體架構設計,軟體研發過程得以縮短,工程師可以專注於與安全相關的應用程式。另外,由一家專攻安全專業的公司Trusted Logic S.A.專門負責TrustZone軟體模組,支援各種ARM中央處理器(CPU)平台,透過整合後的模組來達成安全防護的最佳化設計。

TrustZone軟體元件分工細密  

如圖2所示,TrustZone軟體包含非安全部分的一般作業系統(Normal OS)及應用程式(Normal OS App.),受保護的安全軟體模組部分則包括監控元件(Monitor),負責提供安全與非安全世界的介面、安全核心(Secure Kernel)、安全驅動程式(Secure Drivers)、開機程式(Boot Loader),以及角色類似應用程式的安全服務元件(Secure Services)。

圖2 TrustZone軟體元件架構

由Trusted Logic負責開發的TrustZone安全軟體模組,旨在提供一個最佳化並相容於各種不同ARM CPU平台的解決方案,用來存取具防護機制的記憶體、儲存設備、SIM卡及可信任的使用者介面。透過安全服務軟體來實現各種安全服務,例如完整性檢查、存取控制、密碼演算法等,未來並將包括支援數位權限管理(Digital Rights Management, DRM)、數位簽章及電子銀行等等服務。  

根據需求提供相對應API  

TrustZone根據目標應用程式的不同需求擁有相對應不同層級的API,包括以下幾項:

TrustZone Generic API
  此API提供簡單的訊息傳遞介面(即圖1中的TZAPI+Encoded Message),並提供兩個並行世界低階的溝通管道(Low-level Communication)。

TrustZone Security Channel API
  此API提供介面去存取在安全模組中的各種安全功能與服務。此文所提及的API即包含了以上兩種API。

The Security Module Internal API
 
The Security Module HAL API
  以上兩個API是屬於安全模組設計的介面,適用於只採用TrustZone硬體方案的廠商。不使用Trusted Logic的安全模組軟體時,則可透過這些API來實現TrustZone軟體部分,這部分包含DRM Codecs、專有技術的加密協定或專有的安全溝通協定等。

解構TZ API  

圖3 TZ API基本結構示意圖
如圖3所示,TZ API提供客戶端程式(Client Application)一個介面存取,並管理安全環境中的服務模組(Secure Service),透過此介面,使客戶端能夠與這服務模組連結,並傳達指令給服務模組。指令即是一個精簡的訊息、代表客戶端傳達給服務模組其欲執行的行為。客戶端通常由應用程式和Service Stub所組成,Service Stub為實現應用程式欲呼叫TZ API中的抽象層,如圖3中左半邊區塊所示。由客戶端的角度來看TZ API,其可分解為四大部分:  

TZ API的實現
  TZ API的實現通常與硬體平台有直接的關連,所以一般分成兩部分,一部分是在客戶端程式記憶體中執行的函式庫(TZ Library),另一部分為在作業系統記憶體中執行的驅動程式(TZ Driver)。驅動程式通常比存在於客戶端記憶體的函式庫較為可靠,所以能處理一些有限的須安全防護的動作,例如判斷登入的帳戶資料與權限等。

裝置模組
  這是一個邏輯上的裝置區塊,提供各個安全服務的進入點,並且管理所有與客戶端連結點。

安全管理模組
  一個邏輯管理元件提供裝置有關已安裝執行的服務內容並允許更改服務組態。

安全服務模組
  所有的安全服務程式在此環境執行,並提供高階函式給客戶端程式呼叫。

大部分的API函式都是設計用來處理客戶端程式與安全服務間的溝通,兩者透過結構式訊息(Structured Messages)及記憶體分享(Shared Memory)這兩個機制形成溝通管道。當欲傳遞的資料量小時,透過結構式訊息得以傳送及溝通。而當資料量大時,則直接將客戶端的記憶體映射至安全服務的記憶體空間,然後透過此分享記憶體作為直接存取資料的緩衝區。  

TZ API函式各司所職  

TZ API函式包括控制函式、編碼解碼函式、安全管理函式及其他非必要呼叫的函式。控制函式是TZ API的主要函式組,負責建立介於客戶端與服務端的連結、傳達命命及建立共享記憶體映射等。編解碼函式則負責將結構式訊息在正確的狀態下進行解碼或編碼。而安全管理函式處理安全管理元件所須呼叫的函式,主要負責安裝、移除服務或在運行時間(Run-time)中諮詢已安裝的服務。其他函式則包括了因應一些因為作業系統的特性而須要支援的非同步函式等。  

圖4 呼叫TZ API函式的控制流程
一個基本應用到TZ API的控制程式模組中會呼叫到的函式及流程如圖4所示,圖中描述在正常情況下客戶端程式欲與安全服務建立連結,並執行一個指令所該呼叫的函式。此流程圖忽略了函式中須要帶入的參數,也忽略所有當呼叫函式回傳錯誤時應有的對應動作(Error Handling)。每個方塊中的文字即為所呼叫的函式名稱,其中值得注意的是,當在一個Session中所須要呼叫到的主要三個函式TZOperationPrepareOpen、TZOperationPrepareInvoke及TZOperationPrepareClose,也就是開啟或關閉Session或傳達指令時,必須同時呼叫另外兩個函式TZOperationPerform、TZOperationRelease,來完成整個動作。  

市場接受度仍為推展關鍵  

安謀國際所提出的TrustZone是一個整合軟硬體的完全防護解決方案,類似於在個人電腦(PC)上的可信任平台模組(Trusted Platform Module, TPM)解決方案,然而TPM是獨立於處理器之外的硬體模組,但TrustZone則是密切整合在SoC中,其優勢在文前已詳加敘述過。  

但是,TrustZone所遭遇的最大挑戰在於如何讓手機市場上四個不同的生態系統接受這樣的解決方案,這四個市場上的角色分別為作業系統廠商如Symbian、Android、iOS、Windows Mobile,手機製造商如諾基亞(Nokia)、宏達電、蘋果(Apple)、RIM,手機應用程式設計者和晶片製造商如德州儀器(TI)、高通(Qualcomm)、聯發科。  

由於安謀國際陸續開發出的Cortex-A系列處理器已經內建TrustZone,所以硬體晶片廠商的新一代SoC包含此系列處理器的平台都已支援TrustZone,但是仍有製造廠商持續使用其自行研發多年的安全方案,即使使用安謀國際TrustZone的硬體架構,但是軟體部分由於經過多年長時間所研發的方案已經非常完善,所以還是會採用自行設計的安全解決方案。甚至有些作法 是安全性防護只做到硬體 層面,直接忽略軟體的防護。  

如何在TrustZone軟體模組部分開放更多的資源,進而說服並統合整個市場使用TrustZone的整合性防護,將會是安謀國際在資訊安全課題中的一個非常重要的目標。

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!