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