Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Не в пику LoRaWAN или, тем более AES, но если уж речь зашла о криптографии, то аргументы, подобные
Станет ли наш злоумышленник месяцами писать пакеты, чтобы узнать показания счетчика? Маловероятно.нельзя считать приемлемыми.
интересно, что делает устройство, если навести помеху — пытается ли прислать новый (т.е. можно заставить слать пакеты чаще «раза в час») или спит?
Цитата из первой статьи серии
В А-классе вообще: проснулось, отправило пакет, получило подтверждение (если предусмотрено) и уснуло дальшет.е., в зависимости от настроек, может как требоваться подтверждение приема, так и нет. Если требуется, то, очевидно, при отсутствии подтверждения будет некоторое количество попыток повторной передачи. Только, если повторный пакет будет точной копией предыдущего, то это ни чего не даст в плане взлома.
Можно выставить отправку пакетов с подтверждением и без.
И число попыток на отправку.
Допустим, у нас есть пять попыток и подтверждение.
Радиомодуль просыпается и выходит в эфир на случайной частоте. Пересылает пакет. Ждет ответа от сервера. Если ответа нет, ждет его во втором приемном окне.
Если все равно тишина, то повторяет попытку на другой частоте.
Если быть чуть точнее, то он просто повторяет попытку на случайной частоте. Учитывая, что частот всего шесть, может оказаться, что вторая попытка будет на той же самой. Но третья уж точно на другой.
И так — пока не получит подтверждение или число попыток не кончится.
И число попыток на отправку.
Допустим, у нас есть пять попыток и подтверждение.
Радиомодуль просыпается и выходит в эфир на случайной частоте. Пересылает пакет. Ждет ответа от сервера. Если ответа нет, ждет его во втором приемном окне.
Если все равно тишина, то повторяет попытку на другой частоте.
Если быть чуть точнее, то он просто повторяет попытку на случайной частоте. Учитывая, что частот всего шесть, может оказаться, что вторая попытка будет на той же самой. Но третья уж точно на другой.
И так — пока не получит подтверждение или число попыток не кончится.
То есть, базовая станция имеет на борту шесть постоянно работающих приемных тракта, каждый непрерывно слушающий в своей полосе?
Нет. Базовая станция слушает широкую полосу частот. Порядка 7 МГц.
Каналы она использует только при связи с устройством.
Каналы она использует только при связи с устройством.
А на каком частотном канале следует посылать ответ она определяет из содержимого принятой посылки или имеет какие-то средства анализа частоты, на которой получен запрос?
Точно сейчас не вспомню. Надо спецификацию глянуть. Вообще правило отвечать радиомодулю на частоте обращения или на RX2.
Точная частота приёма пакета определяется базовой станцией, далее сервер сопоставляет частоту с uplink каналом и по алгоритму, зависящему от региона, вычисляет downlink канал и выставляет нужную частоту отправки.
В рассматриваемой системе очень критичны энергетические показатели канала связи (достаточно посмотреть на карту во второй части статьи — с какими уровнями приема Вам приходится иметь дело). То есть отношение сигнал/шум в приемнике имеет решающее значение. В то же время Вы осознанно расширяете полосу приема базовой станции шире полосы полезного сигнала передатчика, тем самым ухудшая соотношение сигнал/шум. На первый взгляд это кажется не логичным. Наверное, я что то упустил, но не могу понять — что именно.
Если вы про цифру в 7 МГц, то беда тут в нелицензируемом спектре. Смотрите, у нас первая граница — это 864 МГц (начало спектра), вторая — 869, 2 (конец). Если бы у нас свободные частоты шли одна за другой, то мы бы выставили себе 2 МГц и не заморачивались. Но раз уж все так, мы ловим широким сачком с большим запасом по краям.
Можно, конечно, поставить две БС или внутри БС сделать два приемника. Однако, это увеличивает стоимость и пока избыточно.
Я думаю, что эволюция Лоры нас все же приведет нас к двум БС в одном корпусе.
Можно, конечно, поставить две БС или внутри БС сделать два приемника. Однако, это увеличивает стоимость и пока избыточно.
Я думаю, что эволюция Лоры нас все же приведет нас к двум БС в одном корпусе.
Спасибо, теперь у меня в мозгах прояснилось.
Насколько помню, типовая схема БС (применяемая как минимум Multitech и в платах iC880a) включает в себя 2 трансивера sx127*, которые работают в относительно узких диапазонах. Собственно, при настройке packet forwarder'а базовые частоты для этих трансиверов и указываются в секциях «radio_0» и «radio_1».
Мне кажется, вы здесь заблуждаетесь. Если взять базовую станцию на чипе SX1301 с фронтендами SX1257, то каждый фронтенд не может покрыть полосу больше 800 кГц, т.е. суммарная максимальная полоса 1.6 МГц.
Глянул глобал конфиг. Да, вы правы, с 7 МГц я загнул. У нас на борту два SX1257 и каждый слушает по 800 кГц.
Соответственно, каждый — на свой поддиапазон. К примеру, центральная частота примерно посередине 864-865 и от нее отступы по 200 и 400 кГц в каждую сторону.
Получается, 5 каналов в 864-865. В результате, если всю полосу брать. там немного больше получается, но по центральным частотам так.
Соответственно, каждый — на свой поддиапазон. К примеру, центральная частота примерно посередине 864-865 и от нее отступы по 200 и 400 кГц в каждую сторону.
Получается, 5 каналов в 864-865. В результате, если всю полосу брать. там немного больше получается, но по центральным частотам так.
Не забывайте, что мы ограничены в вычисдительной мощности оконечки. И мы не гостайну передаем. Нам все равно придется искать определенный компромисс.
Ну и если уж на то пошло — не разу не слышал о подобных взломах. Есть некая теоретическая, посчитанная математически, вероятность. Как только будет первый реальный пример — можно будет разговаривать. Однако, к тому времени, как это случится уж заработает спецификация 1.1.
Ну и если уж на то пошло — не разу не слышал о подобных взломах. Есть некая теоретическая, посчитанная математически, вероятность. Как только будет первый реальный пример — можно будет разговаривать. Однако, к тому времени, как это случится уж заработает спецификация 1.1.
Я критиковал вовсе не криптостойкость LoRaWAN, я недостаточно компетентен в области криптографии, чтобы выносить суждения, пусть этим занимаются профессиональные криптоаналитики, а Вашу аргументацию. В криптографии недопустимы предположения: «это никому не нужно, поэтому взламывать никто не будет». Если разговор зашел о криптостойкости, то априори предполагается, что ломать будут и, причем, самыми разными способами, порой весьма не очевидными. И ценность зашифрованной информации не имеет никакого значения. Но, еще раз повторюсь, криптография — очень специфическая область, и пусть ею занимаются профессионалы.
Я согласен, что аргументация может быть недостаточно серьезной. Но мир в принципе не терпит абсолютов.
Скажем, есть задача купить новую машину и у вас есть только 700 000 рублей. Конечно, нужно, чтобы она была максимально безопасной. Но вы не купите за эти деньги новую Вольво в максималке, со всеми подушками и электронными наворотами, вроде остановиться перед препятствием. Такая машина стоит раза в четыре дороже.
Итог, у вас два варианта: либо вообще остаться без машины, либо подобрать ту, что будет наиболее безопасной в классе.
Кроме того, я подчеркиваю, что реальность взлома пока есть только в теории. На практике я не слышал, чтобы кто-то смог это сделать. И все равно эту проблему уже решили, еще до того. как она стала проблемой. После внедрения 1.1 даже в теории взломать уже не получится.
Скажем, есть задача купить новую машину и у вас есть только 700 000 рублей. Конечно, нужно, чтобы она была максимально безопасной. Но вы не купите за эти деньги новую Вольво в максималке, со всеми подушками и электронными наворотами, вроде остановиться перед препятствием. Такая машина стоит раза в четыре дороже.
Итог, у вас два варианта: либо вообще остаться без машины, либо подобрать ту, что будет наиболее безопасной в классе.
Кроме того, я подчеркиваю, что реальность взлома пока есть только в теории. На практике я не слышал, чтобы кто-то смог это сделать. И все равно эту проблему уже решили, еще до того. как она стала проблемой. После внедрения 1.1 даже в теории взломать уже не получится.
В примере с машинами Вы не упомянули еще один вполне рабочий вариант — купить подержанную. А если вернуться более близко к обсуждаемой теме, то машина ниже определенной стоимости не сможет получить необходимых сертификатов безопасности и не будет допущена для эксплуатации на дорогах общего пользования, т.е. в принципе не сможет считаться транспортным средством в общепринятой терминологии. Так же и с криптостойкостью: либо она не имеет известных уязвимостей и определяется только временем подбора ключа, которое неприемлемо велико для злоумышленника, либо ее как бы и нет вообще.
Еще раз подчеркну, что я вовсе не придираюсь к безопасности LoRaWAN.
Еще раз подчеркну, что я вовсе не придираюсь к безопасности LoRaWAN.
Не совсем понятно, если join request передаётся в открытом виде, то что может помешать заменить dev nonce и послать ещё раз пакет на присоединение?
В пакете JoinRequest есть MIC, который вычисляется на основе ключа AppKey, зашитого в устройство.
Абсолютно верно!
То есть, надо вытащить из устройства app key, и только после этого подменять запрос. А в устройстве он тоже явно не сильно в открытом виде хранится. Всё встало на свои места. Спасибо.
Вы уже хотите попробовать сломать?)
Нет. Я пока слишком далёк от LoRaWAN и всего, что с этим связано. Хотя не исключено, что придётся этим заняться в обозримом будущем. А тут спрашиваю-рассуждаю скорее потому, что было приглашение к дискуссии. И мне показалось, что некоторые моменты не раскрыты. Понятно, что всё можно найти в спецификации протокола. Но зачем тогда писать статьи?
Короче, поддерживаю беседу, как могу.
Короче, поддерживаю беседу, как могу.
А есть ли какая-то защита на БС от дублирующих регистраций оконечки?
Допустим, на одной БС регистрируется настоящее устройство. На второй БС регистрируется фейковое, которое копирует запросы настоящего.
БС между собой как-то общаются? Или это уже дальше, на уровне приложения решают конфликты?
Допустим, на одной БС регистрируется настоящее устройство. На второй БС регистрируется фейковое, которое копирует запросы настоящего.
БС между собой как-то общаются? Или это уже дальше, на уровне приложения решают конфликты?
Вся работа по регистрации происходит на Network Server. Базовые станции тупые и просто принимают и отправляют байтики в эфир. Во второй части была картинка архитектуры LoRaWAN сети.
Вы несколько неверно понимаете роль БС. БС в этой архитектуре — тупая железка, которая просто преобразует радиотраффик в ethernet (или СС) и гонит на сервер.
Всем рулит сервер. Это можно сравнить с неуправляемым коммутатором. Не важно в какой порт льете траффик, важно что стоит дальше.
Насчет активации. Если произошла активация одного устройства, а потом активировался кто-то еще, с такими же параметрами, то первое устройство превратиться в кирпич. Т.е. сервер у себя поменяет сессионные ключи и будет общаться с фейком, а реальное устройство уже не сможет с ним связаться. Однако, если сделать реактивацию реального устройства, то в кирпич превратится уже фейк. И так далее.
Как и в большинстве систем, если вы знаете пароли от входа, то сможете создать проблемы. Потому пароли надо беречь)
Всем рулит сервер. Это можно сравнить с неуправляемым коммутатором. Не важно в какой порт льете траффик, важно что стоит дальше.
Насчет активации. Если произошла активация одного устройства, а потом активировался кто-то еще, с такими же параметрами, то первое устройство превратиться в кирпич. Т.е. сервер у себя поменяет сессионные ключи и будет общаться с фейком, а реальное устройство уже не сможет с ним связаться. Однако, если сделать реактивацию реального устройства, то в кирпич превратится уже фейк. И так далее.
Как и в большинстве систем, если вы знаете пароли от входа, то сможете создать проблемы. Потому пароли надо беречь)
Не совсем: насколько я понимаю, имелась в виду попытка регистрации на сетевом сервере воспроизведением прослушанного и записанного join-request настоящего устройства.
В этом случае все параметры (AppEUI, DevEUI, DevNonce и MIC), конечно, будут корректными, так как являются точной копией настоящего запроса join-request.
Но сетевой сервер хранит «некоторое» количество ранее полученных DevNonce для каждого устройства и повторное обращение с тем же DevNonce игнорирует. Поэтому простое воспроизведение пакета присоединения (и далее) не даст подключиться к сети (например. отключив первое настоящее устройство).
В этом случае все параметры (AppEUI, DevEUI, DevNonce и MIC), конечно, будут корректными, так как являются точной копией настоящего запроса join-request.
Но сетевой сервер хранит «некоторое» количество ранее полученных DevNonce для каждого устройства и повторное обращение с тем же DevNonce игнорирует. Поэтому простое воспроизведение пакета присоединения (и далее) не даст подключиться к сети (например. отключив первое настоящее устройство).
Не совсем. Я имел ввиду ситуацию, когда злоумышленник откуда-то знает наши DevEUI, AppEUI и AppKey. Тогда он сможет сгенерить настоящий запрос. DevNonce и MIC будут отличаться, т.к. он не знает прошлый DevNonce. Сервер примет такой запрос за переактивацию, выдаст нашему клону новые ключи, а по старым отвечать уже не будет. И наше устройство превратиться в кирпич. Если мы его реактивируем, то кирпичом станет клон. И так далее.
Действительно, задача «на второй БС регистрируется фейковое, которое копирует запросы настоящего» может описывать и такую ситуацию.
В этом случае «клон» фактически будет уже не фейковым устройством, так как обладает всей информацией, что и исходное. Но считыванием эфира или копированием считанных запросов эти параметры не получить (по крайней без взлома криптографии).
Видимо, полный ответ на исходный вопрос должен звучать так: БС выступают только передатчиками, регистрацию в одной сети (и дальнейшее общение с кодированием) осуществляет один сетевой сервер. То есть нет нескольких «точек регистрации», которые могли бы зарегистрировать по копиям корректного запроса разные устройства.
Противодействие повторной передаче записанного запроса серверу также предусмотрено.
Если же изготовлена точная копия-злоумышленник устройства (знающая все его параметры, в том числе секретный ключ), то они с оригиналом будут бороться, отключая друг друга.
Но тут вопрос уже у меня: а если подключаться таким образом к разным сетевым серверам (то есть к серверам разных провайдеров, работающих с одним приложением) конфликта не возникнет? То есть может ли определить сервер приложений от какого из сетевых серверов запрос действительно настоящий (например, ему также транслируется и DevNonce)?
В этом случае «клон» фактически будет уже не фейковым устройством, так как обладает всей информацией, что и исходное. Но считыванием эфира или копированием считанных запросов эти параметры не получить (по крайней без взлома криптографии).
Видимо, полный ответ на исходный вопрос должен звучать так: БС выступают только передатчиками, регистрацию в одной сети (и дальнейшее общение с кодированием) осуществляет один сетевой сервер. То есть нет нескольких «точек регистрации», которые могли бы зарегистрировать по копиям корректного запроса разные устройства.
Противодействие повторной передаче записанного запроса серверу также предусмотрено.
Если же изготовлена точная копия-злоумышленник устройства (знающая все его параметры, в том числе секретный ключ), то они с оригиналом будут бороться, отключая друг друга.
Но тут вопрос уже у меня: а если подключаться таким образом к разным сетевым серверам (то есть к серверам разных провайдеров, работающих с одним приложением) конфликта не возникнет? То есть может ли определить сервер приложений от какого из сетевых серверов запрос действительно настоящий (например, ему также транслируется и DevNonce)?
Интересный вопрос! Я никогда не видел архитектуры «два сетевых сервера — один приложений». Наоборот бывает, а вот так… не уверен, что это вообще возможно.
Но конфликта возникнуть не должно. Для определенного DevEUI будет только один действующий сессионный ключ сервера приложений. Уж будет о наш или злоумышленника — вопрос десятый. Важно, что сервер приложений будет работать с тем, кого понимает.
Но конфликта возникнуть не должно. Для определенного DevEUI будет только один действующий сессионный ключ сервера приложений. Уж будет о наш или злоумышленника — вопрос десятый. Важно, что сервер приложений будет работать с тем, кого понимает.
Видимо, теоретически возможно и заложено в идею: в спецификации много рассуждений о роуминге (переходе конечного устройства между сетями) и ограничений параметров для его обеспечения.
Например, это может быть разумно если для ПО какой-то системы учета аналогичное оборудование развернуто на производствах в разных регионах и использовать один сервер неудобно. Или если устройство, работающее с приложением, установлено на транспорте, едущем из региона в регион — с разными провайдерами.
По итогу размышлений (насколько я понимаю эту систему): в любом случае секретный ключ шифрования AppKey «клону» при лобовом копировании неизвестен, а сессионные ключи шифрования напрямую не передаются, но генерируются с обеих сторон с использованием этого AppKey. Причем каждый раз — разные (благодаря случайному AppNonce). То есть кроме подключения через другой сервер «клон» сделать ничего дальше не сможет.
Но не будет ли при таком подключении через сторонний сервер отключен оригинал (и снова попробует сделать подключение, которое опять можно скопировать для его отключения)?
Поэтому вопрос сводится к тому, только ли сервер отслеживает попытку подключения (учет DevNonce) или и приложение за ним тоже его может и должно делать?
Например, это может быть разумно если для ПО какой-то системы учета аналогичное оборудование развернуто на производствах в разных регионах и использовать один сервер неудобно. Или если устройство, работающее с приложением, установлено на транспорте, едущем из региона в регион — с разными провайдерами.
По итогу размышлений (насколько я понимаю эту систему): в любом случае секретный ключ шифрования AppKey «клону» при лобовом копировании неизвестен, а сессионные ключи шифрования напрямую не передаются, но генерируются с обеих сторон с использованием этого AppKey. Причем каждый раз — разные (благодаря случайному AppNonce). То есть кроме подключения через другой сервер «клон» сделать ничего дальше не сможет.
Но не будет ли при таком подключении через сторонний сервер отключен оригинал (и снова попробует сделать подключение, которое опять можно скопировать для его отключения)?
Поэтому вопрос сводится к тому, только ли сервер отслеживает попытку подключения (учет DevNonce) или и приложение за ним тоже его может и должно делать?
Я честно говоря не до конца разобрался в следующем вопросе. Вы пишете:
Если я правильно понимаю, то и NwkSKey, и AppSKey генерируются на сетевом сервере (LoRaWAN 1.0.x). А устройство, получив NetID и AppNonce, в свою очередь используя тот же алгоритм, генерирует эти же ключи NwkSKey и AppSKey. После этого, сетевой сервер передает AppSKey на сервер приложений, чтобы тот мог расшифровывать входящие сообщения с устройства. Получается, что на самом деле сетевой сервер может расшифровать в т.ч. трафик сервера приложений, так как ему известен AppSKey. Так ли это? Как в процессе активации участвует сервер приложений? Спасибо
По сути, генерируются два сессионных ключа – сетевого сервера (NwkSKey) и сервера приложений (AppSKey). Эти ключи вместе с другой информацией шифруются AppKey и отправляются радиомодулю.
Если я правильно понимаю, то и NwkSKey, и AppSKey генерируются на сетевом сервере (LoRaWAN 1.0.x). А устройство, получив NetID и AppNonce, в свою очередь используя тот же алгоритм, генерирует эти же ключи NwkSKey и AppSKey. После этого, сетевой сервер передает AppSKey на сервер приложений, чтобы тот мог расшифровывать входящие сообщения с устройства. Получается, что на самом деле сетевой сервер может расшифровать в т.ч. трафик сервера приложений, так как ему известен AppSKey. Так ли это? Как в процессе активации участвует сервер приложений? Спасибо
Откуда вы взяли такую процедуру?
Нет, NwkSKey генерится на сетевом сервере, а AppSKey — на сервере приложений. Устройство получает их в зашифрованном виде (ключ к шифру, т.е. AppKey, оно знает изначально), пропишет у себя и, станет использовать для расшифровки пакетов с МАС-командами сервера или данными приложений. Активацию производит именно сетевой сервер. Если устройство знает идентификатор AppEUI ключ AppKey и его DevEUI прописан на сервере, то активация состоится (если речь про ОТАА).
Возможно вас смутило, что часть серверов (например, самый популярный от Веги) не придерживаются классической архитектуры, там СС и СП частично совмещены и пакеты после него выходят уже дешифрованные. Но это частный случай, который несколько нарушает классическую модель.
Нет, NwkSKey генерится на сетевом сервере, а AppSKey — на сервере приложений. Устройство получает их в зашифрованном виде (ключ к шифру, т.е. AppKey, оно знает изначально), пропишет у себя и, станет использовать для расшифровки пакетов с МАС-командами сервера или данными приложений. Активацию производит именно сетевой сервер. Если устройство знает идентификатор AppEUI ключ AppKey и его DevEUI прописан на сервере, то активация состоится (если речь про ОТАА).
Возможно вас смутило, что часть серверов (например, самый популярный от Веги) не придерживаются классической архитектуры, там СС и СП частично совмещены и пакеты после него выходят уже дешифрованные. Но это частный случай, который несколько нарушает классическую модель.
Большое спасибо за ответ.
Изначально при изучении процесса OTAA в различных туториалах мне попадались картинки наподобие
Эта схема полностью повторяет слова в статье о процедуре генерации сессионных ключей, и из нее же видно, что AppSKey известен сетевому серверу NS.
Мне похоже удалось разобраться в чем тут дело. Проблема в том, что между новым стандартом LoraWAN 1.1 и версией 1.0 существует некоторая путаница в обозначениях полей запросов JoinRequest, JoinAccept, а также в обозначении некоторых ключей. Судя по тому, что в Вашей статье одним из полей запроса JoinRequest является AppEUI (а не JoinEUI как в v1.1), то речь идет о спецификации 1.0.
В спецификации LoraWAN v1.0 указано:
Из этого видно, что действительно AppSKey известен сетевому серверу. По-другому сделать было невозможно, т.к. генерация сессионных ключей сделана следующим образом (стандарт 1.0)
Видно, что сетевой сервер для генерации своего сессионного ключа использует те же самые поля (кроме одной константы), что и для генерации AppSKey.
Таким образом, в Вашей статье нет ошибки применительно к LoraWAN 1.0, однако действительно AppSKey и NwkSKey известны сетевому серверу.
Видимо для того, чтобы закрыть эту концептуальную уязвимость и сделать так, чтобы NS не мог расшифровать трафик приложения, в более свежих версиях стандарта введена новая сущность JoinServer, при помощи которого обмен ключами производится таким образом, что NS больше не имеет информации об AppSKey и не может расшифровать трафик приложения. Схема генерации ключей в этом случае более сложная, и я еще не до конца с ней разобрался (поэтому и хотел сначала изучить поведение в ранних стандартах) и для меня пока загадка, в чьей зоне ответственности должен находиться JS — сетевого провайдера LoraWAN (NS) или владельца приложения (AS). Спасибо
Откуда вы взяли такую процедуру?
Изначально при изучении процесса OTAA в различных туториалах мне попадались картинки наподобие
этой
Эта схема полностью повторяет слова в статье о процедуре генерации сессионных ключей, и из нее же видно, что AppSKey известен сетевому серверу NS.
Мне похоже удалось разобраться в чем тут дело. Проблема в том, что между новым стандартом LoraWAN 1.1 и версией 1.0 существует некоторая путаница в обозначениях полей запросов JoinRequest, JoinAccept, а также в обозначении некоторых ключей. Судя по тому, что в Вашей статье одним из полей запроса JoinRequest является AppEUI (а не JoinEUI как в v1.1), то речь идет о спецификации 1.0.
В спецификации LoraWAN v1.0 указано:
6.1.4 Application session key (AppSKey)
The AppSKey is an application session key specific for the end-device. It is used by both the network server and the
end-device to encrypt and decrypt the payload field of application-specific data messages. It is also used to calculate and verify an application-level MIC that may be included in the payload of application-specific data messages
Из этого видно, что действительно AppSKey известен сетевому серверу. По-другому сделать было невозможно, т.к. генерация сессионных ключей сделана следующим образом (стандарт 1.0)
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
Видно, что сетевой сервер для генерации своего сессионного ключа использует те же самые поля (кроме одной константы), что и для генерации AppSKey.
Таким образом, в Вашей статье нет ошибки применительно к LoraWAN 1.0, однако действительно AppSKey и NwkSKey известны сетевому серверу.
Видимо для того, чтобы закрыть эту концептуальную уязвимость и сделать так, чтобы NS не мог расшифровать трафик приложения, в более свежих версиях стандарта введена новая сущность JoinServer, при помощи которого обмен ключами производится таким образом, что NS больше не имеет информации об AppSKey и не может расшифровать трафик приложения. Схема генерации ключей в этом случае более сложная, и я еще не до конца с ней разобрался (поэтому и хотел сначала изучить поведение в ранних стандартах) и для меня пока загадка, в чьей зоне ответственности должен находиться JS — сетевого провайдера LoraWAN (NS) или владельца приложения (AS). Спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Записки IoT-провайдера. Активация и безопасность в LoraWAN