저 사양 IoT 기기에서의 보안 통신
저 사양의 IoT 기기는 낮은 프로세서 성능, 저 전력 등의 요구 사항에 의해 TCP보다는 UDP를 기반으로 한 IoT 프로토콜을 도입하는 경우가 많습니다. UDP는 비 연결 데이터그램이라 TCP에 비해 네트워크 오버헤드가 적고, 패킷 또한 더 작기 때문에 요구 사항을 충족하기에 유리합니다.
LwM2M (Lightweight M2M)
Rapid-IoT 플랫폼에서 지원하는 IoT 기기 관리를 위한 주요 프로토콜 중 하나
특히 LwM2M(Lightweight M2M)은 저 사양 IoT 기기를 지원하기 더욱 용이하도록 경량화된 IoT 규격으로, UDP(User Datagram Protocol) 및 CoAP (Constrained Application Protocol)에 기반하고 있습니다. 또한 LwM2M은 Rapid-IoT 플랫폼에서 사용하는 IoT 기기 관리를 위한 주요 프로토콜 중 하나로 OMA(Open Mobile Alliance)에서 제정한 IoT 표준 규격입니다.
[그림 1] LwM2M 1.1 Protocol Stack (출처: omaSpecWorks)
LwM2M version 1.0 에서는 주로 UDP, SMS를 기반했는데 2018년 배포된 LwM2M version 1.1 에서는 [그림 1]에서와 같이 TCP/TLS 뿐만 아니라 LoRa 등 보다 다양한 프로토콜에 대한 지원이 추가 되었습니다. 하지만 LwM2M version 1.0을 지원하는 기존 IoT 기기 뿐만 아니라 LwM2M version 1.1으로 개발된 IoT 기기에서도 UDP는 여전히 주요한 프로토콜로서 사용되고 있습니다.
DTLS 개요
UDP 기반 통신방식에서는 보안성을 추가하기 위해 DTLS(Datagram Transport Layer Security) version 1.2 가 주로 사용됩니다.
DTLS version 1.2 는 Transport layer의 TCP 프로토콜에 보안성을 제공해주는 TLS(Transport Layer Security) version 1.2 프로토콜을 UDP 에 적용 가능하게 해주는 보안 프로토콜입니다.
DTLS 보안 세션은 TLS와 유사하게 Handshake 절차를 통해 이루어 지는데 그 단계는 다음의 [그림 2]와 같습니다.
[그림 2] Message Flights for Full Handshake
사설망 내의 DTLS 보안 통신
TLS나 DTLS 모두 각각 통신 세션을 수립할 때 '5-tuple'를 기반으로 합니다.
5-tuple 란 ①Source IP address/②port, ③Destination IP address/④port, ⑤Transport Layer 4 protocol (TCP/UDP) 입니다.
NAT(Network Address Translation)가 적용되는 사설망 내에 IoT 기기가 위치하고 외부의 서버와 통신을 하는 상황에서는 비 연결 방식인 DTLS의 경우 간혹 문제가 생길 수 있습니다. 외부 서버가 인지하는 IoT 기기의 IP Address/Port가 고정되어 있지 않고 세션 중에 변경될 가능성이 있기 때문입니다. 특히 저 사양, 저 전력 IoT 기기의 경우 서버와의 통신 트래픽이 빈번하지 않고 그 주기가 사설망의 NAT의 주소 Mapping 유지시간 보다 긴 경우도 있기 때문에 이러한 가능성은 더 높아 집니다.
세션 중에 주소가 변경되는 경우 외부 서버는 IoT 기기로부터 수신한 패킷의 Source IP/Port가 기존 세션의 것과 일치하지 않기 때문에 무시해 버리게 되어 더 이상 정상적인 세션이 유지될 수 없습니다.
하지만 DTLS 규격을 정의한 IETF에서 이러한 부분을 보완하기 위한 논의를 진행해 왔고 관련 확장 규격이 거의 정해진 상태입니다.
Connection Identifiers for DTLS 1.2
IETF(Internet Engineering Task Force, 국제인터넷표준화기구)에 제안된 ‘Connection Identifiers for DTLS 1.2’ 규격은 위에서 설명한 사설망 환경에서의 문제를 해결하기 위한 방안입니다.
규격의 세부 내용은 TLS, DTLS 규격에 대한 학습이 선행되어야 이해할 수 있으므로 여기서는 생략하고 제목에 언급된 ‘Connection Identifiers’ 를 중심으로 간략히 소개해 드리겠습니다.
DTLS에서 세션을 수립하는 Handshaking 단계에서 DTLS Client와 Server는 각각 ClientHello 메시지와 ServerHello 메시지에 Connection ID 의 사용여부에 대한 정보를 “connection_id” extension 에 포함하여 전송할 수 있습니다
“connection_id” extension에 자신이 생성한 Connection ID를 포함하여 전송하면 앞으로 자신에게 전송 시 이 값을 포함할 것을 요구함과 동시에 상대방의 Connection ID 역시 자신이 포함해서 전송할 수 있다는 것을 알려주는 의미입니다. 이와 달리 Connection ID를 빈 값으로 설정한 extension을 포함하여 전송하는 것은 자신은 Connection ID를 사용하지 않지만 상대방의 Connection ID는 처리해 줄 수 있다는 의미입니다.
아래 [그림 3]에서와 같이 Connection ID를 포함한 DTLS 세션이 수립되면 이후 Application Data 전송이 서로 교환한 Connection ID를 포함하여 전달합니다. 그리고 수신된 패킷에 대한 DTLS 세션 확인 시 기존에는 5-tuple 에 따라 Source IP Address/Port를 비교하지만 Connection ID가 포함된 경우 이를 우선 비교하여 세션을 확인합니다.
결과적으로 서버와 클라이언트 사이에 사설망에 의한 NAT가 존재하고 NAT에 의해 DTLS 세션 중에 주소가 변경 되더라도 Connection ID를 통해 기존 DTLS세션을 유지할 수 있습니다.
[그림 3] Connection ID가 적용된 DTLS Flow
Connection Identifiers for DTLS 1.2 의 적용
위에서 소개한 ‘Connection Identifiers for DTLS 1.2’ 규격은 아직 Draft 단계로 정식 규격으로 확정 되지는 않았습니다. 하지만 DTLS를 지원하는 여러 오픈 소스 프로젝트에 반영이 되는 등 실제 제품들에 적용이 되고 있는 단계입니다.
IoT 관리 플랫폼인 Rapid-IoT 역시 위 규격을 적용하여 기존에 일부 사설망 환경에서 나타나던 문제를 해결한 경험이 있습니다. 여러분도 DTLS 통신 보완을 위해 위 방법을 참고하시기 바랍니다.
