На днях в лабораторию Hi-Lab.ru поступили модули новой системы nooLite-F компании Ноотехника для тестирования и интеграции с Arduino Mega Server и я предлагаю вашему вниманию небольшое резюме по новой системе, своё мнение о ней и простые примеры кода Arduino для управления новыми устройствами.
Эта статья — одна из первых ласточек по этой системе и я думаю, что скоро вы увидите много других отчётов о ней, а пока самая горячая и актуальная информация из первых рук.
Что такое nooLite?
Для тех кто не знал или забыл, напомню, что nooLite это беспроводная система управления электрооборудованием, таким, как освещение в вашем доме или электроприборы, которые можно включать и выключать при помощи беспроводных пультов управления. Пульты имеют много вариантов исполнения, но в основном они выглядят как обычные выключатели освещения. Управляющие блоки, которые принимают команды, представляют собой небольшие коробочки с несколькими проводами, часть из которых подключается к питающему напряжению, а часть — к нагрузке.
Просто и понятно. Благодаря этой простоте система nooLite завоевала популярность и продаётся в большом количестве сетевых и оффлайновых магазинов. Но есть одно «но». Всем хороша система nooLite, но она имеет один (и даже два) существенных недостатка. Первый — это отсутствие серьёзного шифрования передаваемых команд и данных. Для большинства бытовых применений это не очень критично, но для многих людей это неприемлемо с точки зрения безопасности — существует хоть небольшая, но не нулевая вероятность того, что вам не повезёт и кто-то из хулиганских или криминальных соображений решит вскрыть ваше соединение и поуправлять вашим оборудованием.
Второй недостаток — это отсутствие в системе обратной связи (есть правда псевдо-обратная связь при помощи специальных блоков, но это не очень серьёзно). Что это значит? Это значит, что вы, отдав команду на включение чего-либо, не можете быть уверены, что эта команда реально выполнена, а не ушла бесследно в мировой эфир.
Вот как раз с этими двумя недостатками и призвана бороться новая версия системы под названием nooLite-F. Разговоры необходимости выпуска новой версии шли уже давно и вот наконец в продаже появились первые приборы новой серии.
Немного технических подробностей
С технической точки зрения система nooLite представляет собой приёмно-передающие устройства, работающие на частоте 433 МГц и использующие амплитудную модуляцию передаваемого сигнала. Выбор амплитудной модуляции обусловлен тем, что по мнению производителя системы, это простой и слабо восприимчивый к помехам способ передачи команд на небольшое расстояние. В системе используются PIC контроллеры (12, 16, 18). Энергопотребление устройств невелико и пульты и сенсоры системы работают на батарейках.
В новой системе nooLite-F частота работы осталась прежней, 433 МГц, и что ещё более важно — сохранилась совместимость со старой версией оборудования. То есть вы можете при помощи управляющих модулей nooLite-F работать с обычными приборами nooLite.
В новой системе модуляция сменилась на частотную, но, как это ни удивительно, это не мешает новым устройствам работать со старыми, использующими амплитудную модуляцию. Как это возможно? Инженерам компании, пришлось немного модифицировать трансивер новых модулей для работы одновременно с обоими типами модуляции.
Новые трансиверы имеют лучшую чувствительность и, как следствие, примерно на 30% большую дальность связи.
Безопасность и шифрование
В системе nooLite-F используется серьёзное шифрование по стандарту AES, что должно надёжно обезопасить работу и использование этого оборудования. В свою очередь работа с шифрованием потребовала повышения вычислительной мощности и заставило перейти на использование контроллеров PIC 32. Но это по прежнему энергоэффективное решение и блоки и модули системы могут длительное время работать от батареек.
Доступное оборудование
На данный момент для покупки доступны три устройства новой системы:
- Адаптер MTRF-64-USB для управления через USB интерфейс с компьютера
- Модуль MTRF-64 для управления при помощи контроллеров с UART интерфейсом
- Беспроводной силовой блок SLF-1-300
Мы будем проводить свои эксперименты с силовым блоком SLF-1-300 и модулем MTRF-64.
Всего три изделия это временное явление — в планах компании выпуск целой линейки оборудования системы nooLite-F, в том числе устройств на DIN-рейку.
Силовой блок SLF-1-300
Внешне силовые блоки новой системы ничем не отличаются от привычных блоков nooLite. Тот же аккуратный корпус и те же несколько проводов для подключения питания и нагрузки.
Несколько интересней выглядит содержимое блока. Слева на картинке видны две микросхемы — одна (поменьше) это микросхема трансивера, точная маркировка:
MRF49XA
1637
RG3
и вторая микросхема контроллера, управляющего блоком, точная маркировка
STI E4 7B572
32F030F4P6
PHL 648 A
Всё очень компактно и аккуратно. Это и есть долгожданный nooLite с шифрованием и обратной связью.
Обратная сторона платы практически полностью закрыта радиатором.
Что находится под радиатором можно увидеть, посмотрев на плату силового блока сбоку: несколько объёмных деталей не уместившихся на обратной стороне платы. Вот и вся схемотехника.
Модуль MTRF-64
Как я уже сказал, мы будем рассматривать модуль MTRF-64 с UART интерфейсом, его собрата с USB подключением мы трогать не будем, они практически идентичны, за исключением нескольких деталей о которых будет сказано чуть ниже. Фото управляющего модуля:
Как вы видите, он очень похож на силовой блок, те же микросхемы, кварц и ещё несколько деталей. Вот точная маркировка микросхем, установленных на плате. Трансивер:
MRF49XA
1636
M5H
Микроконтроллер:
STI E4 7B573
32F042F6P6
PHL 648 A
Пустующее место для недостающей микросхемы — это место для установки FTDI переходника USB-UART. Тут же видно место для установки USB разъёма — очевидно, что для обоих устройств используется одна и та же печатная плата.
Теперь немного о подключении модуля к микроконтроллерам вообще и к Arduino в частности: для работы модуля достаточно подключить всего четыре провода — RX, TX, VCC, GND. Проще, как говориться, некуда.
Для тех, кто не только читает статьи, но что-то делает своими руками замечу, что модуль питается строго от 3,3 вольт и его выводы не толерантны к 5-вольтовым сигналам, так что имейте это в виду и будьте внимательны при подключении модуля.
Немного о функционале модуля. Он имеет четыре основных режима работы:
- Передатчик для «старых» устройств системы nooLite. Это аналог функционала модуля nooLite MT1132
- Приёмник для «старых» устройств системы nooLite. Аналог модуля nooLite MR1132
- Передатчик для нового оборудования nooLite-F
- Приёмник для нового оборудования nooLite-F
То есть этот модуль является универсальным решением для взаимодействия микроконтроллеров с системой nooLite. Плюс, в отличие от своих аналогов, имеет возможность работать с 64-я каналами, вместо 32-х.
Arduino и nooLite-F
Теперь давайте разберём простой пример, который даст вам представление о работе с этим модулем в среде Arduino. По аналогии вы сможете организовать работу с этим модулем с любой другой системой.
Модуль взаимодействует с управляющим контроллером по последовательному интерфейсу (Serial) на скорости 9600 б/с. Поскольку MTRF-64 работает только с напряжением 3,3 В, то мы отложим в сторону нашу любимую Arduino Mega и возьмём с полки Arduino Due и подключим модуль к ней. Четыре проводка и всё готово. Для связи с модулем будем использовать Serial3.
- Вывод RX модуля подключаем к TX3 (14) Arduino Due.
- Вывод TX модуля подключаем к RX3 (15) Arduino Due.
Теперь можно написать тестовый демонстрационный скетч. Начнём с функции setup().
void setup() {
Serial.begin(115200);
Serial.println();
Serial.println(F("NooLite-F test"));
Serial3.begin(9600);
delay(1);
bootOut();
// Commands:
// 0 - Off
// 2 - On
// 4 - Switch
// 9 - Unbind
//15 - Bind
setCommand(0);
setChannel(0);
setChecksum();
Serial.print(F("CH: ")); Serial.println(TO_MTRF[4]);
Serial.print(F("CMD: ")); Serial.println(TO_MTRF[5]);
Serial.print(F("CHECKSUM: ")); Serial.println(TO_MTRF[15]);
mtrfSend();
delay(100);
}
Запускаем Serial для вывода отладочных сообщений и Serial3 для работы с модулем MTRF-64. При старте модуль входит в режим обновления ПО на 12 секунд и для прерывания этого режима мы включаем функцию
void bootOut() {
for (byte i = 0; i <= 16; i++) {
Serial3.write(BOOT_OUT[i]);
}
}
Которая отправляет магические данные модулю, выводящие его из режима обновления ПО.
Далее формируем команду:
// Commands:
// 0 - Off
// 2 - On
// 4 - Switch
// 9 - Unbind
//15 - Bind
На самом деле команд гораздо больше, с полным описанием протокола и работы модуля вы можете ознакомиться в документе на сайте производителя.
Далее выводим тестовые сообщения о канале, команде и контрольной сумме посылки. На этом начальная процедура setup() закончена и скетч входит в бесконечный цикл loop().
void loop() {
//setBind();
//setUnbind();
//setOn();
//setOff();
setSwitch();
delay(1000);
}
Здесь находятся пять строк, которые инициируют посылку той или иной команды модулю MTRF-64. Вы должны выбрать какую-либо одну команду и запустить скетч (остальные команды должны быть закомментированы). Начинать нужно с команды привязки силового блока к модулю setBind().
Процедура привязки:
- Нажимаете кнопку на силовом блоке — на нём начинает мигать светодиод
- Запускаете скетч с раскомментированной строкой setBind()
- Подтверждаете привязку, нажав ещё раз кнопку на силовом блоке
Всё, теперь комментируете строку setBind() и раскомментируете, например, строку setSwitch(), запускаете скетч и тестовая лампа, подключённая к силовому блоку, начинает мигать раз в секунду. Это только тестовый пример и на основе этого скетча вы можете создать любую, сколь угодно сложную систему управления приборами nooLite.
Ещё немного о работе скетча. В коде формируется содержимое массива TO_MTRF в соответствии с документацией на MTRF-64, ссылку на которую я дал чуть выше. Далее содержимое этого массива посылается по последовательному интерфейсу непосредственно модулю.
После этого ожидается ответ модуля и пришедшими данными заполняется массив FROM_MTRF, далее этот массив анализируется и принимаются заранее запрограммированные решения.
Вот назначение прочих функций тестового скетча:
setChannel(byte ch) — устанавливает требуемый номер канала (0 – 63).
setCommand(byte cmd) — устанавливает нужную команду.
setChecksum() — вычисляет контрольную сумму посылки.
mtrfSend() — отсылка данных.
mtrfReceive() — приём и парсинг ответов модуля.
Таким образом вы можете привязывать и отвязывать устройства на любом канале, включать, выключать и переключать свет при помощи Ардуино и MTRF-64. Ещё раз напомню, что это только демонстрация работы и пример для дальнейшей разработки.
/*
* NooLite-F
* MTRF-64 test Sketch
*/
// 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
byte BOOT_OUT[17] = {171, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,175,172};
byte TO_MTRF[17] = {171, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,172};
byte FROM_MTRF[17];
// Передача адаптеру посылки для выхода из режима обновления ПО
void bootOut() {
for (byte i = 0; i <= 16; i++) {
Serial3.write(BOOT_OUT[i]);
}
}
void setChannel(byte ch) {
TO_MTRF[4] = ch;
}
void setCommand(byte cmd) {
TO_MTRF[5] = cmd;
}
void setChecksum() {
TO_MTRF[15] = 0; // младший байт
for (byte i = 0; i <= 14; i++) {
TO_MTRF[15] += TO_MTRF[i];
}
}
void mtrfSend() {
for (byte i = 0; i <= 16; i++) {
Serial3.write(TO_MTRF[i]);
}
delay(50);
mtrfReceive();
}
void setOff() {
setCommand(0);
setChecksum();
mtrfSend();
}
void setOn() {
setCommand(2);
setChecksum();
mtrfSend();
}
void setSwitch() {
setCommand(4);
setChecksum();
mtrfSend();
}
void setBind() {
setCommand(15);
setChecksum();
mtrfSend();
}
void setUnbind() {
setCommand(9);
setChecksum();
mtrfSend();
}
void setup() {
Serial.begin(115200);
Serial.println();
Serial.println(F("NooLite-F test"));
Serial3.begin(9600);
delay(1);
bootOut();
// Commands:
// 0 - Off
// 2 - On
// 4 - Switch
// 9 - Unbind
//15 - Bind
setCommand(0);
setChannel(0);
setChecksum();
Serial.print(F("CH: ")); Serial.println(TO_MTRF[4]);
Serial.print(F("CMD: ")); Serial.println(TO_MTRF[5]);
Serial.print(F("CHECKSUM: ")); Serial.println(TO_MTRF[15]);
mtrfSend();
delay(100);
}
void loop() {
//setBind();
//setUnbind();
//setOn();
//setOff();
setSwitch();
delay(1000);
}
void printFromMTRF() {
Serial.println();
for(byte i = 0; i < 17; i++) {
Serial.print(FROM_MTRF[i]); Serial.print(" ");
}
Serial.println();
}
void mtrfReceive() {
if (Serial3.available() > 0) {
Serial3.readBytes(FROM_MTRF, 17);
if (FROM_MTRF[0] == 173 && FROM_MTRF[1] == 2 && FROM_MTRF[16] == 174) {
//printFromMTRF();
Serial.print(F("Receive: "));
if (FROM_MTRF[10] != 0 && FROM_MTRF[2] == 0) {Serial.println(F("On!"));}
if (FROM_MTRF[10] == 0 && FROM_MTRF[2] == 0) {Serial.println(F("Off!"));}
if (FROM_MTRF[2] == 1) {Serial.println(F("Error!"));}
} else {
Serial.println(F("Receive error or bind"));
printFromMTRF();
}
}
}
Заключение
В этот краткий обзор не вошёл рассказ о многих функциях новой системы, например о прошивке по воздуху, дистанционной привязке и многих других возможностях — всё невозможно объять в рамках одной обзорной статьи, но я уверен, что скоро появятся другие статьи про nooLite-F от множества любителей и энтузиастов автоматизации.
Теперь моё мнение о новой системе nooLite-F. Однозначно, это большой шаг вперёд для компании Ноотехника. Разница между старой системой и новой большая — шифрование делает её безопасной, а обратная связь позволяет быть уверенным в выполнении отданных команд. А всё вместе это выводит nooLite на новый уровень и позволяет строить на этой системе серьёзные проекты автоматизации.
Комментарии (69)
imbasoft
17.04.2017 10:20+1Здраствуйте. Подскажите, может я просмотрел, а как по факту работает шифрование?
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?smart_alex
17.04.2017 10:28-1Я думаю производитель скрыл все эти тонкости от конечного пользователя, вся работа с устройствами системы сводится к нажатию кнопок на блоках. Но я перешлю ваш вопрос ведущиму инженеру-конструктору Ноотехники и опубликую его ответ из первых рук здесь, как только он придёт ко мне.
mdn-tech
17.04.2017 12:12Всем привет! Чтобы не играть в испорченный телефон — отвечать от лица Ноотехники буду сам:
В протоколе используется AES 128 (соответственно, длина ключа — 128 бит).
Алгоритм — наверное можно это описать так = ECB+CBC+собственные алгоритмические решения. В итоге я остался доволен, т. к. ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают. Ключи создаются случайным образом.imbasoft
17.04.2017 13:07Коллеги, прошу не понять меня неправильно. Я интересуюсь безопасностью IoT с профессиональной точки зрения и не в коем случае не хочу критиковать вашу разработку. Но…
ECB+CBC+собственные алгоритмические решения. В итоге я остался доволен,
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
Ключи создаются случайным образом.
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.mdn-tech
17.04.2017 13:56Решение, которое применяется в новом протоколе нисколько не уменьшает криптостойкость ECB/CBC/CTR, т.к. не затрагивает основную их реализацию. В самом худшем случае — всё равно придётся перебирать ключи.
Основные доработки были сделаны в транспортной части, в которой непосредственно и кроется риск «засветить» то, с чем потом можно работать.
Полное описание протокола, как транспортного, так и доп. криптографических функций я здесь привести не могу (во всяком случае, пока на это не согласится мой наниматель). Я переслал ему ваш комментарий.
По поводу протоколов есть одна особенность: при наличии потребности включить свет у соседа, на данный момент будет проще взломать его WiFi. В основном из-за того, что есть описание и инструменты.
Можно узнать чем конкретно вы оказались довольны?
Я максимально усложнил работу взломщикам, введя дополнительную защиту от брутфорса. Это всё, что я пока могу сказать.
vvzvlad
17.04.2017 14:11+1Подозреваю, что без открытия схемы шифрования параноики так и не успокоятся — они рассматривают любую, даже очень маленькую вероятность взлома, как уязвимость.
herrjemand
17.04.2017 14:20+1Это не параноя. Это нормальное требование. Почитайте про https://ru.wikipedia.org/wiki/Принцип_Керкгоффса
vvzvlad
17.04.2017 14:22Это одновременно и нормальное требование, и паранойя в данном конкретном случае — распространенность таких систем слишком мала, чтобы принимать во внимание атаку на них. Тем более, атаку на шифрование.
herrjemand
17.04.2017 14:25Ну с таким подходом можно вообще забить на безопасность. Да что вы. С таким подходом можно забить на безопасность, разработку, вакцинацию… А потом люди удивляются что появляются Мираи, Лефпады...
vvzvlad
17.04.2017 15:29У вас какой-то мир полярный — или покупаем систему с максимальной безопасностью, или не пользуемся системами вообще. На практике же, вероятность соседа даже со сниффером очень мала.
herrjemand
17.04.2017 15:35Я вам говорю про нормальную практику публикации схем шифрования, использования проверенных решений, а не про систему с идеальной безопасностью. Фраза "собственные алгоритмические решения" ставит под сомнения заявления о безопасности рекламируемых решений.
vvzvlad
17.04.2017 15:41Да я не в коем случае не пытаюсь вам возражать или топить за ноолайт. Просто немного удивляюсь паранойе.
herrjemand
17.04.2017 15:43-1Ну да. Зачем огнетушители в офиссах? Мы же не горим каждый день!
vvzvlad
17.04.2017 16:12-1Ох. Мы в с вами оперируем разными категориями.
Вы считаете, что уязвимая система непригодна для эксплуатации.
Я считаю, что вероятность взлома УД с современным развитием технологий — очень мала, так как для этого необходим практически физический контакт, надо находиться в радиусе десятков метров. Причем должен находиться человек, который имеет сниффер на определенную частоту/протокол и который понимает, что делает и зачем. Это, плюс отсутствие единого стандарта по частотам/протоколам выливается в то, что в шифровании в УД на данный момент необходимости как таковой просто нет.
Поэтому мне немного смешно смотреть на людей, которым нужна безопасность ради безопасности.
tmin10
17.04.2017 14:25Пока мы не знаем, что внутри, можно предположить худшее: псевдослучайная генерация из константного сида и прочее.
imbasoft
17.04.2017 14:33Наличие шифрование в данном решение указано как конкурентное преимущество, то есть то, чего раньше не было.
Поэтому желание узнать обеспечивает ли шифрование безопасность вполне справедливое желание узнать потребительские качества решения.mdn-tech
17.04.2017 14:48+1Не ожидал что будет столько вопросов по шифрованию.
На мой взгляд — наличие шифрования, это когда в базовом виде нельзя вскрыть систему кодграббером или подобрать управляющую последовательность. Это тут есть.
Дальше уже идёт отношение шифрование/возможные риски. Можно было и 256 бит сделать, но смысла нет, т.к. это не транзикация между банками, а включение света.
Если я даже распишу всю схему шифрования, то местное сообщество параноиков на этом не успокоится, и попросят исходники.imbasoft
17.04.2017 16:07+1При оценке безопасности вы, на мой взгляд, неправильно оцениваете риски.
Вы можете включать или выключать 220V. Если человек будет работать с электрической сетью и на нее будет несанкционированно подано напряжение это может привести к смерти.
Системы безопасности лучше внедрять и совершенствовать в начале продукта, а не когда он разошелся миллионным тиражом.tmin10
17.04.2017 16:11Возможно, вы уже утрируете. Если будут проводиться работы с электричеством, то доверять таким устройствам никак нельзя (даже выключателям нельзя), нужно вырубать автоматы, иначе сам виноват в нарушении ТБ.
imbasoft
17.04.2017 16:17+1Всем кто считает меня параноиком, рекомендую посмотреть презентации с Positive Hack Days, где ребята ломали промышленную автоматизацию. Начало у пром. автоматики было такое же — «за цените как круто и удобно».
P.S. Мне просто интересно, как коллеги реализовали шифрование :)mdn-tech
17.04.2017 16:30-1Я тоже в своём роде добрый «параноик». Правда есть понимание, что в современном мире вопрос «взлома», это лишь вопрос тех средств, которые вы готовы вложить в результат. Пока объект «физически» доступен для манипуляций — его можно взломать. Такова природа физической реальности.
Насколько я понял из комментариев, полнота ответа «какое используется шифрование?» всегда будет зависеть от глубины паранои (в хорошем смысле этого слова). Даже с описанным алгоритмом шифрования новая система имеет такую же вероятность взлома, как и без него.
Почему? (Теперь включу параноика я).
Наверное потому, что пока вы до конца не будете знать какой там исходный код — приведённый алгоритм будет таким же вопросом веры, как и то, что сейчас заявляется как шифрование. Наверное — open source с проверкой контрольных сумм, единственное, что позволит успокоится. Пока у вас нет исходной реализации в коде — всё будет вопросом веры.imbasoft
17.04.2017 16:43Лично мне хватило бы абстрактного описания протокола. Реализацию тестить наlj все равно не на исходниках а снифать пакеты по факту.
Чистые симметричные крипто схемы очень неудобны в эксплуатации. Поэтому, судя по вашим ответам я предполагаю, что в ваша система сделана следующим образом.
На узлах сети, есть встроенные «магические» ключи. При начале обмена вы рандомом генерируете случайный сессионный ключ, шифрутете его магическим ключом и транслируете в сеть. Другие узлы видят пакет, расшифровывают его своим магическим ключом и извлекают от туда сеансовый ключ, так начинается сеанс обмена. Во время сеанса пакеты вы шифруте и считаете HMAC. Для защиты от повторов используется нумерование пакетов. Такой своеобразный протокол TCP.
Подобная схема как раз соответствует указанной выше модели угроз.
olartamonov
18.04.2017 01:46+1В подобных системах один сеанс передачи данных — это всего несколько байт, поэтому генерация нового сеансового ключа на каждый чих не имеет никакого смысла, более того, при низкой скорости передачи — сильно увеличивает time-on-air.
Поэтому обычно сеансовый ключ хранится в течение достаточно длительного времени (часы-дни) в ОЗУ устройств и используется совместно с ECB. Данные при ECB с неизменным ключом, конечно, стоит немного посолить.
В системе с центральным шлюзом базовый («магический») ключ может быть задан на шлюзе через банальный веб-интерфейс. При нажатой на этом же шлюзе физической кнопке он может принимать соединения от устройств с неким ключом по умолчанию и выдавать им в ответ ключ, заданный пользователем — таким образом устройства будут инициализированы ключом данной конкретной сети без необходимости физического подключения к ним. Риск слить таким образом ключ сети на сторону крайне невелик.
У Ноолайта, где центральный шлюз необязателен, эта схема не работает, так что возникает вопрос, откуда берётся и как распространяется базовый ключ.
И есть тут, конечно, плохое подозрение про security through obscurity и ключ, тупо зашитый во флэш и одинаковый для всех выпущенных устройств. Тогда или сеансовые ключи генерируются при привязке устройств друг к другу, пишутся во флэш и хранятся там вечно, или можно поуправлять светом у соседа.
tmin10
17.04.2017 17:02+1Я немного не про это: доверять свою жизнь таким железкам, а не вырубать автоматы при электромонтажных работах — это прямое нарушение ТБ и виноват сам нарушитель. А про алгоритм мне самому было-бы интересно почитать, раз тут такой хороший фидбэк от разработчиков.
olartamonov
18.04.2017 01:46+1Я немного не про это: доверять свою жизнь таким железкам, а не вырубать автоматы при электромонтажных работах — это прямое нарушение ТБ
С учётом, что гальваноразвязки они не обеспечивают — мудрое решение ;)
zapimir
18.04.2017 01:32Дело не в паранойе, а в том, что зачастую разработчики вообще не парятся с шифрованием, и думают, что достаточно просто использовать функцию AES_enсrypt (условно), и система становится супер защищенной. Причем из-за того, что люди не вникали не то что в тонкости шифрования, но даже не читали рекомендации, как делать правильно. В итоге получается фигня, но с иллюзией безопасности.
Примерно, как в дешевую китайскую входную дверь вставить самый крутой замок (или даже 2-3). Да замок крутой и его не взломают отмычкой, или ещё как-то. Воры просто отогнут дверь ломиком секунд за 20.
imbasoft
17.04.2017 14:29+1Если не можете привести схему, то продемонстрируйте хотя бы модель угроз по которой вы строили систему защиты.
И еще вы упомянули, что генерируете ключи случайным образом, опишите пожалуйста откуда вы берете энтропию и какой алгоритм генерации используете. Сноуден очень интересно рассказывал про «случайные» ключи шифрования.
Я максимально усложнил работу взломщикам, введя дополнительную защиту от брутфорса. Это всё, что я пока могу сказать.
В природе существует абсолютно стойкий шифр — шифр Вернама (однаразовый блокнот) брут-форс по нему невозможен и это научно доказано.
НО применяя один и тот же ключ более чем к одному открытому тексту, злоумышленник перехватив зашифрованные данные способен к безключевому чтению. Вот такая вот защита от брут-форса…mdn-tech
17.04.2017 14:54Если не можете привести схему, то продемонстрируйте хотя бы модель угроз по которой вы строили систему защиты.
Модель угроз — кодгарббер, снифер. Изменение (повтор) и ретрансляция ложного пакета.
tmin10
17.04.2017 13:22+1Хотелось бы полного раскрытия алгоритмов и, возможно, аудита от специалистов в области криптографии. Иначе есть возможность засветиться в https://twitter.com/internetofshit.
К сожалению, сейчас безопасность в IoT оставляет желать лучшего, а т.к. всё реализовано в железе, то баги пофиксить не получится быстро.mdn-tech
17.04.2017 14:04Ответил выше.
Насчёт безопасности — на мой взгляд большая часть таких проблем из-за незакрытых инженерных бэкдоров, нежели чем из-за самих протоколов или схем шифрования.tmin10
17.04.2017 14:16+1Спасибо за ответы. Вопросы вызваны тем, что после прослушивания курса криптографии на корсере (ни в коем случае не мню себя экспертом после этого), когда лектор множество раз говорил не изобретать велосипед, а воспользоваться готовыми алгоритмами и схемами, т.е. их безопасность доказывается математически, обращаю внимание на это. Также ярким примером является WEP, который вроде бы и изобретён был профессионалами, но в его архитектуру заложены столь глупые ошибки, что не понятно, как это вообще могло произойти.
В IoT устройствах, насколько понимаю, чаще всего или вообще полное отсутствие какой-то защиты или низкое число возможных вариантов ключей, или применение какой-то своей гениальной схемы, в которой профессионал быстро находит слабое место (примеры тоже были в известных продуктах, но уже не вспомню).
herrjemand
17.04.2017 14:10+2Алгоритм — наверное можно это описать так = ECB+CBC+собственные алгоритмические решения.
Что вы имеет ввиду ECB+CBC+собственные алгоритмические решения? Нельзя совместить ECB и CBC, они два противополжных мода. Один статически шифрует блоки одним и тем же ключем, а второй шифрует цепочным миксом.
В итоге я остался доволен, т. к. ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
Вы говорите о трех разных модах которые используются в разных видах операций. CTR как раз хорошее решение для IoT, который на пример советует Gemalto. https://www.lora-alliance.org/portals/0/documents/whitepapers/LoRaWAN_Security-Whitepaper_V6_Digital.pdf
Ключи создаются случайным образом.
И как происходит обмен ключами?
Можно пожалуйста публично представить схему вашего шифрования?
av0000
17.04.2017 11:15Прочитал. Даже скачал мануал по ссылке, но так до конца и не понял два момента:
— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
Ну и да, с шифрованием как-то непонятно… Раскрыть бы немного подробностиsmart_alex
17.04.2017 11:24Когда вы отдаёте команду силовому блоку, то в Serial интерфейс приходят ответы, содержащие актуальную (то есть действительную) информацию о состоянии блока. Если вы измените состояние силового блока с брелка, то модуль MTRF не получит специальное уведомление. Переслал ваш вопрос разработчикам — послушаем официальный ответ на это вопрос.
av0000
17.04.2017 11:36Когда вы отдаёте команду силовому блоку, то в Serial интерфейс приходят ответы,
Это-то понятно. Но, как по мне, не вполне достаточно. Подождём ответа разработчиков, ибо:
во-первых, радио — довольно непредсказуемая вещь в плане помех, может и ответ не получить (да, читал, есть состояние «нет ответа» или «ошибка исполнения», но она вряд ли скажет текущий статус).
во-вторых, я могу, например, перезагрузить своё устройство с MTRF и/или софтом для контроля/визуализации. И как мне узнать нынешнее состояние?Lerk
17.04.2017 11:58Перед перезагрузкой сохранить текущее состояние системы, а после загрузки заново отослать все команды, на установку тех значений, что восстановлены из памяти. Соотв-но в случае корректной работы оборудования с каждого датчика вернется ответ, что устройство и так уже выключено/включено.
av0000
17.04.2017 12:15Не-е-е… Не вариант:
— устройство могло сброситься не по своей воле и чего-то не сохранить
— у меня «есть» ещё брелки/настенные выключатели и т.п.
— команда «Switch» (из примера) переключает нагрузку и, посему я «не знаю», в каком состоянии лампочка, если _успешный_ ответ не был получен.
причём, если я сижу дома и надо мной погас свет — это одно, а если это обогреватель/котёл/насос/да-что-угодно где-то далеко, ну хотя бы на даче? И был переключен по какому-то алгоритму не «мной», а другим блоком ноолайт-а…
Собственно, пока не будет нормальной информации о состоянии исполнительного устройства, буду «облизываться» на ноолайт, но делать свои временные поделки, где точно буду знать, что происходит :)mdn-tech
17.04.2017 12:37+1Есть ещё одна особенность, почему запрос состояние должен инициировать сам адаптер, а не блок.
Мы рассматривали следующую ситуацию: есть несколько блоков, которые привязаны к одному обычному nooLite пульту. Если с него включить/выключить блоки, то тогда если они будут сами передавать своё состояние — будет каша в радиоэфире (можно конечно и это победить, но протокол значительно усложняется и может появиться лишняя задержка).
Поэтому запрос лучше просто выполнять через какой-либо временной промежуток или привязать управляющие устройства (пульты и пр.) к адаптеру и по событию считывать состояние.
past
17.04.2017 14:00А разгадка одна — z-wave.
mdn-tech
17.04.2017 14:13От идеи MESH сети отказались в самом начале. Постоянно засорённый радиоканал меня немного напрягает, т.к. он один на всех и нужно иметь совесть. Плюс ко всему, появляется задержка. Для управления светом, на мой взгляд, это неприемлемо.
vvzvlad
17.04.2017 14:22+1А откуда и какая задержка у вас появляется?
mdn-tech
17.04.2017 14:30В MESH сетях команды передаются путём прокладки маршрутов. Если команда пошла в сеть, то нужно время чтобы построить маршрут и передать по сети.
vvzvlad
17.04.2017 15:27+3Простите, что? Если сеть построена, то ничего прокладывать не надо. Постройка сети занимает минуты. Задержка — от 20 до 70мс на один хоп. В условиях умного дома(небольшое пространство, сильносвязанные сети, малое число хопов) задержка несущественна.
mdn-tech
17.04.2017 16:41В идеальных условия так. Но опыт реальной эксплуатации в помехах показывает уже значительную задержку. С учётом того, что китайцы уплотнили радиоэфир 433 МГц своими датчиками и метеостанциями и продолжают это делать — ставить на этот диапазон MESH сеть — только получать потом больше проблем (я слушал эфир — он прилично забит, где-то через 3-10 сек что-то всегда передаётся).
И потом, постоянно передающая штука в комнате, когда я ничего не делаю, мне не очень нравиться. Сеть, какой бы она не была, всё равно требует периодического обновления.vvzvlad
17.04.2017 16:44+1А, ну если стоит задача любым способом обеспечить совместимость с предыдущим поколением на 433мгц, то да. Но вот уже на 866/2.4 mesh-сети работают отлично.
Ну и да, устройства будут периодически общаться друг с другом. Это единственный способ понять, что какое-то из них вдруг умерло.
mdn-tech
17.04.2017 12:20+1— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— да, можно. Есть команда CMD_Read_State, которая считывает состояние силового блока. Документацию только что обновил на сайте — там описан ответ от команды.
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
— нет, пока сами не считаете состояние блока. Для автоматизации можно привязать к этому же адаптеру/модулю брелок, и по событию обновить состояние блоков.av0000
17.04.2017 12:33Благодарю!
Собственно, если CMD_Read_State работает, то этого уже вполне достаточно для начальной синхронизации.
С автоматизацией — идея правильная, ибо постоянным опросом на батарейках разоришься :)
Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!mdn-tech
17.04.2017 12:40Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!
Мы продумывали этот вариант — можно пока использовать обычные пульты (блок может работать с ними параллельно). Единственный минус — отсутствие шифрования, которое компенсируется тем, что можно с адаптера передать команду, которая заблокирует управление с обычных пультов (если уходите из дома). Потом по приходу разблокировать. Обратная связь в стационарных пультах особо ничего не даёт, т.к. сам пульт чаще всего в этой же комнате, и визуальной обратной связи вполне достаточно.av0000
17.04.2017 12:53Про параллельно не совсем понял.
Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Пусть будет освещение: 3-4 люстры по 1-2 канала каждая, на каждую люстру по 2 выключателя (типа «проходных»), некий «комп» с MTRF. Одна из люстр с новым (-F) блоком, остальные с обычными.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Обратная связь в стационарных пультах особо ничего не даёт,
Зато появляется вариант желаемых некоторыми выключателей с фиксацией, правда тогда придётся алгоритм вкл/откл выдумывать…mdn-tech
17.04.2017 13:06+1Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Адаптер на приём работает всегда, переключать не нужно. Когда придёт команда — с адаптера придёт пакет с ней. Другими словами — представьте что в этом адаптере параллельно работают 4 адаптера, которыми можно управлять, указывая для которого из них сейчас отправляется команда. Над документацией мы ещё работаем, так что более подробное описание будет.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Новыми блоками можно управлять как со старых пультов (они совместимы с ним), так и с нового адаптера. Отличие только в том, что при управлении с адаптера можно получить состояние нового блока.
Старыми блоками также можно управлять с нового адаптера, для этого просто при передаче управляющей команды указывается что передавать это нужно в режиме старого nooLite. Теоретически, это же можно сделать и для нового блока, т.к. в нём тоже есть поддержка старого nooLite.
smart_alex
17.04.2017 12:24Друзья, не стесняйтесь, у вас есть редкая возможность задать свои вопросы по nooLite непосредственно разработчику системы.
vvzvlad
17.04.2017 14:03+2STI E4 7B573
32F042F6P6
PHL 648 A
Простите, а копировать всю маркировку с чипа — это новый модный тренд вместо того, чтобы написать «STM32F042F6»?
kolayuk
17.04.2017 16:48Очень жду новых девайсов с обратной связью, пока в SLF-1-300 не нравится отсутствие возможности (ну точнее это делается костылями с разборкой корпуса) подключить силовой блок за выключатель и сохранить аналоговое управление выключателем как в SB-1-150, так что усиленно ждем SBF-1-150 с поддержкой выключателя и обратной связи :)
Кстати, интересует вопрос как обстоит дело с обратной связью при переключении состояния вручную через выключатель? Получат ли связанные устройства сообщение об изменении состояния?
mdn-tech
17.04.2017 17:35усиленно ждем SBF-1-150 с поддержкой выключателя и обратной связи
Технически, сделать паразитное (питание через нагрузку) в новом типе устройств не очень просто, т.к. ток потребления стал больше. Есть пару вариантов, сейчас обдумываем. Кнопочное/клавишное управление в SLF-1-300 есть, но для этого нужно подпаивать провода. Если просьбы будут и дальше поступать — будем паять сразу, как в SB.
переключении состояния вручную через выключатель? Получат ли связанные устройства сообщение об изменении состояния?
Нет, в этом случае состояние блока нужно будет обновлять через некоторое время. Возможно, в следующих версиях блоков с обновлением ПО сделаем события. Пока от них отказались, т.к. снова возникает ситуация, если 2 блока, и вы их одновременно включаете, оба сразу и начнут передавать.
Проще реализовать так: при заходе на страницу управления происходит опрос тех устройств, которые на ней есть. Получается визуально и быстро, так что даже постоянно опрашивать смысл отпадает.
IgorKKK
18.04.2017 06:02to mdn-tech
Пожалуйста, дайте пример посылки 17 байтов запроса состояния силовому блоку SLF-1-300
Не смог методом инженерного тыка понять что написано в документации.mdn-tech
18.04.2017 10:21+1Пример набросал, смотрите. Что непонятно — спрашивайте.
Пример
mappa
18.04.2017 20:05Чём вызвано ограничение в 64 устройства на управляющего блоке?
mdn-tech
18.04.2017 21:18Ограниченными ресурсами микроконтроллера (планируется ещё добавлять функции — в адаптере/модуле есть обновление ПО), поэтому решили остановиться на 64 устройствах.
IgorKKK
19.04.2017 00:32+1Подскажите, если при включении, в эти 12 секунд, на модуль будет высыпано много байт случайной информации на скорости 115200, может это как-то повлиять на его работоспособность или вообще завесить?
mdn-tech
19.04.2017 10:34Не должно никак повлиять. Команды для управления в этот промежуток времени тоже обрабатываются только в формате пакета с контрольной суммой.
IgorKKK
20.04.2017 13:42Не получается, что я не так делаю?
Для включения яркости 50% на 0 канале старому силовому блоку отправляю такую последовательность:
171,0,0,0,0,6,1,95,0,0,0,0,0,0,0,17,172
А именно:
171 (старт),
0 (nooLite TX),
0 (Передать команду),
0,
0 (Ячейка),
6 (Яркость),
1 (Один байт данных),
95 (Половина яркости),
0,
0,
0,
0,
0,
0,
0,
17, (Контрольная сумма)
172mdn-tech
20.04.2017 16:10Всё верно, должно работать.
Проходят ли команды вкл/выкл?
Посмотрите ещё, включено ли диммирование (для блоков SU).IgorKKK
20.04.2017 16:29Спасибо, все заработало. Был какой-то временный сбой.
… можно сказать, устройство полностью готово.
Отрабатывает все возможные варианты связи с блоками и датчиками, исключая RGB- ленту. У меня ее нет.
Буду описывать для народа.
Mobile1
А у вас нет в планах сделать управление по Wi-Fi и всем через облако управлять?
smart_alex
У меня в планах интегрировать модуль MTRF-64 с AMS для проводных контроллеров (Mega, Due, 101, M0, RobotDyn Mega+WiFi и т. д.) и беспроводных (ESP8266, Sonoff, RobotDyn Mega+WiFi, LYTKO AMS Home, ESP32 и т. д.), а у компании Ноотехника большие планы по выпуску новых изделий системы nooLite-F и разработки решений на них но подробности мне не известны.