Пример атаки
- Сценарий: умный дом с шлюзом (hub), облачной платформой и мобильным приложением управлением замком: устройство-замок связывается с облаком через Wi‑Fi/роутер; мобильное приложение управляет замком через облако и локальный шлюз.
- Атака MITM: злоумышленник в той же сети создаёт злонамеренную точку доступа/ARP‑спуфит роутер и перехватывает трафик между замком и шлюзом или между шлюзом и облаком. Он выполняет:
- TLS‑strip/Downgrade (если соединения не принудительно защищены),
- подмену DNS (redir на зл. сервис),
- перехват и модификацию MQTT/CoAP сообщений (если эти протоколы без шифрования или без клиентской аутентификации),
- отправку подложных команд для отпирания замка.
- Реальный итог: удалённое открывание замка, перехват паролей/ключей, вмешательство в прошивку.
Векторы проникновения (кратко)
- Сетевые: открытый/слабый Wi‑Fi, rogue AP, ARP‑spoofing, DNS‑spoofing, отсутствие сегментации.
- Протокольные: использование нешифрованных MQTT/CoAP/HTTP или устаревших TLS/SSL, отсутствие клиентской аутентификации.
- Устройство/поставщик: слабая/отсутствующая проверка прошивки, отсутствие secure boot, предсказуемая/встроенная аутентификация.
- Клиентские: приложение без certificate pinning, вредоносный мобильный клиент.
- Физический/снабжение: компрометация устройства на производстве или при установке.
Архитектурное решение для минимизации риска (ключевые принципы и компоненты)
1. Криптографическая основа
- End‑to‑end шифрование и взаимная аутентификация: устройства и шлюз/облако — mTLS/DTLS с клиентскими сертификатами (PKI). Пример: TLS $1.3$ для облака, DTLS для constrained‑устройств.
- Сертификат‑пиннинг в мобильных приложениях и шлюзе при работе с облаком.
- Аутентификация устройств через аппаратный root of trust (secure element/TPM) и уникальные ключи на устройстве, secure provisioning.
2. Безопасная прошивка и запуск
- Подпись и верификация прошивок (OTA) и secure boot.
- Контроль целостности и возможность отката/отзыва по CRL/OCSP.
3. Сетевой дизайн и политки доступа
- Сегментация сети: IoT‑сегмент в отдельном VLAN с ограниченным исходящим доступом.
- Zero‑trust: минимальные ACL, запрет прямого доступа из общего Wi‑Fi к устройствам.
- Защита доступа в Wi‑Fi: WPA$3$ или 802.1X ($802.1X$) для корпоративных кейсов.
4. Протоколы и брокеры
- Использовать MQTT/CoAP только поверх TLS/DTLS с авторизацией клиента и ACL на брокере.
- На стороне облака — API‑gateway, принимающий только mTLS и проверяющий идентификаторы устройств; HSM для хранения корневых ключей.
5. Мониторинг и обнаружение
- Логирование аутентификаций и команд, SIEM/IDS с анализом аномалий (необычные команды/времена/адреса).
- Детекция ARP/DNS spoofing на шлюзе (ARP‑watch, DNSSEC/DoH для критичных запросов).
6. Операционные меры
- Регулярная ротация ключей и сертификатов, отзываемые сертификаты.
- Минимизация прав: принцип наименьших привилегий на уровне команд и API.
- Безопасное управление секретами (HSM/SE) и защищённый процесс provision/commissioning.
Краткая архитектурная схема (текст)
- Устройство ↔(DTLS mTLS, аппаратный ключ)↔ Локальный шлюз/edge (контролирует и переводит протоколы) ↔(TLS $1.3$ mTLS, cert pinning)↔ Облачный API‑gateway → сервисы.
- Все OTA подпись‑проверяется HSM/SE, сеть сегментирована, журналы в SIEM, аутентификация и ACL централизованы.
Резюме (в одном предложении)
- Основная защита от MITM в IoT — обеспечить end‑to‑end взаимную аутентификацию и шифрование (mTLS/DTLS с аппаратным ключом и PKI), сетевую сегментацию и проверяемую подписанную прошивку, дополнительно внедрив мониторинг и управление ключами.