Протокол передачи современных радиореле

[roman.com]

Разрабатываю разные устройства для умного дома.

Принцип работы всех современных радиореле известен:

https://www.youtube.com/watch?v=TxDPRZsX5O8
https://www.youtube.com/watch?v=hM6GCjp7LNk
https://www.youtube.com/watch?v=5vH-gEZQxkQ
https://www.youtube.com/watch?v=zK-EzSeakmA
...
И т.д.

Меня больше интересует протокол. И в первую очередь интересует как происходит обмен ключами AES128 ?
Кто знает ? Или дайте ссылку...

[Flasher]

Звучит как "Разрабатываю марсоходы. Но меня интересует как подключить моторчик к батарейке. "

[BlackKilkennyCat]

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

[mickbell]

Ага, и ключик для подключения нужен не AES128, а гаечный.

[roman.com]

Что, никто не знает ответ на простой вопрос ?
Мда... "мельчают" специалисты...
Эх...

[Garryadmin]

roman.com писал(а):

Что, никто не знает ответ на простой вопрос ?

Ну, так а вопрос-то в чем? Как прикошачить AES128? В тех видео, что вы привели, в радиоканале (433) AES128 нет и в помине, там простенький пакет через FSK или даже OOK передается. Вот в Wi-Fi канале может быть и есть, и то это от настроек зависит. И передается он в соответствие с протоколом используемого Wi-Fi режима, который реализуется в готовом модуле. Контроллер этих реле опять-таки не участвует в этом процессе, максимум подкидывает введенный пользователем ключ. Но делается это через интерфейс модуля Wi-Fi на подобие АТ-команд .

[roman.com]

в радиоканале (433) AES128 нет и в помине, там простенький пакет через FSK или даже OOK передается.

Ну с FSK или даже OOK понятно. А там действительно нет шифрования ? Странно...

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

С этого места по подробней... Кто и как подкидывает ключ ?

Все производители радиореле пишут что используют AES128, но никто не пишет подробности...

Однако, на разных сайтах всплывают некоторые подробности...

К примеру в радиореле от известного производителя Xiaomi была обнаружена уязвимость. Как пишут на одном сайте:
"Радиореле от Xiaomi (модель не уточняется) использует AES128, режим шифрования CBC. А вектор инициализации — случайное число, генерируемое случайным образом, поэтому радиореле от Xiaomi подвержена replay attack".
Чем немедленно и воспользовались - перехватили пакет и повторно воспроизвели. Таким образом перехватили управление радиореле от Xiaomi...
И там же:
"Протокол обмена используемый Xiaomi в их wi-fi устройствах основан на UDP протоколе. Сообщение — это один UDP пакет, в ответ на такой принимающая сторона должна отправить на ip/порт источника UDP пакет ответ. Если ответа нет — автоповтор".

Я сравниваю свои самодельные устройства с устройствами от разных производителей... Ищу уязвимости и т.д.

В своих самодельных устройствах я использую тот же принцип:
Сообщение - один UDP пакет. Далее по радиоканалу (FSK или OOK не важно) транслирую на радиореле.
А вектор инициализации — это обычный счётчик, поэтому все мои устройства защищены от replay attack.
А ключи генерирует генератор случайных чисел. Ключи передаю в том же пакете (вместе с данными).
Режим шифрования CTR или OFB. Они проще программно и позволяют генерировать гамму заранее... Что повышает скорость.
Ключи и вектор инициализации храню в ОЗУ МК. При отключении питания всё должно автоматом записываться в EEPROM МК.

Меня интересует как все эти вопросы решают разные производители. Как генерируют ключи и вектор инициализации... как передают ключи и вектор инициализации... где хранят ключи и вектор инициализации... и т.д.
Для повышения надёжности ключи рекомендуют периодически менять. Как это делают разные производители ? Если можно на конкретном примере какого-нибудь устройства...

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

А как вы решаете все эти вопросы на своих устройствах ?

[Ser60]

roman.com писал(а):

А как вы решаете все эти вопросы на своих устройствах ?

Я полагаюсь на меры безопасности, интегрированные в стеки протоколов, разработанных коллективами высоко-профессиональных специалистов по security и разработчиков ПО, в частности, протоколы Bluetooth LE и Bluetooth Mesh. Они основаны на многолетнем опыте и многочисленных научных исследованиях, никоем образом не покрываемых несколькими обзорными статьями в Википедии или подобных местах в сети. Несмотря на то, что даже они не обеспечивают 100%-й защиты от всех возможных атак, их реализация просто не сравнима по сложности с подходами отдельных радио-любителей. Я не специалист по разработке таких алгоритмов, но не сомневаюсь, что если можно было-бы достичь подобного уровня безопасности более простыми средствами, то так-бы и сделали.

Возможно, ответы на ряд Ваших вопросов выше содержатся в спецификации Bluetooth (Part H, начиная со стр. 1612). Касательно Bluetooth Mesh, основы безопасности её кратко освещены здесь. В коммерческих устройствах ширпотребных радиореле, скорее всего, сделали упрощённую защиту с уровнем достаточным с практической точки зрения для этого класса устройств. Упомянутые мной выше стеки протоколов обеспечивают гораздо лучшую защиту

[Morroc]

Ser60 писал(а):

Я полагаюсь на меры безопасности, интегрированные в стеки протоколов, разработанных коллективами высоко-профессиональных специалистов по security и разработчиков ПО, в частности, протоколы Bluetooth LE и Bluetooth Mesh. Они основаны на многолетнем опыте и многочисленных научных исследованиях, никоем образом не покрываемых несколькими обзорными статьями в Википедии или подобных местах в сети.

Не не не. Никаких "библиотек". Только сами. Все сами. Причем на asm ибо нефиг И пофиг что год писать и с дырками будет, все равно их никто не найдет

[roman.com]

Опять ты со своим asm...))
Ассемблер я использую только в исключительных случаях - когда нужно получить высокоточный сигнал на выходе МК, с кварцевой стабильностью и точностью до одного такта процессора. В остальных случаях я использую Си.
Не будет там никаких дыр))

ответы на ряд Ваших вопросов выше содержатся в спецификации Bluetooth

Спс)) Пошёл читать...


Добавлено after 1 hour 43 minutes 2 seconds:
replay attack Bluetooth LE и Bluetooth Mesh

Screenshot_1.jpg

(80.15 KiB) Скачиваний: 150

Ясно)) принцип тот же что у меня...
А вообще...

Screenshot_2.jpg

(41.04 KiB) Скачиваний: 140

Т.е. Bluetooth LE и Bluetooth Mesh пока ничего нового не изобрели...


Добавлено after 6 hours 7 minutes 48 seconds:
Читаем дальше... ))
Вот интересный пункт - защита от атаки "полного перебора" ключей...

Screenshot_1.jpg

(113.78 KiB) Скачиваний: 143

Нечто подобное и я использую в своих устройствах. Все мои устройства защищены от атаки "полного перебора"...
Есть хитрый счётчик ошибок. Если ввести неправильный ключ то мои устройства блокируются не определённое время... Какое именно - определить внешне невозможно - секрет протокола)). И чем больше вводишь неправильный ключ - тем "глубже" мои устройства уходят в "оборону". )) Поэтому "полный перебор" для моих устройств не страшен...))
В отличии от Wi-Fi, который взламывается простым перебором ключей (паролей)... ))

Далее... пишут про генерацию ключей...
-мастер ключ
-ключ инициализации
-ключ связи
-сеансовый ключ
...
И т.д.
По моему слишком дофига ключей в простом Bluetooth ))
Потом пишут про обмен ключами... Причём ключи привязаны к ID устройству...

Screenshot_2.jpg

(90.51 KiB) Скачиваний: 140

Подобное я уже делал... привязку ключа к ID устройству...

Режим шифрования.jpg

(111.36 KiB) Скачиваний: 144

При этом МК тормозит конкретно... но работает))

Добавлено after 15 minutes 6 seconds:
Потом они ещё добавили аутентификацию...

Screenshot_7.jpg

(75.58 KiB) Скачиваний: 136

У меня аутентификации нет, потому что у меня сквозное шифрование))

Вот они напихали всего... в простой Bluetooth ))

Добавлено after 15 minutes 23 seconds:
А в качестве генератора случайных чисел они используют генератор псевдослучайных чисел на сдвиговых регистрах с обратной связью...

Screenshot_6.jpg

(78.36 KiB) Скачиваний: 139

Плохая идея. Я использую шум квантовая АЦП МК )) Он работает медленней, но у него бесконечный цикл и лучше энтропия ))

Короче у Bluetooth куча каких то не нужных операций))
-ключ инициализации - для подключения новых устройств...
-ключ связи - для связи устройств...
-сеансовый ключ - для передачи пакетов...
-мастер ключ - для широковещательных рассылок и обмена сеансовыми ключами...
...
Короче напихали в Bluetooth всё что только можно))

В конце ещё добавили публичный ключ... для безопасного сопряжения... типа опция что ли))
Diffie Hellman key - в Bluetooth это уже перебор))
...
Короче... Не вдаваясь в мелкие подробности... В целом всё ясно))

Вывод:
Коллектив высоко-профессиональных специалистов по security и разработчиков ПО ничего принципиально нового не изобрели. Просто использовали готовые протоколы (которые уже много лет используются в сети Интернет) и оптимизировали эти протоколы для своего устройства - Bluetooth.

Для простого радиореле это не подходит. Слишком много всего "лишнего". Можно всё сделать проще... и даже надёжней)) Оптимизировать готовые протоколы для простого радиореле. ))

[aleksandr-zh]

А там действительно нет шифрования ? Странно.

да, нет.
По крайней мере, ширпотреб не имеет ничего. Говорю, кто эти "умные дома" делал лет 10 назад из китайского с Али...

[roman.com]

лет 10 назад это уже не современное реле))

Добавлено after 1 minute 39 seconds:

даже я, самоучка, ваяю такое

какое такое ? самодельный протокол ? поподробней...

[NStorm]

roman.com, ютуб, для описания технических ус-в - моветон. Кто захочет часы своего времени тратить на просмотр этого говна, чтобы дать вам ответ?
У вас по 2ой же ссылке из описания того, что реле на ESP8266, можно предположить, что там WiFi. У всяких простых радио управлялок на 433 МГц и правда нет никакой защиты. Они не для того рассчитаны. Но уже давным давно известно, как безопасно обмениваться ключами можно через протокол Диффи-Хеллмана: https://ru.wikipedia.org/wiki/%D0%9F%D1 ... 0%BD%D0%B0
Что и реализуется в TLS нынче, с поправкой на реализацию на эллпитических кривых. Если вы хотите свою безопасную реализацию по радио сделать - берите готовую TLS. Не выдумывайте с нуля. Нельзя. Криптография - не то место. Это целая отдельная наука, нельзя в неё сразу и долго очень.

[roman.com]

Видео на ютуб - это просто обзорное видео для понимания общего принципа работы и из каких деталей состоит современное радиореле. Для подробного разбора деталей - есть даташит.
Производители не пишут про алгоритмы своих протоколов. В этом вся проблема.

Протокол Диффи-Хеллмана в теории знаю На практике ещё не использовал.

Брать готовую TLS для радиореле - не лучшая идея.
-Во-первых это сложно...
-Во-вторых протокол Диффи-Хеллмана не защищен от атак "человек посередине". В интернете для этого используют сертификаты.
Вы предлагаете использовать сертификаты в простом радиореле ? )) По-моему это уже перебор...

Я не выдумываю свой протокол с нуля. Я адаптирую готовые протоколы к своим устройствам. Весь вопрос как это правильно сделать. Вот и всё))

[NStorm]

Так это анонимный DH. В чистом виде, без сертификатов. Вот он как раз таки и не защищен от mitm. А который с сертификатом слой - защищен. Конечно такой никто не применяет для обмена ключами (Key Exchange, KE).
Есть всякие схемы KE, основанные на DH, но при этом стойкие к MITM и позволяющие провести аутентификацию. Например, аутентификация на основе пароля (EKE, SRP, SPEKE): https://en.wikipedia.org/wiki/Password- ... _agreement
Но с тем же успехом можно и PSK (pre-shared key) просто сохранить сразу.
Имхо TLS как раз-таки отличное решение тут. Его реализаций для эмбеддеда полно, можно опять же не включать поддержку всех алгоритмов и протоколов.

Добавлено after 14 minutes 26 seconds:
А вот на интересную штуку наткнулся: https://ru.wikipedia.org/wiki/%D0%90%D0 ... 0%BA%D0%B0

И даже реализация на Си есть: https://github.com/cilliemalan/MicroRatchet https://github.com/louib/olm

Добавлено after 1 hour 29 seconds:
На самом деле, если вернуться к сабжу. Китайцы обычно штампуют 2 вида подобных девайсов - обычные радио на 433.92 МГц, коды у которых никак не шифруются. Я вон в соседней теме почти тоже самое разбираю протокол - обычный манчестер, код 22-23 бита и всё. Потому что всем похер. Кому надо релешку от вашего дома перехватывать. Это не автосигнализация, не охранка, не банковская операция и т.д.
Второй вариант - IoT девайсы. Т.е. с полноценной сетью. Как правило WiFi на базе ESP8266/ESP32. В большинстве своём они облачные, работают через сервера производителя в Интернете. Т.е. через домашний роутер подключаются к инету и весь обмен настройками и сообщениями идет через их сервер. В кач-ве управляющего модуля - обычно клиент под смартфон или веб-версия. По 2ой ссылке судя по всему именно такой вариант. Тут само собой именно полноценный TLS (HTTPS наверняка) используется просто. Просто потому что это просто и дешево. Просто потому, что в ESP для вафли и прочего всё-равно нужен TLS и оно его спокойно тянет, так почему бы и нет?
Ну и иногда (а чаще в довесок к облачному управлению) есть MQTT поверх того же WiFi. Но это обычно в комплексных решениях для умного дома, а не в одиночных "радио" релешках.

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

[roman.com]

Раньше использовал одноразовые блокноты... одна копия на SD карте, вторая на HDD компа... Но бегать с SD не удобно))
Сейчас использую симметричное блочное шифрование типа (pre-shared key). Обмен ключами в одном пакете вместе с данными.
На всякий случай есть кнопочка RESET как на роутере которая сбрасывает устройство и ключи к заводским настройкам.
Ассиметричные алгоритмы типа Диффи-Хеллмана пока не рассматриваю... Они сложные... и врятли влезут в AVR )) Хотя я не пробовал.))
-Полноценный TLS (HTTPS) не использую.
-"облако" не использую. Я им не доверяю)) И не хочу чтобы умный дом без интернета не работал.
-веб-морд не использую. Я им не доверяю)) Браузеры следят за мной (за моей активностью в интернете)... записывают куки... предлагают сохранить пароль... Ага)) я ещё в браузерах пароли не хранил)) А потом показывают мне рекламу которую я не заказывал))
И вообще HTTP и TCP не использую)) Раньше использовал HTTP и TCP. Теперь только UDP.
Мой сервак в инете с белым IP. Клиент под комп/смартфон со своим приложением на UDP.

А вот обмен ключиками - это интересно... Надо почитать...

[NStorm]

DH - не ассиметричный алгоритм, это алгоритм обмена ключами (KE). В AVR к сожалению да, мало что влезет. Сейчас всё-таки если нужно надежное шифрование - под это уже берутся 32/64-битники.
Но DH сам по себе не так много заберет ресурсов, даже в меги старшие должен поместиться. Вот пример реализации на эллиптических кривых: https://github.com/kokke/tiny-ECDH-c
Как видно на ARMе занимает 2.1 Кб и до сотник байт ОЗУ может вместиться.
Можно использовать его при паринге ус-в. Т.е. когда идет привязка передатчика к приемнику, чтобы разово сгенерировать новый ключ и обменяться им. В этом случае MITM атака возможна будет только при этом паринге. Это как альтернатива одноразовым блокнотам, автоматически.

Облкао/веб "не доверяю" - вы просто не понимаете их, поэтому и не доверяете. Ваш сервер в инете и есть "облако" по сути. А свои протоколы - велосипеды по сути. Когда можно использовать уже готовые решения... Ну и браузеры есть без отслеживания. И не надо конечно пароли в браузере хранить, все эти функции отключаются легко, а от рекламы есть блокировщики.

[aleksandr-zh]

roman.com писал(а):

какое такое ? самодельный протокол ? поподробней...

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

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