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

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

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

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

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

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

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

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

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

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

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

• Пусть 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 или просто ограничить его одним разом в день.

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