Embedded System Security Live看到這個(gè)標(biāo)題先別急著把它翻譯成“嵌入式系統(tǒng)安全現(xiàn)場(chǎng)直播”。做設(shè)備安全的人應(yīng)該都有過(guò)這種體會(huì)真正讓你頭疼的不是買一套安全方案裝上就完事而是設(shè)備在真實(shí)環(huán)境里跑著跑著突然有一天跟你鬧脾氣——啟動(dòng)驗(yàn)證掛了、USB設(shè)備被策略攔死、CA證書裝不上、數(shù)據(jù)庫(kù)視圖又報(bào)權(quán)限錯(cuò)誤。我在最近一次給開發(fā)板做安全加固時(shí)一天之內(nèi)把這四類問(wèn)題挨個(gè)遇了一遍從華碩主板開機(jī)直接進(jìn)恢復(fù)界面到調(diào)試器插上電腦彈“當(dāng)前安全策略已阻止此USB設(shè)備”再到給Android模擬器 push 證書被 read-only 攔下。這篇文章就順著這四個(gè)現(xiàn)場(chǎng)講把嵌入式系統(tǒng)安全最核心的四層問(wèn)題——安全啟動(dòng)、運(yùn)行時(shí)訪問(wèn)控制、證書信任鏈、權(quán)限模型——一次講透。適合正在做嵌入式開發(fā)、物聯(lián)網(wǎng)設(shè)備研發(fā)的工程師也適合剛轉(zhuǎn)安全方向、想搞懂“設(shè)備安全到底在防什么”的讀者。1. 嵌入式安全不是“裝個(gè)鎖”從一次真機(jī)調(diào)試說(shuō)起1.1 安全事故的“遲到效應(yīng)”做嵌入式系統(tǒng)安全的第一步是接受一個(gè)反直覺的事實(shí)大部分安全問(wèn)題不會(huì)在你上線那天暴露。設(shè)備可能已經(jīng)在產(chǎn)線上穩(wěn)定跑了半年突然某天因?yàn)橐淮巫C書過(guò)期、一次OTA更新把信任庫(kù)刷壞、或者某個(gè)安全Agent進(jìn)程靜默退出問(wèn)題才真正浮出水面。這種“遲到效應(yīng)”特別容易讓人誤判因?yàn)樵O(shè)備平時(shí)看起來(lái)一切正常你以為安全配置是生效的實(shí)際上它可能在你不知道的時(shí)候已經(jīng)悄悄失效了。我在實(shí)際調(diào)試中越來(lái)越覺得“安全”不是一個(gè)靜態(tài)快照不是一個(gè)“開啟/關(guān)閉”的開關(guān)。Secure Boot 開著不代表信任鏈上的每個(gè)組件都被正確校驗(yàn)過(guò)USB策略配了不代表每個(gè)接口都按新策略執(zhí)行證書裝進(jìn)系統(tǒng)了不代表上層應(yīng)用真的走了系統(tǒng)信任庫(kù)的校驗(yàn)。安全狀態(tài)會(huì)漂移這是嵌入式設(shè)備運(yùn)維里最隱蔽的風(fēng)險(xiǎn)也是我強(qiáng)調(diào)“Live”這個(gè)視角的原因——安全不是一個(gè)瞬間動(dòng)作而是在設(shè)備持續(xù)運(yùn)行過(guò)程中不斷被驗(yàn)證、不斷被維護(hù)的動(dòng)態(tài)過(guò)程。1.2 一天之內(nèi)的四次“安全翻車”現(xiàn)場(chǎng)為了把問(wèn)題講具體我直接復(fù)盤我那次調(diào)試過(guò)程。設(shè)備是一塊跑Linux的開發(fā)板配套一臺(tái)Windows宿主機(jī)外加一個(gè)Android模擬器做聯(lián)動(dòng)測(cè)試。一天之內(nèi)我先后遇到四個(gè)故障宿主機(jī)開機(jī)直接進(jìn)恢復(fù)界面提示“啟動(dòng)策略變更”Secure Boot 顯示開啟但進(jìn)不了系統(tǒng)把調(diào)試器插到電腦上Windows 直接彈窗“當(dāng)前安全策略已阻止此USB設(shè)備”想給 Android 模擬器裝一個(gè)自簽 CA 證書用于調(diào)試adb push 到/system/etc/security/cacerts時(shí)報(bào) read-only導(dǎo)數(shù)據(jù)庫(kù)視圖時(shí)報(bào)了SQL SECURITY DEFINER相關(guān)錯(cuò)誤顯示definer賬戶不存在。這四個(gè)故障表面看毫不相關(guān)一個(gè)是 BIOS/UEFI 層一個(gè)是系統(tǒng)外設(shè)層一個(gè)是證書信任層一個(gè)是數(shù)據(jù)庫(kù)權(quán)限層。但它們背后的邏輯是同一件事——信任與權(quán)限。設(shè)備是否允許這段代碼運(yùn)行、是否允許這個(gè)設(shè)備接入、是否允許這個(gè)證書通過(guò)、是否允許這個(gè)賬戶執(zhí)行操作本質(zhì)都是“你的身份是否被當(dāng)前安全模型接受”。想通了這條主線排查思路一下就清晰了。1.3 一條主線啟動(dòng)鏈、運(yùn)行時(shí)、證書、應(yīng)用層權(quán)限順著這條“信任與權(quán)限”的主線我把嵌入式系統(tǒng)安全分成了四個(gè)層次。設(shè)備上電后的第一件事是啟動(dòng)鏈校驗(yàn)由 BootROM、Bootloader、內(nèi)核逐級(jí)驗(yàn)證簽名這是整個(gè)信任體系的地基系統(tǒng)跑起來(lái)之后運(yùn)行時(shí)訪問(wèn)控制接管 USB、外設(shè)、文件系統(tǒng)等資源的使用權(quán)限再往上設(shè)備與云端、設(shè)備與調(diào)試工具之間的通信依賴證書信任鏈來(lái)保證彼此身份可信最后應(yīng)用和數(shù)據(jù)層的權(quán)限模型決定了一個(gè)進(jìn)程、一個(gè)賬戶能對(duì)資源做什么操作。這四層不是孤立存在而是層層遞進(jìn)的。啟動(dòng)鏈一旦失守后面的所有安全機(jī)制都可以被繞過(guò)運(yùn)行時(shí)訪問(wèn)控制如果配置錯(cuò)誤會(huì)讓合法調(diào)試工具也無(wú)法使用證書信任鏈如果斷了設(shè)備會(huì)變成“誰(shuí)也不信”或者“誰(shuí)都信”兩個(gè)極端權(quán)限模型如果設(shè)計(jì)混亂應(yīng)用層就會(huì)出現(xiàn)各種“允許了但執(zhí)行不了”“執(zhí)行得了但權(quán)限過(guò)大”的怪問(wèn)題。后面的內(nèi)容我就按這四層逐個(gè)拆開講。2. Secure Boot 與信任根為什么“開了安全啟動(dòng)”還是進(jìn)不了系統(tǒng)2.1 華碩主板開機(jī)失敗Secure Boot 的 Enabled 狀態(tài)為什么不可信先說(shuō)我那個(gè)最直接的教訓(xùn)。機(jī)器是一塊華碩主板BIOS 里 Secure Boot Control 明明是 EnabledWindows 也裝得好好的但某天早上開機(jī)直接進(jìn)了恢復(fù)界面提示“啟動(dòng)策略變更系統(tǒng)無(wú)法正常啟動(dòng)”。當(dāng)時(shí)第一反應(yīng)是系統(tǒng)壞了后來(lái)才發(fā)現(xiàn)問(wèn)題出在 Secure Boot 的信任庫(kù)上。Secure Boot 的核心機(jī)制是用一組密鑰和簽名數(shù)據(jù)庫(kù)來(lái)約束啟動(dòng)過(guò)程Platform KeyPK是所有權(quán)的根相當(dāng)于你給大樓配的總鑰匙Key Exchange KeyKEK負(fù)責(zé)管理簽名數(shù)據(jù)庫(kù)的更新相當(dāng)于物業(yè)手里的鑰匙串DB 是白名單記錄允許啟動(dòng)的引導(dǎo)程序簽名DBX 是黑名單記錄已知惡意或已撤銷的簽名。計(jì)算機(jī)啟動(dòng)時(shí)固件會(huì)逐級(jí)驗(yàn)證引導(dǎo)程序簽名是否在 DB 白名單里、是否不在 DBX 黑名單里校驗(yàn)通過(guò)才放行。而問(wèn)題恰恰出在“數(shù)據(jù)庫(kù)更新”環(huán)節(jié)。華碩主板把 Secure Boot 分成 Standard 和 Custom 兩種模式Standard 模式由廠家維護(hù)默認(rèn)密鑰Custom 模式允許用戶自定義 PK/KEK/DB。我雖然在 BIOS 里開著 Secure Boot但之前為了調(diào)試一個(gè)老系統(tǒng)把模式切到了 Custom并替換了 Platform Key。系統(tǒng)更新時(shí)Windows 會(huì)嘗試更新 DB/DBX 數(shù)據(jù)庫(kù)但在 Custom 模式下新數(shù)據(jù)庫(kù)的更新請(qǐng)求需要用正確的 KEK 簽名而我沒有同步更新 KEK導(dǎo)致本地引導(dǎo)程序的簽名不在當(dāng)前信任列表里。最終結(jié)果是Secure Boot 狀態(tài)顯示 Enabled但信任鏈其實(shí)已經(jīng)斷裂系統(tǒng)自然進(jìn)不去。組件作用類比PKPlatform Key所有權(quán)的根控制 KEK 的更新大樓總鑰匙KEKKey Exchange Key管理簽名數(shù)據(jù)庫(kù)更新物業(yè)鑰匙串DB允許啟動(dòng)的簽名白名單員工門禁名單DBX禁止啟動(dòng)的簽名黑名單黑名單通緝令這次事故讓我徹底明白Secure Boot 的“Enabled”只是一個(gè)狀態(tài)標(biāo)志它只說(shuō)明“這個(gè)功能在運(yùn)行”不代表“信任鏈?zhǔn)峭暾摹?。你換了 PK卻沒同步 KEK 和數(shù)據(jù)庫(kù)系統(tǒng)照樣進(jìn)不去。很多嵌入式工程師遇到類似問(wèn)題第一反應(yīng)是關(guān)掉 Secure Boot 省事但這不是解決問(wèn)題的辦法正確做法是把密鑰管理納入系統(tǒng)更新的整體流程保證平臺(tái)密鑰、交換密鑰、簽名數(shù)據(jù)庫(kù)三者始終同步。2.2 嵌入式設(shè)備里的引導(dǎo)驗(yàn)證U-Boot、TF-A 與 AVB 的實(shí)際鏈路PC 上的 Secure Boot 是 UEFI 那一套嵌入式設(shè)備則更復(fù)雜但也更貼近“從零構(gòu)建信任鏈”。以我調(diào)試的這塊開發(fā)板為例用的是常見的 ARM 啟動(dòng)流程BootROM 固化在芯片內(nèi)部最先執(zhí)行接著是 TF-ATrusted Firmware-A的 BL1、BL2、BL31負(fù)責(zé)初始化內(nèi)存、加載 EL3 運(yùn)行時(shí)環(huán)境再往后是 U-Boot作為主流引導(dǎo)加載程序加載內(nèi)核和設(shè)備樹如果運(yùn)行 Android 或需要 AVBAndroid Verified Boot還會(huì)多一層 vbmeta 分區(qū)驗(yàn)證。每一步都需要校驗(yàn)下一級(jí)鏡像的簽名。BootROM 里燒錄了根公鑰BL1 的鏡像簽名由它驗(yàn)證BL2 加載 BL31 和 BL33U-Boot時(shí)用 bootchain 里的密鑰做驗(yàn)簽U-Boot 加載 kernel 時(shí)可以啟用 verified boot 機(jī)制要求內(nèi)核鏡像和 DTB 必須是經(jīng)過(guò)簽名的 fitImage。這個(gè)鏈條只要有一個(gè)環(huán)節(jié)沒有驗(yàn)簽或者簽名密鑰被換掉后面的代碼就可能被替換成惡意版本。我在實(shí)際配置 U-Boot 時(shí)最常踩的坑是CONFIG_CMD_AVB和CONFIG_ANDROID_AB這些宏沒有正確組合導(dǎo)致 vbmeta 校驗(yàn)沒有生效或者簽名鏡像和未簽名鏡像混用調(diào)試時(shí)把未簽名的內(nèi)核刷進(jìn)去也啟動(dòng)了看起來(lái)“沒問(wèn)題”其實(shí)整個(gè)簽名鏈已經(jīng)失效。嵌入式設(shè)備不像 PC 有成熟的系統(tǒng)更新機(jī)制很多團(tuán)隊(duì)把 Secure Boot 開起來(lái)就不再管了結(jié)果幾個(gè)月后要升級(jí)固件發(fā)現(xiàn)新鏡像沒有簽名又要重新燒 Bootloader。2.3 密鑰管理才是大頭開發(fā)密鑰、生產(chǎn)密鑰與回滾保護(hù)把 Secure Boot 真正用起來(lái)的難點(diǎn)不是開啟功能而是把密鑰生命周期管理好。第一次做簽名方案的工程師很容易陷入一個(gè)誤區(qū)拿開發(fā)期間的測(cè)試密鑰當(dāng)生產(chǎn)密鑰或者所有人共用一把簽名私鑰。這樣的結(jié)果就是私鑰泄露后沒有任何補(bǔ)救手段因?yàn)橐粋€(gè)密鑰被用來(lái)簽了所有的鏡像撤銷就等于整個(gè)系統(tǒng)重建。我建議從一開始就做密鑰分離。至少分成兩級(jí)平臺(tái)密鑰和應(yīng)用密鑰。平臺(tái)密鑰用于 BootROM 至 U-Boot 的基礎(chǔ)鏈路應(yīng)用密鑰用于內(nèi)核、設(shè)備樹、文件系統(tǒng)等更上層的鏡像。私鑰存放在 HSM 或芯片的 OTP 區(qū)域里生產(chǎn)環(huán)境不要讓它出現(xiàn)在開發(fā)機(jī)上開發(fā)機(jī)使用的測(cè)試密鑰和生產(chǎn)密鑰嚴(yán)格區(qū)分即使測(cè)試私鑰泄露也不影響生產(chǎn)設(shè)備。回滾保護(hù)同樣不能少RPMB 或 TPM NV 里維護(hù)一個(gè)回滾計(jì)數(shù)器每次升級(jí)把版本號(hào)遞增舊版本鏡像即使簽名有效也會(huì)被拒絕加載防止攻擊者把系統(tǒng)降級(jí)到存在已知漏洞的版本。實(shí)際踩坑后的體會(huì)是密鑰管理和更新機(jī)制最好在設(shè)備量產(chǎn)前就定義清楚否則后面補(bǔ)會(huì)非常痛苦。比如有些團(tuán)隊(duì)在產(chǎn)品發(fā)出去一兩年后才想加簽名驗(yàn)證卻發(fā)現(xiàn)還需要 OTA 升級(jí) Bootloader而沒有可信升級(jí)通道于是只能依賴產(chǎn)線返廠或現(xiàn)場(chǎng)刷機(jī)成本高得驚人。2.4 怎么確認(rèn)安全啟動(dòng)真的在干活正面測(cè)試與負(fù)面測(cè)試調(diào)試完了 Secure Boot我最想分享的一點(diǎn)是不要只看狀態(tài)位一定要做“正反兩向測(cè)試”來(lái)確認(rèn)簽名驗(yàn)證真的在攔截。正面測(cè)試很簡(jiǎn)單用已簽名的完整鏡像執(zhí)行一次正常啟動(dòng)觀察啟動(dòng)日志中是否出現(xiàn)類似 “Verification passed” 或 “Signature OK” 的字段。每個(gè) Bootloader 的日志位置不一樣但基本都會(huì)在加載下一級(jí)鏡像時(shí)打印驗(yàn)證結(jié)果。負(fù)面測(cè)試才是關(guān)鍵。把內(nèi)核鏡像里的一個(gè)字節(jié)改掉或者直接用未簽名鏡像重新打包然后嘗試啟動(dòng)。如果 Secure Boot 生效啟動(dòng)流程必須被卡住報(bào)簽名校驗(yàn)失敗如果設(shè)備照樣跑起來(lái)說(shuō)明驗(yàn)證路徑根本沒接通。做過(guò)負(fù)面測(cè)試之后你會(huì)對(duì)自己的信任鏈有信心得多。很多年前我們調(diào)試一個(gè)新平臺(tái)所有人以為簽了名結(jié)果發(fā)現(xiàn) BootROM 里的公鑰哈希和實(shí)際密鑰不匹配負(fù)面測(cè)試直接暴露了問(wèn)題如果沒做這一步設(shè)備到用戶手里過(guò)幾天就可能在某個(gè)更新后被刷成磚。3. 運(yùn)行時(shí)訪問(wèn)控制USB設(shè)備被安全策略攔下的完整排查鏈路3.1 插上調(diào)試器就被攔“當(dāng)前安全策略已阻止此USB設(shè)備”的現(xiàn)場(chǎng)調(diào)試器插上電腦第一時(shí)間不是滴一聲然后出現(xiàn)在設(shè)備管理器里而是彈出一個(gè)“USB device has been blocked by the current security policy”的提示。設(shè)備管理器里翻半天也看不到新設(shè)備或者看到了也是黃色感嘆號(hào)錯(cuò)誤代碼指向策略攔截。說(shuō)實(shí)話第一次遇到這個(gè)問(wèn)題我愣了一下因?yàn)檫@只調(diào)試器在另一臺(tái)機(jī)器上插得好好的沒有任何硬件故障跡象。這種攔截大多數(shù)時(shí)候并不是設(shè)備壞了而是當(dāng)前操作系統(tǒng)或管理策略環(huán)境不允許這個(gè) USB 設(shè)備接入。安全策略為什么要管 USB因?yàn)?USB 是物理攻擊和數(shù)據(jù)泄露最常見的入口一個(gè)惡意 USB 設(shè)備可以被識(shí)別成鍵盤輸入指令一個(gè) U 盤可以把內(nèi)部資料拷走。為了控制風(fēng)險(xiǎn)系統(tǒng)從設(shè)備安裝、存儲(chǔ)訪問(wèn)、設(shè)備類型等好幾個(gè)層面都設(shè)置了檢查點(diǎn)任何一個(gè)不滿足設(shè)備就會(huì)被攔在門外。3.2 三層攔截機(jī)制設(shè)備安裝策略、USB存儲(chǔ)隔離與設(shè)備自身策略我排查時(shí)會(huì)把 USB 被攔的問(wèn)題分成三個(gè)層次來(lái)定位。第一層是 Windows 的設(shè)備安裝限制Device Installation Restrictions。這是企業(yè) IT 最常用的策略通過(guò)組策略或 MDM 統(tǒng)一下發(fā)可以精確控制允許安裝的硬件 ID、設(shè)備類或設(shè)備實(shí)例路徑。如果你插入的調(diào)試器不在允許列表里或者策略配置成“阻止安裝其他策略未描述的設(shè)備”那么系統(tǒng)直接拒絕安裝驅(qū)動(dòng)設(shè)備自然無(wú)法工作。第二層是 USB 存儲(chǔ)隔離。很多公司的安全策略會(huì)限制可移動(dòng)存儲(chǔ)設(shè)備例如禁止寫入 U 盤、禁止掛載未知設(shè)備。這個(gè)策略的目的當(dāng)然是防數(shù)據(jù)泄露但它經(jīng)常誤傷調(diào)試器、TAP 設(shè)備、串口轉(zhuǎn)換器這類雖然長(zhǎng)得像外設(shè)但不是存儲(chǔ)設(shè)備的東西。還有一個(gè)隱蔽點(diǎn)某些策略會(huì)檢查設(shè)備的接口類型如果你的調(diào)試器恰好實(shí)現(xiàn)了大容量存儲(chǔ)接口可能被當(dāng)成 U 盤處理。第三層是設(shè)備自身的安全設(shè)置。嵌入式設(shè)備或 Android 設(shè)備往往有自己的訪問(wèn)控制例如 Android 的 USB 調(diào)試需要開發(fā)者選項(xiàng)確認(rèn)指紋某些鎖定 Bootloader 的設(shè)備還會(huì)校驗(yàn) USB 連接是否來(lái)自可信主機(jī)。在一些軍工、電力等對(duì)安全要求很高的場(chǎng)景設(shè)備會(huì)直接限制 USB 配置接口任何未授權(quán)的 USB 操作都會(huì)被拒絕。熱搜詞里那個(gè) “this action is not allowed with this security level configuration” 的提示我在設(shè)備端也遇到過(guò)意思就是當(dāng)前安全級(jí)別不允許這個(gè)操作通常需要先提升權(quán)限或切換安全配置文件。3.3 完整排查鏈路從事件日志到組策略結(jié)果集遇到 USB 被攔不要急著改策略先按下面的鏈路排查。第一步確認(rèn)攔截發(fā)生在主機(jī)側(cè)還是設(shè)備側(cè)。最簡(jiǎn)單的辦法是把同一個(gè)設(shè)備換到一臺(tái)沒有任何管控策略的干凈電腦上試一次。如果干電腦能正常識(shí)別問(wèn)題基本在主機(jī)側(cè)如果干電腦也報(bào)錯(cuò)那更可能是設(shè)備自身的問(wèn)題。第二步如果是主機(jī)側(cè)問(wèn)題在 Windows 上查看組策略結(jié)果集。運(yùn)行g(shù)presult /h report.html生成 HTML 報(bào)告后搜索“設(shè)備安裝”相關(guān)策略重點(diǎn)看是否啟用了“設(shè)備安裝限制”或“阻止其他策略未描述的設(shè)備”。有時(shí)候策略來(lái)自本地組策略有時(shí)候來(lái)自域或 MDM 平臺(tái)來(lái)源不同處理方式也不同。第三步打開事件查看器定位到設(shè)備安裝相關(guān)日志。Windows 在阻止設(shè)備安裝時(shí)會(huì)記錄設(shè)備安裝事件里面包含被阻止設(shè)備的硬件 ID 和攔截理由。拿到硬件 ID 之后去設(shè)備安裝限制策略里比對(duì)確認(rèn)這個(gè)設(shè)備是否在白名單范圍。第四步制定最小化放行方案。如果被攔的是合法調(diào)試工具可以精確放行該設(shè)備的硬件 ID 或者設(shè)備實(shí)例路徑而不是把整個(gè)設(shè)備安裝限制關(guān)掉。舉個(gè)例子如果策略阻止了“其他設(shè)備”你可以單獨(dú)添加一條允許規(guī)則用VID_xxxxPID_yyyy指定這只調(diào)試器。我見過(guò)有人圖省事直接把“設(shè)備安裝限制”策略停用結(jié)果一個(gè)同事把私人的 USB 攝像頭帶進(jìn)公司第二天安全部門就找上門了。正確的做法永遠(yuǎn)是開一個(gè)“只允許特定設(shè)備”的窗口而不是把整面墻拆掉。3.4 文件安全權(quán)限的姊妹坑“could not set file security for file”與“wrong security type”同樣屬于運(yùn)行時(shí)訪問(wèn)控制的還有一個(gè)高頻問(wèn)題就是往設(shè)備復(fù)制文件或給服務(wù)安裝目錄設(shè)置權(quán)限時(shí)報(bào) “could not set file security for file”。我第一次遇到這個(gè)報(bào)錯(cuò)是在給一塊開發(fā)板的 FAT 分區(qū)寫配置時(shí)Windows 報(bào)無(wú)法設(shè)置文件安全屬性。查了一圈發(fā)現(xiàn)FAT32/exFAT 這類文件系統(tǒng)根本上不支持 Windows 的 ACL 安全描述符系統(tǒng)想往文件上寫權(quán)限規(guī)則文件系統(tǒng)根本不認(rèn)。NTFS 下用得好好的 ACL到 FAT 分區(qū)上就成了“無(wú)效安全類型”。這個(gè)報(bào)錯(cuò)和“wrong security type”是姊妹問(wèn)題。簡(jiǎn)單來(lái)說(shuō)安全類型不匹配指你嘗試應(yīng)用的安全主體在目標(biāo)系統(tǒng)上無(wú)法被識(shí)別。好比你把一串印著某個(gè)制服標(biāo)識(shí)的鑰匙帶到另一個(gè)大門口門禁系統(tǒng)里根本沒有這個(gè)標(biāo)識(shí)的登記信息它自然不知道該怎么處理你的權(quán)限申請(qǐng)。排查思路很直接先看目標(biāo)文件系統(tǒng)支不支持 ACL再看目標(biāo)系統(tǒng)里是否存在當(dāng)前 SID 或用戶名的映射。嵌入式設(shè)備上尤其常見因?yàn)楹芏嘣O(shè)備分區(qū)采用非 NTFS 格式或者使用獨(dú)立的用戶體系和 Windows 的 SID 完全映射不上。解決方案分幾種如果只是為了在宿主機(jī)和設(shè)備之間傳文件把目標(biāo)分區(qū)換成支持 ACL 的文件系統(tǒng)或者干脆通過(guò) adb/scp 等工具傳文件不走 Windows 文件共享如果必須在設(shè)備上設(shè)置權(quán)限要使用設(shè)備自身的用戶體系和權(quán)限命令而不是在宿主機(jī)側(cè)設(shè)置安全屬性。嵌入式設(shè)備上很多權(quán)限管理必須“到現(xiàn)場(chǎng)做”跨系統(tǒng)的安全描述符千成不能直接搬。4. 證書信任鏈裝個(gè)CA證書怎么就撞上了read-only文件系統(tǒng)4.1 用 adb 裝證書被 read-only 擋下的那一刻調(diào)試設(shè)備 HTTPS 流量時(shí)最常用的操作是給測(cè)試設(shè)備裝一個(gè)自簽 CA 證書讓設(shè)備信任代理服務(wù)器的證書這樣才能抓到加密包內(nèi)容。我那次在 Android 模擬器上執(zhí)行adb push my-ca.crt /system/etc/security/cacerts/結(jié)果直接報(bào) “remote couldnt create file: read-only”也就是熱搜里那條mumu adb /system/etc/security/cacerts remote couldnt create file: read-only的完整場(chǎng)景。第一反應(yīng)是權(quán)限不夠于是adb root再試一次還是 read-only。這時(shí)候才反應(yīng)過(guò)來(lái)問(wèn)題不是權(quán)限而是這個(gè)分區(qū)本身就是只讀掛載。Android 系統(tǒng)證書目錄在/system/etc/security/cacerts/system分區(qū)在生產(chǎn)鏡像里默認(rèn)以只讀方式掛載這不是為了防止你裝證書而是為了保護(hù)系統(tǒng)完整性。如果任何進(jìn)程都能往系統(tǒng)目錄里寫文件那惡意軟件也能把自己的惡意 CA 證書塞進(jìn)去之后所有 TLS 流量都能被它劫持。所以系統(tǒng)鏡像的只讀屬性本身就是一條安全邊界。4.2 Android 證書存儲(chǔ)機(jī)制的兩次收緊從用戶證書到 APEX很多老工程師習(xí)慣用老辦法先拿到 root然后 remount 系統(tǒng)分區(qū)把證書 push 進(jìn)去重啟生效。這套流程在 Android 9 之前還行得通但 Android 系統(tǒng)的證書存儲(chǔ)機(jī)制已經(jīng)收得非常緊。用戶證書和系統(tǒng)證書是兩回事。通過(guò)設(shè)置里的“安裝證書”裝進(jìn)去的證書屬于用戶證書存儲(chǔ)只能被一部分應(yīng)用信任很多應(yīng)用為了安全默認(rèn)不信任用戶 CA。系統(tǒng)證書存儲(chǔ)位于/system/etc/security/cacerts全系統(tǒng)進(jìn)程都信任所以抓包工具都希望把證書裝到這里。Android 14 之后系統(tǒng) CA 證書被進(jìn)一步收進(jìn)了com.android.conscrypt這個(gè) APEXAndroid Package EXtension模塊。APEX 本身是一個(gè)只讀的、經(jīng)過(guò)簽名的系統(tǒng)組件包即使你adb root后 remount 成功看到的/system/etc/security/cacerts也是一個(gè)由 APEX 管理、運(yùn)行時(shí)可重置的內(nèi)容直接往里寫文件并不能穩(wěn)定生效。在模擬器上調(diào)試比較可靠的做法是啟動(dòng)時(shí)加-writable-system參數(shù)讓模擬器以可寫系統(tǒng)模式運(yùn)行再配合adb root和adb remount來(lái)修改證書目錄。在自有測(cè)試設(shè)備上最簡(jiǎn)單且合法的路徑是把證書安裝為“用戶證書”然后在應(yīng)用的網(wǎng)絡(luò)安全配置里手動(dòng)信任該用戶證書。雖然不如系統(tǒng)證書徹底但已驗(yàn)證場(chǎng)景足夠用。需要強(qiáng)調(diào)的是以上操作只適用于開發(fā)者自有測(cè)試設(shè)備生產(chǎn)環(huán)境中的設(shè)備證書必須通過(guò)工廠預(yù)置或正式的 OTA 更新機(jī)制絕不能在運(yùn)行現(xiàn)場(chǎng)用 root 硬塞證書那會(huì)徹底破壞設(shè)備的信任體系。4.3 設(shè)備端與云端信任驗(yàn)證別在兩端偷懶證書信任鏈的問(wèn)題不只出現(xiàn)在“往設(shè)備里裝證書”這一步。設(shè)備作為客戶端去訪問(wèn)云端時(shí)同樣需要校驗(yàn)服務(wù)端證書。我在不少項(xiàng)目里看到過(guò)這樣的代碼為了省事把 TLS 證書校驗(yàn)直接關(guān)掉或者設(shè)置一個(gè)“信任所有證書”的 SSLContext。開發(fā)階段這么干可以理解但如果帶著這個(gè)開關(guān)上生產(chǎn)等于讓設(shè)備裸奔——中間人輕輕松松就能把設(shè)備到云端的流量截走改指令、換固件、盜數(shù)據(jù)為所欲為。設(shè)備端校驗(yàn)證書我建議要么走系統(tǒng) CA 庫(kù)讓設(shè)備信任常見 CA 鏈同時(shí)一定要校驗(yàn)主機(jī)名hostname防止證書鏈雖然有效但簽給了另一個(gè)域名要么對(duì)特定的服務(wù)端證書做固定公鑰校驗(yàn)pinning把預(yù)期公鑰直接內(nèi)置到固件里。前者維護(hù)成本低但依賴 CA 體系的安全后者對(duì)公共服務(wù)器的證書輪換比較敏感需要提前設(shè)計(jì)好證書更新方案。兩種方式都要配套時(shí)間同步因?yàn)樽C書有效期驗(yàn)證依賴設(shè)備當(dāng)前時(shí)間很多設(shè)備 RTC 電池沒電或者從未做過(guò) NTP 同步結(jié)果證書明明沒過(guò)期設(shè)備卻一直報(bào)“證書無(wú)效”。4.4 證書排查三步法設(shè)備信任庫(kù)、應(yīng)用加載路徑、時(shí)間同步證書類問(wèn)題排查我總結(jié)了一個(gè)三層檢查法