Подтвержденный канал на сервер из приложения на iPhone

Question

Я работаю над игрой для iPhone и хотел бы, чтобы она могла отправлять результаты на сервер. Достаточно просто, но я хочу, чтобы результаты проверок были получены из игрового процесса. С (де-факто) запретом на настоящую криптографию с условиями экспорта, что было бы лучшим способом вернуть информацию по безопасному / проверенному каналу?

Все мои мысли возвращаются к алгоритму цифровой подписи в стиле RSA, но я предпочел бы что-то менее "крипто", чтобы обойти этот вопрос об экспорте.

Спасибо!

Answer 1

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

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

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

Answer 2

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

Возможно, вы захотите взглянуть на EAR 742.15 (b) 3 , который охватывает исключения для цифровой подписи.

Конечно, я не юрист, и правила могли измениться за последний год.

Answer 3

Не могли бы вы просто использовать клиентский сертификат (подписанный вами) и установить HTTPS-соединение с вашим сервером, который был настроен на прием только тех соединений, которые начались с клиентского сертификата, подписанного вами?

Answer 4

Одна идея, которая может быть достаточно хорошей:

• Пусть Secret1, Secret2, Secret3 будут произвольными строками.
• Пусть DeviceID будет уникальным идентификатором устройства iPhone.
• Пусть Hash (Foo + Bar) означает, что я объединяю Foo и Bar, а затем вычисляю хеш.

Тогда:

1. При первом обращении к серверу приложение запрашивает пароль DevicePassword. iPhone отправляет: DeviceID, Hash (DeviceID + Secret1)

2. Сервер использует Secret1 для проверки, что запрос поступил из приложения. Если это так, он генерирует DevicePassword и сохраняет связь между DeviceID и DevicePassword на сервере.

3. Сервер отвечает: DevicePassword, Hash (DevicePassword + Secret2)

4. Приложение использует Secret2 для проверки того, что пароль пришел с сервера. Если это так, это сохраняет его.

5. Чтобы отправить счет, iPhone отправляет: DeviceID, Score, Hash (Score + DevicePassword + Secret3)

6. Сервер проверяет, используя Secret3 и DevicePassword.

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

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

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

Answer 5

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

Запоздалая мысль: если вы хотите усложнить обращение к engenier, умножьте свое случайное число на числовое представление дня (понедельник = 1, вторник = 2, ...)