Как стать автором
Обновить

Интернет вещей по-русски. Канальный уровень OpenUNB. Общие положения и адресация устройств

Время на прочтение6 мин
Количество просмотров2.6K
Всего голосов 3: ↑3 и ↓0+3
Комментарии26

Комментарии 26

Мне всегда казалось, что статья с заголовком "<что-то там сложное> по-русски" поведает
об этом сложном, но на простом человеческом языке. Данная статья разрушила данное заблуждение.
Прошу прощения, я старался упростить. Видимо не вышло.

Но «по-русски» здесь означает не «перевод на русский», а «наш, отечественный, созданный в России».
Теперь полная картина не ускользнет от вас.


Хотел задать вопрос, как решается проблема с уходом часов на устройстве, но прочитал в стандарте. Не могу сказать, чтобы уже были какие-то конкретные замечания, но на первый взгляд как-то чесание левой пяткой правого уха напоминает.
Конечно, напоминает. Связь-то односторонняя.
Да я помню, что одностороння. Надо вспомнить, что по этому поводу в Weightless-N было…
Мне тоже интересно. Я не могу найти спецификацию. Она публична? Или надо стать мембером?
Было б, где становиться мембером… Судя по тому, что на сайте weightless.org недавно появился какой-то сомнительный контент, а теперь он недоступен, и ubiik с публичных страниц ссылки поубирали, дела у Weightless SIG не очень.
Еще есть Wireless M-Bus, но у него скорости большие, дальности не будет.

Да и спецификация недоступна, надо заплатить.
Он сильно похитрее. Не такой однонаправленный :-)
Написано, что режимы T1 и S1 однонаправленные.
Если бы их не было — я бы просто написал, что протокол двунаправленный :-)
Для общего понимания достаточно драфта, да и полно по нему информации в инете.
Спасибо!

Но при криптографию нет ничего.
Ну там же целая пачка стандартов по M-BUS. Криптографии, специфичной именно для Wireless, вроде и нет. Плюс там еще и на произвол производителей слегка рассчитано.
А так проще сводный обзор почитать, чем в спеке сразу ковыряться. Можно не то выковырять с непривычки, были прецеденты :-)
Спасибо! Объемный документ. Сложно понять, есть в нем про однонаправленный вариант или нет. Слова «T1», «S1» и «unidirect» не находятся.
Пачка из всех EN13757 стандартов была бы пообъемней.
А почему Вы думаете, что там есть какой-то отдельный криптографический режим для однонаправленной связи?
Я искал примеры протоколов аутентификации, шифрования, обеспечения целостности и защиты от повторов для экономичных систем типа Интернета вещей, чтобы сравнить с OpenUNB. В однонаправленной системе сложно обеспечить сеансовую смену ключей. В двунаправленной это легко. Кажется, без смены ключей нельзя обеспечить надежную защиту от повторов.
Да это я понял, Вы просто почти с самого начала упомянули WMBUS, я думал, может, упустил что. Я с ним не особо много возился. И скорее с американским специфическим изводом.
Кстати, защита от повторов не всегда нужна. Разнообразные счетчики, под которые и создан тот же WMBUS, как раз пример. Показания счетчика по-хорошему сопровождаются таймстемпом, ну пусть кто-нибудь повторяет перехваченные пакеты, ему только спасибо скажут :-)
Простые счетчики повторять наверное бесполезно.

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

В протоколах по радио обычно экономят и не делают таймстемп большой длины, а это значит, что он скоро повторится.

Да нет, совершенно не значит. Точность же важна еще. Тут нужна та, которая удовлетворит метрологов. Для суточных показаний — с точностью для суток, для получасовых — с точностью для получаса. Возьмем плохой вариант, получасовки. 16 бит хватит года на три с половиной, 20 бит хватит фактически на все время жизни счетчика.

Вам действительно стоит понасобирать описаний протоколов прикладного уровня и вникнуть в них внимательно.
P.S.
Тогда злоумышленник может сделать повтор, который приведет к искажению информации в инфосистеме.

Это тоже, кстати, не факт. Во многих случаях на верхнем уровне на раз отлавливается. Если показания нарастающим итогом — сразу видно, если вдруг они в обратную сторону пошли. Т.е. тут нет никакого «обычно» — есть конкретные ситуации, требующие конкретного решения в каждом случае.
Я не разработчик, я пытаюсь осознать и проанализировать протокол, чтобы сильно не соврать в статьях на тему. Разработчики закладываются не только на сбор информации со счетчиков. Наверное поэтому ставят себе задачу защитить систему от повторов.
Да я не спорю, что она нужна. Тут просто проблема «броня-снаряд». Как бы от переутяжеления дредноут не потонул :-), и особенно обидно будет, если на нем предполагалось всего лишь туристов по Неве катать :-)
Это конечно все правильно:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации