Обзор
Аутентификация по лицу позволяет пользователям разблокировать свое устройство, просто взглянув на переднюю часть устройства. В Android 10 добавлена поддержка нового стека аутентификации по лицу, который может безопасно обрабатывать кадры камеры, сохраняя безопасность и конфиденциальность во время аутентификации по лицу на поддерживаемом оборудовании. Android 10 также предоставляет простой способ реализации, соответствующей требованиям безопасности, позволяющей интегрировать приложения для транзакций, таких как онлайн-банкинг или другие услуги.
Стек аутентификации по лицу Android — это новая реализация в Android 10. В новой реализации представлены IBiometricsFace.hal
, IBiometricsFaceClientCallback.hal
и types.hal
.
Архитектура
API BiometricPrompt включает в себя всю биометрическую аутентификацию, включая проверку подлинности лица, пальца и радужной оболочки глаза. 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() | Когда слишком много граней отклонено, грань должна войти в состояние блокировки LOCKOUT faced или LOCKOUT_PERMANENT ). Когда это произойдет, необходимо отправить оставшееся время в фреймворк, чтобы он мог отобразить его для пользователя. Как и в случае с setFeature() , для этого метода требуется активный токен аппаратной аутентификации (HAT) для безопасного сброса внутреннего состояния. Сбрасывает блокировку только для текущего пользователя. |
Все три оставшихся метода являются синхронными и должны блокироваться на минимальное время, чтобы избежать остановки фреймворка.
Метод | Описание |
---|---|
generateChallenge() | Генерирует уникальный и криптографически безопасный случайный токен, используемый для обозначения начала безопасной транзакции. |
setFeature() | Включает или отключает функцию для текущего пользователя. Из соображений безопасности для этого требуется, чтобы HAT проверял пин-код/шаблон/пароль пользователя на соответствие вышеуказанной задаче. |
getFeature() | Получает текущее состояние включения функции в соответствии с параметром по умолчанию или вызовом setFeature() выше. Если идентификатор лица недействителен, реализация должна вернуть ILLEGAL_ARGUMENT |
getAuthenticatorId() | Возвращает идентификатор, связанный с текущим набором граней. Этот идентификатор должен меняться всякий раз, когда добавляется лицо |
Диаграмма состояний
Фреймворк ожидает, что faced
будет следовать приведенной ниже диаграмме состояний.