নিরাপত্তা ব্যাখ্যা

Meari বেবি ক্যামেরার নিরাপত্তা দুর্বলতা: Timmy কীভাবে আলাদা

Meari-এর ঘটনা দেখায়, সুন্দরভাবে তৈরি লগইনই যথেষ্ট নয়। বেবি মনিটরের নিরাপত্তা নির্ভর করে স্থাপত্য, অনুমোদন ও কী ব্যবস্থাপনার ওপর।

লেখক প্রকাশিত হালনাগাদ

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 কি ব্যক্তিগত, অল্প সময়ের জন্য কার্যকর এবং প্রতি ডিভাইসে অনুমোদিত?
  • কী কি অ্যাপের ভেতরে স্থির থাকার বদলে প্রতি ডিভাইস বা পেয়ারিংয়ের জন্য তৈরি হয়?
  • ব্রোকার কি শুধু আপনার নিজের ডিভাইসের জন্যই বার্তা পাঠাতে পারে?
  • পেয়ারিংয়ে কি মানুষ মাঝপথে আক্রমণের চেষ্টা বুঝতে পারে?

কোড দেখুন

সূত্র

← ব্লগে ফিরে যান