Android-эквивалент ios devicecheck

Существует ли Android-эквивалент проверки устройства ios https://developer.apple.com/documentation/devicecheck или какой-либо способ убедиться, что это ваш неуправляемый apk, выполняющий вызов API?

4 ответа

Первая часть вопроса

Есть ли Android-эквивалент проверки устройства ios? https://developer.apple.com/documentation/devicecheck

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

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

Кроме того, когда разработчик внедряет решение SafetyNet, ему необходимо помнить:

  • Он является частью Google Mobile Services (GMS), поэтому работает только на устройствах, которые имеют это. На некоторых рынках, например, на Дальнем Востоке, существует значительное количество устройств, у которых этого нет.

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

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

  • Поскольку SafetyNet выполняет полный анализ хэшей образа ОС, он может быть довольно медленным (иногда несколько секунд). Это означает, что он не может работать непрерывно, и при его использовании требуется некоторая осторожность, чтобы скрыть эту задержку от пользователя, но без создания возможности для взлома.

  • SafetyNet специально не анализирует карту памяти запущенных приложений для обнаружения платформ инструментов (она основана на том факте, что они могут работать только на корневых устройствах), таких как XPposed и Frida.

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

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

Вторая часть вопроса

или любой способ проверить, что это ваш неуправляемый apk, выполняющий вызов api?

Здесь можно использовать SafetyNet вместе со службой аттестации мобильных приложений. OAUTH2 также следует использовать, если в вашем мобильном приложении необходима аутентификация и аутентификация пользователя. Последнее, но не менее важное, это использование закрепления сертификатов для защиты канала связи между сервером API и мобильным приложением, как описано в этой серии статей о методах мобильного API.

Определение службы аттестации мобильных приложений

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

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

В случае сбоя в Аттестации приложения JWT подписывается с секретом, который сервер API не знает.

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

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

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

Служба аттестации мобильных приложений уже существует в качестве решения SAAS на Approov(я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.

У них есть SafetyNet - несколько более полный: https://developer.android.com/training/safetynet/index.html

Два API, на которые вы захотите взглянуть, - это Attestation и Verify Apps:

API-интерфейс Attestation проверяет целостность устройства, а API-интерфейс Verify Apps проверяет, установлены ли известные потенциально опасные приложения. Для дополнительной защиты вы должны проверить целостность устройства с помощью API-интерфейса Attestation, прежде чем использовать API-интерфейс Verify Apps.

Что касается второй части вашего вопроса, то, что вы запекаете в свое приложение, вы должны считать, что оно уже взломано, потому что злоумышленник может декомпилировать ваше приложение. Вам лучше сосредоточиться на надлежащей безопасности на стороне сервера и ограничить то, что фактически предоставляет ваш API, правильное шифрование, токенизацию (если имеет дело с информацией об оплате) и адекватную регистрацию для отслеживания гнусных вызовов вашего API. Есть причина, по которой вы нанимаете специализированных разработчиков, когда вы достаточно велики, чтобы привлечь внимание хакеров.

Для этого в Android есть собственное решение — KeyPairGenerator.

Пример создания новой пары ключей, если она еще не существует —

      KeyPairGenerator kpg = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore"); 
kpg.initialize(new KeyGenParameterSpec.Builder( 
        alias, // Key identifier 
        KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY) 
    .setDigests(KeyProperties.DIGEST_SHA256, KeyProperties.DIGEST_SHA512) 
    .setAttestationChallenge(attestationChallenge) 
    .build()); 
KeyPair kp = kpg.generateKeyPair();

Примечания:

  1. Вы должны указать ненулевое значение дляKeyPairGenerator.initializeметод для создания действительного объекта аттестации, иначе вы получите поддельную цепочку сертификатов.
  2. attestationChallengeможно получить, позвонив на соответствующую конечную точку вашего сервера, чтобы сгенерировать одноразовый вызов.

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

  • Поддерживаемые платформы — существуют межплатформенные решения для защиты API, такие как Talsec AppiCrypt, или специфичные для Android версии, такие как комплект Safety Detect Kit только для Huawei или Google Mobile Services SafetyNet.
  • Особенности производителя Android:
  • Влияние на производительность - т.е. SafetyNet вносит некоторую задержку, вызванную удаленной обработкой и оценкой данных. AppiCrypt обеспечивает стабильное время отклика <10 мс.

  • Сторонние элементы — использование сторонних серверов (например, Google SafetyNet, который не находится под вашим контролем) может быть проблемой для вашего бизнеса, если вам нужна гарантированная работа.

  • Уровень детализации угроз — нужен ли вам детальный анализ угроз и возможность реагировать соответствующим образом? Результат SafetyNet является бинарным: безопасное или опасное устройство. Если вам нужна более конкретная информация, в AppiCrypt есть подробная эвристическая система взвешивания для оценки угроз.

Другие вопросы по тегам