Android: безопасность CryptoObject и BiometricPrompt. Можно ли взломать?

Ваши вопросы по теме

Android: безопасность CryptoObject и BiometricPrompt. Можно ли взломать?

Если это программное обеспечение, то его можно взломать. Это всего лишь вопрос времени, знаний и усилий.

Но есть ли известные уязвимости в этом механизме? Есть ли возможность получить этот криптообъект без использования биометрии (например, на корневом устройстве)?

Не то, чтобы я был в курсе, но я не эксперт в реверс-инжиниринге, просто человек, обладающий достаточными знаниями, чтобы сказать вам, что злоумышленнику не нужно обходить этот механизм безопасности, чтобы извлечь секрет из вашего мобильного приложения.

Просто продолжайте читать, чтобы понять, как это возможно...

Секреты в мобильном приложении общедоступны

Мне нужно надежно хранить определенный секрет в моем приложении с помощью биометрии. Я хотел использовать BiometricPrompt для получения CryptoObject, который будет использоваться для шифрования и расшифровки этого секрета.

Использование CryptoObject и BiometricPrompt надежно зашифрует секрет и сохранит его с помощью механизма подчеркивания, известного Android Hardware. -хранилище ключей:

Наличие доверенной среды выполнения в системе на кристалле (SoC) дает возможность устройствам Android предоставлять аппаратно поддерживаемые надежные службы безопасности для ОС Android, служб платформы и даже сторонних приложений.

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

Одна из самых популярных инструментальных сред — Frida:

Внедряйте собственные скрипты в процессы черного ящика. Подключайте любую функцию, следите за криптографическими API или отслеживайте код частного приложения, исходный код не требуется. Отредактируйте, нажмите «Сохранить» и сразу же увидите результаты. Все без шагов компиляции или перезапуска программы.

Суть здесь в том, что независимо от того, насколько безопасно вы храните свои секреты в мобильном приложении, они должны считаться общедоступными с момента выпуска мобильного приложения.

Делегировать доступ к сторонним сервисам и API

Я часто вижу, как к сторонним API обращаются непосредственно из мобильного приложения, поэтому мобильное приложение должно иметь секреты для доступа к ним.

Проблема с этим подходом заключается в том, что, поскольку вы не можете гарантировать, что злоумышленник не украдет ваши секреты, вы можете узнать, что они были скомпрометированы, только когда ваш счет за использование этих услуг достигнет крыши. Хуже того, вы можете обнаружить, что секреты были скомпрометированы только после того, как вам стало известно, что вы пострадали от утечки данных, но теперь репутация вашего бизнеса серьезно пострадала или повреждена без возможности восстановления, не говоря уже об огромных штрафах, которые могут быть наложены на бизнес. платить из-за нарушений законов, таких как GDPR в Европе.

Поэтому я советую всегда делегировать бэкэнду, который вы контролируете доступ к сторонним службам/API, и вы можете прочитать больше об этом в моей статье Использование обратного прокси-сервера для защиты сторонних API:

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

Теперь вы можете сказать, что вам все еще нужен секрет для доступа к этому обратному прокси, и это правда, но теперь вы включаете только один секрет в мобильное приложение для серверной части, которую вы полностью контролируете, где вы можете применять все меры защиты. вы считаете нужным отслеживать злоупотребления, ограничивать их или полностью блокировать. Так что больше никаких неожиданных счетов в ваших сторонних сервисах/API, потому что теперь доступ к ним осуществляется через этот сервер, которым вы управляете.

Суть в том, что мобильное приложение должно взаимодействовать только с серверной частью, находящейся под вашим контролем, и любой доступ к сторонним службам API должен осуществляться тем же сервером, которым вы управляете. Таким образом, вы ограничиваете поверхность атаки только одним местом, где вы будете использовать столько уровней защиты, сколько стоит то, что вы защищаете.

Возможные решения для защиты вашего бэкэнда

Выше я упоминал, что вы можете применять меры защиты, которые считаете нужными, и рекомендую вам прочитать этот ответ, который я дал на вопрос Как защитить API REST для мобильного приложения?, особенно разделы Защита сервера API и Возможное лучшее решение, чтобы понять некоторые варианты. .

Вы хотите пройти лишнюю милю?

В любом ответе на секретный вопрос я всегда хотел бы сослаться на прекрасную работу фонда OWASP.

Для АПИС

10 лучших API-интерфейсов OWASP

Проект OWASP API Security Project направлен на обеспечение ценности для разработчиков программного обеспечения и экспертов по безопасности, подчеркивая потенциальные риски, связанные с небезопасными API, и показывая, как эти риски можно снизить. Для достижения этой цели проект OWASP API Security Project создаст и будет поддерживать документ «10 основных рисков безопасности API», а также портал документации для лучших практик создания или оценки API.

Для мобильных приложений

Проект OWASP Mobile Security — 10 основных рисков

Проект OWASP Mobile Security — это централизованный ресурс, предназначенный для предоставления разработчикам и специалистам по безопасности ресурсов, необходимых им для создания и обслуживания безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски безопасности мобильных устройств и обеспечить контроль разработки, чтобы уменьшить их влияние или вероятность использования.

OWASP — Руководство по тестированию безопасности мобильных устройств:

Руководство по тестированию безопасности мобильных устройств (MSTG) — это подробное руководство по разработке, тестированию и обратному проектированию безопасности мобильных приложений.