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

ਇਸ ਹਾਲਤ ਵਿੱਚ, ਹਮਲਾਵਰ ਇੱਕ ਸਾਂਝਾ ਸੀਕ੍ਰੇਟ ਗਿਣਦਾ ਹੈ S_A ਡਿਵਾਈਸ A ਨਾਲ ਅਤੇ ਇੱਕ ਵੱਖਰਾ ਸਾਂਝਾ ਸੀਕ੍ਰੇਟ S_B ਡਿਵਾਈਸ 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 ਸਰਵਰ ਇਨਕ੍ਰਿਪਟ ਕੀਤਾ ਮੀਡੀਆ ਰੀਲੇ ਕਰਦਾ ਹੈ। ਘੱਟ ਸਮੇਂ ਲਈ ਵੈਧ ਕ੍ਰੈਡੈਂਸ਼ਲ (24h) 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 ਮੀਡੀਆ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਹਮਲਾਵਰ ਨੂੰ ਡਿਵਾਈਸਾਂ ਜਾਂ ਮਾਪਿਆਂ ਨੂੰ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਿਨਾਂ ਕਈ ਥਾਵਾਂ 'ਤੇ ਇਹ ਲੜੀ ਤੋੜਨੀ ਪਵੇਗੀ।

ਹੋਰ ਲੇਖ

← ਬਲੌਗ 'ਤੇ ਵਾਪਸ