Является ли этот план предотвращением подмены iPhone приложения iPhone?

Question

Я разрабатываю приложение для iPhone, которое общается с сервером через HTTP.

Я хочу, чтобы приложение, а не произвольные HTTP-клиенты, могло получать POST для определенных URL-адресов на сервере. Поэтому я настрою сервер только для проверки POST, которые включают секретный токен, и настройте приложение, чтобы включить этот секретный токен. Все запросы, которые включают этот токен, будут отправляться только через соединение HTTPS, так что его нельзя обнюхивать.

Вы видите какие-либо недостатки в этом рассуждении? Например, можно ли было бы прочитать токен из скомпилированного приложения, используя «строки», шестнадцатеричный редактор и т. Д.? Конечно, я не буду хранить этот токен в формате .plist или другом текстовом формате.

Предложения по альтернативному дизайну приветствуются.

Answer 1

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

Что действительно важно, кто пытается получить ключ, и каков их стимул. Продавайте продукт, нацеленный на демографию, которая не хочет красть. Оцените свой продукт так, чтобы его было дешевле, чем искать ключ. Обеспечьте хорошее обслуживание своих клиентов. Это все маркетинговые и юридические вопросы, а не технологические.

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

iPhone does provide the "KeyChain" API,, который может помочь приложению скрыть секреты от владельца устройства, к лучшему или к худшему. Но все что угодно.

Answer 2

Предлагаю добавить контрольную сумму (md5/sha1) на основе отправленных данных и секретного ключа, который знает ваше приложение и сервер.

Answer 3

Как я понимаю, да, ключ может быть извлечен из приложения так или иначе. Из-за самой его природы почти невозможно скрыть что-то в среде Objective-C. Насколько мне известно, только Omni справлялись с их серийными номерами, по-видимому, сохраняя критический код в C (Cocoa Insecurity).

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

Answer 4

Приложения могут быть разобраны, чтобы они могли найти ваш ключ.

Answer 5

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

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

Можно добавить к своей схеме клиентские сертификаты для SSL.Можно похоронить этот сертификат и ключ для токена глубоко в каком-то обфускационном коде. Вероятно, можно создать схему с использованием криптографии с открытым/закрытым ключом, чтобы еще больше затмить токен. Можно было бы реализовать протокол «запрос/ответ», в котором время отклика по времени, в течение которого сервер сталкивается с проблемой приложения, и приложение имеет X миллисекунд для ответа до его отключения.

Количество и сложность всех препятствий зависят от стоимости актива.

Джек

Answer 6

Вы должны смотреть в Entrust Technologies (www.entrust.com) линейки продуктов для двухфакторной аутентификации, привязанной к разному роду особенности (например, устройство, IMEI, серийный номер приложения, идентификатор пользователя, и т. д.)