Главная » Хабрахабр » Записки IoT-провайдера. Активация и безопасность в LoraWAN

Записки IoT-провайдера. Активация и безопасность в LoraWAN

Продолжение записок IoT-провайдера. Здравствуйте, уважаемые любители Интернета Вещей.

Первая часть > || > Вторая часть > || > Третья часть > || > Четвертая часть

Тут ходит много слухов и легенд. Сегодня пришло время поговорить о безопасности в LoRaWAN. Мы попытаемся разобраться как это работает и в чем риски.

Этот процесс в LoRaWAN называется активация. Чтобы вообще перейти к теме безопасности, придется сделать небольшую вводную и рассказать о первоначальной инициализации радимодуля в сети.

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

Итак, активация в LoRaWAN может производиться по воздуху (OTAA), либо по преднастройкам (ABP).

OTAA (Over-the-Air-Activation)

Его уникальный идентификатор (DevEUI), идентификатор сервера (AppEUI) и ключ сервера (AppKey). В случае активации по воздуху у нас на радиомодуле должны быть заданы три параметра.

Т.е. Со стороны сервера так же должны быть прописаны идентификатор радиомодуля, идентификатор сервера и ключ. Если мы знаем идентификаторы и ключи сервера, но наш DevEUI не прописан у него в базе, то соединения не состоится. сервер должен изначально знать то устройство, которое попробует к нему присоединиться.

Этим пакетом он спрашивает, есть ли поблизости сеть, которая его «узнает». При первоначальном включении радиомодуль отправляет в эфир пакет join_request на одной из трех заранее оговоренных join-частотах. Как видим, он содержит те самые DevEUI и AppEUI, а так же DevNonce. Ниже приведен состав пакета join_request.

Сервер какое-то время хранит ее в памяти и если придет join_request с таким же DevNonce, как один из предыдущих, сервер этот запрос проигнорирует. DevNonce – это случайная величина. Кстати, защитой от этой атаки могут похвастаться далеко не все стандарты IoT. Это сделано для защиты от атаки повторения, когда злоумышленник может записать запрос на активацию, а потом повторить его со своего устройства.

AppKey в этом сообщении напрямую не используется, но через него считается контрольная сумма MIC в конце кадра.
Этот ключ понадобится нам чуть дальше, в ответном сообщении сервера join_accept.

Join_request передается в незашифрованном виде.

Иначе ответа не последует.Если все проверки пройдены, то сервер генерирует ответное сообщение join_accept. Join_accept поступит в том случае, если серверу известны AppEUI и DevEUI, а так же нет совпадения по полю DevNonce и нет проблем с MIC. Его состав приведен на картинке ниже.

Эти ключи вместе с другой информацией шифруются AppKey и отправляются радиомодулю. По сути, генерируются два сессионных ключа – сетевого сервера (NwkSKey) и сервера приложений (AppSKey). NwkSKey и AppSKey уникальны для каждого отдельного радиомодуля. Далее весь обмен сообщениями происходит с двойным шифрованием сессионными ключами.

Каждый раз, когда пакет от радиомодуля будет приходить в нашу систему, он будет частично зашифрован для сетевого сервера и частично – для сервера приложений. Двойное шифрование используется для дополнительной защиты информации. сетевой сервер сможет расшифровать только те послания, что адресованы ему (различные служебные сообщения). Т.е. Нужно это за тем, что сетевой сервер с вероятностью 99 процентов будет стоять у провайдера. Сервер приложений увидит лишь полезную составляющую пакетов (собственно сами переправляемые данные). Двойное шифрование делает для провайдера затруднительным узнать содержание пакета. А вот сервер приложений вполне может разместиться у клиента.

Напомню, что изначально радиомодуль знает только три частоты, на которых он может работать. Помимо двух ключей, в join_accept по OTAA есть еще одна важная штука – расширенный список частот (CFList). После активации на него прописываются дополнительные частоты для выхода на связь.

Можно договориться, что у нас во всех сетях 3 частоты (+RX2) будут всегда совпадать, а остальные пять — на усмотрение провайдера. Это очень удобно, если точно не известно, в какой сети будет работать устройство.

Так же, на будущее, для работы с большим числом устройств CFList можно использовать для кластеризации

Допустим, наш радиомодуль знает три частоты F1, F2 и F3. Это когда вы делите сеть на кластера и внутри кластеров есть частотное планирование. Для кластера2 он получит совсем другие F4-2, F5-2, F6-2. Он производит активацию на одной из частот и если он в кластере1, то получает дополнительную таблицу частот в виде F4-1, F5-1 и F6-1. А в соседних кластерах резко снизится вероятность коллизий. При этом мы можем настроить все радиомодули одинаково и не очень задумываться какой из них в какой кластер попадет.

ABP (Activation by Personalization)

Удобно тем, что не надо производить активацию, радиомодуль сразу готов к работе. Упрощенная процедура, когда сессионные ключи сразу зашиваются в радиомодуль и изначально прописаны со стороны сервера. безопасность в этом случае так себе. Больше ничем не удобно, т.к. Случаев реального использования не встречал ни разу. Кроме того, нельзя подтянуть частоты с сервера. Рассматривать мы его не будем и все нижесказанное – это про OTAA.

И что же с безопасностью?

Итак, по сути у нас основная нагрузка по шифрованию ложится на сессионные ключи сетевого сервера и сервера приложений.

Рассмотрим их чуть внимательней.

Точнее, они могут и годами не меняться, пока не произойдет ре-активация устройства. Главная претензия критиков стандарта LoRaWAN заключается в том, что при активации устройства в сети у нас появляются два ключа, которые потом могут месяцами не меняться. Собственно, от установки до ухода в ноль батарейки.
Насколько надежны наши ключи? В нормальных условиях мы радиомодуль активировали и забыли, так что срок жизни ключа в три–четыре года вполне реальная перспектива.

Это алгоритм шифрования, более известный как AES-CMAC. Спецификация сообщает, что они соответствуют загадочному RFC4493.
Что это такое?

Она представлена на рисунке ниже. Давайте не полезем в дебри криптографии и ограничимся общим пониманием картины.

Каждый блок шифруется отдельно AES-ключом. Принцип AES-CMAC примерно такой: шифруемое сообщение разбивают на 128-битные блоки. А при шифровании третьего – результат второго и (косвенно) первого. Причем, при шифровании второго блока, помимо ключа, используется результат шифрования первого. Такая цепочка усложнений.

Насколько надежен этот принцип?

Алгоритм вышел больше десяти лет назад. Весьма надежен. Тогда есть шанс понять, что же внутри зашифрованных блоков. С тех пор на него провели множество различных атак и в конце-концов, в теории доказали, что его-таки можно взломать.Проблема в том, что для взлома понадобится большая выборка пакетов, несколько тысяч.

Давайте прикинем. Сможет ли злоумышленник с нужными знаниями получить данную выборку, если мы говорим про перехват пакетов LoRaWAN? За месяц от радиомодуля уйдет 720 пакетов. Пусть пакеты ходят раз в час. Маловато.

И то не факт, что он все же сможет взломать алгоритм и получить заветные ключи. Для реальной угрозы нам понадобится ооочень терпеливый злоумышленник, который будет месяцами писать пакеты. И еще вспомним, что передача пакетов раз в час – это ОЧЕНЬ часто. Не забудем, что такое терпение надо будет проявлять в отношении каждого радиомодуля отдельно. На практике промежутки куда больше – часов шесть, а то и сутки.

1, где реализованы команды ре-активации и join server. Но даже эта призрачная возможность сейчас закрыта после выхода спецификации 1. Пока напоминаю свою мысль из предыдущей статьи: когда стандарт открыт и у него есть сообщество, все его дыры видны. Про эту спецификацию еще как-нибудь поговорим. Во время апгрейда разработчики точно знают, на что смотреть в первую очередь.

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

Мы понимаем, что защиту можно усилить. LoRaWAN отвечает тому разумному соотношению цена-качество. Но это вычислительные мощности оконечки, это дополнительная нагрузка на батарейку, возможно увеличение размера пакетов или снижение полезной нагрузки.

По мне, так для задач телеметрии более чем.

Помните, что тема безопасности всегда требует обсуждения и никогда не должна упираться в мнение одного человека. В комментариях я буду рад услышать как своих оппонентов, так и сторонников.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Главные конференции по интернету вещей в 2018-2019. Россия и мир

Linux Foundation Open IoT Summit. Портленд, 2018 При этом мы ориентировались на рейтинги PTC University, Hewlett Packard Enterpise и Sam Solutions. В преддверии нашей пятой конференции «Интернет вещей» мы составили список наиболее масштабных мероприятий по IoT в России и в ...

Мобильная разработка. Swift: таинство протоколов

Сегодня мы продолжаем цикл публикаций на тему мобильной разработки под iOS. И если в прошлый раз речь шла о том, что нужно и не нужно спрашивать на собеседованиях, в этом материале мы коснемся тематики протоколов, которая имеет в Swift важное ...