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 избягва съхраняването на достъпни за бекенда медийни данни от детската стая и позволява критичната за сигурността логика за сдвояване да бъде проверена в публичния основен проект.
Въпроси, които да зададете за всяка бебешка камера
- Доставчикът съхранява ли изображения или клипове?
- Частни и краткотрайни ли са URL адресите за медийни данни и разрешава ли се достъпът чрез тях поотделно за всяко устройство?
- Ключовете генерират ли се за всяко устройство или сдвояване, вместо да са статични в приложението?
- Може ли брокерът да доставя съобщения само за устройството, което действително притежавате?
- Позволява ли сдвояването на човек да забележи опит за атака „човек по средата“?
Прочетете кода
- ECDH и SAS в Timmy Core
- Ключ за среща, ключ за документ и AES-GCM
- Правила на Firestore за сесии и сдвояване
- Документация за сигурността в основния проект
Източници
- Свободно достъпни записи от бебешки камери · Galaxus
- Милион бебефони и охранителни камери бяха лесно достъпни за гледане от хакери · The Verge
- никой не слага бебето в ъгъла · Sammy Azdoufal
- Ръководство за родители за същия инцидент · Baby Monitor Timmy