LoRaWNA

Сообщество LoRaWAN

Протокол LoRaWAN, модуляция LoRa, технологии Long Range, LPWAN сети и Интернет вещей (IoT)

IoT

LoRaWAN: активация узлов и безопасность

Данные в LoRaWAN сетях надежно защищены от любого несанкционированного доступа. Это стало возможным благодаря применению достаточно простого, но эффективного решения, при котором шифрование происходит на двух независимых слоях: сетевом и прикладном с применением двух уникальных для каждого устройства AES-128 ключей. Шифрование происходит в соответствии с RFC-4493. Полезные данные (payload) шифруются непосредственно на конечном узле (end-node) и следуют весь свой путь от отправителя до получателя в зашифрованном виде.

Принципы безопасности заложены в самом сетевом стеке LoRaWAN и непосредственно связаны с функционированием всех устройств сети, поэтому чтобы разобраться в вопросах безопасности нужно знать как устроена сеть изнутри.

Активация — получение «прописки» end-node

Для подключения узла к сети LoRaWAN каждое устройство должно пройти специальную процедуру активации, «получить прописку». Активация end-node может осуществляться двумя способами: OTAA (Over-the-Air Activation) и ABP (Activation by Personalization).

Over-the-Air Activation — активация «по воздуху»

При нахождении end-node в зоне покрытия сети возможна активация «по воздуху» (OTAA), которая происходит путем отправки конечным узлом запроса на присоединение (join-request) и получения разрешение на подключение (join-accept). Для успешного прохождения процедуры активации OTAA оператор сети LoRaWAN должен внести запись в специальную таблицу маршрутизации, в которой идентификатор приложения AppEUI будет соответствовать приложению на сервере (App Server) сервис-провайдера.

До начала OTAA активации в конечном узле луже должны храниться следующие данные:

  • DevEUI — (8-ми байтный, EUI64) глобально уникальный идентификатор устройства (End-device identifier). Может быть присвоен производителем устройства (по аналогии с MAC адресом), в ограниченном количестве может быть получен из доступного пула идентификаторов оператора, либо получен владельцем узла в составе пула в IEEE.
  • AppEUI — (8-ми байтный, EUI64 ) глобально уникальный идентификатор приложения для маршрутизации полученных данных сервером сети (Network Server), или как еще говорят: ядром сети (Network Core) на сервер приложений (AppServer)
  • AppKey — уникальный (16-ти байтный, AES-128) ключ шифрования, сгенерированный сервером приложений (AppServer) именно для этого устройства

Запрос на OTAA активацию (join-request) принимается всеми LoRaWAN сетями, имеющими покрытие в точке установки узла, сетевой сервер каждой из них принимает решение о подключении устройства к сети (join) и отправляет подтверждение подключения устройства отправкой join-accept сообщения или игнорирует запрос join-request. Повторные запросы join-request, от активированных ранее узлов, сервером сети игнорируются. Процедура активации «по воздуху» (OTAA — Over-the-Air Activation) также выполняется при регистрации устройств, находящихся вне зоны покрытия “домашней” сети, т.е. в роуминге в LoRaWAN сетях других операторов.

После OTAA активации конечный узел получает от сетевого сервера и хранит в себе:

  • DevAddr — 32-битный (четырехбайтный) сетевой адрес для адресации пакетов на сетевом уровне, имеет уникальное значение в пределах сети оператора (можно провести аналогию c MAC адресом, который тоже обеспечивает адресацию на 2 уровне модели OSI в сетях Ethernet, но способ получения DevAddr при OTAA сходен с получением динамического IP адреса, получаемого от DHCP сервера в TCP/IP сетях). Старшие 7 бит DevAddr содержат адрес сети оператора NwkID, это значение должно быть уникальными для находящихся рядом сетей и для сетей, имеющих перекрывающиеся зоны покрытия. Чаще всего, для обозначения DevAddr, используют четырехбайтную последовательность, например: 02:D1:D2:01, в которой старший байт является адресом сети NwkID (если снова проводить аналогию, то адрес сети оператора NwkID аналогичен трехбайтному коду изготовителя сетевого оборудования в MAC адресах в Ethernet сетях)
  • NwkSKey — уникальный (16-ти байтный, AES-128) ключ сетевой сессии, передается устройству зашифрованным с помощью ключа AppKey
  • AppSKey — уникальный (16-ти байтный, AES-128) ключ сессии приложения, передается устройству зашифрованным с помощью ключа AppKey, данный ключ сетевой сервер получает от сервера приложений и передает его узлу в составе join-accept сообщения, как и ключ сетевой сессии и DevAddr

На основании AppKey, содержащемуся в join-request пакете, сервер сети добавляет в таблицу маршрутизации запись о соответствии только что выданного устройству DevAddr приложению на сервере (App Server) сервис-провайдера, что в дальнейшем используется для маршрутизации всех данных от активированного устройства к сервис-провайдеру, а NwkSKey и AppSKey используются для шифрования.

При получении конечным узлом join-accept сообщения от сервера сети, узел аутентифицирует разрешение на подключение, расшифровывает его, извлекает и запоминает DevAddr, NwkSKey и AppSKey. В дальнейшем ключи NwkSKey и AppSKey не передаются по каналам связи, а DevAddr наоборот, присутствует в каждом пакете.

Activation by Personalization — активация путем записи в устройство персональных настроек

Активации ABP (Activation by Personalization) происходит без радиодоступа к сети, путем непосредственной записи сетевого адреса (DevAddr), выданного LoRaWAN провайдером и ключей шифрования NwkSKey и AppSKey либо при изготовлении устройства, либо позднее. ABP производится под выбранного LoRaWAN оператора.

Для осуществления ABP активации провайдер должен выделить пул сетевых адресов (address pool) из своего адресного пространства и настроить соответствие этих сетевых адресов DevAddr всех конечных узлов абонента приложению на сервере (App Server) сервис-провайдера для маршрутизации пакетов получателю.

При ABP (Activation by Personalization) производитель оконечных устройств, интегратор или конечный пользователь сохраняют DevAddr, NwkSKey и AppSKey непосредственно в каждый узел до его подключения к сети, предварительно получив адрес и ключ сетевой сессии у сетевого оператора, а ключ сессии (AppSKey) приложения у сервис-провайдера.

В этом случае устройство будет работать только в сети того оператора, который выдал данные для регистрации устройства. Для исключения компрометации ключей запрещается их передача владельцу конечного узла по небезопасным каналам связи, в отличии, например, от адреса устройства DevAddr. При выдаче DevAddr абоненту, оператор также, как и при OTAA, добавляет в таблицу маршрутизации запись о соответствии только что выданного пула адресов DevAddr приложению на сервере (App Server) сервис-провайдера. NwkSKey и AppSKey используются в дальнейшем для шифрования каждого пакета переданного узлом серверу сети.

При наличии корректных DevAddr, NwkSKey, AppSKey устройство становится активированным в сети выбранного оператора и полностью готово к работе сразу после включения.

Итогом успешной активации, независимо от способа, OTAA или ABP, является наличие в памяти узла DevAddr, NwkSKey и AppSKey.

Безопасность при обмене данными в LoRaWAN сетях

Важно отметить, что узлы сети не имеют в своем программном обеспечении функции дешифровки данных, их ПО позволяет только зашифровать данные перед отправкой, обратная расшифровка для них недоступна, расшифровка этой информации является прерогативой сервера сети (Network Server) и сервера приложений (AppServer).

Сервер сети (Network Server) производит расшифровку верхнего, сетевого слоя, для получения сведений, необходимых для проверки целостности данных и их дальнейшей транспортировки, при этом сами полезные данные (payload) остаются зашифрованными ключом сессии приложения AppSKey и недоступны для расшифровки на всех элементах сетевой инфраструктуры, кроме получателя — сервера приложений (AppServer).

Сервер приложений (AppServer) производит расшифровку пакета на нижнем, прикладном слое — расшифровка для извлечения полезной нагрузки из пакета данных и передача этих данных в пользовательское приложение.

Несанкционированное извлечение из устройства и компрометация ключей NwkSKey, AppSKey или AppKey является бессмысленным, т.к. эти ключи уникальны и предназначены только для одного конкретного устройства и не предоставляет злоумышленникам шансов скомпрометировать ключи других узлов.

На конечном узле (end-node) полезные данные (payload), полученные например, от подключенного сенсора, шифруются ключом сессии приложения AppSKey (прикладной слой), а полученный результат шифруется ключом сетевой сессии NwkSKey (сетевой слой) и упаковывается в пакет, содержащий адрес отправителя DevAddr, для передачи по радиоканалу на шлюзы, имеющие радиопокрытие в точке установки узла.

Все шлюзы принимают пакет от узла и с помощью встроенного программного обеспечения (packet forwarder), передают данные в свой TCP/IP интерфейс (обычно это VPN туннель организованный по протоколу IPsec) серверу сети (Network Server). Шлюзы пересылают пакеты в неизменном виде и абсолютно прозрачны с точки зрения обмена между узлами (end-node) и сервером сети (Network Server).

Пакет, зашифрованный на узле, ключом сетевой сессии NwkSKey и принятый от оконечного устройства сервером, проходит валидацию путем расчета и проверки кода целостности сообщения (от англ. MIC — message integrity code) и дешифруется (сетевой слой). Сервер сети не имеет доступа к полезной нагрузке (payload) пакета, потому что полезные данные в сообщении все еще зашифрованы с помощью AppSKey — ключа сессии приложения (прикладной слой шифрования).

На основании таблицы маршрутизации, в которой каждому адресу узла (DevAddr) соответствует конкретное приложение, сервер направляет пакет данных, прошедший идентификацию, на сервер приложений (App Server) сервис-провайдера.

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

В сети LoRaWAN одного оператора может быть много серверов приложений (App Server), сетевой сервер (Network Server) пересылает данные каждому из них в соответствии с заданными маршрутами. Например, в одной сети могут параллельно работать и торговые автоматы, отправляющие данные о своем состоянии в вендинговую компанию и счетчики коммунальных услуг c LoRa радиоканалом (вода, электроэнергия и пр.), передающие данные в управляющие компании.

Передача данных к пользователю от сервера приложений, обеспечение конфиденциальности и целостности данных, протоколом LoRaWAN не регламентируется и происходит с использованием традиционных технологий, реализованных в приложении сервис-провайдера.

Уровень безопасности в LoRaWAN сетях

Представленная технология шифрования двумя разными AES-128 ключами на сетевом и прикладном слоях позволяет избежать искажения, либо подменены данных, перехват сообщений в LoRaWAN сети также теряет смысл для злоумышленников.

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

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

Абсолютно безопасных способов передачи данных, как известно, не существует, но концепции безопасности, заложенные разработчиками протокола LoRaWAN, делают взлом практически невозможным, вычислительные мощности способные подобрать комплект из двух AES-128 ключей за разумное время появятся еще очень не скоро. Если учесть, что ключи разные для каждого устройства, то вероятность подбора ключей становится ничтожно малой величиной на данном этапе развития вычислительной техники.

Автор: Виктор Бруцкий, 4refr0nt@gmail.com

Обсуждение этой статьи на нашем форуме

Теги: , , , , , , , , ,