Записки IoT-провайдера. Активация и безопасность в LoraWAN
Здравствуйте, уважаемые любители Интернета Вещей. Продолжение записок IoT-провайдера.
Первая часть > || > Вторая часть > || > Третья часть > || > Четвертая часть
Сегодня пришло время поговорить о безопасности в LoRaWAN. Тут ходит много слухов и легенд. Мы попытаемся разобраться как это работает и в чем риски.
Чтобы вообще перейти к теме безопасности, придется сделать небольшую вводную и рассказать о первоначальной инициализации радимодуля в сети. Этот процесс в LoRaWAN называется активация.
Для краткости я приведу ниже список необходимых нам терминов. Если немного запутаетесь — можете возвращаться сюда и сверяться. Возвращаться наверняка придется, т.к. аббревиатуры многих терминов очень похожи. Кроме того, в этом описании приведу аналогии, чтобы вы примерно понимали, с чем можно сравнить тот или иной термин. Точные аналогии подобрать не всегда возможно, потому прошу не судить эту колонку слишком строго.
Итак, активация в LoRaWAN может производиться по воздуху (OTAA), либо по преднастройкам (ABP).
OTAA (Over-the-Air-Activation)
В случае активации по воздуху у нас на радиомодуле должны быть заданы три параметра. Его уникальный идентификатор (DevEUI), идентификатор сервера (AppEUI) и ключ сервера (AppKey).
Со стороны сервера так же должны быть прописаны идентификатор радиомодуля, идентификатор сервера и ключ. Т.е. сервер должен изначально знать то устройство, которое попробует к нему присоединиться. Если мы знаем идентификаторы и ключи сервера, но наш DevEUI не прописан у него в базе, то соединения не состоится.
При первоначальном включении радиомодуль отправляет в эфир пакет join_request на одной из трех заранее оговоренных join-частотах. Этим пакетом он спрашивает, есть ли поблизости сеть, которая его «узнает». Ниже приведен состав пакета join_request. Как видим, он содержит те самые DevEUI и AppEUI, а так же DevNonce.
DevNonce — это случайная величина. Сервер какое-то время хранит ее в памяти и если придет join_request с таким же DevNonce, как один из предыдущих, сервер этот запрос проигнорирует. Это сделано для защиты от атаки повторения, когда злоумышленник может записать запрос на активацию, а потом повторить его со своего устройства. Кстати, защитой от этой атаки могут похвастаться далеко не все стандарты IoT.
AppKey в этом сообщении напрямую не используется, но через него считается контрольная сумма MIC в конце кадра.
Этот ключ понадобится нам чуть дальше, в ответном сообщении сервера join_accept.
Join_request передается в незашифрованном виде.
Join_accept поступит в том случае, если серверу известны AppEUI и DevEUI, а так же нет совпадения по полю DevNonce и нет проблем с MIC. Иначе ответа не последует.Если все проверки пройдены, то сервер генерирует ответное сообщение join_accept. Его состав приведен на картинке ниже.
По сути, генерируются два сессионных ключа — сетевого сервера (NwkSKey) и сервера приложений (AppSKey). Эти ключи вместе с другой информацией шифруются AppKey и отправляются радиомодулю. Далее весь обмен сообщениями происходит с двойным шифрованием сессионными ключами. NwkSKey и AppSKey уникальны для каждого отдельного радиомодуля.
Двойное шифрование используется для дополнительной защиты информации. Каждый раз, когда пакет от радиомодуля будет приходить в нашу систему, он будет частично зашифрован для сетевого сервера и частично — для сервера приложений. Т.е. сетевой сервер сможет расшифровать только те послания, что адресованы ему (различные служебные сообщения). Сервер приложений увидит лишь полезную составляющую пакетов (собственно сами переправляемые данные). Нужно это за тем, что сетевой сервер с вероятностью 99 процентов будет стоять у провайдера. А вот сервер приложений вполне может разместиться у клиента. Двойное шифрование делает для провайдера затруднительным узнать содержание пакета.
Помимо двух ключей, в join_accept по OTAA есть еще одна важная штука — расширенный список частот (CFList). Напомню, что изначально радиомодуль знает только три частоты, на которых он может работать. После активации на него прописываются дополнительные частоты для выхода на связь.
Это очень удобно, если точно не известно, в какой сети будет работать устройство. Можно договориться, что у нас во всех сетях 3 частоты (+RX2) будут всегда совпадать, а остальные пять — на усмотрение провайдера.
Так же, на будущее, для работы с большим числом устройств CFList можно использовать для кластеризации
Это когда вы делите сеть на кластера и внутри кластеров есть частотное планирование. Допустим, наш радиомодуль знает три частоты F1, F2 и F3. Он производит активацию на одной из частот и если он в кластере1, то получает дополнительную таблицу частот в виде F4–1, F5–1 и F6–1. Для кластера2 он получит совсем другие F4–2, F5–2, F6–2. При этом мы можем настроить все радиомодули одинаково и не очень задумываться какой из них в какой кластер попадет. А в соседних кластерах резко снизится вероятность коллизий.
ABP (Activation by Personalization)
Упрощенная процедура, когда сессионные ключи сразу зашиваются в радиомодуль и изначально прописаны со стороны сервера. Удобно тем, что не надо производить активацию, радиомодуль сразу готов к работе. Больше ничем не удобно, т.к. безопасность в этом случае так себе. Кроме того, нельзя подтянуть частоты с сервера. Случаев реального использования не встречал ни разу. Рассматривать мы его не будем и все нижесказанное — это про OTAA.
И что же с безопасностью?
Итак, по сути у нас основная нагрузка по шифрованию ложится на сессионные ключи сетевого сервера и сервера приложений.
Рассмотрим их чуть внимательней.
Главная претензия критиков стандарта LoRaWAN заключается в том, что при активации устройства в сети у нас появляются два ключа, которые потом могут месяцами не меняться. Точнее, они могут и годами не меняться, пока не произойдет ре-активация устройства. В нормальных условиях мы радиомодуль активировали и забыли, так что срок жизни ключа в три–четыре года вполне реальная перспектива. Собственно, от установки до ухода в ноль батарейки.
Насколько надежны наши ключи?
Спецификация сообщает, что они соответствуют загадочному RFC4493.
Что это такое? Это алгоритм шифрования, более известный как AES-CMAC.
Давайте не полезем в дебри криптографии и ограничимся общим пониманием картины. Она представлена на рисунке ниже.
Принцип AES-CMAC примерно такой: шифруемое сообщение разбивают на 128-битные блоки. Каждый блок шифруется отдельно AES-ключом. Причем, при шифровании второго блока, помимо ключа, используется результат шифрования первого. А при шифровании третьего — результат второго и (косвенно) первого. Такая цепочка усложнений.
Насколько надежен этот принцип?
Весьма надежен. Алгоритм вышел больше десяти лет назад. С тех пор на него провели множество различных атак и в конце-концов, в теории доказали, что его-таки можно взломать.Проблема в том, что для взлома понадобится большая выборка пакетов, несколько тысяч. Тогда есть шанс понять, что же внутри зашифрованных блоков.
Сможет ли злоумышленник с нужными знаниями получить данную выборку, если мы говорим про перехват пакетов LoRaWAN? Давайте прикинем. Пусть пакеты ходят раз в час. За месяц от радиомодуля уйдет 720 пакетов. Маловато.
Для реальной угрозы нам понадобится ооочень терпеливый злоумышленник, который будет месяцами писать пакеты. И то не факт, что он все же сможет взломать алгоритм и получить заветные ключи. Не забудем, что такое терпение надо будет проявлять в отношении каждого радиомодуля отдельно. И еще вспомним, что передача пакетов раз в час — это ОЧЕНЬ часто. На практике промежутки куда больше — часов шесть, а то и сутки.
Но даже эта призрачная возможность сейчас закрыта после выхода спецификации 1.1, где реализованы команды ре-активации и join server. Про эту спецификацию еще как-нибудь поговорим. Пока напоминаю свою мысль из предыдущей статьи: когда стандарт открыт и у него есть сообщество, все его дыры видны. Во время апгрейда разработчики точно знают, на что смотреть в первую очередь.
В итоге получаем, что угроза безопасности скорее иллюзорна. Где-то в глубокой теории взлом произвести можно, но на практике это практически не реально. Теперь помножим на ценность полученной информации. Станет ли наш злоумышленник месяцами писать пакеты, чтобы узнать показания счетчика? Маловероятно.
LoRaWAN отвечает тому разумному соотношению цена-качество. Мы понимаем, что защиту можно усилить. Но это вычислительные мощности оконечки, это дополнительная нагрузка на батарейку, возможно увеличение размера пакетов или снижение полезной нагрузки.
По мне, так для задач телеметрии более чем.
В комментариях я буду рад услышать как своих оппонентов, так и сторонников. Помните, что тема безопасности всегда требует обсуждения и никогда не должна упираться в мнение одного человека.
