በ 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 ደግሞ ሚዲያውን ይጠብቃል። መሣሪያዎቹ ወይም ወላጆቹ ሳያውቁ አጥቂ ይህን ሰንሰለት በብዙ ቦታዎች መስበር ይኖርበታል።

ተጨማሪ ጽሑፎች

← ወደ ብሎግ ተመለስ