Привратник

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

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

Архитектура

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

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

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

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

Демон gatekeeperd предоставляет API-интерфейсам платформы Android доступ к HAL и участвует в отправке отчетов об аутентификации устройства в Keystore. Демон 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 для передачи общего секрета непосредственно между мастером ключей и реализацией гейткипера Trusty ( Trusty Gatekeeper ). Этот общий секрет используется для подписи AuthTokens, отправляемых в хранилище ключей, чтобы обеспечить подтверждение проверки пароля. Trusty Gatekeeper запрашивает ключ у Keymaster для каждого использования и не сохраняет и не кэширует значение. Реализации могут свободно делиться этим секретом любым способом, который не ставит под угрозу безопасность.

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

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

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

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

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

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

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

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

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

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

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