Faille de sécurité des caméras pour bébé Meari : ce que Timmy fait différemment

Galaxus a signalé des enregistrements de caméras pour bébé librement accessibles ; The Verge a rapporté qu’environ 1,1 million d’appareils Meari étaient concernés. Pour moi, le constat est simple : un système de connexion ne protège pas la chambre de bébé si la plateforme qui le sous-tend ne sépare pas correctement, pour chaque appareil, les messages, les images et les clés. Timmy ne résout pas tous les problèmes de sécurité du monde. Mais les secrets essentiels de Timmy pour les flux multimédias et l’appairage ne résident pas dans une plateforme de caméras connectées au cloud.

Ce qui semble avoir échoué dans le cas Meari

Les rapports publics décrivent une plateforme en marque blanche. De nombreuses marques présentes sur le marché vendaient des caméras reposant sur la même infrastructure Meari/CloudEdge. C’est pourquoi cet incident est important : lorsqu’une plateforme partagée définit mal les périmètres d’autorisation, ce n’est pas une seule caméra qui est exposée, mais tout un parc d’appareils.

Le problème signalé va au-delà de mots de passe par défaut trop faibles. Les sources décrivent des messages MQTT sans contrôle suffisant des abonnements pour chaque appareil, des URL d’images accessibles publiquement, un masquage rudimentaire des images ainsi que des clés statiques ou extractibles de l’application. C’est une défaillance de la plateforme : l’infrastructure pouvait révéler des données qui n’auraient jamais dû être accessibles à un autre compte.

Comment Timmy crée le secret

Le code Timmy à quatre caractères n’est volontairement pas le secret. Dans le code, il sert uniquement de point de rendez-vous : l’appli en dérive une meetingKey à partir de celui-ci, afin que les deux appareils puissent retrouver le même échange de clés publiques dans Firestore. Les clés privées ECDH ne quittent jamais les appareils.

Les deux appareils calculent ensuite le même secret partagé par ECDH P-256. La clé d’appairage est dérivée localement. Le SAS à deux chiffres est dérivé du secret partagé et des deux clés publiques triées. Si cet échange de clés est altéré, les appareils affichent deux nombres différents, ce qui indique aux utilisateurs de ne pas confirmer l’appairage.

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
        

Pourquoi les flux WebRTC ne peuvent pas être visionnés à l’insu des utilisateurs

WebRTC ne se limite pas à « envoyer de la vidéo ». Avant que les flux ne circulent, les appareils établissent une connexion sécurisée DTLS. Les clés SRTP de l’audio et de la vidéo sont dérivées de ce transport sécurisé. Les paquets multimédias sont ensuite chiffrés en SRTP. Un serveur TURN peut transmettre ces paquets, mais il ne reçoit pas les clés nécessaires pour déchiffrer l’audio ou la vidéo.

Timmy ajoute une couche avant cela : les données de signalisation telles que les offres SDP, les réponses SDP et les candidats ICE sont chiffrées avec AES-256-GCM avant d’arriver dans Firestore. Firestore aide les appareils à négocier ; ce n’est pas l’endroit où la vidéo, l’audio ou la signalisation en clair doivent se trouver.

Ce que Timmy ne prétend toujours pas faire

Aucun babyphone sérieux ne devrait prétendre être inviolable. Si un téléphone est compromis, n’importe quelle application peut être attaquée. Une version malveillante de l’application change le modèle de risque. La configuration du serveur doit rester correcte. L’affirmation plus limitée de Timmy porte sur son architecture : celle-ci évite de créer des contenus multimédias de la chambre de bébé lisibles par le backend et permet d’examiner la logique d’appairage essentielle à la sécurité dans le projet public Timmy Core.

Consulter le code source

• ECDH et SAS dans Timmy Core
• Clé de rendez-vous, clé de document et AES-GCM
• Règles Firestore pour les sessions et l’appairage
• Documentation de sécurité du projet public Timmy Core

Sources

• Enregistrements de caméras bébé librement accessibles · Galaxus
• Un million de babyphones et de caméras de sécurité pouvaient être facilement visionnés par des pirates informatiques · The Verge
• On ne laisse pas bébé dans un coin · Sammy Azdoufal
• Guide parental sur le même incident · Baby Monitor Timmy

← Retour au blog