Пояснення щодо безпеки

Уразливість у системі безпеки камер Meari: чим Timmy відрізняється

Випадок Meari показує, що навіть бездоганно оформленого входу недостатньо. Безпека радіоняні залежить від архітектури, авторизації та керування ключами.

Автор Опубліковано Оновлено

Galaxus повідомив про вільно доступні записи з дитячих камер, а The Verge — про приблизно 1,1 мільйона пристроїв Meari, яких це торкнулося. Для мене висновок простий: вхід у застосунок не захищає дитячу кімнату, якщо платформа за ним не розділяє належним чином повідомлення, зображення та ключі для кожного пристрою. Timmy не вирішує всіх проблем безпеки у світі. Але критично важливі секрети для передавання медіаданих і створення пари в Timmy не зберігаються на платформі хмарних камер.

Що, ймовірно, не спрацювало у випадку Meari

У публічних повідомленнях описано платформу, яку різні бренди використовували під власними назвами. Багато відомих брендів продавали камери, що залежали від тієї самої інфраструктури Meari/CloudEdge. Саме тому цей інцидент важливий: коли спільна платформа неправильно визначає межі авторизації, під загрозою опиняється не одна слабко захищена камера, а цілий парк пристроїв.

Описана схема виходить за межі слабких стандартних паролів. Джерела повідомляють про MQTT-повідомлення без достатнього контролю підписок для кожного пристрою, загальнодоступні URL-адреси зображень, слабке приховування зображень і статичні або такі, що можна витягти із застосунку, ключі. Це збій платформи: інфраструктура могла розкривати дані, які ніколи не повинні бути доступними іншому обліковому запису.

Ризик хмарних камерЯк цей ризик усунуто в Timmy
Серверна частина зберігає або розповсюджує зображення, пов’язані з подіями.Timmy не має хмарного архіву зображень із дитячої кімнати; медіа передаються наживо через WebRTC.
Брокер або сховище мають безпомилково перевіряти права доступу для кожного пристрою.Firestore передає лише дані для створення пари та сигнального обміну; SDP/ICE шифруються перед записом.
Статичні ключі можуть поставити під загрозу весь парк пристроїв.Під час кожного створення пари на пристроях генерується окремий ключ на основі P-256 ECDH.
Наявність шляху через ретранслятор можна помилково сприйняти як доступ до медіаданих.TURN пересилає зашифровані пакети SRTP, але не отримує ключів шифрування медіаданих.

Як Timmy створює секрет

Чотирисимвольний код Timmy навмисно не є секретом. У програмному коді це лише точка зустрічі: застосунок виводить із нього meetingKey щоб обидва пристрої могли знайти той самий канал обміну відкритими ключами у Firestore. Закриті ключі ECDH ніколи не залишають пристрої.

Потім обидва пристрої обчислюють той самий спільний секрет P-256 ECDH. Ключ парування виводиться локально. Двозначний SAS виводиться зі спільного секрету та обох відсортованих відкритих ключів. Якщо обмін ключами було підмінено, пристрої покажуть різні числа — це означає, що користувачам не слід підтверджувати парування.

sequenceDiagram
    participant Baby as Baby device
    participant Firestore as Firestore meeting point
    participant Parent as Parent device
    participant Turn as TURN relay

    Baby->>Baby: Generate P-256 ECDH keypair
    Parent->>Parent: Generate P-256 ECDH keypair
    Baby->>Firestore: Write public key only under meetingKey
    Parent->>Firestore: Write public key only under meetingKey
    Firestore-->>Baby: Parent public key
    Firestore-->>Parent: Baby public key
    Baby->>Baby: Compute sharedSecret + SAS
    Parent->>Parent: Compute sharedSecret + SAS
    Baby-->>Parent: Humans compare SAS on both screens
    Baby->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
    Parent->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
    Baby-)Turn: WebRTC media as DTLS/SRTP packets
    Turn-)Parent: Relay forwards encrypted packets
    Note over Turn: TURN sees network metadata, not media keys

Спрощений ланцюг безпеки Timmy: Firestore слугує точкою зустрічі й каналом сигнального обміну; TURN — лише ретранслятор; медіадані залишаються зашифрованими засобами WebRTC.

Чому медіапотік WebRTC не можна непомітно переглядати чи прослуховувати

WebRTC — це не просто «надіслати відео». Перш ніж почнеться передавання медіаданих, пристрої виконують процедуру встановлення захищеного з’єднання DTLS. Із цього захищеного транспортного з’єднання виводяться ключі SRTP для аудіо та відео. Потім медіапакети шифруються за протоколом SRTP. Сервер TURN може пересилати ці пакети, але не отримує ключів, потрібних для розшифрування аудіо чи відео.

Timmy додає ще один рівень захисту: дані сигнального обміну, зокрема пропозиції SDP, відповіді SDP та кандидати ICE, шифруються за допомогою AES-256-GCM ще до того, як потрапляють у Firestore. Firestore допомагає пристроям узгодити з’єднання; незашифровані відео, аудіо чи сигнальні дані не повинні там зберігатися.

Чого Timmy усе ще не стверджує

Жоден серйозний виробник радіоняні не повинен заявляти, що її неможливо зламати. Якщо телефон скомпрометовано, атакувати можна будь-який застосунок. Шкідлива збірка застосунку змінює модель ризиків. Конфігурація сервера має й надалі залишатися правильною. Timmy робить вужче твердження про свою архітектуру: він не створює на серверній частині медіаданих із дитячої кімнати, доступних їй у незашифрованому вигляді, а критично важливу логіку створення пари можна перевірити у відкритому проєкті Timmy Core.

Запитання про будь-яку дитячу камеру

  • Чи зберігає постачальник зображення або кліпи?
  • Чи є URL-адреси медіаданих приватними, чи мають вони обмежений строк дії та окрему авторизацію для кожного пристрою?
  • Чи генеруються окремі ключі для кожного пристрою або кожної пари, замість статичних ключів усередині застосунку?
  • Чи може брокер доставляти повідомлення лише для пристрою, який справді належить вам?
  • Чи дає створення пари користувачеві змогу помітити спробу атаки посередника?

Переглянути код

Джерела

← Назад до блогу