AAOS SDV - 融入安全考量的設計

Google 認為產品應具備安全設計，因此我們以現有的市場驗證平台為基礎，運用 Cuttlefish 等虛擬化技術，建構 Android Automotive OS for Software Defined Vehicle (AAOS SDV)。雖然我們的版本公告著重於功能，但這篇網誌文章概述了一些安全性概念。

基礎：網域隔離

透過虛擬化技術隔離共同託管的執行個體

目前趨勢是將電子控制單元 (ECU) 整合至單一晶片，這會讓多個網域並排執行，降低隔離效果。

雖然 AAOS SDV 執行個體提供內部隔離機制，但通常最好獨立執行邏輯網域。舉例來說，叢集和資訊娛樂系統有不同的需求。我們使用虛擬機器平行執行多個執行個體，確保共用行為明確，且預設行為是隔離。

沿用 Android 安全性

AAOS SDV 是從 Microdroid 演變而來，這是一種經過最佳化的極簡 Android 版本，適用於隱私權虛擬機器 (pVM)。這項血統為 Android 平台工程師提供他們已知的既定安全防護功能。

程序隔離和預設拒絕

AAOS SDV 遵循 Android 的使用者 ID (UID) 隔離模型，為每個應用程式設定沙箱。每項服務都在專屬程序中執行，並具有專屬 UID，用於管理存取權、資料目錄和其他限制。我們採用可攜式作業系統介面 (POSIX) 功能，嚴格限制作業，並搭配安全增強式 Linux (SELinux) 執行「預設拒絕」策略。這種做法可將每項服務限制在絕對必要的範圍內，也就是說，缺少設定會導致存取權遭封鎖，而非建立權限過多的系統。我們也將這項策略套用至通訊權限系統，詳情請參閱本文後續說明。

經實證的安全漏洞管理

AAOS SDV 整合了 Android 成熟的安全應變和安全漏洞管理基礎架構，可識別、分類、修正及揭露安全發現。這個生命週期包含持續自動掃描、年度深入滲透測試，以及透過 Android 安全性弱點回報程序取得的合作夥伴情報。安全團隊會對發現的安全漏洞進行分類、根據風險指派嚴重性評等，並追蹤修復進度，直到完成為止。我們透過每月的 Android 安全性公告，協調揭露和發布政策，並定期進行嚴格的安全稽核和全面的架構審查，確保平台長期保持韌性。

完整性：安全推送軟體

除了確保程序隔離外，安全平台也必須在執行前確保程式碼完整性。我們透過下列方式確保軟體推送安全：

經過驗證的軟體推送

AAOS SDV 提供兩種安裝方法。首先，我們會直接將軟體安裝到唯讀系統、產品或供應商分區，每次啟動時都會驗證簽章。確保基本系統元件安全無虞。

其次，我們使用 Android Pony EXpress (APEX) 套件提供服務。每個 APEX 都會封裝軟體及其依附元件，並將套件視為具有強制簽章驗證的分區。在 AAOS SDV 中，APEX 會將程式碼簽署視為持續性的硬體強制合約。APEX 透過四大核心支柱，確保惡意程式碼執行作業獲得緩解：

1. 不可變的儲存空間

• 機制：Android 核心會使用唯讀回送，將 apex_payload.img 檔案直接迴圈為原始儲存裝置，並使用嚴格的 MS_RDONLY 旗標掛接。
• 為什麼這個方式更安全：由於檔案不會解壓縮到車輛的儲存空間，因此不會向 OS 公開任何寫入路徑。即使攻擊者取得根權限，也無法修改執行中的 APEX 程式碼，因為檔案系統層會拒絕所有寫入指令。

2. 加密完整性

• 機制：密碼編譯簽章會驗證整個檔案系統映像檔的默克爾樹。
• 安全性更高的原因：核心會使用個別區塊的 dm-verity，即時驗證每個 4KB 資料區塊的簽章。如果攻擊者修改快閃記憶體上的原始區塊，核心會偵測到雜湊不符，並立即停止執行。

3. 嚴格隔離

• 機制：這會套用「程序隔離」一節所述的程序隔離規則，建立沙箱，並將 APEX 掛接為 /apex 下的專屬分區。
• 安全性更高的原因：每項服務都有專屬的使用者和資料目錄，除非明確共用，否則無法存取。Android 會建立專屬分割區，確保只有明確公開的程式庫可從非具備權限的系統精靈存取，進而縮小攻擊面。

4. 原子復原

• 機制：APEX 採用「Active/Backup」設計，可啟用雙緩衝區回溯。出廠預先安裝的 APEX 會保留在不可變更的 /system 分區，而更新則會位於可變更的 /data 分區。
• 安全性更高的原因：如果更新失敗或疑似惡意，apexd daemon 會在提早啟動期間將其標示為「失敗」。系統會立即將符號連結切換回 /system 分區。這種原子復原機制有助於確保系統不會維持在損壞狀態。

復原力：記憶體安全開發

經過驗證的載入程序可防止系統遭到外部修改，但平台韌性也取決於基礎程式碼的建構方式。針對為 AAOS SDV 開發的新元件，我們優先考量記憶體安全。

以 Rust 做為主要語言

AAOS SDV 的目標是小型系統，且必須快速推出，因此無法在完整的 Android 堆疊上建構，我們也將範圍限制在原生架構。為了建立分散式系統所需的基礎架構，我們除了現有基礎架構外，還開發了多個元件，並採用 Rust 做為主要語言。我們也使用 Rust 開發服務的商業邏輯，協助合作夥伴編寫安全的軟體。Rust 採用記憶體安全功能，可防範常見的記憶體安全漏洞，同時支援團隊在編寫原生程式碼時的處理量。

分散式信任：網路與存取控管

軟體定義車輛需要隔離網域之間的安全互動。AAOS SDV 網格佈建架構會以加密方式驗證每個通訊端點的版本和作者，解決這項複雜問題。

裝置和網狀網路佈建

AAOS SDV Mesh 會以數學方式將每個元件的網路身分繫結至實際的二進位執行狀態，藉此建立驗證。這個模型會以硬體根層級驗證取代隱含的軟體信任。

網狀架構驗證採用持續加密機制，舉例來說，車輛閘道等服務可能會因為資訊娛樂 VM 具有正確的 IP 位址，而信任遭入侵的 VM，但這項機制可避免這種情況發生。

硬體強制隔離和自動隔離通訊協定可保護平台安全。SDV 網格內的對等互連裝置會使用 DICE 型驗證和認證 (詳情請參閱下一節)，協助識別及遏止未經授權的執行程式碼或設定竄改行為。

以 DICE 為基礎的 TLS，可確保 VM 間的通訊安全

確認主持人身分

DICE (裝置 ID 組合引擎) 的黃金法則：如果韌體中的單行程式碼發生變更 (即使是微幅更新或惡意攻擊)，衍生的複合裝置 ID (CDI) 就會完全改變，產生完全不同的別名金鑰。

DICE 和傳輸層安全標準 (TLS) 整合後，可解決零信任架構的基本難題：驗證機器身分，同時驗證軟體完整性。

DICE 採用專屬硬體的識別功能和 TLS 的加密交握功能結合後，接收端電腦就能驗證呼叫端的身分和確切軟體狀態。

傳統憑證只能證明擁有密鑰，無法偵測韌體是否遭到竄改。DICE 透過測量啟動分層解決這個問題：

• 專屬裝置密鑰 (UDS)：製造期間產生的隨機加密密鑰。只有第一階段的開機載入程式可以存取 UDS，其他軟體和外部介面都無法存取。
• 分層測量 (複合裝置 ID)：硬體 ROM 會使用下一個韌體層的確切程式碼和設定對 UDS 進行雜湊處理，藉此啟動鏈結。這會建立 CDI，然後在後續各層啟動時依序鏈結。

AAOS SDV 網格中的服務互動受到嚴格的存取控管。與所有 AAOS SDV 軟體一樣，這些存取控管機制會經過驗證，且其完整性會在裝置層級和網狀網路中的裝置之間，透過 DICE 驗證機制受到保護。

分層存取控管

AAOS SDV 採用縱深防禦策略，可在不影響存取機制的情況下，動態更新車輛。這個模型仰賴兩個主要信任層：

1. 服務層級權限：定義特定 VM 上的服務可存取或公開的網格資源。
2. VM 層級權限：為特定 VM 上代管的所有服務定義跨 VM 通訊界線。

這個模型可讓原始設備製造商在安全性和可更新性之間取得平衡。對於非安全性敏感服務，寬鬆的 VM 層級政策可透過輕量 APEX 更新進行安裝，而非完整重新部署 VM。

反之，安全敏感信號的權限必須硬式編碼至每個 VM。缺點是，如果要在新的 VM 導入安全敏感服務，就必須在整個系統中更新 VM 層級權限。因此必須更新網格中的所有 VM。

結論

AAOS SDV 擴充 Android 的安全架構，透過安全設計方法滿足特定汽車業需求。這個平台運用虛擬化技術隔離網域，並強制執行「預設拒絕」存取政策，為軟體定義車輛打造彈性環境。透過硬體強制執行的即時驗證，確保執行程式碼的加密完整性。

該平台整合了持續的安全生命週期，從主動的安全漏洞管理，到透過 DICE 進行硬體根源的身分驗證，這些多層防禦機制可讓原始設備製造商 (OEM) 在進階功能更新能力與現代汽車環境所需的強大安全性之間取得平衡。如需技術規格和導入詳情，請參閱 AAOS SDV 總覽頁面。