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

Помогите разобраться в сессиях (2 стр)

Страницы: 1 2
#15
13:12, 1 дек. 2016

iCpu
> Двупроходный ключ размазывает матожидание, так как у тебя появляется
> дополнительный шум от второго ключа. Грубо говоря, предыдущая система
> возводится в квадрат.
Можешь сказать что за двупроходный ключ? И по какому принципу получается ClientKey1 и ClientKey2?

В исходниках мы видим что ServerKey1 и ServerKey2 - это просто случайные числа.
Если ClientKey1 и ClientKey2 тоже просто сгенерировать случайно - алгоритм будет работать? Или он будет работать, но смысла тогда в 2х ключах не будет?

iCpu
> Все эти попытки защититься - говно
кстати, это не важно, я лишь хочу использовать то, что используют другие. Мне не нужна 100% защита, такой не бывает.

В Lineage 2 использовали обычное XOR шифрование, во всяком случае в самом начале, я мог бы так же.


#16
13:23, 1 дек. 2016

gamedeveloper01
Да, случайные, иначе смысла нет. Двупроходной - это полученный из двух порций данных. Это не термин, а моё косноязычие.

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

#17
13:28, 1 дек. 2016

iCpu
> Почитайте основы асимметричного шифрования
А есть инфа где почитать сразу о двупроходных ключах?

Всё что я знаю про ассиметричное шифрование это RSA, и еще Diffie - Hellman.

А о виде с двупроходными ключами не слышал. Или это самодел?

#18
13:37, 1 дек. 2016

gamedeveloper01
Нет.
Самодел. Причём, не ахти какой. Скорее всего, симметричный. Не имею желания копать.

#19
13:41, 1 дек. 2016

iCpu
> Нет.
> Самодел. Причём, не ахти какой. Скорее всего, симметричный. Не имею желания
> копать.
И на том спасибо

#20
14:18, 1 дек. 2016

У меня появились кое какие догадки, почему в тере используют "упрощенный" обмен ключами. Скорее всего этот алгоритм они используют только для подключения к игровым серверам, то есть, не для авторизации на логин сервере разумеется. У них есть лаунчер для этого.

Вот например, я вообще собирался использовать подключение к игровому серверу следующим образом:
1) Получаю от логин сервера SessionId.
2) Посылаю на игровой сервер SessionId по открытому каналу (вместо обмена ServerKey1/2 и ClientKey1/2).
3) Использую SessionKey, переданный через логин сервер.

В тере вероятно подключение к игровому серверу происходит без предварительного SessionKey.
Вместо этого, они получают 2 ключа - EncryptKey и DecryptKey (из комбинации C1/2 + S1/2 keys), что вроде как намекает на то, что алгоритм асимметричный, причем асимметричный и двухсторонний, а не односторонний как RSA.

Чуть позже продолжу мысль.

#21
14:50, 1 дек. 2016

Получается, что если сервер способен генерировать свои ключи EncryptKey и DecryptKey, используя только C1/C2 + S1/S2 keys, которые публичные. То и клиент должен уметь тоже самое. То есть, инициализировать ClientEncriptKey и ClientDecryptKey можно, точно также имея только  C1/C2 + S1/S2 keys.

Вопрос только в том, как мне изменить функцию Session->Init или как мне поменять местами в ней ключи так, чтобы получить ClientEncryptKey и ClientDecryptKey.

Но я толком даже не понимаю что происходит в функции Session->Init, не говоря уже о том, чтобы изменить её. Но уже во всяком случае я в общих чертах понимаю что происходит:

В тере используется некий "простой", самодельный асимметричный алгоритм, смесь XOR и чего то там еще, в котором используются составные ключи со сдвигом (аля Цезарь).

Но все эти рассуждения портит одна мааааааленькая деталь: если ключи S1/S2 + C1/C2 известны MITM, а они ему известны, ведь они передаются открыто, тогда он может создать ServerEncrypKey/ServerDecryptKey, а также ClientEncryptKey/ClientDecryptKey и расшифровать оба направления. Поэтому в этом алгоритме просто обязан быть какой то секретный ингредиент, хотя бы у Клиента. Отсюда по всей видимости и 2 стадии обмена ключами, то есть, по всей логике ClientKey2 обязан использовать ServerKey1 в своём составе, то есть это не просто случайный ключ. Даже не смотря на то, что ServerKey2 - не использует в своём составе ClientKey1 (а возможно оригинальный сервер это делает).

Не пойму чем, но мне это явно напоминает Diffie-Hellman.
Сначала мы передаем два общих ключа S1+C1.
Потом мы смешиваем эти ключи с секретным ингредиентом: S2 = C1 * SecretServerKey, C2 = S1 * SecretClientKey. (в тера эмуляторе используют просто S2 = random() не понятно почему)
Обмениваемся S2 и C2.

Только это какой то двойной Diffie-Hellman с составным общим ключем, каждая часть которого в последствии по отдельности используется для генерации EncryptKey/DecryptKey.

#22
15:52, 1 дек. 2016

В целом всё логично.

1) Им нет смысла использовать RSA, для того чтобы подтвердить официальность сервера. Тут подойдет Diffie Hellman, а официальность сервера подтвердится в сообщении с передачей SessonTicket, что кстати говоря скорее всего и делается, потому что теровском пакете Auth есть поле Session, который скорее всего не что иное как SessionTicket.

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

3) Почему бы просто не использовать Diffie-Hellman + симметричное шифрование?
По той же причине, что и пункт (2)

Например в Tibia вообще используется RSA даже для подключения к игровым серверам, а не только на логин сервере. То есть по сути лишняя работа.

Результат такой:
Я не смогу расшифровать то, что шифрует тера-эмулятор. Не зная секретного ингредиента, который только у клиента. То есть алгоритм в эмуляторе, работает только для сервера и без своей второй половины (не известно как генерируется ClientKey2) - бесполезен для общего пользования, но годится для сервер-эмулятора.

Что касается установки сессии, то тут 2 вида:
1) Установка первичной сессии, с авторизацией (логин сервер).
  a) HTTPS (скорее всего мой выбор)
  b) SSL
  c) RSA + XTEA/AES/XOR...
2) Установка вторичной сессии, без авторизации (игровой сервер).
  a) RSA + XTEA/AES/XOR...(SessionKey, login, password), используется в Tibia - по сути лишняя двойная авторизация.
  b) SessionId + XTEA/AES/XOR...(SessionTicket) (скорее всего мой выбор).
  c) Diffie-Hellman + XTEA/AES/XOR...(SessionTicket)
  d) Unknown(аля Цезарь + Хеллман) + Unknown(аля "асимметричный" XOR) (SessionTicket), Tera.

За сим тему можно считать решенной.

PS: помимо SessionTicket, игровой сервер еще будет проверять IP адрес клиента, чтобы он совпадал с IP адресом, который использовался на логин сервере. Если не использовать сессию, то хотя бы это должно быть в любом случае, этого может даже хватить для самой простой защиты.

PS2: сессия не защитит от продвинутых взломщиков, это и не требуется для игр, достаточно отсеить 97% школьников на проводе. Для них обычный XOR, вместо чистого текста, это непреодолимое препятствие и повод больше не снифить пакеты. Хотя сейчас такие школьники пошли... взломают сломают всё что угодно.

Страницы: 1 2
ПрограммированиеФорумСеть

Тема в архиве.