Security Explainer

Was die Meari-Babykamera-Sicherheitslücke zeigt – und warum Timmy anders absichert

Die Meari-Babykamera-Sicherheitslücke zeigt nicht nur, dass Kameras gehackt werden können. Sie zeigt, warum Babyphone-Sicherheit an Architektur, Autorisierung und Schlüsselverwaltung hängt.

Aktualisiert 2026-05-14 · 7 Minuten · mit Code-Verweisen

Galaxus berichtet über frei zugängliche Aufnahmen von Babykameras, The Verge über rund 1,1 Millionen betroffene Meari-Geräte. Die wichtigste Lehre ist unbequem: Ein Login schützt das Kinderzimmer nicht, wenn die Plattform dahinter Nachrichten, Bilder oder Schlüssel nicht sauber pro Gerät abgrenzt. Timmy löst nicht alle Sicherheitsprobleme der Welt, aber die kritischen Medien- und Pairing-Geheimnisse liegen absichtlich nicht in einer Cloud-Kamera-Plattform.

Was im Meari-Fall offenbar schiefging

Die öffentlichen Berichte beschreiben eine White-Label-Plattform: Viele Marken verkauften Kameras, die auf derselben Meari/CloudEdge-Infrastruktur aufsetzten. Genau das macht solche Fälle so gefährlich. Wenn die gemeinsame Plattform eine Autorisierungsgrenze falsch zieht, betrifft das nicht ein einzelnes Babyzimmer, sondern eine ganze Geräteflotte.

Die relevanten Muster waren laut Galaxus, The Verge und der Disclosure nicht nur schwache Standardpasswörter. Genannt werden unter anderem ein MQTT-Nachrichtenweg ohne ausreichende per-device Subscribe-Grenze, öffentlich erreichbare Bild-URLs, schwache Bild-Obfuskation und statische beziehungsweise aus Apps extrahierbare Schlüssel. Das ist eine Plattformlücke: Die Infrastruktur konnte Dinge sehen oder ausliefern, die sie gegenüber fremden Accounts nie hätte freigeben dürfen.

Risiko im Cloud-Kamera-Modell Timmy-Gegenentwurf
Backend speichert oder verteilt Bildereignisse. Timmy hat kein Cloud-Archiv für Kinderzimmerbilder; Medien laufen live über WebRTC.
Ein Broker oder Speicher muss perfekt pro Gerät autorisieren. Firestore transportiert nur Pairing- und Signaling-Daten, SDP/ICE werden vorher verschlüsselt.
Statische Schlüssel können eine ganze Flotte betreffen. Jede Kopplung erzeugt per P-256 ECDH einen eigenen Pairing-Key auf den Geräten.
Ein Relay oder Cloudpfad könnte mit Medien verwechselt werden. TURN leitet verschlüsselte SRTP-Pakete weiter, bekommt aber keine Medien-Schlüssel.

Wie Timmy den geheimen Schlüssel erzeugt

Der vierstellige Timmy-Code ist bewusst nicht der geheime Schlüssel. Im Code ist er nur ein Treffpunkt: Aus dem Code wird ein meetingKey abgeleitet, über den beide Geräte ihre öffentlichen ECDH-Schlüssel in Firestore finden. Die privaten Schlüssel verlassen die Geräte nicht.

Danach berechnen beide Seiten denselben P-256-ECDH-Shared-Secret-Wert. Aus diesem Geheimnis entsteht lokal der Pairing-Key. Die zweistellige SAS-Zahl wird zusätzlich aus dem Geheimnis und beiden sortierten Public Keys abgeleitet. Wird dieser Schlüsselaustausch manipuliert, erzeugen die Geräte unterschiedliche Zahlen. Genau daran erkennen Nutzer, dass sie die Kopplung nicht bestätigen sollten.

sequenceDiagram
    participant Baby as Baby-Gerät
    participant Firestore as Firestore-Meetingpoint
    participant Parent as Eltern-Gerät
    participant Turn as TURN-Relay

    Baby->>Baby: P-256 ECDH-Keypair erzeugen
    Parent->>Parent: P-256 ECDH-Keypair erzeugen
    Baby->>Firestore: Nur Public Key unter meetingKey schreiben
    Parent->>Firestore: Nur Public Key unter meetingKey schreiben
    Firestore-->>Baby: Public Key Eltern-Gerät
    Firestore-->>Parent: Public Key Baby-Gerät
    Baby->>Baby: sharedSecret + SAS berechnen
    Parent->>Parent: sharedSecret + SAS berechnen
    Baby-->>Parent: Menschen vergleichen SAS auf beiden Displays
    Baby->>Firestore: SDP/ICE mit AES-256-GCM verschlüsselt schreiben
    Parent->>Firestore: SDP/ICE mit AES-256-GCM verschlüsselt schreiben
    Baby-)Turn: WebRTC-Medien als DTLS/SRTP-Pakete
    Turn-)Parent: Relay leitet verschlüsselte Pakete weiter
    Note over Turn: TURN sieht Netzwerkmetadaten, aber keine Medien-Schlüssel

Vereinfachte Timmy-Sicherheitskette: Firestore ist Treffpunkt und Signaling-Transport, TURN ist nur Relay, Medien bleiben WebRTC-verschlüsselt.

Warum WebRTC nicht heimlich mitgelesen werden kann

WebRTC besteht nicht nur aus "Video senden". Vor der Medienübertragung führen die Geräte einen DTLS-Handshake durch. Daraus werden SRTP-Schlüssel für Audio und Video abgeleitet. Die Medienpakete sind dann SRTP-verschlüsselt. Ein TURN-Server kann sie weiterleiten, aber er bekommt nicht die Schlüssel, um Ton oder Bild zu öffnen.

Timmy legt davor noch eine zweite Schicht: Die Signaling-Daten, also SDP-Angebot, SDP-Antwort und ICE-Kandidaten, werden mit AES-256-GCM verschlüsselt, bevor sie in Firestore landen. Firestore hilft also beim Finden und Aushandeln, ist aber nicht der Ort, an dem ein Klartext-Video oder ein Klartext-SDP offen herumliegt.

Was Timmy trotzdem nicht verspricht

Kein seriöses Babyphone sollte "unhackbar" behaupten. Wenn ein Smartphone kompromittiert ist, kann jede App angegriffen werden. Wenn jemand eine manipulierte App-Version installiert, gelten andere Risiken. Und Serverkonfiguration muss laufend korrekt bleiben. Der Unterschied liegt enger: Timmy vermeidet ein Backend, das Kinderzimmer-Medien als lesbare Bilder oder Videoclips verwaltet, und macht die sicherheitskritische Pairing-Logik im Core-Projekt überprüfbar.

Prüffragen für jede Babykamera

  • Werden Bilder oder Clips beim Anbieter gespeichert?
  • Sind Medien-URLs privat, kurzlebig und pro Gerät autorisiert?
  • Sind Schlüssel pro Gerät oder Pairing erzeugt statt statisch in der App versteckt?
  • Kann ein Broker wirklich nur die Nachrichten des eigenen Geräts liefern?
  • Ist die Kopplung so erklärt, dass ein Mensch einen MITM-Angriff bemerken könnte?

Im Code nachlesen

Quellen

← Zurück zum Blog