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)

सामायिक गुपितातून एक Short Authentication String (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 पीअर-टू-पीअर (जाड रेषा): ऑडिओ, व्हिडिओ आणि DataChannel थेट डिव्हाइसदरम्यान प्रवाहित होतात — आणि DTLS-SRTP ने एन्क्रिप्ट केलेले असतात. कोणत्याही सर्व्हरला हा डेटा दिसत नाही.
Firebase Firestore (सलग रेषा): पेअरिंग डेटा (ECDH कळा) आणि सिग्नलिंग (SDP/ICE) Firestore मधून जातात — AES-256-GCM ने एंड-टू-एंड एन्क्रिप्टेड. Firebase हा डेटा डिक्रिप्ट करू शकत नाही.
STUN सर्व्हर: थेट पीअर-टू-पीअर कनेक्शन तयार करता यावे म्हणून दोन्ही डिव्हाइस आपला सार्वजनिक IP पत्ता शोधतात.
TURN रिले: थेट कनेक्शन शक्य नसेल (उदा., मोबाइल डेटावर), तर निवडलेला स्थानिक किंवा 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 मीडियाचे संरक्षण करते. हल्लेखोराला डिव्हाइस किंवा पालकांना न कळता ही साखळी अनेक ठिकाणी तोडावी लागेल.

आणखी लेख

← ब्लॉगकडे परत