A Galaxus informou que gravações de câmeras de bebê estavam livremente acessíveis; o The Verge relatou cerca de 1,1 milhão de dispositivos Meari afetados. Para mim, a conclusão é objetiva: um login não protege o quarto do bebê se a plataforma por trás dele não separa corretamente, por dispositivo, mensagens, imagens e chaves. A Timmy não resolve todos os problemas de segurança do mundo. Mas os segredos essenciais de mídia e pareamento da Timmy não ficam dentro de uma plataforma de câmeras em nuvem.
O que parece ter falhado no caso Meari
Os relatos públicos descrevem uma plataforma white-label. Diversas marcas vendiam câmeras que dependiam da mesma infraestrutura Meari/CloudEdge. É por isso que o incidente importa: quando uma plataforma compartilhada define incorretamente um limite de autorização, o resultado não é apenas uma câmera vulnerável, mas uma exposição que afeta toda a frota.
O padrão relatado vai além de senhas padrão fracas. As fontes descrevem mensagens MQTT sem controles suficientes de assinatura por dispositivo, URLs de imagens acessíveis publicamente, ofuscação fraca das imagens e chaves estáticas ou extraíveis do app. Isso é uma falha de plataforma: a infraestrutura podia revelar dados que nunca deveriam estar disponíveis para outra conta.
| Risco das câmeras em nuvem | A abordagem oposta da Timmy |
|---|---|
| O backend armazena ou distribui eventos de imagem. | A Timmy não mantém um arquivo em nuvem com imagens do quarto do bebê; a mídia é transmitida ao vivo via WebRTC. |
| Um broker ou bucket precisa aplicar corretamente a autorização de cada dispositivo. | O Firestore transporta apenas dados de pareamento e sinalização; os dados de SDP/ICE são criptografados antes de serem gravados. |
| Chaves estáticas podem afetar toda uma frota. | Cada pareamento gera nos dispositivos uma chave própria derivada por ECDH P-256. |
| Um caminho de retransmissão pode ser confundido com acesso à mídia. | O TURN encaminha pacotes SRTP criptografados, mas não recebe as chaves de mídia. |
Como a Timmy cria o segredo
O código Timmy de quatro caracteres não é, de propósito, o segredo. No código, ele é apenas um ponto de encontro: o app deriva uma meetingKey a partir dele para que os dois dispositivos encontrem a mesma troca de chaves públicas no Firestore. As chaves privadas de ECDH nunca saem dos dispositivos.
Depois, os dois dispositivos calculam o mesmo segredo compartilhado ECDH P-256. A chave de pareamento é derivada localmente. O SAS de dois dígitos é derivado do segredo compartilhado mais as duas chaves públicas ordenadas. Se essa troca de chaves for adulterada, os dispositivos mostram números diferentes, avisando os usuários para não confirmar o pareamento.
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 da Timmy: o Firestore funciona como ponto de encontro e transporte de sinalização; o TURN serve apenas como retransmissor; a mídia permanece criptografada pelo WebRTC.
Por que a mídia WebRTC não pode ser monitorada às escondidas
WebRTC não é apenas "enviar vídeo". Antes de a mídia começar a fluir, os dispositivos realizam um handshake DTLS. As chaves SRTP de áudio e vídeo são derivadas desse transporte seguro. Em seguida, os pacotes de mídia são criptografados como SRTP. Um servidor TURN pode encaminhar esses pacotes, mas não recebe as chaves necessárias para descriptografar o áudio ou o vídeo.
A Timmy adiciona uma camada antes disso: dados de sinalização, como ofertas SDP, respostas SDP e candidatos ICE, são criptografados com AES-256-GCM antes de chegarem ao Firestore. O Firestore ajuda os dispositivos a negociar; ele não deve armazenar vídeo, áudio nem dados de sinalização sem criptografia.
O que a Timmy ainda não afirma
Nenhuma babá eletrônica séria deve afirmar que é impossível de hackear. Se um celular for comprometido, qualquer app pode ser atacado. Uma versão maliciosa do app muda o modelo de risco. A configuração do servidor precisa permanecer correta. A alegação mais específica da Timmy diz respeito à arquitetura: ela evita artefatos de mídia do quarto do bebê que possam ser lidos pelo backend e permite que a lógica de pareamento crítica para a segurança seja inspecionada no projeto público Timmy Core.
Perguntas para fazer sobre qualquer câmera de bebê
- O fornecedor armazena imagens ou clipes?
- As URLs de mídia são privadas, de curta duração e autorizadas por dispositivo?
- As chaves são geradas por dispositivo ou pareamento, em vez de serem estáticas dentro de um app?
- Um broker só consegue entregar mensagens ao dispositivo que de fato pertence a você?
- O pareamento permite que uma pessoa perceba uma tentativa de ataque do tipo man-in-the-middle?
Leia o código
- ECDH e SAS no Timmy Core
- Chave de encontro, chave do documento e AES-GCM
- Regras do Firestore para sessões e pareamento
- Documentação de segurança no projeto Timmy Core
Fontes
- Gravações de câmeras de bebê livremente acessíveis · Galaxus
- Um milhão de babás eletrônicas e câmeras de segurança podiam ser facilmente visualizadas por hackers · The Verge
- ninguém coloca o bebê num canto · Sammy Azdoufal
- Guia para pais sobre o mesmo incidente · Baby Monitor Timmy