最近因?yàn)橐恢痹谡{(diào)研獨(dú)立secure element集成的工作，不巧的是目前使用的高通平臺只有NFC-eSE的方案。高通目前也并不支持獨(dú)立的eSE集成，codebase中并無相對應(yīng)的代碼。舉個(gè)例子，目前使用的STM的一款eSE，但是這款eSE的開發(fā)STM還沒有完成（搞不清楚，為什么就可以被選來用于項(xiàng)目），STM需要將code release給到高通進(jìn)行validation的操作，高通集成進(jìn)codebase之后，才能使可用狀態(tài)，我理解這個(gè)也是進(jìn)Qualcomm PVL的基本方法。

說一下Keymaster，之前的項(xiàng)目上是有過Keymaster相關(guān)經(jīng)驗(yàn)的。Qualcomm SDM660的平臺(至少是Android6 launch）基于這個(gè)平臺，我們在Android N上launch了一個(gè)產(chǎn)品，產(chǎn)品為Gpc60，當(dāng)時(shí)對應(yīng)的keymaster1.0。通過觀察，ota包解壓后，里面有個(gè)兩個(gè)鏡像文件，keymaster.img

這里插一個(gè)Google version binding的項(xiàng)目：https://source.android.com/docs/security/features/keystore/version-binding?hl=zh-cn

通過綁定的系統(tǒng)版本和安全補(bǔ)丁信息，阻止針對攻擊的系統(tǒng)回滾！詳細(xì)的后面繼續(xù)深度研究一下 。?

將OTA包解壓后，內(nèi)容如下：

這里最大的內(nèi)容是，payload.bin文件，其它部分后面再看。通過，payload_dumper工具能夠?qū)ayload.bin 的內(nèi)容導(dǎo)出：

可以看到里面的keymaster.img，update engine能夠通過分區(qū)表中的分區(qū)名稱查找鏡像文件，并用來更新分區(qū)。分區(qū)表的內(nèi)容通常和Emergency download的tool中對應(yīng)的xml分區(qū)表是一致的。通常，分區(qū)表中內(nèi)容是由Qualcomm進(jìn)行定義的，codebase中自帶。

那好，這里留一個(gè)疑問，keymaster.img和androd.hardware.keymaster@1.0-service的關(guān)系是什么？

為弄清楚上面這個(gè)問題，繼續(xù)理解Qualcomm Android Security中的keymaster相關(guān)的技術(shù)。有幸經(jīng)歷了三個(gè)高通平臺和Android6~Android14的8個(gè)Android的OS的開發(fā)過程。就先從Android6的keymaster1開始。在Android6（M）中，我們可以看到，要支持keymaster，

首先要物理分區(qū)表進(jìn)行配置，早期都是使用的emmc作為存儲。配置如下：

<partition label="keymaster" size_in_kb="256" type="4F772165-0F3C-4BA3- BBCB-A829E9C969F9" bootable="false" readonly="false" filename="keymaster.mbn" />
?

這里還涉及tz和metadata的內(nèi)容，tz的具體內(nèi)容暫時(shí)先不看，主要看下metadata。分區(qū)表中，有單獨(dú)的metadata的分區(qū)配置，但是目前也不是很清楚具體的作用，暫時(shí)按下不表。但是，可以了解一下vbmeta。

vbmeta 是Android 8.0 以后引入的一個(gè)機(jī)制，用于保證系統(tǒng)啟動過程的完整性和安全性。 vbmeta 是一個(gè)包含數(shù)字簽名的元數(shù)據(jù)文件，其中記錄了系統(tǒng)啟動過程中需要校驗(yàn)的boot、recovery、system 和vendor 分區(qū)的完整性信息，以及用于校驗(yàn)這些分區(qū)完整性的公鑰。在分區(qū)表中通常由如下的分區(qū)設(shè)定：

<partition?label="vbmeta_a"?size_in_kb="64"?type="4b7a15d6-322c-42ac-8110-88b7da0c5d77"?bootable="false"?readonly="true"?filename="vbmeta.img"/>

<partition?label="vbmeta_b"?size_in_kb="64"?type="77036CD4-03D5-42BB-8ED1-37E5A88BAA34"?bootable="false"?readonly="true"?filename=""/>? //沒有文件名稱？

<partition?label="vbmeta_system_a"?size_in_kb="64"?type="1344859D-3A6A-4C14-A316-9E696B3A5400"?bootable="false"?readonly="true"?filename="vbmeta_system.img"/>

<partition?label="vbmeta_system_b"?size_in_kb="64"?type="FE3AB853-5B66-4D4A-BF85-8D90AF1C2C4A"?bootable="false"?readonly="true"?filename=""/> //沒有文件名稱？

看下verify boot是什么概念：先看看Google的相關(guān)概念，簡單的流程圖如下：

簡單的說就是簽名和驗(yàn)簽的過程， 確保用本公司自己的簽名工具簽過的image來啟動機(jī)器。簽名的過程就是獲取分區(qū)的摘要（摘要通常就是一個(gè)數(shù)據(jù)塊的hash值），使用私鑰對摘要進(jìn)行加密，并將加密文件和分區(qū)文件打包并刷到機(jī)器的磁盤中，例如mmc或者ufs中。

這里涉及到一個(gè)問題，這里的signature是存儲在哪個(gè)位置？通過相關(guān)文檔，發(fā)現(xiàn)是存在了vbmeta.img中了；

驗(yàn)證（verify）的過程就比較簡單了，同樣對分區(qū)取摘要為摘要A，對簽名進(jìn)行解密得到之前簽名時(shí)的分區(qū)鏡像文件的摘要為摘要B，對A/B進(jìn)行比較，如果摘要一直，那么驗(yàn)簽成功。針對Android的Verified boot后面要重點(diǎn)講一下。

這里繼續(xù)keymaster的故事，看一下一些名稱需要理解和記憶：

AndroidKeystore?是供應(yīng)用訪問 Keystore 功能的 Android Framework API 和組件。它是作為標(biāo)準(zhǔn) Java Cryptography Architecture API 的擴(kuò)展程序?qū)崿F(xiàn)的，包含在應(yīng)用自己的進(jìn)程空間中運(yùn)行的 Java 代碼。AndroidKeystore?通過將與密鑰庫行為有關(guān)的應(yīng)用請求轉(zhuǎn)發(fā)到密鑰庫守護(hù)程序執(zhí)行這些請求。//最好自己寫一下測試app進(jìn)行調(diào)試看看；

密鑰庫守護(hù)程序是 Android 系統(tǒng)中的一個(gè)守護(hù)程序，該程序通過?Binder API?提供對所有密鑰庫功能的訪問權(quán)限（java的后端，AIDL）。密鑰庫守護(hù)程序負(fù)責(zé)存儲“密鑰 blob”。密鑰 blob 中包含已加密的實(shí)際密鑰材料，因此密鑰庫可以存儲這些材料，但無法使用或顯示這些材料。(比如說？)

keymasterd?是一個(gè) HIDL 服務(wù)器，可提供對 Keymaster TA 的訪問權(quán)限。（此名稱未進(jìn)行標(biāo)準(zhǔn)化，僅用于說明概念。）（keymaster@1.0-service.rc/?keymaster@4.0-service.rc/keymaster@3.0-service). e.g :keymaster@3.0-service, 這個(gè)便是keymasterd的一個(gè)實(shí)例。

Keymaster TA（可信應(yīng)用）是在安全環(huán)境（大多數(shù)情況為 ARM SoC 上的 TrustZone）中運(yùn)行的軟件。它可提供所有安全的密鑰庫操作，能夠訪問原始密鑰材料，在密鑰上驗(yàn)證所有訪問權(quán)限控制條件，等等。（ps操作命令可以能訪問到嗎？肯定是不能夠的，因?yàn)檫\(yùn)行在TEE中）；

LockSettingsService?是負(fù)責(zé)用戶身份驗(yàn)證（包括密碼和指紋）的 Android 系統(tǒng)組件。它不是密鑰庫的一部分卻與其相關(guān)，因?yàn)楹芏嗝荑€庫密鑰操作都需要對用戶進(jìn)行身份驗(yàn)證。LockSettingsService?與 Gatekeeper TA 和 Fingerprint TA 進(jìn)行交互以獲取身份驗(yàn)證令牌，并將其提供給密鑰庫守護(hù)程序，這些令牌最終將由 Keymaster TA 應(yīng)用使用。

Gatekeeper TA（可信應(yīng)用）是在安全環(huán)境中運(yùn)行的另一個(gè)組件，它負(fù)責(zé)驗(yàn)證用戶密碼并生成身份驗(yàn)證令牌（用于向 Keymaster TA 證明已在特定時(shí)間點(diǎn)完成對特定用戶的身份驗(yàn)證）。

Fingerprint TA（可信應(yīng)用）是在安全環(huán)境中運(yùn)行的另一個(gè)組件，它負(fù)責(zé)驗(yàn)證用戶指紋并生成身份驗(yàn)證令牌（用于向 Keymaster TA 證明已在特定時(shí)間點(diǎn)完成對特定用戶的身份驗(yàn)證）

繼續(xù)回到上面的問題：keymaster.img和androd.hardware.keymaster@1.0-service的關(guān)系是什么？手邊剛好有Android12 的代碼作為O設(shè)備的launch的設(shè)備MR。 對應(yīng)的service是android.hardware.keymaster@3.0-service。對應(yīng)的partition.xml內(nèi)容如下：

那就要看看keymaster64.mbn的編譯腳本，就可以知道keymaster64.mbn的內(nèi)容。但開始可以確認(rèn)的是，android.hardware.keymaster@3.0-service 是屬于vendor分區(qū)的一部分，會被打包到vendor.img中。有點(diǎn)意思，keymaster64.mdn的內(nèi)容到底是啥？（引導(dǎo)加載密鑰?）

從高通得知，這個(gè)是高通平臺封裝的TA，是通過編譯腳本打包進(jìn)ROM包中。有一個(gè)問題是，那么TEE的整個(gè)運(yùn)行環(huán)境是如何更新的？文章來源地址http://www.zghlxwxcb.cn/news/detail-840288.html

到了這里，關(guān)于我的NPI項(xiàng)目之Android 安全系列 -- Keymaster到底是個(gè)什么的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！