Записки 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 не принимает участия в шифровании пакетов только с данными (без команд), но через него считается контрольная сумма.
    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 отвечает тому разумному соотношению цена-качество. Мы понимаем, что защиту можно усилить. Но это вычислительные мощности оконечки, это дополнительная нагрузка на батарейку, возможно увеличение размера пакетов или снижение полезной нагрузки.

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


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

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 37
      +1
      Не в пику LoRaWAN или, тем более AES, но если уж речь зашла о криптографии, то аргументы, подобные
      Станет ли наш злоумышленник месяцами писать пакеты, чтобы узнать показания счетчика? Маловероятно.
      нельзя считать приемлемыми.
        0
        интересно, что делает устройство, если навести помеху — пытается ли прислать новый (т.е. можно заставить слать пакеты чаще «раза в час») или спит?
          0
          Цитата из первой статьи серии
          В А-классе вообще: проснулось, отправило пакет, получило подтверждение (если предусмотрено) и уснуло дальше
          т.е., в зависимости от настроек, может как требоваться подтверждение приема, так и нет. Если требуется, то, очевидно, при отсутствии подтверждения будет некоторое количество попыток повторной передачи. Только, если повторный пакет будет точной копией предыдущего, то это ни чего не даст в плане взлома.
            0
            Можно выставить отправку пакетов с подтверждением и без.
            И число попыток на отправку.
            Допустим, у нас есть пять попыток и подтверждение.
            Радиомодуль просыпается и выходит в эфир на случайной частоте. Пересылает пакет. Ждет ответа от сервера. Если ответа нет, ждет его во втором приемном окне.
            Если все равно тишина, то повторяет попытку на другой частоте.

            Если быть чуть точнее, то он просто повторяет попытку на случайной частоте. Учитывая, что частот всего шесть, может оказаться, что вторая попытка будет на той же самой. Но третья уж точно на другой.
            И так — пока не получит подтверждение или число попыток не кончится.
              0
              То есть, базовая станция имеет на борту шесть постоянно работающих приемных тракта, каждый непрерывно слушающий в своей полосе?
                0
                Нет. Базовая станция слушает широкую полосу частот. Порядка 7 МГц.
                Каналы она использует только при связи с устройством.
                  0
                  А на каком частотном канале следует посылать ответ она определяет из содержимого принятой посылки или имеет какие-то средства анализа частоты, на которой получен запрос?
                    0
                    Точно сейчас не вспомню. Надо спецификацию глянуть. Вообще правило отвечать радиомодулю на частоте обращения или на RX2.
                      +1
                      Точная частота приёма пакета определяется базовой станцией, далее сервер сопоставляет частоту с uplink каналом и по алгоритму, зависящему от региона, вычисляет downlink канал и выставляет нужную частоту отправки.
                        0
                        Да, могу ошибаться. Надо чуть глубже вгрызть схемотехнику.
                      0
                      В рассматриваемой системе очень критичны энергетические показатели канала связи (достаточно посмотреть на карту во второй части статьи — с какими уровнями приема Вам приходится иметь дело). То есть отношение сигнал/шум в приемнике имеет решающее значение. В то же время Вы осознанно расширяете полосу приема базовой станции шире полосы полезного сигнала передатчика, тем самым ухудшая соотношение сигнал/шум. На первый взгляд это кажется не логичным. Наверное, я что то упустил, но не могу понять — что именно.
                        0
                        Если вы про цифру в 7 МГц, то беда тут в нелицензируемом спектре. Смотрите, у нас первая граница — это 864 МГц (начало спектра), вторая — 869, 2 (конец). Если бы у нас свободные частоты шли одна за другой, то мы бы выставили себе 2 МГц и не заморачивались. Но раз уж все так, мы ловим широким сачком с большим запасом по краям.

                        Можно, конечно, поставить две БС или внутри БС сделать два приемника. Однако, это увеличивает стоимость и пока избыточно.

                        Я думаю, что эволюция Лоры нас все же приведет нас к двум БС в одном корпусе.
                          0
                          Спасибо, теперь у меня в мозгах прояснилось.
                            0
                            Насколько помню, типовая схема БС (применяемая как минимум Multitech и в платах iC880a) включает в себя 2 трансивера sx127*, которые работают в относительно узких диапазонах. Собственно, при настройке packet forwarder'а базовые частоты для этих трансиверов и указываются в секциях «radio_0» и «radio_1».
                              0
                              В целом верно. Я выше уже писал. Это указывается в глобал конфиге БС
                          0
                          Мне кажется, вы здесь заблуждаетесь. Если взять базовую станцию на чипе SX1301 с фронтендами SX1257, то каждый фронтенд не может покрыть полосу больше 800 кГц, т.е. суммарная максимальная полоса 1.6 МГц.
                            0
                            Глянул глобал конфиг. Да, вы правы, с 7 МГц я загнул. У нас на борту два SX1257 и каждый слушает по 800 кГц.
                            Соответственно, каждый — на свой поддиапазон. К примеру, центральная частота примерно посередине 864-865 и от нее отступы по 200 и 400 кГц в каждую сторону.
                            Получается, 5 каналов в 864-865. В результате, если всю полосу брать. там немного больше получается, но по центральным частотам так.
                  0
                  Не забывайте, что мы ограничены в вычисдительной мощности оконечки. И мы не гостайну передаем. Нам все равно придется искать определенный компромисс.
                  Ну и если уж на то пошло — не разу не слышал о подобных взломах. Есть некая теоретическая, посчитанная математически, вероятность. Как только будет первый реальный пример — можно будет разговаривать. Однако, к тому времени, как это случится уж заработает спецификация 1.1.
                    0
                    Я критиковал вовсе не криптостойкость LoRaWAN, я недостаточно компетентен в области криптографии, чтобы выносить суждения, пусть этим занимаются профессиональные криптоаналитики, а Вашу аргументацию. В криптографии недопустимы предположения: «это никому не нужно, поэтому взламывать никто не будет». Если разговор зашел о криптостойкости, то априори предполагается, что ломать будут и, причем, самыми разными способами, порой весьма не очевидными. И ценность зашифрованной информации не имеет никакого значения. Но, еще раз повторюсь, криптография — очень специфическая область, и пусть ею занимаются профессионалы.
                      0
                      Я согласен, что аргументация может быть недостаточно серьезной. Но мир в принципе не терпит абсолютов.
                      Скажем, есть задача купить новую машину и у вас есть только 700 000 рублей. Конечно, нужно, чтобы она была максимально безопасной. Но вы не купите за эти деньги новую Вольво в максималке, со всеми подушками и электронными наворотами, вроде остановиться перед препятствием. Такая машина стоит раза в четыре дороже.

                      Итог, у вас два варианта: либо вообще остаться без машины, либо подобрать ту, что будет наиболее безопасной в классе.

                      Кроме того, я подчеркиваю, что реальность взлома пока есть только в теории. На практике я не слышал, чтобы кто-то смог это сделать. И все равно эту проблему уже решили, еще до того. как она стала проблемой. После внедрения 1.1 даже в теории взломать уже не получится.
                        0
                        В примере с машинами Вы не упомянули еще один вполне рабочий вариант — купить подержанную. А если вернуться более близко к обсуждаемой теме, то машина ниже определенной стоимости не сможет получить необходимых сертификатов безопасности и не будет допущена для эксплуатации на дорогах общего пользования, т.е. в принципе не сможет считаться транспортным средством в общепринятой терминологии. Так же и с криптостойкостью: либо она не имеет известных уязвимостей и определяется только временем подбора ключа, которое неприемлемо велико для злоумышленника, либо ее как бы и нет вообще.
                        Еще раз подчеркну, что я вовсе не придираюсь к безопасности LoRaWAN.
                          0
                          Я специально упомянул про новизну, т.к. покупать б.у. в этой сфере проблематично, поскольку нет еще нормального б.у. А что есть — все очень так себе.

                          Насчет безопасности же пишу все, как есть. Да, в 1.0 есть проблемы и скрывать их глупо. Но дальше будет легче)
                  0
                  Не совсем понятно, если join request передаётся в открытом виде, то что может помешать заменить dev nonce и послать ещё раз пакет на присоединение?
                    +1
                    В пакете JoinRequest есть MIC, который вычисляется на основе ключа AppKey, зашитого в устройство.
                      0
                      Абсолютно верно!
                        0
                        То есть, надо вытащить из устройства app key, и только после этого подменять запрос. А в устройстве он тоже явно не сильно в открытом виде хранится. Всё встало на свои места. Спасибо.
                          0
                          Вы уже хотите попробовать сломать?)
                            +1
                            Нет. Я пока слишком далёк от LoRaWAN и всего, что с этим связано. Хотя не исключено, что придётся этим заняться в обозримом будущем. А тут спрашиваю-рассуждаю скорее потому, что было приглашение к дискуссии. И мне показалось, что некоторые моменты не раскрыты. Понятно, что всё можно найти в спецификации протокола. Но зачем тогда писать статьи?
                            Короче, поддерживаю беседу, как могу.
                              0
                              Правильно делаете)
                              На самом деле, раскрыть все в одной статье проблематично. И получится уж слишком заумно. Я обозначил основные моменты, связанные с безопасностью, как работает это процесс и очевидные бреши. Здесь можем погрузиться поглубже.
                        0
                        А есть ли какая-то защита на БС от дублирующих регистраций оконечки?
                        Допустим, на одной БС регистрируется настоящее устройство. На второй БС регистрируется фейковое, которое копирует запросы настоящего.
                        БС между собой как-то общаются? Или это уже дальше, на уровне приложения решают конфликты?
                          0
                          Вся работа по регистрации происходит на Network Server. Базовые станции тупые и просто принимают и отправляют байтики в эфир. Во второй части была картинка архитектуры LoRaWAN сети.
                            0
                            Вы несколько неверно понимаете роль БС. БС в этой архитектуре — тупая железка, которая просто преобразует радиотраффик в ethernet (или СС) и гонит на сервер.
                            Всем рулит сервер. Это можно сравнить с неуправляемым коммутатором. Не важно в какой порт льете траффик, важно что стоит дальше.

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

                            Как и в большинстве систем, если вы знаете пароли от входа, то сможете создать проблемы. Потому пароли надо беречь)
                              0
                              Не совсем: насколько я понимаю, имелась в виду попытка регистрации на сетевом сервере воспроизведением прослушанного и записанного join-request настоящего устройства.
                              В этом случае все параметры (AppEUI, DevEUI, DevNonce и MIC), конечно, будут корректными, так как являются точной копией настоящего запроса join-request.
                              Но сетевой сервер хранит «некоторое» количество ранее полученных DevNonce для каждого устройства и повторное обращение с тем же DevNonce игнорирует. Поэтому простое воспроизведение пакета присоединения (и далее) не даст подключиться к сети (например. отключив первое настоящее устройство).
                                0
                                Не совсем. Я имел ввиду ситуацию, когда злоумышленник откуда-то знает наши DevEUI, AppEUI и AppKey. Тогда он сможет сгенерить настоящий запрос. DevNonce и MIC будут отличаться, т.к. он не знает прошлый DevNonce. Сервер примет такой запрос за переактивацию, выдаст нашему клону новые ключи, а по старым отвечать уже не будет. И наше устройство превратиться в кирпич. Если мы его реактивируем, то кирпичом станет клон. И так далее.
                                  0
                                  Действительно, задача «на второй БС регистрируется фейковое, которое копирует запросы настоящего» может описывать и такую ситуацию.

                                  В этом случае «клон» фактически будет уже не фейковым устройством, так как обладает всей информацией, что и исходное. Но считыванием эфира или копированием считанных запросов эти параметры не получить (по крайней без взлома криптографии).

                                  Видимо, полный ответ на исходный вопрос должен звучать так: БС выступают только передатчиками, регистрацию в одной сети (и дальнейшее общение с кодированием) осуществляет один сетевой сервер. То есть нет нескольких «точек регистрации», которые могли бы зарегистрировать по копиям корректного запроса разные устройства.

                                  Противодействие повторной передаче записанного запроса серверу также предусмотрено.

                                  Если же изготовлена точная копия-злоумышленник устройства (знающая все его параметры, в том числе секретный ключ), то они с оригиналом будут бороться, отключая друг друга.

                                  Но тут вопрос уже у меня: а если подключаться таким образом к разным сетевым серверам (то есть к серверам разных провайдеров, работающих с одним приложением) конфликта не возникнет? То есть может ли определить сервер приложений от какого из сетевых серверов запрос действительно настоящий (например, ему также транслируется и DevNonce)?
                                    0
                                    Интересный вопрос! Я никогда не видел архитектуры «два сетевых сервера — один приложений». Наоборот бывает, а вот так… не уверен, что это вообще возможно.
                                    Но конфликта возникнуть не должно. Для определенного DevEUI будет только один действующий сессионный ключ сервера приложений. Уж будет о наш или злоумышленника — вопрос десятый. Важно, что сервер приложений будет работать с тем, кого понимает.
                                      0
                                      Видимо, теоретически возможно и заложено в идею: в спецификации много рассуждений о роуминге (переходе конечного устройства между сетями) и ограничений параметров для его обеспечения.
                                      Например, это может быть разумно если для ПО какой-то системы учета аналогичное оборудование развернуто на производствах в разных регионах и использовать один сервер неудобно. Или если устройство, работающее с приложением, установлено на транспорте, едущем из региона в регион — с разными провайдерами.

                                      По итогу размышлений (насколько я понимаю эту систему): в любом случае секретный ключ шифрования AppKey «клону» при лобовом копировании неизвестен, а сессионные ключи шифрования напрямую не передаются, но генерируются с обеих сторон с использованием этого AppKey. Причем каждый раз — разные (благодаря случайному AppNonce). То есть кроме подключения через другой сервер «клон» сделать ничего дальше не сможет.

                                      Но не будет ли при таком подключении через сторонний сервер отключен оригинал (и снова попробует сделать подключение, которое опять можно скопировать для его отключения)?

                                      Поэтому вопрос сводится к тому, только ли сервер отслеживает попытку подключения (учет DevNonce) или и приложение за ним тоже его может и должно делать?

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое