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，可能會導致 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 進行硬體根層級的身分驗證，無一不包。這些多層式防禦措施可讓原始設備製造商兼顧進階功能更新能力，以及現代汽車環境所需的強大安全性。如需技術規格和實作詳細資料，請參閱 AAOS SDV 總覽頁面。