Meari ကလေးကင်မရာ လုံခြုံရေးအားနည်းချက် — Timmy က ဘယ်လိုကွဲပြားအောင် လုပ်ထားသလဲ

Galaxus က မည်သူမဆို ဝင်ရောက်ကြည့်ရှုနိုင်သည့် ကလေးကင်မရာမှတ်တမ်းများအကြောင်း ဖော်ပြခဲ့ပြီး The Verge က Meari စက်ပေါင်း 1.1 သန်းခန့် ထိခိုက်ခဲ့ကြောင်း ရေးသားခဲ့သည်။ ကျွန်တော့်အတွက် သင်ခန်းစာက ရှင်းပါသည်- နောက်ကွယ်ရှိ ပလက်ဖောင်းက စက်တစ်လုံးချင်းစီအလိုက် မက်ဆေ့ချ်များ၊ ပုံများ သို့မဟုတ် သော့များကို သေချာစွာ မခွဲထားနိုင်လျှင် login ရှိနေခြင်းက ကလေးအခန်းကို မကာကွယ်နိုင်ပါ။ Timmy က ကမ္ဘာပေါ်ရှိ လုံခြုံရေးပြဿနာအားလုံးကို မဖြေရှင်းနိုင်ပါ။ သို့သော် Timmy ၏ မီဒီယာနှင့် တွဲဖက်ချိတ်ဆက်မှုဆိုင်ရာ အရေးကြီးသော လျှို့ဝှက်ချက်များကို cloud-camera ပလက်ဖောင်းထဲတွင် မထားပါ။

Meari ဖြစ်ရပ်တွင် ဘာတွေမှားယွင်းခဲ့ပုံရသလဲ

အများပြည်သူထံ ထွက်ပေါ်လာသော သတင်းများတွင် white-label platform တစ်ခုအကြောင်း ဖော်ပြထားပါသည်။ မြင်တွေ့ရသည့် brand များစွာက တူညီသော Meari/CloudEdge infrastructure ကို အားကိုးသည့် ကင်မရာများ ရောင်းချခဲ့ကြသည်။ ထို့ကြောင့် ဤဖြစ်ရပ်သည် အရေးကြီးပါသည်- shared platform တစ်ခုက authorization boundary ကို မှားယွင်းစွာ သတ်မှတ်လျှင် အားနည်းသောကင်မရာတစ်လုံးတည်း မဟုတ်ဘဲ စက်အုပ်စုတစ်ခုလုံး ထိခိုက်နိုင်ပါသည်။

ဖော်ပြထားသည့် ပြဿနာပုံစံသည် မူလသတ်မှတ်ထားသော စကားဝှက်များ အားနည်းရုံထက် ပိုမိုကျယ်ပြန့်သည်။ ရင်းမြစ်များတွင် စက်တစ်လုံးချင်းစီအလိုက် လုံလောက်သော subscription ထိန်းချုပ်မှုမရှိသည့် MQTT မက်ဆေ့ချ်များ၊ အများပြည်သူ ဝင်ရောက်နိုင်သည့် ပုံ URL များ၊ အားနည်းသော ပုံဖုံးကွယ်မှုနှင့် မပြောင်းလဲသော သို့မဟုတ် အက်ပ်မှ ထုတ်ယူနိုင်သည့် သော့များကို ဖော်ပြထားသည်။ ယင်းသည် ပလက်ဖောင်းအဆင့် ချို့ယွင်းမှုဖြစ်သည်- အခြေခံအဆောက်အအုံက အခြား account တစ်ခု လုံးဝမရရှိသင့်သည့် ဒေတာများကို ဖော်ထုတ်ပေးနိုင်သည့် အခြေအနေဖြစ်သည်။

Timmy က လျှို့ဝှက်ချက်ကို ဘယ်လိုဖန်တီးသလဲ

အက္ခရာလေးလုံးပါ Timmy ကုဒ်ကို လျှို့ဝှက်ချက်အဖြစ် ရည်ရွယ်ထားခြင်း မဟုတ်ပါ။ ကုဒ်အရ ၎င်းသည် စက်နှစ်လုံး ဆုံတွေ့ရန်နေရာတစ်ခုသာဖြစ်ပြီး အက်ပ်က ထိုကုဒ်မှ meeting key တစ်ခုကို ဆင်းသက်တွက်ချက်ပါသည်။ meetingKey ထို meeting key ကြောင့် စက်နှစ်လုံးစလုံးက တူညီသော Firestore အများသုံးသော့လဲလှယ်မှုကို ရှာတွေ့နိုင်သည်။ သီးသန့် ECDH သော့များသည် စက်များမှ ဘယ်တော့မျှ မထွက်ပါ။

ထို့နောက် စက်နှစ်လုံးစလုံးက တူညီသော P-256 ECDH မျှဝေလျှို့ဝှက်ချက်ကို တွက်ချက်သည်။ တွဲဖက်ချိတ်ဆက်မှုသော့ကို စက်များပေါ်တွင်ပင် ဆင်းသက်တွက်ချက်သည်။ ဂဏန်းနှစ်လုံးပါ 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
        

WebRTC media ကို ဘာကြောင့် မသိမသာ ကြည့်ရှုမရသလဲ

WebRTC သည် "video ပို့ခြင်း" သာမဟုတ်ပါ။ Media မစီးဆင်းမီ device များက DTLS handshake ပြုလုပ်ပါသည်။ Audio နှင့် video အတွက် SRTP key များကို ထို secure transport မှ ထုတ်ယူပါသည်။ ထို့နောက် media packet များကို SRTP ဖြင့် encrypt လုပ်ပါသည်။ TURN server သည် packet များကို ဆက်ပို့နိုင်သော်လည်း audio သို့မဟုတ် video ကို ဖွင့်ရန်လိုအပ်သည့် key များကို မရရှိပါ။

Timmy က ထိုအရှေ့တွင် အလွှာတစ်ခု ထပ်ထည့်ထားပါသည်- SDP offer၊ SDP answer နှင့် ICE candidate ကဲ့သို့သော signaling data များကို Firestore သို့ မရောက်မီ AES-256-GCM ဖြင့် encrypt လုပ်ပါသည်။ Firestore က device များ ညှိနှိုင်းနိုင်ရန် ကူညီပေးသည်သာဖြစ်ပြီး cleartext video၊ audio သို့မဟုတ် cleartext signaling သိမ်းဆည်းရမည့်နေရာ မဟုတ်ပါ။

Timmy က အခိုင်အမာ မဆိုထားသည့်အရာများ

ယုံကြည်စိတ်ချရသော baby monitor တစ်ခုက လုံးဝဖောက်ထွင်းမရနိုင်ဟု မဆိုသင့်ပါ။ ဖုန်းတစ်လုံး ဖောက်ထွင်းထိန်းချုပ်ခံရလျှင် မည်သည့်အက်ပ်မဆို တိုက်ခိုက်ခံရနိုင်သည်။ အန္တရာယ်ရှိသော အက်ပ်ဗားရှင်းတစ်ခုက အန္တရာယ်ပုံစံကို ပြောင်းလဲစေသည်။ ဆာဗာဖွဲ့စည်းပုံကိုလည်း အမြဲမှန်ကန်စွာ ထိန်းသိမ်းရမည်။ Timmy ၏ ပိုမိုကန့်သတ်ထားသော အဆိုမှာ စနစ်တည်ဆောက်ပုံဆိုင်ရာဖြစ်သည်- backend က ဖတ်ရှုနိုင်သည့် ကလေးအခန်းမီဒီယာဒေတာ မကျန်စေဘဲ လုံခြုံရေးအတွက် အရေးကြီးသည့် တွဲဖက်ချိတ်ဆက်မှု logic ကို အများပြည်သူကြည့်ရှုနိုင်သော core project တွင် စစ်ဆေးနိုင်စေသည်။

ကုဒ်ကိုဖတ်ရန်

• Timmy Core ရှိ ECDH နှင့် SAS
• Meeting key၊ document key နှင့် AES-GCM
• Session နှင့် pairing အတွက် Firestore rule များ
• Core project ရှိ လုံခြုံရေးဆိုင်ရာ စာရွက်စာတမ်းများ

ရင်းမြစ်များ

• ကလေးကင်မရာများမှ မှတ်တမ်းများကို လွတ်လပ်စွာ ဝင်ရောက်ကြည့်ရှုနိုင်ခဲ့သည် · Galaxus
• Baby monitor နှင့် security camera တစ်သန်းကို hacker များက အလွယ်တကူ ကြည့်ရှုနိုင်ခဲ့သည် · The Verge
• ဘယ်သူမှ ကလေးကို ထောင့်ထဲ မထားဘူး · Sammy Azdoufal
• တူညီသော ဖြစ်ရပ်အတွက် မိဘလမ်းညွှန် · Baby Monitor Timmy

← ဘလော့ဂ်သို့ ပြန်သွားရန်