Как сервер может аутентифицировать приложение для iPhone (код, не пользователь)?
Скажем, у меня есть решение, включающее приложение для iPhone, которое генерирует некоторую информацию и затем отправляет ту информацию в веб-сервис для обработки. Важно, чтобы ТОЛЬКО запросил от экземпляров этого конкретного приложения для iPhone, позволяются быть обработанным (может быть много экземпляров приложения, используемого многими различными пользователями, но я хочу быть уверенным, что они все используют код, которому я доверяю). Другими словами, я хочу быть уверенным, что мое приложение для iPhone не может быть (легко) явлено олицетворением другими клиентами. Как Вы сделали бы это?
7 ответов
Все остальные ответы дают законные способы обеспечения некоторой дополнительной, но не идеальной безопасности. Вы должны заранее знать (поскольку никто другой не был столь явным), что невозможно обеспечить теоретически безопасную связь, чтобы ваш сервер всегда мог подтвердить, что клиент на другом конце является купленной копией ваше приложение работает на санкционированном оборудовании. Вы не можете этого сделать, потому что какой бы аппаратный уровень безопасности не был встроен Apple для запуска цепочки доверия (чтобы это действительно было возможно для них), они вам не открываются.
Таким образом, ваша стратегия должна быть одним из «многих барьеров», некоторые из которых больше, некоторые меньше, предназначенных для предотвращения атак различной степени сложности и изощренности злоумышленника. См. Другие ответы на этот вопрос для получения хороших идей. Сколько барьеров вам нужно и насколько сложны, полностью зависит от того, сколько вам (с экономической точки зрения, доверия и т. Д.) Будет стоить успешная атака.
Не забывайте также о том, что если вы можете избежать «воспроизводимой» атаки на систему безопасности, вам будет лучше. Другими словами, если кто-то нарушает ваше приложение / протокол, и данные для других людей одинаковы для каждой копии / экземпляра, тогда у вас больше проблем, потому что инструкции / ключи можно просто опубликовать в Интернете. где-то. Если вы сможете придумать способ сделать каждую копию / клиент уникальной, тогда вы сможете наблюдать на сервере и, в худшем случае, отключать известные сломанные клиенты и т. Д. (Это сложно на платформе iPhone).
{{1 }}Использовать идентификатор устройства ... Отправить идентификатор устройства с запросом ... каждый iphone будет иметь уникальный идентификатор устройства
Некоторое время назад я задавал аналогичный вопрос:
Ограничение доступа к серверу для приложения iPhone
В итоге я использовал случайно сгенерированное имя пользователя (GUID). Затем я беру имя пользователя, добавляю секрет (жестко запрограммированный в моем приложении, отраженный на сервере) и результат SHA1 и отправляю его в качестве пароля.
На сервере я беру заданное имя пользователя, добавляю тот же секрет, хэширую его и сравниваю с тем, что отправил клиент. Обратите внимание, что это должно быть отправлено через SSL, чтобы быть даже удаленно безопасным.
Другой подход - отправить сертификат клиента SSL вместе с комплектом приложений и настроить сервер так, чтобы он принимал соединения только от клиентов с этим сертификатом.
Слабость обоих из них заключается в том, что если ваше приложение взломано, извлечь секрет или сертификат клиента несложно.
Если вас беспокоит неоплачиваемое использование клиентами ресурсов вашего сервера, у вас совершенно другая проблема, потому что тогда ваша основная модель угрозы - это пиратские копии вашего приложения, работающие на взломанных телефонах. См. Ответы на мой вопрос о некоторых контрмерах.
Вы можете скрыть закрытый ключ в своем приложении, который используется для аутентификация запрос-ответ .
Если ответ слишком короткий / абстрактный, оставьте комментарий, и я объясню подробнее.
Изменить:
Я хотел бы добавить, что я не думаю, что существует безопасный (как в случае обратного проектирования) способ выполнить описанную аутентификацию. Но в вопросах безопасности я чаще всего ошибаюсь, чем никогда.
Любая исходящая коммуникация, созданная вашим приложением, может быть перехвачена и воспроизведена позже. Если вы хотите быть достаточно уверенным в том, что запрос исходит от вашего приложения, вы можете сделать что-то вроде встраивания открытых (не закрытых) ключей в ваше приложение и использовать их для подписи ваших сообщений. Однако в подобной ситуации закрытые и открытые ключи не делают ничего, кроме обеспечения безответности (т.е. доказывают, что только предполагаемый получатель может прочитать сообщение, поскольку только у него есть совпадающая половина пары ключей).
Что вы ищете, так это обеспечение подлинности. Вы можете сделать что-то вроде обмена ключами DH ( http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange ) для создания общего секрета (поскольку жесткое кодирование секрета в вашем приложении не гарантирует, что он будет секретным), а затем использовать этот секрет для выполнения определенных манипуляций с вашим сообщением (хотя это все еще не является идеальной аутентичностью).
Или вы можете сделать что-то вроде проверки подписи кода вашего приложения и убедиться, что это соответствующая подпись и что это ваше приложение, или что-то подобное.
Возможно, Грэм Ли появится и даст лучший ответ. :)
EDIT
(мысли вслух) Вот идея: Как только ваше приложение появится в магазине, вы можете извлечь подпись кода публикуемого приложения, поместить ее на свой сервер и использовать в вызове-ответе. Когда ваш клиент подключается к серверу, сервер может сгенерировать случайное значение и отправить его обратно. Клиент может манипулировать этим значением, используя встроенную подпись кода приложения, и возвращать обработанное значение. Тем временем ваш сервер может делать то же самое. Когда сервер получает манипулированное значение, он может сравнить его со своей версией и затем прервать/продолжить соединение в зависимости от того, совпадают ли они. Технически, это все еще может быть подделано (другое приложение может украсть подпись кода и использовать ее самостоятельно), но кажется, что это было бы более безопасно.
Другая возможность - запросить у приложения некоторую часть содержимого пакета приложения - что-то вроде байта 59967 исполняемого файла приложения, включенного списка или xib. Сохраняя как имя файла, так и позицию, запрошенные совершенно случайными, любой спуфинг должен встроить всю копию вашего приложения, что позволяет очень легко определить, подделывают ли они ваше приложение, и, возможно, очень легко найти в Google происшествия.
По сути, клиент просто должен дать вам номер версии, а на сервере у вас будут копии всех файлов для всех общедоступных версий, чтобы проверить ответы (и решить, какую задачу отправить).
Поскольку фактически предотвратить это невозможно, лучше всего сделать обнаружение спуфинга как можно более простым для сканирования, и поэтому я бы подумал о решениях, которые помогут вам в этом отношении, а не пытались заблокировать неблокируемые ( хотя какая-нибудь банальная начальная блокировка удержит шумиху).
По сути, для защиты чего-либо требуется больше слоев, чем один действительно жесткий.
При запуске приложения отправьте запрос токена на сервер. Затем попросите сервер отправить клиенту токен (только некоторую секретную вновь созданную строку) через APNS. Все последующие коммуникации аутентифицируются с помощью этого токена. Вы даже можете «надежно» сохранить токен, используя связку ключей на стороне iPhone. В пределе то, что вы хотите, действительно невозможно, но в этом случае вы немного больше полагаетесь на инструменты Apple.