Здравствуйте, уважаемые любители Интернета Вещей. Продолжение записок 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 отвечает тому разумному соотношению цена-качество. Мы понимаем, что защиту можно усилить. Но это вычислительные мощности оконечки, это дополнительная нагрузка на батарейку, возможно увеличение размера пакетов или снижение полезной нагрузки.
По мне, так для задач телеметрии более чем.
В комментариях я буду рад услышать как своих оппонентов, так и сторонников. Помните, что тема безопасности всегда требует обсуждения и никогда не должна упираться в мнение одного человека.
Комментарии (30)
Imbecile
04.06.2018 15:12Не совсем понятно, если join request передаётся в открытом виде, то что может помешать заменить dev nonce и послать ещё раз пакет на присоединение?
Viknet
04.06.2018 15:22+1В пакете JoinRequest есть MIC, который вычисляется на основе ключа AppKey, зашитого в устройство.
Interfer Автор
04.06.2018 15:34Абсолютно верно!
Imbecile
04.06.2018 15:58То есть, надо вытащить из устройства app key, и только после этого подменять запрос. А в устройстве он тоже явно не сильно в открытом виде хранится. Всё встало на свои места. Спасибо.
Interfer Автор
04.06.2018 17:16Вы уже хотите попробовать сломать?)
Imbecile
04.06.2018 17:27+1Нет. Я пока слишком далёк от LoRaWAN и всего, что с этим связано. Хотя не исключено, что придётся этим заняться в обозримом будущем. А тут спрашиваю-рассуждаю скорее потому, что было приглашение к дискуссии. И мне показалось, что некоторые моменты не раскрыты. Понятно, что всё можно найти в спецификации протокола. Но зачем тогда писать статьи?
Короче, поддерживаю беседу, как могу.Interfer Автор
04.06.2018 17:33Правильно делаете)
На самом деле, раскрыть все в одной статье проблематично. И получится уж слишком заумно. Я обозначил основные моменты, связанные с безопасностью, как работает это процесс и очевидные бреши. Здесь можем погрузиться поглубже.
Imbecile
05.06.2018 08:45А есть ли какая-то защита на БС от дублирующих регистраций оконечки?
Допустим, на одной БС регистрируется настоящее устройство. На второй БС регистрируется фейковое, которое копирует запросы настоящего.
БС между собой как-то общаются? Или это уже дальше, на уровне приложения решают конфликты?Viknet
05.06.2018 08:49Вся работа по регистрации происходит на Network Server. Базовые станции тупые и просто принимают и отправляют байтики в эфир. Во второй части была картинка архитектуры LoRaWAN сети.
Interfer Автор
05.06.2018 08:53Вы несколько неверно понимаете роль БС. БС в этой архитектуре — тупая железка, которая просто преобразует радиотраффик в ethernet (или СС) и гонит на сервер.
Всем рулит сервер. Это можно сравнить с неуправляемым коммутатором. Не важно в какой порт льете траффик, важно что стоит дальше.
Насчет активации. Если произошла активация одного устройства, а потом активировался кто-то еще, с такими же параметрами, то первое устройство превратиться в кирпич. Т.е. сервер у себя поменяет сессионные ключи и будет общаться с фейком, а реальное устройство уже не сможет с ним связаться. Однако, если сделать реактивацию реального устройства, то в кирпич превратится уже фейк. И так далее.
Как и в большинстве систем, если вы знаете пароли от входа, то сможете создать проблемы. Потому пароли надо беречь)
Serge78rus
Не в пику LoRaWAN или, тем более AES, но если уж речь зашла о криптографии, то аргументы, подобные
нельзя считать приемлемыми.vassabi
интересно, что делает устройство, если навести помеху — пытается ли прислать новый (т.е. можно заставить слать пакеты чаще «раза в час») или спит?
Serge78rus
Цитата из первой статьи серии
т.е., в зависимости от настроек, может как требоваться подтверждение приема, так и нет. Если требуется, то, очевидно, при отсутствии подтверждения будет некоторое количество попыток повторной передачи. Только, если повторный пакет будет точной копией предыдущего, то это ни чего не даст в плане взлома.Interfer Автор
Можно выставить отправку пакетов с подтверждением и без.
И число попыток на отправку.
Допустим, у нас есть пять попыток и подтверждение.
Радиомодуль просыпается и выходит в эфир на случайной частоте. Пересылает пакет. Ждет ответа от сервера. Если ответа нет, ждет его во втором приемном окне.
Если все равно тишина, то повторяет попытку на другой частоте.
Если быть чуть точнее, то он просто повторяет попытку на случайной частоте. Учитывая, что частот всего шесть, может оказаться, что вторая попытка будет на той же самой. Но третья уж точно на другой.
И так — пока не получит подтверждение или число попыток не кончится.
Serge78rus
То есть, базовая станция имеет на борту шесть постоянно работающих приемных тракта, каждый непрерывно слушающий в своей полосе?
Interfer Автор
Нет. Базовая станция слушает широкую полосу частот. Порядка 7 МГц.
Каналы она использует только при связи с устройством.
Serge78rus
А на каком частотном канале следует посылать ответ она определяет из содержимого принятой посылки или имеет какие-то средства анализа частоты, на которой получен запрос?
Interfer Автор
Точно сейчас не вспомню. Надо спецификацию глянуть. Вообще правило отвечать радиомодулю на частоте обращения или на RX2.
Viknet
Точная частота приёма пакета определяется базовой станцией, далее сервер сопоставляет частоту с uplink каналом и по алгоритму, зависящему от региона, вычисляет downlink канал и выставляет нужную частоту отправки.
Interfer Автор
Да, могу ошибаться. Надо чуть глубже вгрызть схемотехнику.
Serge78rus
В рассматриваемой системе очень критичны энергетические показатели канала связи (достаточно посмотреть на карту во второй части статьи — с какими уровнями приема Вам приходится иметь дело). То есть отношение сигнал/шум в приемнике имеет решающее значение. В то же время Вы осознанно расширяете полосу приема базовой станции шире полосы полезного сигнала передатчика, тем самым ухудшая соотношение сигнал/шум. На первый взгляд это кажется не логичным. Наверное, я что то упустил, но не могу понять — что именно.
Interfer Автор
Если вы про цифру в 7 МГц, то беда тут в нелицензируемом спектре. Смотрите, у нас первая граница — это 864 МГц (начало спектра), вторая — 869, 2 (конец). Если бы у нас свободные частоты шли одна за другой, то мы бы выставили себе 2 МГц и не заморачивались. Но раз уж все так, мы ловим широким сачком с большим запасом по краям.
Можно, конечно, поставить две БС или внутри БС сделать два приемника. Однако, это увеличивает стоимость и пока избыточно.
Я думаю, что эволюция Лоры нас все же приведет нас к двум БС в одном корпусе.
Serge78rus
Спасибо, теперь у меня в мозгах прояснилось.
Viknet
Мне кажется, вы здесь заблуждаетесь. Если взять базовую станцию на чипе SX1301 с фронтендами SX1257, то каждый фронтенд не может покрыть полосу больше 800 кГц, т.е. суммарная максимальная полоса 1.6 МГц.
Interfer Автор
Глянул глобал конфиг. Да, вы правы, с 7 МГц я загнул. У нас на борту два SX1257 и каждый слушает по 800 кГц.
Соответственно, каждый — на свой поддиапазон. К примеру, центральная частота примерно посередине 864-865 и от нее отступы по 200 и 400 кГц в каждую сторону.
Получается, 5 каналов в 864-865. В результате, если всю полосу брать. там немного больше получается, но по центральным частотам так.
Interfer Автор
Не забывайте, что мы ограничены в вычисдительной мощности оконечки. И мы не гостайну передаем. Нам все равно придется искать определенный компромисс.
Ну и если уж на то пошло — не разу не слышал о подобных взломах. Есть некая теоретическая, посчитанная математически, вероятность. Как только будет первый реальный пример — можно будет разговаривать. Однако, к тому времени, как это случится уж заработает спецификация 1.1.
Serge78rus
Я критиковал вовсе не криптостойкость LoRaWAN, я недостаточно компетентен в области криптографии, чтобы выносить суждения, пусть этим занимаются профессиональные криптоаналитики, а Вашу аргументацию. В криптографии недопустимы предположения: «это никому не нужно, поэтому взламывать никто не будет». Если разговор зашел о криптостойкости, то априори предполагается, что ломать будут и, причем, самыми разными способами, порой весьма не очевидными. И ценность зашифрованной информации не имеет никакого значения. Но, еще раз повторюсь, криптография — очень специфическая область, и пусть ею занимаются профессионалы.
Interfer Автор
Я согласен, что аргументация может быть недостаточно серьезной. Но мир в принципе не терпит абсолютов.
Скажем, есть задача купить новую машину и у вас есть только 700 000 рублей. Конечно, нужно, чтобы она была максимально безопасной. Но вы не купите за эти деньги новую Вольво в максималке, со всеми подушками и электронными наворотами, вроде остановиться перед препятствием. Такая машина стоит раза в четыре дороже.
Итог, у вас два варианта: либо вообще остаться без машины, либо подобрать ту, что будет наиболее безопасной в классе.
Кроме того, я подчеркиваю, что реальность взлома пока есть только в теории. На практике я не слышал, чтобы кто-то смог это сделать. И все равно эту проблему уже решили, еще до того. как она стала проблемой. После внедрения 1.1 даже в теории взломать уже не получится.
Serge78rus
В примере с машинами Вы не упомянули еще один вполне рабочий вариант — купить подержанную. А если вернуться более близко к обсуждаемой теме, то машина ниже определенной стоимости не сможет получить необходимых сертификатов безопасности и не будет допущена для эксплуатации на дорогах общего пользования, т.е. в принципе не сможет считаться транспортным средством в общепринятой терминологии. Так же и с криптостойкостью: либо она не имеет известных уязвимостей и определяется только временем подбора ключа, которое неприемлемо велико для злоумышленника, либо ее как бы и нет вообще.
Еще раз подчеркну, что я вовсе не придираюсь к безопасности LoRaWAN.
Interfer Автор
Я специально упомянул про новизну, т.к. покупать б.у. в этой сфере проблематично, поскольку нет еще нормального б.у. А что есть — все очень так себе.
Насчет безопасности же пишу все, как есть. Да, в 1.0 есть проблемы и скрывать их глупо. Но дальше будет легче)