Технология беспроводной передачи данных LoRa на российском рынке используется уже давно и перестала быть диковинкой. Свои сети развернули несколько десятков операторов, заявляются даже два федеральных игрока. Однако, у заказчиков LoRa до сих пор остаются сомнения в ее безопасности. В этой статье мы не будем касаться темы надежности передачи, а попробуем непредвзято рассмотреть вопрос информационной безопасность, причем не просто радиоканала LoRa как модуляции, а именно стандарта канального уровня LoRaWAN
Активация LoRaWAN
Итак, LoRa (Long Range) — это технология, разработанная французской компанией Semtech. Ориентирована она на передачу небольших объемов данных огромным числом устройств. Это важно: LoRaWAN не предназначена для передачи больших объемов данных от одного устройства. Более того, стандарт это прямо запрещает через специальный параметр — duty cycle, который определяет максимальное время нахождения оконечного устройства в эфире, оно равно одному проценту. Т.е. не более 1 процента времени в час устройство может быть в эфире. Отмечу также, что весь дальнейший рассказ пойдет про спецификацию версии 1.02-1.03, хотя самая свежая спецификация на сегодняшний день — 1.1, но она почти не внедрена на местах. Однако, особенности версии 1.1 я немного коснусь.
Для начала рассмотрим первоначальную регистрацию устройства в сети. В LoRaWAN этот процесс называется «активация». Для краткости я приведу ниже список необходимых нам терминов. Если немного запутаетесь – можете возвращаться сюда и сверяться. Возвращаться наверняка придется, т.к. аббревиатуры многих терминов очень похожи. Кроме того, в этом описании приведу аналогии, чтобы вы примерно понимали, с чем можно сравнить тот или иной термин. Точные аналогии подобрать не всегда возможно, потому прошу не судить эту колонку слишком строго. (см. рис. 1)
Рисунок 1. Расшифровка терминологии, используемой в LoRaWAN
Активация в LoRaWAN может производиться по воздуху (Over-the-Air-Activation или OTAA) или по преднастройкам оператора (Activation by Personalization — ABP).
По воздуху
В случае активации по воздуху у нас на радиомодуле должны быть заданы три параметра. Его уникальный идентификатор (DevEUI), идентификатор сервера (AppEUI) и ключ сервера (AppKey). Со стороны сервера так же должны быть получены следующие параметры: идентификатор радиомодуля, идентификатор сервера и ключ. Т.е. сервер должен изначально знать то устройство, которое попробует к нему присоединиться. Если мы знаем идентификаторы и ключи сервера, но наш DevEUI не будет внесен в его базу данных, то соединения не состоится. Сервер все равно будет «слушать» все устройства и будет принимать их пакеты, но не сможет расшифровать. И не будет отвечать таким устройствам.
При первоначальном включении радиомодуль отправляет в эфир пакет join_request с запросом на подключение на одной из трех заранее оговоренных частотах присоединения. Этим пакетом он запрашивает, есть ли поблизости сеть, которая его «узнает». Ниже приведен состав пакета join_request. Как видим, он содержит те самые DevEUI и AppEUI, а так же DevNonce. (см. рис. 2)
Рисунок 2. Формат запроса к серверу join_request
DevNonce – это случайная величина. Сервер хранит ее в памяти и если придет join_request с таким же DevNonce, как один из предыдущих, сервер этот запрос проигнорирует. Это сделано для защиты от атаки повторения, когда злоумышленник может записать запрос на активацию, а потом повторить его со своего устройства. Кстати, защитой от этой атаки могут похвастаться далеко не все стандарты IoT.
AppKey в этом сообщении напрямую не используется, но через него считывается контрольная сумма MIC в конце кадра. Этот ключ понадобится нам чуть дальше, в ответном сообщении сервера — join_accept. Причем запрос Join_request передается в незашифрованном виде.
Положительный ответ сервера (Join_accept) поступит в том случае, если серверу известны AppEUI и DevEUI, а так же нет совпадения по полю DevNonce и нет проблем с контрольной суммой MIC. Иначе ответа не последует. Если все проверки пройдены, то сервер генерирует ответное сообщение join_accept. Его состав приведен на картинке ниже. (см. рис. 3)
Рисунок 3. Формат положительного ответа сервера join_accept
Для взаимодействия с устройством сервер передает клиентскому оборудованию два сессионных ключа – сетевого взаимодействия с сервером (NwkSKey) и взаимодействия с приложением (AppSKey). Эти ключи вместе с другой информацией шифруются ключом шифрования сервера AppKey и отправляются радиомодулю. Далее все сообщения шифруются этим двумя сессионными ключами, что приводится в качестве аргумента защищенности LoRaWAN.
На самом деле ситуация с шифрованием несколько хитрее. Если в пакете есть данные для приложения и МАС-команды для сервера, то действительно шифрование выполняется двумя ключами. В случае пакета только с МАС-командами, которые не требует от сервера обращения к приложению, такой пакет ключом приложения уже не шифруется. В случае такого пакета с данными NwkSKey не принимает непосредственного участия в шифровании, но он участвует в подсчете контрольной суммы и влияет на ее результат. Следует отметить, что NwkSkey и AppSKey уникальны для каждого отдельного клиента сети LoRaWAN.
Два ключа используется для дополнительного уровня защиты, чтобы сервер мог расшифровать только те послания, что адресованы ему, то есть МАС-команды. Приложение в этом случае увидит лишь полезную составляющую пакетов — сами передаваемые данные. Нужно это для того, чтобы разделить уровни сети и приложения, поскольку сервер чаще всего будет стоять у провайдера, а вот приложение вполне может быть размещено у клиента. Двойное шифрование делает для провайдера затруднительным узнать содержание пакета, предназначенного для приложения.
Помимо двух ключей, в join_accept по OTAA есть еще одна важная информация – расширенный список частот (CFList). Напомню, что изначально радиомодуль знает только три частоты, на которых он может работать. После активации ему передаются дополнительные частоты для выхода на связь. Это очень удобно, если точно не известно, в какой сети будет работать устройство. Можно договориться, что у нас во всех сетях 3 частоты (+RX2) будут всегда совпадать, а остальные пять — на усмотрение провайдера. С расширением числа нелицензируемых частот в поддиапазоне 868 это вдвойне актуально.
Преднастроенные устройства
Чтобы не заниматься активацией по воздуху в LoRaWAN используется упрощенная процедура, когда сессионные ключи сразу зашиваются в радиомодуль и изначально прописаны со стороны провайдера. Удобно тем, что не надо производить активацию, радиомодуль сразу готов к работе. К сожалению, это оказывается не очень удобно для большой сети и в случае, когда устройства и сеть принадлежат различным компаниям. Кроме того, в этом случае нельзя менять частоты передачи динамически. Обычно такая процедура используют в тестовых сетях, когда заранее известно, что с сервером могут происходить метаморфозы. Так же отмечу, что режим ABP устойчивее к атаке клонирования, но плата за такую устойчивость слишком высока.
Криптоанализ
Итак, основная нагрузка по шифрованию ложится на сессионные ключи сетевого сервера и сервера приложений. Рассмотрим их чуть внимательней.
Главная претензия критиков стандарта LoRaWAN заключается в том, что при активации устройства в сети у нас появляются два ключа, которые потом могут месяцами не меняться. Точнее, они могут и годами не меняться, пока не произойдет ре-активация устройства. В нормальных условиях мы радиомодуль активировали и забыли, так что срок жизни ключа в три–четыре года вполне реальная перспектива. Собственно, от установки до исчерпания заряда батарейки.
Насколько надежны наши ключи? Спецификация сообщает, что они соответствуют загадочному RFC4493. Что это такое? Это алгоритм шифрования, более известный как AES-CMAC. Мы не будем глубоко погружаться в дебри криптографии и ограничимся общим пониманием картины. Она представлена на рисунке ниже. (См. Рис. 4)
Рисунок 4. Упрощенная схема шифрования по алгоритму AES-CMAC
Принцип AES-CMAC примерно такой: шифруемое сообщение разбивают на 128-битные блоки (M1, M2, … Mn). Каждый блок шифруется отдельно AES-ключом. Причем, при шифровании второго блока, помимо ключа, используется результат шифрования первого. А при шифровании третьего – результат второго и (косвенно) первого. Такая цепочка усложнений.
Насколько надежен этот принцип? Весьма надежен. Алгоритм вышел больше десяти лет назад. С тех пор на него провели множество различных атак и в конце-концов, в теории доказали, что его-таки можно взломать. Проблема в том, что для взлома понадобится большая выборка пакетов, несколько тысяч. Тогда есть шанс понять, что же внутри зашифрованных блоков.
Сможет ли злоумышленник с нужными знаниями получить данную выборку, если мы говорим про перехват пакетов LoRaWAN? Давайте прикинем. Пусть пакеты передаются раз в час. За месяц от радиомодуля уйдет 720 пакетов — этого маловато для взлома. Для реальной угрозы нам понадобится очень терпеливый злоумышленник, который будет месяцами писать пакеты. И то не факт, что он все же сможет взломать алгоритм чтобы получить заветные ключи. Не забудем, что такое терпение надо будет проявлять в отношении каждого клиентского устройства отдельно. А еще напомним, что передача пакетов раз в час – это ОЧЕНЬ часто. На практике промежутки куда больше – часов шесть, а то и раз в сутки.
Но даже эта призрачная возможность сейчас закрыта после выхода спецификации 1.1, где реализованы команды ре-активации и запроса join_server. Понятие «дырявости» — это вообще удел открытых стандартов. Когда есть огромное сообщество, которое под микроскопом изучает все уязвимости, то они находятся быстро. И в этом и преимущество открытого подхода. Когда будет очередная модернизация стандарта разработчики точно знают, на что смотреть в первую очередь. У проприетарных стандартов такой возможности нет и их внутренние проблемы либо остаются известны только в среде разработчиков, либо вообще находятся уже в процессе эксплуатации в самый неподходящий момент.
В итоге получаем, что угроза безопасности скорее иллюзорна. Где-то в глубокой теории взлом произвести можно, но на практике это практически не реально. Теперь помножим на ценность полученной информации. Станет ли наш злоумышленник месяцами писать пакеты, чтобы узнать показания счетчика? Маловероятно.
Возможен ли взлом?
Хорошо, расшифровать пакеты злоумышленнику будет проблематично. А как насчет возможности удаленно ввести в заблуждение сервер или организации атаки на отказ в обслуживании — DoS. Рассмотрим несколько наиболее популярных техник атаки на радио-сети.
Атака повторения
В случае атаки повторения злоумышленник записывает сообщение от устройства (без расшифровки) и позже передает его в эфире, «прикидываясь» устройством. Такая атака не будет успешной, поскольку в каждом пакете есть контрольная сумма, привязанная к счетчику пакетов, то есть следующий пакет даже с тем же содержимым должен иметь другую контрольную сумму.
DoS преамбулами
Преамбула — это часть сообщения, которая, условно говоря, «привлекает» внимание сервера. Что-то вроде «слушай, сейчас будет сообщение». Атака заключается в «забивании» эфира преамбулами, в результате которой сервер будет все время ждать какого-то сообщения и не получать его. Реальный пакет в такой ситуации может просто не пройти. Это классический SYN-flood, с которого начинались первые DoS-атаки на IP-сети. И вот тут, увы, LoRaWAN сдает позиции. Т.к. сервер прослушивает все пакеты в эфире, то он весьма чувствительно реагирует на такие атаки. Справедливости ради надо отметить, что такой «болезнью» страдает не только LoRaWAN, но практически все радио-протоколы.
Глушение
Передача в эфир мощной помехи на рабочих частотах — более просто способ DoS-атаки. Тут надо понимать, что заглушить можно любую радиосвязь. Вопрос соотношения мощностей передатчиков полезного сигнала и помехи. У LoRaWAN очень хорошие показатели работы в шумном эфире, технология может работать даже ниже уровня шума. Но физику никто не отменял и хорошая помеха, особенно рядом с базовой станцией или устройством, вызовет потерю пакетов.
Человек посередине
Еще более сложная атака, когда между сервером и устройством «вклинивается» злоумышленник. Он перехватывает пакеты от устройства, а на сервер отправляет уже измененную информацию. И наоборот. Для проведения такой атаки в рабочей сети нашему злоумышленнику придется знать сессионные ключи и идентификаторы устройства. Их еще надо раздобыть, возвращаемся к разговору выше. В теории, зная только идентификаторы можно попробовать вклиниться в момент активации. То есть ввести в заблуждение и сервер и клиентское устройство.
Но тут две проблемы. Первая — нужно точно знать момент активации, умудриться перехватить join-пакеты с обоих сторон и не дать им пройти по маршруту. Это непростая задача в условиях, когда устройства активируются в зоне действия легальной базовой станции. Да и персонал провайдера может заподозрить что-то неладное по косвенным признакам. Например, по уровню сигнала от устройства или явному несоответствию приходящих данных. Второй вариант добраться до устройства и произвести его переактивацию. Это уже более реальный вариант, и все равно внеочередные запросы на реактивацию могут насторожить инженеров провайдера. В общем, чисто технически осуществимо. Но требует высокой квалификации и хорошего оборудования, а также точного понимания логики работы не только технологии, но и инженеров провайдера.
Клонирование
Создание клона устройства — частный случай атаки человека посередине. В предыдущем случае мы вводим в заблуждение как сервер, так и оконечное устройство. В случае клонирования обманывать будем лишь сервер. Нужно устройство, со всеми теми же идентификаторами, что и легальный терминал. Кроме того, режим активации должен быть выбран OTAA. Проводим активацию клона, сервер считает, что у нас переактивировалось оригинальное устройство и обновляет сессионные ключи. Готово. Клон теперь воспринимается сервером и приложением как легальный источник данных, а настоящее устройство сервер перестает слушать, поскольку стирает его сессионные ключи. Старый терминал продолжает слать пакеты, но сервер их уже не воспринимает из-за устаревших сессионных ключей.
Тут есть две тонкости. Во-первых, нам нужно откуда-то взять набор идентификаторов легального устройства для клона. Во-вторых, некоторые производители добавляют в оконечные устройства оригинальную защиту, не предусмотренную спецификацией. Например, если терминал слишком долго не слышит ответов от сервера, то он запрашивает реактивацию. И вот тут сервер будет игнорировать уже сообщения клона.
Плюс — внимательность инженеров на сервере, которые должны заметить слишком частые запросы на реактивацию устройства. Клон может повести себя не так, как оригинальное устройство и это также должно вызвать подозрения.
К примеру, у нас есть специальная проверка на большой выборке данных: водосчетчик шлет данные, а мы записываем их в базу. В какой-то момент вклинился злоумышленник и начал нам отправлять заниженные показания. Если в момент «вклинивания» очередной пакет с показаниями от водосчетчика будет меньше, чем предыдущий, то сработает триггер. «Счетчик начал мотать назад». Генерируется аварийный акт и назначается разбирательство руками инженера, вплоть до выезда на место.
Не знаю как у других, но подозреваю, что не одни мы такие умные и большинство серверов крупных провайдеров также обложены проверками.
Заключение
Итог. Любой стандарт, любой канал связи можно взломать. Особенно беспроводной. Это всегда вопрос ресурсов и времени. Если вам говорят, что технология совершенна и никто не может ее взломать — не верьте. Либо кривят душой, либо сами не знают про какую-нибудь уязвимость. Другой вопрос, когда изначально ясно, какие ресурсы потребуются для взлома. Тогда мы сможем оценить стоит ли овчинка выделки. Обычное соотношение цена/качество, которое является основой для реальной информационной безопасности. Очевидно, что через LoRaWAN не будут передавать данные, которые могут заинтересовать ЦРУ или МОССАД — спецслужбы с большими финансовыми возмодностями. А месяцами слушать пакеты, чтобы узнать показания водосчетчика без гарантии успеха — это удел очень странного, подкованного и терпеливого злоумышленника. Такого еще поискать в наших широтах.
