Hacker News 의견

• 장기적인 해결책은 지역 제어를 무시하는 가정용 제품을 구매하지 않는 것임

  • WiFi 비밀번호가 필수라면 제품을 반품할 것임
  • 보안과 프라이버시를 희생하고 싶다면 개인의 선택이지만, 기능 손실 없이 거부할 수 있는 옵션을 제공해야 함
  • RTSP를 지원하지 않는 도어벨 카메라는 구매하지 않을 것임

• 공기청정기가 실내 공기질이 떨어질 때 작동을 강화하는 것은 IoT 기기, 앱, 무선 통신, 허브가 필요하지 않음

  • 공기청정기에 공기질 센서와 작은 LCD를 부착해 설정을 조정하면 충분함
  • 복도 조명이 자동으로 켜지는 것은 클라우드, HomeAssist, WiFi, Zigbee, 앱, 배터리 교체 없이 동작함
  • 지난 10년간 네트워크가 다운되어도 문제 없이 작동함

• ESP32 기반 IoT 기기 판매자에게:

  • 스마트 홈 시스템과 통합하기 위해 스마트 기기를 업그레이드하는 것은 다른 인스턴스나 클라우드 서비스에 영향을 주지 않음
  • 민감한 제품 데이터는 모호화되거나 삭제됨

• ESP32 기반 IoT 기기 소유자에게:

  • 스마트 홈 제품의 클라우드 제거 및 디버깅을 위한 오픈 소스 프로젝트를 생성하며 기술적 측면을 많이 배움
  • 이 게시물 작성에 많은 노력을 기울였으며, 형식에 대한 피드백을 받으면 좋겠음

• 기기의 보드에서 어떤 핀이 연결되어 있는지 파악하고 ESPHome으로 완전히 플래시하고 사용자 정의 yaml 구성을 작성할 수 있을지 궁금함

• IoT 기기 설계 팀에 있을 때마다 보안에 중점을 둔 엔지니어가 부트 보호를 담당했음

  • 펌웨어를 덤프하고 다시 플래시하는 것에 저항이 없었다는 것이 놀라움
  • 플래시 암호화를 하지 않는 이유가 궁금함

• 기사에 대한 피드백:

  • 장치 키 사용에 대한 노트는 장치별로 키가 있는 것이 가장 명확함
  • 장치별 키 관리의 복잡성과 위험에 대한 피드백을 공유하고 싶음
  • 장치 암호화는 공장에서 많은 문제를 일으킬 수 있으며, 제품이 감당할 수 있다면 무시하는 것이 좋음

• 표준화된 솔루션을 사용하지 않은 이유가 궁금함

  • 자체 솔루션을 만드는 것보다 비용 효율적일 것 같음

• ESP32 IoT 기기에서 펌웨어 암호화를 사용하는 경우가 드물었음

  • 펌웨어를 읽을 수 없으면 인증서를 만들기 어려웠을 것임
  • 그러나 동시에 인상적임

• 서비스 엔지니어들이 DTLS 같은 표준 프로토콜을 구현하지 않기로 결정한 것에 대한 의견

  • 각 기기가 고유한 개인 키를 가지고 있는지 확실하지 않음
  • 모든 기기가 동일한 펌웨어 개인 키를 공유하면 단일 기기를 역설계하여 다른 기기에 MITM 공격을 할 수 있음

• 스마트 기기를 사용하는 사람들은 DD-WRT, OpenWrt, Tomato, Asuswrt-Merlin을 사용하여 기기를 개인 네트워크와 분리된 VLAN에 격리해야 함

• 구매한 제품을 사용하기 위해 해킹할 필요가 없어야 함

  • "렌트 시킹" 경제는 규제되거나 금지되어야 함