LoRa 1.0 취약점 분석
(2018년 ~ 2019년 초반 과거 메모, 논문 쓰려다 망해서 던진 것, LoRa 1.1에 있는 내용 ㅠㅠ)
Abstract
사물인터넷은 4차 산업을 주도하는 대표적인 기술 중 하나이다. 사물인터넷은 다양한 산업분야에 적용이 가능하다. 사물인터넷을 여러 분야, 환경, 상황에 적용하기 위해서는 저전력, 광대역, 저비용 등의 특징이 필요하다. 이러한 조건의 적합한 기술은 LPWAN(Low Power Wide Area Network)이 적합하며, 대표적인 기술은 LoRaWAN(LongRangeWAN)이 있다. 이와 같은 기술을 적용하여, 사물인터넷 기술은 농업, 제조업, 서비스업 등 다양하게 사용할 수 있다. 그러나 사물인터넷은 많은 보안 위협에 노출되어 있으며, 실로 외부로부터 많은 공격을 받았고, 지속적으로 받고 있다. 또한 LoRaWAN의 경우, 기본적인 암호키 관리 체계가 상당히 부족하며, 위와 같은 현상은 절대적인 보안 취약점의 요소이다. 본 논문은 LoRaWAN의 암호키의 사용, 관리 및 유지에 대한 취약점 분석을 실시하며, 개선 모델을 제안한다.
1. 서론
4차 산업혁명을 바라보는 오늘날,, 사물인터넷(Internet-of-Things, IoT)은 4차 산업혁명을 주도하는 핵심기술 중 하나이다. 이에 부응하여 IoT와 관련된 다양한 기술과 서비스들이 등장하고 있다.
IoT 기기는 제한된 배터리와 전원이 공급되지 않는 곳에 장기간 설치하여 안정적으로 동작하며, 데이터 송/수신을 하는 경우가 많다. 대부분의 데이터 통신은 단순한 유선 통신이 아닌, 무선 환경을 이용한 무선통신이다. IoT에 적합한(광대역, 저전력, 저비용, 적절한 통신 속도, 소량의 데이터 전달) 통신 규격은 LPWAN이다. LPWAN 기술은 대표적으로 총 4가지가 있으며 다음과 같다. LoRaWAN, Sigfox와 같은 비면허 대역과 LTE-M, NB-IOT와 같은 면혀대역의 LPWAN이 있다.
각각의 LPWAN은 장단점이 존재하며, 특정 기술로 모든 IoT에 동일하게 적용할 수 없으며, 사용 환경과 서비스에 적절하게 각각의 LPWAN을 적용해야 한다. 예를 들어, 높은 데이터 통신 품질, 높은 데이터 통신 빈도 및 양을 우선시하는IoT 기기는 NB-IOT, LTE-M이 적합하며, 저렴하고 넓은 데이터 통신 커버리지와 데이터 통신 품질에 의존하지 않는 경우, LoRaWAN, Sigfox가 적합하다.[2]
그러나 LPWAN 기술에서의 보안은 부차적인 요소로 되어있다. 각각의 LPWAN의 보안 적용 방법도 가지각색이며, 보안에 취약한 사항이 존재한다. IoT의 서비스는 하나의 개인과 점점 밀접해지며, 이러한 데이터는 기밀성, 무결성은 보호되어야 한다.
본 논문은 최근 IoT에서 많이 사용하는 비면허 대역 LoRaWAN[3]의 보안 취약점 중 암호키 관리 방안에 대한 취약점을 중점적으로 분석했다.
본 논문의 구성은 다음과 같다. 2장은 LoRaWAN의 암호키 배포 과정(Join 과정)과 취약점 분석 선행 연구 분석을 다루고 이를 토대로 3장에서 LoRaWAN 암호키 관리 방안 취약점 분석을 하여, 문제점을 열거한다. 그 후, 4장은 결론을 맺는다.
2. 관련 연구
2장 관련 연구는 다음과 같다. LoRaWAN 암호키 라이프 사이클은 LoRaWAN의 암호키의 주입과 배포, 세션키 유도, payload의 암/복호화, payload의 무결성 검증, 디바이스 식별 및 인증 절차 등 암호키와 관련된 보안 구조를 분석한다. 그리고 위의 과정의 취약점 분석에 대한 선행 연구를 분석한다.
2.1 LoRaWAN 암호키 Join 과정
LoRaWAN은 아래 [그림 1]과 같이 두 개의 계층 별 암호화를 제공한다. MAC 계층의 암호화는 디바이스의 식별 및 인증 부분이며, Application 계층의 암호화는 디바이스에서 실질적으로 송신하고자 하는 데이터 즉 payload의 암호화를 담당한다. 두 개의 계층은 모두 AES128 대칭키를 사용하며, 상이한 유도식을 통해 산출된 다른 암호키를 사용한다.
암호키를 위의 [그림 1]과 사용하기 위해서는 기기 정보 및 암호키의 사전 주입과 활성화 절차가 필요하다. 활성화 절차는 OTAA(Over- The-Air Activation), ABP(Activation by Personalization) 두 가지의 방법이 있으며, 위의 두 가지 방법마다 상이한 사전 주입 절차를 갖고 있다. OTAA은 기기 출하 전, 사전에 DevEUI, AppEUI, AppKey(PSK, Pre-Shared Key)를 기기에 주입을 한다. 기기는 위의 세 가지 정보를 통해 NS(Network Server)와의 Join 과정을 거쳐, 두 개의 Session Key(NwkSKey, AppSKey)를 얻는다. ABP은 갱신되지 않는 두 개의 Session Key를 통해 NS와 송/수신을 한다. 그러나 더 나은 보안성을 제공하기 위해서는 OTAA 방식을 권고한다[4]. 또한 본 논문은 OTAA 방식에서의 암호키 관리 방안에 대한 취약점 분석을 진행한다.
OTAA은 DevEUI, AppEUI, AppKey를 기기에 주입 후, 기기 최초 개통 또는 초기화를 할 때 Join 과정을 진행한다. Join 과정은 다음 [그림 2]와 같다.
첫 번째 LoRa Mote는 NS에 AppEUI, DevEUI, DevNonce 값과 MIC(Message Integrity Code) 값을 보낸다. MIC를 제외한 세 개의 값은 평문으로 전송된다. AppKey는 기기 출하 전, 사전에 공유된 키이다. DevNonce는 재전송 공격을 방지하기 위한 Mote에서 임의로 생성된 2옥텟 값이며, MIC는 기기의 인증을 위한 값이다. MIC 값 계산식은 다음과 같다.
cmac = aes128_cmac(Appkey, MHDR | AppEUI | DevEUI | DevNonce)
MIC = cmac[0..3]
두 번째 NS는 먼저 DevNonce 값을 통해 재전송 공격을 방지 절차를 진행한다. DevNonce 값이 일전에 사용되었을 경우, 요청은 거절된다. 그 후, Join요청을 한 DevEUI의 AppKey, Mac Header 등 위의 MIC 계산 식을 통해 MIC 인증 절차를 진행한다. 인증을 성공했을 경우, 두 개의 Session key인 Network Session Key(NwkSKey), Application Session Key (AppSKey)를 생성한다. NwkSKey와 AppSKey의 유도석은 다음과 같다.
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad )
AppSKey = aes128_encrypt(Appkey, 0x02 | AppNonce | NetID | DevNonce | pad )
세 번째 위의 인증 및 두 개의 세션키 생성 완료 후, Mote에 Join Accept Message를 송신하기 위해, 암호키 유도식에 사용된 AppNonce, NetID 등을 AppKey를 이용하여 다음과 같이 암호화한다.
cmac = aes128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList)
네 번째 생성된 AppSKey는 Mote와의 E2E 통신을 위해 AS(Application Server)에 송신한다[6]. LoRaWAN 규격은 AppSKey의 송신 시점을 명확하게 정의하지 않았다[5].
다섯 번째 Mote는 Join Accept Message를 수신하여, AppKey를 통해 복호화를 하여 Session Key(NwkSKey, AppSKey)두 개를 생성한다.
결과적으로 Mote는 AppKey, NwkSKey, AppSkey를 보관, NS는 AppKey, NwkSKey를 보관, AS는 AppSKey를 보관한다.
위와 같은 Join 과정이 완료되면 Mote, NS는 양단간 UpLink 또는 DownLink 준비가 끝난다. Mote의 주기 보고(UpLink)가 있을 경우, [그림 3]과 같이 암호화되어NS에 송신한다. Mote에서 실질적으로 송신하고자 하는 데이터 payload인 FRMPayload(MAC Frame Payload)를 AppSKey를 통해 AES128 CMAC, CTR 모드를 활용하여 암호화한다. 메시지 무결성을 위해 Mac Header(MHDR), Frame Header (FHDR), FPort, 암호화된 FRMPayload의 MIC를 [그림 3]과 같이 계산한다[7]. MIC 계산식은 다음과 같다.
cmac = aes128_cmac(NwkSKey, B0| msg)
MIC = cmac[0..3]
위의 식 은 UpLink 또는 DownLink의 구분자 역할을 한다.
2.2 LoRaWAN 암호키 관리 방안 취약점 분석 선행 연구
현재 LoRaWAN의 암호키 사용, 관리 및 유지함에 있어 취약점이 존재한다. 이런 취약점은 보안 사고와 개인(민감) 정보의 유출로 이어진다. 본 논문의 선행 연구 분석은 LoRaWAN의 암호키 관리에 대해 취약점을 언급한 선행 연구만 분석한다.
선행 연구에서 언급한 LoRaWAN의 암호키 관리 측면에서의 취약점은 [표 1]과 같다.
첫째 암호키의 관리 주체는 NS 또는 AS이다. LoRaWAN의 암호키의 보관, 사용, 유지, 분배, 폐기 등 모든 프로세스는 NS와 AS에서 이루어진다. 이와 같이 관리를 할 경우, 인가되지 않은 내부자의 접근을 허용하여, 암호키의 누수와 오용을 범할 여지가 있다.
두 번째 AppKey의 갱신 프로세스가 존재하지 않는다. AppKey를 통해, 두 개의 세션키를 유도하지만, 본질적으로 사용하는 AppKey의 수명은 Mote의 수명과 같다. 즉, AppKey가 노출될 경우, 그간 사용했던 Session Key가 복구될 위험성이 있다.
세 번째 Mote의 OTAA 활성화의 경우, Join 과정이 존재하는데, Join Request(Mote->NS)의 payload는 평문으로 전송된다. Mote의 식별 값과 암호키 유도 재료 중 하나의 노출로 인하여 기밀성을 위배할 수 있다.
[표 1]의 선행 연구 분석 결과와 같이 LoRaWAN은 암호키 관리 측면에서 많은 취약점이 존재한다. III장 취약점 분석은 선행 연구의 취약점 분석에서 언급하지 않은 부분과 추가적인 취약점 분석을 실시한다.
|
취약 사항 |
참고문헌 |
|
ECB 암호 모드를 사용한다. |
[8] |
|
암호키의 관리 주체는 NS와 AS이다. |
[8][12] |
|
MACPayload의 FPort 0 일 경우, payload는 NwkSKey를 통해 암호화를 한다. |
[8] |
|
AppKey(PSK)의 온라인 갱신 프로세스가 존재하지 않는다. |
[5][8] |
|
Mote와 AppKey의 생명주기가 같다. |
[8] |
|
AppKey의 합의 및 폐기 메커니즘이 존재하지 않는다. |
[8] |
|
낮은 Byte의 Nonce 값으로 인하여, 재전송 공격에 취약하다. |
[9][10] [11] |
|
NS는 AS, NS의 세션키를 만든다. 즉, 계층간의 암호화를 하지 않는다. |
[5] |
|
OTAA Join Request의 본문은 암호화되지 않고, NS에 송신된다. |
[5][10] [11] |
3. 취약점 분석
III장 취약점 분석은 선행 연구 분석 토대로 추가적으로 LoRaWAN의 암호키에 관련한 취약점을 분석한다. 취약점 분석 관점은 암호키의 관리와 사용 측면을 중점으로 분석한다.
첫 번째 위의 선행 연구 “Mote와 AppKey의 생명주기가 같다.”와 같이 현재 LoRaWAN은 암호키의 생명주기, 상태별 프로세스, 정책이 존재하지 않는다. 암호키의 생명주기는 NIST 키 관리 권고사항의 활성화, 비활성화, 폐기, 손상 등 Mote마다 암호키의 최초 생성부터 유지 및 폐기까지의 암호키의 생명주기와 암호키 상태별 사용 용도를 차등적으로 적용해야 한다[13]. 또한 Mote의 서비스 수준, 처리하는 데이터의 민감도, 용례 등을 통해 위험 평가를 실시하여, 보안 모델을 산정해야 한다[14]. 이와 같은 보안 모델을 통해 암호키의 수명을 측정해야 한다. 암호키의 수명은 암호 메커니즘, 데이터의 트랜잭션의 양, 데이터의 민감도, 키의 노출/사용 정도 보안 모델 요소 등으로 암호키의 수명을 차등적으로 부여해야 한다[15].
두 번째 위의 선행 연구 “ECB 암호 모드를 사용한다.”와 같이 현재 LoRaWAN은 암호키를 통해 암호화를 할 때, IV 값이 존재하지 않는다. 또한 규격에는 IV 값에 대해서 언급을 하지 않았다. IV의 공유 방법이나 어떤 페킷에 적재하는지에 대한 여부가 존재하지 않는다. IV는 같은 평문을 지속적으로 암호화를 하여도 다른 암호문을 출력하기 위한 암호화 재료이다. IV는 재사용되지 않으며, 암호화의 필요성이 없다. LoRaWAN은 16Byte의 암호키 길이를 사용하며, 이와 적합한 IV는 16Byte이므로[18], 이에 적합한 페킷을 적재할 수 있는 공간이 필요하다.
세 번째 세션키 NwkSKey, AppSKey에 대해 갱신 권고 사항이 존재하지 않는다. 세션키는 Mote와 NS 간의 Join 과정에서 확립된다. Join 과정은 Mote의 최초 개통 호 처리 또는 초기화를 하였을 경우만 진행한다. 즉, Mote의 최초 개통 호 작업 후 Mote단에서 초기화 절차를 진행하지 않을 경우, 세션키의 생명주기는 Mote와 같을 수 있다. 세션은 둘 이상의 통신 장비 간, 일정 시간 유효 연결을 확립하여, 요청 및 응답을 처리하는 절차이다[16]. 세션키 또한 한 세션에서 유효한 키를 의미한다[17]. LoRaWAN 환경에서의 지속적인 세션키 갱신은 사실상 어려움이 존재한다. 그러나 일정 주기마다 세션키를 갱신하는 절차를 확립해야 한다.
네 번째 AppKey의 합의 메커니즘을 분석한다. 선행 연구[8]에서는 AppKey의 합의 메커니즘 부재에 대해 문제점으로 지적하였으며, ECDH(Elliptic Curve Diffie-Hellman) 알고리즘을 통해서 해결안을 제시하였다. 현재 LoRaW- AN의 AppKey는 세션키를 유도할 때와 Join Accept Message를 암호화할 때 사용한다. 또한 AppKey에 대해 갱신 권고사항과 규격이 존재하지 않아, AppKey와 Mote의 생명주기가 같다. 위와 같은 문제점은 AppKey의 갱신 절차를 통해 해결할 수 있다. 그러나 AppKey의 암호키 교환 프로토콜(합의 메커니즘)를 적용할 경우 다음의 우려사항이 존재한다.
LoRaWAN에서의 Class A의 Mote의 경우, Mote의 UpLink를 통해서 NS의 DownLink가 가능하다. NS는 주체적으로 DownLink를 하지 못하는 제약이 존재한다. 또한 Mote의 높은 SF(Spreading Factor)는 낮은 Bit Rate로 인하여, 무선 통신은 외부의 잡음에 쉽게 노출된다. 결국 위와 같은 현상에서의 송/수신은 무선 통신의 높은 실패 확률을 초래한다[19].
이러한 통신 환경은 암호키 교환 프로토콜의 적용보다는 PSK가 적합하다. 현재 LoRaWAN에서 사용하는 암호키의 길이 128bit는 적합한 암호 비도를 갖고 있으며, 또한 이미 PSK 기술을 적용한 WPA(Wi-Fi Protected Access)는 다양하게 활용하고 있다. PSK를 안전하게 사용하는 조건은 신뢰된 제3의 서버의 암호키 발급과 갱신이 필요하다.
여기서부터 막장ㅋㅋㅋ
4. LoRaWAN 암호키 보호 모델 제안
선행 연구 분석과 추가적인 취약점 분석을 통해 LoRaWAN은 제3의 신뢰 서버가 필요하며, 안전한 암호키 사용과 유지를 위해서는 암호키 관리 체계와 안전한 암호키 배포 및 접근을 위한 식별 및 인증/인가의 체계 적용이 필요하다. 신뢰 서버의 구성요소는 아래 [그림 4]와 같다.
신뢰 서버는 암호키의 관리, 유지, 배포, 갱신 및 폐기 등의 암호키 사이클 관리를 한다. NS와 AS는 신뢰 서버 API를 통해 값의 암/복호화를 진행하며, 암호키의 관리는 신뢰 서버에 위임을 한다.
암호키의 전체적인 관리와 유지 및 갱신 등의 운영을 한다. 용례는 [그림 5]와 같다.
HSM 난수 발생기를 통해 임의의 암호키 생성 규격에 맞게 암호키 PSK를 생성한다. 생성된 PSK는 HSM의 KEK(Key Encryp -tion Key)를 통해 포장(Wrapping)하여, 안전하게 보관한다.
PSK는 Mote에 배포 및 주입되며 개통 호 작업을 실시한다.
Join 과정을 할 때 신뢰 서버는 중계 서버 역할을 한다. NS는 Mote의 식별 및 인증을 하며, Join 과정에 필요한 데이터를 신뢰 서버에 송신한다. 신뢰 서버는 NS에서 받은 필요 데이터와 함께 NwkSKey와 AppSKey를 생성한 후, Mote에 송신한다.
Mote에서의 UpLink를 받은 NS는 무결성 검증에 필요한 데이터를 신뢰 서버에 송신한다. 신뢰 서버는 해당 데이터와 NwkSKey를 통해 무결성 검증을 실시한다.
NS는 암호화된 FRMPayload를 AS에서 송신한다.
AS는 NS로부터 받은 암호화된 FRMPay -load를 신뢰 서버에 송신하여, 복호화된 FRMPayload를 수신한다.
이와 같이 구성할 경우, NS와 AS의 독립된 계층 관리를 할 수 있다. 데이터의 암/복호화는 신뢰 서버에서 진행하며, NS와 AS는 암호키의 값이 필요 없다. 신뢰 서버는 NS와 AS의 식별/인증/인가를 통해 적합한 사용자(NS 또는 AS)를 파악할 수 있다.
신뢰 서버는 Mote의 서비스 보안 수준 진단을 통해 암호키 보호 수준과 암호키의 생명주기를 결정하여, 암호키의 안전성을 지속적으로 유지한다. 또한 해당하는 보호 수준에 상응하는 정책을 적용한다.
Mote의 보안 수준과 정책에 맞게 AppKey, AppSKey, NwkSKey의 지속적인 갱신 절차를 적용한다.
암호키의 생명주기는 NIST 암호키 권고 사항의 권고안을 적용한다. 암호키의 상태 및 상황별 암호키의 생성, 등록, 백업, 복구, 검색, 수정, 폐기, 말소, 검증, 인증 등의 운영체계를 확립해야 한다.
결론
결론 대외비
[참고문헌]
[2] K. Mekki, E. Bajic, F. Chaxel and F. Meyer, "A comparative study of LPWAN technologies for large-scale IoT deployment", ICT Express, Vol. O, no. O, pp.00~11, Sep 2017
[3] N. Sornin, M. Luis, T. Eirich and T. Kramp, "LoRaWAN Specification V1.0.1 Draft 3", LoRa Alliance, Oct 2015
[4] "LoRa Security FAQ in LoRaAlliance", LoRa Alliance, Jul 2016
[5] JH Kim and JS Song, "A Dual Key-Based Activation Scheme for Secure LoRaWAN", Wireless Communication and Mobile Computing, Vol. 2017, Article ID 6590713, Nov 2017
[6] "LoRaWAN Security", LoRa Alliance, Jul 2016
[7] A. Augustin, J. Yi, T. Clausen, and W. M. Townsley, “A Study of LoRa: Long Range & Low Power Networks for the Internet of Things,” Sensors, vol. 16, no. 9, p. 1466, Sep 2016.
[8] van Leent, Marcel. "An improved key distribution and updating mechanism for low power wide area networks (LPWAN).", Cyber Security Academy, Vol. O, no. O, pp.00~11, Jan 2017
[9] Aras, E., Ramachandran, G. S., Lawrence, P., and Hughes, D., "Exploring The Security Vulnerabilities of LoRa." Cybernetics (CYBCONF), 2017 3rd IEEE International Conference on. IEEE, 2017.
[10] Na, S., Hwang, D., Shin, W., and Kim, K. H., "Scenario and countermeasure for replay attack using join request messages in LoRaWAN." Information Networking (ICOIN), 2017 International Conference on. IEEE, 2017.
[11] Tomasin, S., Zulian, S., and Vangelista, L., "Security Analysis of LoRaWAN Join Procedure for Internet of Things Networks." Wireless Communications and Networking Conference Workshops (WCNCW), 2017 IEEE. IEEE, 2017.
[12] R. Miller, "LoRa Security: Building a Secure LoRa Solution", MWR LABS, https://labs.mwrinfosecurity.com/publications/lo/
[13] NIST SP 800-57, "Recommendation for Key Management Part 1:General", 2012
[14] GSMA, IoT Security Guidelines Overview Document Version 2.0, CLP11, 2017.
[15] NIST SP 800-130, "A Framework for Designing Cryptographic Key Manage- ment Systems", 2013
[16]https://en.wikipedia.org/wiki/Session_(co mputer_science)
[17] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer, “RFC 4880 Open- PGP Message Format,” 2007.
[18] NIST SP 800-38A, "Recommendation for block cipher modes of operation", 2001
[19] Adelantado, F., Vilajosana, X., Tuset-Peiro, P., Martinez, B., Melia-Segui, J., & Watteyne, T. (2017). Understanding the limits of LoRaWAN. IEEE Communications Magazine, 55(9), 34-40., 2017
'개발관련 > 삽질' 카테고리의 다른 글
| 안전한 비동기 처리 전략(Feat. Spring) (0) | 2021.04.02 |
|---|---|
| Oracle/Tibero CURRVAL 사용 주의사항 (0) | 2021.03.29 |
| LoRaWAN 1.1 보안 부분 분석(LoRa Spec 6장 일부분 번역) (0) | 2021.02.04 |
| Java Enum 활용기(기본/활용/Spring/MyBatis/테스트까지) (2) | 2020.07.20 |
| 샤미르의 비밀 공유(SSS, Shamir's Secret Sharing) - 구현 (0) | 2020.05.12 |
