Аутентификация

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

• Поставщик хранения и услуг криптографических ключей. Хранит криптографические ключи и предоставляет стандартные криптографические процедуры поверх этих ключей. Android поддерживает аппаратное хранилище ключей и Keymaster для криптографических служб, включая аппаратную криптографию для хранения ключей, которая может включать доверенную среду выполнения (TEE) или элемент безопасности (SE), например Strongbox.
• Аутентификаторы пользователей. Подтвердите присутствие пользователя и/или успешную аутентификацию. Android поддерживает Gatekeeper для аутентификации по PIN-коду, шаблону или паролю и Fingerprint для аутентификации по отпечатку пальца. Устройства, поставляемые с Android 9 и выше, могут использовать BiometricPrompt в качестве единой точки интеграции для отпечатков пальцев и дополнительных биометрических данных. Эти компоненты сообщают о своем состоянии аутентификации службе хранилища ключей через аутентифицированный канал. ( Система хранилища ключей Android на уровне платформы также поддерживается службой хранилища ключей.)

Компоненты Gatekeeper, Fingerprint и Biometric работают с Keystore и другими компонентами для поддержки использования аппаратных токенов аутентификации (AuthTokens).

Регистрация

При первой загрузке устройства после сброса настроек все аутентификаторы готовы к получению учетных данных от пользователя. Пользователь должен первоначально зарегистрировать PIN-код/шаблон/пароль в Gatekeeper. Эта первоначальная регистрация создает случайно сгенерированный 64-битный безопасный идентификатор пользователя (SID), который служит идентификатором пользователя и маркером привязки для криптографического материала пользователя. Этот SID пользователя криптографически привязан к паролю пользователя; успешная аутентификация на Gatekeeper приводит к созданию токенов AuthToken, содержащих SID пользователя для этого пароля.

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

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

Аутентификация

После того как пользователь настроил учетные данные и получил пользовательский SID, он может начать аутентификацию, которая начинается, когда пользователь предоставляет PIN-код, шаблон, пароль или отпечаток пальца. Все компоненты TEE имеют общий секретный ключ, который они используют для аутентификации сообщений друг друга.

1. Пользователь предоставляет метод аутентификации, а связанная служба отправляет запрос связанному демону.
   • Для получения PIN-кода, шаблона или пароля LockSettingsService отправляет запрос gatekeeperd .
   • Потоки аутентификации на основе биометрии зависят от версии Android. На устройствах под управлением Android 8.x и ниже FingerprintService отправляет запрос на fingerprintd ). На устройствах под управлением Android 9 и более поздних версий BiometricPrompt отправляет запрос соответствующему биометрическому демону (например, fingerprintd для отпечатков пальцев или faced для лица), используя соответствующий класс Biometric Manager , например FingerprintManager или FaceManager . Независимо от версии, биометрическая аутентификация происходит асинхронно после отправки запроса.
2. Демон отправляет данные своему аналогу, который генерирует AuthToken:
   • Для аутентификации по PIN-коду, шаблону или паролю gatekeeperd отправляет PIN-код, шаблон или хеш пароля гейткиперу в TEE. Если аутентификация в TEE прошла успешно, гейткипер в TEE отправляет AuthToken, содержащий соответствующий SID пользователя (подписанный ключом AuthToken HMAC), своему аналогу в ОС Android.
   • Для аутентификации по отпечатку пальца fingerprintd прослушивает события отпечатка пальца и отправляет данные в Fingerprint в TEE. Если аутентификация в TEE прошла успешно, Fingerprint в TEE отправляет AuthToken (подписанный ключом AuthToken HMAC) своему аналогу в ОС Android.
   • Для другой биометрической аутентификации соответствующий биометрический демон прослушивает биометрическое событие и отправляет его соответствующему биометрическому компоненту TEE.
3. Демон получает подписанный AuthToken и передает его службе хранилища ключей через расширение интерфейса Binder службы хранилища ключей. ( gatekeeperd также уведомляет службу хранилища ключей при повторной блокировке устройства и изменении пароля устройства.)
4. Служба хранилища ключей передает токены AuthTokens в Keymaster и проверяет их, используя ключ, общий с Gatekeeper, и поддерживаемый биометрический компонент TEE. Keymaster доверяет метке времени в токене как времени последней аутентификации и основывает решение о выпуске ключа (чтобы разрешить приложению использовать ключ) на этой метке времени.

Формат токена авторизации

Чтобы обеспечить совместное использование токенов и совместимость между языками и компонентами, формат AuthToken описан в hw_auth_token.h . Формат представляет собой простой протокол сериализации с полями фиксированного размера.

Порядок загрузки устройства

При каждой загрузке устройства ключ AuthToken HMAC должен создаваться и использоваться всеми компонентами TEE (Gatekeeper, Keymaster и поддерживаемыми биометрическими трастлетами). Таким образом, для дополнительной защиты от атак повторного воспроизведения ключ HMAC должен генерироваться случайным образом каждый раз при перезагрузке устройства.

Протокол для совместного использования этого ключа HMAC со всеми компонентами является функцией реализации, зависящей от платформы. Ключ никогда не должен быть доступен за пределами TEE. Если в ОС TEE отсутствует механизм внутреннего межпроцессного взаимодействия (IPC) и необходимо передавать данные через недоверенную ОС, передача должна осуществляться через защищенный протокол обмена ключами.

Операционная система Trusty , работающая рядом с Android, является примером TEE, но вместо нее можно использовать и другие TEE. Trusty использует внутреннюю систему IPC для прямой связи между Keymaster и Gatekeeper или соответствующим биометрическим трастлетом. Ключ HMAC хранится исключительно в Keymaster; Отпечаток пальца и гейткипер запрашивают ключ у Keymaster для каждого использования и не сохраняют и не кэшируют значение.

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