Привратник

Подсистема Gatekeeper выполняет аутентификацию устройства по шаблону/паролю в доверенной среде выполнения (TEE). Gatekeeper регистрирует и проверяет пароли, используя аппаратный секретный ключ. Кроме того, Gatekeeper блокирует последовательные неудачные попытки проверки и должен отказывать в обслуживании запросов по истечении заданного времени ожидания и заданного количества последовательных неудачных попыток.

Когда пользователи проверяют свои пароли, Gatekeeper выпускает токен аутентификации, подписанный ключом HMAC, доступным только для загрузочных компонентов, и этот токен отправляется в аппаратное хранилище ключей . То есть токен аутентификации Gatekeeper уведомляет хранилище ключей о том, что приложения могут использовать ключи, связанные с аутентификацией (например, ключи, созданные приложениями).

Архитектура

Gatekeeper включает в себя три основных компонента:

• gatekeeperd (демон Gatekeeper) — служба C++ Binder в Android, которая содержит платформенно-независимую логику, реализующую интерфейс IGateKeeperService AIDL на основе базовой реализации IGatekeeper , специфичной для поставщика.
• Служба уровня аппаратной абстракции Gatekeeper (HAL) — специфичная для поставщика реализация интерфейса IGatekeeper AIDL. Эта служба HAL работает в Android, но основные функции Gatekeeper должны работать в безопасной среде, поэтому она обычно взаимодействует с Gatekeeper TA.
• Доверенное приложение Gatekeeper (TA) — реализация, специфичная для поставщика, которая работает в TEE и выполняет фактическую проверку пароля или шаблона.

Служба LockSettingsService отправляет запрос (через Binder), который достигает демона gatekeeperd в ОС Android. Затем демон gatekeeperd отправляет запрос к службе HAL IGatekeeper , которая, в свою очередь, достигает своего аналога Gatekeeper TA в TEE:

Рисунок 1. Высокоуровневый поток данных для аутентификации GateKeeper.

Демон gatekeeperd предоставляет API фреймворка Android доступ к HAL и участвует в передаче данных об аутентификации устройств в хранилище ключей. Демон gatekeeperd работает в отдельном процессе и не связан с системным сервером.

Реализация HAL

Демон gatekeeperd использует HAL IGatekeeper для взаимодействия с базовым Gatekeeper TA для аутентификации пароля. Реализация Gatekeeper TA должна иметь возможность подписывать (регистрировать) и верифицировать двоичные объекты (BLOB-объекты). Все реализации должны придерживаться стандартного формата токена аутентификации ( HardwareAuthToken ), генерируемого при каждой успешной проверке пароля. Подробную информацию о содержании и семантике HardwareAuthToken см. в определении HardwareAuthToken.aidl .

Реализации HAL IGatekeeper от поставщика должны реализовывать функции enroll и verify :

• Метод enroll принимает двоичный объект пароля, подписывает его и возвращает подпись в виде дескриптора. Возвращаемый двоичный объект (вызов enroll ) должен иметь структуру, указанную в файле system/gatekeeper/include/gatekeeper/password_handle.h .
• Функция verify должна сравнить подпись, созданную предоставленным паролем, и убедиться, что она соответствует зарегистрированному дескриптору пароля.

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

Trusty и другие реализации

Операционная система Trusty — это доверенная ОС с открытым исходным кодом от Google для сред TEE, которая содержит одобренную реализацию Gatekeeper. Однако любая операционная система TEE может реализовать Gatekeeper, если у TEE есть доступ к постоянному аппаратному ключу и безопасным, монотонным часам , которые тикают в режиме ожидания .

Trusty использует внутреннюю систему IPC для прямой передачи общего секретного ключа между KeyMint (ранее Keymaster) и реализацией Gatekeeper в Trusty ( Trusty Gatekeeper ). Этот общий секретный ключ используется для подписи AuthToken, отправляемых в Keystore для подтверждения подлинности пароля. Trusty Gatekeeper запрашивает ключ у KeyMint при каждом использовании и не сохраняет и не кэширует его значение. Реализации могут свободно передавать этот секретный ключ любым способом, не нарушающим безопасность.

Ключ HMAC, используемый для регистрации и проверки паролей, создается и хранится исключительно в Gatekeeper.

Android предоставляет универсальную реализацию Gatekeeper на C++, для которой требуется лишь добавление специфичных для устройства процедур; реализация Trusty основана на ней. Чтобы реализовать Gatekeeper TEE с кодом, специфичным для устройства, обратитесь к функциям и комментариям в system/gatekeeper/include/gatekeeper/gatekeeper.h . Основные обязанности совместимой реализации включают:

• Соблюдение HAL IGatekeeper .
• Возвращаемые токены аутентификации должны быть отформатированы в соответствии со спецификацией HardwareAuthToken (описанной в разделе «Аутентификация »).
• TEE Gatekeeper должен иметь возможность поделиться ключом HMAC с KeyMint, либо запрашивая ключ через TEE IPC по требованию, либо постоянно поддерживая действительный кэш значения.

Безопасные идентификаторы пользователей (SID)

SID пользователя — это TEE-представление пользователя (без строгой привязки к идентификатору пользователя Android). SID генерируется с помощью криптографического генератора псевдослучайных чисел (ГПСЧ) каждый раз, когда пользователь регистрирует новый пароль, не предоставляя предыдущий. Это называется ненадёжной повторной регистрацией и обычно происходит только тогда, когда пользователь впервые устанавливает пароль или графический ключ.

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

SID пользователя включается в аутентификацию HMAC вместе с паролем в дескрипторе пароля при регистрации пароля.

Идентификаторы безопасности пользователей включаются в HardwareAuthToken , возвращаемый функцией verify() , и связываются со всеми ключами хранилища ключей, связанными с аутентификацией (подробную информацию о формате HardwareAuthToken и хранилище ключей см. в разделе Аутентификация ).

Обратите внимание, что ненадёжный вызов функции enroll() изменяет SID пользователя, делая ключи, привязанные к этому паролю, бесполезными. Злоумышленники могут изменить пароль устройства, если они контролируют ОС Android, но при этом они уничтожают конфиденциальные ключи, защищённые root-доступом.

Запрос регулирования

Gatekeeper должен иметь возможность безопасно блокировать попытки подбора учётных данных пользователя. Как показано в GatekeeperVerifyResponse.aidl , HAL обеспечивает возврат тайм-аута в миллисекундах. Тайм-аут информирует клиента о том, что не следует вызывать Gatekeeper повторно до истечения этого времени. Gatekeeper не должен обслуживать запросы, если существует ожидание тайм-аута.

Перед проверкой пароля пользователя привратник должен записать счётчик ошибок. Если пароль проверен успешно, счётчик ошибок должен быть очищен. Это предотвращает атаки, препятствующие регулированию пропускной способности путём отключения встроенной карты MMC (eMMC) после выполнения verify вызова. Функция enroll также проверяет пароль пользователя (если он указан) и должна регулироваться аналогичным образом.

Если устройство поддерживает эту функцию, настоятельно рекомендуется записывать счётчик сбоев в защищённое хранилище. Если устройство не поддерживает шифрование файлов или защищённое хранилище слишком медленное, реализации могут напрямую использовать Replay Protected Memory Block (RPMB).