Comments 89
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
ECB+CBC+собственные алгоритмические решения. В итоге я остался доволен,
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
Ключи создаются случайным образом.
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
Это не параноя. Это нормальное требование. Почитайте про https://ru.wikipedia.org/wiki/Принцип_Керкгоффса
Ну с таким подходом можно вообще забить на безопасность. Да что вы. С таким подходом можно забить на безопасность, разработку, вакцинацию… А потом люди удивляются что появляются Мираи, Лефпады...
Я вам говорю про нормальную практику публикации схем шифрования, использования проверенных решений, а не про систему с идеальной безопасностью. Фраза "собственные алгоритмические решения" ставит под сомнения заявления о безопасности рекламируемых решений.
Ну да. Зачем огнетушители в офиссах? Мы же не горим каждый день!
Вы считаете, что уязвимая система непригодна для эксплуатации.
Я считаю, что вероятность взлома УД с современным развитием технологий — очень мала, так как для этого необходим практически физический контакт, надо находиться в радиусе десятков метров. Причем должен находиться человек, который имеет сниффер на определенную частоту/протокол и который понимает, что делает и зачем. Это, плюс отсутствие единого стандарта по частотам/протоколам выливается в то, что в шифровании в УД на данный момент необходимости как таковой просто нет.
Поэтому мне немного смешно смотреть на людей, которым нужна безопасность ради безопасности.
Поэтому желание узнать обеспечивает ли шифрование безопасность вполне справедливое желание узнать потребительские качества решения.
Вы можете включать или выключать 220V. Если человек будет работать с электрической сетью и на нее будет несанкционированно подано напряжение это может привести к смерти.
Системы безопасности лучше внедрять и совершенствовать в начале продукта, а не когда он разошелся миллионным тиражом.
P.S. Мне просто интересно, как коллеги реализовали шифрование :)
Чистые симметричные крипто схемы очень неудобны в эксплуатации. Поэтому, судя по вашим ответам я предполагаю, что в ваша система сделана следующим образом.
На узлах сети, есть встроенные «магические» ключи. При начале обмена вы рандомом генерируете случайный сессионный ключ, шифрутете его магическим ключом и транслируете в сеть. Другие узлы видят пакет, расшифровывают его своим магическим ключом и извлекают от туда сеансовый ключ, так начинается сеанс обмена. Во время сеанса пакеты вы шифруте и считаете HMAC. Для защиты от повторов используется нумерование пакетов. Такой своеобразный протокол TCP.
Подобная схема как раз соответствует указанной выше модели угроз.
Поэтому обычно сеансовый ключ хранится в течение достаточно длительного времени (часы-дни) в ОЗУ устройств и используется совместно с ECB. Данные при ECB с неизменным ключом, конечно, стоит немного посолить.
В системе с центральным шлюзом базовый («магический») ключ может быть задан на шлюзе через банальный веб-интерфейс. При нажатой на этом же шлюзе физической кнопке он может принимать соединения от устройств с неким ключом по умолчанию и выдавать им в ответ ключ, заданный пользователем — таким образом устройства будут инициализированы ключом данной конкретной сети без необходимости физического подключения к ним. Риск слить таким образом ключ сети на сторону крайне невелик.
У Ноолайта, где центральный шлюз необязателен, эта схема не работает, так что возникает вопрос, откуда берётся и как распространяется базовый ключ.
И есть тут, конечно, плохое подозрение про security through obscurity и ключ, тупо зашитый во флэш и одинаковый для всех выпущенных устройств. Тогда или сеансовые ключи генерируются при привязке устройств друг к другу, пишутся во флэш и хранятся там вечно, или можно поуправлять светом у соседа.
Примерно, как в дешевую китайскую входную дверь вставить самый крутой замок (или даже 2-3). Да замок крутой и его не взломают отмычкой, или ещё как-то. Воры просто отогнут дверь ломиком секунд за 20.
И еще вы упомянули, что генерируете ключи случайным образом, опишите пожалуйста откуда вы берете энтропию и какой алгоритм генерации используете. Сноуден очень интересно рассказывал про «случайные» ключи шифрования.
Я максимально усложнил работу взломщикам, введя дополнительную защиту от брутфорса. Это всё, что я пока могу сказать.
В природе существует абсолютно стойкий шифр — шифр Вернама (однаразовый блокнот) брут-форс по нему невозможен и это научно доказано.
НО применяя один и тот же ключ более чем к одному открытому тексту, злоумышленник перехватив зашифрованные данные способен к безключевому чтению. Вот такая вот защита от брут-форса…
К сожалению, сейчас безопасность в IoT оставляет желать лучшего, а т.к. всё реализовано в железе, то баги пофиксить не получится быстро.
В IoT устройствах, насколько понимаю, чаще всего или вообще полное отсутствие какой-то защиты или низкое число возможных вариантов ключей, или применение какой-то своей гениальной схемы, в которой профессионал быстро находит слабое место (примеры тоже были в известных продуктах, но уже не вспомню).
Алгоритм — наверное можно это описать так = 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
Ключи создаются случайным образом.
И как происходит обмен ключами?
Можно пожалуйста публично представить схему вашего шифрования?
— можно ли запросить состояние силового блока (вроде есть команда get_status, но не документирована)?
— что будет, если я переключу лампу с брелка/выключателя? Узнает ли mtrf об этом?
Ну и да, с шифрованием как-то непонятно… Раскрыть бы немного подробности
Когда вы отдаёте команду силовому блоку, то в Serial интерфейс приходят ответы,
Это-то понятно. Но, как по мне, не вполне достаточно. Подождём ответа разработчиков, ибо:
во-первых, радио — довольно непредсказуемая вещь в плане помех, может и ответ не получить (да, читал, есть состояние «нет ответа» или «ошибка исполнения», но она вряд ли скажет текущий статус).
во-вторых, я могу, например, перезагрузить своё устройство с MTRF и/или софтом для контроля/визуализации. И как мне узнать нынешнее состояние?
— устройство могло сброситься не по своей воле и чего-то не сохранить
— у меня «есть» ещё брелки/настенные выключатели и т.п.
— команда «Switch» (из примера) переключает нагрузку и, посему я «не знаю», в каком состоянии лампочка, если _успешный_ ответ не был получен.
причём, если я сижу дома и надо мной погас свет — это одно, а если это обогреватель/котёл/насос/да-что-угодно где-то далеко, ну хотя бы на даче? И был переключен по какому-то алгоритму не «мной», а другим блоком ноолайт-а…
Собственно, пока не будет нормальной информации о состоянии исполнительного устройства, буду «облизываться» на ноолайт, но делать свои временные поделки, где точно буду знать, что происходит :)
А разгадка одна — z-wave.
Собственно, если CMD_Read_State работает, то этого уже вполне достаточно для начальной синхронизации.
С автоматизацией — идея правильная, ибо постоянным опросом на батарейках разоришься :)
Осталось дождаться выключателей с новым протоколом и жизнь вообще наладится!
Если там разные протоколы, мне придётся постоянно переключать MTRF из старого в новый режим? Или на приём будет работать и так? Раз уж пошла такая пьянка, пример бы…
Пусть будет освещение: 3-4 люстры по 1-2 канала каждая, на каждую люстру по 2 выключателя (типа «проходных»), некий «комп» с MTRF. Одна из люстр с новым (-F) блоком, остальные с обычными.
Я так понимаю, что новым блоком (пока) будет рулить исключительно MTRF, а старыми могут как пульты, так MTRF?
Обратная связь в стационарных пультах особо ничего не даёт,
Зато появляется вариант желаемых некоторыми выключателей с фиксацией, правда тогда придётся алгоритм вкл/откл выдумывать…
STI E4 7B573
32F042F6P6
PHL 648 A
Простите, а копировать всю маркировку с чипа — это новый модный тренд вместо того, чтобы написать «STM32F042F6»?
Кстати, интересует вопрос как обстоит дело с обратной связью при переключении состояния вручную через выключатель? Получат ли связанные устройства сообщение об изменении состояния?
Пожалуйста, дайте пример посылки 17 байтов запроса состояния силовому блоку SLF-1-300
Не смог методом инженерного тыка понять что написано в документации.
Чём вызвано ограничение в 64 устройства на управляющего блоке?
Подскажите, если при включении, в эти 12 секунд, на модуль будет высыпано много байт случайной информации на скорости 115200, может это как-то повлиять на его работоспособность или вообще завесить?
Для включения яркости 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, (Контрольная сумма)
172
силовые блоки привязываются командой 15.
А как с пультами?
с разъяснениями от самой организации
Сама организация на своем сайте не имеет неи форума ни нормальной техподдержки.
Вопросы приходится задавать по всяким случайным темам.
Ребята, вы что… Вы из какого века?
Я общался с разработчиком этой железки и в конце концов был послан… со своими вопросами. Вопросами того, для кого эта железка и разрабатывалась.
Посмотрите на документацию, там до сих пор не убраны даже грамматические ошибки — «Управление модульом ».
Купил еще один модуль — похоже(?) не работает. И нет даже желания ни к кому обращаться.
… " с разъяснениями от самой организации". Движетесь вперед семимильными шагами — http://www.noo.com.by/sistema-radioupravleniya-noolite.html — ОГО!!!
Но тем не менее система очень интересная. Интегрировал ее в свой умный дом, работает стабильно.
Пока не работал с датчиками температуры, а вот цена на датчик температуры и влажности завышены неимоверно…
Хотелось бы видеть датчики движения в классическом корпусе с кронштейном.
Необходимы датчики открытия/закрытия двери/окна, датчики протечки, датчик атмосферного давления.
не помешала бы и возможность подключения датчиков ds18b20, они есть и во всепогодном исполнении.
Извиняюсь, вот ссылка на мои поделки с этим железом.
А где таблица то?
Это был мой первый вопрос разработчику. Воз и ныне там.
тем не менее система очень интересная.
Интересная. Ценой она интересна, в первую очередь. А ассортиментное наполнение — однобокое.
Но вот ребята уже дышат в спину: http://delumo.ru/ Разговаривал с разработчиком — готовят к выпуску такие же модули управления.
При нажатии кнопки пультов приходят подобные команды от модуля:
mode=1, req_code=0, togl=46, n_ch=0, n_cmd=0, n_format=0, n_d0=36, n_d1=0, n_d2=0, n_d3=0, n_adr=0
Хотелось понять, что значит n_d0=36
Товарищ разработчик!
Ответьте на простые вопросы: Почему мы общаемся с Вами в этой проходной теме? Почему не существует нормального форума, нормального места общения на вашем сайте?
Вам страшно его создать?
Работа по документации уже ведётся. Но это не так быстро, т. к. параллельно идёт несколько разработок
Пожалуйста! Выложите инструкцию по прошивке и прошивку для MTRF-64.
(свеже) Купленный модуль после подачи питания через 10-12 секунд мигает светодиодом как и обычный но больше до него достучаться не удается.
Полагаю, его следует перепрошить — как это сделать?
Новая система nooLite-F с обратной связью и шифрованием