Аутентификация по лицу HIDL

Обзор

Аутентификация по лицу позволяет пользователям разблокировать устройство, просто взглянув на его переднюю панель. Android 10 добавляет поддержку нового стека аутентификации по лицу, который может безопасно обрабатывать кадры с камеры, обеспечивая безопасность и конфиденциальность во время аутентификации по лицу на поддерживаемом оборудовании. Android 10 также предоставляет простой способ для реализаций, соответствующих требованиям безопасности, обеспечить интеграцию приложений для транзакций, таких как онлайн-банкинг или другие сервисы.

В Android 10 реализована новая реализация стека аутентификации по лицу. Новая реализация включает интерфейсы IBiometricsFace.hal , IBiometricsFaceClientCallback.hal и types.hal .

Архитектура

API BiometricPrompt включает в себя все виды биометрической аутентификации, включая распознавание лица, отпечатков пальцев и радужной оболочки глаза. Face HAL взаимодействует со следующими компонентами.

Рисунок 1. Биометрический стек.

FaceManager

FaceManager — это закрытый интерфейс, поддерживающий связь с FaceService . Он используется Keyguard для доступа к аутентификации по лицу с помощью пользовательского интерфейса. Приложения не имеют доступа к FaceManager и должны использовать вместо него BiometricPrompt .

FaceService

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

столкнулся

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

Выполнение

Face HIDL

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

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

Сообщения об ошибках отправляются через функцию обратного вызова и после отправки возвращают конечный автомат в состояние ожидания . Большинство сообщений имеют соответствующую строку, предназначенную для информирования пользователя об ошибке, но не все ошибки имеют эту строку. Для получения дополнительной информации о сообщениях об ошибках см. types.hal . Все сообщения об ошибках представляют собой конечное состояние, то есть платформа предполагает, что HAL возвращается в состояние ожидания после отправки сообщения об ошибке.

Сообщения о привлечении клиентов

Сообщения о получении данных передаются во время регистрации или аутентификации и предназначены для того, чтобы помочь пользователю успешно пройти регистрацию или аутентификацию. Каждому порядковому номеру соответствует сообщение из файла FaceAuthenticationManager.java . Можно добавлять сообщения, специфичные для конкретного производителя, при условии предоставления соответствующих строк справки. Сообщения о получении данных сами по себе не являются конечными состояниями; ожидается, что HAL отправит столько таких сообщений, сколько необходимо для завершения текущей регистрации или аутентификации. Если сообщение о получении данных приводит к конечному состоянию, в котором дальнейшее продвижение невозможно, то HAL должен последовать за сообщениями об ошибке, например, если изображение слишком темное и остается слишком темным для дальнейшего продвижения. В этом случае целесообразно отправить сообщение UNABLE_TO_PROCESS после нескольких попыток, но дальнейшего продвижения не удается.

Аппаратное обеспечение

Для соответствия строгим биометрическим требованиям Android 10 устройства должны иметь защищенное оборудование, обеспечивающее целостность данных лица и окончательную проверку подлинности. В документе Android Compatibility Definition Document (CDD) описан требуемый уровень безопасности и допустимый уровень принятия поддельных данных (SAR). Для безопасной обработки и распознавания требуется доверенная среда выполнения (TEE). Кроме того, для предотвращения атак внедрения в аутентификацию по лицу требуется защищенное оборудование камеры. Например, страницы памяти, содержащие данные изображения, могут быть привилегированными и помечены как доступные только для чтения, так что обновлять их может только оборудование камеры. В идеале доступ к данным лица должен иметь только TEE и оборудование.

Поскольку аппаратное обеспечение для аутентификации по лицу значительно различается, необходимо разрабатывать драйверы, специфичные для конкретного оборудования, чтобы включить аутентификацию по лицу в зависимости от архитектуры конкретного устройства. Поэтому эталонной реализации для faced не существует.

Методы

Все перечисленные ниже методы являются асинхронными и должны немедленно возвращать управление фреймворку. Несоблюдение этого требования приводит к замедлению работы системы и потенциальному сбросу сторожевого таймера. Рекомендуется использовать очередь сообщений с несколькими потоками, чтобы избежать блокировки вызывающего объекта. Все 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 ниже диаграмме состояний.

Рисунок 2. Последовательность состояний аутентификации по лицу.