단방향 SSL로 IoT 장치를 보호 할 수 있습니까?


9

인터넷 액세스 유무에 관계없이 로컬 네트워크에 연결된 IoT 장치 (기본 설정, VPN, NAT, DMZ 없음)를 고려하고 있습니다. 내 장치는 인증 및 권한 부여가있는 RPC 메커니즘을 제공하는 HTTP 서버로 실행됩니다. 그것은 mDNS로 광고하고 내 모바일 앱이나 RaspberryPi를 사용하여 이야기합니다.

IoT 개발의 표준은 상호 (양방향) SSL을 갖는 것 같습니다. 이는 단방향 SSL이 내 트래픽을 보호 할 수 없음을 의미합니까? 왜?

노트:

  • 나는 일방향 및 양방향 SSL의 기술적 차이점을 이해하지만 IoT 생산에서 단방향 (거의)이 결코 고려되지 않는 이유를 이해하지 못합니다.
  • 로컬 장치에 대한 상호 SSL을 사용하는 것이 어렵다는 것을 이해합니다. 서버 공개 키와 인증서를 클라이언트와 공유해야하며 그 반대도 마찬가지입니다. 반면에 단방향은 더 쉬워 보입니다 (사용자 조치가 필요하지 않음).
  • Philips Hue와 같은 일부 대량 생산 장치는 단방향 SSL 암호화보다 로컬 http 끝 점이 열려 있고 보안되지 않은 상태입니다. 왜이 선택을했을까요?
  • 나는이 질문이 의견에 근거하지 않기를 기대합니다. 이 경우 사과드립니다.

답변:


8

SSL / TLS는 "서버"가 인증서의 CN과 일치 할 수있는 알려진 위치 (고정 호스트 이름)에있을 때 잘 작동합니다.

RFC1918 블록에서 IP 주소를 발급 받고 DNS 항목이 없기 때문에 홈 네트워크의 장치 (예 : 대부분의 IoT 장치)에는 적합하지 않습니다. 이것은 인증서와 함께 발급 될 수 없음을 의미합니다 (물론 가능하지만 대부분의 브라우저는 인증서를 거부합니다). 이것이 Philips Hue와 같은 장치가 장치의 보안되지 않은 HTTP 엔드 포인트를 사용하는 이유이며, 기본적으로 장치를 보호하기 위해 보안되는 네트워크에 대한 액세스에 의존합니다.

상호 TLS를 사용하는 경우 장치가 일부 중앙 서비스에 연결되어있을 때 클라이언트에 해당 중앙 서버의 소유자를 대신하여 작동 할 수 있음을 인증하는 자체 인증서 / 개인 키가 있습니다.

귀하의 질문을 명확히하기 위해 서버 인증서 / 키를 모든 클라이언트에 배포 할 필요는 없으며 인증서를 발급 한 CA의 인증서만이 인증서가 신뢰할 수 있음을 증명하는 데 필요합니다.

편집하다:

안전한 로컬 장치 연결의 좋은 예는 클라이언트 당 키를 생성하는 데 사용되는 장치의 사전 공유 키 (QR 코드로)와 DTLS를 통해 COAP를 사용하는 IKEA의 Tradfri 조명입니다. 이를 통해 새로운 클라이언트를 설정하기위한 물리적 인 액세스를 보장하고 로컬 네트워크에서 비행중인 데이터를 보호합니다.


호스트가 고정 DNS 이름 또는 IP 주소가 아닌 경우 인증서는 해당 주소의 장치가 자신이 누구인지 (일반 "단일"SSL)라고 주장하기 때문에 정상적인 인증서 확인에 실패합니다. 상호 인증 된 SSL의 경우 두 당사자 모두에 동일한 키 / 인증서를 사용해서는 안됩니다. 서버와 클라이언트는 상호 신뢰할 수있는 CA가 서명 한 자체 인증서 / 키를 가지고 있어야합니다.
hardillb

답변 해 주셔서 감사합니다. 긴 침묵 @hardillb에 대해 죄송합니다. "이는 인증서와 함께 발급 될 수 없다는 것을 의미합니다. (그렇지만 대부분의 브라우저는 인증서를 거부 할 것입니다.") 내 IoT 장치와의 통신을 고려할 때 브라우저를 사용하여 언제 그렇게 할 것인지 알 수 없습니다 ... "서버 인증서 / 키를 모든 클라이언트에 배포 할 필요는없고 CA 인증서 만" 단방향 TLS의 경우 맞습니까? 서로를 위해 인증서와 키를 제공해야한다고 생각하기 때문에 상황이 더욱 어려워집니다. Tradfri와 관련하여 사전 공유 키는 암호화가 아니라 인증 용입니다.
발렌틴

아니오 tradrfi의 사전 공유 키는 핸드 셰이크 및 암호화를위한 장치 별 키 생성하는 것입니다
hardillb

1

일반적으로 TLS는 x.509보다 훨씬 우수하지만 많은 구현에서는 x.509로만 제한합니다.

x.509는 안전한 간접 신뢰를위한 기술입니다. "B"에 "C"로 서명되고 "C"가 "A"로 신뢰되는 인증서가있는 경우 "A"는 "B"를 신뢰합니다. 그것은 실제 생활에서도 작동합니다. 당신이 신뢰하는 사람이 서명 한 서한이 있다면, 당신은 당신이 모르는 누군가를 신뢰합니다. 어쩌면 함정을 볼 수 있습니다. 편지에 나와 있으면 차를주지 않을 커피 한 잔을주세요. 따라서 인증서의 추가 정보는 신뢰 범위와 관련이 있습니다. 그래서 서버는 일반적으로 인증서에 dns 이름 또는 ip-address를 가지고 있습니다. 일반적으로 다른 정보 (예 : "거실 램프")를 포함 할 수 있지만 DNS / IP 항목을 사용 / 확인하기 위해 많은 구현이 미리 구성되어 있습니다. 그리고 누군가가 신뢰할 수있는 "에 관심이있는 경우에만 작동

그것에 시간을 보낼 수 있다면 PSK 암호 제품군도 제공하는지 구현을 확인하십시오. 그렇지 않은 경우 서버 인증서의 "유효성 검사"를 조정할 수 있습니다. 그러나 좋은 해결책을 찾으려면 많은 독서가 필요합니다. 때로는 사용 된 TLS 구현이이를 제공하지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.