Baby Monitor Timmy හි ආරක්ෂිත යුගල කිරීම: ECDH සහ SAS පැහැදිලි කිරීම

Baby Monitor Timmy ශබ්දය සහ වීඩියෝ යැවීමට පෙර, උපාංග දෙකක් එකිනෙකා සොයාගෙන එකිනෙකා විශ්වාස කළ යුතුය. මෙම යුගල කිරීමේ පියවර මුළු ක්‍රියාවලියේම ඉතාමත් වැදගත් මොහොතයි. මෙහිදී Timmy යුගල වන්නේ කෙසේද, ඒ පිටුපස ඇති සංකේතකරණය කුමක්ද, සහ ළඟ සිටින ප්‍රහාරකයෙකුට නොදැනුවත්ව සම්බන්ධතාවය පාලනය කරගත නොහැක්කේ ඇයි යන්න පැහැදිලි කරමි.

ගැටලුව: මගේ උපාංගය කතා කරන්නේ කා සමඟදැයි දන්නේ කෙසේද?

උපාංග දෙකක් පළමු වරට සම්බන්ධ වන විට මූලික ප්‍රශ්නය මෙයයි: උපාංගය A ඇත්තටම උපාංගය B සමඟ කතා කරනවාද, නැතිනම් අතරමැද කෙනෙකු සිටිනවාද? සංකේතකරණයේදී මෙය මැදින්-මැදිහත් වන ප්‍රහාරයක් (MITM) ලෙස හැඳින්වේ.

Timmy මෙය විසඳන්නේ Elliptic Curve Diffie-Hellman (ECDH) යතුරු හුවමාරුවක් Firebase හරහා සිදු කරමින්, පරිශීලකයාගේ දෘශ්‍ය තහවුරු කිරීම.

සමඟ ඒකාබද්ධ කිරීමෙනි. පහත රූපසටහනෙන් සම්පූර්ණ යුගල කිරීමේ ක්‍රියාවලිය එක බැල්මකින් දැක්වේ:

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

සම්පූර්ණ යුගල කිරීමේ ප්‍රොටෝකෝල අනුක්‍රමය — සංස්කරණය කළ හැකි මූලාශ්‍රය: docs/diagrams/pairing-sequence.mmd

පියවර 1: සෑම උපාංගයක්ම යතුරු යුගලයක් සාදයි

යුගල කිරීමේ තිරය විවෘත කළ විට, සෑම උපාංගයක්ම තාවකාලික ECDH යතුරු යුගලයක් P-256 වක්‍රය (secp256r1) මත ජනනය කරයි:

එක් පෞද්ගලික යතුරක් — උපාංගය තුළ පමණක් තබා ගනී
එක් පොදු යතුරක් — Firebase හරහා හුවමාරු කෙරේ

යතුරු සංකේතකරණයට ආරක්ෂිත අහඹු සංඛ්‍යා උත්පාදකයකින් (Random.secure()) භාවිතයෙන් සාදන අතර ඒවා මෙම එක් යුගල කිරීමේ උත්සාහයට පමණක් වලංගුය. සෑම නව උත්සාහයක් සඳහාම අලුත් යතුරු ජනනය කෙරේ.

පියවර 2: Firebase හරහා පොදු යතුරු හුවමාරු කිරීම

උපාංග දෙකකට එකිනෙකා සොයාගැනීමට Timmy අක්ෂර 4ක කේතයක් හමුවන ලක්ෂ්‍යයක් ලෙස භාවිතා කරයි. මෙම කේතය Nearby Connections (Bluetooth Low Energy) හරහා ස්වයංක්‍රීයව සොයාගත හැකි අතර, අතින් ඇතුළත් කළද හැක. එයට සංකේතකරණමය වටිනාකමක් නැත; එය උපාංග දෙකටම එකම Firebase Firestore ලේඛනය සොයාගැනීමට පමණක් උපකාරී වේ.

උපාංග දෙකම කේතය දැනගත් පසු, සෑම එකක්ම තම පොදු ECDH යතුර හවුල් Firestore ලේඛනයකට ලියයි. ඉන්පසු සෑම උපාංගයක්ම එම ලේඛනයෙන් අනෙක් උපාංගයේ පොදු යතුර කියවයි.

වැදගත්ම දේ: යවන්නේ පොදු යතුර පමණි. පෞද්ගලික යතුර කිසිවිටෙක උපාංගයෙන් පිටතට යන්නේ නැත. Firebase ගමනාගමනය නරඹන කෙනෙකුට පොදු යතුරු දැකිය හැකි නමුත්, ඒවායෙන් හවුල් රහස ගණනය කළ නොහැක . මෙය Elliptic Curve Discrete Logarithm Problem (ECDLP) විසඳීමේ දුෂ්කරතාව මත රඳා පවතී.

පියවර 3: හවුල් රහස ගණනය කිරීම

උපාංග දෙකම එකිනෙකාගේ පොදු යතුර සොයාගත් පසු, ඒවා ස්වාධීනව එකම හවුල් රහස:

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

ගණනය කරයි. සෑම උපාංගයක්ම තම පෞද්ගලික යතුර සහ අනෙකාගේ පොදු යතුර පමණක් දැන සිටියත්, ඉලිප්ටික් වක්‍ර ගණිතය මඟින් ගණනය දෙකම එකම ප්‍රතිඵලය ලබාදෙන බව සහතික කරයි.

පියවර 4: තහවුරු කිරීමේ අංකය (SAS)

හවුල් රහසෙන් කෙටි සත්‍යාපන පෙළක් (SAS) ලබාගනී — උපාංග දෙකෙහිම පෙන්වන ඉලක්කම් දෙකක අංකයකි:

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

උපාංග දෙකම එකම අංකය පෙන්වයි — උදාහරණයක් ලෙස, 42. පරිශීලකයා තිර දෙකෙහි අංක ගැළපෙනවාදැයි දෘශ්‍යව සසඳා, සෑම උපාංගයකම වෙන වෙනම තහවුරු කරයි.

ප්‍රහාරකයෙකුට මෙය ව්‍යාජ ලෙස සෑදිය නොහැක්කේ ඇයි

මැදින්-මැදිහත් වන ප්‍රහාරකයෙකු Firebase හි යතුරු හුවමාරුව හසුකරගත යුතුය. විශේෂයෙන්ම, ඔහුට මෙසේ කිරීමට සිදුවේ:

Firestore ලේඛනයේ තබා ඇති සැබෑ පොදු යතුරු තමන්ගේ යතුරු මඟින් ප්‍රතිස්ථාපනය කිරීම
සෑම උපාංගයක් සමඟම වෙන වෙනම හවුල් රහස් පිහිටුවීම

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)

SAS නොගැළපීම හරහා මැදින්-මැදිහත් වන ප්‍රහාර හඳුනාගැනීම — සංස්කරණය කළ හැකි මූලාශ්‍රය: docs/diagrams/mitm-detection.mmd

මෙම අවස්ථාවේදී ප්‍රහාරකයා උපාංගය A සමඟ හවුල් රහසක් S_A ගණනය කරයි සහ උපාංගය B සමඟ වෙනස් හවුල් රහසක් S_B ගණනය කරයි. එබැවින් S_A ≠ S_B, උපාංග වෙනස් තහවුරු කිරීමේ අංක.

ගණනය කරයි. ප්‍රහාරකයාට අංක ගැළපෙන ලෙස කළ නොහැක්කේ:

උපාංගවල පෞද්ගලික යතුරු ඔහු නොදන්නා නිසා
SHA-256 ආපසු හැරවිය නොහැකි නිසා
අහඹු ලෙස ගැළපීමක සම්භාවිතාව 100න් 1ක්

පමණක් වන නිසා. පරිශීලකයා තිරවල වෙනස් අංක දකිමින් යුගල කිරීම අවලංගු කරයි. එවිට ප්‍රහාරය හෙළි වේ.

පියවර 5: යුගල කිරීම සම්පූර්ණ කිරීම

පරිශීලකයා උපාංග දෙකෙහිම තහවුරු කළ පසුව පමණක් යුගල කිරීම සම්පූර්ණ වේ:

එක් අක්ෂර 64ක යුගල කිරීමේ යතුරක් (බිටු 256ක්) හවුල් රහසෙන් ලබාගනී: SHA-256("pair:" + sharedSecret) → pairingKey
ලේඛන යතුර ලබාගන්නේ SHA-256("doc:" + pairingKey) ලෙස වන අතර එය Firestore ලේඛන යතුර ලෙස භාවිතා වේ
සංකේතන යතුර ලබාගන්නේ SHA-256("enc:" + pairingKey) ලෙස වන අතර එය සංකේතනය කළ සංඥාකරණය සඳහා AES-256-GCM යතුර සපයයි
උපාංග දෙකම එකම යුගල කිරීමේ යතුර සුරකිමින් මාදිලි තේරීමට යයි

මෙතැන් සිට ඉදිරියට සම්බන්ධ වීමේ සියලු උත්සාහ (Firestore සංඥාකරණය, WebRTC සැකසුම) හවුල් AES-256-GCM යතුරෙන් සංකේතනය වේ. යුගල කිරීමේ යතුර කිසිවිටෙක බැක්එන්ඩ් වෙත යවන්නේ නැත; ලේඛන හඳුනාගැනුම ලෙස භාවිතා කරන්නේ එහි SHA-256 හැෂ් අගය පමණි.

පද්ධති ගෘහ නිර්මාණය

පහත රූපසටහනෙන් යුගල කිරීම සහ සන්නිවේදනයට සම්බන්ධ කොටස් දැක්වේ:

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

පද්ධති ගෘහ නිර්මාණයේ දළ විශ්ලේෂණය — සංස්කරණය කළ හැකි මූලාශ්‍රය: docs/diagrams/pairing-architecture.mmd

සන්නිවේදන මාර්ග විස්තරයෙන්:

WebRTC peer-to-peer (ඝන රේඛාව): ශබ්දය, වීඩියෝ සහ DataChannel උපාංග අතර සෘජුව ගලා යයි — DTLS-SRTP මඟින් සංකේතනය කර ඇත. කිසිදු සේවාදායකයකට මෙම දත්ත නොපෙනේ.
Firebase Firestore (සම්පූර්ණ රේඛාව): යුගල කිරීමේ දත්ත (ECDH යතුරු) සහ සංඥාකරණය (SDP/ICE) Firestore හරහා යයි — AES-256-GCM මඟින් අන්තයේ සිට අන්තය දක්වා සංකේතනය කර ඇත. Firebase ට දත්ත විකේතනය කළ නොහැක.
STUN සේවාදායකය: සෘජු peer-to-peer සම්බන්ධතාවයක් පිහිටුවිය හැකි ලෙස උපාංග දෙකම තම පොදු IP ලිපිනය සොයාගනී.
TURN relay: සෘජු සම්බන්ධතාවයක් කළ නොහැකි විට (උදා., ජංගම දත්ත මත), තෝරාගත් දේශීය හෝ Cloudflare TURN සේවාදායකය සංකේතනය කළ මාධ්‍ය දත්ත රිලේ කරයි. පැය 24කට වලංගු අක්තපත්‍ර Firebase Cloud Functions හරහා ලබාගනී.
Bluetooth LE (තිත් රේඛාව): Nearby Connections ළඟ ඇති උපාංග ස්වයංක්‍රීයව සොයාගනී — යවන්නේ හමුවීමේ කේතය පමණි, යතුරු ද්‍රව්‍ය නොවේ.

විකල්පය: කේතය අතින් ඇතුළත් කිරීම

Bluetooth නොමැති නම් (උදා., පැරණි උපාංගවල), අක්ෂර 4ක කේතය අතින් ටයිප් කළ හැක. අතින් ඇතුළත් කිරීමේදී එකම ECDH යතුරු හුවමාරුව සහ එකම SAS තහවුරු කිරීම ස්වයංක්‍රීය යුගල කිරීමේදී මෙන්ම භාවිතා වේ. වෙනස ඇත්තේ BLE හරහා සොයාගන්නවා වෙනුවට කේතය පරිශීලකයා කියවා ටයිප් කිරීම පමණි.

අවස්ථා දෙකේදීම ECDH යතුරු හුවමාරුව Firebase හරහා සිදුවන නිසා, ආරක්ෂාව සමානයි. අක්ෂර 4ක කේතය හමුවන ලක්ෂ්‍යයක් පමණි; සැබෑ සංකේතනය ECDH මඟින් ලබාගත් බිටු 256ක යතුර මත පදනම් වේ.

සාරාංශය

ආරක්ෂක ක්‍රමවේදය	ආරක්ෂා කරන්නේ
ECDH යතුරු හුවමාරුව (P-256)	යතුරු හුවමාරු ගමනාගමනයට රහසින් සවන් දීමෙන්
තාවකාලික යතුරු යුගල	ඉදිරි රහස්‍යතාව — පෙර යුගල කිරීම් ආරක්ෂිතව පවතී
දෘශ්‍ය තහවුරු කිරීමේ අංකය (SAS)	යතුරු හුවමාරුව අතරතුර මැදින්-මැදිහත් වන ප්‍රහාරයෙන් (MITM)
ලේඛන යතුර ලෙස SHA-256 හැෂ් අගය	Firestore වෙතින් කේතය උකහාගැනීමෙන්
AES-256-GCM සංකේතනය	සංඥාකරණ දත්තට රහසින් සවන් දීමෙන්
දෙපාර්ශ්වීය තහවුරු කිරීම	පරිශීලකයා නොදැන එක්පාර්ශ්වීය යුගල කිරීමෙන්
DTLS-SRTP (WebRTC)	ශබ්දය/වීඩියෝවට රහසින් සවන් දීමෙන්

මෙම ස්තර එකට ක්‍රියා කරයි: ECDH යතුරු හුවමාරුව ආරක්ෂා කරයි, තහවුරු කිරීමේ අංකය MITM ප්‍රහාරයෙන් ආරක්ෂා කරයි, AES-256-GCM සංඥාකරණය ආරක්ෂා කරයි, සහ WebRTC මාධ්‍ය දත්ත ආරක්ෂා කරයි. උපාංග හෝ දෙමාපියන් නොදැන ප්‍රහාරකයෙකුට ස්ථාන කිහිපයකින්ම මෙම ආරක්ෂක දාමය බිඳිය යුතුය.

තවත් ලිපි

← බ්ලොගයට ආපසු