Android FBE的背景

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

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

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

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

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

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

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

使用TrustZone派生CE密鑰

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

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

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

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

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

使用Gatekeeper進(jìn)行身份驗(yàn)證

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

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

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

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

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

合成密碼

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

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

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

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

用于Gatekeeper的PoC

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

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

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

1.BL3，它被稱為小內(nèi)核（簡稱為LK），禁用Android驗(yàn)證啟動(dòng)檢查，因?yàn)槲覀兿胍獑?dòng)修改的Android映像；

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

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

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

為了實(shí)現(xiàn)Android Rooting，我們使用了Magisk。用修復(fù)的Gatekeeper TA替換它，我們只需要在SPU分區(qū)中創(chuàng)建一個(gè)新文件，然后Magisk的init程序在啟動(dòng)時(shí)將其安裝在現(xiàn)有文件的位置。這種方法的優(yōu)點(diǎn)是，它可以簡單地替換任何文件，因?yàn)槲覀冎恍枰獙⑺旁趶?fù)制目錄樹的SPU分區(qū)中。

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

修復(fù)TEEGRIS

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

TEEGRIS分為幾個(gè)鏡像：

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

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

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

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

總而言之，我們需要修復(fù)userboot。所以二進(jìn)制禁用驗(yàn)證的TZAR。然后，我們修復(fù)root_task以禁用TA的驗(yàn)證，這樣終于可以修復(fù)Gatekeeper了。

修復(fù)Gatekeeper

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

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

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

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

暴力破解憑證

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

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

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

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

利用安全芯片派生CE密鑰

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

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

使用Weaver進(jìn)行身份驗(yàn)證

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

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

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

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

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

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

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

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

Weaver的PoC

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

總結(jié)

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

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