KI
здесь как раз кусок с паролем
Size: a a a
2021 January 25
R
Обрати внимание на провайдера. Там JKS
KI
ну да, все так
R
Я выше писал, что для JKS можно пароли, для AndroidKeyStore нет
KI
а, вот оно что, тогда ясно
RS
имеется в виду шифрование своими ключами подставными?
Просто представляю это так:
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
R
Я про это все скоро видос сделаю. Только раскидаюсь тут с делами чутка
R
Просто представляю это так:
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
По подписи, не по имени
KI
Просто представляю это так:
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
На нашем проекте мы использовали JKS, у него без пароля приватный ключ не получишь. Алиасы все посмотреть можно, также получить сертификаты по алиасу, а вот приватный ключ, который и используется для криптографических операций, нет
R
На нашем проекте мы использовали JKS, у него без пароля приватный ключ не получишь. Алиасы все посмотреть можно, также получить сертификаты по алиасу, а вот приватный ключ, который и используется для криптографических операций, нет
Все так, но этот файл можно стащить с девайса и натравить переборщик. Из AndroidKeyStore проще так не стащищь ключевой материал
KI
я вот даже не трогал AndroidKeyStore, по докам выглядит неплохо, буду ждать видосика)
PV
Просто представляю это так:
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
KeyStore генерирует ключ, и хранит его в аппаратном хранилище, которые должно быть прям мега-секюрное, что даже root туда не зайдет.
И эти ключи доступны только моему приложению в виде списка ключей (мои aliases видны только моему приложению).
И каждый из этих ключей может использовать для шифровки и расшифровки какой-то информации.
Если я в чем-то тут не прав, плиз, поправьте.
И то, что в приложении я доступ к ключу получаю, просто по его имени, у меня складывается оущщение, что это не безопасно)
Ну и я каждому юзеру создаю отдельный alias, отдельные ключи. Но чисто технически, даже когда у меня залогинен один юзер, у меня есть ключи всех пользователей, просто по alias. И это мне тоже показалось не очень безопасным.
Всем спасибо за объяснения)
Всё примерно так и есть. Рут туда не зайдёт потому что ТЕЕ - это отдельная операционная система, и из андроида она видна только в виде HAL и общение с ней происходит в бинарном формате примерно так:
TX: "вот мой 128-битный блок данных, зашифруй их шифром таким-то, ключом с алиасом таким то, в режиме таком-то"
RX: "вот тебе 128-битный зашифрованный результат"
TX: "вот тебе данные, подпиши их ключом с алиасом таким-то"
RX: "вот тебе результат подписи"
TX: "вот мой 128-битный блок данных, зашифруй их шифром таким-то, ключом с алиасом таким то, в режиме таком-то"
RX: "вот тебе 128-битный зашифрованный результат"
TX: "вот тебе данные, подпиши их ключом с алиасом таким-то"
RX: "вот тебе результат подписи"
RS
я вот даже не трогал AndroidKeyStore, по докам выглядит неплохо, буду ждать видосика)
Забавно, почему-то в гугле мне только его использование и попадалось)
А если использовать JKS, это получается файлик нужно будет хранить где-то в Internal Storage?
И дёргать его, когда мне нужны будут ключи
А если использовать JKS, это получается файлик нужно будет хранить где-то в Internal Storage?
И дёргать его, когда мне нужны будут ключи
RS
Всё примерно так и есть. Рут туда не зайдёт потому что ТЕЕ - это отдельная операционная система, и из андроида она видна только в виде HAL и общение с ней происходит в бинарном формате примерно так:
TX: "вот мой 128-битный блок данных, зашифруй их шифром таким-то, ключом с алиасом таким то, в режиме таком-то"
RX: "вот тебе 128-битный зашифрованный результат"
TX: "вот тебе данные, подпиши их ключом с алиасом таким-то"
RX: "вот тебе результат подписи"
TX: "вот мой 128-битный блок данных, зашифруй их шифром таким-то, ключом с алиасом таким то, в режиме таком-то"
RX: "вот тебе 128-битный зашифрованный результат"
TX: "вот тебе данные, подпиши их ключом с алиасом таким-то"
RX: "вот тебе результат подписи"
Спасибо)
KI
Забавно, почему-то в гугле мне только его использование и попадалось)
А если использовать JKS, это получается файлик нужно будет хранить где-то в Internal Storage?
И дёргать его, когда мне нужны будут ключи
А если использовать JKS, это получается файлик нужно будет хранить где-то в Internal Storage?
И дёргать его, когда мне нужны будут ключи
Да, файлик будет либо в песочнице, либо там где ты положишь
KI
Ну у нас была специфическая история, нам бы андроидовский стор не подошёл
PV
Все так, но этот файл можно стащить с девайса и натравить переборщик. Из AndroidKeyStore проще так не стащищь ключевой материал
Кстати, всегда было интерсно, но ни разу не проверял на практике, действуют ли на симметричные ключи в кейсторе такие же ограничения как на проверку пин-кода на экране который показывается после загрузки устройства? Потому что при гипотетическом сценарии полного контроля над приложением на устройстве, если ключ AES используется как часть операции со вводом пользователя у которого явно низкая энтропия, типа проверки пин-кода (допустим 4-хзначного) то можем ли мы от лица самого приложения задолбать кейстор брутфорсом, учитывая что возможных результатов всего 10 в 4 степени?
С экраном ввода пин-кода разблокировки системы так точно не получится, потому что там ТЕЕ использует RPMB блок в котором хранит счётчик неправильно введённых пинов и таймштампы последней попытки чтобы увеличивать интервал между возможными попытками ввода пин-кодов
С экраном ввода пин-кода разблокировки системы так точно не получится, потому что там ТЕЕ использует RPMB блок в котором хранит счётчик неправильно введённых пинов и таймштампы последней попытки чтобы увеличивать интервал между возможными попытками ввода пин-кодов
R
Кстати, всегда было интерсно, но ни разу не проверял на практике, действуют ли на симметричные ключи в кейсторе такие же ограничения как на проверку пин-кода на экране который показывается после загрузки устройства? Потому что при гипотетическом сценарии полного контроля над приложением на устройстве, если ключ AES используется как часть операции со вводом пользователя у которого явно низкая энтропия, типа проверки пин-кода (допустим 4-хзначного) то можем ли мы от лица самого приложения задолбать кейстор брутфорсом, учитывая что возможных результатов всего 10 в 4 степени?
С экраном ввода пин-кода разблокировки системы так точно не получится, потому что там ТЕЕ использует RPMB блок в котором хранит счётчик неправильно введённых пинов и таймштампы последней попытки чтобы увеличивать интервал между возможными попытками ввода пин-кодов
С экраном ввода пин-кода разблокировки системы так точно не получится, потому что там ТЕЕ использует RPMB блок в котором хранит счётчик неправильно введённых пинов и таймштампы последней попытки чтобы увеличивать интервал между возможными попытками ввода пин-кодов
Я об этом выше и писал (или мне кажется). Когда локальный пинкод в приложении, то это всегда подвержено брутфорсу.
R
Его время можно увеличивать, так или иначе, но все равно это брутится.
KI
Кстати, всегда было интерсно, но ни разу не проверял на практике, действуют ли на симметричные ключи в кейсторе такие же ограничения как на проверку пин-кода на экране который показывается после загрузки устройства? Потому что при гипотетическом сценарии полного контроля над приложением на устройстве, если ключ AES используется как часть операции со вводом пользователя у которого явно низкая энтропия, типа проверки пин-кода (допустим 4-хзначного) то можем ли мы от лица самого приложения задолбать кейстор брутфорсом, учитывая что возможных результатов всего 10 в 4 степени?
С экраном ввода пин-кода разблокировки системы так точно не получится, потому что там ТЕЕ использует RPMB блок в котором хранит счётчик неправильно введённых пинов и таймштампы последней попытки чтобы увеличивать интервал между возможными попытками ввода пин-кодов
С экраном ввода пин-кода разблокировки системы так точно не получится, потому что там ТЕЕ использует RPMB блок в котором хранит счётчик неправильно введённых пинов и таймштампы последней попытки чтобы увеличивать интервал между возможными попытками ввода пин-кодов
если говорить о самом сторе, то я видел провайдеры которые проверяют количество попыток ввода пароля, но брутить такие все ещё можно, если заново стор открывать, если я все правильно помню