Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Как защитить пакеты от изменения? какие чексуммы нужны? (3 стр)

Как защитить пакеты от изменения? какие чексуммы нужны? (3 стр)

Страницы: 1 2 3
gamedeveloper01Постоялецwww1 фев. 20186:18#30
Интересный момент, вот тут например: https://gist.github.com/atoponce/07d8d4c833873be2f68c34f9afc5a78a

Советуют для разных вещей использовать в основном libsodium, но когда дело доходит до Client - server applications, то пишут только TLS. Только совсем непонятно, пишут лучше не использовать TLS с дефолтной конфигурацией, не совсем понятно что это, в частности для .NET framework SslStream.

Я хочу разобраться с TLS самоподписанными сертификатами, как аутентифицировать клиента используя такие сертификаты, чтобы сервер при этом не мог себя подделать? Я например знаю что можно использовать так называемые клиентские сертификаты, но пока не знаю что это и как они работают и как их нужно юзать. Есть только догадки: в сервер и клиент вшивают 2 парных сертификата - у сервера сертификат с приватным ключем, у клиента с публичным (по типу RSA). Не уверен что это так работает.

Параллельно хочу разобраться как в libsodium делать авторизацию с аутентификацией и последующим криптованием (как на основе libsodium сделать замену TLS с самоподписанными ключами). А то я сейчас только знаю про chacha20 + poly1305, но это лишь замена AES + HMAC, а что юзать вместо RSA-DHE например, и чтобы еще передать на сервер свой Token для авторизации?

-——————————-

PS: немного точнее напишу мой первоначальный вариант, а то как я понял там большая разница между stream cipher и block cipher, я собирался юзать именно block cipher AES-CBC, насколько я понял это самый адекватный вариант, который предлагает .NET framework, GCM там нету, как и CTR, итак:

1) RSA-OAEP + DHE + AES-CBC(packet, CRC32(packet))
2) ECDSA + ECDHE + AES-CBC(packet, CRC32(packet))

Это как бы мои первоначальные варианты, насколько я понял для блочных кефиров не особо необходим HMAC, так как для CBC насколько я понял следующие блоки будут итак испорчены, если изменить хоть один. Может для server-to-server такой CRC без HMAC не подойдёт, а вот gameclient-to-lobbyserver думаю может быть более чем достаточно?

Мои догадки по поводу чата внутри AES, если в соединении нужно передавать чат, так сказать по закону, то надо иметь возможность хранить детерминированные ключи на сервере, то есть нужно использовать DH, вместо DHE, если я всё правильно про них понял:

1) RSA-OAEP + DH + AES-CBC(packet, CRC32(packet))
2) ECDSA + ECDH + AES-CBC(packet, CRC32(packet))
или вообще без DH:
1) RSA-OAEP(token, AESKey) + AES-CBC(packet, CRC32(packet))
2) ECDSA(token, AESKey) + AES-CBC(packet, CRC32(packet))
Именно такой вариант я себе представляю, когда читаю вот это: https://docs.unity3d.com/ScriptReference/Network.InitializeSecurity.html

Правка: 1 фев. 2018 9:09

BiomanПостоялецwww7 июня 201822:27#31
gamedeveloper01
> Ну я сомневаюсь что например в EvE Online трафик никак не защищают, хотябы
> чтобы была небольшая гарантия что у тебя не сломают все предметы и не переведут
> все деньги на другой аккаунт. Тоже самое может быть и в других играх, например
> в доте 2 вещи в инвентаре можно уничтожать, вот представь у тебя удалят хук
> пуджа и все арканы - техподдержке тоже проблем таких не нужно.
И что в еве ломать? Все активные игроки давным давно используют двойную авторизацию,а ее ломать будут пару тысячелетий,если не больше. Без входа все равно ничего не передашь,да и кто в здравом уме такое проверять будет,один хрен все значимое считается только на сервере,а любые попытки лезть куда не надо могут легко и просто закончится флагом и последующим баном. Да и толку пакеты пытаться менять,сервер не настолько тупой,несоответствие всплывет сразу,а вот последствия от этого зависят от паранойи создателей. Можно и за такое бан словить. В реалиях же без физического доступа к аккаунту/кешу с учетки в случае со стимом никто еще ничего не ломал. Если уж за аккаунтом смотреть и данными не светить. Что же касается защиты чата - по большому счету нахрен не нужно,за ним никто следить не будет. Да и просто так в инете ты это дело не поймаешь,тут либо трояны,либо прокси,либо надо иметь доступ к площадке провайдера. В общем слишком много нюансов,из-за такой фигни заморачиться смысла нет. Защищать по сути стоит только при логине,вот там да,все шифровать. По сути во всех онлайн играх так и сделана. А чат - это дело десятое.
SagaCCGПользовательwww28 окт. 201816:04#32
Всегда можно изобрести велосипед, но спрашиваетша зачем?
Сегодня стандартом защиты является HTTPS (SSL).  Вряд ли, будучe не подкованым в этой области, вы сделаете что то более защищённое чем SSL.

Самое простое решение это получить обычный ключ семетричного шифрования через HTTPS, т.к. это предотвратит Man In The Middle, а дальше можно спокойно пользоваться обычным семетричным ключем.

gamedeveloper01Постоялецwww1 ноя. 201819:24#33
SagaCCG
На самом деле в онлайн играх никто не использует SSL, во всяком случае для ПК игр. А вот RSA + AES используют.
kiparУчастникwww1 ноя. 201822:44#34
SagaCCG
и как потом пользоваться симметричным ключом?
youtubeПостоялецwww2 ноя. 20186:32#35
gamedeveloper01
> На самом деле в онлайн играх никто не использует SSL, во всяком случае для ПК
> игр. А вот RSA + AES используют.
На самом деле SSL/TLS это и есть, с оговорками, RSA + AES.

kipar
> и как потом пользоваться симметричным ключом?
Симметричный ключ известен только серверу и клиенту. Берешь любой алгоритм симметричного шифрования, которому этот ключ подходит и, соответственно, шифруешь всё что надо.

kiparУчастникwww2 ноя. 20187:37#36
youtube
Шифруешь без чексумм, нонс и прочей защиты от подмены? Просто в #0 речь и идёт о шифровании симметричным ключом, странно слышать совет "не изобретать велосипед" и сразу после этого "пользоваться симметричным ключом".
youtubeПостоялецwww2 ноя. 201812:06#37
kipar
SagaCCG имеет в виду, что средствами ssl можно получить симметричный ключ и дальше его использовать. Это будет ну, скажем так, "более лучше", чем то что написано в #0, но так делать не надо. Надежнее всего использовать openssl. И да, не изобретать велосипед. Вот хороший (де)мотиватор: https://habr.com/post/181372/
kiparУчастникwww2 ноя. 201814:23#38
youtube
Чтобы его использовать кроме алгоритма шифрования нужен HMAC. О котором и спрашивалось в #0. И все равно это останется велосипедом - по https и так обмен данными идёт с помощью симметричного ключа.
----
собственно, по ссылке раз речь как раз о hmac и идёт. Так что совет "просто использовать https" - да, был бы с точки зрения "не изобретать велосипед" логичным (хотя и спорным с точки зрения накладных расходов), а совет "использовать https чтобы получить сеансовый ключ, а потом любой алгоритм шифрования" - совет построить велосипед.

Правка: 2 ноя. 2018 14:28

Страницы: 1 2 3

/ Форум / Программирование игр / Сеть

2001—2018 © GameDev.ru — Разработка игр