ຊ່ອງໂຫວ່ຄວາມປອດໄພຂອງກ້ອງເບິ່ງເດັກ Meari: Timmy ເຮັດຫຍັງແຕກຕ່າງ

Galaxus ລາຍງານວ່າມີໄຟລ໌ບັນທຶກຈາກກ້ອງເບິ່ງເດັກທີ່ໃຜກໍເຂົ້າເບິ່ງໄດ້; The Verge ລາຍງານວ່າອຸປະກອນ Meari ປະມານ 1.1 ລ້ານເຄື່ອງໄດ້ຮັບຜົນກະທົບ. ສຳລັບຂ້ອຍ ບົດຮຽນຈາກເລື່ອງນີ້ແມ່ນຊັດເຈນ: ການເຂົ້າລະບົບບໍ່ສາມາດປົກປ້ອງຫ້ອງເດັກໄດ້ ຖ້າແພລດຟອມທີ່ຢູ່ເບື້ອງຫຼັງບໍ່ແຍກຂໍ້ຄວາມ, ຮູບພາບ ຫຼືຄີຂອງແຕ່ລະອຸປະກອນອອກຈາກກັນຢ່າງຊັດເຈນ. Timmy ບໍ່ໄດ້ແກ້ບັນຫາຄວາມປອດໄພທຸກຢ່າງໃນໂລກ. ແຕ່ຄີລັບສຳຄັນສຳລັບສື່ ແລະການຈັບຄູ່ຂອງ Timmy ບໍ່ໄດ້ຖືກເກັບໄວ້ໃນແພລດຟອມກ້ອງຄລາວ.

ຮາດແວ ຫຼື ແອັບ ບໍ່ແມ່ນຈຸດແບ່ງທີ່ແທ້ຈິງ

ກ້ອງເບິ່ງເດັກແບບອຸປະກອນ ແລະແອັບເບິ່ງເດັກທີ່ໃຊ້ໂທລະສັບ ຕ່າງກໍພົບບັນຫາຫຼັກດຽວກັນ: ໄມໂຄຣໂຟນ ແລະກ້ອງທີ່ເຊື່ອມຕໍ່ເຄືອຂ່າຍຖືກວາງໄວ້ໃນຫ້ອງສ່ວນຕົວພາຍໃນເຮືອນ. ສິ່ງສຳຄັນບໍ່ແມ່ນວ່າຜະລິດຕະພັນເປັນຮາດແວ ຫຼືຊອບແວ ແຕ່ແມ່ນວ່າບັນຊີ, ອຸປະກອນ, ຕົວກາງສົ່ງຂໍ້ຄວາມ, ບ່ອນເກັບຂໍ້ມູນ, ຕົວສົ່ງຕໍ່ ແລະຄີ ຖືກອອກແບບໃຫ້ບັນຊີອື່ນບໍ່ສາມາດເຂົ້າເຖິງເຊສຊັນຂອງຜູ້ອື່ນຢ່າງງຽບໆໄດ້ຫຼືບໍ່.

ສິ່ງທີ່ເບິ່ງຄືວ່າລົ້ມເຫຼວໃນກໍລະນີ Meari

ລາຍງານທີ່ເຜີຍແຜ່ຕໍ່ສາທາລະນະລະບຸວ່າ ນີ້ເປັນແພລດຟອມແບບ white-label. ຫຼາຍຍີ່ຫໍ້ທີ່ວາງຂາຍໃນຕະຫຼາດໄດ້ຂາຍກ້ອງທີ່ອາໄສໂຄງສ້າງພື້ນຖານ Meari/CloudEdge ດຽວກັນ. ນັ້ນຄືເຫດຜົນທີ່ເຫດການນີ້ສຳຄັນ: ເມື່ອແພລດຟອມທີ່ໃຊ້ຮ່ວມກັນກຳນົດຂອບເຂດການອະນຸຍາດຜິດ ຜົນທີ່ຕາມມາບໍ່ແມ່ນພຽງຊ່ອງໂຫວ່ຂອງກ້ອງໜຶ່ງເຄື່ອງ ແຕ່ເປັນການເປີດເຜີຍຂໍ້ມູນໃນລະດັບອຸປະກອນທັງກຸ່ມ.

ຮູບແບບບັນຫາທີ່ມີການລາຍງານນັ້ນ ຮ້າຍແຮງກວ່າພຽງການໃຊ້ລະຫັດຜ່ານເລີ່ມຕົ້ນທີ່ອ່ອນແອ. ແຫຼ່ງຂໍ້ມູນລະບຸເຖິງຂໍ້ຄວາມ MQTT ທີ່ຂາດການຄວບຄຸມສິດສະໝັກຮັບຕາມແຕ່ລະອຸປະກອນຢ່າງພຽງພໍ, URL ຮູບພາບທີ່ສາທາລະນະເຂົ້າເຖິງໄດ້, ການປິດບັງຮູບພາບທີ່ອ່ອນແອ ແລະຄີແບບຄົງທີ່ ຫຼືຄີທີ່ສາມາດດຶງອອກຈາກແອັບໄດ້. ນີ້ແມ່ນຄວາມລົ້ມເຫຼວຂອງແພລດຟອມ: ໂຄງສ້າງພື້ນຖານອາດເຜີຍຂໍ້ມູນທີ່ບັນຊີອື່ນບໍ່ຄວນເຂົ້າເຖິງໄດ້.

ຄວາມສ່ຽງຂອງກ້ອງຄລາວ	ການອອກແບບຕອບໂຕ້ຂອງ Timmy
ແບັກເອັນດ໌ເກັບ ຫຼືແຈກຢາຍເຫດການຮູບພາບ.	Timmy ບໍ່ມີບ່ອນເກັບຮູບພາບຫ້ອງເດັກໃນຄລາວ; ສື່ແມ່ນ WebRTC ແບບສົດ.
ຕົວກາງສົ່ງຂໍ້ຄວາມ ຫຼືບັກເກັດຕ້ອງອະນຸຍາດທຸກອຸປະກອນໄດ້ຢ່າງຖືກຕ້ອງ.	Firestore ສົ່ງຜ່ານພຽງຂໍ້ມູນການຈັບຄູ່ ແລະການສົ່ງສັນຍານ; SDP/ICE ຖືກເຂົ້າລະຫັດກ່ອນຈະຖືກຂຽນລົງ.
ຄີແບບຄົງທີ່ອາດສົ່ງຜົນຕໍ່ອຸປະກອນທັງໝົດ.	ການຈັບຄູ່ແຕ່ລະຄັ້ງຈະສ້າງຄີສະເພາະຂອງຕົນເອງຈາກ P-256 ECDH ຢູ່ໃນອຸປະກອນທັງສອງ.
ເສັ້ນທາງຜ່ານຕົວສົ່ງຕໍ່ອາດຖືກເຂົ້າໃຈຜິດວ່າເຂົ້າເຖິງສື່ໄດ້.	TURN ສົ່ງຕໍ່ແພັກເກັດ SRTP ທີ່ເຂົ້າລະຫັດ ແຕ່ບໍ່ໄດ້ຮັບຄີສື່.

Timmy ສ້າງຄວາມລັບແນວໃດ

ລະຫັດ Timmy ສີ່ຕົວອັກສອນບໍ່ໄດ້ຕັ້ງໃຈໃຫ້ເປັນຄວາມລັບ. ໃນໂຄດ ມັນເປັນພຽງຈຸດນັດພົບ: ແອັບສ້າງ meetingKey ຈາກມັນ ເພື່ອໃຫ້ອຸປະກອນທັງສອງຫາການແລກປ່ຽນ public key ໃນ Firestore ດຽວກັນໄດ້. ຄີ ECDH ສ່ວນຕົວບໍ່ເຄີຍອອກຈາກອຸປະກອນ.

ຈາກນັ້ນອຸປະກອນທັງສອງຄຳນວນຄວາມລັບຮ່ວມ P-256 ECDH ດຽວກັນ. ຄີການຈັບຄູ່ຖືກສ້າງຢູ່ໃນເຄື່ອງ. SAS ສອງຫຼັກໄດ້ມາຈາກຄວາມລັບຮ່ວມ ບວກກັບ public key ທັງສອງທີ່ຈັດລຽງແລ້ວ. ຖ້າການແລກປ່ຽນຄີນັ້ນຖືກແຊກແຊງ ອຸປະກອນຈະສະແດງຕົວເລກຕ່າງກັນ ເພື່ອບອກໃຫ້ຜູ້ໃຊ້ຢ່າຢືນຢັນການຈັບຄູ່.

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 handshake. ຄີ SRTP ສຳລັບສຽງ ແລະວິດີໂອ ໄດ້ມາຈາກການສື່ສານທີ່ປອດໄພນີ້. ຫຼັງຈາກນັ້ນ ແພັກເກັດສື່ຈະຖືກເຂົ້າລະຫັດເປັນ SRTP. ເຊີບເວີ TURN ສາມາດສົ່ງຕໍ່ແພັກເກັດເຫຼົ່ານັ້ນໄດ້ ແຕ່ບໍ່ໄດ້ຮັບຄີທີ່ຈຳເປັນຕໍ່ການເປີດສຽງ ຫຼືວິດີໂອ.

Timmy ເພີ່ມອີກຊັ້ນໜຶ່ງກ່ອນໜ້ານັ້ນ: ຂໍ້ມູນການສົ່ງສັນຍານ ເຊັ່ນ SDP offers, SDP answers ແລະ ICE candidates ຖືກເຂົ້າລະຫັດດ້ວຍ AES-256-GCM ກ່ອນຈະໄປເຖິງ Firestore. Firestore ຊ່ວຍໃຫ້ອຸປະກອນເຈລະຈາກັນ; ມັນບໍ່ແມ່ນບ່ອນສຳລັບເກັບວິດີໂອ, ສຽງ ຫຼືຂໍ້ມູນການສົ່ງສັນຍານແບບບໍ່ເຂົ້າລະຫັດ.

ສິ່ງທີ່ Timmy ຍັງບໍ່ໄດ້ອ້າງ

ລະບົບເບິ່ງເດັກທີ່ໜ້າເຊື່ອຖືບໍ່ຄວນອ້າງວ່າບໍ່ມີທາງຖືກເຈາະລະບົບ. ຖ້າໂທລະສັບຖືກເຈາະ ແອັບໃດໆກໍອາດຖືກໂຈມຕີໄດ້. ແອັບເວີຊັນທີ່ຖືກສ້າງຂຶ້ນດ້ວຍເຈດຕະນາຮ້າຍຈະປ່ຽນຮູບແບບຄວາມສ່ຽງ. ການຕັ້ງຄ່າເຊີບເວີຕ້ອງຖືກຕ້ອງຢູ່ສະເໝີ. ຂໍ້ອ້າງທີ່ຈຳກັດກວ່າຂອງ Timmy ແມ່ນຢູ່ທີ່ສະຖາປັດຕະຍະກຳ: Timmy ຫຼີກລ່ຽງການສ້າງຂໍ້ມູນສື່ຈາກຫ້ອງເດັກທີ່ລະບົບແບັກເອັນດ໌ສາມາດອ່ານໄດ້ ແລະເຮັດໃຫ້ສາມາດກວດສອບຕັກກະການຈັບຄູ່ທີ່ສຳຄັນຕໍ່ຄວາມປອດໄພໄດ້ໃນໂຄງການຫຼັກທີ່ເປີດເຜີຍຕໍ່ສາທາລະນະ.

ຄຳຖາມທີ່ຄວນຖາມກ່ຽວກັບກ້ອງເບິ່ງເດັກທຸກຮຸ່ນ

ຜູ້ຂາຍເກັບຮູບພາບ ຫຼືຄລິບບໍ?
URL ສື່ເປັນສ່ວນຕົວ, ໃຊ້ໄດ້ໄລຍະສັ້ນ ແລະອະນຸຍາດຕາມແຕ່ລະອຸປະກອນບໍ?
ຄີຖືກສ້າງສຳລັບແຕ່ລະອຸປະກອນ ຫຼືການຈັບຄູ່ ແທນທີ່ຈະເປັນຄີຄົງທີ່ໃນແອັບບໍ?
ຕົວກາງສົ່ງຂໍ້ຄວາມສົ່ງໄດ້ພຽງຂໍ້ຄວາມສຳລັບອຸປະກອນທີ່ທ່ານເປັນເຈົ້າຂອງແທ້ບໍ?
ການຈັບຄູ່ຊ່ວຍໃຫ້ຜູ້ໃຊ້ສັງເກດເຫັນການພະຍາຍາມໂຈມຕີແບບ man-in-the-middle ໄດ້ບໍ?

ອ່ານໂຄດ

ແຫຼ່ງຂໍ້ມູນ

← ກັບໄປບລັອກ