從諾基亞 X6 聊人臉解鎖：你以為有結構光就叫安全嗎？

來自專欄周三科技

周三科技的一大主義是（正考慮改叫周三電子），從理論上分享一些知識點，如果一定要談目標，那大概就是開闊愛好者們的視野吧。因為我翻譯和撰寫的文章，一般既不像很多「評測」文章那樣具有導購的作用，也不是專業技術文——對生產也不會有任何幫助。所以這裡的資訊，本質上也就是起到增加談資的作用，作為茶餘飯後的笑料去和好友分享可能是最合適的。

文題略標題黨，這次我想聊一個相對偏門，甚至很難作為營銷賣點去說的手機人臉識別某一個層級的安全性問題——恰巧之前寫過一篇類似的文章，這篇則意圖以更便於理解的方式來談這一問題（雖然在寫完之後，感覺又有點自 high 了）。

沒想到的是，我前兩個月撰寫的《聽說 Android 手機已經和 iPhone 一樣安全了，真的是這樣嗎？》點贊和評論都還算活躍，畢竟這個話題關注的人其實挺少的。不過實際上，Android 和 iOS 的安全性問題範疇遠大於文中提到的「系統漏洞」，至少 Android 最嚴重的安全威脅就目前看來其實是惡意程序，其中的絕大部分是不涉及漏洞的。如果我們再進一步對這兩個系統做安全性的探討，那麼無論蘋果還是谷歌，在系統安全性方面做的文章都還是極為多樣和工程龐大的，本文就再嘗試探討其中的一個層面。

本文面向的閱讀群體是手機愛好者，一般消費用戶也可以閱讀；若要理解全文，可能需要對計算機科學有最基本的認識。不過文章內容整體還是比較淺的，閱讀時可以忽略一些細節；略過文中標註「選讀」部分，也完全不影響全文意思的理解。有意向對技術做進一步了解的，歡迎點閱文末參考的鏈接，裡面有更具體的技術分析。

前兩周參加諾基亞 X6 的發布會，會上的其中一屏 PPT 提到了這款手機的人臉識別解鎖採用了 TEE 方案。TEE 的全稱叫 Trust Execution Enviroment，說句人話，TEE 在 ARM 架構的處理器中就叫 TrustZone。TEE 最早是由 GlobalPlatform 提出的一種標準，其基本理念是在 CPU 內部構建一塊獨立的「安全世界」，把敏感信息（如某些密鑰、PIN 碼）的存儲和操作都放在這裡進行，以確保安全性。而我們所知的 TrustZone 就是 TEE 的一種具體實現。

所以諾基亞的意思也就是 X6 這款手機的人臉識別是和 TrustZone 掛鉤的，這是我們要談的重點。

人臉解鎖的安全性是什麼意思？

「安全」是個比較寬泛和涉及到多層級的辭彙，一般媒體日常都很喜歡說 Face ID 的安全性好。不過這裡的「安全性」好，說的是眾多感測器（包括攝像頭）識別人臉這一過程比較安全——而生物特徵（biometric）做身份認證的安全性實際上不光這一個環節，它還涉及到生物特徵數據（如人臉、指紋數據）的存儲、傳輸等操作是否安全。

如果說感測器識別人臉的過程很安全（比如 2D 照片、3D 臉模都無法欺騙人臉識別感測器），但人臉數據在存儲後卻可以被輕易竊取，則其安全性也是存在問題的。當然 Face ID 這方面做得也不錯，其生物特徵（人臉數據）就是在 A11 晶元的 TEE 安全世界中執行操作的。當然在蘋果的宣傳中，這個 TEE 叫做 Secure Enclave，這也可以認為是蘋果版的 TrustZone 了（雖然可能微架構存在很大差別）。

再舉個例子，在 Touch ID 時代，人們普遍更關注生命特徵的存儲問題。實際上也正是從 iPhone 5s 的指紋識別感測器開始，很多消費用戶和愛好者知道了有個叫 TrustZone 的東西的存在。因為在指紋識別作為主流身份認證的年代，識別過程的安全性往往沒有那麼重要（即便依然有黑客通過指紋取樣、建模來欺騙指紋識別感測器，但這個層面的攻擊難度會大很多），指紋數據的傳輸和存儲在一般人看來才是最重要的。

這裡小結一下，至少就本地生物特徵身份認證（如手機的人臉解鎖）的安全性需要分兩個階段來談，第一階段即感測器識別生物特徵的過程，第二階段則是生物特徵數據傳輸和存儲的安全性問題。針對其中任一階段的攻擊和破解，都可以達到竊取數據或其他破壞性目的。比如理想情況下，針對指紋識別的第一階段，可以通過採集指紋和建模來欺騙指紋識別感測器，也可以針對第二階段來攔截傳輸中的或獲取已存儲的指紋數據——完成其中任何一個階段，都能欺騙身份認證過程，並最終竊取手機中的資料。

在人臉識別時代，其實大部分消費電子科技媒體談的所謂安全性都是第一階段的安全性，這的確也是人臉識別解鎖乃至支付最大的挑戰。iPhone X 可能是目前在民用移動設備領域，人臉識別第一階段安全性做得最好的手機產品：Face ID 用上了現在被很多人所熟知的結構光。而許多 Android 手機人臉識別的第一階段，很大程度上還受制於 2D 照片的欺騙——而用戶的 2D 照片實際上是很容易從社交網路上獲取的。

早年，相對複雜的 3D 臉部識別技術對於硬體的處理性能會有較高的要求，而且體驗也並不好。比如東芝臉部識別工具（Toshiba Face Recognition Utility）要求用戶根據提示把頭轉向幾個不同的方向，整個認證過程還需要大約 30 秒——這在民用設備上是個不能忍的。另一方面，其實 2D 維度的人臉識別也並非全靠用戶錄入的一張照片。2014 年的一篇題為《Sensor-assisted facial recognition: An enhanced biometric authentication system for smartphones》的 paper 就提到了，利用手機中的加速計來推測前置攝像頭的位置和方向[1]。

所以蘋果在收購 PrimeSense 之後能有此番建樹也實屬不易了（尤其是體驗和安全的雙重提升）。不過這不是本文要談的重點，我想從較淺的層面聊聊這裡的第二階段，即生物特徵數據的存儲和操作的安全性——也是諾基亞 X6 所說的安全性所在，畢竟 TrustZone 的博大精深遠不是我這樣的二道販子能完全理清的（而且大部分消費電子科技媒體似乎也都沒提過 TrustZone 在人臉識別這件事情上扮演何種角色）。

而 TrustZone 相關的安全問題，也絕不僅僅是下面討論的這些。典型如蘋果的 Secure Enclave 參與 iOS 的安全啟動過程，而且每一代 SoC 的迭代也伴隨 Secure Enclave 的加強，如最新的 A11 中，會有個 integrity tree 阻止 Secure Enclave 的存儲部分被 replay 攻擊，存儲空間還會藉由片上 SRAM 內的臨時密鑰（ephemeral key）和隨機數做加密...這些就不在我們的討論範圍內了。

Android 4 時代的人臉解鎖

不知很多同學是否還記得，早在 Android 4.0 冰淇淋三明治時代，Android 系統內部就集成了人臉解鎖功能——當年的 Galaxy Nexus 和 Nexus 4 還用這項功能做過一波廣告（還記得是一個小孩兒做出各種鬼臉企圖解鎖父親的手機，父親把手機拿到跟前看了一眼就完成了解鎖）。那個時代的人臉解鎖體驗當然比現在差遠了，尤其識別率和對場景的要求，都和現在的人臉解鎖解決方案相去甚遠。

但這是次要的，在人臉解鎖功能推出初期，谷歌似乎沒怎麼考量過這項功能的安全性，所以用照片來欺騙 Android 4.0 的人臉識別解鎖是完全可行的（即第一階段的安全性差）。那麼第二階段安全性又如何呢？悲劇的是，我作為一個從未參與過生產的人，也沒有條件去對當年的 Android 4.0 搞逆向；我也沒有找到相關資料。不過我惡意揣測，這個階段的人臉數據和 TrustZone 還沒什麼關係（或者說沒有專有硬體的證書存儲和加密操作），人臉數據可能只是簡單地放在某個文件夾里，有關依據會在下文提到。

這其中當然還關乎很多細節，比如人臉數據是如何轉為數字形式存儲的，是否加密等。但其存儲方式就決定了其安全等級與當代諾基亞 X6 這類手機在生物特徵數據存儲安全性方面存在差距。所以後來谷歌把這項功能移到了設置菜單的 Smart Lock 中，而不將其作為解鎖手機的屬性單獨列項。

現在各 OEM 手機製造商所用的人臉解鎖方案大部分也都不是谷歌集成在 Android 系統內的功能了。即便它們始終也沒能邁過人臉識別第一階段安全性的門檻，第二階段的安全性卻都清一色做了升級——這是一種進步，但這也註定 Android 手機當前比較普遍的人臉解鎖方案是很難應用於支付的。畢竟支付關乎金錢，它對於安全性的要求可比解個鎖高多了（至少對普通人而言是如此），唯有第一階段也做到蘋果的程度，才有將其作為全局身份認證方案的基礎。

那麼如果我們只討論第二階段的安全性，iPhone 和 Android 手機誰又做得更好呢？如果不做具體工程，大概也很難比對 QSEE（高通的 TrustZone 方案）和蘋果 Secure Enclave 誰更安全，所以就第二階段，Android 手機和 iPhone 的安全性比較也很難講清楚。但至少，它們的大體思路是一樣的，就是把生物特徵數據在 CPU 的這個「黑匣子」里進行操作，包括加密、存儲等，別說其它 App 撬不開，連繫統自己也拿不到裡面的數據——這就是一種進步。

實際上我們之所以說 Android 4.0 時代的人臉解鎖在安全性方面還很原始，有一則依據是直到 2013 年下半年 Android 4.3 果凍豆的推出，谷歌才在 API 文檔中首次提及硬體級別的證書存儲（Hardware credential storage）[2]，說句人話就是 KeyChain 證書可以存儲在專有的硬體中了（好像也不是人話...），極為敏感的身份憑證，比如密鑰這種東西就會更安全。谷歌也是那時才第一次在開發者文檔中提到了 TrustZone，「即便是操作系統內核也無法訪問（存儲在其中的）密鑰資料」。

從這個版本的系統開始，Android Key Store 密鑰存儲，對於存儲和使用 app 私鑰才有了公共 API——早前的系統其實也可以實現，只不過並沒有得到谷歌的正式支持。系統甚至在設置項中還支持檢查證書存儲是否受到專有硬體支持，比如當時的 Nexus 4 就已經開始宣傳高通內部的 TrustZone 了，而更早一代的 Galaxy Nexus 在證書存儲的問題上仍然只支持從軟體上來實現（德州儀器的 SoC？）[3]。其實我們把這裡的「證書」譯作「身份憑證」可能更便於理解，人臉或指紋解鎖中的人臉和指紋數據，就是一種身份憑證（即便可能和實質上的 credential 還是不一樣，或成為獨立的子系統），它們放在哪個位置顯然是很重要的。

(註：但我也不能下結論說，Android 4.3 之前的解鎖憑證沒有受到硬體級別的保護；另外可能還需要對 Android 系統後來的全盤加密做更進一步研究。這裡簡單聊一聊，Android 系統的全盤加密是從 5.0 時代開始受到支持的，這其中涉及到的各類密鑰和加密過程比較複雜。設備解鎖啟用的 PIN 碼、密碼、解鎖圖案都屬於全盤加密（以及文件級別加密）的組成部分，而不僅是很多人以為的某個簡單的通行證而已。詳情可以參見 Android 安全文檔[4]。

我們說「證書存儲」，究竟存什麼證書？實際上 Android 4.3 正式引入的證書存儲 API 主要用於存儲例如 Wi-Fi 和 VPN 連接之類的證書（比如密鑰），另外當然就是針對第三方 App 的證書。這個 API 支持生成和訪問 App 私鑰，為非系統 App 安全存儲密鑰提供了便利，開發者不需要再自己取實施密鑰保護措施。就硬體支持的證書存儲（TrustZone），即便有 root 許可權也很難拿到其中的證書。

不過據此，我們至少可以認為，Android 4.3 之前的系統還罕有專門硬體支持的憑證存儲。TrustZone 在此之前還沒有被普遍認知，更不用談生物特徵數據是否在這裡操作。）

選讀：有關 Android 系統證書的存儲（可略過）

《Android 安全剖析：Android 安全架構深度指導（Android Security Internals: An In-Depth Guide to Androids Security Architecture）》[5]（這本書貌似還挺貴的，電子書售價 874 美元）一書中有特別提到我們上面在談的這個證書存儲。這裡與大家分享一些節選。

「系統證書存儲是個系統服務，在將導入的證書存入磁碟之前，可對其進行加密。加密密鑰源自用戶提供的密碼，包括在 Android 4.0 系統之前專門的證書存儲防護密碼，或者設備解鎖圖案，PIN，或者是 4.0 系統之後支持的密碼。此外，證書存儲系統服務會對證書而訪問做出規範，確保僅有明確授權的 App 才可以訪問密鑰。」

「最初的證書存儲特性，是在 Android 1.6 系統中引入的，當時僅限於 VPN 和 Wi-Fi EAP 證書。那個時候只有系統可以訪問存儲的密鑰和憑證，第三方 App 是不可以的...證書存儲管理是沒有公共 API 的...」

「訪問系統存儲證書 API 的最早引入是在 Android 4.0。系統證書存儲後來擴展到了硬體級別，不僅支持共享的系統密鑰，而且還支持 App 私鑰。上表展示了每個 Android 版本證書存儲相關的重大升級...」

「原本守護進程的實施方案包括在一個庫中的密鑰塊管理和加密，但後來 Android 4.1 引入了全新的 keymaster 硬體抽象層（HAL）系統模塊，支持在無需輸出密鑰的情況下，就可以生成非對稱密鑰，以及簽署和確認數據。keymaster 模塊會將 keystore 密鑰存儲服務，從非對稱密鑰操作實施方案中剝離出來，支持特定設備、硬體級別更方便的整合。實施方案可採用供應商提供的專有庫，與加密硬體進行通訊，並提供 HAL 庫...」

「Android 另外支持 softkeymaster 模塊，可以純軟體的形式執行所有密鑰操作（使用系統的 OpenSSL 庫）。該模塊使用基於模擬器（emulator），用於那些不包含專用加密硬體的設備...」

「所有非對稱密鑰操作，對 keystore 服務可見，通過調用系統 keymaster 模塊來實現。因此，如果 keymaster HAL 模塊有硬體級別的支持，那麼所有更上層的命令，以及使用 keystore 服務介面的 API，都會自動去使用硬體加密。除了非對稱密鑰操作，所有其他證書存儲操作，都通過 keysotre 系統服務實現，不依賴於 HAL 模塊......和大部分 Android 服務有所不同的是，keystore 服務以 C++ 實施，位於 system/security/keystore 中。」

不過需要指出的是，這本書寫的時間比較早，可能其中的資訊是滯後的；後續 Android 系統或已經對這部分內容做了更新。跟進這部分內容的高人歡迎留言補充。

用指紋或人臉解鎖設備時，系統究竟在做什麼？

其實我不知道諾基亞 X6 的人臉解鎖用的是哪家的方案（諾基亞當前全系支持人臉解鎖設備的手機應該都是同一套方案），可能並不是時下國內廠商普遍流行的 Face++（曠視）。而且我在網上找 Face++ 的方案細節也一無所獲（哭，不會做逆向的悲哀）。但 Face++ 的方案基於 TrustZone 也是可以確認的。

這裡我們只能借用 iOS 系統的 Touch ID 和 Face ID 來簡單地管中窺豹了[6]（Android 的安全文檔實際上也有指紋識別方面的內容），iOS 的安全白皮書相對簡要地談到人臉解鎖識別和支付的過程。人臉解鎖和支付的過程，其實並不像很多人想像得那麼簡單，就是把兩份數據簡單比對一下，看看是否匹配，匹配就解鎖或支付——因為如果真的這麼做，安全性會成為一個巨大的問題。

先聊聊 Touch ID，畢竟就生物特徵數據的存儲和操作，總體上它和 Face ID 應該是差不多的。這部分有點繞：就 iPhone 而言，Touch ID 是幾乎直接和處理器的 Secure Enclave 進行通訊的。蘋果的處理器與 Touch ID 指紋識別感測器的通訊是通過串列外圍介面（SPI）匯流排進行的，處理器隨後把 Touch ID 獲得的數據轉給 Secure Enclave，處理器自己的「普通世界」是無法閱讀這部分數據的。每台 iPhone 設備的 Touch ID 感測器都會與對應的處理器 Secure Enclave 最初都會有個共享密鑰（出廠時就有的，且每台設備都不一樣），兩者會利用這個共享密鑰再協商一個會話密鑰——這個會話密鑰對剛才獲取的指紋數據進行加密和認證。

另外，兩者的會話密鑰的交換過程也是加密的，而這裡用於加密交換過程的 AES 密鑰還會有一重外衣，這層外衣由 Touch ID 感測器和 Secure Enclave 分別提供的隨機密鑰構建起來，傳輸再採用 AES-CCM 傳輸加密。

說得這麼繞，講句人話其實也就是 Touch ID 的指紋數據的傳輸、存儲等操作經過了層層加密、各種加密，才在 Secure Enclave 中落地，即便或許在你的使用過程中，只是一瞬間的事情。

當然有一點還是需要提一下，即所謂的「指紋數據」存儲，最終還是要落地為數字化內容的，不會是真的給 Secure Enclave 呈現個指紋圖片。實際上 Touch ID 感測器的光柵掃描結果首先會臨時存儲在 Secure Enclave 的專用存儲區間內。然後分析過程中會對指紋紋路進行一個映射，這個過程會丟棄一些細節數據，隨後映射產生的數據再以加密的方式存起來，僅有 Secure Enclave 可以讀取。這個所謂的「映射過程」算是個有損的數據存儲過程（因為丟棄了某些細節數據）。按照蘋果的說法，這麼說是為了防止有機會可利用這些數據重新構建用戶真正的指紋長什麼樣。

Face ID 的這一過程則會相對更複雜，很多媒體都提過感測器識別人臉數據的過程——這套系統在蘋果那兒叫 TrueDepth。Face ID 在首先檢測到人臉之後就會開始後續的操作，iPhone X 劉海的那一排感測器會投射出超過 30000 個紅外點，構成臉部的深度圖（depth map），另外當然也會錄入 2D 紅外圖像。最後轉往 Secure Enclave 的數據實際上是一系列的臉部 2D 和深度圖。諸多 2D 圖像和深度圖的順序是隨機化的。處理器 Secure Enclave 隨後會把這些圖像轉成某種數據形式，隨後的人臉識別匹配過程自然也是在 Secure Enclave 中進行的。這個識別過程當然又關乎到神經網路了，但此處的匹配只關乎深度學習的 inference，而 training 階段仍然是蘋果那邊在做的事情——這和麒麟 970 的 NPU 是異曲同工的。

不好意思，一激動又裝了個逼。上面這兩段都是次要的，也不是我們這篇文章要討論的問題，畢竟它們更偏向於前文提到的「第一階段」的安全性。不過在 Face ID 的闡述中，蘋果並未言明相關臉部數據的「傳輸」通道是如何保證安全性的，對應於 Touch ID 的傳輸（感測器和處理器之間的通訊）經過了層層加密；畢竟後續「臉部數據」的數字化表達（mathematical representation）和加密都是在 Secure Enclave 內部進行的，前期的傳輸過程如何是未知的（以及除了前置攝像頭意外，其他感測器是如何與處理器進行通訊的）。我們猜測，2D 圖像和深度圖順序的隨機化，或許可以抵禦針對傳輸過程的攻擊。

實際上，和前文 Android 證書存儲部分所述的一樣，利用 Touch ID 和 Face ID 進行手機「解鎖」，它們並不只是單純充當通行證的角色，匹配正確了就讓你完成解鎖，進入系統。生物特徵數據，或者我們設置的解鎖密碼、PIN 之類，本質上都會參與設備上的各種加密操作，比如 Android 5.0 之後的全盤加密，以及 iOS 設備上的數據防護。有關這部分內容，還可以參見我早前寫的另一篇文章《內置加密晶元的金立M6，真的是「最安全」的手機嗎？咱來聊聊TrustZone》（這篇文章可能在 TrustZone 架構的理解上存在一些錯誤）。

iOS 的數據防護（Data Protection，包括文件加密）當然也有最高級別的密鑰，這些密鑰存在於 Secure Enclave 中。如果我們開啟人臉或指紋識別，在我們關閉屏幕之後，設備不會丟棄這些密鑰。這些密鑰會再用另一個密鑰進行加密操作，然後把它們交給 Touch ID 或 Face ID 子系統。當我們去解鎖設備，並且成功匹配，則 Touch ID 或 Face ID 就會交還一個密鑰，用於解密數據防護的密鑰。如果設備重啟，上面提到的這些密鑰會丟失，Secure Enclave 也丟棄了這些密鑰（也包括 48 小時我們都沒有去使用設備的情況下），所以我們需要重新輸入解鎖密碼。

（順帶吐槽一下魅族，無論何時，包括重啟等各類操作，你都可以用指紋去解鎖手機——這其實算得上對安全的一種漠視。大部分 Android 手機即便啟用指紋解鎖，某些情況下，如重啟設備，依然會要求用戶數據密碼。）

所以簡單的一個解鎖設備的操作，其後系統忙裡忙外做的事情可是相當多樣的。我雖然沒有仔細閱讀 Android 在這部分的設定，加密解密的細節可能會存在較大差異，但整體思路差不多也會是這樣——但 Android 的人臉解鎖估計並不參與這部分操作，因為 Android 安全文檔的身份驗證章節中並沒有提到人臉解鎖。所以有可能 Android 當前的人臉解鎖還真的主要停留在進入系統的「通行證」功能的層級上（歡迎反駁）。

有關支付的巧妙操作

最後咱來聊聊生物特徵識別，在支付行為中扮演什麼角色。某一類生物特徵識別的支付，或者關乎金融操作（比如取款）的方案其實是很不安全的，比如很多銀行為了方便用戶進行金融方面的操作，要用戶到銀行去錄入指紋，以後取錢不用密碼，用指紋就可以。這種模型是一個「中心化」的模型，即指紋數據是集中存儲在一個中央機構的，如果說有黑客用各種手段攻破了伺服器防線，獲取到了這些數據，那麼就意味著上億用戶的生物特徵數據被竊取（即便或許其他攻擊方式可能會更經濟）。

大部分消費類媒體都不止一次地提到，生物特徵數據的一次破解，就意味著終生破解，畢竟生物特徵（包括指紋、掌紋、聲紋、心跳等）具有穩定、不可更改、不可拋棄的特點。這和設置字元密碼是不同的，畢竟如果密碼被暴力破解了，我們大不了改一個。所以中心化的生物特徵識別支付操作是非常不安全的。

FIDO 聯盟（Fast Identity Online）2015 年就提出過一個參考標準[7]，而且是與 TrustZone 打配合的。其中 UAF（Universal Authentication Framework）標準的擴展提到過這麼一套方案：比如利用指紋或人臉來支付的場景，設備生成公鑰和私鑰（兩者自然是配對的關係）——針對用戶、設備及賣家（也就是購物網站）。賣家那邊僅持有公鑰，買家持有私鑰——這個私鑰當然也是加密存儲的。買東西的時候，如果私鑰能夠與公鑰匹配，則完成支付操作。

可能很多人以為私鑰就是指紋或人臉了，但實際情況是私鑰是加密存儲的，指紋、人臉這樣的生物特徵只不過是用來解密私鑰的一個因素（也就是說指紋、人臉只是獲得私鑰的一個必要途徑）。這樣一來，生物特徵數據只參與解密私鑰，而且不可或缺，還不會在網路上傳輸，安全性自然就和前面提到的那些銀行的操作不同了。

現如今用指紋進行支付的場景已經隨處可見了，包括 Android 手機也能用指紋完成支付。但就像文章第一部分說的，Android 手機至今都沒能很好地解決人臉識別關乎的第一階段的安全性，所以用人臉來支付在 Android 設備上依舊任重而道遠。

選讀：TrustZone 究竟是個啥？（可略過）

ARM 很早就提出了 TrustZone 的設計。就像我們前面說的，TrustZone 的設計理念是把 SoC 硬體和軟體資源分隔成兩部分：安全子系統的「安全世界」，和常規使用的「普通世界」（比如 Android 系統整體都可以算是普通世界）。安全世界有自己專門的操作系統（比如高通的 QSEOS，這個系統直接以系統調用的形式提供少量服務），內部還運行一些「微應用」，比如密鑰管理、加密、完整性檢查等。這些微應用（Trustlet）為普通世界提供安全服務。一般來說，兩個世界之間的通訊是經過操作系統內核進行的。

常見的微應用比如 Keymaster，這是 Android 系統 keystore 守護進程提供的密鑰管理 API 的具體實現，它負責生成存儲加密密鑰，以及讓用戶使用這些密鑰。微應用再比如 Widevine，負責在設備上進行媒體的「安全播放」等。

TrustZone 的實現就 ARM 的官方方案來看，並不只是單純在 CPU 內部劃個邏輯區塊出來。它的實現關乎很多物理層面的設計，比如說其 AMBA3 AXI 系統匯流排需要針對每個讀寫通道增加額外的控制信號，用這個信號比特位來確認處理操作究竟是 Secure 還是 Non-secure。處理器的 Cache 也需要重新設計，需要多一個標記比特位。另外，處理具體工作的時候，如何在兩個「世界」間切換也是需要考慮的。

每家晶元製造商對於 TEE 的具體實施方案可能會存在很大差別，甚至不按照 ARM 的方案去做。具體到 Nexus 4 當年的高通驍龍 S4 Pro APQ8064，系統與安全世界微應用通訊的唯一途徑就是 /dev/qseecom 提供的控制介面。Android 應用如果想要與 QSEE 通訊，則載入專門的 libQSEEComAPI.so 庫，利用其函數給 QSEE 發出命令。如 QSEE keystore 應用會使用專門的加密密鑰塊，某些形式的主 KEK（master key-encryption key）會得到保護，用戶生成的密鑰則會以 KEK 進行加密。

敬畏信息技術的每一次改進

無論 ARM 的 TrustZone，還是蘋果版本的 Secure Enclave 都不是絕對安全的。前兩年的 GeekPwn 2016 黑客大賽上，美國的 Shellphish 團隊攻破華為 P9 Lite 的加密功能，也就是海思 Kirin 內部的 TrustZone，最終實現了用任意指紋來解鎖手機。高通的 QSEE 也被數度曝出漏洞。本質上都是抓住「安全世界」和「普通世界」通訊的切入點，一擊斃命。對此感興趣的可以參考先前某些大神分享的系列文章：《Exploring Qualcomms Secure Execution Environment》

但 ARM 在 TrustZone 安全白皮書中提過的安全理念很正確[8]，我在過去的文章中提過無數次：

• 任何一種設計出來的安全方案都不應該用「不可能被繞過」來形容，而應該這樣描述：「A 針對 B 資產的攻擊，至少需要耗費 Y 天，Z 美元的成本。」因為所有的安全措施，只要有足夠的時間和金錢都能被攻破。如果花費的時間和金錢成本太長太多，這樣的防禦就是成功的。
• 不僅攻擊複雜度高，而且攻擊方案無法簡單複製到其他同類設備之上，也就是說攻擊一台設備成功後，如果還想攻擊其他同類設備，則還需要付出同樣程度的勞動，這樣的防護也可以認為是成功的。

電子科技行業的任何一點進步，哪怕是體驗方面用戶無法察覺的一點小提升，其背後所需付出的努力都是海量的。如同現如今我們可以在諾基亞 X6 這樣的千元機上用上人臉解鎖的功能，即便它可能還需要在安全性上做提升。從 Android 4.0 到現如今人臉解鎖的變遷，其提升自然不光是體驗上的，即便第一階段的安全性依舊沒有解決得很好，第二階段的安全性改進卻是一步步可以看得到的。

當我們談「安全」這個話題的時候，即便每篇近萬字的籠統概括，也只能揪出其中的一個點來大致聊聊。這篇文章其實也就是隨意談了談 Android 和 iOS 系統在生物識別身份認證方面的一小部分投入，就已經值得我們花大量的時間去研究和深入了。如果你是個技術愛好者，請記得在探究哪怕是某些媒體所謂「癢點創新」的時候，都懷有一顆敬畏之心。

參考來源

[1]TrustFA: TrustZone-Assisted Facial Authentication on Smartphone

[2]Android 4.3 APIs - Google

[3]Credential storage enhancements in Android 4.3

[4]Full-Disk Encryption - Google

[5]Android Security Internals: An In-Depth Guide to Androids Security Architecture

[6]iOS Security - Apple

[7]Securing the Future of Authentication with ARM TrustZone-based Trusted Execution Environment and Fast Identity Online (FIDO)

[8]ARM Security Technology - Building a Secure System using TrustZone? Technology

• 轉載請註明來源周三科技，以及作者歐陽洋蔥

推薦閱讀：