사용자 편의성 및 안전성이 강화된 ZigBee 인증 프로토콜

ZigBee Authentication Protocol with Enhanced User Convenience and Safety

Abstract

빠르게 성장하고 있는 IoT 시장은 일반 가정에서뿐만 아니라 스마트홈이나 스마트시티까지 확대되고 있다. IoT에서 사용하는 주요 프로토콜 중 ZigBee는 스마트홈의 도어락 시장에서 90% 이상 차지하고 있고 소형화된 센서 디바이스에서 주로 사용하고 있어 프로토콜의 안전성이 매우 중요하다. 하지만, ZigBee를 사용하는 디바이스가 네트워크에 연결되는 인증과정에서 고정된 키를 사용하고 있어 전방향 안전성을 만족하지 못하고 있고, 최근에 개발한 ZigBee 3.0에서도 해결되지 못하였다. 본 논문에서는 ZigBee 인증 프로토콜에 전방향 안전성을 제공함과 동시에 기존 프로토콜에서도 빠르게 적용할 수 있는 설계방법을 제안한다. 제안하는 개선된 ZigBee 인증 프로토콜은 IoT에서 연산량이 적고 전방향 안전성을 제공하는 ECDH를 적용하기 위해 최근 개발된 OWE 프로토콜을 분석 및 적용하였다. 이를 바탕으로 ZigBee 인증 프로토콜의 안전성을 제공하며, 별도의 인증서나 패스워드 입력이 필요하지 않아 사용자의 편의성 또한 제공할 수 있을 것으로 본다.

The rapidly growing IoT market is expanding not only in general households but also in smart homes and smart cities. Among the major protocols used in IoT, ZigBee accounts for more than 90% of the smart home's door lock market and is mainly used in miniaturized sensor devices, so the safety of the protocol is very important. However, the device using Zig Bee is not satisfied with the omnidirectional safety because it uses a fixed key during the authentication process that connects to the network, and it has not been resolved in the recently developed ZigBee 3.0. This paper proposes a design method that provides omnidirectional safety to the ZigBee authentication protocol and can be quickly applied to existing protocols. The proposed improved ZigBee authentication protocol analyzed and applied the recently developed OWE protocol to apply ECDH, which has low computational volume and provides omnidirectional safety in IoT. Based on this, it provides the safety of the ZigBee authentication protocol, and it is expected that it will be able to provide user convenience as it does not require a separate certificate or password input.

1. 서론

IoT(Internet of Things)의 보급은 국내뿐만 아니라 전 세계적으로 꾸준하게 성장하고 있다. 학기술정보통신부가 발간한 ‘2020년 사물인터넷 산업 실태조사 결과’에 따르면 2020년 사물인터넷 총 매출액은 약 13조 4,637억원으로 조사되었고, 제품기기 분야가 40.9%의 비중으로 가장 크게 차지하였다.[1]

또한, 연구개발특구진행재단이 발간한 ‘2021 글로벌 시장동향보고서 IoT 센서 시장’에 따르면 ZigBee는 2021년 4억 6,630만 달러에서 연평균 31.1%로 증가하여 2026년에는 약 18억 달러에 이를것으로 전망하고 있다.[2] 이는 IoT에서 사용하는 다양한 프로토콜 중 Wi-Fi와 Bluetooth 다음으로 3번째로 높은 시장을 보여준다. 이뿐만 아니라 ZigBee는 스마트홈 시장의 스마트 도어락 분야에서 90%를 상회하는 시장침투율을 기록하고 있다.

IoT의 보급률은 꾸준하게 증가하고 있지만, IoT에서 사용하는 무선 네트워크 프로토콜은 기존에 문제점이 발생한 프로토콜을 계속해서 사용하거나 사용자에게 많은 인증 수단을 요구하는 등의 문제점이 있다.[3] 예를 들어 무선 네트워크 보안 프로토콜 문제로 수많은 IoT를 불법적으로 이용하여 분산 서비스 거부 공격으로 사용되거나, 중요 시설에서 사용하는 IoT의 통신 내용이 유출되는 사고가 계속해서 발생하고 있다. 따라서 IoT 환경에서 사용자의 편의성을 높이고, 강력한 인증 및 암호화를 제공할 수 있는 무선 네트워크 프로토콜에 대한 연구가 필요하다.

IoT의 핵심요소인 무선 네트워크 프로토콜은 IEEE 802.15.4와 IEEE 802.11 기반으로 발전해 왔다.[4][5] 본 논문에서는 IoT 디바이스에서 사용하는 무선 네트워크를 보호하기 위해 최근 연구되어 상용화 준비 중인 IEEE802.11 WPA3(Wi-Fi Protected Access)에서 사용하는 인증 기법 OWE(Opportunistic Wireless Encryption)를 ZigBee에 적용한다. 또한, 공개된 무선 네트워크 환경에서의 IoT 디바이스 보안과 데이터 유출 방지를 위한 인증 및 암호화 방법에 대해 연구하고자 한다.

본 논문의 구성으로 2장에서는 기존 ZigBee 프로토콜을 분석하고 기존 취약점에 대해 검증한다. 이후 ZigBee에 적용할 Wi-Fi OWE 프로토콜을 분석하여 ECDH(Elliptic-Curve Diffie-Hellman)를 인증 단계에서 적용하는 방법을 확인한다.

3장에서는 2장에서 분석한 내용을 바탕으로 기존 프로토콜을 구현하고, OWE가 적용된 프로토콜을 구현한다.

4장에서는 OWE가 적용된 프로토콜에 기존 취약점이 해결되는지를 확인하기 위해 Wireshark를 활용하여 검증하며, 마지막으로 5장에서는 결론을 기술한다.

2. ZigBee 인증 프로토콜 분석

저전력, 저사양의 IoT 장치에서 사용할 수 있는 무선 네트워크 프로토콜인 ZigBee는 IEEE 802.15.4 표준을 기반으로 개발된 프로토콜이다.

ZigBee는 최대 65,536개의 장치를 연결할 수 있으며 필요한 경우에만 작업을 진행하는 휴면 상태를 지원한다. 사용하는 주파수는 IEEE802.11의 Wi-Fi와 같은 2.4GHz를 사용하고, Wi-Fi의 간섭을 피하기위해 915MHz, 868MHz 대역을 사용하기도 한다.[6]

또한, ZigBee는 (그림 1)과 같이 4개의 계층으로 이루어져 있다. 물리계층과 데이터링크계층은 IEEE 802.15.4 규격을 사용하고 네트워크 계층과 애플리케이션 계층은 ZigBee Specification에 기반을 둔다. 또한, 보안의 경우 네트워크 계층과 애플리케이션 계층에서 관리되고 있다.[7]

(그림 1) ZigBee 프로토콜 스택 구조

ZigBee를 사용하는 IoT 디바이스가 네트워크에 연결하기 위해서는 (그림 2)와 같이 End Device(IoT)와 데이터를 전달하고 네트워크를 구성할 수 있는 Coordinator(AP, Access Point), End Device와 Coordinator의 연결과 보안 키를 관리하는 Trust Center로 구성되어있다.

(그림 2) ZigBee 연결과정

다만, Coordinator와 Trust Center가 분리되어 있는 사용자는 대규모 센서 디바이스들과 Coordinator를 사용하는 환경에서 사용하고 있으며 일반 사용자는 Coordinator와 Trust Center가 합쳐진 형태로 구성되어있다.

(그림 2)의 경우 Coordinator와 Trust Center가 합쳐진 환경에서의 연결과정을 나타내고 있다. 이때 End Device가 네트워크에 연결되기까지는 IEEE 802.15.4 MAC Association 과정과 자신의 정보를 알려주는 Device Announce 과정, 상대방의 정보를 요청하는 Node Descriptor Request, Response 과정을 거친 뒤 Application Data를 암호화하기 위한 키를 요청하는 단계인 Request Key, Transport Key, Verify Key, Confirm Key 과정이 존재한다. 이때 Transport Key 과정의 경우 Network Key를 전송할 때도 사용이 된다.

2.1 MAC Association 과정

ZigBee의 MAC Association 과정은 Beacon Request, Beacon, Association Request, Association Response로 구분되며 IEEE 802.15.4의 규격을 따른다.

IEEE 802.15.4 규격은 ZigBee 프로토콜에서 MAC 계층에 사용되므로 모든 패킷에서 사용된다. <표 1>은 IEEE 802.15.4 규격에서 사용되는 필드 중 ZigBee에서 주로 사용되는 Frame Control 필드에 대한 설명이다.

<표 1> IEEE 802.15.4 Frame Control Field

Beacon Request 패킷은 End Device에 전원이 인가된 후 연결 설정이 필요할 때 가장 먼저 전송하는 패킷이다. Beacon Request 패킷은 짧은 주기를 가지며 Broadcast로 패킷을 전송하고 Beacon 패킷이 도착할 때까지 반복한다.

Beacon Request 패킷을 받은 Coordinator는Beacon 패킷을 전송한다. ZigBee의 Beacon 패킷은 (그림 3)과 같이 IEEE 802.15.4와 ZigBee Stack을 합쳐서 보내게 된다. 이때 End Device의 8Bytes MAC주소는 제조 시 기본으로 설정된 상태이지만 Short 주소는 설정되어 있지 않은 상태이다.

(그림 3) Beacon Request 패킷과 Beacon 패킷

또한, Beacon Request 패킷을 전송한 End Device는 Beacon 패킷을 통해 현재 네트워크의 PAN ID와 Coordinator의 4Bytes Short Address와 8Bytes Long Address를 얻을 수 있다.

Beacon 패킷을 받은 End Device는 자신이 사용할 4Bytes Short Address를 부여받고, 네트워크에 참여하기 위해서 Association Request를 생성하여 Coordinator에게 전송한다. 해당 과정은(그림 4)와 같이 동작하며 Association Request와 Association Response 사이에 Acknowledge 패킷과 Data Request 패킷이 존재하는 것을 확인할 수 있다.

(그림 4) Association Request/Response

Acknowledge 패킷은 전송한 패킷을 받았는지 확인하는 용도로 사용되고 있으며 Acknowledge 패킷의 Frame Pending Field가 True로 설정된 경우 이후 데이터를 전송한다.

또한, Data Request 패킷의 경우 Association Request 패킷과 같이 전송 후 자신이 받을 패킷이 있는 경우 데이터를 요청하는 패킷이며 (그림 4)와 같이 구성된 것을 확인할 수 있다.

2.2 Key Exchange 과정

MAC Association 과정이 끝나면 End Device와 Coordinator는 <표 2>와 같은 정보를 얻을 수 있다. 이때 Default ZigBee Trust Center Link Key(D-TCLK)는 “ZigBeeAlliance09”라는 문자열을 Hex로 변경한 값으로 End Device와 Coordinator 사이에서 기본으로 사용하는 암/복호화 키다.

<표 2> MAC Association까지 얻은 정보

D-TCLK는 사전에 고정된 키로 ZigBee를 사용하는 Device를 공격하려는 공격자도 쉽게 획득할 수 있는 정보이다. 이러한 특성을 가지는 D-TCLK는 다양한 취약점을 가질 수 있다.

ZigBee Key Exchange 과정은 Network Key를 공유하는 과정과 Link Key를 공유하는 과정이 있다.

Network Key를 공유하는 과정은 Transport Key 패킷만 End Device에게 전송하며 Link Key를 공유하는 과정은 Request Key, Transport Key, Verify Key, Confirm Key로 구성되어있다.

먼저, Request Key 패킷의 경우 모든 Device의 정보를 수집한 End Device가 Application Layer를 암호화할 수 있는 기존 D-TCLK를 End Device와 Coordinator 사이에서만 사용할 TCLK를 요청한다. Request Key 패킷부터는 Network Layer와 Application Layer가 암호화되어 전송되며 Network Layer는 앞선 Transport Key에서 받은 Network Key를 사용하고 Application Layer는 D-TCLK를 사용하게 된다.

Network Key를 전송하는 Transport Key 패킷은 Network Layer를 암호화할 수 있는 Network Key를 전송하게 된다. 이때 Network Key를 전송하기 위해서는 D-TCLK만 알고 있고 Network Key는 알 수 없으므로 Application Layer만 암호화하여 전송한다.

해당 패킷에서는 Application Layer 영역인 Transport Key를 암호화하고 ZigBee Application Support Layer Command의 Frame Control Field의 Security Field가 True(1)로 설정된 것을 확인할 수 있다. 위에서 설명한 것과 같이 ZigBee Network Layer Data의 Frame Control Field의 Security Field는 Network Key가 없으므로 False(0)로 설정되어 암호화하지 않는다. 따라서 (그림 5)와 같은 구조로 암호화하고 MIC를 생성한다.

(그림 5) Transport Key(Send Network Key)

Link Key를 전송하는 Transport Key 패킷은 Network Layer와 Application Layer가 암호화되어 Link Key를 전송하게 된다. 이때 (그림 6)과 같이 Network Layer와 Application Layer가 암호화 및 MIC를 생성하게 되며 Application Layer는 Link Key와 Network Key로 2번 암호화되는 구조를 가지고 있다.

(그림 6) Transport Key(Send Link Key)

Link Key를 받은 End Device는 자신이 받은 Link Key가 Coordinator가 보낸 Link Key인지 확인하기 위해서 Key Hash 값을 생성하여 Verify Key 패킷을 전송한다. 이때 Verify Key 패킷은 Network Layer만 암호화하여 전송하게 된다.

Verify Key 패킷을 받은 Coordinator는 Key Hash를 검증하여 결과를 Confirm Key 패킷으로 전송해준다. 검증 결과가 성공이면 Transport Key에서 전달된 Network Key와 Link Key를 사용하여 암호화한다. 또한, 이후 데이터 패킷을 암호화하여 전송할 수 있으며 연결과정이 마무리된다.

3. Wi-Fi OWE 인증 프로토콜 분석

OWE 인증 프로토콜의 전체 과정은 (그림 7)과 같이 Wi-Fi WPA2 인증과정과 같다. 먼저 AP는 주기적으로 자신의 정보인 Beacon Frame을 생성하여 Broadcast로 전송한다. AP에 접속하려는 Station은 이를 확인하고 Probe Request를 통해 AP의 정보를 다시 한번 확인한다. Probe Request를 받은 AP는 자신의 정보를 Probe Response를 통해 전송하고 이후 공개 시스템으로 Authentication을 진행한다. Association 과정의 경우 OWE에서는 서로의 공개키를 전송하고 이를 바탕으로 공유키를 생성하게 된다.

(그림 7) Wi-Fi OWE 인증 프로토콜 전체 과정

3.1 OWE 키 교환 과정 분석

OWE 프로토콜 인증과정에서 가장 핵심인 과정은 Association 과정이다. Association 과정은 연결된 세션에서 사용할 암호화 방법이나 인증 방법을 선택하는 과정으로 OWE에서는 각자의 타원 곡선 공개키를 전송한다.

먼저 Association Request 패킷을 받은 AP는 자신의 개인키와 Station의 공개키로 Shared Secret(SS)을 생성한다. 이후 HKDF(HMAC-based Extract and Expand Key Derivation Function)를 사용하여 PMK(Pairwise Master Key)를 생성한다. 이후 AP도 Station에게 자신의 공개키를 전송한다. AP의 공개키를 받은 Station은 PMK를 생성하며 AP와 동일한 PMK를 생성하기 위해 PMK를 생성하는 과정은 Association Request를 받았을 때 AP가 연산하는 과정과 동일하다.[8]

따라서 상대방의 공개키를 받은 후 PMK를 생성하는 과정은 (그림 8)과 같다.

(그림 8) OWE 프로토콜의 PMK 생성 과정

3.2 OWE 인증 프로토콜 구현

패킷 구조를 구현하기 위해서는 기존 정의된 구조체를 사용할 수 있다. 하지만, OWE의 경우 최근에 개발된 프로토콜로 구현된 구조체가 없다. 따라서 구조체 정의가 간편한 C++을 사용하였고 그 외 구현 환경은 <표 3>과 같다.

<표 3> OWE 인증 프로토콜 구현 환경

OWE에서 사용하는 타원곡선은 RFC5903(Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2)에서 제공하는 P-256(256-bit Random ECP Group)을 사용하며 타원곡선에서 사용하는 값은 <표 4>와 같다.[9]

<표 4> P-256(256-bit Random ECP Group)

이를 위해 OpenSSL 라이브러리의 타원곡선(EC)에서는 “NID_X9_62_prime256v1”를 사용하여 P-256(256-bit Random ECP Group)을 사용할 수 있다. 따라서 (그림 9)와 같이 타원곡선 공개키와 비밀키를 생성할 수 있다.

(그림 9) OpenSSL 라이브러리의 P-256(256-bit Random ECP Group) 키 생성

Association 과정을 통해 얻은 상대방의 공개키는 HKDF를 통해 PMK를 도출하게 된다. HKDF는 (그림 10)과 같이 HKDF-extract과 HKDF-expand를 통해 키를 확장 및 유도하게 된다.

(그림 10) OpenSSL 라이브러리의 PMK 생성과정

이후 4-Way Handshake 과정을 통해 암호화키를 생성 및 검증하게 되어 OWE 연결과정이 마무리된다.

본 논문에서는 2개의 무선 랜카드를 사용하여 AP와 Station을 구현하였다. (그림 11-13)은 Station이 AP에 연결하는 과정을 보여주며 AP가 지속해서 전송하는 Beacon Frame을 확인 후 Probe Request부터 4-Way Handshaking 과정까지 키가 어떻게 생성되고 MIC를 생성 및 검증하는지를 보여준다. 또한, AP Log인 (그림 12)와 Station Log인 (그림 13)에서 Compute TK Log를 보면 암호화키가 0x576D6F08A55D8E4D78A6571267804F45로 동일한 것을 볼 수 있다.

(그림 11) Wireshark에서의 OWE 인증 과정

(그림 12) AP Log에서의 인증 과정

(그림 13) Station Log에서의 인증 과정

4. 개선된 ZigBee 인증 프로토콜 구현

기존 ZigBee 인증 프로토콜은 고정된 암호화키(ZigBeeAlliance09)로부터 Network Key와 Link Key가 유도된다. 이처럼 고정된 키로부터 다른 키가 유도되는 경우 전방향 안전성을 제공하지 못하여 Offline Dictionary Attack 등 다양한 취약점이 발생할 수 있다.

이를 해결하기 위해 본 논문에서 제안하는 개선된 ZigBee 인증 프로토콜은 ECDH를 적용하여 전방향 안전성을 만족할 수 있다.

4.1 개선된 ZigBee 인증 프로토콜 구조

ZigBee 인증 프로토콜에서 사용하는 Network Key는 동일한 Coordinator와 연결된 모든 장치가 같은 Key를 사용한다.

만약 Network Key를 ECDH로 유도하게 된다면 모든 장치가 유니크한 Network Key와 Link Key를 가지게 되어 매우 비효율적이다. 따라서 제안하는 인증 프로토콜 구조는 기존 ZigBee 인증 프로토콜에서 Link Key를 주고받는 과정에ECDH 과정을 추가한다.

4.1.1 제안하는 Request Key 구조

Link Key 요청 패킷인 Request Key 패킷에 (그림 14)와 같이 Key Type을 256-bit Random EGP Group으로 변경하고 하위에 공개키를 전달하도록 수정한다.

(그림 14) 제안하는 Request Key 패킷 구조

기존 Request Key 패킷의 Key Type은 <표 5>와 같이 6가지로 분류된다. 따라서 기존 Key Type과 겹치지 않도록 0x06으로 새로운 Key Type을 정의해준다.

<표 5> ZigBee Key Type

OWE에서는 기존 Association 패킷의 하위에 공개키를 추가 전달하는 방식을 사용하고 있다. 따라서 OWE와 같이 Request Key 패킷의 마지막에 공개키를 전달하기 위해 새로운 Field를 정의하여 전달할 수 있다.

4.1.2 제안하는 Transport Key 구조

Request Key 패킷을 통해 End Device의 공개키를 받은 Coordinator는 (그림 15)와 같이 OWE에서 PMK를 생성하는 과정을 진행한다.

(그림 15) 제안하는 ZigBee PMK 생성 과정

먼저 상대방의 공개키가 256-bit Random EGP Group에 포함되는지 확인한다. 이후 자신도 256-bit Random EGP Group 공개키, 개인키를 생성하고 Common Secret을 생성하기 위해 자신의 개인키와 상대방의 공개키를 곱한다.

위에서 생성된 Common Secret은 End Device와 Coordinator가 동일한 값을 생성하게 된다. 따라서 Common Secret으로 도출된 키와 검증값을 생성하여 서로 같은 키를 가지고 있는지 확인할 수 있게 된다.

OWE에서는 이러한 과정을 KDF(Key Derivation Function)을 통해 256 Bytes의 KCK(Key Confirm Key)와 265 Bytes의 PMK를 생성한다. 따라서 본 논문에서도 KDF를 사용하여 KCK와 PMK를 생성하고 KCK를 통해 PMK를 검증할 수 있다.

모든 과정을 마친 Coordinator는 자신의 공개키를 End Device에게 전송해야 한다. 이를 위해 (그림 16)과 같이 Transport Key 패킷의 Key Field를 이용하여 전송한다.

(그림 16) 제안하는 Transport Key 패킷 구조

Transport Key 패킷의 경우 기존에 Key Type Field과 Key Field가 존재하며 Request Key에서 사용하는 Key Type과 같이 0x06(256-bit Random EGP Group)을 사용하여 전송할 수 있다.

4.1.3 제안하는 Verify Key 구조

Transport Key 패킷을 받은 End Device는 Coordinator가 Request Key 패킷을 받아 자신의 개인키와 상대방의 공개키로부터 KCK와 PMK를 생성하는 과정을 동일하게 수행한다. 이때 End Device는 Request Key 패킷에서 전송한 공개키에 대응하는 개인키와 Transport Key에 들어있는 Coordinator의 공개키로 KCK와 PMK를 생성한다.

이후 Verify Key 패킷을 생성하기 위해 MIC를 생성해야 한다. MIC는 (그림 18)과 같이 Verify Key 패킷에서 MIC Field를 0으로 채운 후 해당 패킷의 Bytes를 통해 계산되며 HMAC과 KCK를 사용하여 도출하게 된다.

(그림 17) 제안하는 ZigBee MIC 생성 과정

(그림 18) 제안하는 Verify Key 패킷 구조

패킷 구조의 경우 (그림 19)와 같이 기존에 있는 MIC Field를 사용할 수 있으며 Request Key에서 사용하는 Key Type을 사용한다.

(그림 19) 제안하는 Confirm Key 패킷 구조

4.1.4 제안하는 Confirm Key 구조

Verify Key 패킷을 받은 Coordinator는 자신이 도출한 KCK를 사용하여 MIC를 계산하고 검증한다. 만약 Verify Key 패킷에서 받은 MIC와 Coordinator가 계산한 MIC가 동일한 경우 성공 코드를 보내준다.

Confirm Key 패킷은 기존 ZigBee 인증과정에서 MIC를 검증하고 검증 결과를 전달해주는 패킷으로 Status Field가 존재한다. 따라서 (그림 19)와 같이 기존 Field를 활용할 수 있다.

4.2 개선된 ZigBee 인증 프로토콜 구현

ZigBee 인증 프로토콜은 기존에 정의되어 있는 구조체가 Python의 Scapy 라이브러리에 존재한다. 또한, PyCryptoDome 라이브러리는 Python에서 타원곡선뿐만 아니라 다양한 암호알고리즘을 지원한다. 따라서 본 논문에서 제안하는 개선된ZigBee 인증 프로토콜의 구현 환경은 <표 6>과같다.

<표 6> OWE 인증 프로토콜 구현 환경

먼저 기존 구현된 Scapy의 ZigBee Layer에서 (그림 20)과 같이 256-bit Random EGP Group Key Type을 추가해야 한다.

(그림 20) Custom ZigBee Protocol Key Type

이후 모든 패킷에서 사용할 수 있도록 정의한 Key Type을 적용하고 Request Key 패킷과 Transport Key 패킷에 64Bytes 키 길이를 가지는 Filed를 (그림 21)과 같이 추가한다.

(그림 21) Custom ZigBee Request Key

위와 같이 패킷 구조를 수정하고 패킷을 전송하여 패킷 스니핑 도구인 Wireshark를 통해 수정된 패킷을 확인할 수 있다. 하지만 Wireshark에서는 기존 사용하는 구조만 확인할 수 있어 제안하는 인증 프로토콜을 확인할 수 없다.

따라서 본 논문에서는 Wireshark의 소스코드를 임의로 수정하였다. 먼저 Key Type을 추가하기 위해 “packet-zbee-aps.h/c” 파일에서 (그림 22)와 같이 새로운 Key Type을 추가하였다.

(그림 22) Wireshark ZigBee Key Type 추가

또한, 256-bit Random EGP Group Key를 사용하는 경우 64Bytes 키를 확인할 수 있도록 (그림 23)과 같이 item을 추가하였다.

(그림 23) Wireshark Request Key 수정

위와 같은 방법으로 모든 패킷 구조를 변경하고 Wireshark에서 제안하는 ZigBee 인증 프로토콜을 확인하면 (그림 24)와 같이 변경되는 것을 확인할 수 있다.

(그림 24) OWE를 적용한 Request Key 패킷

4.3 개선된 ZigBee 인증 프로토콜 검증

Wireshark에는 초기 ZigBee 인증과정에서 사용하는 Trust Center Link Key인 “576D6F08A55D8E4D78A6571267804F45(ZigBeeAlliance09)”를 (그림 25)와 같이 입력하면 모든 과정을 복호화해주는 기능이 존재한다.

(그림 25) Wireshark Pre-configured Keys 입력

해당 기능을 활용하면 Wireshark에서는 사용된 Key 종류와 복호화된 내용을 보여준다. 따라서 본 논문에서 제안하는 프로토콜은 기본 Trust Center Link Key를 입력하더라도 복호화가 불가능한 것을 보여주어야 한다.

본 논문에서 제안하는 개선된 ZigBee 인증 프로토콜을 Wireshark에서 살펴보면 (그림 26)과 같이 암호화된 데이터를 복호화하지 못하여 Undecoded로 표시되는 것을 확인할 수 있다.

(그림 26) 전방향 안전성을 만족하여 복호화가 불가능한 Confirm Key 패킷

하지만 프로토콜 동작 과정에서 PMK를 확인하여 직접 입력한 경우 (그림 27)과 같이 복호화가 되는 것을 확인할 수 있다. 따라서 제안하는 ZigBee 인증 프로토콜이 전방향 안전성을 만족하고 있다는 것을 알 수 있다.

(그림 27) OWE를 적용한 Confirm Key 패킷

5. 결론

최근 IoT에서 사용할 수 있는 다양한 프로토콜을 통합하여 사용할 수 있는 새로운 프로토콜에 대한 연구 또한 활발하게 이루어지고 있다. 하지만, ZigBee 인증 프로토콜에서 발생할 수 있는 한계점을 해결하지 않고 Application Layer에서만 프로토콜을 통합하는 연구가 대다수이다.

따라서 본 논문에서는 WPA3에서 개발된 OWE를 ZigBee 환경에 적용하여 전방향 안전성을 만족하는 프로토콜을 구현하였다. 그 결과 기존 Wireshark에서 노출되었던 Link Key를 안전하게 교환할 수 있으며, 복호화가 가능하였던 데이터와 Confirm Key 패킷 등이 복호화가 더 이상 불가능한 것을 확인하였다. 또한, 기존 프로토콜의 문제점을 효과적으로 해결하여 별도의 비밀번호나 인증서가 필요 없어 안전성을 강화함과 동시에 사용자에게 편의성을 제공할 수 있다.