Spiegazione sulla sicurezza

Vulnerabilità di sicurezza delle baby camera Meari: cosa fa Timmy in modo diverso

Il caso Meari mostra che un accesso ben curato non basta. La sicurezza di un baby monitor dipende dall'architettura, dalle autorizzazioni e dalla gestione delle chiavi.

Di Pubblicato Aggiornato

Galaxus ha segnalato registrazioni di baby camera liberamente accessibili; The Verge ha riportato circa 1,1 milioni di dispositivi Meari coinvolti. Per me, la lezione da trarne è sobria: un accesso non protegge la cameretta se la piattaforma alle spalle non separa correttamente messaggi, immagini o chiavi per ogni dispositivo. Timmy non risolve ogni problema di sicurezza al mondo. Ma i segreti essenziali di Timmy per i contenuti multimediali e l'abbinamento non risiedono in una piattaforma cloud per telecamere.

Cosa sembra non aver funzionato nel caso Meari

Le fonti pubbliche descrivono una piattaforma white-label. Telecamere vendute con molti marchi diversi dipendevano dalla stessa infrastruttura Meari/CloudEdge. Ecco perché l'incidente è importante: quando una piattaforma condivisa definisce in modo errato un confine di autorizzazione, il risultato non è una sola telecamera vulnerabile, ma l'esposizione di un intero parco di dispositivi.

Lo schema descritto va oltre le password predefinite deboli. Le fonti segnalano messaggi MQTT privi di controlli sufficienti sulle sottoscrizioni per ciascun dispositivo, URL di immagini accessibili pubblicamente, una debole offuscazione delle immagini e chiavi statiche o estraibili dall'app. È un problema della piattaforma: l'infrastruttura poteva rivelare dati che non avrebbero mai dovuto essere accessibili a un altro account.

Rischio delle telecamere cloudL'approccio alternativo di Timmy
Il backend archivia o distribuisce eventi con immagini.Timmy non dispone di un archivio cloud per le immagini della cameretta; il flusso multimediale avviene in diretta tramite WebRTC.
Un broker o un bucket deve autorizzare perfettamente ogni dispositivo.Firestore trasporta solo dati di abbinamento e segnalazione; i dati SDP/ICE vengono crittografati prima di essere scritti.
Le chiavi statiche possono mettere a rischio un'intera flotta di dispositivi.Ogni abbinamento genera sui dispositivi una chiave specifica derivata tramite ECDH P-256.
Un percorso relay può essere scambiato per accesso ai contenuti multimediali.TURN inoltra pacchetti SRTP crittografati, ma non riceve le chiavi dei contenuti multimediali.

Come Timmy crea il segreto

Il codice Timmy di quattro caratteri, volutamente, non è il segreto. Nell'implementazione è soltanto un punto d'incontro: l'app ne deriva una meetingKey a partire da esso, così che entrambi i dispositivi possano trovare lo stesso scambio di chiavi pubbliche su Firestore. Le chiavi ECDH private non lasciano mai i dispositivi.

Entrambi i dispositivi calcolano poi lo stesso segreto condiviso ECDH P-256. La chiave di abbinamento viene derivata localmente. Il SAS a due cifre viene derivato dal segreto condiviso più entrambe le chiavi pubbliche ordinate. Se lo scambio di chiavi viene manomesso, i dispositivi mostrano numeri diversi, avvisando gli utenti di non confermare l'abbinamento.

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

Catena di sicurezza semplificata di Timmy: Firestore è il punto d'incontro e il trasporto di segnalazione; TURN è solo un relay; i contenuti multimediali restano crittografati con WebRTC.

Perché i contenuti WebRTC non possono essere intercettati di nascosto

WebRTC non significa semplicemente "inviare video". Prima che inizi il flusso multimediale, i dispositivi eseguono un handshake DTLS. Le chiavi SRTP per audio e video vengono derivate da questo trasporto sicuro. I pacchetti multimediali vengono quindi crittografati tramite SRTP. Un server TURN può inoltrarli, ma non riceve le chiavi necessarie per decifrare l'audio o il video.

Timmy aggiunge un ulteriore livello prima di questo: i dati di segnalazione come offerte SDP, risposte SDP e candidati ICE vengono crittografati con AES-256-GCM prima di raggiungere Firestore. Firestore aiuta i dispositivi a negoziare; non è il luogo in cui dovrebbero risiedere video, audio o dati di segnalazione in chiaro.

Cosa Timmy comunque non sostiene

Nessun baby monitor serio dovrebbe dichiararsi inattaccabile. Se un telefono è compromesso, qualsiasi app può essere attaccata. Una versione malevola dell'app cambia il modello di rischio. La configurazione del server deve rimanere corretta. L'affermazione più circoscritta di Timmy riguarda l'architettura: evita di creare elementi multimediali della cameretta leggibili dal backend e rende ispezionabile, nel progetto core pubblico, la logica di abbinamento essenziale per la sicurezza.

Domande da porsi su qualsiasi baby camera

  • Il fornitore archivia immagini o clip?
  • Gli URL dei contenuti multimediali sono privati, validi per poco tempo e autorizzati per ciascun dispositivo?
  • Le chiavi vengono generate per ciascun dispositivo o abbinamento, anziché essere statiche all'interno di un'app?
  • Un broker può consegnare messaggi solo per il dispositivo che possiedi davvero?
  • L'abbinamento consente a una persona di rilevare un tentativo di attacco man-in-the-middle?

Leggi il codice

Fonti

← Torna al blog