Биометрия

Биометрия предлагает более удобный, но потенциально менее безопасный способ подтверждения вашей личности с помощью устройства. В многоуровневой модели аутентификации первичная аутентификация (то есть модальности, основанные на факторах знаний, таких как PIN-код, шаблон и пароль) обеспечивает наивысший уровень безопасности. Биометрия находится на втором уровне аутентификации, предлагая баланс между удобством и безопасностью. CDD для Android определяет три класса биометрической стойкости: класс 3 (ранее Сильный), класс 2 (ранее Слабый) и класс 1 (ранее Удобство). У каждого класса есть набор предварительных условий, привилегий и ограничений. Дополнительные сведения см. в CDD выше. Все три класса могут интегрироваться с экраном блокировки, но только аутентификаторы Strong и Weak могут интегрироваться с API-интерфейсами android.hardware.biometrics. В этой таблице описывается каждый аутентификатор и функции, которые они поддерживают.

Аутентификатор Экран блокировки Интеграция биометрических подсказок Хранилище ключей (ключ на основе времени) Хранилище ключей (операционный ключ)
БИОМЕТРИЧЕСКАЯ_СИЛЬНАЯ (Класс 3) да да да да
БИОМЕТРИЧЕСКАЯ_СЛАБАЯ (Класс 2) да да Нет Нет
БИОМЕТРИЧЕСКОЕ_УДОБСТВО
(Класс 1)
да Нет Нет Нет
DEVICE_CREDENTIAL да да да Да (1)
  1. Эта функция была добавлена ​​в Android 11, подробности см.

Платформа Android включает поддержку биометрической аутентификации по лицу и отпечатку пальца. Android можно настроить для поддержки других биометрических модальностей (например, Iris). Однако биометрическая интеграция будет зависеть от биометрической безопасности, а не от модальности. Дополнительные сведения о характеристиках безопасности биометрических данных см. в разделе Измерение безопасности разблокировки биометрических данных.

Источник

Андроид 11

  • Представляет интерфейс BiometricManager.Authenticators , который предоставляет константы, которые разработчики могут использовать для указания типов проверки подлинности, принимаемых их приложениями.
  • Добавляет действиенамерения ACTION_BIOMETRIC_ENROLL , которое разработчики могут использовать, чтобы указать пользователю зарегистрировать метод проверки подлинности, соответствующий требованиям их приложений.
  • Добавляет метод AuthenticationResult #getAuthenticationType () , который разработчики могут использовать для проверки того, прошел ли пользователь аутентификацию с помощью биометрических учетных данных или учетных данных устройства.
  • Обеспечивает дополнительную поддержку ключей аутентификации на основе использования в классе BiometricPrompt.

Андроид 10

  • Представляет класс BiometricManager , который разработчики могут использовать для запроса доступности биометрической проверки подлинности.
  • Включает интеграцию аутентификации по отпечаткам пальцев и лицу для BiometricPrompt

Андроид 9

  • Включает интеграцию отпечатков пальцев только для BiometricPrompt .
  • Устаревает класс FingerprintManager. Если ваши связанные и системные приложения используют этот класс, обновите их, чтобы вместо этого использовать BiometricPrompt и BiometricManager .
  • Обновлены тесты верификатора CTS FingerprintManager для тестирования BiometricPrompt с использованием BiometricPromptBoundKeysTest .

Реализация

Чтобы пользователи и разработчики могли без проблем работать с биометрическими данными, интегрируйте свой стек биометрических данных с API-интерфейсами BiometricPrompt , BiometricManager и ACTION_BIOMETRIC_ENROLL . Устройства с биометрическими датчиками должны соответствовать этим требованиям прочности .
Чтобы интегрировать свой биометрический стек с API-интерфейсами BiometricPrompt и BiometricManager APIs :

  1. Убедитесь, что ваша <Modality>Service правильно зарегистрирована в BiometricService с помощью метода IBiometricService#registerAuthenticator и реализует интерфейс IBiometricAuthenticator . Общие модальности (отпечаток пальца, лицо) происходят от общего суперкласса . Если вам нужно интегрировать неподдерживаемую модальность, следуйте примеру отпечатка пальца / лица и рекомендациям CDD для биометрии.
  2. Убедитесь, что ваша новая модальность правильно поддерживается в SystemUI . Существуют пользовательские интерфейсы BiometricPrompt по умолчанию для отпечатков пальцев и лица. Это должно включать любые изменения макета или темы, необходимые для вашего устройства. То есть соответствующие изменения макета для датчика отпечатков пальцев на дисплее.

Чтобы интегрировать свой биометрический стек с API ACTION_BIOMETRIC_ENROLL:

  1. Измените BiometricEnrollActivity , чтобы представить поток регистрации. Обратите внимание, что ваши биометрические данные могут быть представлены только в том случае, если они соответствуют требуемой надежности. Если ваше устройство поддерживает более одного, это действие должно представить список, из которого пользователь может выбрать.
Биометрическая архитектура Prompt
Рисунок 1. Архитектура BiometricPrompt

Рекомендации по реализации HAL

Следуйте этим рекомендациям HAL для биометрических данных, чтобы предотвратить утечку биометрических данных и их удаление при удалении пользователя с устройства:

  • Убедитесь, что необработанные биометрические данные или их производные (например, шаблоны) никогда не будут доступны из-за пределов защищенной изолированной среды (например, TEE или Secure Element). Все сохраненные данные должны быть зашифрованы ключом для конкретного устройства, известным только TEE (Trusted Execution Environment). Если аппаратное обеспечение поддерживает это, ограничьте аппаратный доступ к безопасной изолированной среде и защитите его с помощью политики SELinux. Сделайте канал связи (например, SPI, I2C) доступным только для безопасной изолированной среды с явной политикой SELinux для всех файлов устройства.
  • Сбор, регистрация и распознавание биометрических данных должны происходить внутри защищенной изолированной среды, чтобы предотвратить утечку данных и другие атаки. Это требование применяется только к биометрическим данным класса 3 (ранее Strong) и класса 2 (ранее Weak) .
  • Для защиты от повторных атак подписывайте биометрические шаблоны закрытым ключом для конкретного устройства. Для Advanced Encryption Standard (AES) как минимум подпишите шаблон с абсолютным путем в файловой системе, группой и биометрическим идентификатором, чтобы файлы шаблонов не работали на другом устройстве или для кого-либо, кроме пользователя, зарегистрировавшего их на том же устройстве. . Например, запретите копирование биометрических данных другого пользователя на том же устройстве или с другого устройства.
  • Если вам нужно хранить данные за пределами TEE, используйте путь к файловой системе, предоставленный методом setActiveUser() HIDL method или предоставьте другой способ стереть все данные пользовательского шаблона при удалении пользователя. Причина в том, чтобы защитить утечку пользовательских данных. Устройства, которые не используют этот путь, должны очищаться после удаления пользователя. CDD требует, чтобы биометрические данные и производные файлы хранились в зашифрованном виде, особенно если это не в TEE. стирается. См. LockSettingsService.removeBiometricsForUser()

Настройка

Если ваше устройство поддерживает несколько биометрических данных, пользователь должен иметь возможность указать значение по умолчанию в настройках. Ваша реализация BiometricPrompt должна предпочесть биометрию класса 3 (ранее Strong) по умолчанию, если только пользователь явно не переопределит ее, тогда должно отображаться предупреждающее сообщение с объяснением рисков, связанных с биометрией (например, ваша фотография может разблокировать ваше устройство). )

Проверка

Ваша биометрическая реализация должна пройти следующие тесты:

  • CTS BiometricManager
  • CTS BiometricPrompt (вменяемость, углубленное тестирование зависит от верификатора)
  • Раздел биометрического теста CtsVerifier : должен проходить индивидуально для каждого модальности, которую поддерживает устройство.

Кроме того, если ваше устройство поддерживает биометрические данные с AOSP HIDL ( отпечаток пальца@2.1, отпечаток пальца@2.2, лицо1.0 ), оно должно пройти соответствующий тест VTS ( отпечаток пальца , лицо ).