Sekuriteit verduidelik

Meari-babakamera se sekuriteitskwesbaarheid: wat Timmy anders doen

Die Meari-saak wys dat selfs ’n goed afgewerkte aanmeldproses nie genoeg is nie. Die veiligheid van ’n babamonitor hang af van die argitektuur, magtiging en bestuur van sleutels.

Deur Gepubliseer Bygewerk

Galaxus het berig oor vrylik toeganklike opnames van babakameras; The Verge het berig dat ongeveer 1,1 miljoen Meari-toestelle geraak is. Vir my is die nugtere les: ’n aanmelding beskerm nie die babakamer as die platform daaragter nie boodskappe, beelde en sleutels behoorlik vir elke toestel afsonder nie. Timmy los nie elke sekuriteitsprobleem ter wêreld op nie. Timmy se kritieke media- en koppelingsgeheime word egter nie op ’n wolkkameraplatform bewaar nie.

Wat blykbaar in die Meari-saak verkeerd geloop het

Die openbare berigte beskryf ’n platform wat onder verskillende handelsname verkoop word. Talle handelsmerke het kameras verkoop wat op dieselfde Meari/CloudEdge-infrastruktuur staatgemaak het. Daarom maak die voorval saak: wanneer ’n gedeelde platform ’n magtigingsgrens verkeerd toepas, stel dit nie net een swak kamera bloot nie, maar moontlik ’n hele reeks toestelle.

Die gerapporteerde patroon gaan verder as swak verstekwagwoorde. Bronne beskryf MQTT-boodskappe sonder voldoende intekeningbeheer per toestel, beeld-URL’s wat openbaar toeganklik was, swak verdoeseling van beelde en statiese sleutels of sleutels wat uit die app onttrek kon word. Dit is ’n fout in die platform: die infrastruktuur kon data blootlê wat nooit vir ’n ander rekening beskikbaar moes gewees het nie.

Wolkkamera-risikoTimmy se alternatiewe ontwerp
Die bedienerkant stoor of versprei beeldgebeurtenisse.Timmy het geen wolkargief vir beelde uit die babakamer nie; media word regstreeks via WebRTC gestroom.
’n Boodskapmakelaar of bergingshouer moet elke toestel foutloos magtig.Firestore dra slegs data vir koppeling en seinuitruiling; SDP/ICE word geënkripteer voordat dit geskryf word.
Statiese sleutels kan ’n hele vloot raak.Elke koppeling skep sy eie sleutel, wat op die toestelle deur middel van P-256 ECDH afgelei word.
Die gebruik van ’n relais kan verkeerdelik as toegang tot die media beskou word.TURN stuur geënkripteerde SRTP-pakkies aan, maar ontvang nie mediasleutels nie.

Hoe Timmy die geheim skep

Die Timmy-kode van vier karakters is doelbewus nie die geheim nie. In die programkode dien dit slegs as ’n ontmoetingspunt: die app lei ’n meetingKey daaruit af sodat albei toestelle dieselfde Firestore-uitruiling van openbare sleutels kan vind. Die private ECDH-sleutels verlaat nooit die toestelle nie.

Albei toestelle bereken dan dieselfde gedeelde P-256 ECDH-geheim. Die koppelingsleutel word plaaslik afgelei. Die tweesyfer-SAS-kode word afgelei van die gedeelde geheim en albei gesorteerde openbare sleutels. As iemand met die sleuteluitruiling peuter, wys die toestelle verskillende getalle. Dit waarsku gebruikers om nie die koppeling te bevestig nie.

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

Vereenvoudigde Timmy-sekuriteitsketting: Firestore dien as ontmoetingspunt en dra die seinuitruiling; TURN is slegs ’n relais; die media bly deur WebRTC geënkripteer.

Waarom WebRTC-media nie ongemerk bekyk kan word nie

WebRTC beteken nie bloot dat video gestuur word nie. Voordat die media begin vloei, voer die toestelle ’n DTLS-handdruk uit. Die SRTP-sleutels vir klank en video word uit dié veilige verbinding afgelei. Die mediapakkies word daarna met SRTP geënkripteer. ’n TURN-bediener kan die pakkies aanstuur, maar ontvang nie die sleutels wat nodig is om die klank of video te ontsleutel nie.

Timmy voeg reeds voor dié stap nog ’n beskermingslaag by: seindata soos SDP-aanbiedinge, SDP-antwoorde en ICE-kandidate word met AES-256-GCM geënkripteer voordat dit Firestore bereik. Firestore help die toestelle om die verbinding op te stel; dit is nie bedoel om ongeënkripteerde video, klank of seindata te bevat nie.

Wat Timmy nie beweer nie

Geen verantwoordelike vervaardiger van ’n babamonitor behoort te beweer dat die produk onmoontlik is om te kraak nie. As ’n foon gekompromitteer word, kan enige app aangeval word. ’n Kwaadwillige weergawe van die app verander die risikomodel. Die bedienerkonfigurasie moet ook korrek bly. Timmy se meer beperkte bewering gaan oor sy argitektuur: dit vermy media-artefakte uit die babakamer wat deur die bedienerkant gelees kan word, en maak dit moontlik om die sekuriteitskritieke koppelingslogika in die openbare kernprojek na te gaan.

Vrae om oor enige babakamera te vra

  • Berg die verskaffer beelde of snitte?
  • Is media-URL’s privaat, kortstondig en per toestel gemagtig?
  • Word sleutels vir elke toestel of koppeling gegenereer, eerder as om staties in ’n app ingebou te wees?
  • Kan ’n boodskapmakelaar slegs boodskappe aflewer vir die toestel wat jy werklik besit?
  • Stel die koppelproses ’n gebruiker in staat om ’n man-in-die-middel-aanval raak te sien?

Lees die kode

Bronne

← Terug na blog