AB
нашел в чем проблема
все скучно - во flavor прописано android:networkSecurityConfig.
расходимся)
Size: a a a
2018 March 30
2018 April 02
ВЛ
Предусловие: есть два приложение подписанные разными ключами, между ними надо передавать данные, сейчас передача реализованы через broadcastreceiver с разрешением. Это разрешение объявлено в приложении А. Если их скачивать в следующем порядке: сначала А, потом Б. Тогда передача данных работает, если наоборот, то не работает. Какие есть варианты решения проблемы порядка скачивания?
D
service & aidl interface
PV
Добрый день, друзья. Познакомился с этой группой на крайнем мосдроиде, Георгий упомянул её в докладе :) И, собственно, примерно по теме доклада и будет мой к вам вопрос.
Помогите пожалуйста советом. Столкнулся с неприятной необходимостью хранить внутри приложения секретную строку.
Я решил прибегнуть к следующему: использую AndroidKeystore, генерирую случайный SecretKey для AES и храню его в KeyStore. С помощью этого ключа шифрую и ложу в шаредпрефы свою строку.
Для того чтобы не палить строку в коде, сделал служебный экран, который используется для того чтобы принять от пользователя строку, сгенерить AESный ключ в кейсторе, зашифровать и сохранить её в префы. Т.е. потенциальное вытаскивание из исходников отметается. Девайс вроде как поддерживает Hardware backed ключи и операции с ними проводит в TEE.
Приложение будет использоваться нешироким кругом пользователей и только на одних определённых устройствах (там API 23).
Ситуация в том что конфиденциальность этой строки превыше всего. Устройства служебные и будут выдаваться на руки. Предполагаю что наша строка будет "прошиваться" нами в устройства руками, это не самый удобный сценарий, но для нас это ок. Если работоспособность приложения пропадёт, ничего страшного не случится. Главное не раскрыть строку.
При необходимости получить и использовать значение строки в коде я совершаю ряд проверок и в случае фейла хотя бы одной из них кейстор и префы зачищаются:
- Получаю ключ из кейстора, дергаю его KeyInfo и проверяю что isInsideSecureHardware() возвращает true
- Посильно проверяю на отсутствие рута (наличие известных бинарников su, пакетов известных менеджеров рут-доступа, readonly состояние системных директорий итд)
Есть мысли добавить проверки google safetynet, который помогает проверить что апкшник не был изменён после выкачивания из стора (не знаком с технологией лично, только почитал о ней) а также содержит какие то свои проверки на рут.
Подскажите пожалуйста, нормальное ли это решение и/или какие ещё меры нужно принять? Можно ли как то эту строку выпотрошить из приложения в рантайме? Моих знаний о безопасности андроида не хватает для полноценного решения этой задачи, поэтому обращаюсь к вам.
Заранее спасибо.
Помогите пожалуйста советом. Столкнулся с неприятной необходимостью хранить внутри приложения секретную строку.
Я решил прибегнуть к следующему: использую AndroidKeystore, генерирую случайный SecretKey для AES и храню его в KeyStore. С помощью этого ключа шифрую и ложу в шаредпрефы свою строку.
Для того чтобы не палить строку в коде, сделал служебный экран, который используется для того чтобы принять от пользователя строку, сгенерить AESный ключ в кейсторе, зашифровать и сохранить её в префы. Т.е. потенциальное вытаскивание из исходников отметается. Девайс вроде как поддерживает Hardware backed ключи и операции с ними проводит в TEE.
Приложение будет использоваться нешироким кругом пользователей и только на одних определённых устройствах (там API 23).
Ситуация в том что конфиденциальность этой строки превыше всего. Устройства служебные и будут выдаваться на руки. Предполагаю что наша строка будет "прошиваться" нами в устройства руками, это не самый удобный сценарий, но для нас это ок. Если работоспособность приложения пропадёт, ничего страшного не случится. Главное не раскрыть строку.
При необходимости получить и использовать значение строки в коде я совершаю ряд проверок и в случае фейла хотя бы одной из них кейстор и префы зачищаются:
- Получаю ключ из кейстора, дергаю его KeyInfo и проверяю что isInsideSecureHardware() возвращает true
- Посильно проверяю на отсутствие рута (наличие известных бинарников su, пакетов известных менеджеров рут-доступа, readonly состояние системных директорий итд)
Есть мысли добавить проверки google safetynet, который помогает проверить что апкшник не был изменён после выкачивания из стора (не знаком с технологией лично, только почитал о ней) а также содержит какие то свои проверки на рут.
Подскажите пожалуйста, нормальное ли это решение и/или какие ещё меры нужно принять? Можно ли как то эту строку выпотрошить из приложения в рантайме? Моих знаний о безопасности андроида не хватает для полноценного решения этой задачи, поэтому обращаюсь к вам.
Заранее спасибо.
ВЛ
service & aidl interface
а как сделать так, чтобы только приложение Б могло передовать данные в приложение А?
D
а как сделать так, чтобы только приложение Б могло передовать данные в приложение А?
проверять pid вызываемоего процесса
https://stackoverflow.com/questions/32208237/retrieving-java-package-name-of-aidl-consumer/33963315#33963315
https://stackoverflow.com/questions/32208237/retrieving-java-package-name-of-aidl-consumer/33963315#33963315
D
Добрый день, друзья. Познакомился с этой группой на крайнем мосдроиде, Георгий упомянул её в докладе :) И, собственно, примерно по теме доклада и будет мой к вам вопрос.
Помогите пожалуйста советом. Столкнулся с неприятной необходимостью хранить внутри приложения секретную строку.
Я решил прибегнуть к следующему: использую AndroidKeystore, генерирую случайный SecretKey для AES и храню его в KeyStore. С помощью этого ключа шифрую и ложу в шаредпрефы свою строку.
Для того чтобы не палить строку в коде, сделал служебный экран, который используется для того чтобы принять от пользователя строку, сгенерить AESный ключ в кейсторе, зашифровать и сохранить её в префы. Т.е. потенциальное вытаскивание из исходников отметается. Девайс вроде как поддерживает Hardware backed ключи и операции с ними проводит в TEE.
Приложение будет использоваться нешироким кругом пользователей и только на одних определённых устройствах (там API 23).
Ситуация в том что конфиденциальность этой строки превыше всего. Устройства служебные и будут выдаваться на руки. Предполагаю что наша строка будет "прошиваться" нами в устройства руками, это не самый удобный сценарий, но для нас это ок. Если работоспособность приложения пропадёт, ничего страшного не случится. Главное не раскрыть строку.
При необходимости получить и использовать значение строки в коде я совершаю ряд проверок и в случае фейла хотя бы одной из них кейстор и префы зачищаются:
- Получаю ключ из кейстора, дергаю его KeyInfo и проверяю что isInsideSecureHardware() возвращает true
- Посильно проверяю на отсутствие рута (наличие известных бинарников su, пакетов известных менеджеров рут-доступа, readonly состояние системных директорий итд)
Есть мысли добавить проверки google safetynet, который помогает проверить что апкшник не был изменён после выкачивания из стора (не знаком с технологией лично, только почитал о ней) а также содержит какие то свои проверки на рут.
Подскажите пожалуйста, нормальное ли это решение и/или какие ещё меры нужно принять? Можно ли как то эту строку выпотрошить из приложения в рантайме? Моих знаний о безопасности андроида не хватает для полноценного решения этой задачи, поэтому обращаюсь к вам.
Заранее спасибо.
Помогите пожалуйста советом. Столкнулся с неприятной необходимостью хранить внутри приложения секретную строку.
Я решил прибегнуть к следующему: использую AndroidKeystore, генерирую случайный SecretKey для AES и храню его в KeyStore. С помощью этого ключа шифрую и ложу в шаредпрефы свою строку.
Для того чтобы не палить строку в коде, сделал служебный экран, который используется для того чтобы принять от пользователя строку, сгенерить AESный ключ в кейсторе, зашифровать и сохранить её в префы. Т.е. потенциальное вытаскивание из исходников отметается. Девайс вроде как поддерживает Hardware backed ключи и операции с ними проводит в TEE.
Приложение будет использоваться нешироким кругом пользователей и только на одних определённых устройствах (там API 23).
Ситуация в том что конфиденциальность этой строки превыше всего. Устройства служебные и будут выдаваться на руки. Предполагаю что наша строка будет "прошиваться" нами в устройства руками, это не самый удобный сценарий, но для нас это ок. Если работоспособность приложения пропадёт, ничего страшного не случится. Главное не раскрыть строку.
При необходимости получить и использовать значение строки в коде я совершаю ряд проверок и в случае фейла хотя бы одной из них кейстор и префы зачищаются:
- Получаю ключ из кейстора, дергаю его KeyInfo и проверяю что isInsideSecureHardware() возвращает true
- Посильно проверяю на отсутствие рута (наличие известных бинарников su, пакетов известных менеджеров рут-доступа, readonly состояние системных директорий итд)
Есть мысли добавить проверки google safetynet, который помогает проверить что апкшник не был изменён после выкачивания из стора (не знаком с технологией лично, только почитал о ней) а также содержит какие то свои проверки на рут.
Подскажите пожалуйста, нормальное ли это решение и/или какие ещё меры нужно принять? Можно ли как то эту строку выпотрошить из приложения в рантайме? Моих знаний о безопасности андроида не хватает для полноценного решения этой задачи, поэтому обращаюсь к вам.
Заранее спасибо.
скорее это история с NDK и libkeystore_binder, все маняпуляции производить нативно, и реализация JNI интерфейса для получения этой строки. Выпотрошить всегда можно, сделав дамп heap приложения (hprof).
Поэтому в памяти нужно тоже "по-особому" хранить
Поэтому в памяти нужно тоже "по-особому" хранить
ВЛ
проверять pid вызываемоего процесса
https://stackoverflow.com/questions/32208237/retrieving-java-package-name-of-aidl-consumer/33963315#33963315
https://stackoverflow.com/questions/32208237/retrieving-java-package-name-of-aidl-consumer/33963315#33963315
сначала не понял с pid, он же меняется от запуска к запуску.
Ты предлагаешь по pid получить package, а вотом проверить этот package на то, что это тот от которого мы ожидаем сообщение?
Ты предлагаешь по pid получить package, а вотом проверить этот package на то, что это тот от которого мы ожидаем сообщение?
D
сначала не понял с pid, он же меняется от запуска к запуску.
Ты предлагаешь по pid получить package, а вотом проверить этот package на то, что это тот от которого мы ожидаем сообщение?
Ты предлагаешь по pid получить package, а вотом проверить этот package на то, что это тот от которого мы ожидаем сообщение?
yep
ВЛ
в целов звучит круто. Пойду покурю AIDL
VD
Хардкорненько. А кастомный пермишн не получится использовать?
ВЛ
Предусловие: есть два приложение подписанные разными ключами, между ними надо передавать данные, сейчас передача реализованы через broadcastreceiver с разрешением. Это разрешение объявлено в приложении А. Если их скачивать в следующем порядке: сначала А, потом Б. Тогда передача данных работает, если наоборот, то не работает. Какие есть варианты решения проблемы порядка скачивания?
ВЛ
Хардкорненько. А кастомный пермишн не получится использовать?
переслал сообщение
D
вариант, забыл что можно навешать его)
ВЛ
сейчас используется, получается, что для работы нужно в правильном порядке установить приложения
ВЛ
может быть что-то не так сделал
D
сейчас используется, получается, что для работы нужно в правильном порядке установить приложения
если история с сервисом и aidl будет, сделать пермишен можно, так как если не будет разрешения, он не сможет прибиндится
https://stackoverflow.com/questions/11730085/android-custom-permission-fails-based-on-app-install-order
https://stackoverflow.com/questions/11730085/android-custom-permission-fails-based-on-app-install-order
R
https://habrahabr.ru/post/352252/ - немного капитанская статья, но для начинающих должна отлично зайти.
PV
скорее это история с NDK и libkeystore_binder, все маняпуляции производить нативно, и реализация JNI интерфейса для получения этой строки. Выпотрошить всегда можно, сделав дамп heap приложения (hprof).
Поэтому в памяти нужно тоже "по-особому" хранить
Поэтому в памяти нужно тоже "по-особому" хранить
Спасибо, а можно где нибудь поглубже почитать про эту тему?
Если строка будет храниться на нативной стороне, то хипдамп её не сольёт?
Если строка будет храниться на нативной стороне, то хипдамп её не сольёт?