本頁面由 Cloud Translation API 翻譯而成。

臉孔驗證 HIDL

總覽

使用者只要看著裝置正面，即可透過臉部驗證解鎖裝置。Android 10 新增了臉部辨識堆疊的支援功能，可安全處理攝影機影格，在支援的硬體上進行臉部辨識時，確保安全性和隱私權。Android 10 也為符合安全性規範的實作方式提供簡單方法，可啟用應用程式整合功能，用於處理交易，例如線上銀行或其他服務。

Android 臉部驗證堆疊是 Android 10 中的新實作項目。新的實作會導入 IBiometricsFace.hal、IBiometricsFaceClientCallback.hal 和 types.hal 介面。

建築

BiometricPrompt API 包含所有生物特徵辨識驗證，包括臉部、手指和鳶尾花。Face HAL 會與下列元件互動。

FaceManager

FaceManager 是私人介面，用來維持與 FaceService 的連線。Keyguard 會使用這個類別，透過自訂 UI 存取臉部驗證功能。應用程式無法存取 FaceManager，因此必須改用 BiometricPrompt。

FaceService

這種架構實作方式可管理臉孔驗證硬體存取權。其中包含基本的註冊和驗證狀態機器，以及各種其他輔助程式 (例如列舉)。基於穩定性和安全性考量，這個程序不允許執行任何供應商程式碼。所有供應商程式碼皆可透過 Face 1.0 HIDL 介面存取。

面臨

這是 Linux 可執行檔，可實作 FaceService 使用的 Face 1.0 HIDL 介面。將其註冊為 IBiometricsFace@1.0，以便 FaceService 找到。

實作

臉部 HIDL

如要實作 Face HIDL，您必須在供應商專屬程式庫中實作 IBiometricsFace.hal 的所有方法。

錯誤訊息

錯誤訊息會透過回呼傳送，並在傳送後將狀態機器傳回至「idle」狀態。大多數訊息都有對應的使用者端字串，可向使用者說明錯誤，但並非所有錯誤都有這個使用者端字串。如要進一步瞭解錯誤訊息，請參閱 types.hal。所有錯誤訊息都代表終端狀態，也就是說，架構會假設 HAL 在傳送錯誤訊息後會返回空閒狀態。

獲客訊息

獲取訊息會在註冊或驗證期間傳送，目的是引導使用者成功註冊或驗證。每個序數都有來自 FaceAuthenticationManager.java 檔案的相關訊息。只要提供對應的說明字串，即可新增特定供應商的訊息。獲取訊息本身並非終端機狀態，因此 HAL 預計會視需要傳送這類訊息來完成目前的註冊或驗證作業。如果擷取訊息導致無法取得任何進展的終端狀態，HAL 就應在擷取訊息後附上錯誤訊息，例如圖片太暗且持續處於太暗狀態，無法取得任何進展。在這種情況下，您可以在嘗試多次嘗試後傳送 UNABLE_TO_PROCESS，但無法進一步進度。

硬體

為符合 Android 10 的高強度生物特徵辨識規定，裝置必須具備安全的硬體，才能確保臉孔資料的完整性，以及最終的驗證比較結果。Android 相容性定義說明文件 (CDD) 概略說明所需的安全性級別，以及所需的假冒接受率 (SAR)。需要信任的執行環境 (TEE) 才能安全地進行處理及辨識作業。此外，您必須使用安全的相機硬體，才能防止臉部驗證遭到注入攻擊。舉例來說，圖片資料的相關記憶體頁面可設為特權，並標示為唯讀，這樣只有攝影機硬體才能更新這些頁面。理想情況下，除了 TEE 和硬體，其他程序都應無法存取。

由於臉孔驗證硬體的差異相當大，因此您必須根據特定裝置架構，開發硬體專屬的驅動程式，才能啟用臉孔驗證功能。因此 faced 沒有參照實作。

方法

下列方法皆為非同步，必須立即傳回至架構。否則系統會變慢，且可能會重設 Watchdog。建議您使用多個執行緒的訊息佇列，以免阻斷呼叫端。所有 GET 要求都應盡可能快取資訊，以便將呼叫端的封鎖時間降至最低。

方法	說明
`setCallback()`	由 `FaceService` 呼叫，用於將所有訊息回傳至自身。
`setActiveUser()`	設定有效使用者，並套用所有後續 HAL 作業。除非再次呼叫此方法，否則系統一律會對這位使用者進行驗證。
`revokeChallenge()`	透過讓 `generateChallenge()` 產生的挑戰失效，完成安全交易。
`enroll()`	註冊使用者的臉孔。
`cancel()`	取消目前的作業 (例如註冊、驗證、移除或列舉)，並將 `faced` 傳回閒置狀態。
`enumerate()`	列舉與活躍使用者相關聯的所有臉孔範本。
`remove()`	移除與使用者相關聯的人臉模板或所有人臉模板。
`authenticate()`	驗證活躍使用者。
`userActivity()`	只有在 HAL 處於驗證或待機狀態時，才應使用此方法。如果 HAL 不在上述任一狀態，使用這個方法會傳回 `OPERATION_NOT_SUPPORTED`。如果在 HAL 已進行驗證時呼叫此方法，系統尋找臉孔的時間可能會延長。
`resetLockout()`	如果錶面遭到拒絕的次數過多，`faced` 就必須進入鎖定狀態 (`LOCKOUT` 或 `LOCKOUT_PERMANENT`)。在這種情況下，`faced` 必須將剩餘時間傳送至架構，以便向使用者顯示。與 `setFeature()` 一樣，這個方法需要有效的硬體驗證權杖 (HAT)，才能安全地重設內部狀態。「僅」為目前的使用者重設鎖定功能。

剩下的三種方法都是同步的，應只阻斷最少的時間，以免延遲架構。

方法	說明
`generateChallenge()`	產生不重複的加密編譯隨機權杖，用來表示安全交易的啟動。
`setFeature()`	為目前使用者啟用或停用功能。為了安全起見，這需要 HAT 根據上述驗證問題檢查使用者的 PIN 碼/解鎖圖案/密碼
`getFeature()`	擷取功能目前的啟用狀態 (由預設或上述 `setFeature()` 呼叫)。如果 Face ID 無效，實作項目必須傳回 `ILLEGAL_ARGUMENT`
`getAuthenticatorId()`	傳回與目前臉孔集相關聯的 ID。每當新增臉孔時，這個 ID 必須變更

狀態圖表

架構預期 faced 會遵循下方的狀態圖表。