Размышления о шифровании и безопасной передаче данных

[Alex 4 683]

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

 

Я считаю, это вопрос №1 при использовании сети Реднет вообще и покрытия CraftNet в частности. Для тех, кто не в курсе, скажу, что можно перехватить любое сообщение Реднет, а также отправить ложное сообщение получателю, представившись любым отправителем, и идентифицировать подмену можно только по уникальному актуальному пакету, привязанному ко времени, но для этого сообщение нужно зашифровать.

 

Какие варианты у нас есть?

 

1. Нужно разобраться с блоком Cryptographic Accelerator. Только он не крафтится чего-то(не жарятся каменные компы для получения чипов), хотя в конфиге крафт разрешил.

 

Вот официальный источник:

http://www.computercraft.info/forums2/index.php?/topic/3728-mc-164-cc-158-immibiss-peripherals/

 

Пример программы:

http://pastebin.com/kztKdG9U

 

Но его использовать для черепах нельзя.

 

 

 

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

Кто не видел, посмотрите алгоритм Диффи-Хеллмана

 

3. Может как то использовать возможность сети интернет и по нему передать ключи. Но как сказать компьютерам и роботам, что по такому-то адресу лежит ключ. Адрес то можно тоже перехватить. Или сразу создать и удалить (перезатереть) файл на пастебине, например. Пока не соображу, как это сделать.

 

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

 

Возле терминала стоит Biometric Lock. Клиент по отпечатку пальца инициализирует процедуру аутентификации, терминал получает ник игрока. Далее терминал просит придумать пароль для регистрации. Пароль хешируется и отправляется на сервер вместе с ником. Если такого игрока нет в базе, создается аккаунт на данного клиента. Аккаунт создан.

 

Далее выбираем войти в аккаунт, проверяем отпечаток пальца, вводим свой пароль и терминал отправляет на сервер ник и хеш. Если хеши совпали, сервер генерирует случайный ключ шифрования для данной сессии и через командный блок шлет его игроку на мыло в игровом чате. Например так (/mail send AlexCC trtYhhGDFf) Далее игрок вводит полученный ключ и начинается сессия по обмену информацией в зашифрованном виде симметричным ключом.

 

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

 

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

[Alex Автор темы 4 683]

А ведь использовать карту как в обычном банкомате проще?или нет?

Нет! RFID карта просто хранит до 80 символов. Для чего это нужно, пока не понятно. Подойдет для хранения какой-то личной информации и ее считывания и идентификации. Карту можно перезаписывать. Не понятно, как ее выдавать игрокам. Так же ее легко потерять в бою с ким-то крипером. И толку от нее, как от зонтика для рыбки. Она же не шифрует Реднет сообщения

 

А у нас тема просвещена шифрованию и обмену информацией по открытому каналу связи.

[Zer0Galaxy 2 187]

Если речь идет только о работе банковской системы, то может нет необходимости шифровать сообщения? Ну узнает Ева, что Алиса купила два алмаза. И что? Тут важнее идентификация абонента, что бы никто не покупал алмазики за чужой счет.

Предлагаю рассмотреть следующий вариант. Предположим, пользователь User имеет пароль Password и хочет передать сообщение Message на сервер. Клиентская программа формирует строку Message+H(Message+User+Password), которая и передается по незащищенному каналу. Где H() - хеш-функция. Обратите внимание, сообщение передается незашифрованным, но сопровождается подписью, подделать которую невозможно не зная пароля.

[Zer0Galaxy 2 187]

А по поводу первого поста.

1. Нужно разобраться с блоком Cryptographic Accelerator.

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

2. Придумать свой алгоритм шифрования

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

3. Может как то использовать возможность сети интернет и по нему передать ключи.

Лично я противник всего, что выходит за игровой сервер. Исключение делаю только для pastebinа и то не всегда

[NEO 541]

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

[Zer0Galaxy 2 187]

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

Не совсем понятно. Поясни на примере, пожалуйста.

[Alex Автор темы 4 683]

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

Но ведь Message+H я могу перехватить и отправить от имени отправителя, то есть на его радиочастоте адресату что-то типа MyMessage+H, при этом мне пароль то и не нужен?

[Totoro 3 563]

Но выходит, что H(Message+User+Password) != H(MyMessage+User+Password), следовательно, полученное сообщение было подделано.

[Zer0Galaxy 2 187]

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

Но я не об этом. Я о том, что если работать не в направлении шифрования сообщений, а в направлении электронной подписи?

[NEO 541]

Не совсем понятно. Поясни на примере, пожалуйста.

когда ты будешь подключаться к роутеру нужно будет ввести логин пароль

[Zer0Galaxy 2 187]

когда ты будешь подключаться к роутеру нужно будет ввести логин пароль

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

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

[Zer0Galaxy 2 187]

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

[Alex Автор темы 4 683]

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

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

:DLike

 

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

Zer0Galaxy! Можно, подробнее, пожалуйста, какая версия, мод, сервер, что не так передается? И нет ли таблицы символов под рукой?

[Zer0Galaxy 2 187]

Пробую в эмуляторе CCEmu

[ATTACH]127[/ATTACH]

На скриншоте видно, что пытаюсь отправить символ с кодом 195, а принимаю - 239. Почему так, не знаю

На всякий случай реализовал алгоритм шифрования, у которого на выходе строка содержащая только шестнадцатеричные цифры. В результате зашифрованная строка вдвое длиннее незашифрованной

[Zer0Galaxy 2 187]

Предлагаю для тестирования свежеиспеченный алгоритм шифрования на основе сети Фейстеля

http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D1%8C_%D0%A4%D0%B5%D0%B9%D1%81%D1%82%D0%B5%D0%BB%D1%8F

http://pastebin.com/KC7uE6ZP

Работает это следующим образом:

Сначала создаем массив ключей key. Это обычная луа-таблица из 16-ти числовых элементов. Она используется для шифрования и дешифрования строк. У передающей и принимающей сторон она должна быть одинаковой, а взломщику известна быть не должна. Как она генерируется не важно, но я сделал функцию getkey(pwd) на входе которой произвольная строка. а на выходе - требуемая таблица.

И так, первое действие key=getkey('secret_password'). Его нужно выполнить и на передающей и на принимающей стороне. Если секретный пароль одинаков, то и таблица ключей сгенерируется одинаково.

Затем вызываем функцию crypt(str,key). Тут str - передаваемое сообщение, а key - таблица ключей. На выходе получим кучу букв и цифр, что и есть зашифрованное сообщение. Зашифрованное сообщение передаем получателю по незащищенному каналу.

Получатель вызывает функцию decrypt(str,key). Где str - зашифрованное сообщение, а key - догадываетесь что.

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

[Alex Автор темы 4 683]

Попробовал на сервисе запустить, ошибка [string "stdin"]:24: attempt to index global 'bit' (a nil value) при попытке вызова функции getkey

...

mstr = 'hello world'

mkey=getkey('qwerty')

print(crypt(mstr,mkey))

[Zer0Galaxy 2 187]

Сервис не поддерживает всех CraftOSовских библиотек. В данном случае ругается на библиотеку bit

[Alex Автор темы 4 683]

Дима, подскажи, как лучше и разумнее сделать отсечку добавочных символов в 64-битном последнем блоке на получателе?

 

 

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

То есть шифровать уже буду, например, строку: T=2345569051L=29M=hello world. Получатель расшифрует текст, выкинет нулевые знаки и начнет работать с исходной строкой. http://puu.sh/c5pb3/554dd8ceba.png

Или как еще можно сделать?

 

П.С. Ну и decrypt, видимо, придется запускать в безопасном режиме, так как крашится при попытке расшифровки абракадабры, а не реального шифротекста.

[Zer0Galaxy 2 187]

Отбросить нулевые символы можно при помощи заклинания

mess=mess:match("(%Z*)")

, где mess - принятое сообщение. Передавать длину сообщения при этом не нужно.

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

[Alex Автор темы 4 683]

Отбросить нулевые символы можно при помощи заклинания...

Отлично! Работает заклинание:)Like Ты Маг!