Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .

Эта страница переведена с помощью 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 для доступа к аутентификации по лицу с помощью пользовательского интерфейса. Приложения не имеют доступа к FaceManager и должны использовать вместо этого BiometricPrompt .

FaceService

Это реализация фреймворка, которая управляет доступом к оборудованию аутентификации по лицу. Она содержит базовые машины регистрации и аутентификации, а также различные другие помощники (например, перечисление). Из-за проблем со стабильностью и безопасностью ни один код поставщика не может быть запущен в этом процессе. Доступ ко всему коду поставщика осуществляется через интерфейс Face 1.0 HIDL .

столкнулся

Это исполняемый файл Linux, который реализует интерфейс Face 1.0 HIDL, используемый FaceService . Он регистрируется как IBiometricsFace@1.0, чтобы FaceService мог его найти.

Выполнение

Лицо HIDL

Для реализации Face HIDL необходимо реализовать все методы IBiometricsFace.hal в библиотеке, специфичной для поставщика.

Сообщения об ошибках

Сообщения об ошибках отправляются с помощью обратного вызова и возвращают конечный автомат в состояние ожидания после отправки. Большинство сообщений имеют соответствующую строку, отображаемую пользователем, чтобы информировать пользователя об ошибке, но не все ошибки имеют эту строку, отображаемую пользователем. Для получения дополнительной информации о сообщениях об ошибках см. 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` ). Когда это происходит, требуется отправить оставшееся время фреймворку, чтобы он мог отобразить его для пользователя. Как и в случае с `setFeature()` , этот метод требует активный аппаратный токен аутентификации (HAT) для безопасного сброса внутреннего состояния. Сбрасывает блокировку только для текущего пользователя.

Все три оставшихся метода являются синхронными и должны блокироваться на минимальное время, чтобы избежать остановки фреймворка.

Метод	Описание
`generateChallenge()`	Генерирует уникальный и криптографически безопасный случайный токен, используемый для обозначения начала безопасной транзакции.
`setFeature()`	Включает или отключает функцию для текущего пользователя. По соображениям безопасности, это требует HAT от проверки PIN-кода/графического ключа/пароля пользователя на соответствие вышеуказанному вызову
`getFeature()`	Извлекает текущее состояние включения функции, как предписано по умолчанию или вызовом `setFeature()` выше. Если идентификатор лица недействителен, реализация должна вернуть `ILLEGAL_ARGUMENT`
`getAuthenticatorId()`	Возвращает идентификатор, связанный с текущим набором лиц. Этот идентификатор должен меняться всякий раз, когда добавляется лицо

Диаграмма состояний

Ожидается, что структура faced соответствовать диаграмме состояний, представленной ниже.