Разработайте модель угроз и план защиты для подключённой к Интернету камеры умного дома с ограниченными вычислительными ресурсами: перечислите реальные векторы атак (включая supply-chain и физический доступ), предложите конкретные меры (аутентификация, шифрование, обновления, ключевая инфраструктура) с учётом ограничений устройства и объясните компромиссы между безопасностью, стоимостью и удобством пользователя

23 Окт в 12:44
6 +3
0
Ответы
1
Кратко и по делу — модель угроз и план защиты для подключённой к Интернету камеры умного дома с ограниченными ресурсами.
Ключевые активы
- Видео/аудио поток и записи.
- Ключи/учётные данные устройства.
- Целостность и доступность прошивки и конфигурации.
- Конфиденциальность владельца (метаданные, облачные учётки).
Акторы/мотивации
- Удалённые злоумышленники (шпионаж, ботнет).
- Вредоносные или коррумпированные поставщики (supply‑chain).
- Локальные злоумышленники/соседи (физический доступ).
- Исследователи/пентестеры.
Реальные векторы атак
- Брутфорс/использование дефолтных паролей при первой настройке.
- Уязвимости в сетевом стекe (RTSP/HTTP/UPnP/SSDP) → удалённый доступ.
- MITM/DNS‑перехват при отсутствии/слабом TLS; перехват потоков.
- Компрометация сервера обновлений (подмена прошивки).
- Подмена сертификатов/ключей при нескорректной проверке.
- Supply‑chain: вредоносная прошивка на заводе, подмена микроконтроллера, скомпрометированные сборочные серверы.
- Физический доступ: чтение флеш, извлечение JTAG/SWD, восстановление ключей из памяти.
- Боковые каналы/отладочные интерфейсы (JTAG, UART) оставленные открытыми.
- Уязвимости в облачном бэкенде/мобильном приложении.
- DoS/амплификация через RTSP/ONVIF, злоупотребление питанием.
Конкретные меры защиты (учитывая ограниченные ресурсы)
1) Идентификация и начальная поставка
- Генерировать уникальную учётную запись/пароль на устройстве и печатать/QR‑код на упаковке (не использовать одинаковые дефолтные пароли).
- Поддержка безопасной первичной привязки: локальная привязка через скан QR + физическое нажатиe кнопки ("push‑to‑pair").
2) Аутентификация и доступ
- Сертификаты устройства (клиентские) + mTLS для связи с облаком: использовать персонифицированный ключ/сертификат, подписанный CA производителя.
- Для локального доступа — OAuth2/short‑lived токены или сессионные ключи; минимальный набор прав.
- Отключать ненужные сервисы (telnet, ssh, ftp) и закрывать порты по умолчанию.
3) Шифрование и криптография
- TLS‑канал для всего трафика: предпочитать TLS‑1.31.31.3 или TLS‑1.21.21.2 при необходимости.
- Симметричное шифрование потоков: AES-128128128-GCM при наличии аппаратного ускорения; если нет — ChaCha202020-Poly1305.
- Ассиметрия: ключи на базе ECC (Curve255192551925519 или P-256256256) и подписи Ed255192551925519 / ECDSA(P-256256256).
- Хранение приватных ключей в безопасном хранилище: аппаратный Secure Element/SE/ATECC или MCU с защищённой флеш‑энкрипцией. Если SE нет — использовать прошивку, защищённую обфускацией и минимизировать время ключа в ОЗУ.
4) Обновления и целостность прошивки
- Подписанные бинарные образы: подпись на стороне производителя (Ed255192551925519/ECDSA) и проверка на устройстве до установки.
- Двухразделная A/B прошивка + откат (rollback protection через monotonic counter или версия в SE) — защищает от некорректного обновления.
- Дельта‑обновления для экономии трафика/памяти.
- Обновления через HTTPS + проверка подписи; периодические проверки целостности.
5) Аппаратная защита и защита от физического доступа
- Физические заглушки/заливка для JTAG/SWD, удалить отладочные интерфейсы или блокировать программно.
- Конструктив: винты Torx, пломба/наклейка, защита микрофона/камеры от наружного вмешательства.
- Хранение ключей в SE/TPM или использование MCU с встроенной фичей flash encrypt.
- Шифрование локальных записей на флеш: ключи в SE/TPM.
6) Supply‑chain и разработка
- Подписание всех артефактов сборки; reproducible builds, контроль версий и CI с проверкой доступа.
- Разделение прав доступа на производство; аудиты поставщиков компонентов; проверка прошивки пакетов сторонних библиотек.
- Приёмка устройств: проверка целостности устройства при включении (secure boot с корнем доверия в mask ROM/SE).
7) Логирование, мониторинг и реагирование
- Логирование аномалий (частые входы, неудачные логины) и централизованная аналитика облака.
- Rate‑limiting, блокировка IP при брутфорсах, уведомления владельцу.
- Возможность удалённого блокирования/отзыва сертификата (CRL/OCSP или short‑lived certs).
Компромиссы между безопасностью, стоимостью и удобством
- Аппаратные SE/TPM: сильно повышают безопасность (защита ключей, monotonic counter) — но добавляют стоимость +++ и немного сложнее логистика производства. Рекомендация: если цена позволяет — использовать SE; иначе — MCU с встроенной флеш‑энкрипцией и внимательное ПО.
- TLS и ECC: небольшой CPU‑нагрузки, но при отсутствии AES‑hardware лучше выбрать ChaCha202020-Poly1305 для скорости на слабых MCU. Это решает проблему производительности без ухудшения безопасности.
- A/B обновления и подписанные образы: требуют больше флеш/RAM (двойная копия), но дают надёжность. Если память ограничена — применять уменьшённые образы/дельта‑патчи; без A/B риск кирпичей/потери устройства выше.
- Уникальные пароли/сертификаты и сложная первичная привязка: повышают безопасность, но ухудшают UX (пользователь должен сканировать QR, хранить пароль). Компромисс — выдавать удобные QR/встроенные подсказки + простой UX для восстановления через облачный аккаунт с 2FA.
- Частые обновления повышают безопасность, но увеличивают трафик и нагрузку на серверы. Баланс: срочные патчи при уязвимости + регулярные накопительные обновления.
Приоритетный план внедрения (практичный для бюджета‑ограничений)
- Базис (обязательно): уникальные учётные данные, TLS для облака, выключение дебаг‑сервисов, подпись прошивок и проверка перед установкой.
- Средний уровень (рекомендуется): ECC‑сертификаты per‑device, secure boot, обновления A/B или проверка rollback, минимизация открытых сервисов.
- Высокий уровень (если бюджет позволяет): аппаратный SE/TPM, полное шифрование локального хранилища, supply‑chain аудиты, reproducible builds.
Коротко о конкретных рекомендуемых алгоритмах/версиях
- TLS‑1.31.31.3 (если библиотека и HW поддерживают), иначе TLS‑1.21.21.2 с современным шифр‑сетом.
- Ассиметрия: Curve255192551925519 / Ed255192551925519 или ECDSA P-256256256.
- Симметрия: AES-128128128-GCM при AES HW; иначе ChaCha202020-Poly1305.
- Подписи прошивок: Ed255192551925519 или ECDSA(P-256256256).
Заключение (одно предложение)
- Минимум: уникальные учётные данные + TLS + подписанные обновления; оптимум: добавить secure element, secure boot и A/B обновления — это обеспечивает разумный баланс безопасности, цены и удобства для камер с ограниченными ресурсами.
23 Окт в 13:06
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир