Позвольте мне попытаться разбить ваш вопрос на несколько подвопросов/предположений:

Предположения:

а) Связка ключей — безопасное место

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

Вопросы:

а) Есть ли способ поместить ключ в приложение (двоичный файл, который поставляется из AppStore) и обеспечить полную безопасность?

Краткий ответ НЕТ. Как только в вашем двоичном файле есть что-то, это может быть реконструировано.

b) Поможет ли обфускация?

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

Однако в большинстве случаев безопасность через неизвестность — плохая практика. Она дает вам ощущение, что вы в безопасности, но на самом деле это не так.

Таким образом, это может быть одной из мер безопасности, но вам также необходимо предусмотреть и другие меры безопасности.

c) Что мне делать в таком случае?*

Трудно дать вам хорошее решение, не зная предыстории того, что вы пытаетесь сделать.

Например, почему у всех должен быть доступ к одному и тому же Amazon S3? Им нужно только чтение или запись (как указал Кендалл Хелмстеттер Гейн).

Я считаю, что одним из самых безопасных сценариев будет что-то вроде этого:

• Ваше приложение должно быть защищено паролем
• Когда вы впервые входите в свое приложение, оно запрашивает у пользователя аутентификацию (введите свое имя пользователя, пароль) на сервере.
• Это аутентифицирует ваш сервер или другого поставщика аутентификации (например, Google).
• Сервер отправляет на устройство некоторый токен аутентификации (часто это файл cookie).
• Вы шифруете этот токен на основе хэша кода доступа вашего приложения и сохраняете его в цепочке для ключей в этой форме.
• And now you can do one of two things:
  • hand over specific keys from the server to the client (so each client will have their own keys) and encrypt them with the hash of your application passcode
  • обрабатывать все операции с S3 на сервере (и требовать от клиента отправки)

Таким образом, вы защититесь от множества возможных атак.

c) Уууу.... Я не планирую реализовывать все то, что вы только что написали, потому что это займет у меня месяцы. Есть ли что-нибудь проще?

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

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

P.S. И Кендалл, и Роб правы.

Обновление 1 (на основе новой информации)

Прежде всего, видели ли вы в руководстве по программированию покупки приложения.

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

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

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

Это не остановит продвинутого хакера, но, по крайней мере, защитит от любого, кто использует iExplorer и просто копирует файлы (поскольку они будут зашифрованы).

Обновление 2

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

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

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

ЕДИНСТВЕННЫЙ способ, которым приложение может записывать контент в S3 с какой-либо степенью безопасности, — это пройти через сервер, которым вы управляете.

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

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

Редактировать:

Основываясь на новой информации, вам, вероятно, лучше просто встроить секреты в код. Используя такой инструмент, как iExplorer, случайный пользователь может легко получить доступ к основной базе данных данных или чему-либо еще в комплекте вашего приложения, но объектные файлы несколько зашифрованы. Если у них есть взломанное устройство, они могут легко получить незашифрованные версии, но по-прежнему может быть трудно найти значимые строки, возможно, сохранить их в двух частях и повторно собрать в коде.

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

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

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

Это не пустая трата времени, чтобы немного запутать. Это нормально. Но не тратьте на это много времени. Если он есть в программе и очень ценен, то он будет взломан. Сосредоточьтесь на том, как обнаружить, когда это произойдет, и как восстановиться, когда это произойдет. И, насколько это возможно, переместите такие конфиденциальные данные на какой-нибудь другой сервер, который вы контролируете.