Безопасность: Насколько уязвима эта схема аутентификации / шифрования?

Во-первых, я бы не стал использовать RC4. Существуют как более быстрые, так и более безопасные потоковые шифры, поэтому, если вы контролируете и клиент, и сервер, вы, вероятно, сможете добиться большего, чем RC4. Отброса только 512 байтов может быть недостаточно для атаки Флурера, Мантина и Шамира, но даже если вы отбросите больше байтов, есть еще атака Кляйна и т. Д. Я не знаю, стоит ли это того.

Во-вторых, убедитесь, что генерируемые вами ключи случайны. Я знаю, что это кажется очевидным, но для примера см .: http://www.debian.org/security/2008/dsa-1571

Но настоящая проблема заключается в следующем: «Игровой сервер на 100% доверяет расшифрованной им информации о пользователе. Это делает серверы полностью разъединенными, что хорошо, но если ключ будет скомпрометирован, пользователи могут полностью подделать свою информацию о пользователе».

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

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

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

Никогда не следует доверять клиенту. Вы должны хранить данные клиента на стороне сервера и сопоставлять их с ключом или подписывать данные и проверять их, или использовать HMAC и т. Д., Потому что, если игровой сервер на 100% доверяет информации пользователя, тогда у вас возникнут проблемы раньше или позже. Обойти это практически невозможно.

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

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

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

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

В итоге я также разместил сообщение на sci.crypt и постараюсь обобщить предлагаемые изменения (насколько я их понимаю) ниже, если это может быть интересно.

Шаг 1. Клиент отправляет HTTPS-запрос на сервер входа с учетными данными

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

Шаг 3. Информация о пользователе + сеанс RC4 + временная метка + дайджест

Используйте алгоритм шифрования, обеспечивающий целостность, вместо явного использования дайджеста. Например. AES-GCM или AES-CCM. Добавьте дополнительное поле идентификатора на шаге 1. Также добавьте ip к игровому серверу.

Шаг 4. Упакованные данные + ключ шифрования сеанса RC4 + IP-адрес игровому серверу отправляются в качестве ответа.

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

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

Добавьте к полезной нагрузке самоназначенный идентификатор на шаге 1 в незашифрованном виде.

Шаг 6: игровой сервер распаковывает данные, упакованные в (3). Теперь он знает пользователя и ключ шифрования RC4, который предполагается использовать.

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

Шаг 8. Если все проходит нормально, сервер отправляет незашифрованный LOGIN_OK, и начинается зашифрованный обмен данными RC4.

На этом этапе игровой сервер не может быть уверен в личности клиента. Используйте ключ сеанса и зашифруйте одноразовый номер + строго увеличивающийся идентификатор сеанса + состояние успешного входа в систему с помощью AES-GCM / CCM и отправьте его клиенту.

Клиент расшифровывает и проверяет состояние успешного входа в систему. Если это правда, то клиент знает, что игровой сервер знает ключ сеанса (GCM / CCM проверяет, что пакет не был подделан). Клиент возвращает sid + nonce.

Сервер проверяет, что sid + nonce совпадают с отправленными значениями.

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

Что касается RC4

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

Просто используйте SSL для игрового сервера. Современный криптоанализ привел к нескольким очень быстрым реализациям некоторых из лучших алгоритмов шифрования. Например, хорошо оптимизированные реализации AES могут легко зашифровать со скоростью лучше 150 МБ / с на любой удаленной современной машине. Кроме того, хотя AES пользуется большим уважением, у него есть два недостатка, о которых я знаю, но при правильном использовании эти недостатки становятся несущественными.

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