Android FBE的背景

我們將在本文介紹分析靜態(tài)數(shù)據(jù)加密。Android FBE是Android Full Disk Encryption的簡稱,是一種安全機制,用于對Android設(shè)備的所有數(shù)據(jù)進行加密,保護用戶的個人隱私和敏感數(shù)據(jù)。 

簡而言之，此功能允許永遠不以明文形式存儲文件，以防止攻擊者通過簡單地提取存儲設(shè)備來讀取它們。相反，文件在加載到內(nèi)存中時（例如，通過文本編輯器）會自動解密，并在寫回磁盤時再次加密。這要歸功于操作系統(tǒng)的支持，Android歷來使用兩種方法：全磁盤加密（FDE）和基于文件的加密（FBE）。顧名思義，基于文件的加密在文件級工作。也就是說，每個文件都有自己的密鑰，并且可以獨立于其他文件進行解密。Android依賴于Linux內(nèi)核特性fscrypt來實現(xiàn)這一點，該特性在Ext4和F2FS等各種文件系統(tǒng)中都得到支持。在為目錄樹獲得主密鑰之后，系統(tǒng)將為文件、目錄和符號鏈接檢索單獨的密鑰。

由于采用了文件級方法，F(xiàn)BE實現(xiàn)非常精確。Android利用這一點將文件劃分為兩個加密級：

設(shè)備加密（DE）：文件在啟動后立即可用；

憑證加密（CE）：文件只有在用戶進行身份驗證后才可用（這是用戶數(shù)據(jù)的選擇級別）。

在啟動設(shè)備時自動派生DE密鑰，考慮到這一點以及它所保護的數(shù)據(jù)類型，從攻擊者的角度來看，它并不是特別有趣。然而，值得注意的是，這是直接啟動功能的基礎(chǔ)，允許在用戶進行身份驗證之前解鎖設(shè)備的某些功能，比如警報。

盡管如此，由于攻擊者的目標可能是檢索私有數(shù)據(jù)，因此本文主要關(guān)注CE密鑰。派生它的步驟相當復雜，過程從系統(tǒng)擁有的一些DE保護文件（在/data/system_DE//spblob中）開始。最終密鑰的原始字節(jié)實際上是從憑證的原始字節(jié)派生出來的。盡管過程復雜，但這意味著無論攻擊者可以利用多少漏洞，他們?nèi)匀恍枰┝ζ平鈶{證以將其提供給密鑰派生過程。

使用TrustZone派生CE密鑰

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

上圖顯示了派生CE密鑰所需的不同組件是如何鏈接在一起的。如上所述，這是一個相當復雜的過程，所以我們建議在一個單獨的選項卡中打開圖片。對于沒有配備安全芯片的設(shè)備，密鑰派生來自兩個不同的受保護組件：

特權(quán)用戶（system或root）擁有的文件：普通用戶無法訪問；

TEE保護密鑰：這些密鑰只能在TEE內(nèi)部由Keymaster應(yīng)用程序使用。這些密鑰也是與身份驗證綁定的，因此只有在用戶成功通過身份驗證時才能使用它們。

這意味著攻擊者應(yīng)該能夠提升權(quán)限并篡改可信執(zhí)行環(huán)境，以便提取密鑰或能夠在身份驗證之前使用密鑰。為此，我們有必要了解Gatekeeper如何進行身份驗證。

使用Gatekeeper進行身份驗證

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

Gatekeeper是TEE中經(jīng)常出現(xiàn)的可信應(yīng)用程序（TA）之一，通過與相應(yīng)的Android守護進程以及硬件抽象層通信，它在驗證用戶的身份驗證憑證方面發(fā)揮著關(guān)鍵作用。請注意，Gatekeeper僅通過PIN/密碼/模式參與身份驗證，而其他TA用于支持生物識別。盡管如此，當用戶在啟動設(shè)備時首次進行身份驗證時，他們無法使用生物識別技術(shù)，原因恰恰與數(shù)據(jù)加密有關(guān)。

Gatekeeper實現(xiàn)了兩個概念上簡單的命令：Enroll和Verify。通常在用戶首次設(shè)置身份驗證因素或更改身份驗證因素時調(diào)用Enroll。該命令接受一個所謂的密碼（pwd） blob，對其進行簽名，然后返回，將其轉(zhuǎn)換為密碼句柄。密碼blob是從憑證創(chuàng)建的，憑證首先使用scrypt進行擴展，然后與哈希字符串組合。用于簽名所提供的密碼的密鑰是Gatekeeper的內(nèi)部密鑰，用于驗證憑證。這樣的功能是通過Verify命令實現(xiàn)的，而在用戶嘗試進行身份驗證時調(diào)用該命令。顧名思義，它驗證當前身份驗證嘗試的密碼blob是否有效。它通過計算其HMAC并將其與原始密碼句柄進行比較來實現(xiàn)這一點，原始密碼句柄也與命令一起發(fā)送。

Scrypt是一個密鑰派生函數(shù)，在這種情況下，它通過需要大量內(nèi)存來減緩自定義硬件攻擊。它的參數(shù)與憑證的鹽值一起存儲在一個文件中。這意味著每次身份驗證嘗試的延遲可以忽略不計，但卻讓需要多次進行身份驗證的攻擊者減慢了速度。

如果身份驗證成功，Gatekeeper將創(chuàng)建一個身份驗證（auth）令牌。這是一個標準格式的簽名令牌（如AOSP中指定的），旨在防止重放攻擊。此令牌證明用戶已通過身份驗證，需要發(fā)送給Keymaster TA以解鎖綁定身份驗證的密鑰。如果身份驗證嘗試失敗，Gatekeeper的節(jié)流機制就會啟動，使暴力破解變得不可能。這是與實現(xiàn)相關(guān)的，但通常TA存儲有關(guān)每個失敗請求的時間的信息，并在此類失敗請求的頻率變得可疑時開始返回錯誤。當用戶再次成功進行身份驗證時，計數(shù)器將重置。

合成密碼

用戶通過身份驗證后，系統(tǒng)就有了一個有效的applicationId。在真正成為CE密鑰之前，還需要經(jīng)過幾個步驟。對我們來說，第一個也是更有趣的是合成密碼的推導過程。檢索到這些信息后，還有許多一些操作，但是這些步驟不需要用戶或某些受信任的組件提供任何信息。

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

合成密碼存儲在Android文件系統(tǒng)中，必須用兩個不同的密鑰解密。第一個是存儲在Android Keystore中的常規(guī)密鑰，該密鑰受TEE保護并綁定身份驗證。由于這些密鑰永遠不會離開TEE，因此它們以加密形式存儲，并且需要在Keymaster TA中進行解密。除此之外，如上所述，只有當命令還包含先前由Gatekeeper生成的驗證令牌并且仍然有效時，才能使用它們。一旦在TEE中完成了第一次解密，就使用哈希的applicationId作為密鑰再次解密中間緩沖區(qū)。注意，這里的AES是使用GCM模式完成的，如果密鑰出現(xiàn)問題，則由于標記不匹配而導致操作失敗。

此時，攻擊者基本上需要完成三件事才能恢復CE密鑰。首先，他們需要能夠檢索特權(quán)用戶擁有的文件，這很可能是利用了一個包含多個漏洞的內(nèi)核漏洞。然后，他們還必須篡改TEE，要么從Keymaster泄露所需的密鑰，要么攻擊Gatekeeper中的憑證驗證和認證令牌生成。最后，他們需要對獲得的信息執(zhí)行暴力破解。

用于Gatekeeper的PoC

研究人員在三星A22設(shè)備（更準確地說是在A226B和A225F）上實現(xiàn)了PoC，這些設(shè)備使用來自Mediatek 的兩個易受攻擊的SoC： MT6769V和MT6833V，可以使用MTKClient利用。該工具與下載模式（類似于高通soc上的EDL模式）交互，該模式暴露了一個USB接口，該接口最初用于在其上執(zhí)行支持操作（例如刷新固件）。要觸發(fā)該漏洞，就必須物理訪問，并且在某些設(shè)備（如A225F）上，必須在設(shè)備PCB上短路兩個引腳才能進入下載模式。一旦設(shè)備以正確的模式啟動，該工具利用Boot ROM漏洞，然后修改BL2（在Mediatek 啟動模式中稱為preloader）以禁用下一個安全啟動檢查，最后將其加載到設(shè)備上并在其上啟動。

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

但要實現(xiàn)攻擊，就需要修復以下組件：

1.BL3，它被稱為小內(nèi)核（簡稱為LK），禁用Android驗證啟動檢查，因為我們想要啟動修改的Android映像；

2.Android系統(tǒng)（在本示例中為啟動鏡像），授予我們root訪問權(quán)限，并修改供應(yīng)商分區(qū)中存在的Gatekeeper Trusted應(yīng)用程序；

3.TEE操作系統(tǒng)（稱為TEEGRIS）禁用對受信任應(yīng)用程序的驗證。

獲得Android系統(tǒng)最高權(quán)限（Android Rooting）

為了實現(xiàn)Android Rooting，我們使用了Magisk。用修復的Gatekeeper TA替換它，我們只需要在SPU分區(qū)中創(chuàng)建一個新文件，然后Magisk的init程序在啟動時將其安裝在現(xiàn)有文件的位置。這種方法的優(yōu)點是，它可以簡單地替換任何文件，因為我們只需要將它放在復制目錄樹的SPU分區(qū)中。

一旦完成，我們就可以對設(shè)備進行root訪問，然后使用它來訪問CE密鑰派生中涉及的文件。

修復TEEGRIS

TEEGRIS是三星設(shè)計的TrustZone操作系統(tǒng)，可以在Exynos和Mediatek 的soc上找到。它的設(shè)計和逆向工程已經(jīng)被介紹了很多次，所以本文只關(guān)注我們需要修復的部分來實現(xiàn)我們的目標：執(zhí)行修改后的TA。在本文的示例中，我們決定修復Gatekeeper，以繞過句柄驗證并始終生成有效的驗證令牌。

TEEGRIS分為幾個鏡像：

tee1.img：它包含Arm Trusted Firmware（在監(jiān)視器模式下以最高權(quán)限執(zhí)行-EL3）、Secure World內(nèi)核和一個名為userboot.so的二進制文件。最后一個對我們來說非常重要，因為它用于加載和驗證TEEGRIS的根文件系統(tǒng)。

tzar.img：這是TEEGRIS的根文件系統(tǒng)，以逆向工程的自定義壓縮格式存儲。它包含可供其他庫使用但也可供TA使用的庫，以及二進制文件，其中包括一個名為root_task的二進制文件，負責驗證和運行Android提供的TA。

super.img：它是包含幾個邏輯分區(qū)的Android主分區(qū)。其中之一是供應(yīng)商分區(qū)，包含大多數(shù)TA，包括Gatekeeper。

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

總而言之，我們需要修復userboot。所以二進制禁用驗證的TZAR。然后，我們修復root_task以禁用TA的驗證，這樣終于可以修復Gatekeeper了。

修復Gatekeeper

Gatekeeper用于驗證用戶的憑證。驗證使用密鑰派生函數(shù)（KDF）生成一個惟一的值，然后可以將該值與作為參數(shù)傳遞的預(yù)期值進行比較。在Trusty TEE實現(xiàn)中，KDF實際上是一個使用內(nèi)部密鑰的HMAC。對于TEEGRIS來說，KDF似乎是一個自定義的，顯然是在加密驅(qū)動程序中實現(xiàn)的，至少在基于exynos的設(shè)備上，它依賴于內(nèi)部加密處理器。

如果憑證匹配，Gatekeeper生成一個auth_token并將其發(fā)送回Android，以便它可以附加到Keymaster請求。需要注意的是，這是Keymaster解密身份驗證綁定密鑰所必需的，例如加密的合成密碼。這里有幾個選項，但我們決定修復兩個值之間的比較，以確保接受任何憑證。這是可能的，因為auth_token生成機制不使用憑證中的任何位。由于進行過修改，每次我們輸入一些憑證時，Gatekeeper都會生成令牌并返回成功，使系統(tǒng)相信它可以繼續(xù)下一步來解鎖設(shè)備。可以肯定的是，它不能用錯誤的憑證解密用戶數(shù)據(jù)。但是在嘗試之前，Keymaster任務(wù)必須執(zhí)行合成密碼的第一次解密（它被加密了兩次）。

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

我們可以按照這個辦法盜取第一個AES解密操作的結(jié)果。該設(shè)備是根設(shè)備，使用Frida，我們可以在SyntheticPasswordCrypto.decryptBlob中暫停請求該操作的system_server進程。檢索到該值后，我們就可以開始強制使用憑據(jù)了。

暴力破解憑證

暴力破解的代碼如下所示：

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

從設(shè)備加密的文件中檢索scrypt的參數(shù)。顧名思義，value_leaked_from_keymaster就是我們通過Frida盜取的值。由于此AES_Decrypt函數(shù)背后使用的GCM操作模式，如果密鑰是錯誤的，解密將失敗，我們知道我們需要選擇另一個密碼。如果成功，就意味著我們找到了正確的值。具體視頻請點此。

就性能而言，暴力執(zhí)行腳本肯定可以改進。如上所述，即使只是簡單地將它移動到一個一般功能的VM上，也有顯著的改進。使用專用硬件會有所不同，但這不是我們PoC的重點，我們更愿意把重點放在實現(xiàn)暴力執(zhí)行所需的過程上。

利用安全芯片派生CE密鑰

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

上圖顯示了使用安全芯片時如何派生CE密鑰。該模式與上一部分中介紹的模式非常相似，主要區(qū)別在于引入了一個名為Weaver的新組件，并用于生成applicationId。

使用Weaver進行身份驗證

Weaver是一個依賴于安全芯片來存儲密鑰和值的服務(wù)，每個值被分配到一個唯一的插槽。它公開了一個由三個命令組成的非常簡單的API：

Read：在輸入中提供插槽編號和密鑰，如果密鑰正確，則接收相關(guān)值；

write：提供要存儲的插槽編號、密鑰和值；

getConfig：檢索Weaver實現(xiàn)的配置信息。

與Gatekeeper類似，Weaver實現(xiàn)了一種節(jié)流機制，該機制在多次讀取嘗試失敗后生效。

在安全芯片的加持下，Android數(shù)據(jù)加密越來越難被竊取

當安全芯片可用時，使用scrypt生成的令牌將轉(zhuǎn)換為Weaver密鑰，然后將該密鑰與存儲在設(shè)備加密文件（/data/system_de/

最后，將令牌和哈希密鑰組合起來生成applicationId，從中派生出的CE密鑰與Gatekeeper模式中提供的密鑰相同。

Weaver的PoC

隨著安全芯片在越來越多的設(shè)備中變得越來越流行，Weaver是Android系統(tǒng)中相對較新的成員。在Quarkslab，研究人員花了很多時間研究Titan M芯片，這是谷歌在Pixel 3中引入的。

總結(jié)

Android磁盤加密絕對是一個突破性的功能，其安全性可以說是密不透風，設(shè)計者通過組合不同組件的功能，很好的保護了Android系統(tǒng)數(shù)據(jù)，攻擊者只有找到非常強大的漏洞才能發(fā)起攻擊。另外，受信任的芯片又把安全級別提高到了一個新的高度。

本文翻譯自：https://blog.quarkslab.com/android-data-encryption-in-depth.html如若轉(zhuǎn)載，請注明原文地址