Meari બેબી કેમેરાની સુરક્ષા ખામી: Timmy શું અલગ કરે છે

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 ખાનગી, ટૂંકા સમય માટે માન્ય અને દરેક ડિવાઇસ માટે અધિકૃત છે?
શું કીઓ ઍપમાં સ્થિર રાખવાને બદલે દરેક ડિવાઇસ અથવા પેરિંગ માટે બનાવાય છે?
શું બ્રોકર ફક્ત તમારા માલિકીના ડિવાઇસ માટે જ સંદેશાઓ પહોંચાડી શકે છે?
શું પેરિંગ વ્યક્તિને મૅન-ઇન-ધ-મિડલ પ્રયાસ ધ્યાનમાં લેવા દે છે?

કોડ વાંચો

સ્ત્રોતો

← બ્લોગ પર પાછા જાઓ