Комментарии 8
Называть 6LoWPAN протоколом не очень корректно, отдельно он на практике не применяется, но включен в другие протоколы. Например Thread. И шлюз для "6LoWPAN" еще как нужен, т.к. он управляет меш сетью и преобразует IPv6 либо иные входящие пакеты в пакеты под конкретную технологию. Т.е. у вас не может быть прямой сети между своей сетью и технологией с 6LoWPAN, "преобразовалка" нужна обязательно.
Да, 6LoWPAN – не совсем протокол. Это стандарт, который лежит в основе других протоколов.
Для данных сетей понятие Gateway не применяется, в источниках указывают border router или edge router.
Шлюз в данном случае - это устройство которое преобразует, но не передает данные дальше: чтобы их получить, нужно знать адрес шлюза и запросить их у него. Роутер знает обе сети и может сразу направить данные к получателю, за ними не надо обращаться.
Бельгийским исследовательским институтом CETIC был разработан проект 6LBR. Благодаря ему связь между сетями может быть настроена как в аппаратном (отдельным устройством), так и программном (на ОС Linux) виде без необходимости использования отдельного устройства, занимающегося только преобразованием и передачей. Условно, у нас может быть сервер, на котором установлен 6LBR, и к нему подключены 6LoWPAN и Ethernet сеть. ПО на сервере сможет обращаться к устройствам в обеих сетях, сами устройства из разных сетей будут обмениваться данными.
Некоторые из доступных видов передачи данных для 6LBR: умный мост, роутер и прозрачный мост. При работе в режиме прозрачного моста связь между сетями 6LoWPAN и Ethernet проходит на уровне пакетного фильтра.
Про сам граничный роутер написано тут.
Доступные режимы работы проекта 6LBR с описанием и схемами можно посмотреть тут.
К сожалению в статье ничего не увидел про реальную защиту IoT устройств на уровне железа.
Утверждения что в устройствах не хватает ресурсов на шифрацию безосновательны.
В недавно рассмотренном мной микроконтроллере для IoT скорость шифрования была около 50 Мегабайт в сек! Это превышает все мыслимые требования IoT.
Даже если взять менее мощные микроконтроллеры от ST на 100..200 МГц, то там будет 10-20 Мегабайт в сек скорость шифрования AES-256 GCM.
Это еще не начиная обсуждать такие технологии как TrustZone в совсем простых Cortex-M23..33
Все MQTT, AMQP, XMPP ... работают через TLS, поддерживают цепочки сертификатов, доверенные сервера и прочее.
Надеялся в статье будет от том как взламывают что-то вроде Mbed TLS
Если проверить слова автора о незащищенности протоколов, то они не подтверждаются сразу же первыми ссылками в поиске.
Вот, например, как сделана защита в ZigBee.
К сожалению в статье ничего не увидел про реальную защиту IoT устройств на уровне железа. Утверждения что в устройствах не хватает ресурсов на шифрацию безосновательны. В недавно рассмотренном мной микроконтроллере для IoT скорость шифрования была около 50 Мегабайт в сек! Это превышает все мыслимые требования IoT. Даже если взять менее мощные микроконтроллеры от ST на 100..200 МГц, то там будет 10-20 Мегабайт в сек скорость шифрования AES-256 GCM.
В приложенной статье рассматривается настоящий монстр с огромным количеством ресурсов. Для оконечных IoT продуктов (не контроллеров) используются куда более простые чипы, у которых ресурсов меньше на порядки.
Это еще не начиная обсуждать такие технологии как TrustZone в совсем простых Cortex-M23..33 Все MQTT, AMQP, XMPP ... работают через TLS, поддерживают цепочки сертификатов, доверенные сервера и прочее.
В статье не написано, что протоколы IoT не умеют в шифрование. Про AMQP, MQTT в статье отмечено, что шифрование возможно. Другой вопрос – защищённость в этих протоколах является опцией, которую используют далеко не все.
Надеялся в статье будет от том как взламывают что-то вроде Mbed TLS
Статья – обзор IoT в целом, регулирования, стандартов, протоколов, решений по ИБ IoT. Тема поиска уязвимостей в Mbed TLS, если бы мне было, что про это сказать, уместнее была бы в рамках более специализированной статьи.
Если проверить слова автора о незащищенности протоколов, то они не подтверждаются сразу же первыми ссылками в поиске. Вот, например, как сделана защита в ZigBee.
Как и в вопросе про шифрование IoT, не нашёл в статье слов про то, что ZigBee не защищён. Да, в документе по ссылке есть описание каких-то механизмов создания защищённой сети на основе ключей, сертификатов, но их использование – опция, а не требование, и дополнительная проблема в том, что дыры в них находят с завидной регулярностью. Причем есть там не только уязвимости реализации (кода), но и архитектурные уязвимости, которые так просто не закрыть.
Вопрос, почему бы тогда не написать про реальную информационную безопасность?
Вот про эти все шифрации и прочее. Про AWS IoT Greengrass или про Azure Sphere
Сейчас ни к одному крупному облаку не подключиться без шифрации.
“The S in IoT stands for security.”
Особых проблем с ресурсами, я бы сказал, нет. Многие современные микроконтроллеры имеют аппаратную или программную поддержку шифрования данных. И это никак не мешает им работать годами на одной батарейке. Также некоторые протоколы имеют шифрование по умолчанию, например LoRaWAN.
Что до статистики о 98% процентах назащищенного трафика, так может просто не шифруют потому, что нет смысла, например, шифровать температуру почвы в теплице? Или безопасность достигается другими средствами.
Насчет LPWAN вы пишете: "Идея основана на увеличении мощности сигнала для передачи 1 бита информации". Я бы сказал что речь идет не о увеличении мощности, а о простом повторении одного и того же символа огромное количество раз. Иначе при чем здесь скорость передачи?
А так статья, конечно, интересная, плюсую
К популярным протоколам верхнего (прикладного) уровня относятся MQTT и AMQP. Оба основаны на идее публикации-подписки.…
Другой популярный протокол, основанный на XML – XMPP. Его важный плюс – простой способ адресации в формате user@domain. То есть мы можем легко обратиться к любому пользователю в сети.
Аэээ, простите, что? XMPP это же полумертвый нынче джаббер, каким боком он к IoT?
К протоколам дальнего радиуса действия относится LPWAN, на основе которого строятся многие другие протоколы.
Идея основана на увеличении мощности сигнала для передачи 1 бита информации, за счет чего сильно увеличивается дальность связи, в ущерб скорости передачи данных.
LPWAN — это не стандарт, это тип сетей.
На LPWAN основано несколько других распространенных протоколов – это SigFox, LoRa и NB-IoT, которые будут описаны ниже.
"На легковых автомобилях основаны несколько распространных компаний — шкода, мерседес и другие". У всех трех перечисленных совершенно разный физический уровень (в случае сигфокса и лоры вообще кардинально отличаются подходы, одинакова только цель на покрытие больших расстояний)
LoRaWAN – наиболее известная реализация протокола LoRa. Он предназначен для управления связью между LPWAN-шлюзами и конечными устройствами.
LoRaWAN это не "реализация протокола LoRa". Хорошо уже что вы не пишите LoRaWAN как LoraOne (я встречал и такие перлы в статьях), но все еще статья довольно далеко от корректных описаний. LoRaWAN это протокол поверх LoRa, которая реализует физический уровень. LoRaWAN же это адресация, джойн в сеть, упаковка сообщений и так далее. Ничего не мешает взять LoRa и написать поверх нее свой протокол.
Существует ещё два протокола дальнего радиуса действия, тоже основанных на LPWAN. Это NB-IoT и NB-Fi.
Особенность этих протоколов в том, что можно не строить свою сеть, а использовать существующие сотовые сети с небольшой программной доработкой.
Для NB-IoT можно использовать новые БС мобильных операторов, для поделки NB-Fi — нет, для нее нужны свои БС, как и для лоры.
Кроме того, эти протоколы очень эффективны – например, устройство с NB-IoT может работать на одной небольшой батарейке более 10 лет.
С LoRa устройство тоже может работать на батарейке более 10 лет. И что? Да и на BLE устройство может работать столько же, вопрос в частоте передачи и скорости передачи(и времени в эфире, соответственно). В целом NB-IoT и LoRa примерно одинаково потребляют. NB-Fi тоже, но у него проблемы с обратным каналом (что хорошо бы указать в его минусах, потому что это довольно серьезный недостаток). И да, кстати, NB-Fi и протокол "стрижа" это одно и то же.
Статья — поделка копирайтера, не понимающего, о чем он пишет.
Информационная безопасность в IoT