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

Google 認為產品應具備安全設計，因此我們在現有經市場驗證的平台上，建構軟體定義車輛專用的 Android Automotive 作業系統 (AAOS SDV)，並運用 Cuttlefish 等虛擬化技術。雖然我們的版本公告著重於功能，但這篇網誌文章會概述一些安全性概念。

基礎：網域隔離

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

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

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

沿用 Android 安全性

AAOS SDV 是由 Microdroid 演變而來，Microdroid 是專為隱私虛擬機器 (pVM) 最佳化的精簡版 Android。這項血統為 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 建立專屬分區後，會建立專屬連結器命名空間，確保只有明確公開的程式庫可供非授權系統 Daemon 存取，盡可能縮小攻擊面。

4. 原子復原

• 機制：APEX 採用「主動/備份」設計，可啟用雙緩衝復原。原廠刷寫的 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 對 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 通訊邊界。

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

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

結論

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

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