Explicação sobre segurança

Vulnerabilidade de segurança das câmaras para bebés Meari: o que o Timmy faz de diferente

O caso Meari mostra que uma interface de início de sessão cuidada não basta. A segurança de um monitor para bebés depende da arquitetura, da autorização e da gestão de chaves.

Por Publicado Atualizado

A Galaxus noticiou que havia gravações de câmaras para bebés livremente acessíveis; o The Verge noticiou cerca de 1,1 milhão de dispositivos Meari afetados. Para mim, a conclusão é simples e sóbria: um início de sessão não protege o quarto do bebé se a plataforma por trás dele não separar corretamente, por dispositivo, as mensagens, as imagens e as chaves. O Timmy não resolve todos os problemas de segurança do mundo. Mas os segredos críticos de multimédia e emparelhamento do Timmy não estão alojados numa plataforma de câmaras na cloud.

O que parece ter falhado no caso Meari

Os relatos públicos descrevem uma plataforma de marca branca. Muitas marcas visíveis venderam câmaras que dependiam da mesma infraestrutura Meari/CloudEdge. É por isso que o incidente importa: quando uma plataforma partilhada define incorretamente uma fronteira de autorização, o resultado não é uma única câmara vulnerável, mas uma exposição à escala de toda a frota.

O padrão relatado vai além de palavras-passe predefinidas fracas. As fontes descrevem mensagens MQTT sem controlos suficientes de subscrição por dispositivo, URLs de imagens acessíveis publicamente, ofuscação fraca de imagens e chaves estáticas ou extraíveis da aplicação. Trata-se de uma falha da plataforma: a infraestrutura podia revelar dados que nunca deveriam estar disponíveis para outra conta.

Risco das câmaras na cloudA abordagem alternativa do Timmy
O backend armazena ou distribui eventos de imagem.O Timmy não mantém um arquivo na cloud com imagens do quarto do bebé; os conteúdos multimédia são transmitidos em direto através de WebRTC.
Um broker ou bucket tem de aplicar corretamente a autorização a todos os dispositivos.O Firestore transporta apenas dados de emparelhamento e sinalização; SDP/ICE é cifrado antes de ser gravado.
Chaves estáticas podem afetar toda uma frota.Cada emparelhamento cria nos dispositivos uma chave própria derivada através de ECDH P-256.
Um percurso por relé pode ser confundido com acesso à multimédia.O TURN encaminha pacotes SRTP cifrados, mas não recebe chaves de multimédia.

Como o Timmy cria o segredo

O código Timmy de quatro caracteres foi deliberadamente concebido para não ser o segredo. Na implementação, é apenas um ponto de encontro: a aplicação deriva uma meetingKey a partir dele para que ambos os dispositivos encontrem a mesma troca de chaves públicas no Firestore. As chaves privadas ECDH nunca saem dos dispositivos.

Depois, ambos os dispositivos calculam o mesmo segredo partilhado através de ECDH P-256. A chave de emparelhamento é derivada localmente. O SAS de dois dígitos é derivado do segredo partilhado e das duas chaves públicas ordenadas. Se essa troca de chaves for adulterada, os dispositivos mostram números diferentes, indicando aos utilizadores que não devem confirmar o emparelhamento.

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

Cadeia de segurança simplificada do Timmy: o Firestore serve de ponto de encontro e de transporte de sinalização; o TURN é apenas um relé; os conteúdos multimédia permanecem cifrados por WebRTC.

Porque não é possível espiar discretamente os conteúdos multimédia WebRTC

O WebRTC não se limita a «enviar vídeo». Antes de os conteúdos multimédia começarem a fluir, os dispositivos efetuam um handshake DTLS. As chaves SRTP para áudio e vídeo são derivadas desse transporte seguro. Os pacotes multimédia são depois cifrados como SRTP. Um servidor TURN pode encaminhar esses pacotes, mas não recebe as chaves necessárias para desencriptar o áudio ou o vídeo.

O Timmy acrescenta uma camada antes disso: os dados de sinalização, como ofertas SDP, respostas SDP e candidatos ICE, são cifrados com AES-256-GCM antes de chegarem ao Firestore. O Firestore ajuda os dispositivos a negociar; não se destina a alojar vídeo, áudio ou sinalização em claro.

O que o Timmy continua a não prometer

Nenhum monitor para bebés sério deve afirmar que é impossível de piratear. Se um telemóvel estiver comprometido, qualquer aplicação pode ser atacada. Uma versão maliciosa da aplicação altera o modelo de risco. A configuração do servidor tem de permanecer correta. A alegação mais circunscrita do Timmy é de natureza arquitetural: evita artefactos multimédia do quarto do bebé que o backend consiga ler e permite inspecionar a lógica de emparelhamento crítica para a segurança no projeto público Timmy Core.

Perguntas a fazer sobre qualquer câmara para bebés

  • O fornecedor armazena imagens ou vídeos?
  • Os URLs de multimédia são privados, de curta duração e autorizados por dispositivo?
  • As chaves são geradas por dispositivo ou emparelhamento, em vez de serem estáticas dentro de uma aplicação?
  • Um broker só consegue entregar mensagens relativas ao dispositivo que é efetivamente seu?
  • O emparelhamento permite que uma pessoa detete uma tentativa de ataque de intermediário (man-in-the-middle)?

Ler o código

Fontes

← Voltar ao blogue