Galaxus va informar de gravacions de càmeres per a nadons accessibles lliurement; The Verge va informar que hi havia aproximadament 1,1 milions de dispositius Meari afectats. Per a mi, la lliçó és clara: un inici de sessió no protegeix l'habitació del nadó si la plataforma que hi ha al darrere no separa bé els missatges, les imatges o les claus de cada dispositiu. Timmy no resol tots els problemes de seguretat del món. Però els secrets essencials de contingut multimèdia i aparellament de Timmy no viuen dins d'una plataforma de càmeres al núvol.
Què sembla que va fallar en el cas Meari
Els informes públics descriuen una plataforma de marca blanca. Moltes marques visibles venien càmeres que depenien de la mateixa infraestructura de Meari/CloudEdge. Per això aquest incident és important: quan una plataforma compartida defineix malament un límit d'autorització, el resultat no és una sola càmera vulnerable, sinó una exposició a escala de tota la flota.
El patró descrit va més enllà de les contrasenyes predeterminades febles. Les fonts descriuen missatges MQTT sense prou controls de subscripció per dispositiu, URL d'imatges accessibles públicament, una ofuscació d'imatges feble i claus estàtiques o extreïbles de l'app. És una fallada de plataforma: la infraestructura podia revelar dades que mai no haurien d'haver estat disponibles per a un altre compte.
| Risc de les càmeres al núvol | El disseny alternatiu de Timmy |
|---|---|
| El backend emmagatzema o distribueix esdeveniments d'imatge. | Timmy no té cap arxiu al núvol d'imatges de l'habitació del nadó; el contingut multimèdia és WebRTC en directe. |
| Un intermediari o un bucket ha d'autoritzar perfectament cada dispositiu. | Firestore només transporta dades d'aparellament i senyalització; SDP/ICE es xifra abans d'escriure-s'hi. |
| Les claus estàtiques poden afectar tota una flota. | Cada aparellament crea als dispositius la seva pròpia clau derivada d'ECDH P-256. |
| Es pot confondre un camí de relé amb accés al contingut multimèdia. | TURN reenvia paquets SRTP xifrats, però no rep les claus multimèdia. |
Com crea Timmy el secret
El codi Timmy de quatre caràcters no és deliberadament el secret. En el codi, només és un punt de trobada: l'app en deriva una meetingKey perquè tots dos dispositius puguin trobar el mateix intercanvi de claus públiques de Firestore. Les claus ECDH privades no surten mai dels dispositius.
Després, tots dos dispositius calculen el mateix secret compartit ECDH P-256. La clau d'aparellament es deriva localment. El SAS de dos dígits es deriva del secret compartit i de les dues claus públiques ordenades. Si s'altera aquest intercanvi de claus, els dispositius mostren números diferents, fet que indica als usuaris que no han de confirmar l'aparellament.
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
Cadena de seguretat simplificada de Timmy: Firestore és el punt de trobada i el transport de senyalització; TURN només és un relé; el contingut multimèdia es manté xifrat amb WebRTC.
Per què el contingut multimèdia WebRTC no es pot mirar d'amagat
WebRTC no és només «enviar vídeo». Abans que flueixi el contingut multimèdia, els dispositius fan una negociació DTLS. Les claus SRTP d'àudio i vídeo es deriven d'aquest transport segur. Després, els paquets multimèdia es xifren com a SRTP. Un servidor TURN pot reenviar aquests paquets, però no rep les claus necessàries per obrir l'àudio o el vídeo.
Timmy hi afegeix una capa prèvia: les dades de senyalització, com les ofertes SDP, les respostes SDP i els candidats ICE, es xifren amb AES-256-GCM abans d'arribar a Firestore. Firestore ajuda els dispositius a negociar; no és el lloc on hagin de residir vídeo, àudio ni senyalització en text clar.
El que Timmy encara no afirma
Cap monitor de nadons seriós hauria d'afirmar que és impossible de piratejar. Si es compromet un telèfon, es pot atacar qualsevol app. Una versió maliciosa de l'app canvia el model de risc. La configuració del servidor ha de continuar sent correcta. L'afirmació més limitada de Timmy és arquitectònica: evita que el backend pugui llegir contingut multimèdia de l'habitació del nadó i fa que la lògica d'aparellament crítica per a la seguretat sigui revisable en el projecte central públic.
Preguntes que cal fer sobre qualsevol càmera per a nadons
- El proveïdor emmagatzema imatges o clips?
- Les URL del contingut multimèdia són privades, de curta durada i autoritzades per dispositiu?
- Les claus es generen per dispositiu o aparellament, en lloc de ser estàtiques dins d'una app?
- Un intermediari només pot lliurar missatges del dispositiu que realment tens?
- L'aparellament permet que una persona detecti un intent d'atac de tipus man-in-the-middle?
Llegeix el codi
- ECDH i SAS a Timmy Core
- Clau de reunió, clau de document i AES-GCM
- Regles de Firestore per a sessions i aparellament
- Documentació de seguretat al projecte central
Fonts
- Gravacions de càmeres per a nadons accessibles lliurement · Galaxus
- Un milió de monitors de nadons i càmeres de seguretat eren fàcilment visibles per als pirates informàtics · The Verge
- ningú no posa el nadó en un racó · Sammy Azdoufal
- Guia per a pares sobre el mateix incident · Baby Monitor Timmy