Привратник

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

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

Архитектура

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

• gatekeeperd (демон-привратник). Служба связывания C++, содержащая независимую от платформы логику и соответствующая Java-интерфейсу GateKeeperService .
• Уровень аппаратной абстракции гейткипера (HAL) . Интерфейс HAL в hardware/libhardware/include/hardware/gatekeeper.h и реализующий модуль.
• Привратник (TEE) . TEE-аналог gatekeeperd . Реализация Gatekeeper на основе TEE.

Gatekeeper требует реализации Gatekeeper HAL (в частности, функций в hardware/libhardware/include/hardware/gatekeeper.h ) и компонента Gatekeeper, специфичного для TEE (частично основанного на заголовочном файле system/gatekeeper/include/gatekeeper/gatekeeper.h который включает чисто виртуальные функции для создания/доступа к ключам и вычисления подписей).

LockSettingsService отправляет запрос (через Binder), который достигает демона gatekeeperd в ОС Android. Затем демон gatekeeperd отправляет запрос, который достигает своего аналога (привратника) в TEE:

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

реализация HAL

Демон gatekeeperd использует HAL для взаимодействия с аналогом TEE демона gatekeeperd для аутентификации по паролю. Реализация HAL должна иметь возможность подписывать (регистрировать) и проверять большие двоичные объекты. Ожидается, что все реализации будут соответствовать стандартному формату токена аутентификации (AuthToken), создаваемого при каждой успешной проверке пароля. Подробную информацию о содержимом и семантике AuthToken см. в разделе Формат AuthToken .

Реализации заголовочного файла hardware/libhardware/include/hardware/gatekeeper.h должны реализовывать функции enroll и verify :

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

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

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

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

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

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

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

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

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

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

SID пользователя записывается в HMAC вместе с паролем в дескрипторе пароля при регистрации пароля.

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

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

GateKeeper должен иметь возможность безопасно ограничивать попытки грубого подбора учетных данных пользователя. Как показано в hardware/libhardware/include/hardware/gatekeeper.h , HAL обеспечивает возврат тайм-аута в миллисекундах. Тайм-аут сообщает клиенту, что ему не следует снова вызывать GateKeeper до тех пор, пока не истечет тайм-аут; GateKeeper не должен обслуживать запросы, если истекло время ожидания.

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

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