Galaxus informou de gravacións de cámaras para bebés accesibles libremente; The Verge informou de aproximadamente 1,1 millóns de dispositivos Meari afectados. Para min, a conclusión é sobria: un inicio de sesión non protexe o cuarto do bebé se a plataforma que hai detrás non separa ben por dispositivo as mensaxes, as imaxes ou as claves. Timmy non resolve todos os problemas de seguridade do mundo. Porén, os segredos críticos do emparellamento e do contido multimedia de Timmy non residen nunha plataforma de cámaras na nube.
O que parece que fallou no caso Meari
Os informes públicos describen unha plataforma de marca branca. Moitas marcas recoñecibles vendían cámaras que dependían da mesma infraestrutura de Meari/CloudEdge. Por iso importa o incidente: cando unha plataforma compartida establece mal un límite de autorización, o resultado non é unha soa cámara vulnerable, senón unha exposición que afecta a toda unha frota.
O patrón informado vai máis alá de contrasinais predeterminados febles. As fontes describen mensaxes MQTT sen controis suficientes de subscrición por dispositivo, URL de imaxes accesibles publicamente, ofuscación débil das imaxes e claves estáticas ou extraíbles da aplicación. É un fallo da plataforma: a infraestrutura podía revelar datos que nunca deberían estar dispoñibles para outra conta.
| Risco das cámaras na nube | O deseño alternativo de Timmy |
|---|---|
| O backend almacena ou distribúe eventos con imaxes. | Timmy non ten un arquivo na nube de imaxes do cuarto do bebé; o contido multimedia transmítese en directo mediante WebRTC. |
| Un intermediario de mensaxería ou un depósito de almacenamento debe autorizar correctamente cada dispositivo. | Firestore só transporta datos de emparellamento e sinalización; os datos SDP/ICE cífranse antes de escribirse. |
| As claves estáticas poden afectar toda unha frota. | Cada emparellamento crea nos dispositivos a súa propia clave derivada de ECDH P-256. |
| Unha ruta de relé pode confundirse cunha vía de acceso ao contido multimedia. | TURN reenvía paquetes SRTP cifrados, pero non recibe as claves do contido multimedia. |
Como crea Timmy o segredo
O código Timmy de catro caracteres non é o segredo de forma intencionada. No código, só é un punto de encontro: a aplicación deriva un meetingKey a partir del para que ambos os dispositivos poidan atopar o mesmo intercambio de claves públicas de Firestore. As claves privadas de ECDH nunca saen dos dispositivos.
A continuación, ambos os dispositivos calculan o mesmo segredo compartido ECDH P-256. A clave de emparellamento derívase localmente. O SAS de dous díxitos derívase do segredo compartido máis ambas as claves públicas ordenadas. Se se manipula ese intercambio de claves, os dispositivos amosan números distintos, o que indica ás persoas usuarias que non deben confirmar o emparellamento.
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
Cadea de seguridade simplificada de Timmy: Firestore é o punto de encontro e o transporte da sinalización; TURN é só un relé; o contido multimedia permanece cifrado mediante WebRTC.
Por que o contido multimedia de WebRTC non se pode ver ás agachadas
WebRTC non consiste simplemente en «enviar vídeo». Antes de comezar a transmisión multimedia, os dispositivos realizan unha negociación DTLS. As claves SRTP do audio e do vídeo derívanse dese transporte seguro. Despois, os paquetes multimedia cífranse mediante SRTP. Un servidor TURN pode reenvialos, pero non recibe as claves necesarias para descifrar o audio ou o vídeo.
Timmy engade unha capa antes diso: os datos de sinalización, como as ofertas SDP, as respostas SDP e os candidatos ICE, cífranse con AES-256-GCM antes de chegar a Firestore. Firestore axuda os dispositivos a negociar; non é o lugar onde deben residir sen cifrar nin o vídeo, nin o audio, nin a sinalización.
O que Timmy aínda non afirma
Ningún vixilabebés serio debería afirmar que é imposible de piratear. Se un teléfono está comprometido, pódese atacar calquera aplicación. Unha compilación maliciosa da aplicación cambia o modelo de risco. A configuración do servidor debe seguir sendo correcta. A afirmación máis limitada de Timmy é arquitectónica: evita que o backend poida ler datos multimedia do cuarto do bebé e permite revisar a lóxica de emparellamento crítica para a seguridade no proxecto principal público.
Preguntas que facer sobre calquera cámara de bebé
- O provedor almacena imaxes ou clips?
- Os URL do contido multimedia son privados, de curta duración e están autorizados por dispositivo?
- As claves xéranse por dispositivo ou emparellamento, en lugar de ser estáticas dentro dunha aplicación?
- Pode un intermediario de mensaxería entregar unicamente as mensaxes do dispositivo que realmente tes?
- O emparellamento permite que unha persoa detecte un intento de ataque de intermediario?
Ler o código
- ECDH e SAS en Timmy Core
- Clave de reunión, clave de documento e AES-GCM
- Regras de Firestore para sesións e emparellamento
- Documentación de seguridade no proxecto principal
Fontes
- Gravacións de cámaras de bebé accesibles libremente · Galaxus
- Un millón de vixilabebés e cámaras de seguridade eran facilmente visibles para hackers · The Verge
- ninguén pon o bebé nun recuncho · Sammy Azdoufal
- Guía para familias sobre o mesmo incidente · Baby Monitor Timmy