本節包含確保核心 Android 作業系統和裝置安全的建議。
生物辨識認證
仔細獲取、儲存和處理生物識別資料以進行使用者身份驗證。你應該：
- 在使用任何其他形式的身份驗證（包括生物識別技術）之前，強制使用主要身份驗證方法。
- 在使用被動生物辨識方式（例如臉部辨識）進行涉及身分驗證綁定金鑰的交易（例如付款）時，需要明確確認以表明意圖。
- 要求每 72 小時使用一次主要身份驗證方法。
- 使用完全安全的管道來處理所有生物識別數據和處理。
- 切勿在設備外傳送生物辨識資料（包括原始感測器測量值和衍生特徵）。如果可能，請將此資料保存在安全的隔離環境中，例如可信任執行環境 (TEE)或安全元件。
具有生物辨識技術的設備應支援BiometricPrompt API ，該 API 為應用程式開發人員提供通用且一致的介面，以便在其應用程式中利用基於生物辨識技術的身份驗證。只有強大的生物辨識技術才能與BiometricPrompt集成，並且集成必須遵循Android 相容性定義文件(CDD) 指南。
有關更多生物辨識指南，請參閱生物辨識 HAL 實施指南。
SELinux
SELinux 提供了大部分 Android 安全模型的定義和實作。正確使用 SELinux 對於 Android 裝置的安全至關重要，有助於減輕安全漏洞的影響。因此，所有 Android 裝置都應實施強大的 SELinux 策略。
- 實施最小權限策略。
- 避免授予
CAP_DAC_OVERRIDE、CAP_SYS_ADMIN和CAP_NET_ADMIN權限。 - 不要將系統資料記錄到 SD 卡上。
- 使用提供的類型進行驅動程式訪問，例如
gpu_device、audio_device等。 - 對進程、檔案和 SELinux 類型使用有意義的名稱。
- 確保不使用預設標籤並且不授予它們存取權限。
- 設備特定的策略應佔設備上運作的整體策略的 5-10%。 20% 以上範圍內的自訂幾乎肯定包含特權過高的網域和死策略。不必要的大策略會浪費內存，由於需要更大的引導映像而浪費磁碟空間，並對運行時策略查找時間產生負面影響。
SELinux策略的動態載入
不要在 Android 裝置上動態載入 SELinux 策略。這樣做可能會導致問題，例如：
- 阻止接受關鍵安全性修補程式。
- 公開透過重新載入策略來取得設備根權限的能力。
- 暴露針對策略更新程式的中間人攻擊向量。
- 由於策略更新錯誤導致裝置變磚。
後門
Android 應用程式不應有任何後門或繞過正常安全機制存取系統或資料的方式。這包括由開發人員已知的秘密進行的診斷、調試、開發或保固維修特殊訪問。防止後門：
- 使用業界認可的應用程式漏洞掃描工具掃描所有第三方應用程式。
- 對具有敏感存取權限的所有程式碼（包括第三方程式庫）執行程式碼審查。
- 透過將應用程式上傳到 Google Play 進行掃描來利用 Google Play Protect。您可以上傳應用程式進行掃描，而無需發佈到 Google Play。
- 不要在發布版本上預先載入以診斷或修復為重點的工具。僅按需安裝這些工具來解決特定問題。此外，這些工具不得操作或上傳任何特定於帳戶的資料。
開發工具
開發工具（例如調試、測試和診斷工具）通常會暴露其操作方式和收集的數據，從而在您的設備上造成意外的安全漏洞。為了確保開發工具不會進入生產版本：
- 在使用系統映像之前，請制定內部偵錯和測試工具雜湊的黑名單並掃描這些 APK 的版本。
- 使用業界認可的應用程式漏洞掃描工具掃描所有第一方應用程式。
- 在任何重大更新之前，聘請第三方應用程式安全測試公司來評估所有關鍵的設備上診斷應用程序，特別是如果該應用程式是由第三方開發的。
- 確保只有使用者可以在支援會話期間透過口頭或聊天方式啟用該工具。收集必要的診斷資訊後，儲存同意的工件並停用該工具。
- 將此工具的使用記錄儲存在使用者可以透過其運營商帳戶存取的日誌中。
- 確保該工具收集的任何個人識別資訊 (PII) 或設備遙測資料均遵守與所在國家/地區相關的匿名、保留和刪除做法。僅應收集與支援電話相關的數據。每次調用後應刪除此數據。
- 確保未經用戶明確同意，不會使用可用於間諜軟體的技術，例如按鍵記錄、麥克風使用或攝影機使用。使用這些潛在侵犯隱私方法的應用程式應該非常明確地披露，並附有用戶必須同意的隱私權政策。未經用戶明確同意，不應啟用此類應用程式。
以下是在實施揭露和同意時可參考的一些額外建議：
應用內揭露
- 直接在應用程式內顯示應用的正常使用情況。不需要使用者導航到選單或設定。
- 描述所收集的資料類型並解釋如何使用這些資料。
- 理想情況下，請勿將此資訊嵌入隱私權政策或服務條款中。請勿將其與與個人或敏感資料收集無關的其他揭露一起包含在內。
請求同意
- 同意必須是肯定的。不要將導航離開披露（包括點擊離開或按後退或主頁按鈕）視為同意。
- 以清晰明確的方式呈現同意對話框。
- 需要肯定的使用者操作（例如點擊接受或說出命令）才能接受。
- 在獲得明確同意之前，請勿收集個人或敏感資料。
- 不要使用自動消除或過期的訊息。
AOSP 中的嵌入式功能
在 AOSP 中嵌入附加功能通常會產生意想不到的行為和後果；謹慎行事。
- 確保使用者在想要使用不同的預設應用程式（例如搜尋引擎、Web 瀏覽器、啟動器）並揭露從裝置發送資料時收到提示。
- 確保 AOSP APK 使用 AOSP 憑證進行簽署。
- 執行回歸測試並保留更改日誌以確定 AOSP APK 是否已新增程式碼。
安全性更新
Android 裝置應在發布後至少兩年內獲得持續的安全支援。這包括接收解決已知安全漏洞的定期更新。
- 與硬體合作夥伴（例如 SoC 供應商）合作，為 Android 裝置上的所有元件製定適當的支援協議。
- 確保可以透過最少的用戶互動來安裝安全性更新，以增加用戶在其 Android 裝置上接受和安裝更新的可能性。強烈建議實施無縫系統更新或同等安全功能。
- 確保您了解Android 安全性公告中聲明的 Android 安全性修補程式等級 (SPL) 的累積要求。例如，使用 2018-02-01 安全性修補程式等級的裝置必須包含與該安全性修補程式等級相關的所有問題，以及對先前所有安全性公告中報告的所有問題的修正。
動態核心更新
請勿動態修改關鍵系統組件。雖然有一些研究顯示動態核心更新有助於防範緊急威脅，但目前評估的成本超過了效益。相反，創建一個強大的 OTA 更新方法來快速分發漏洞保護。
密鑰管理
維護良好的金鑰管理政策和實踐，以確保簽署金鑰的安全。
- 不要與外部各方共用簽署金鑰。
- 如果簽署金鑰遭到洩露，請產生新金鑰並對所有應用程式進行雙重簽署。
- 將所有金鑰儲存在需要多種因素存取的高安全性模組硬體或服務中。
系統鏡像簽名
系統映像的簽章對於確定裝置完整性至關重要。
- 不要使用公開金鑰對設備進行簽署。
- 以符合處理敏感金鑰的業界標準實務的方式管理設備簽章金鑰，包括提供有限、可審核存取的硬體安全模組 (HSM)。
可解鎖的引導程式
許多 Android 裝置支援解鎖，使裝置擁有者能夠修改系統分割區或安裝自訂作業系統。常見用例包括安裝第三方系統映像以及在設備上執行系統級開發。例如，要解鎖 Google Nexus 或 Pixel 上的系統映像，使用者可以執行fastboot oem unlock ，它會顯示以下訊息：
作為最佳實踐，可解鎖的 Android 裝置必須在解鎖之前安全地刪除所有使用者資料。如果未能正確刪除解鎖時的所有數據，可能會導致物理上鄰近的攻擊者未經授權存取機密 Android 用戶數據。為了防止用戶資料洩露，支援解鎖的設備必須正確實現。
- 用戶確認解鎖命令後，設備必須立即開始資料擦除。在安全刪除完成前不得設定
unlocked標誌。 - 如果無法完成安全刪除，設備必須保持鎖定狀態。
- 如果底層塊設備支持，則應使用
ioctl(BLKSECDISCARD)或等效項。對於嵌入式多媒體卡 (eMMC) 設備，這意味著使用安全性清除或安全性修剪命令。對於 eMMC 4.5 及更高版本，這意味著使用正常的擦除或修剪，然後進行清理操作。 - 如果底層塊設備不支援
BLKSECDISCARD，則必須改用ioctl(BLKDISCARD)。在 eMMC 裝置上，這是正常的 Trim 操作。 - 如果不支援
BLKDISCARD，則可以接受用全零覆蓋塊設備。 - 使用者必須可以選擇要求在刷新分割區之前擦除使用者資料。例如，Nexus 裝置使用
fastboot oem lock命令來擦除使用者資料。 - 設備可以透過 eFuse 或類似機制記錄設備是否已解鎖和/或重新鎖定。但是，我們強烈建議透過隨後的恢復原廠設定重新鎖定引導程序，以恢復完整的裝置功能。
這些要求確保在解鎖操作完成後所有資料都被銷毀。未能實施這些保護措施被視為中等程度的安全漏洞。
隨後可以使用fastboot oem lock指令重新鎖定已解鎖的裝置。鎖定引導程式可以為新的自訂作業系統提供與原始裝置製造商作業系統相同的使用者資料保護（例如，如果裝置再次解鎖，使用者資料將被清除）。
設備滲透測試
設備在裝運前應由合格的滲透測試人員進行審查。滲透測試應確定設備遵循此處提供的安全指南以及內部 OEM 安全指南。
安全測試
使用AOSP提供的安全測試工具。尤其
- 在開發過程中使用記憶體安全工具：在支援的情況下使用MTE （ARMv9 及更高版本），在不支援的情況下使用HWASan 。在啟用這些工具的情況下運行盡可能多的測試。
- 在生產中使用GWP-ASan 和 KFENCE ，對記憶體安全問題進行機率檢測。