Galaxus ने ऐसे बेबी-कैमरा रिकॉर्डिंग्स की रिपोर्ट की जो बिना रोक-टोक उपलब्ध थीं; The Verge ने बताया कि लगभग 1.1 मिलियन Meari डिवाइस प्रभावित हुए। मेरे लिए इससे सीधी सीख यह है: अगर पीछे का प्लेटफ़ॉर्म संदेशों, तस्वीरों या कुंजियों को हर डिवाइस के लिए साफ़ तौर पर अलग नहीं रखता, तो लॉगिन बच्चे के कमरे की सुरक्षा नहीं कर सकता। Timmy दुनिया की हर सुरक्षा समस्या हल नहीं करता। लेकिन Timmy के अहम मीडिया और पेयरिंग रहस्य किसी क्लाउड-कैमरा प्लेटफ़ॉर्म में नहीं रहते।
Meari मामले में क्या विफल हुआ लगता है
सार्वजनिक रिपोर्टों में एक व्हाइट-लेबल प्लेटफ़ॉर्म का वर्णन है। कई दिखने में अलग ब्रांडों ने ऐसे कैमरे बेचे जो एक ही Meari/CloudEdge इन्फ्रास्ट्रक्चर पर निर्भर थे। इसलिए यह घटना अहम है: जब साझा प्लेटफ़ॉर्म अनुमति की सीमा गलत तय करता है, तो सिर्फ़ एक कैमरा कमजोर नहीं होता—पूरा डिवाइस बेड़ा जोखिम में पड़ता है।
बताया गया पैटर्न सिर्फ़ कमजोर डिफ़ॉल्ट पासवर्ड से आगे जाता है। स्रोतों में पर्याप्त प्रति-डिवाइस सदस्यता नियंत्रण के बिना MQTT संदेशों, सार्वजनिक रूप से पहुँच योग्य इमेज URL, कमजोर इमेज छिपाव और स्थिर या ऐप से निकाली जा सकने वाली कुंजियों का ज़िक्र है। यह प्लेटफ़ॉर्म की विफलता है: इन्फ्रास्ट्रक्चर ऐसा डेटा दिखा सकता था जो कभी किसी दूसरे खाते को उपलब्ध नहीं होना चाहिए था।
| क्लाउड-कैमरा का जोखिम | Timmy का वैकल्पिक डिज़ाइन |
|---|---|
| बैकएंड इमेज इवेंट्स को स्टोर या वितरित करता है। | Timmy में बच्चे के कमरे की तस्वीरों का कोई क्लाउड आर्काइव नहीं है; मीडिया लाइव WebRTC है। |
| ब्रोकर या बकेट को हर डिवाइस के लिए अनुमति बिल्कुल सही तरीके से देनी होती है। | Firestore में सिर्फ़ पेयरिंग और सिग्नलिंग डेटा रहता है; SDP/ICE लिखे जाने से पहले एन्क्रिप्ट होता है। |
| स्थिर कुंजियाँ पूरे डिवाइस बेड़े को प्रभावित कर सकती हैं। | हर पेयरिंग डिवाइसों पर अपनी P-256 ECDH-आधारित कुंजी बनाती है। |
| रिले पाथ को गलती से मीडिया एक्सेस समझा जा सकता है। | TURN एन्क्रिप्टेड SRTP पैकेट आगे भेजता है, लेकिन उसे मीडिया कुंजियाँ नहीं मिलतीं। |
Timmy रहस्य कैसे बनाता है
चार कैरेक्टर वाला Timmy कोड जानबूझकर रहस्य नहीं है। कोड में वह केवल मिलाने का बिंदु है: ऐप उससे एक meetingKey बनाता है, ताकि दोनों डिवाइस एक ही Firestore सार्वजनिक-कुंजी एक्सचेंज ढूँढ सकें। निजी ECDH कुंजियाँ कभी डिवाइसों से बाहर नहीं जातीं।
फिर दोनों डिवाइस एक ही P-256 ECDH साझा रहस्य की गणना करते हैं। पेयरिंग कुंजी स्थानीय रूप से निकाली जाती है। दो अंकों वाला SAS साझा रहस्य और क्रमबद्ध दोनों सार्वजनिक कुंजियों से निकाला जाता है। अगर उस कुंजी एक्सचेंज से छेड़छाड़ हो, तो डिवाइस अलग-अलग नंबर दिखाते हैं, जिससे उपयोगकर्ता समझ जाते हैं कि पेयरिंग की पुष्टि नहीं करनी चाहिए।
sequenceDiagram
participant Baby as Baby device
participant Firestore as Firestore meeting point
participant Parent as Parent device
participant Turn as TURN relay
Baby->>Baby: Generate P-256 ECDH keypair
Parent->>Parent: Generate P-256 ECDH keypair
Baby->>Firestore: Write public key only under meetingKey
Parent->>Firestore: Write public key only under meetingKey
Firestore-->>Baby: Parent public key
Firestore-->>Parent: Baby public key
Baby->>Baby: Compute sharedSecret + SAS
Parent->>Parent: Compute sharedSecret + SAS
Baby-->>Parent: Humans compare SAS on both screens
Baby->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
Parent->>Firestore: Write SDP/ICE encrypted with AES-256-GCM
Baby-)Turn: WebRTC media as DTLS/SRTP packets
Turn-)Parent: Relay forwards encrypted packets
Note over Turn: TURN sees network metadata, not media keys
Timmy की सरल सुरक्षा श्रृंखला: Firestore मिलाने और सिग्नलिंग ट्रांसपोर्ट के लिए है; TURN केवल रिले है; मीडिया WebRTC-एन्क्रिप्टेड रहता है।
WebRTC मीडिया को चुपचाप क्यों नहीं देखा जा सकता
WebRTC सिर्फ़ “वीडियो भेजना” नहीं है। मीडिया शुरू होने से पहले डिवाइस DTLS हैंडशेक करते हैं। ऑडियो और वीडियो की SRTP कुंजियाँ इसी सुरक्षित ट्रांसपोर्ट से निकाली जाती हैं। फिर मीडिया पैकेट SRTP के रूप में एन्क्रिप्ट होते हैं। TURN सर्वर इन पैकेटों को आगे भेज सकता है, लेकिन उसके पास ऑडियो या वीडियो खोलने के लिए ज़रूरी कुंजियाँ नहीं होतीं।
Timmy इससे पहले एक और परत जोड़ता है: SDP ऑफ़र, SDP आंसर और ICE कैंडिडेट्स जैसा सिग्नलिंग डेटा Firestore तक पहुँचने से पहले AES-256-GCM से एन्क्रिप्ट होता है। Firestore डिवाइसों को कनेक्शन तय करने में मदद करता है; यह वह जगह नहीं है जहाँ सादा वीडियो, ऑडियो या सिग्नलिंग डेटा रखा जाना चाहिए।
Timmy क्या दावा नहीं करता
किसी गंभीर बेबी मॉनिटर को यह दावा नहीं करना चाहिए कि उसे हैक नहीं किया जा सकता। अगर फ़ोन से समझौता हो जाए, तो किसी भी ऐप पर हमला हो सकता है। दुर्भावनापूर्ण ऐप बिल्ड जोखिम के मॉडल को बदल देता है। सर्वर कॉन्फ़िगरेशन सही रहना भी ज़रूरी है। Timmy का दावा इससे सीमित है: यह बैकएंड पर पढ़े जा सकने वाले बच्चे के कमरे के मीडिया निशानों से बचता है और सुरक्षा के लिए अहम पेयरिंग लॉजिक को सार्वजनिक कोर प्रोजेक्ट में जाँचने योग्य बनाता है।
किसी भी बेबी कैमरे के बारे में पूछने लायक सवाल
- क्या विक्रेता तस्वीरें या क्लिप स्टोर करता है?
- क्या मीडिया URL निजी, थोड़े समय के लिए मान्य और हर डिवाइस के लिए अलग से अधिकृत हैं?
- क्या कुंजियाँ ऐप के भीतर स्थिर रखने के बजाय हर डिवाइस या पेयरिंग के लिए बनाई जाती हैं?
- क्या ब्रोकर केवल उसी डिवाइस के संदेश पहुँचा सकता है जो वास्तव में आपका है?
- क्या पेयरिंग में व्यक्ति को मैन-इन-द-मिडल कोशिश पहचानने का मौका मिलता है?
कोड पढ़ें
- Timmy Core में ECDH और SAS
- मीटिंग कुंजी, दस्तावेज़ कुंजी और AES-GCM
- सेशन और पेयरिंग के लिए Firestore नियम
- कोर प्रोजेक्ट में सुरक्षा दस्तावेज़
स्रोत
- बेबी कैमरों की रिकॉर्डिंग्स बिना रोक-टोक उपलब्ध · Galaxus
- दस लाख बेबी मॉनिटर और सुरक्षा कैमरे हैकर्स आसानी से देख सकते थे · The Verge
- कोई भी बेबी को कोने में नहीं रखता · Sammy Azdoufal
- इसी घटना पर माता-पिता के लिए गाइड · Baby Monitor Timmy