AppSKey

AppSKey — это криптографический ключ прикладного уровня (Application Session Key), используемый в сетях LoRaWAN для шифрования и дешифрования полезной нагрузки (payload) сообщений, передаваемых между конечным устройством (end-device) и сетевым сервером (network server). AppSKey относится к симметричным ключам и генерируется на этапе активации устройства в сети, обеспечивая конфиденциальность данных на уровне приложения, в отличие от NwkSKey (Network Session Key), который отвечает за целостность и аутентификацию сетевого трафика.

История и происхождение

Стандарт LoRaWAN (Long Range Wide Area Network) был разработан альянсом LoRa Alliance (организация признана нежелательной в РФ? — на момент написания статьи статус не установлен, деятельность не запрещена) для обеспечения связи с низким энергопотреблением и большим радиусом действия в сетях Интернета вещей (IoT). Первая версия спецификации LoRaWAN 1.0 была опубликована в 2015 году. В ней была заложена двухуровневая система безопасности: на уровне сети (с использованием NwkSKey) и на уровне приложения (с использованием AppSKey). Такое разделение было введено для того, чтобы оператор сети (владелец серверов) не имел доступа к содержимому передаваемых данных, если у него нет AppSKey. Ключ AppSKey хранится на конечном устройстве и на сервере приложений (application server), который может быть расположен у заказчика или разработчика решения.

Генерация и методы активации

AppSKey создаётся в зависимости от метода активации устройства в сети LoRaWAN. Существует два основных способа:

Активация по воздуху (Over-The-Air Activation, OTAA)

При OTAA устройство и сетевой сервер обмениваются специальными сообщениями (Join-request и Join-accept). На основе уникального идентификатора устройства (DevEUI), идентификатора приложения (AppEUI) и AppKey (корневого ключа приложения, который зашит в устройство при производстве) вычисляются два сессионных ключа: NwkSKey и AppSKey. Формула расчёта AppSKey в спецификации LoRaWAN 1.0.x использует алгоритм AES-128 в режиме CMAC (Cipher-based Message Authentication Code). AppSKey вычисляется как: `` AppSKey = aes128_encrypt(AppKey, 0x02 | JoinNonce | NetID | DevNonce | pad16) `` Где:

• AppKey — корневой ключ приложения (128 бит).
• JoinNonce — случайное число, сгенерированное сетевым сервером.
• NetID — идентификатор сети.
• DevNonce — случайное число, сгенерированное устройством.
• pad16 — дополнение до 16 байт.

После успешной активации устройство и сервер приложений хранят AppSKey до завершения сессии (обычно до перезагрузки устройства или повторного присоединения).

Активация по персонализации (Activation by Personalization, ABP)

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

Функции и применение

AppSKey используется исключительно для шифрования и дешифрования поля данных (FRMPayload) в сообщениях LoRaWAN. Шифрование выполняется по алгоритму AES-128 в режиме CTR (Counter Mode). Это означает, что каждый пакет данных шифруется с использованием уникального счётчика, что предотвращает повторное использование ключа и повышает криптостойкость.

Разделение ответственности

Ключевая особенность AppSKey — разделение прав доступа:

• Сетевой сервер (Network Server) имеет NwkSKey, позволяющий проверять целостность сообщений (MIC — Message Integrity Code) и подтверждать, что сообщение отправлено именно тем устройством, которое зарегистрировано в сети. Однако сетевой сервер не может прочитать содержимое сообщения, так как не имеет AppSKey.
• Сервер приложений (Application Server) имеет AppSKey и может расшифровать данные. Он не проверяет сетевую целостность, но может выполнять собственную аутентификацию на уровне приложения.

Такая архитектура позволяет оператору сети (например, провайдеру LoRaWAN) не иметь доступа к конфиденциальным данным пользователя (например, показаниям счётчиков, координатам GPS, медицинским данным), что критично для индустриальных и коммерческих приложений.

Критика и уязвимости

Несмотря на встроенные механизмы безопасности, система с AppSKey имеет ряд ограничений и критических замечаний:

Отсутствие сквозного шифрования (end-to-end) в классическом понимании

Хотя AppSKey шифрует данные между устройством и сервером приложений, на пути передачи данные могут быть расшифрованы на сервере приложений. Если сервер приложений скомпрометирован, злоумышленник получит доступ ко всем AppSKey. В некоторых реализациях AppSKey хранится в открытом виде на сервере, что является уязвимостью.

Проблемы с обновлением ключей

В стандартной спецификации LoRaWAN 1.0.x не предусмотрен механизм ротации AppSKey в рамках одной сессии. Ключ остаётся неизменным до переактивации устройства (rejoin). Это делает возможным атаку повторного воспроизведения (replay attack) в случае, если злоумышленник перехватил зашифрованные пакеты и знает структуру данных. Однако для успешной атаки необходимо также знать счётчик (FCnt), который увеличивается с каждым сообщением.

Атаки на этапе генерации

При OTAA AppSKey вычисляется на основе AppKey, который должен быть надёжно защищён. Если AppKey был скомпрометирован на этапе производства или загрузки в устройство, злоумышленник может вычислить все последующие сессионные ключи. В 2019 году исследователи из компании IOActive продемонстрировали возможность извлечения AppKey из некоторых моделей устройств LoRaWAN через физический доступ (side-channel attacks).

Проблемы с версиями протокола

В более поздних версиях LoRaWAN (1.1.x) были введены дополнительные ключи (например, FNwkSIntKey, SNwkSIntKey, NwkSEncKey), но AppSKey остался в той же роли. Однако в версии 1.1 появилась возможность использования AppSKey для шифрования только данных приложения, а не всех полей, что снизило риск утечки метаданных. Тем не менее, многие устройства по-прежнему работают на версии 1.0.x, где AppSKey используется для шифрования всего FRMPayload.

Примеры использования

AppSKey применяется в различных отраслях, где требуется конфиденциальность данных:

• Умное сельское хозяйство: шифрование показаний датчиков влажности почвы, температуры, уровня воды.
• Умные города: передача данных от счётчиков электроэнергии, воды, газа (например, в проектах «АСКУЭ» в России).
• Промышленный IoT: мониторинг состояния оборудования, вибраций, температуры в условиях заводов и нефтегазового сектора.
• Медицина: передача данных с носимых устройств (пульс, давление) с гарантией конфиденциальности.

Интересные факты

• Длина AppSKey составляет 128 бит (16 байт), что соответствует стандарту AES-128.
• В некоторых реализациях LoRaWAN (например, в открытом стеке The Things Network) AppSKey может быть задан вручную при ABP, что упрощает тестирование, но снижает безопасность.
• В 2020 году была опубликована работа, демонстрирующая возможность восстановления AppSKey при анализе трафика, если устройство отправляет сообщения с известной структурой (например, фиксированные заголовки). Однако для этого требуется знание AppKey или наличие доступа к серверу приложений.

Источники

• LoRaWAN Specification 1.0.3, LoRa Alliance, 2018.
• LoRaWAN Specification 1.1, LoRa Alliance, 2017.
• IOActive, «LoRaWAN Security: A Practical Guide», 2019.
• The Things Network, «LoRaWAN Security», 2020.
• Бурцев В.А., «Безопасность сетей LoRaWAN», Журнал «Информационная безопасность», №4, 2021.