網狀網路狀態和佈建

我們推出名為「SDV 開機模式」的新概念，可設為「已鎖定」或「已解鎖」，定義 SDV VM 中的 SDV 服務探索代理程式在嘗試連線至其他服務探索代理程式 (在其他 SDV VM 中執行) 時的行為，以建立安全網格。這與 Android 驗證開機程序現有的「裝置狀態」概念類似。

在佈建或更新車輛 VM 信任儲存區時，系統會運用 SDV 開機模式。

SDV 安全網格行為

服務探索網格可能會處於下列其中一種狀態，具體取決於收到的啟動值：正常、警告或嚴重錯誤。

只有在網格處於「正常」狀態時，車輛才會交到車主手中。如果沒有診斷介入，網格不可能從「正常」狀態變成「警告」狀態。在實際執行環境 (例如非開發/偵錯環境) 中，「警告」狀態只會在佈建期間發生。

「嚴重」是基本故障，類似於 Android 開機載入程式中system_ext映像檔的簽章驗證失敗。如果 SDV Mesh 僅因無線 (OTA) 更新而從「正常」轉換為「嚴重」，則該更新會被視為不良，且系統會回復為原始的「正常」版本。

以下各節將詳細說明這些狀態。

check 正常

• 從服務探索的角度來看，系統啟動是 SECURE。
• Service Discovery 只會連線至它認為已安全啟動的對等互連，因此它認為自己所屬的 SDV 安全網格安全無虞。

warning 警告

• 由於部分驗證程序已停用，系統開機程序可能遭到入侵。
• 服務探索只會連線至同樣停用驗證的對等互連裝置，因此屬於 SDV 安全網狀架構，具有與自身相同的安全性屬性。
• 對等互連啟動可能已成功或失敗，但由於本機故障 / 停用，因此無法驗證。
• 在開發環境或情況以外，這會產生下列影響：
  • 使用者資料不得提供。也就是說，SDV Secure 通訊不得傳輸或影響該資料。
  • 當網狀網路處於這種狀態時，只有佈建流程所需的服務才能使用。

error 嚴重

• 系統開機階段發生重大錯誤。
• 至少有一個基本故障或錯誤，導致 Service Discovery 代理程式無法建立網格。本機服務無法與遠端服務通訊。
• 從服務探索的角度來看，系統啟動是不安全的。

SDV 啟動模式

SDV 開機模式有兩種可能的值：UNLOCKED 和 LOCKED。就服務探索網格建立而言，「LOCKED」模式表示驗證錯誤是嚴重錯誤，而「UNLOCKED」模式則不是。

請注意，SDV 開機模式與 Android 的裝置狀態 (又稱 AVB 模式) 不同。SDV 開機模式會引導 SDV 安全網格的行為，以及網格連線錯誤是否為 FATAL。AVB 模式則會決定 Android 開機載入程式執行的驗證是否為 FATAL。

本機 SDV 和 AVB 模式比對

下表說明 AVB 模式和 SDV 開機模式對 SDV 安全網狀行為的影響。顏色定義請參閱 AVB 文件的「Android Specific Integration」一節。

裝置模式值

在 DICE 鏈結中，每個 CDI 憑證都有模式值，用於根據設定輸入內容描述該層的安全狀態。為了表示裝置上所有軟體的安全狀態，系統會定義裝置模式值，該值衍生自與特定 SDV VM (即 Android HLOS 和安全世界) 相關的 DICE 鏈結所有 CDI 階段的模式值，定義如下：

enum DeviceMode {
  NotConfigured = 0,
  Recovery = 1,
  Debug = 2,
  Normal = 3,
}

演算法

1. 讓「deviceMode」成為「DeviceMode::Normal」
2. 假設 diceChainList 是與 SDV VM 相關的 DICE 鏈結清單
3. 針對 diceChain 中的每個 diceChainList：
   1. 假設 cdiList 是 diceChain 中的 CDI 憑證清單：
   2. 針對 cdiCert 中的每個 cdiList：
      1. 假設 cdiDeviceMode 是對應於 cdiCert.mode 的 DeviceMode。
      2. 將 deviceMode 設為 min(deviceMode, cdiDeviceMode)。
4. 回程日期：deviceMode。

比較遠端裝置模式值

服務探索代理程式只會與具有相同裝置模式值的其他代理程式連線。

裝置模式值可確保網狀網路成員不會有不同的安全性屬性。因此，網狀網路所有成員的安全性狀態一致。

工廠佈建流程

這是車輛組裝線的佈建流程，假設公開金鑰基礎架構無法使用。

這個流程取決於儲存在一次性可程式化 (OTP) 記憶體 (稱為 VVMFactoryTrust) 中的 32 位元組值。設定這個值後，系統會將其做為名為 androidboot.sdv.vvmfactorytrust 的參數傳遞至核心。

ECU 中的所有 VM 都必須採用相同的 SDV 啟動模式和 VVMFactoryTrust。

Initial State

所有 ECU 最初都會解除 SDV 開機模式鎖定，且 VVMFactoryTrust 和 VVMTrustStore 為空白，VVMTrustStore 上可能會有 uds_certs。

圖 1 顯示一個範例，其中有三個 SDV VM (VM-A、VM-B 和 VM-C) 分布在兩個不同的 ECU (ECU-0 和 ECU-1) 中。

步驟 1：執行 sdv_provisioning_tool

從所有 ECU 啟動所有 VM。

在每個 VM 上：

• 執行「sdv_provisioning_tool」

  • 這項工具會與本機 Service Discovery 代理程式通訊，並等待代理程式發出 SDV Secure Mesh 完成的信號，以及代理程式將 UDS 公開金鑰清單寫入 /vvmtruststore/uds_pubs。
  • 發生這種情況時，工具會取得剛寫入的 /vvmtruststore/uds_pubs 的雜湊，並輸出該雜湊。

步驟 2：撰寫 VVMFactoryTrust

在每個 ECU 的一個 VM 上：

• 將上一步中 sdv_provisioning_tool 輸出的 /vvmtruststore/uds_pubs 雜湊值寫入 VVMFactoryTrust。寫入方式因 OEM/供應商而異，因此不在本規格的範圍內。

步驟 3：以 SDV 開機模式鎖定重新啟動

在 SDV 開機模式鎖定狀態下，重新啟動所有 ECU 中的所有 VM。

如果這個檔案的雜湊與 VVMFactoryTrust 相符，Service Discovery 代理程式就會信任 ECU 中的 VM，並使用 uds_pubs 列出的 UDS 公開金鑰。

由於 ECU 是同時佈建，因此會永久綁定在一起，從 DICE 鏈結驗證的角度來看，可視為單一硬體。

零件更換流程

這是授權汽車維修廠或車庫的佈建流程，必須將故障的 ECU 更換為新的未佈建 ECU。

這個流程取決於 UDS 憑證是由 vvmconfig 中所述的根授權單位直接核發，還是透過某個中間授權單位鏈結間接核發。

Initial State

所有 VM 都已完成原廠佈建，並以鎖定的 SDV 啟動模式執行。

圖 5 顯示 ECU-0 故障的範例，因此需要更換
。

步驟 1：安裝新的 ECU

安裝新的 ECU，此時 ECU 處於空白的未佈建狀態。

如圖 6 所示，當 ECU-2 (更換的 ECU) 啟動電源時，會有兩個不相連的 SDV 安全網格：一個處於警告狀態，另一個處於正常狀態。這兩個 SDV 安全網格都不完整。

步驟 2：以解鎖的 SDV 開機模式重新啟動

在 SDV 開機模式解鎖後，重新啟動所有 ECU 的所有 VM。

在圖 7 中，VM-B 和 VM-C 隨後加入警告 SDV 安全網格，現在已完成。

步驟 3：執行 sdv_provisioning_tool

在每個 VM 上執行 sdv_provisioning_tool。

這項工具會與本機 Service Discovery 代理程式通訊，並等待代理程式發出 SDV Secure Mesh 完成的信號，以及代理程式將 UDS 公開金鑰清單寫入 /vvmtruststore/uds_pubs。

發生這種情況時，工具會取得剛寫入的 /vvmtruststore/uds_pubs 雜湊值並輸出，但這個雜湊值不會用於這個流程。

步驟 4：安裝 UDS 憑證

• 從任意 SDV VM 擷取 /vvmtruststore/uds_pubs。由於相同 SDV 安全網狀網路中的所有 VM 都會使用相同的 IP 位址，因此選擇哪個 IP 位址都沒關係。
• 為該 /vvmtruststore/uds_pubs 中列出的所有 UDS 公開金鑰擷取佈建憑證。
  • 這通常是指將這項資訊傳送至遠端伺服器，該伺服器已儲存憑證，或會根據已知的 UDS 公開金鑰資料庫檢查收到的公開金鑰，藉此產生憑證。這個資料庫是從 ECU 製造期間擷取的 UDS 公開金鑰建構而成。
• 寫下每個 SDV VM 的 /vvmtruststore/uds_certs。

步驟 5：以 SDV 開機模式重新啟動裝置 (已鎖定)

重新啟動所有 VM，並鎖定 SDV 開機模式。

如果 SDV 安全網格不完整，請返回步驟 2。