Приём пакета шлюзом ещё не означает, что система учёта защищена. Регистрация устройства в сети, хранение корневых ключей, формирование сеансовых ключей, защита от повторной передачи, безопасность серверного канала и права операторов — отдельные контрольные задачи.
Шлюз — не вся система защиты
Устройство LoRaWAN передаёт радиопакеты одному или нескольким шлюзам. Шлюз пересылает их по IP на Network Server и сам по себе не выполняет все процедуры аутентификации устройств и расшифрования прикладной нагрузки. Проверка целостности и счётчиков кадров относится к сетевому уровню, а доступ к расшифрованным данным определяется Application Server и архитектурой ключей.
ATLAS LR-1 — шлюз сбора данных счётчиков и датчиков. Наличие Join Server, Network Server, Application Server, защищённого TLS/VPN-транспорта и регламентов управления ключами необходимо указывать отдельно; нельзя считать их гарантированными функциями одного аппаратного шлюза.
OTAA и ABP: различия активации
При OTAA устройство проходит процедуру присоединения и формирует сеансовые ключи; в эксплуатационных сетях этот метод обычно предпочтительнее. В ABP адрес устройства и ключи сеанса задаются заранее, что требует дополнительных мер при перезапуске, переносе устройства и повторной настройке.
В LoRaWAN 1.0.x корневой AppKey участвует в получении NwkSKey для сетевой целостности и AppSKey для конфиденциальности прикладных данных. В LoRaWAN 1.1 разделены корневые AppKey/NwkKey, а в сети применяются FNwkSIntKey, SNwkSIntKey и NwkSEncKey. Схему ключей выбирают после подтверждения версии протокола конкретного устройства.
Что обеспечивает AES-128 и чего не обеспечивает
LoRaWAN использует криптографические механизмы на базе AES-128 для защиты прикладной нагрузки и контроля целостности MAC-сообщений. Однако это не заменяет TLS/VPN на сетевом участке, разграничение ролей, защиту API, журналы действий и политику обновления секретов в серверной инфраструктуре.
DevEUI и JoinEUI — идентификаторы, а не секреты. Корневые ключи должны создаваться с надлежащей уникальностью и храниться у уполномоченных сторон. Нельзя распространять их в обычных таблицах или незащищённой переписке; при замене прибора предусматривается отзыв доступа.
Зачем нужен счётчик кадров FCnt
Перехваченный радиопакет можно повторно передать. Счётчики кадров, включая FCntUp, помогают серверу отклонять ранее принятые сообщения. Если последним принят кадр с номером 105, старый кадр 103 не должен стать новым показанием. Особенно тщательно проверяется сохранение счётчиков после перезагрузки ABP-устройств, переноса сервера и восстановления резервной копии.
FCnt не равен накопленному индексу расхода воды. В прикладной системе отдельно контролируют идентификатор счётчика, время измерения, последовательность поступления и правдоподобие регистров.
Девять проверок при приёмке системы
Зафиксируйте версию LoRaWAN, региональный частотный план и метод активации. Подтвердите идентификацию устройства и выдачу индивидуального корневого ключа. Проверьте регистрацию DevEUI/JoinEUI на доверенном сервере. Задокументируйте ошибки Join и повторы. В тестовой среде проверьте отклонение устаревшего FCnt. Проверьте защищённый транспорт шлюз–сервер и права учётных записей. Ограничьте роли и API-токены. Опишите отзыв доступа при передаче прибора. На тестовых данных проверьте временные метки, индексы и резервное восстановление.
Применение к проектам ATLAS LR-1
Страница LR-1 описывает сбор беспроводных данных; доступные интерфейсы и радиопараметры зависят от аппаратного исполнения. В проекте следует зафиксировать модели приборов, версии LoRaWAN, сетевой сервер, сервер присоединения, сервер приложения, владельца ключей и ответственных за инциденты. Радиопокрытие не подменяет проверку безопасности.
Изучите шлюз ATLAS LR-1 и запросите техническое решение с учётом версии приборов, серверной архитектуры и требований к ключам.
Статья описывает общие механизмы LoRaWAN и не подтверждает конкретную версию прошивки или сертификат безопасности устройств ATLAS.