Ukubhangqa okuphephile ku-Baby Monitor Timmy

Ngaphambi kokuba i-Baby Monitor Timmy idlulise umsindo nevidiyo, amadivayisi amabili kufanele atholane futhi athembane. Lesi sinyathelo sokubhangqa siyisikhathi esibaluleke kakhulu kulo lonke uhlelo. Lapha ngichaza indlela i-Timmy ebhangqa ngayo amadivayisi, ubuchwepheshe bokubhala ngemfihlo obusekela lokhu, nokuthi kungani umhlaseli oseduze engakwazi ukuthatha uxhumano ngaphandle kokubonwa.

Inkinga: Idivayisi yami yazi kanjani ukuthi ikhuluma nobani?

Lapho amadivayisi amabili exhuma okokuqala, umbuzo oyinhloko uthi: ingabe iDivayisi A ikhuluma ngempela neDivayisi B, noma kukhona umuntu ophakathi nendawo? Ku-cryptography, lokhu kubizwa ngokuthi ukuhlasela komuntu ophakathi nendawo (MITM).

I-Timmy ixazulula lokhu ngokusebenzisa ukushintshisana ngokhiye kwe-Elliptic Curve Diffie-Hellman (ECDH) nge-Firebase, kuhlanganiswe nokuqinisekiswa ngumsebenzisi ngokubheka.

Umdwebo olandelayo ubonisa lonke uhlelo lokubhangqa kafushane:

sequenceDiagram
    autonumber
    participant A as 📱 Device A
    participant F as ☁️ Firebase
    participant B as 📱 Device B

    Note over A,B: Phase 1 — Discovery

    A->>A: Generate ECDH key pair (P-256)
    B->>B: Generate ECDH key pair (P-256)

    alt Auto-Pairing (Nearby BLE)
        A-->>B: BLE broadcast: SBM:XKQM
        B-->>A: BLE broadcast: SBM:R7NP
        Note over A,B: Lower code wins → determines creator/joiner
    else Manual Pairing
        A->>A: Display 4-char code
        Note right of A: User reads code
        B->>B: User enters code
    end

    Note over A,B: Phase 2 — ECDH Key Exchange

    A->>F: Write public key (PubA) to meeting doc
    B->>F: Write public key (PubB) to meeting doc
    F-->>B: Read PubA
    F-->>A: Read PubB

    Note over A,B: Phase 3 — Shared Secret

    A->>A: sharedSecret = ECDH(privA, PubB)
    B->>B: sharedSecret = ECDH(privB, PubA)
    Note over A,B: Both compute identical 32-byte secret

    A->>A: SAS = SHA-256("sas:" + sort(PubA,PubB) + secret) → 2-digit number
    B->>B: SAS = SHA-256("sas:" + sort(PubA,PubB) + secret) → 2-digit number

    Note over A,B: Phase 4 — Visual Verification

    A->>A: Display SAS: 42
    B->>B: Display SAS: 42
    Note over A,B: 👤 User compares numbers on both screens

    A->>A: User confirms ✓
    B->>B: User confirms ✓

    Note over A,B: Phase 5 — Key Derivation

    A->>A: pairingKey = SHA-256("pair:" + secret)
    B->>B: pairingKey = SHA-256("pair:" + secret)
    A->>A: docKey = SHA-256("doc:" + pairingKey)
    A->>A: encKey = SHA-256("enc:" + pairingKey)

    Note over A,B: ✅ Paired — all future signaling encrypted with AES-256-GCM
      

Isinyathelo 1: Idivayisi ngayinye yakha ipheya yokhiye

Lapho kuvulwa isikrini sokubhangqa, idivayisi ngayinye yakha ipheya yokhiye ye-ECDH yesikhashana egobeni le-P-256 (secp256r1):

• Ukhiye oyimfihlo — uhlala kudivayisi kuphela
• Ukhiye wasesidlangalaleni — ushintshaniswa nge-Firebase

Okhiye bakhiwa kusetshenziswa umkhiqizi wezinombolo ezingahleliwe ovikelekile ngokwe-cryptography (Random.secure()) futhi basebenza kulowo mzamo owodwa wokubhangqa kuphela. Okhiye abasha bayakhiwa ngomzamo ngamunye omusha.

Isinyathelo 2: Ukushintshisana ngokhiye basesidlangalaleni nge-Firebase

Ukuze amadivayisi amabili atholane, i-Timmy isebenzisa ikhodi yezinhlamvu ezi-4 njengendawo yokuhlangana. Le khodi ingatholwa ngokuzenzakalela nge Nearby Connections (Bluetooth Low Energy) noma ifakwe ngesandla. Ayinakho ukubaluleka kwe-cryptography; yenza nje amadivayisi womabili athole idokhumenti efanayo ye-Firebase Firestore.

Uma womabili amadivayisi eseyazi ikhodi, ngalinye libhala ukhiye walo we-ECDH wasesidlangalaleni kudokhumenti eyabiwe ye Firestore. Bese idivayisi ngayinye ifunda ukhiye wasesidlangalaleni wenye idivayisi kuleyo dokhumenti.

Okubalulekile: kuthunyelwa ukhiye wasesidlangalaleni kuphela. Ukhiye oyimfihlo awulokothi uphume kudivayisi. Noma ubani obuka ukuxhumana kwe-Firebase ubona okhiye basesidlangalaleni, kodwa akakwazi ukubala imfihlo eyabiwe ngabo. Lokhu kusekelwe ebunzimeni be Elliptic Curve Discrete Logarithm Problem (ECDLP).

Isinyathelo 3: Ukubala imfihlo eyabiwe

Lapho womabili amadivayisi esethole ukhiye wasesidlangalaleni womunye nomunye, azibala ngokuzimela le mfihlo eyabiwe:

sharedSecret = ECDH(myPrivateKey, remotePublicKey)
             → 32 bytes (identical on both devices)

Izibalo zamagobe e-elliptic ziqinisekisa ukuthi zombili izibalo zinikeza umphumela ofanayo, nakuba idivayisi ngayinye yazi ukhiye wayo oyimfihlo kuphela nokhiye wasesidlangalaleni wowenye.

Isinyathelo 4: Inombolo yokuqinisekisa (SAS)

Emfihlweni eyabiwe, kwakhiwa i-Short Authentication String (SAS) — inombolo enamadijithi amabili eboniswa kuwo womabili amadivayisi:

hash   = SHA-256("sas:" + sort(pubkeyA, pubkeyB) + sharedSecret)
number = (hash[0] × 256 + hash[1]) mod 100   → 00 to 99

Womabili amadivayisi abonisa inombolo efanayo — isibonelo, 42. Umsebenzisi ubheka ukuthi izinombolo ezikuzikrini zombili ziyafana yini, bese eqinisekisa ku divayisi ngayinye ngokwehlukana.

Kungani umhlaseli engakwazi ukukopela lokhu

Umhlaseli ophakathi nendawo kuzodingeka angenelele ekushintshisaneni ngokhiye ku-Firebase. Ngokuqondile, kuzodingeka:

1. Ashintshe okhiye bangempela basesidlangalaleni abagcinwe kudokhumenti ye-Firestore afake abakhe
2. Akhe izimfihlo ezabiwe ezihlukene nedivayisi ngayinye

sequenceDiagram
    autonumber
    participant A as 📱 Device A
    participant M as 🕵️ Attacker (MITM)
    participant B as 📱 Device B

    Note over A,B: Attacker intercepts the Firebase key exchange

    A->>A: Generate key pair (privA, PubA)
    B->>B: Generate key pair (privB, PubB)
    M->>M: Generate TWO key pairs (privM1, PubM1) + (privM2, PubM2)

    A->>M: Write PubA to Firebase
    M->>M: Replace PubA with PubM1
    M->>B: B reads PubM1 (thinks it is PubA)

    B->>M: Write PubB to Firebase
    M->>M: Replace PubB with PubM2
    M->>A: A reads PubM2 (thinks it is PubB)

    Note over A,B: Each device computes a DIFFERENT shared secret

    A->>A: secret_A = ECDH(privA, PubM2)
    M->>M: secret_A = ECDH(privM2, PubA)
    M->>M: secret_B = ECDH(privM1, PubB)
    B->>B: secret_B = ECDH(privB, PubM1)

    Note over A,M: secret_A ≠ secret_B

    A->>A: SAS_A = SHA-256("sas:" + sort(PubA,PubM2) + secret_A) → 73
    B->>B: SAS_B = SHA-256("sas:" + sort(PubM1,PubB) + secret_B) → 18

    rect rgb(255, 230, 230)
        Note over A,B: ❌ User sees DIFFERENT numbers!
        A->>A: Display: 73
        B->>B: Display: 18
        Note over A,B: 👤 User notices mismatch → cancels pairing
    end

    Note over A,B: 🛡️ Attack detected — MITM cannot force SAS match (P = 1/100)
      

Kulokhu, umhlaseli ubala imfihlo eyabiwe S_A neDivayisi A kanye nemfihlo eyabiwe ehlukile S_B neDivayisi B. Njengoba S_A ≠ S_B, amadivayisi abala izinombolo zokuqinisekisa ezihlukene.

Umhlaseli angeke enze izinombolo zifane ngoba:

• Abazi okhiye abayimfihlo bamadivayisi
• I-SHA-256 ayibuyiseki
• Amathuba okufana ngengozi angu 1 kwangu-100

Umsebenzisi ubona izinombolo ezingafani ezikrinini bese ekhansela ukubhangqa. Ngaleso sikhathi, ukuhlasela sekubonakele.

Isinyathelo 5: Ukuqedela ukubhangqa

Ukubhangqa kuqedwa kuphela ngemva kokuba umsebenzisi eseqinisekise inombolo yokuqinisekisa kuwo womabili amadivayisi :

1. Ukhiye wokubhangqa onezinhlamvu ezingama-64 (amabhithi angu-256) utholakala emfihlweni eyabiwe: SHA-256("pair:" + sharedSecret) → pairingKey
2. Ukhiye wedokhumenti utholakala njengokuthi SHA-256("doc:" + pairingKey) futhi usebenza njengokhiye wedokhumenti ye-Firestore
3. Ukhiye wokubethela utholakala njengokuthi SHA-256("enc:" + pairingKey) futhi unikeza ukhiye we-AES-256-GCM wokubethela ulwazi lokusungula uxhumano
4. Womabili amadivayisi agcina ukhiye ofanayo wokubhangqa bese eya ekukhetheni imodi

Kusukela lapha kuya phambili, yonke imizamo yokuxhuma elandelayo (ukushintshisana ngolwazi lokusungula uxhumano nge-Firestore nokusetha i-WebRTC) ibethelwa ngokhiye owabiwe we-AES-256-GCM. Ukhiye wokubhangqa awulokothi uthunyelwe ohlelweni lwangemuva; kusetshenziswa i-hash yawo ye-SHA-256 kuphela njengesihlonzi sedokhumenti.

Ukwakheka kwesistimu

Umdwebo olandelayo ubonisa izingxenye ezibandakanyekayo ekubhangqeni nasekuxhumaneni:

flowchart TB
    BABY["📱 Baby Phone
Baby Mode"]
    PARENT["📱 Parent Phone
Parent Mode"]

    BABY <==>|"🔒 WebRTC Peer-to-Peer · DTLS-SRTP
Audio · Video · DataChannel"| PARENT
    BABY -.-|"🔵 Bluetooth LE · Nearby
Auto-Discovery"| PARENT

    subgraph FIREBASE["☁️ Firebase (Google Cloud)"]
        direction LR
        AUTH["🪪 Anonymous
Authentication"]
        FS["📄 Firestore
Pairing + Signaling"]
        CF["⚡ Cloud Functions
getTurnCredentials"]
    end

    BABY <-->|"🔐 AES-256-GCM encrypted
SDP · ICE · ECDH keys"| FS
    FS <-->|"🔐 AES-256-GCM encrypted
SDP · ICE · ECDH keys"| PARENT

    BABY -.->|Token| AUTH
    PARENT -.->|Token| AUTH

    STUN["📡 STUN server
stun.cloudflare.com:3478"]
    TURN["🔄 TURN relay
local or Cloudflare"]

    BABY & PARENT -->|Short-lived credentials| CF
    CF -->|local first, Cloudflare fallback| TURN

    BABY & PARENT -.->|NAT Traversal| STUN

    BABY -.->|"Relay Fallback"| TURN
    TURN -.->|"Relay Fallback"| PARENT

    style BABY fill:#FBF6F0,stroke:#B5734A,stroke-width:2px
    style PARENT fill:#FBF6F0,stroke:#B5734A,stroke-width:2px
    style FIREBASE fill:#fff5f5,stroke:#E9B44C,stroke-width:2px
    style AUTH fill:#E9B44C,stroke:#2B2D42
    style FS fill:#E9B44C,stroke:#2B2D42
    style CF fill:#E9B44C,stroke:#2B2D42
    style STUN fill:#F6E3D2,stroke:#B5734A
    style TURN fill:#7BC47F,stroke:#2B2D42
      

Izindlela zokuxhumana ngokuningiliziwe:

• I-WebRTC ye-peer-to-peer (umugqa owugqinsi): Umsindo, ividiyo, ne-DataChannel kudlula ngqo phakathi kwamadivayisi — kubethelwe nge-DTLS-SRTP. Ayikho iseva ebona le datha.
• I-Firebase Firestore (umugqa oqinile): Idatha yokubhangqa (okhiye be-ECDH) nolwazi lokusungula uxhumano (SDP/ICE) kudlula ku-Firestore — kubethelwe kusukela kolunye uhlangothi kuya kolunye nge-AES-256-GCM. I-Firebase ayikwazi ukususa ukubethelwa kwedatha.
• Iseva ye-STUN: Womabili amadivayisi athola ikheli lawo le-IP lomphakathi ukuze kusungulwe uxhumano oluqondile lwe-peer-to-peer.
• I-TURN relay: Uma uxhumano oluqondile lungenzeki (isib., kudatha yeselula), iseva ye-TURN yendawo ekhethiwe noma ye-Cloudflare idlulisa imidiya ebethelwe. Iziqinisekiso zesikhashana (amahora angu-24) zitholwa nge-Firebase Cloud Functions.
• I-Bluetooth LE (umugqa onamachashazi): I-Nearby Connections ithola amadivayisi aseduze ngokuzenzakalela — kudluliswa ikhodi yokuhlangana kuphela, akukho zinto zokhiye.

Okunye: Ukufaka ikhodi ngesandla

Uma i-Bluetooth ingatholakali (isib., kumadivayisi amadala), ikhodi yezinhlamvu ezi-4 ingafakwa nangesandla. Ukufaka ngesandla kusebenzisa ukushintshisana ngokhiye kwe-ECDH okufanayo nokuqinisekiswa kwe-SAS okufanayo njengokubhangqa okuzenzakalelayo. Umehluko kuphela ukuthi ikhodi ifundwa bese ifakwa ngumsebenzisi, kunokuba itholwe nge-BLE.

Ngenxa yokuthi ukushintshisana ngokhiye kwe-ECDH kwenzeka nge-Firebase kuzo zombili izimo, ukuphepha kuyafana. Ikhodi yezinhlamvu ezi-4 iyindawo yokuhlangana kuphela; ukubethela kwangempela kusekelwe kukhiye wamabhithi angu-256 otholakala ku-ECDH.

Isifinyezo

Lezi zingqimba zisebenza ndawonye: i-ECDH ivikela ukushintshisana ngokhiye, inombolo yokuqinisekisa ivikela ekuhlaselweni kwe-MITM, i-AES-256-GCM ivikela ulwazi lokusungula uxhumano, kanti i-WebRTC ivikela imidiya. Kuzodingeka umhlaseli aphule lolu chungechunge ezindaweni eziningana ngaphandle kokuba amadivayisi noma abazali babone.

Ezinye izihloko

• Ubuchwepheshe obusemuva kwe-Timmy
• Ubumfihlo ekamelweni lengane
• Kungani izinhlelo zokuqapha ingane kufanele zibe yi-open source

← Buyela kubhulogi