Это я просто ответил на вопрос, дабы просто так без дела не кидать ссылку😀

Ахахах

Паранойя😁😄

Сейчас ж по сути никто пароли не брутит:) другие ж методы есть, по типу соц инженерии:)

Ты сам всё любезно мошенникам предоставишь

Базы перебирают

Кто может хакнуть покупку в приложении?

очевидно хакер какой-нибудь, здесь таких нет

Ну вдруг есть

А че денег дают? 😄

-

Ну если без денег, то ищи проверки и флипай условия там 😉

Друзья, всем доброго дня!
Решил несколько разобраться с тем, как происходит взаимодействие между ОС и TEE, а так же, как добавляются и извлекаются ключи из KeyStore.
Наткнулся на несколько разное толкование по поводу того, где  находится HMAC Key и кому доступен.
Сначала указано:

The HMAC key is kept solely in Keymaster; Fingerprint and Gatekeeper request the key from Keymaster for each use and don't persist or cache the value.

Потом они пишут, что:

The HMAC key used to enroll and verify passwords is derived and kept solely in GateKeeper.

Подскажите, кто что думает на этот счет?
https://source.android.com/security/authentication/gatekeeper?hl=en -  оригинальный источник

Знакомому нужен сниф мобильного приложения, за пару месяцев никто не смогу, оплата достойная. Отпишите в лс

Вспомнил как снифал приложение для многотонников

С заправками

Так прикольно было копаться

The HMAC key is kept solely in Keymaster; Fingerprint and Gatekeeper request the key from Keymaster for each use and don't persist or cache the value.

The HMAC key used to enroll and verify passwords is derived and kept solely in GateKeeper.

Ну смысл ТЕЕ в том чтобы генерировать какие-то значения, чтобы потом пользователь мог запрашивать их использование через обычный андроид фреймворк. ТЕЕ умеет генерить ключевые пары, после чего PrivateKey можно использовать в операциях подписи (RSA/ECDSA) и расшифровки (RSA), симметричные ключи, после чего кейстор можно попросить зашифровать/расшифровать данные используя эти SecretKey.

В андроиде ключи в аппаратном кейсторе генерятся внутри с помощью своего независимого аппаратного ГСЧ и никогда не добавляются извне, и, по-моему, это отличное решение.

Keymaster - нативный системный сервис через который ось общается с ТЕЕ, т.е. как раз проводятся все эти операции типа расшифруй/зашифруй эти данные ключём вот с этим алиасом, подписши эти данные приватным ключом вот с тем алиасом и т.д.

Gatekeeper - нативный системный сервис отвечающий за блокировку/разблокировку системы, через него ось выполняет проверку пинов/паролей/отпечатков/лиц.

Про HMAC видимо речь идёт о том что когда мы создаём пин или пароль, то мы очевидно не можем использовать материал этот в качестве основы для выработки ключей шифрования или подписи (например посчитава от него хэш SHA256), потому что он очень низкоэнтропийный, вместо этого мы используем HMAC (по простому - хэш с секретом), в котором секретом является SecretKey из кейстора, таким образом мы можем получить надёжные ключи например для шифрования ФС или схемы аутентификации из очень ненадёжного четырёхзначного пина. Перебрать 10^4 значений пина легко, но 2^32 значений секретного ключа HMAC - невозможно.

Не уверен на 100%, но вероятно что HMAC это больше про Gatekeeper (как раз аутентификация на разблокировке устройства) а такие формулировки возникают потому что  gatekeeper скорее всего сам использует keymaster для проведения расчётов

А так речь должна идти об одном и том же ключе

Именно так, ключ один и тот же, но по логике вещей, как сделано в Trusty TEE, gatekeeperd передаёт твой ПИН/Пароль/патерн на gatekeeperd в TEE (биометрия идет по аналогичному пути, но там отдельная реализация. Кроме того, для биометрии начиная с 9 добавили <Biometic>Manager, где вместо Biometric конкретная реализация Фингер или фэйс).
Дальше, реализация в TEE должна верифицировать данные, которые мы ей подсунули, если с ними все ок, то он запрашивает у keymaster ключ, с помощью которого он подпишет тут же сгенерированный AuthToken. Этот токен потом передаётся gatekeeperd (или другая реализация для биометрии), которая отдаёт его в keystore service. Keystore service дает токен keymaster, тот его проверят и или дает нам(приложению) получить ключик из keystore или нет. По моему так это работает, если я не прав - поправьте.
Вопрос был именно в том, кто является хранителем этого секретного ключа для подписи токена, потому как документы говорят о том, что этот ключ нужно каждый раз получать у keymaster, а так же его нельзя кэшировать или сохранять где то.