セキュリティ解説

Meariベビーカメラのセキュリティ脆弱性:Timmyが異なる点

Meariの事例は、洗練されたログイン画面だけでは十分でないことを示しています。ベビーモニターのセキュリティは、アーキテクチャ、認可、鍵管理にかかっています。

Galaxusは誰でもアクセスできるベビーカメラの録画映像について報じ、The Vergeは影響を受けたMeari端末が約1.1百万台に上ると報じました。私がここから得た教訓は明快です。背後にあるプラットフォームがメッセージ、画像、鍵を端末ごとに適切に分離できていなければ、ログイン機能があっても子どものいる部屋は守れません。Timmyが世の中のあらゆるセキュリティ問題を解決するわけではありません。しかし、Timmyの重要なメディア情報やペアリング用の秘密情報は、クラウドカメラのプラットフォーム内には置かれません。

Meariの事例で起きたとみられること

公開された報道では、ホワイトラベルのプラットフォームについて説明されています。複数のブランドが、同じMeari/CloudEdgeのインフラに依存するカメラを販売していました。この事案が重要なのはそのためです。共有プラットフォームが認可の境界を誤ると、1台のカメラだけでなく、端末群全体がさらされることになります。

報告されている問題は、初期パスワードが弱いというだけではありません。情報源では、端末ごとの購読制御が不十分なMQTTメッセージ、一般公開された画像URL、脆弱な画像の難読化、固定鍵やアプリから抽出可能な鍵が指摘されています。これはプラットフォーム全体の問題です。本来は別のアカウントから決してアクセスできないはずのデータが、インフラを通じて露出する状態にありました。

クラウドカメラのリスクTimmyの対策設計
バックエンドが画像イベントを保存または配信します。Timmyには子どものいる部屋の画像を保管するクラウドアーカイブはありません。メディアはライブのWebRTCです。
ブローカーやバケットは、すべての端末を完璧に認可しなければなりません。Firestoreが扱うのはペアリングとシグナリングのデータのみです。SDP/ICEは書き込まれる前に暗号化されます。
固定鍵は端末群全体に影響するおそれがあります。ペアリングごとに、端末上でP-256 ECDHから導出した固有の鍵を作成します。
リレー経路がメディアへのアクセスだと誤解されることがあります。TURNは暗号化されたSRTPパケットを転送しますが、メディア鍵は受け取りません。

Timmyが秘密情報を作る仕組み

4文字のTimmyコードは、意図的に秘密情報ではありません。コード上では、これは待ち合わせ地点にすぎません。アプリはそこから meetingKey を導出し、両方の端末が同じFirestore上の公開鍵交換を見つけられるようにします。秘密ECDH鍵が端末の外に出ることはありません。

その後、両方の端末で同じP-256 ECDH共有秘密を計算します。ペアリング鍵は端末内で導出されます。2桁のSASは、共有秘密と並べ替えた両方の公開鍵から導出されます。鍵交換が改ざんされると端末には異なる番号が表示されるため、ユーザーはペアリングを確認しないよう判断できます。

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
        

Timmyのセキュリティチェーン(簡略版):Firestoreは待ち合わせとシグナリングの転送に使われ、TURNはリレーのみ、メディアはWebRTCで暗号化されたままです。

WebRTCのメディアを気づかれずに見られない理由

WebRTCは単に「動画を送る」ものではありません。メディアが流れる前に、端末同士でDTLSハンドシェイクを行います。音声と映像のSRTP鍵は、この安全な転送経路から導出されます。その後メディアパケットはSRTPで暗号化されます。TURNサーバーはパケットを転送できますが、音声や映像を開くための鍵は受け取りません。

Timmyではその前にも層を追加しています。SDPオファー、SDPアンサー、ICE候補などのシグナリングデータは、Firestoreに届く前にAES-256-GCMで暗号化されます。Firestoreは端末同士の接続交渉を助けるものであり、平文の映像、音声、シグナリングを置く場所ではありません。

Timmyが保証しないこと

信頼に足るベビーモニターであれば、絶対にハッキングされないとは主張しないはずです。スマートフォン自体が侵害されれば、どのアプリも攻撃される可能性があります。悪意のあるアプリのビルドが使われれば、前提となるリスクモデルも変わります。サーバーの設定も常に正しく保つ必要があります。Timmyの主張はより限定的です。子どものいる部屋の映像や音声をバックエンドから読み取れる形で残さず、セキュリティ上重要なペアリングの仕組みを公開されているコアプロジェクトで検証できるようにしています。

どのベビーカメラにも確認したいこと

  • メーカーは画像や動画クリップを保存していますか?
  • メディアURLは非公開で、有効期限が短く、端末ごとに認可されていますか?
  • 鍵はアプリ内の固定鍵ではなく、端末またはペアリングごとに生成されていますか?
  • ブローカーは、自分が実際に所有する端末向けのメッセージだけを配信できますか?
  • ペアリング時に、利用者が中間者攻撃に気づける仕組みがありますか?

コードを見る

情報源