Программирование игр, создание игрового движка, 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 вещи в инвентаре можно уничтожать, вот представь у тебя удалят хук
> пуджа и все арканы - техподдержке тоже проблем таких не нужно.
И что в еве ломать? Все активные игроки давным давно используют двойную авторизацию,а ее ломать будут пару тысячелетий,если не больше. Без входа все равно ничего не передашь,да и кто в здравом уме такое проверять будет,один хрен все значимое считается только на сервере,а любые попытки лезть куда не надо могут легко и просто закончится флагом и последующим баном. Да и толку пакеты пытаться менять,сервер не настолько тупой,несоответствие всплывет сразу,а вот последствия от этого зависят от паранойи создателей. Можно и за такое бан словить. В реалиях же без физического доступа к аккаунту/кешу с учетки в случае со стимом никто еще ничего не ломал. Если уж за аккаунтом смотреть и данными не светить. Что же касается защиты чата - по большому счету нахрен не нужно,за ним никто следить не будет. Да и просто так в инете ты это дело не поймаешь,тут либо трояны,либо прокси,либо надо иметь доступ к площадке провайдера. В общем слишком много нюансов,из-за такой фигни заморачиться смысла нет. Защищать по сути стоит только при логине,вот там да,все шифровать. По сути во всех онлайн играх так и сделана. А чат - это дело десятое.
Страницы: 1 2 3

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

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