- •От издательства
- •О техническом обозревателе
- •О соавторах
- •Об авторах
- •Вступительное слово
- •Благодарности
- •Предисловие
- •Почему важна защита интернета вещей?
- •Чем защита интернета вещей отличается от традиционной ИТ-защиты?
- •Законы хакинга интернета вещей
- •Заключение
- •Моделирование угроз для интернета вещей
- •Схема моделирования угроз
- •Определение архитектуры
- •Разбивка архитектуры на компоненты
- •Выявление угроз
- •Использование деревьев атак для обнаружения угроз
- •Распространенные угрозы интернета вещей
- •Атаки с подавлением сигнала
- •Атаки с воспроизведением
- •Атаки со взломом настроек
- •Клонирование узла
- •Заключение
- •Пассивная разведка
- •Физический или аппаратный уровень
- •Периферийные интерфейсы
- •Среда загрузки
- •Блокировки
- •Предотвращение и обнаружение несанкционированного доступа
- •Прошивка
- •Интерфейсы отладки
- •Физическая устойчивость
- •Разведка
- •Атаки на сетевой протокол и службы
- •Тестирование беспроводного протокола
- •Оценка веб-приложений
- •Картирование приложений
- •Элементы управления на стороне клиента
- •Аутентификация
- •Управление сеансом
- •Проверка ввода
- •Логические ошибки
- •Сервер приложений
- •Исследование конфигурации хоста
- •Учетные записи пользователей
- •Привилегии учетной записи
- •Уровни патчей
- •Удаленное обслуживание
- •Управление доступом к файловой системе
- •Шифрование данных
- •Неверная конфигурация сервера
- •Мобильное приложение и облачное тестирование
- •Заключение
- •4. Оценка сети
- •Переход в сеть IoT
- •VLAN и сетевые коммутаторы
- •Спуфинг коммутатора
- •Двойное тегирование
- •Имитация устройств VoIP
- •Идентификация устройств IoT в сети
- •Обнаружение паролей службами снятия отпечатков
- •Атаки MQTT
- •Настройка тестовой среды
- •Написание модуля MQTT Authentication-Cracking в Ncrack
- •Тестирование модуля Ncrack на соответствие MQTT
- •Заключение
- •5. Анализ сетевых протоколов
- •Проверка сетевых протоколов
- •Сбор информации
- •Анализ
- •Создание прототипов и разработка инструментов
- •Работа с Lua
- •Общие сведения о протоколе DICOM
- •Генерация трафика DICOM
- •Включение Lua в Wireshark
- •Определение диссектора
- •Определение основной функции диссектора
- •Завершение диссектора
- •Создание диссектора C-ECHO
- •Начальная загрузка данных функции диссектора
- •Анализ полей переменной длины
- •Тестирование диссектора
- •Разработка сканера служб DICOM для механизма сценариев Nmap
- •Написание библиотеки сценариев Nmap для DICOM
- •Коды и константы DICOM
- •Написание функций создания и уничтожения сокетов
- •Создание заголовков пакетов DICOM
- •Написание запросов контекстов сообщений A-ASSOCIATE
- •Чтение аргументов скрипта в движке сценариев Nmap
- •Определение структуры запроса A-ASSOCIATE
- •Анализ ответов A-ASSOCIATE
- •Создание окончательного сценария
- •Заключение
- •6. Использование сети с нулевой конфигурацией
- •Использование UPnP
- •Стек UPnP
- •Распространенные уязвимости UPnP
- •Злоупотребление UPnP через интерфейсы WAN
- •Другие атаки UPnP
- •Использование mDNS и DNS-SD
- •Как работает mDNS
- •Как работает DNS-SD
- •Проведение разведки с помощью mDNS и DNS-SD
- •Злоупотребление на этапе проверки mDNS
- •Атаки «человек посередине» на mDNS и DNS-SD
- •Использование WS-Discovery
- •Как работает WS-Discovery
- •Подделка камер в вашей сети
- •Создание атак WS-Discovery
- •Заключение
- •UART
- •Аппаратные средства для связи с UART
- •Как найти порты UART
- •Определение скорости передачи UART
- •JTAG и SWD
- •JTAG
- •Как работает SWD
- •Аппаратные средства для взаимодействия с JTAG и SWD
- •Идентификация контактов JTAG
- •Взлом устройства с помощью UART и SWD
- •Целевое устройство STM32F103C8T6 (Black Pill)
- •Настройка среды отладки
- •Кодирование целевой программы на Arduino
- •Отладка целевого устройства
- •Заключение
- •Как работает SPI
- •Как работает I2C
- •Настройка архитектуры шины I2C типа «контроллер–периферия»
- •Заключение
- •9. Взлом прошивки
- •Прошивка и операционные системы
- •Получение доступа к микропрограмме
- •Взлом маршрутизатора Wi-Fi
- •Извлечение файловой системы
- •Статический анализ содержимого файловой системы
- •Эмуляция прошивки
- •Динамический анализ
- •Внедрение бэкдора в прошивку
- •Нацеливание на механизмы обновления микропрограмм
- •Компиляция и установка
- •Код клиента
- •Запуск службы обновления
- •Уязвимости служб обновления микропрограмм
- •Заключение
- •10. Радио ближнего действия: взлом rFID
- •Радиочастотные диапазоны
- •Пассивные и активные технологии RFID
- •Структура меток RFID
- •Низкочастотные метки RFID
- •Высокочастотные RFID-метки
- •Настройка Proxmark3
- •Обновление Proxmark3
- •Клонирование низкочастотных меток
- •Клонирование высокочастотных меток
- •Имитация RFID-метки
- •Изменение содержимого RFID-меток
- •Команды RAW для небрендированных или некоммерческих RFID-тегов
- •Подслушивание обмена данными между меткой и считывателем
- •Извлечение ключа сектора из перехваченного трафика
- •Атака путем подделки RFID
- •Автоматизация RFID-атак с помощью механизма скриптов Proxmark3
- •Пользовательские сценарии использования RFID-фаззинга
- •Заключение
- •11. Bluetooth Low Energy (BLE)
- •Как работает BLE
- •Необходимое оборудование BLE
- •BlueZ
- •Настройка интерфейсов BLE
- •Обнаружение устройств и перечисление характеристик
- •GATTTool
- •Bettercap
- •Взлом BLE
- •Настройка BLE CTF Infinity
- •Приступаем к работе
- •Заключение
- •12. Радиоканалы средней дальности: взлом Wi-Fi
- •Как работает Wi-Fi
- •Атаки Wi-Fi на беспроводные клиенты
- •Деаутентификация и атаки «отказ в обслуживании»
- •Атаки на Wi-Fi путем подключения
- •Wi-Fi Direct
- •Атаки на точки доступа Wi-Fi
- •Взлом WPA/WPA2
- •Взлом WPA/WPA2 Enterprise для сбора учетных данных
- •Методология тестирования
- •Заключение
- •13. Радио дальнего действия: LPWAN
- •Захват трафика LoRa
- •Настройка платы разработки Heltec LoRa 32
- •Настройка LoStik
- •Превращаем USB-устройство CatWAN в сниффер LoRa
- •Декодирование протокола LoRaWAN
- •Формат пакета LoRaWAN
- •Присоединение к сетям LoRaWAN
- •Атаки на LoRaWAN
- •Атаки с заменой битов
- •Генерация ключей и управление ими
- •Атаки воспроизведения
- •Подслушивание
- •Подмена ACK
- •Атаки, специфичные для приложений
- •Заключение
- •14. Взлом мобильных приложений
- •Разбивка архитектуры на компоненты
- •Выявление угроз
- •Защита данных и зашифрованная файловая система
- •Подписи приложений
- •Аутентификация пользователя
- •Управление изолированными аппаратными компонентами и ключами
- •Проверенная и безопасная загрузка
- •Анализ приложений iOS
- •Подготовка среды тестирования
- •Статический анализ
- •Динамический анализ
- •Атаки путем инъекции
- •Хранилище связки ключей
- •Реверс-инжиниринг двоичного кода
- •Перехват и изучение сетевого трафика
- •Анализ приложений Android
- •Подготовка тестовой среды
- •Извлечение файла APK
- •Статический анализ
- •Обратная конвертация двоичных исполняемых файлов
- •Динамический анализ
- •Перехват и анализ сетевого трафика
- •Утечки по побочным каналам
- •Заключение
- •15. Взлом умного дома
- •Физический доступ в здание
- •Клонирование RFID-метки умного дверного замка
- •Глушение беспроводной сигнализации
- •Воспроизведение потока с IP-камеры
- •Общие сведения о протоколах потоковой передачи
- •Анализ сетевого трафика IP-камеры
- •Извлечение видеопотока
- •Атака на умную беговую дорожку
- •Перехват управления интеллектуальной беговой дорожкой на базе Android
- •Заключение
- •Инструменты для взлома интернета вещей
- •Предметный указатель
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
зволяетдобиться этого,но не стесняйтесь экспериментировать сдру- |
|
|
to |
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
m |
|||
|
w Click |
|
|
|
|
|
|
||||
гими значениями в диапазоне от 7 до 12. |
w |
|
df-x chan |
|
|
|
|||||
|
w |
|
|
o |
|
||||||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
|
|
|
|
|
e |
|
Еслифункцияrfm9x.receive() ничегонеполучилавтечениезадан- ноговремени,онавозвращаетNone ,затеммывыводимсоответству- ющее сообщение на последовательную консоль и возвращаемся к на- чалуцикла.Еслимыполучаемпакет,топечатаемегонеобработанные байты и затем пытаемся декодировать их в ASCII . Часто пакет мо- жет содержать символы,не входящие в ASCII,из-за повреждения или шифрования,и для перехвата исключений у нас есть обработчик UnicodeError, иначе наша программа завершится с ошибкой. Наконец, мы выводим в консоль уровень принятого сигнала последнего полу- ченного сообщения, считывая регистр RSSI нашего чипа с помощью функции rfm9x.rssi().
Если вы оставите работающую последовательную консоль PuT- TY, вы должны увидеть перехваченные сообщения, как показано на рис. 13.9.
Рис.13.9.Последовательная консоль в PuTTY показывает нам перехваченные сообщения LoRa с устройства CatWAN
Декодирование протокола LoRaWAN
В этом разделе мы рассмотрим беспроводной протокол LoRaWAN, который является протоколом верхнего уровня для LoRa. Чтобы луч- ше понять протокол, мы рекомендуем вам прочитать официальную спецификацию на сайте LoRa Alliance по адресу https://lora-alliance.org/ lorawan-for-developers/.
Формат пакета LoRaWAN
LoRaWAN определяетуровни модели OSI поверх LoRa (уровеньOSI 1). Онвосновномработаетнауровнеуправлениядоступомксредепере-
дачиданных (MediumAccess Control,MAC) (уровеньOSI 2),хотя вклю-
чаетнекоторые элементы сетевого уровня (уровеньOSI 3).Например, сетевой уровень охватывает такие задачи, как подключение узлов ксетямLoRaWAN(см.раздел«ПрисоединениексетямLoRaWAN»),как пакеты пересылаются и т.д.
Формат пакета LoRaWAN дополнительно делит сетевой уровень на уровни MAC и приложения. Эти слои показаны на рис. 13.10.
372 Глава 13
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|
|||
|
|
X |
|
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
|||
P |
|
|
|
|
|
NOW! |
o |
|
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
Преамбула |
||||
|
|
|
|
|
|
||||||
w |
|
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
. |
|
|
|
|
|
.c |
|
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
|
||
|
|
|
|
-xcha |
|
|
|
|
|
PHDR PHDR_CRC PHYPayload
CRC
|
|
|
|
|
|
hang |
e |
|
|
|
|
||
|
|
|
|
|
C |
|
E |
|
|
||||
|
|
|
|
X |
|
|
|
|
|
|
|||
|
|
|
- |
|
|
|
|
|
|
d |
|
||
|
|
|
F |
|
|
|
|
|
|
|
t |
|
|
|
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
|
|
r |
||
|
|
P |
|
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
|
to |
|
|
|
|
|
||
LoRa– |
w Click |
|
|
|
|
|
m |
||||||
|
|
|
|
|
|
|
|||||||
|
w |
|
|
|
|
|
|
|
|
|
|
||
физический |
|
w |
|
df |
|
|
|
n |
|
o |
|
||
|
. |
|
|
|
.c |
|
|||||||
|
|
|
|
p |
|
|
|
|
|
g |
|
|
|
|
|
|
|
|
|
-x cha |
|
e |
|
||||
уровень(OSI 1) |
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MHDR |
MACPayload |
MIC |
|
LoRaWAN– |
||
|
|
|
|
|
|
|
уровеньMAC |
|
Сетевой |
|
|
|
|
|
|
||
|
|
|
|
|
(OSI 2) |
|||
уровень |
|
|
|
|
|
|
|
|
(OSI 3) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FHDR FPort FRMPayload |
|
|
Уровень |
|
|
|
|
|
|
|
|
приложения |
|
|
|
|
|
|
|
|
|
|
|
Рис.13.10.Формат пакета LoRaWAN
Чтобы понять, как взаимодействуют эти три уровня, вам сначала нужно понять принцип применения трех 128-битных ключей AES, которые использует LoRaWAN.NwkSKey –это сетевой сеансовый ключ, который узел и сетевой сервер используютдля вычисления и провер- ки кода целостности всех сообщений (Message Integrity Code, MIC), обеспечивая целостностьданных.AppSKey –это ключ сеанса приложе- ния,который конечное устройство и сервер приложений (можетбыть тем же объектом, что и сетевой сервер) используют для шифрования и дешифрования полезной нагрузки уровня приложения. AppKey (об- ратите внимание: в названии ключа нет буквы S) – это ключ прило- жения, известный узлу и серверу приложения и используемый для метода беспроводной активации (Over-the-Air Activation, OTAA), как описано в разделе «Присоединение к сетям LoRaWAN».
Физический уровень LoRa определяет радиоинтерфейс, схему мо- дуляции и дополнительный CRC для обнаружения ошибок. Он также несет полезную информацию для уровня MAC.Он состоит из следую щих частей:
zzпреамбулы – преамбулы радиопакета, которая содержит функ- цию синхронизации и определяетсхему модуляции пакета.Дли- тельность преамбулы обычно составляет 12,25 Т;
zzPHDR – заголовка физического уровня, который содержиттакую информацию, как длина полезной информации и наличие CRC полезной информации;
zzPHDR_CRC – CRC физического заголовка (PHDR). PHDR и PHDR_ CRC составляют в общей сложности 20 бит;
zzPHYPayload – полезной информации физического уровня, кото- рая содержит фрейм MAC;
zzCRC–необязательного 16-битного CRCдля PHYPayload.Сообще- ния, отправленные с сетевого сервера на узел, никогда не содер- жат это поле по причинам оптимизации производительности.
MAC-уровеньLoRaWANопределяеттипсообщенияLoRaWANиMIC, а также несет полезную информацию для уровня приложения выше.
Радио дальнего действия: LPWAN 373
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|
|||
|
|
|
|
X |
|
|
|
|
|
|
|||
|
|
|
- |
|
|
|
|
|
d |
|
|||
|
|
|
F |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
|
|
t |
|
||
|
P |
D |
|
|
|
|
|
|
|
|
o |
||
|
|
|
|
|
NOW! |
r |
|||||||
|
|
|
|
|
|
|
BUY |
|
|
||||
Он состоит из следующих частей: |
|
|
|
|
|
to |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
w |
|
|
|
|
|
|
|
|
|
|
m |
||
|
w Click |
|
|
|
|
|
|
o |
|||||
|
|
w |
|
|
|
|
|
|
|
|
|
||
|
|
|
. |
|
|
|
|
|
|
.c |
|
||
zzMHDR–заголовкаMAC(MHDR),которыйопределяеттипсообще- |
|
p |
df |
|
|
|
|
e |
|
||||
|
|
|
|
g |
|
|
|
||||||
|
|
|
|
n |
|
|
|
|
|||||
|
|
|
-x cha |
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
ния(MType)форматафреймаиверсиюспецификацииLoRaWAN. Трехбитовый MType указывает,какой из шести различныхтипов
MAC-сообщений у нас есть: Join-Request, Join-Accept, непод-
твержденные данные «вверх/вниз» и подтвержденные данные «вверх/вниз». «Вверх» в этом случае относится к передаче дан- ных от узла к сетевому серверу, а «вниз» указывает на передачу данных в противоположном направлении;
zzMACPayload – полезной информации MAC, которая содержит фрейм уровня приложения. Для сообщений Join-Request (или ReJoin-Request) полезная информация MAC имеет свой соб- ственный формат и не несет типичной полезной информации прикладного уровня;
zzMIC–четырехбайтовогоMIC,которыйобеспечиваетцелостность данных и предотвращает подделку сообщения. Он рассчитыва- ется по всем полям сообщения (msg = MHDR | FHDR | FPort | FRM- Payload) с использованием NwkSKey.Имейте в виду,что в сообще- ниях Join-Request и Join-Accept мы вычисляем MIC по-разному, потому что это особый тип полезной информации MAC.
Уровень приложения содержит данные для конкретного приложе- ния и адрес конечного устройства (DevAddr (адрес конечного устрой- ства), который однозначно идентифицирует узел в текущей сети. Он состоит из следующих частей:
zzFHDR – заголовка кадра (FHDR), который содержит DevAddr, байт управления фреймом (FCtrl), двухбайтовый счетчик фреймов (FCnt) и от нуля до 15 байт параметров фрейма (FOpts). Обрати- те внимание, что FCnt увеличивается каждый раз при передаче сообщенияииспользуетсядляпредотвращенияатакповторного воспроизведения;
zzFPort – порта фрейма, используемого для определения того, со- держит ли сообщение только MAC-команды (например, запрос на присоединение) или данные, относящиеся к приложению;
zzFRMPayload – фактические данные (например, значение темпе- ратуры датчика). Эти данные зашифрованы с помощью AppSKey.
Присоединение к сетям LoRaWAN
Узлы могут присоединиться к сети LoRaWAN двумя способами: OTAA
и активацией спомощью персонализации (Activation by Personalization, ABP). В этом разделе мы обсудим оба метода.
Обратите внимание, что в сетевой архитектуре LoRaWAN сервер приложений может быть отдельным компонентом сервера сети, но для простоты мы будем предполагать, что один и тот же объект вы- полняет обе функции. Официальная спецификация LoRaWAN делает то же предположение.
374 Глава 13
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
OTAA |
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
|||||
|
|
|
|
|
|
||||||
|
w |
|
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
В OTAA узлы следуют процедуре соединения, прежде чем смогут от- |
|
|
|
|
|
|
|||||
|
|
|
|
|
-x cha |
|
|
|
|
правлять данные в сеть и сервер приложений. Рисунок 13.11 иллю- стрирует эту процедуру.
Сетевой сервер
Шлюз
Узел
Рис.13.11.Поток сообщений OTAA
Сначала узел LoRa отправляет запрос соединения , содержащий идентификатор приложения (AppEUI), идентификатор конечного устройства (DevEUI) и случайное значение из двух байтов (DevNonce). Сообщение подписано (но не зашифровано) с использованием ключа AES-128, специфичного для узла, называемого AppKey.
Узел вычисляет эту подпись – MIC, описанный в предыдущем раз- деле – следующим образом:
cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce) MIC = cmac[0..3]
Узел использует код аутентификации сообщения на основе шифра
(Cipher-based MessageAuthentication Code,CMAC),который представ-
ляет собой хеш-функцию с ключом, основанную на блочном шифре с симметричным ключом (в этом случае AES-128). Узел формирует сообщение для аутентификации путем объединения MHDR, AppEUI, DevEUI и DevNonce. Функция aes128_cmac генерирует 128-битный код аутентификации сообщения, и его первые четыре байта образуют MIC, потому что MIC может содержатьтолько четыре байта.
ПРИМЕЧАНИЕ Вычисление MIC отличается для сообщений с данны- ми(любоесообщение,кромесообщенияJoin-Request иJoin-Accept).До- полнительную информацию о CMAC можно найти в RFC4493.
Любой шлюз , который получает пакет Join-Request, пересылает его в свою сеть. Устройство шлюза не мешает передаче сообщения; оно только действует как ретранслятор.
Узел не отправляет AppKey в запросе на присоединение. Поскольку сетевой сервер знает AppKey,он может пересчитать MIC на основе по-
Радио дальнего действия: LPWAN 375
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
|
X |
|
|
|
|
|
|||
|
|
|
- |
|
|
|
|
|
d |
|
||
|
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
|
r |
|||
|
P |
|
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
BUY |
|
|
|||
лученных значений MHDR, AppEUI, |
DevEUI и DevNonce в сообщении. Если |
|
|
|
to |
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
m |
|||
|
w Click |
|
|
|
|
|
|
|||||
|
w |
|
|
|
|
|
|
|
|
|
|
|
|
|
w |
|
df-x chan |
|
o |
|
|||||
у конечного устройства не было правильного ключа приложения,MIC |
. |
.c |
|
|||||||||
|
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
|
|
|
|
|
|
e |
|
|
в Join-Request не будетсовпадать с рассчитанным сервером,и сервер |
|
|
|
|
|
|
|
|
|
|
||
не будет проверять устройство. |
|
|
|
|
|
|
|
|
|
|
|
|
Если MIC совпадают, устройство считается действительным, и сер- |
|
|
|
|
|
|
|
|
|
|
||
вер отправляет ответ Join-Accept , содержащий идентификатор |
|
|
|
|
|
|
|
|
|
|
||
сети (NetID), DevAddr и одноразовое число (AppNonce), а также некото- |
|
|
|
|
|
|
|
|
|
|
||
рые настройки сети,такие как список частотканаловдля сети.Сервер |
|
|
|
|
|
|
|
|
|
|
||
шифрует Join-Accept с помощью |
AppKey. Сервер также вычисляет два |
|
|
|
|
|
|
|
|
|
|
сеансовых ключа, NwkSKeyи AppSKey, следующим образом:
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
Сервер вычисляет оба ключа с помощью AES-128 – шифрования конкатенации 0x01 (для NwkSKey) или 0x02 (для AppSKey), AppNonce, NetID, DevNonce и некоторого заполнения нулевых байтов, поэтому общая длина ключа кратна 16. В качестве ключа AES используется
AppKey.
Шлюз с самым сильным сигналом к устройству пересылает от- вет Join-Accept устройству . Затем узел сохраняет NetID, DevAddr и настройки сети и использует AppNonce для генерации тех же клю- чей сеанса, NwkSKey и AppSKey, что и сетевой сервер, используя ту же формулу.С этого момента узел и сервер используютNwkSKey иAppSKey для проверки, шифрования и дешифрования данных, которыми об- мениваются.
ABP
В ABP нет процедуры запроса или подтверждения присоединения
(Join-Request или Join-Accept). Вместо этого DevAddr и два сеансовых ключа,NwkSKeyиAppSKey,ужежесткозапрограммированывузле.Эти значениятакже предварительно зарегистрированы на сетевом серве- ре.На рис.13.12 показано,как узел отправляет сообщение на сетевой сервер, используя ABP.
Сетевой сервер
Шлюз
Узел
Рис.13.12.Поток сообщений ABP
376 Глава 13