Авторизация устройств

Всем привет,

Есть у меня своя поделка устройств, которые обмениваются с центральным ХАБом командами и данными по радиоканалу. Заморочился я зашифровать протокол обмена, чтоб данные не светились в эфире. Прикрутил алгоритм AES (либа от ST), все хорошо, теперь хочу еще усилить, дело в том, что у меня есть исполнительные устройства, например выключатель, которому посылается команда, так вот одинаковые данные зашифрованные AES тоже будут одинаковые что не составляет труда перехватить радио посылку и отправлять ту же самую команду но зашифрованную и устройство её примет и обработает. Какие мне видятся способы защиты:
<ul>- самое простое - посылать дополнительный случайный байт (два, три), который будет являться "шумом", тогда кодированные данные всегда будут разные, но все равно повторив одну такую посылку устройство её примет.
- посылать счетчик команд и не принимать команды, если этот счетчик не увеличивается или меньше чем ожидается, уже лучше, но нужно помнить последнюю команду и как-то синхронизироваться с хабом.
- использовать токен и сеансы (сессии) - при включении устройства оно посылает на ХАБ запрос, хаб генерит токен и отсылает его устройству, далее идет обмен данными, "подписаными" этим токеном (например CRC32). Токен протухает на ХАБе раз в N времени и нужно его заново генерить. Все это естественно еще шифруется AES. Вроде не сильно сложно. Но опять же - в пределах одного токена посылка для одной команды будет одинаковая.
- ваш вариант?</ul>

0

Сообщение от pytrpts Зато любой сможет помочь соседу со своего смартофона, послав команду "Вырубить перфоратор у долбодебила в кв. 666".

А думаешь я зачем стараюсь? У меня именно такой сосед. Подарю ему вумный перфоратор ))

0

otixsom
Что-то по поводу памяти сомнительно. Не атмапированы ли эти области на нормальный ram?
А по сабжу можно заморочиться с ассиметричным шифрованием токена доступа, а токены доступа сменять каждый раз по установленному алгоритму с опять же случайным зерном.... Чтоб совсем все было чики-пуки :).

0

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

0

Сообщение от Myrmyk Вообще, алгоритм шифрования надо сто=роить таким образом, чтоб пакет нельзя было прочитать за разумное время даже при наличии всех исходных кодов и алгоритмов.

Я придерживаюсь другого постулата: Если пакет можно штатно прочитать за разумное время при наличии всех исходных кодов и алгоритмов, то тоже самое можно сделать нештатно с тем же результатом...
главное надо знать как читать

https://www.cyberforum.ru/savedimages/2016/12/26/nbwwxehdg7ednjqb.jpg

0

Сообщение от Myrmyk otixsom Что-то по поводу памяти сомнительно. Не атмапированы ли эти области на нормальный ram?

Что именно сомнительно?
Использую МК STM32F030F4 почти самый куцый из всех:
http://www.st.com/en/microsont... 030f4.html
У него 16КБ по литературе. Хотя реально там конечно намного больше, но производитель не рекомендует. Как говориться - во избежании.

0

Сообщение от Myrmyk Вообще, алгоритм шифрования надо сто=роить таким образом, чтоб пакет нельзя было прочитать за разумное время даже при наличии всех исходных кодов и алгоритмов.

Поддерживаю. Алгоритмы с открытым ключом именно так и строятся. Проблема расшифровки меняется от "невозможно расшифровать без ключа, потому что надо перебрать 10^40 вариантов" к "ключ и алгоритм есть, расшифровка элементарна, но из 10^20 полученных вариантов совпадает с исходным всего один".

0

Сообщение от yiv91 "ключ и алгоритм есть, расшифровка элементарна, но из 10^20 полученных вариантов совпадает с исходным всего один".

хм, а можно пример?

0

Ymk
Видимо yiv91 имел ввиду, что не только злоумышленник будет расшифровывать за 10^20, а и устройство, которому адресован пакет :)

Т.е. с технической точки зрения это будет выглядеть так: хеш_функция(команда + соль), в качестве хеш функции можно взять например SHA1, соль генерируется случайно при каждой посылке. Таким образом злоумышленнику и целевому устройству понадобится перебрать все соли для каждой команды.

0

Разумеется нет :)... В википедии есть довольно понятная статья "Криптосистема с открытым ключем". Там написано, как это работает.

0

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

0

а все равно не понимаю "из 10^20 полученных вариантов совпадает с исходным всего один", при том, что ключ известен.
и соль - информация открытая, никто их не подбирает. иначе это не соль, а что-то еще.

0

Сообщение от yiv91 Сообщение от Myrmyk Вообще, алгоритм шифрования надо сто=роить таким образом, чтоб пакет нельзя было прочитать за разумное время даже при наличии всех исходных кодов и алгоритмов.

Поддерживаю. Алгоритмы с открытым ключом именно так и строятся. Проблема расшифровки меняется от "невозможно расшифровать без ключа, потому что надо перебрать 10^40 вариантов" к "ключ и алгоритм есть, расшифровка элементарна, но из 10^20 полученных вариантов совпадает с исходным всего один".И чего ? Автосигнализации стойкие ?
В теории всё гладко, а вот на практике ломают навороченные протоколы в реальном времени за секунды :)

Я как то в защите одной программы разбирался... криптование, ксоренье, сдвиги расксоренного.
Понял как формируется открытый ключ, отскорил, сдвинул, убрал мусор.
Какого же было удивление когда в одном месте перед всем этим заметил проверку одного байта ... и если байт имеет значение *, то просто жумп на исполнение команды мимо всех проверок ... писавший облегчил себе отладку :)

0

Ymk
Вы не одиноки в непонимании, я тоже смысл его фразы не понял.

friiom
Покажите мне, как ломают за секунды HTTPS или Wi-Fi (кроме WEP и WPS).

0

Нет, я не отвечу на вопросы, не моя специализация. Я написал, как понял систему PGP лет 15 назад. Разумеется, для дешифровки нужны оба ключа. Насколько я понимаю, алгоритм работает быстро только в одну сторону, поскольку мощность множества при этом уменьшается, а в обратную - увеличивается. Поэтому дешифрация пакета происходит быстро, а взлом требует несоизмеримого количества операций. Однако в следующую версию PGP уже был встроен механизм быстрого взлома, и я перестал им пользоваться. Пользуюсь только самостоятельно изготовленным ключом, который передаю адресату на физическом носителе.

0

Сообщение от Kitvym friiom Покажите мне, как ломают за секунды HTTPS или Wi-Fi (кроме WEP и WPS).

Попробуй самостоятельно взломать поисковую строку Яндекса

Взлом HTTPS. Этот процесс считался крайне надежным до недавнего времени, когда была проведена атака...

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

https://www.cyberforum.ru/savedimages/2016/12/27/bpndhacgrzbsvuff6ga.jpg
а кто то до сих пор думает рекламными лозунгами

0

Сообщение от friiom было доказано, что можно получить одинаковые "хэши" для разных файлов

Ну как бы это общеизвестный факт и называется коллизией хэш функции.

0

Сообщение от Kitvym Сообщение от friiom было доказано, что можно получить одинаковые "хэши" для разных файлов

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

https://www.cyberforum.ru/savedimages/2016/12/27/jpxffrspxwzcblhzbe5jqchc.jpg

0

Сообщение от yiv91 Насколько я понимаю, алгоритм работает быстро только в одну сторону, поскольку мощность множества при этом уменьшается, а в обратную - увеличивается.

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

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

а как ключ самостоятельно готовился?:) с помощью листочка и ручки? или какой-то таки чужой программой? в последнем случае есть вероятность бэкдора в ключе;)

Сообщение от friiom Лет 13 назад.... по нынешним меркам уже давно ... было доказано, что можно получить одинаковые "хэши" для разных файлов

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

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

0

Сообщение от Ymk а как ключ самостоятельно готовился?:)

Я включил ФМ-радио на свободной частоте и записал несколько минут шума. Нормализовал и записал в 8-битном формате. Затем прошелся по нему 24-битным скремблером. Получилось несколько десятков мегабайт ключа. Для передачи сообщения используется каждый раз новый участок ключа.

0

Господа, что-то мы ушли от темы, давайте ближе к реальности связанной с МК.
Еще раз напомню - шифрование данных AES. Ключи для каждого девайса свои. Т.е. сам хаб при подключении внешнего дейвайса генерит для него ключ, отдает ему и запоминает у себя. В асинхронном алгоритме не вижу смысла.
Нужно защитится от повторных отправок, т.н. "replay attack".

0