Эта страница переведена с помощью Cloud Translation API.

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

Обзор

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

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

Архитектура

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

FaceManager

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

FaceService

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

столкнулся

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

Выполнение

Лицо ХИДЛ

Чтобы реализовать 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 с приведенной ниже диаграммой состояний.