Galaxus는 누구나 접근할 수 있었던 베이비 카메라 녹화 영상을 보도했고, The Verge는 영향을 받은 Meari 기기가 약 1.1백만 대, 즉 110만 대라고 전했습니다. 제가 이 사건에서 얻은 교훈은 냉정합니다. 배후 플랫폼이 기기별로 메시지, 이미지, 키를 제대로 분리하지 못한다면 로그인만으로는 아이 방을 보호할 수 없습니다. Timmy가 세상의 모든 보안 문제를 해결하는 것은 아닙니다. 하지만 Timmy에서 미디어와 페어링의 보안에 핵심적인 비밀값은 클라우드 카메라 플랫폼 내부에 저장되지 않습니다.
Meari 사례에서 문제가 된 것으로 보이는 부분
공개 보도에 따르면 이는 화이트라벨 플랫폼이었습니다. 여러 브랜드가 같은 Meari/CloudEdge 인프라에 의존하는 카메라를 판매했습니다. 그래서 이 사건이 중요합니다. 공유 플랫폼이 권한 경계를 잘못 설정하면 카메라 한 대의 취약점에 그치지 않고, 대규모 기기 전체가 노출될 수 있습니다.
보고된 양상은 취약한 기본 비밀번호를 넘어섭니다. 자료에 따르면 기기별 구독 제어가 충분하지 않은 MQTT 메시지, 공개적으로 접근 가능한 이미지 URL, 약한 이미지 난독화, 정적 키 또는 앱에서 추출 가능한 키가 있었습니다. 이는 플랫폼의 실패입니다. 인프라가 다른 계정에는 절대 제공되어서는 안 될 데이터를 노출할 수 있었기 때문입니다.
| 클라우드 카메라의 위험 | Timmy의 대응 설계 |
|---|---|
| 백엔드가 이미지 이벤트를 저장하거나 배포합니다. | Timmy에는 아이 방 이미지용 클라우드 보관함이 없습니다. 미디어는 실시간 WebRTC로 전송됩니다. |
| 브로커나 저장소 버킷은 모든 기기의 접근 권한을 빈틈없이 제어해야 합니다. | Firestore에는 페어링 및 시그널링 데이터만 전달되며, SDP/ICE는 기록되기 전에 암호화됩니다. |
| 정적 키는 전체 기기에 영향을 줄 수 있습니다. | 각 페어링은 기기에서 자체 P-256 ECDH 기반 키를 생성합니다. |
| 릴레이 경로가 미디어 접근 권한으로 오해될 수 있습니다. | TURN은 암호화된 SRTP 패킷을 전달하지만 미디어 키는 받지 않습니다. |
Timmy가 비밀 정보를 만드는 방식
4자리 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은 비공개이며, 짧은 시간만 유효하고, 기기별로 권한이 확인되나요?
- 키는 앱 안의 정적 키가 아니라 기기 또는 페어링별로 생성되나요?
- 브로커는 실제로 내가 소유한 기기에 대한 메시지만 전달할 수 있나요?
- 페어링 과정에서 사용자가 중간자 공격 시도를 알아챌 수 있나요?
코드 보기
출처
- 누구나 접근할 수 있었던 베이비 카메라 녹화 영상 · Galaxus
- 해커가 쉽게 볼 수 있었던 100만 대의 베이비 모니터와 보안 카메라 · The Verge
- 아무도 아기를 구석에 두지 않는다 · Sammy Azdoufal
- 같은 사건에 대한 부모 가이드 · Baby Monitor Timmy