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. 密碼編譯完整性

• 機制：加密簽章會驗證整個檔案系統映像檔的 Merkle 樹狀結構。
• 安全性更高：核心會使用每個區塊的 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 總覽頁面。