Android 長期安全製造商指南

本指南介紹了 Google 建議的應用由 Android 相容性測試套件 (CTS) 評估的安全性修補程式的最佳實踐。它適用於 Android 相容 OEM 裝置（製造商）的製造商，這些裝置的支援時間將超過三年，例如車輛、電視、機上盒和家用電器。本指南不適用於最終使用者（例如車主）。

致謝和免責聲明

本指南不對 Google 或其他製造商產生法律或合約約束，也無意成為一組要求。相反，本指南是描述推薦實踐的教學輔助工具。

回饋

本指南並非全面；計劃進行更多修訂。將回饋提交至Manufacturer-guide-android@googlegroups.com。

詞彙表

學期定義
ACC Android 相容性承諾。以前稱為 Android 反碎片協定 (AFA)。
AOSP Android 開源專案
ASB Android 安全公告
中央銀行主機板支援包
CDD相容性定義文檔
CTS相容性測試套件
福塔無線韌體
全球定位系統全球定位系統
米斯拉汽車工業軟體可靠性協會
美國國家標準技術研究所美國國家標準技術研究院
車載診斷系統車載診斷（ OBD-II在功能和標準化方面均較OBD-I有所改進）
代加工原始設備製造商
作業系統作業系統
SEI軟體工程學院
系統系統
標準作業程序開始生產
聲壓級安全補丁級別
胎壓監測系統胎壓監測系統

關於安卓作業系統

Android 是一個基於 Linux 的開源完整軟體堆疊，專為各種裝置和外形尺寸而設計。自 2008 年首次發布以來，Android 已成為最受歡迎的作業系統 (OS)，為全球 14 億多台裝置提供支援（2016 年）。截至 2017 年 3 月，其中約 67% 的裝置使用 Android 5.0 (Lollipop) 或更高版本（更多最新數據可在Android 儀表板上查看）。雖然絕大多數設備是手機和平板電腦，但 Android 在智慧手錶、電視和汽車車載資訊娛樂 (IVI) 設備中的應用正在不斷增長。

Google Play 商店中可用的 Android 應用程式數量已達到2.2+ 萬個（2016 年）。 Android 應用程式開發由 Android 相容性計劃提供支持，該計劃透過相容性定義文件 (CDD)定義了一組要求，並透過相容性測試套件 (CTS)提供測試工具。 Android 相容性計劃可確保任何 Android 應用程式都可以在支援該應用程式所需功能的任何 Android 相容裝置上運行。

Google 定期發布新的作業系統版本、作業系統安全性更新以及有關已發現漏洞的資訊。製造商應審查Android 安全公告，以確定這些更新對 Android 作業系統支援的產品的適用性。有關 Android 安全性、相容性和建置系統的回顧，請參閱以下內容：

關於連網車輛（規範的長壽命產品）

20 世紀 20 年代，隨著 AM 收音機的引入，車輛開始聯網。從那時起，隨著監管機構和汽車製造商轉向電子產品來簡化診斷和服務（例如OBD-II 連接埠）、提高安全性（例如TPMS）並滿足燃油經濟性目標，外部實體和無線連接的數量開始增長。接下來的連接浪潮引入了駕駛員便利功能，例如遠端無鑰匙進入、遠端資訊處理系統以及藍牙、Wi-Fi 和智慧型手機投影等高級資訊娛樂功能。如今，整合感測器和連接（例如 GPS）支援安全和半自動駕駛系統。

隨著車輛連接數量的增加，潛在車輛攻擊面的面積也會增加。連線帶來了與消費性電子產品類似的網路安全問題。然而，雖然重啟、每日修補更新和無法解釋的行為是消費性電子產品的常態，但對於車輛等具有安全關鍵系統的產品來說，這些情況卻不一致。

製造商必須採取積極主動的方法，確保產品在現場的持續安全狀態。簡而言之，製造商必須了解產品中已知的安全漏洞，並採取基於風險的方法來解決這些漏洞。

確保長期安全

一輛連網車輛通常具有一個或多個電子控制單元(ECU)，其中包括作業系統、庫、實用程式等多個軟體元件。製造商應追蹤這些元件並透過主動分析識別已知已發布的漏洞，包括：

  • 定期根據常見漏洞和暴露 (CVE) 資料庫評估產品。
  • 收集與產品相關的安全缺陷的情報。
  • 安全測試。
  • 積極分析 Android 安全公告。

作業系統和安全性修補程式更新範例（運行 Android 的 IVI）：

圖 1.在車輛生命週期內推出主要作業系統和安全性更新的範例。

#步活動

①

發展科製造商選擇 Android 版本 (Android X)。在此範例中，「Android X」成為初始生產開始 (SOP) 前兩年將在車輛中出貨的基礎。
②首次啟動在 Android X 成為產品中發布的第一個作業系統版本之前的幾個月，安全性更新將從 Android 安全公告 (ASB) 以及製造商認為有價值的其他潛在來源取得。 y2 = Android X 版本的第二個安全公告，由製造商應用（向後移植）到 Android X。此更新隨產品一起提供，生產時鐘從 Android X.y2 的零年開始計時。

在此範例中，製造商決定不發布最新的 Android X+1 年度版本。發布最新版本的原因包括新增功能、解決新的安全漏洞和/或發布需要較新 Android 版本的 Google 或第三方服務。反對發布最新版本的原因是車輛開發和發布過程缺乏整合、測試和驗證變更（包括遵守所有監管和認證要求）所需的時間。

③完整作業系統更新SOP 之後，製造商發布了 Android X+2 作業系統更新，這是在初始產品 (Android X0) 使用的版本之後的兩個 Android 版本。 ASB 安全性更新可用於 API 層級（截至發布日期），因此更新在 SOP 後約 1.25 年發佈為 X+2.y0。此作業系統更新可能與現場產品相容，也可能不相容。如果是的話，可以製定一個計劃來更新已部署的車輛。

除非有其他業務協議，否則進行完整作業系統更新的決定完全由製造商自行決定。

④安全性更新車輛生產週期滿兩年後，製造商對 Android X+2 作業系統進行了修補。該決定基於製造商的風險評估。製造商選擇版本 X+2 的第三個 ASB 安全性更新作為更新的基礎。接收安全性更新的產品現在處於 (X+2.y3) OS + Android 安全性修補程式等級。

雖然製造商可以從任何單獨的 ASB 中選擇單獨的安全補丁，但他們必須修復公告中的所有必要問題才能使用與公告關聯的 Android 安全補丁等級 (SPL)（例如 2017-02-05）。製造商有責任為受支援的產品執行向後移植和安全發布。

⑤完整作業系統更新重複步驟 3（完整作業系統更新），第二次完整作業系統更新將產品升級至 Android X+4，此時車輛的生產壽命已達三年。製造商現在正在平衡最新 Android 版本的新硬體要求與產品中的硬件，以及用戶從更新的 Android 作業系統中受益。製造商發布了沒有安全性更新的更新，因此該產品現在處於 (X+4.y0) OS + Android 安全性修補程式等級。

在此範例中，由於硬體限制，X+4 是為此產品提供的最後一個主要 Android 版本，儘管車輛 6 年以上的預期壽命仍需要安全支援。

⑥安全性更新重複步驟 4（安全性更新）。製造商的任務是從更高版本的 Android (X+6) 取得 ASB 安全性更新，並將其中部分或全部更新移植回 Android X+4。製造商有責任合併、整合和執行更新（或與第三方簽訂合約）。此外，製造商應該意識到，ASB 不涵蓋不再受支援的 Android 版本中的安全問題。
⑦安全性更新車輛生產生命週期已過去八年，自第5 步（完整操作系統更新）中的最後一次操作系統更新以來已發布了四個Android 版本，自Android X 指定以來已有十年，策劃和向後移植安全補丁的負擔完全由製造商承擔這些版本距離 API 等級公開發布已超過三年。

安全最佳實踐

為了使安全妥協更加困難，Google 建議並採用普遍接受的安全性和軟體工程最佳實踐，如實施安全性所述。

安全指南

建議的安全做法包括：

  • 使用最新版本的外部程式庫和開源元件。
  • 不要在作業系統的發行版本中包含侵入式偵錯功能。
  • 刪除未使用的功能（以減少不必要的攻擊面）。
  • 使用最小權限原則和其他Android 應用程式開發最佳實踐。

軟體開發指南

系統生命週期內安全軟體開發的建議實務包括：

  • 執行威脅建模以排名和識別資產、威脅和潛在的緩解措施。
  • 執行架構/設計審查以確保安全和健全的設計。
  • 定期進行程式碼審查，以盡快識別反模式和錯誤。
  • 設計、實現和運行高程式碼覆蓋率單元測試，包括：
    • 功能測試（包括負面測試案例）
    • 定期回歸測試（以確保已修復的錯誤不會再次出現）
    • 模糊測試（作為單元測試套件的一部分）
  • 使用靜態原始碼分析工具（scan-build、lint 等）來識別潛在問題。
  • 使用動態原始碼分析工具，例如 AddressSanitizer、UndefinedBehaviorSanitizer 和 FORTIFY_SOURCE（對於本機元件）來識別和緩解系統開發過程中的潛在問題。
  • 對軟體原始碼和發布配置/版本有管理策略。
  • 制定用於產生和部署軟體修補程式的修補程式管理策略。

安全向後移植政策

目前，自API 等級公開發布起三 (3) 年內，Google 將為已發現和報告的安全漏洞提供積極的安全反向移植支援。積極的支持包括以下：

  1. 接收並調查漏洞報告。
  2. 建立、測試和發布安全性更新。
  3. 提供定期發布的安全性更新和安全公告詳細資訊。
  4. 根據既定指南執行嚴重性評估。

自 API 等級公開發布之日起三年後，Google 建議遵循以下準則：

  • 使用第三方（例如 SoC 供應商或核心提供者）為 API 發布三年以上的作業系統安全更新提供向後移植支援。
  • 透過第三方使用公開提供的 ASB 執行程式碼審查。雖然 ASB 識別當前支援版本的漏洞，但製造商可以使用提供的資訊將新發布的更新與先前的版本進行比較。這些數據可用於執行影響分析，並可能為 API 發布三年以上的作業系統版本產生類似的修補程式。
  • 在適當的時候，將安全性更新上傳到 Android 開源專案 (AOSP)。
  • 製造商必須協調供應商特定代碼（例如，專有設備特定代碼）的安全更新處理。
  • 製造商應加入NDA Android安全公告合作夥伴預覽通知組（需要簽署開發者NDA等法律協議）。公告應包括：
    • 公告
    • 按補丁等級列出的問題摘要，包括 CVE 和嚴重性
    • 適當情況下的漏洞詳細信息

其他參考資料

有關安全編碼和軟體開發實務的說明，請參閱以下內容：

Google 鼓勵使用以下推薦做法。

通常建議任何連接的產品都使用最新的作業系統版本啟動，製造商應在啟動產品之前嘗試使用最新的作業系統版本。雖然在測試和驗證之前鎖定版本對於提高穩定性是必要的，但製造商必須平衡從舊作業系統版本獲得的產品穩定性與具有較少已知安全漏洞和增強安全保護的新作業系統版本。

建議的指南包括：

  • 由於車輛開發過程固有的開發週期較長，製造商可能需要推出 n-2 或更早版本的作業系統。
  • 透過無線 (OTA) 活動保持每個已發布 Android 作業系統版本與 Android 相容性的一致性。
  • 實施支援 Android 無線韌體 (FOTA) 的產品，以實現快速、客戶友好的更新。 FOTA 應使用安全最佳實踐來完成，例如產品與 IT 後台之間的程式碼簽章和 TLS 連線。
  • 向 Android 安全團隊提交獨立識別的 Android 安全漏洞。

注意： Google 已考慮在 Android 安全公告中提供裝置類型或行業特定的通知。但是，由於 Google 不知道給定裝置（車輛、電視、穿戴式裝置、手機等）的核心、驅動程式或晶片組，因此 Google 沒有確定的方法來標記裝置類型的任何給定安全問題。

製造商應盡一切努力在產品週期增強期間使用最新的作業系統版本或正在使用的版本的安全性更新。更新可以在定期產品更新期間執行，或用於解決品質和/或其他問題的修補程式。建議的做法包括：

  • 建立一個計劃來解決驅動程式、核心和協定更新問題。
  • 利用適合行業的方法為已部署的車輛提供更新。

相容性定義文檔 (CDD)

相容性定義文件 (CDD) 描述了裝置相容於 Android 的要求。 CDD 是公開的，所有人都可以使用；您可以從source.android.com下載從 Android 1.6 到最新版本的 CDD 版本。

滿足產品的這些要求涉及以下基本步驟：

  1. 合作夥伴與 Google 簽署 Android 相容性承諾 (ACC)。然後指派一名技術解決方案顧問 (TSC) 作為指導。
  2. 合作夥伴完成產品 Android 作業系統版本的 CDD 審核。
  3. 合作夥伴運行並提交 CTS 結果（如下所述），直到結果符合 Android 相容性要求。

相容性測試套件 (CTS)

相容性測試套件 (CTS) 測試工具可驗證產品實作是否與 Android 相容，以及是否包含最新的安全性修補程式。 CTS 是公開的、開源的，可供所有人使用；您可以從source.android.com下載從 Android 1.6 到最新版本的 CTS 版本。

每個向公眾發布的 Android 軟體版本（出廠安裝和現場更新映像）都必須透過 CTS 結果證明 Android 相容性。例如，如果裝置運行 Android 7.1，則在建立和測試發布意圖建置映像時應引用 CDD 7.1 和 CTS 7.1 的最新對應版本。強烈鼓勵製造商儘早並頻繁地使用 CTS 來識別和修復問題。

注意：簽署其他協定（例如Google 行動服務 (GMS)）的合作夥伴可能需要滿足其他要求。

CTS工作流程

CTS 工作流程包括設定測試環境、執行測試、解釋結果以及理解 CTS 原始程式碼。以下指南旨在幫助 CTS 使用者（例如開發人員、製造商）有效且有效率地使用 CTS。

  • 經常運行測試。 CTS 被設計為整合到您的建置系統中的自動化工具。經常執行 CTS 可以幫助您在發生軟體降級或回歸時快速、儘早發現缺陷。
  • 下載並檢查 CTS 原始碼。完整的 CTS 原始碼是任何人都可以下載和使用的開源軟體（下載的原始碼是完全可建置和運行的）。當設備上的測試失敗時，檢查原始程式碼的相關部分可以幫助您確定原因。
  • 取得最新的 CTS 。新的 Android 版本可以透過錯誤修復、改進和新測試來更新 CTS。經常檢查CTS 下載並根據需要更新您的 CTS 程式。製造商和 Google 應就用於產品發布的 CTS 版本達成一致，因為產品必須在某個時刻凍結，同時 CTS 繼續刷新。

透過CTS

對於 Android 相容產品，Google 確保裝置的 CTS 和 CTS 驗證器報告測試結果是可接受的。原則上，所有測試都必須通過。但是，如果測試因裝置不符合 Android 相容性要求以外的原因而失敗，則需要接受 Google 的審核。在此過程中：

  1. 製造商向 Google 提供了建議的 CTS 補丁、補丁驗證以及證明論點的理由。
  2. Google 會檢查提交的資料，如果接受，則會更新相關的 CTS 測試，以便該裝置能夠通過 CTS 的下一個修訂版。

如果 CTS 測試在應用安全性修補程式後突然失敗，製造商必須修改補丁，以便不會破壞相容性或表明測試錯誤並為測試提供修復程序（如上所述）。

CTS 仍然開放以接受測試修復的審查。例如，Android 4.4 繼續接受修復（請參閱https://android-review.googlesource.com/#/c/273371/ ）。

常見問題 (FAQ)

Q：誰負責將安全更新應用於 Android 的特定實作？

答：由直接提供設備的製造商負責。該實體不是Google，Google 在 AOSP 中發布安全性更新，而不是針對特定設備（例如車輛）。

Q：Google 如何處理 Android 中的安全性問題？

答：Google 不斷調查問題並開發潛在的修復程序，作為定期安全更新過程的一部分，Google 會將這些修復程序提供給所有支援的 API 等級。自 2015 年 8 月以來，Google 一直保持定期發佈公告和source.android.com更新連結；谷歌也將安全更新作為主要作業系統版本的一部分發布。另請參閱安全性向後移植策略。

Q：如果製造商整合了 ASB 的所有 AOSP 補丁，但沒有整合同一公告中提到的 BSP 供應商的補丁，是否仍可以提高安全等級（例如，將相應的補丁應用於平台/建置）？

答：要聲明 Android 安全性修補程式等級 (SPL)，製造商必須解決 Android 安全性公告（包括先前的公告）中發布的所有必要問題，並對應到特定的 Android SPL。例如，使用2017 年 3 月安全公告(2017-03-01 SPL) 的製造商已解決了2017 年3 月公告中記錄的該SPL 的所有必需問題以及所有先前的更新，包括所有先前Android 安全公告的設備特定更新，包括與 2017-02-05 SPL 相關的設備特定更新。

Q：如果製造商不同意 BSP 供應商提供的安全性更新，或供應商未提供 ASB 強制要求的安全性更新，會發生什麼情況？

答：ASB 描述安全漏洞（透過 CVE 清單列舉）並通常提供相符的安全性測試。目標是確保列出的漏洞不再在設備上重現，並且設備可以通過相關的安全測試。因此，問題不在於是否採用 Google 或第三方供應商提供的安全更新，而是製造商證明該設備不易受到 ASB 中 CVE 清單的影響。製造商可以自由使用所提供的安全性更新，或者，如果他們有更適合其設備的更改，則使用該更改。

例如，考慮這樣一種情況：Google 使用程式碼變更來解決 AOSP 安全漏洞，該變更可讓元件保持完整功能並符合 CDD。如果製造商確定設備上不需要該組件，或者 CDD（或相關認證測試）未強制要求該組件，則製造商可以刪除該組件以減少未來的服務需求並減少攻擊面。儘管製造商沒有使用提供的安全更新，但它確實確保設備不易受到安全公告中記錄的 CVE 的攻擊。然而，如果偏離建議的安全性更新，製造商就會冒著錯誤解決問題、引入新的安全漏洞或以其他方式減少最終版本功能的風險。

雖然我們與所有 SoC 合作夥伴合作，確保 ASB 中的所有問題都已修復，但我們建議製造商與其 SoC 供應商就設備的生命週期簽訂服務協議。 SoC 可能會提前停止為晶片組提供服務，因此在選擇設備晶片組之前建立協議是設備啟動過程的重要組成部分。

最後，如果無法直接取得或獨立建立 ASB 中記錄的問題的修復程序，製造商可以維護先前的 Android SPL，並且仍然向建置添加新的可用修復程序。然而，這種做法最終會導致建置認證問題（因為 Android 確保最新的安全性修補程式等級在經過認證的裝置上可用）。 Google 建議提前與您的 SoC 合作以避免這種做法。

Q：如果製造商確定某個 ASB 專案不適用於其產品，是否仍需要應用或修補該專案才能滿足其他 Google 要求或透過 CTS？

答：我們不要求打補丁才能聲明 Android 安全性修補程式等級 (SPL)；我們確實要求製造商證明他們的產品不易受到此問題的影響。

一個例子是製造商的系統中不存在要修補的組件，或為了解決問題而從製造商的系統中刪除了組件。在這種情況下，系統可能是合規的，而不需要製造商打補丁。

這與製造商想要的根本不同，例如，只修復關鍵補丁，而不採取其他可能導致安全測試失敗的適用補丁。在這種情況下，假定未滿足 SPL。