클라우드 없이는 안 돌아가는 공기청정기를 뜯어본 사람 — 자체 암호 프로토콜이 무너진 이유
클라우드 없이는 안 돌아가는 공기청정기를 뜯어본 사람 — 자체 암호 프로토콜이 무너진 이유
분류: Security · 펌웨어·IoT · IoT 기기 침투 [정보성]
덱. 개발자 jmswrnr는 자기 집 스마트 공기청정기를 자체 홈 자동화 시스템(Home Assistant)에 붙이고 싶다는 소박한 동기에서 출발해, 이 기기가 만든 회사 클라우드 서버 없이는 원격 제어가 아예 불가능하다는 사실을 발견하고 직접 뜯어보기로 합니다. 그 결과 회로 기판의 디버그 핀 몇 개, 암호화되지 않은 저장소, 그리고 표준 프로토콜 대신 손수 만든 암호화 방식이 어떻게 차례로 무너지는지가 드러났습니다.
리드
소비자용 IoT(사물인터넷) 기기는 원가에 극도로 민감합니다. 개발팀은 대개 검증된 표준 암호화 프로토콜을 새로 익혀 구현하는 대신, 자체 프로토콜을 손으로 짜는 편을 선택합니다. 문제는 이렇게 손으로 짠 프로토콜이 “아무도 안의 원리를 모르니 안전하다”는 은닉을 통한 보안(security through obscurity)에 크게 의존하게 된다는 점입니다. 그리고 물리적으로 그 기기를 손에 쥔 사람 앞에서는, 은닉이 언젠가는 걷힙니다.
핵심 사실 요약
- 대상은 저자가 소유한 스마트 공기청정기로, 블루투스·와이파이가 꺼진 상태에서는 원격 제어 앱이 전혀 동작하지 않는다는 점에서 로컬 직접 통신이 아니라 클라우드 서버를 반드시 거치는 구조였습니다. 저자는 제조사·모델명 등 특정 가능한 정보는 원문에서 의도적으로 가려 공개하지 않았습니다.
- 먼저 안드로이드 제어 앱을 분석해, 이 앱이 리액트 네이티브(React Native)로 만들어졌고 보안 웹소켓(WebSocket)으로 클라우드 서버에 접속한다는 것을 확인했습니다. 이어서 가정용 DNS 서버(Pi-hole)로 기기의 통신 대상 도메인을 알아내고, 그 트래픽을 자신의 컴퓨터로 돌려 Wireshark로 들여다본 결과, 기기가 UDP(비연결형 전송 프로토콜)로 암호화된 것으로 보이는 데이터를 서버와 주고받는다는 걸 확인했습니다.
- 여기서 네트워크 분석만으로는 더 나아갈 수 없었기에, 기기를 직접 분해했습니다. 메인보드에서 ESP32 계열 마이크로컨트롤러(와이파이·블루투스를 내장한 저가 범용 칩)를 확인하고, 보드 위 디버그용 핀 홀에 시리얼 통신선을 연결해 부팅 로그를 확보했습니다.
- 이 시리얼 연결로 기기를 다운로드 모드로 진입시켜 플래시 메모리 전체(4메가바이트)를 통째로 덤프했습니다. 이 기기는 플래시 암호화(flash encryption) 기능이 꺼져 있었기 때문에, 덤프한 내용을 그대로 읽을 수 있었습니다. 그 안에서 기기 고유의 개인키(EC 개인키), 인증서 두 장, 그리고 저자 본인의 와이파이 비밀번호까지 평문으로 발견됐습니다.
- 이어서 펌웨어 실행 파일을 리버스 엔지니어링 도구인 Ghidra로 정적 분석해, 기기가 통신 암호화 키를 만드는 절차(ECDH 키 교환 + HKDF 방식의 키 유도, SHA-256 기반)를 코드 레벨로 재구성했습니다. 이 절차 자체는 표준 암호 기법을 쓰고 있었지만, 계산에 필요한 값들이 이미 위 플래시 덤프에서 다 확보된 뒤였습니다.
- 저자는 이후 펌웨어의 사용하지 않는 코드 영역에 자신이 작성한 소규모 함수를 심어, 기기가 계산해낸 공유 비밀 키(shared secret)를 시리얼 포트로 출력하도록 만들었습니다. 개념적으로 단순화하면, “특정 계산이 끝난 직후 그 결과값을 로그로 찍어라”는 한 줄짜리 후킹(hooking)에 해당합니다(개념용 단순화, 실제 어셈블리 코드는 원문에만 있으며 이 글에는 옮기지 않았습니다). 이렇게 얻은 키로 캡처한 패킷을 시험 삼아 복호화한 결과 AES-128-CBC(128비트 키를 쓰는 표준 대칭 암호화 방식) 암호문임이 확인됐습니다.
- 이 지점부터는 펌웨어를 더 건드릴 필요 없이, 기기와 클라우드 서버 사이에 끼어드는 중간자(MITM) 프록시만으로 모든 통신을 실시간으로 열어볼 수 있게 됐습니다. 저자는 이 프록시로 기기의 상태 조회·갱신 메시지 형식을 전부 파악한 뒤, 클라우드 서버 역할을 대신하는 자체 서버를 만들어 MQTT(경량 IoT 메시징 프로토콜)를 통해 Home Assistant와 연결했습니다. 결과적으로 제조사 클라우드 없이도 공기청정기의 팬 속도 등을 제어할 수 있게 됐다고 밝혔습니다.
짧은 논평
이 글의 결말부에서 저자 스스로 짚은 지적이 정확합니다 — 표준 프로토콜(DTLS 등) 대신 자체 프로토콜을 만드는 순간, 보안의 상당 부분이 “아무도 뜯어보지 않을 것”이라는 가정에 기대게 됩니다. 이번 사례에서 결정타는 암호화 로직 자체의 결함이 아니라, 그 로직을 지탱하는 비밀(개인키)이 암호화되지 않은 저장소에 평문으로 놓여 있었다는 점입니다. 좋은 암호 알고리즘도 그 키를 지키지 못하면 의미가 없습니다. 이건 저희가 다른 임베디드·펌웨어 사례에서도 반복해서 보는 패턴입니다 — 소프트웨어 계층의 암호화 설계가 아무리 정교해도, 그 밑을 받치는 하드웨어 계층(플래시 암호화, 디버그 포트 잠금, 보안 부팅)에 구멍이 있으면 공격자는 굳이 암호를 깨려 하지 않고 그 아래로 파고듭니다. 물리적 접근을 전제로 한 위협 모델을 “우리 제품과는 상관없는 이야기”로 치부하는 순간, 그 가정이 무너지는 건 시간문제일 뿐입니다.
References / 참고자료
- jmswrnr, “Hacking a Smart Home Device” — 이 글이 재구성한 원 분석. 모바일 앱 분석부터 하드웨어 분해, 펌웨어 덤프, 암호 프로토콜 리버스 엔지니어링, Home Assistant 연동까지 전 과정을 다룸. https://jmswrnr.com/blog/hacking-a-smart-home-device
이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·코드·어셈블리를 그대로 옮기지 않았으며, 작동하는 재현 절차·실제 통신 키·펌웨어 패치 코드는 싣지 않았습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 확증·정정되어야 합니다.