Шифрование данных. Обмен данных с Flash

[Aetbaev]

Автор оригинала: Gas
Aetbaev, передаваемые данные связаны с деньгами? on-line казино или ещё что-то?

Связанно с очками, на основе этих очков формируется сумма(денег) выигрыша.
On-line игра.

 

[Bermuda]

Flash-клиента можно декомпилировать? Можно. Если ключ хранится в нем, то получить его не проблема. Если ключ передается сервером клиенту, то тоже не проблема. Раз укрыть ключ нельзя, то и смысла кодировать/подписывать данные я не вижу.

Alexandre

публичный ключ сервера, которым открываются данные

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

-~{}~ 29.09.06 11:42:

Ссылочку на игру не забудьте запостить

 

[Wicked]

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

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

 

[Bermuda]

Автор оригинала: Wicked
в этом случае просто получается один из способов проверки того, что сообщение было зашифровано именно владельцем секретного ключа.

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

 

[Alexandre]

Публичным ключем данные не открываюся, а закрываются (кодируются).

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

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

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

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

буду думать

 

[corda]

Если речь о real-time игре, то никаких вариантов, способов или чего-то еще нет!
Можно только максимально усложнить процесс взлома. за деньги
рано или поздно кто-то накрутит себе очки и не пожалеет на это времени.
Надежда только на очень тщательное отслеживание данных, но от качественного взлома
и это не спасет.
Единственный вариант в вашем случае - Shockwave Director. На данный момент ни одного
известного декмопилятора для него нет.

 

[Alexandre]

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

 

[corda]

Автор оригинала: Alexandre
мы делали онлайн-игру - пазлы, приз -"стеклопакетное окно", так там, чтоб определить накрутчиков - каждый ход - логировался, по этому сразу видно - кто играл честно, а где играла машина.

Так и говорю только о real-time играх, а не о пошаговых.

 

[valyala]

Aetbaev, самый надежный способ защитить данные от искажения на стороне клиента (во flash'ке) - не хранить их на стороне клиента. После успешной авторизации создавай сессию для хранения защищаемых данных (про сессии читай тут: http://php.net/session). Клиенту будет известен только идентификатор сессии, но не сами данные (количество очков, денег на счету и т.п.), поэтому исказить эти данные у него не получится.

Если по каким-либо причинам сессии тебя не устраивают (например, жалко выделять место для хранения сессионных данных на стороне сервера), то можно сохранять данные на стороне клиента. Ниже приведены два возможных варианта:

1. Защищаемые данные хранятся на стороне клиента в зашифрованном виде. Ключ, с помощью которого зашифрованы данные, известен лишь серверу. Т.к. клиенту не известен этот ключ, то он не сможет их прочесть, а также корректно исказить. Для защиты от некорректного искажения данных используется котрольная сумма от исходных данных, которая хранится вместе с данными и проверяется каждый раз после расшифровки данных на стороне сервера.

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

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

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

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

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

p.s.
Прежде, чем использовать криптографию на практике, необходимо ясно представлять, где ее можно использовать, а где она совершенно не нужна. Ниже приведены очень полезные ссылки для тех, кто решил внедрять криптографию в свои продукты:
http://www.ssl.stu.neva.ru/psw/publications/crypto.html
http://www.osp.ru/text/302/179641/
http://offline.computerra.ru/1998/262/1518/
http://www.cryptopro.ru/cryptopro/documentation/hanaanbalz.htm

 

[corda]

valyala, а для для того, чтобы накрутить очки и не нужно ничего подменять.
Просто модифицуется flash таким образом, чтобы очки набирались "естественным"
образом: "бессмертие", "автоматичесикий прицел" или самый прикольный вариант -
"бот", который будет за тебя все делать. При этом часть кода, о которой ты говоришь
вообще не трогается.

 

[Bermuda]

valyala
Все никак не могу понять, кто мешает расколупать исходник и подменить данные ДО их подписи клиентом? Где-то же они берутся/хранятся?

 

[Gas]

самый надежный способ защитить данные от искажения на стороне клиента (во flash'ке) - не хранить их на стороне клиента

Это безусловно так, так-же как и не вылаживать проект в сеть чтоб его не взломали
Данные создаются самим клиентом/пользователем, это ж интерактивное приложение, где результат определяется активностью пользователя и можно только усложнить путь отправки заведомо выигрышных данных + логи состояния приложения для анализа при больших выигрышах (если логика приложение поддаётся прогнозу на основе промежуточных состояний).

 

[Alexandre]

valyalaты все правильно сказал, но у нас как раз так и вынло

а то как-бы не получилось я про одно, ты про другое...

но давай на этом не заморачиваться...

как вариант флешка может подписывать данные, таким образом сервер узнает - отправлены они флешкой или нет...

хотя, если паб-кей берется с сервера, то флеш формирует сессионный кей и им шифрует данные, и шифрует сессионный кей паб-кеем. Соответственно - данные -не перехватишь

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

а зная, вышеперечисленные составляющие - нам не предстоит труда - эмулировать флеш!
составить фальшивые данные
зашифровать их и отправить на сервер.

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

 

[Bermuda]

А еще ключ от квартиры где деньги лежат можно положить под коврик, а чтобы уж точно никто не нашел -- в почтовый ящик.