Korean Institute of Information Technology
[ Article ]
The Journal of Korean Institute of Information Technology - Vol. 19, No. 9, pp.57-68
ISSN: 1598-8619 (Print) 2093-7571 (Online)
Print publication date 30 Sep 2021
Received 20 Aug 2021 Revised 15 Sep 2021 Accepted 18 Sep 2021
DOI: https://doi.org/10.14801/jkiit.2021.19.9.57

IoT 헬스케어 기기에서의 중간자 공격 방어를 위한 디지털 서명 알고리즘 분석과 구현

전형석* ; 이성기**
*경북대학교 컴퓨터학부 박사과정
**경북대학교 컴퓨터학부 교수(교신저자)
Analysis and Implementation of Digital Signature Algorithm for the Defense of MITM Attacks in IoT Healthcare Devices
Hyeongseok Jeon* ; Sungkee Lee**

Correspondence to: Sungkee Lee School of Computer Science and Engineering, Kyungpook National University, 80 Daehakro, Bukgu, Daegu, 41566, Korea Tel.: +82-53-950-6375, Email: sklee@knu.ac.kr

초록

중간자 공격은 IoT 헬스케어 기기에서 전송되는 사용자 정보, 생체 신호 측정 자료의 유출 및 변조, IoT 헬스케어 기기가 오작동을 유발하여 사용자의 건강에 직간접적인 위해를 입힐 수 있다. 본 논문에서는 시스템 자원이 부족한 IoT 헬스케어 기기에서 중간자 공격을 방어할 수 있는 디지털 서명 알고리즘을 분석하고 적용하였으며, 경량 디지털 인증서를 정의하였다. IoT 헬스케어 기기에 사용되는 4종의 MCU 보드들에 128-bit 보안 수준의 디지털 서명 알고리즘 3종을 평가시험한 결과 secp256k1 타원곡선을 사용한 ECDSA가 실행 가능성과 실행 속도 측면에서 우수했다. 또한 ECDSA와 경량 인증서가 IoT 헬스케어 기기에서 중간자 공격을 방어할 수 있음을 검증하기 위해 원격 업데이트 상황의 IoT 헬스케어 기기와 중간자 공격을 모의하였다. 그 결과 중간자 공격자는 ECDSA와 경량 인증서가 적용된 모의 IoT 헬스케어 기기와 업데이트 서버 간 네트워크 연결에 개입할 수 없음을 입증하였다.

Abstract

MITM(Man-In-The-Middle) attacks can directly or indirectly harm users' health by leaking and modulating user information, vital sign data from IoT healthcare devices, and causing them to malfunction. In this paper, we analyzed and applied digital signature algorithms to defend against MIMT attacks on IoT healthcare devices having low system resources, and we also defined the light-weight digital certificate. After implementing and testing three digital signature algorithms that offer a 128-bit of security level on four MCU boards which are used in IoT healthcare devices, we found that the ECDSA using secp256k1 elliptic curve was excellent in terms of execution and speed. To verify that ECDSA and the light-weight certificate can defend against MITM attacks on IoT healthcare devices, we simulated a IoT Healthcare device in a remote update situation and a MITM attack. As a result, we prove that the MITM attacker was unable to intervene in the network connection between the simulated IoT Healthcare device and the update server which are ECDSA and the light-weight certificate applied.

Keywords:

internet of things, IoT, healthcare, network, security, remote update, ECDSA, EdDSA, Man-In-The-Middle attack, MITM

Ⅰ. 서 론

IoT(Internet of Things) 기기에 사용되는 MCU(Microcontroller Unit)의 시장 점유율은 2017년 기준으로 8-bit와 16-bit MCU가 40%를 넘고 2026년에도 여전히 30%에 이를 것으로 예상되는 만큼 IoT 기기는 성능과 가용 자원이 낮다[1]. 따라서 PC나 스마트폰 등 비교적 높은 성능의 시스템에서 동작하는 기존의 보안 방법들 중 일부는 IoT 기기에 따라 적용할 수 없거나 응답 속도 저하, 배터리 효율성 하락 등 부작용으로 인해 적용하는 것이 비효율적이다.

이러한 이유로 많은 IoT 기기들이 적합한 보안 방법 선택과 적용에 어려움을 겪고 있다. IoT 기기들의 보안 취약성은 특히 IoT 헬스케어 기기에서 그 문제점이 두드러진다. IoT 헬스케어 기기는 측정 또는 관리하고 있는 사용자의 건강상태를 스마트폰과 같은 게이트웨이를 통해 병원, 구급 및 소방서 등 의료 서비스 제공자에게 전달하여 측정 정보의 효율성을 증대시키고 능동적인 건강관리를 가능하게 하는 것을 목표로 한다. 그 결과 IoT 기기의 보안 취약성이 사용자의 건강 상태에 직접적인 위해를 가하거나 상위 의료 서비스의 신뢰성 손상, 업무 마비 등을 야기하여 피해가 확산 될 수 있다. 따라서 IoT 헬스케어 기기에는 보안 적용과 그에 따른 부작용 간 적합한 지점을 찾아 네트워크 공격으로부터 보호하는 것이 반드시 필요하다[2].

IoT 헬스케어 기기에 대한 주요 네트워크 공격 방법으로는 기기 간 네트워크 통신에 공격자가 개입하여 패킷을 탈취하거나 변조할 수 있는 중간자 공격이 있다. 중간자 공격을 통해 IoT 헬스케어 기기가 송수신하는 생체신호 측정 결과 메시지나 원격 업데이트를 위해 전송되는 소프트웨어를 변조함으로써 기기의 오작동을 유발하거나 병원 등 상위 시스템을 간접적으로 공격할 수 있다[3]. 따라서 IoT 헬스케어 기기의 목적과 특성을 고려하였을 때 중간자 공격을 방어하는 것이 가장 주요한 선결 과제이다.

본 논문에서는 다음과 같은 방법으로 자원이 부족한 IoT 헬스케어 기기에서 동작할 수 있으면서 중간자 공격에 대한 충분한 보안 수준(Security level)을 제공할 수 있는 방안을 제안하고 검증한다. 첫째, 2030년 이후에도 사용할 수 있을 것으로 알려져 있는 128-bits 보안 수준에 부합하는 3종의 디지털 서명 알고리즘을 선별하였다. 둘째, 선별한 3종의 알고리즘을 IoT 기기에 사용되는 저성능의 MCU 4종에 구현 및 적용하여 디지털 서명 생성 및 검증, 키쌍 생성을 각 1000회씩 수행하는 평가시험을 통해 실행 가능성과 속도 측면에서 가장 우수한 디지털 서명 알고리즘을 선택하였다. 셋째, 네트워크 패킷량 감소를 위해 경량 인증서를 새로 정의하였다. 마지막으로, IoT 헬스케어 기기의 원격 업데이트 상황을 모의하고 디지털 서명 알고리즘과 경량 인증서를 적용하여 중간자 공격을 방어할 수 있음을 보였다.

본 논문의 구성은 다음과 같다. 2장에서는 관련 연구로 중간자 공격과 중간자 공격 방어에 사용되는 디지털 서명 알고리즘을 분석하고, 3장에서는 디지털 서명 알고리즘 3종을 IoT 기기에 주로 사용되는 저성능의 MCU 4종에 적용 및 평가시험을 수행한다. 4장에서는 경량의 디지털 인증서를 정의한다. 5장에서는 IoT 헬스케어 기기 업데이트 상황을 모의하여 디지털 서명 알고리즘 및 경량 인증서로 중간자 공격을 방어할 수 있음을 입증한다. 6장에서는 결론과 본 연구의 의미와 향후 연구과제를 기술한다.


Ⅱ. 관련 연구

2.1 중간자 공격

중간자 공격은 시스템 간의 통신에 공격자가 개입하여 전송되는 데이터를 중계하거나 위조 및 변조하는 것을 말한다.

그림 1에서 보이듯, 중간자 공격의 가장 주요한 위험은 키 교환 알고리즘을 무력화 시키고 그 결과 암호화된 통신도 무력화 시킬 수 있다는 점이다. 스니핑 공격 하에서는 각 시스템의 공개키(Public key)만 도청 당하고 개인키(Private key)는 유출되지 않는다. 따라서 공개키와 개인키를 모두 알고 있어야 생성할 수 있는 공통키(Shared key)는 안전하기 때문에 공격자는 키 교환 후 암호화된 통신은 복호화 할 수 없다.

Fig. 1.

Key exchange under a MITM attack

그러나 중간자 공격은 각 시스템과 새로운 네트워크 통신을 연결하여 자신의 공개키를 전송하고 정상 시스템들로부터 수신한 공개키와 자신의 개인키로 공통키들을 생성한다. 그 결과 공격자는 각 시스템 별로 암호화된 통신을 복호화 하여 탈취하거나 조작한 후 다시 암호화하여 상대 시스템에 전송할 수 있다. 따라서 네트워크 보안에 키 교환을 통한 암호화 알고리즘을 적용하기 위해서는 중간자 공격을 방어하는 것이 반드시 필요하다.

2.2 디지털 서명

디지털 서명은 네트워크로 전송된 데이터의 송신자의 신원을 확인하기 위한 방법이다. 디지털 서명을 사용하면 각 시스템이 네트워크로 데이터를 전송하기 전 상대 시스템의 신원을 확인하여 인가되지 않은 중간자가 통신에 개입하는 것을 막을 수 있다.

디지털 서명에는 개인키와 공개키로 구성된 키 쌍들을 생성하고 개인키를 사용한 디지털 서명 생성과 공개키를 사용한 디지털 서명 유효성 검사를 수행할 수 있는 알고리즘이 포함된다. 개인키와 공개키를 생성하는 발급자는 각 키 쌍의 유일성을 보장해야 하며, 키 쌍을 발급받은 서명자는 공개키는 다른 사용자와 공유하되 개인키는 외부에 유출되지 않도록 한다. 서명자가 개인키로 메시지에서 디지털 서명을 생성하여 전송하면 디지털 서명을 수신한 시스템은 공개키로 해당 디지털 서명이 유효한지 검사한다. 검증에 사용한 공개키와 쌍을 이루는 개인키를 소유한 서명자는 유일하기 때문에 해당 디지털 서명이 유효하다면 이를 생성한 서명자의 신원을 신뢰할 수 있다.

보편적으로 사용되는 디지털 서명 알고리즘 중 하나는 RSA 암호화 알고리즘이다. RSA는 두 개의 큰 소수의 곱으로 이루어진 합성수는 소인수분해하기 어렵다는 것을 기반으로 하는 비대칭키 암호화 알고리즘 중 하나로 공개키 또는 개인키로 암호화하면 각각 개인키, 공개키로만 복호화 할 수 있다는 특징이 있다. 공개키로 암호화하는 경우 개인키를 가진 유일한 시스템 외에는 복호화 할 수 없으므로 데이터 전송 보안에 사용된다. 반면에 개인키로 암호화하는 경우 모든 시스템에서 복호화를 할 수 있으므로 전송 데이터 보안에는 사용할 수 없으나 개인키를 가진 유일한 시스템이 암호문을 생성했음을 명확히 할 수 있으므로 시스템의 신원 확인에 사용할 수 있다.

일반적으로 비대칭키 암호화 알고리즘은 대칭키 암호화 알고리즘에 비해 암호화 및 복호화에 많은 시스템 자원을 소모하기 때문에 스마트폰이나 PC 등 비교적 컴퓨팅 성능이 뛰어난 기기에서도 신원 인증을 위한 제한적인 용도로만 사용된다. 본 논문에서는 IoT 헬스케어 기기가 중간자 공격을 방어할 수 있도록 적은 시스템 자원으로도 실행할 수 있는 디지털 서명 알고리즘을 분석 및 구현하고 평가시험한다.


Ⅲ. 디지털 서명 알고리즘 평가시험

현대 암호학에서는 2030년 이후에도 용인할 수 있는 보안성을 확보하기 위해 128-bit 보안 수준 이상을 요구하고 있다[4]. 일반적으로 암호화 알고리즘의 보안 수준은 키의 길이에 비례하는데, RSA의 경우 128-bit 보안 수준을 확보하기 위해서는 개인키와 공개키의 길이를 3072bits 이상으로 설정해야 하며, 생성되는 디지털 서명도 키와 동일한 길이를 가진다[5]. 그러나 많은 IoT 기기는 여전히 수 KB ~ 수십 KB의 SRAM을 가지고 있기 때문에 RSA 구현 및 적용이 불가능하거나 비효율적이다. 또한 키의 길이가 길수록 연산에 많은 시간이 필요하며 무선 네트워크 환경에서의 데이터 전송에 따른 비용을 고려하여 키의 길이를 줄일 필요가 있다. 따라서 본 논문에서는 시스템 자원이 부족한 IoT 헬스케어 기기에도 적용할 수 있는 128-bit 보안 수준을 만족하는 디지털 서명 알고리즘들을 구현하고 평가시험한다.

3.1 ECDSA

ECDSA(Elliptic Curve Digital Signature Algorithm)는 이산 로그 문제의 난해함과 타원곡선의 특성을 기반으로 하는 디지털 서명 알고리즘이다[6]. ECDSA의 장점은 키의 길이가 매우 짧다는 것으로 128-bit 보안 수준을 갖추기 위해 필요한 키의 길이는 약 256bits다. 암호화 및 복호화가 가능한 비대칭키 암호화 알고리즘인 RSA는 디지털 서명으로부터 서명 생성에 사용한 메시지를 복원할 수 있으나 ECDSA는 개인키를 이용한 디지털 서명 생성과 공개키를 이용한 검증만 가능하다. 디지털 서명 생성에 사용하는 메시지 전체가 서명 생성 과정에 참여하는 것을 보장하기 위해 일반적으로 원본 메시지 대신 메시지를 해시(Hash)한 값을 디지털 서명 생성에 사용한다.

ECDSA의 보안 수준과 신뢰성은 사용하는 타원곡선에 따라 결정된다. 본 논문에서는 128-bit 보안 수준을 달성하기 위한 타원곡선을 선택하고 구현 및 평가시험을 수행한다. 128-bit 보안 수준에 부합하는 타원곡선은 secp256r1, secp256k1가 있으며, 본 논문에서도 두 타원곡선에 대한 평가시험을 수행한다.

secp256r1 타원곡선은 NIST에서 권장하는 타원곡선으로 P-256 또는 prime256v1이라고도 한다[7]. secp256r1 타원곡선 사용 시 ECDSA의 개인키 길이는 256bits, 디지털 서명의 길이는 512bits이다. 공개키는 원본 형태와 압축된 형태로 표현할 수 있는데, 압축 여부를 표현하기 위해 8bits의 추가 정보가 포함되어 원본 공개키는 520bits, 압축된 공개키는 264bits가 된다. 공개키를 압축하는 경우 키의 보관 및 네트워크를 통한 전송에는 유리하지만 원본 키 복원을 위해 추가 연산이 필요하다. 평가시험에는 IoT 헬스케어 기기의 공개키 송수신이 무선 네트워크 환경에서 이루어지는 것을 고려하여 공개키를 압축하여 사용하였다. 디지털 서명 생성에 필요한 메시지 해시 알고리즘은 IETF(Internet Engineering Task Force) 구현에 따라 SHA-256을 사용하였다[8].

secp256k1 타원곡선은 secp256r1 타원곡선에 비해 기대 보안 수준이 수 bits 정도 낮을 수 있지만 128-bit 보안 수준을 크게 벗어나지는 않는 것으로 알려져 있으며, 일부 시스템에서는 secp256r1 타원곡선에 비해 연산 수행 속도가 빠르다는 장점이 있다. 최근 비트코인에 사용되면서 사용례가 증가하고 있으며 개인키, 공개키, 디지털 서명의 길이는 secp256r1 타원곡선을 사용할 때와 동일하다. 평가시험에는 공개키를 압축하여 사용하였고, 비트코인의 구현을 따라 메시지 해시 알고리즘에 SHA-256을 사용했다.

3.2 EdDSA

EdDSA(Edwards-curve Digital Signature Algorithm)는 꼬인 에드워즈 곡선(TEdC, Twisted Edwards Curve)을 기반으로 하는 슈노르 서명 알고리즘(Schnorr signature algorithm)의 변형이다[9]. 꼬인 에드워즈 곡선은 타원곡선의 일부 계열인 에드워즈 곡선(EdC, Edwards Curve)을 일반화한 형태이다. EdDSA는 보안 수준을 희생하지 않으면서도 일부 시스템에서 ECDSA에 비해 빠른 것으로 알려져 있다. 본 논문에서는 EdDSA에 사용할 수 있는 에드워즈 곡선 중 128-bit 보안 수준에 부합하는 Curve25519를 적용하여 평가시험한다. Curve25519를 적용한 EdDSA는 Ed25519라고도 하며, 메시지 해시 등에 자체적으로 SHA-512를 사용하도록 정의되어 있다. Ed25519의 개인키와 공개키의 길이는 모두 256bits이며, 공개키는 항상 압축되어 있다. 서명의 길이는 512bits이다.

3.3 디지털 서명 알고리즘 평가시험 결과 및 효율 비교

표 1은 디지털 서명 알고리즘들을 구현하고 평가시험한 보드의 주요 시스템 자원을 정리한 표이다. 해당 보드들은 IoT 기기에 자주 사용되는 AVR, ARM, Tensilica 계열의 저성능 MCU를 탑재한 보드들이다. 전반적으로 성능이 높은 순서대로 보드들을 나열하면 Node MCU ESP8266 1.0, Arduino MKR 1010, Arduino Mega 2560 Rev3, Arduino UNO Rev3 순서이며 Mega 2560과 UNO는 8-bit MCU를 사용하고 있고 나머지 보드들은 32-bit MCU를 사용한다. 프로그래밍 및 컴파일, 프로그램 업로드는 Arduino IDE 1.8.15를 사용하였다.

Test platforms for digital signature algorithms

평가시험 항목은 각 보드에서 디지털 서명 알고리즘별 공개키와 개인키 생성, 디지털 서명 생성, 디지털 서명 검증의 실행 가능 여부와 수행 속도이다. 디지털 서명 생성에 사용하는 메시지의 길이는 128bytes로 한다.

각 알고리즘의 평가시험은 보드 별로 1000회씩 수행하여 항목별 경과 시간을 측정하여 평균값을 취하였다

표 2는 본 논문에서 평가시험한 디지털 서명 알고리즘의 주요 특성들을 보인다. 각 알고리즘은 동일한 128-bit 보안 수준에 부합하기 때문에 대부분의 특성이 유사하지만 공개키의 길이와 사용하는 해시 알고리즘에서 차이를 보인다.

Comparison of properties of digital signature algorithms

표 3은 평가시험 결과를 정리한 표이다. Ed25519는 8-bit MCU인 ATmega328P와 2KB SRAM을 탑재한 Arduino UNO Rev3 보드에서 SRAM 부족으로 실행에 실패하였다. 그 외의 경우에는 알고리즘과 보드에 관계없이 개인키와 공개키 생성, 디지털 서명 생성과 검증에 성공하였으나, 수행 속도에는 차이를 보였다.

Comparison of digital signature algorithm speed by board

그림 2는 각 디지털 서명 알고리즘이 디지털 서명을 생성하는데 걸린 시간(Elapsed time)을 MCU 보드 별로 평가시험한 결과를 보인다. MCU에 따라 지원하는 명령어 세트와 명령어 처리 시간이 다르기 때문에 MCU 보드 별로 효율적인 알고리즘이 존재했다. 전체적인 성능이 낮은 8-bit MCU 보드인 Arduino UNO Rev3, Arduino Mega 2560 Rev3에서는 ECDSA 계열이 우수한 성능을 보였으며, 비교적 성능이 높은 32 bit MCU 보드인 Arduino MKR 1010, Node MCU ESP8266 1.0에서는 Curve25519를 사용한 EdDSA가 우수한 성능을 보였다. ECDSA 계열 중에서는 secp256k1을 사용하는 것이 secp256r1을 사용하는 것보다 낮은 성능의 MCU 보드에서 디지털 서명 생성에 걸린 시간이 짧았다.

Fig. 2.

Elapsed time in digital signature generation by digital signature algorithm

그림 3은 각 디지털 서명 알고리즘의 디지털 서명을 검증하는데 걸린 시간(Elapsed time)을 측정한 결과를 보인다. ECDSA 계열의 경우 디지털 서명 검증에 걸린 시간이 생성에 걸린 시간에 비해 큰 차이가 없거나 더 짧았다. 그러나 EdDSA는 디지털 서명 검증에 걸린 시간이 생성에 걸린 시간보다 약 60% 정도 더 길었다. 그 결과 디지털 서명 생성 시 속도 효율은 MKR 1010 보드와 ESP8266 보드에서 EdDSA가 우수한 것에 비해 디지털 서명 검증 시 속도 효율은 ESP8266 보드에서만 EdDSA가 우수했다.

Fig. 3.

Elapsed time in digital signature validation by digital signature algorithm

그림 4는 각 디지털 서명 알고리즘이 공개키와 개인키를 생성하는데 걸린 시간(Elapsed time)을 측정한 결과를 보인다. 전반적으로 디지털 서명 생성 시간과 유사한 경향을 보이지만 모든 경우에서 키쌍 생성 시간이 디지털 서명 생성 시간보다 짧았다.

Fig. 4.

Elapsed time in key pair generation by digital signature algorithm

평가시험 결과 IoT 헬스케어 기기에 가장 적합한 디지털 서명 알고리즘은 secp256k1 타원곡선을 사용한 ECDSA였다. secp256r1도 secp256k1과 유사한 특성을 보였으나 secp256k1이 저성능 MCU에서 실행 속도가 더 빨랐다. MCU의 성능이 높을수록 EdDSA Curve25519가 실행 속도에서 장점을 보였으나 기기의 SRAM이 작은 경우 실행에 어려움이 있었으며 MCU의 성능이 높다면 ECDSA 실행에 걸리는 시간도 충분히 짧았다. 따라서 IoT 헬스케어 기기에서는 디지털 서명 알고리즘으로 ECDSA secp256k1을 선택하는 것이 실행 가능성과 실행 효율성 측면에서 유리하다.


Ⅳ. 경량 디지털 인증서

본 장에서는 3장에서 선택한 ECDSA-secp256k1 디지털 서명 알고리즘과 함께 사용할 경량의 디지털 인증서의 구조와 발급 방법, 유효성 검증 절차를 정의한다.

디지털 인증서는 공개키의 소유권을 증명하기 위한 전자 문서로 디지털 서명 알고리즘과 함께 신원 인증에 사용된다. 디지털 인증서는 일반적으로 인증서 소유자 정보, 소유자의 공개키, 디지털 서명 등이 포함된다. 인증서의 신뢰성을 확보하기 위해 서버, 기업, 정부 등 다양한 단체들 별로 인정한 기관들에서 발급한 디지털 인증서만 유효한 인증서로 취급하고 있으며, 이러한 디지털 인증서 발급 기관을 인증기관(CA, Certificate Authority)라고 한다.

기존의 디지털 인증서 표준으로는 국내 공인인증서나 HTTPS 등 TLS/SSL 프로토콜에 사용되는 X.509가 있다[10]. X.509는 다양한 디지털 서명 알고리즘에 대응할 수 있는 유연성과 기존에 사용 중인 표준이라는 보편성을 갖추고 있다. 그러나 인증서의 크기가 일정하지 않고 수 KB 이상의 크기를 가질 수 있기 때문에 자원이 부족한 IoT 헬스케어 기기에 적합하지 않다[11]. 따라서 본 논문에서는 IoT 헬스케어 기기에 적합하도록 ECDSA-secp256k1 디지털 서명 알고리즘을 위한 경량의 인증서 형식을 구성하고 간략한 인증서 유효성 검사 절차를 정의한다.

표 4는 본 논문에서 정의한 경량 디지털 인증서의 구조를 보인다. 경량 디지털 인증서는 인증서 발급자의 식별자(Issuer ID), 인증서 소유자의 식별자(Owner ID), 인증서 소유자의 공개키(Owner public key), 인증서 발급자가 발급자의 개인키로 인증서의 나머지 부분을 서명한 디지털 서명(Digital signature)으로 구성한다. 인증서의 각 요소들은 순서대로 위치하며 인증서의 크기는 항상 904bits, 113bytes이다.

Structure of light-weight digital certificate for ECDSA-secp256k1

본 논문에서 정의한 인증서 발급 및 분배 방식은 다음과 같다. 첫째, CA는 자신이 사용할 공개키와 개인키를 생성하고 자신에게 인증서를 발급한다. 이를 CA 인증서라고 하며 발급자 ID와 소유자 ID가 동일하다. CA 인증서에는 CA의 공개키와 CA의 개인키로 서명한 전자서명이 포함된다. 따라서 CA 인증서는 자체적으로 디지털 서명을 검증할 수 있다. 둘째, CA는 각 시스템들의 공개키, 개인키, 인증서를 생성한다. 이 인증서는 시스템 인증서라고 하며, 발급자 ID와 소유자 ID가 다르다. 시스템 인증서에는 각 시스템의 공개키와 CA의 개인키로 서명된 전자서명이 포함된다. 마지막으로 CA는 각 시스템들에 CA 인증서의 복사본, 시스템 인증서, 시스템의 개인키를 배포한다.

그림 5는 경량 인증서의 유효성 검증 과정을 보인다. 인증 과정은 다음과 같은 절차를 거친다.

Fig. 5.

Light-weight digital certificate validation process

첫째, 소유하고 있는 CA 인증서 중 인증하고자 하는 시스템 인증서를 발급한 CA의 인증서를 찾는다. 이는 시스템 인증서의 Issuer ID와 동일한 Owner ID를 가지는 CA 인증서를 찾는 것과 같다.

둘째, CA 인증서에 포함된 CA의 공개키(PubKCA)로 CA 인증서의 디지털 서명(SignCA)을 검증한다. 유효한 디지털 서명이라면 해당 CA 인증서를 신뢰할 수 있다.

셋째, CA 인증서의 공개키(PubKSys)로 시스템 인증서의 디지털 서명(SignSys)을 검증한다. 검증 결과가 유효하다면 해당 시스템 인증서는 신뢰할 수 있는 CA가 발급한 인증서임을 의미한다. 따라서 해당 시스템 인증서에 포함된 정보를 신뢰할 수 있다.


Ⅴ. 구 현

본 장에서는 3장의 평가시험 결과 실행성과 속도 효율성이 가장 우수했던 ECDSA-secp256k1 디지털 서명 알고리즘, 4장에서 정의한 경량 인증서를 적용하여 IoT 헬스케어 기기 원격 업데이트 상황에 보안을 적용하는 절차를 제안하고 구현한다.

그림 6은 ECDSA-secp256k1 디지털 서명 알고리즘과 ECDH(Elliptic-curve Diffie-Hellman) 키 교환 알고리즘을 적용하여 업데이트 서버가 IoT 헬스케어 기기에 새로운 소프트웨어를 설치하는 상황을 보인다.

Fig. 6.

Interation diagram of secure remote update on IoT healthcare device

디피-헬만(Diffie-Hellman) 키 교환 알고리즘은 이산 로그의 난해함을 기반으로 안정성을 확보하고 있다. 두 시스템에서 공개키와 개인키 쌍을 각자 생성한 후 서로의 공개키를 교환하고, 자신의 개인키와 상대방으로부터 전달받은 공개키를 통해 공통키(Shared Key)를 생성하는 방식이다. ECDH는 디피-헬만 키 교환 알고리즘에 타원곡선을 적용하여 동일한 보안 수준을 달성하는데 필요한 키의 길이를 줄인 것으로 ECDSA와 유사한 방식으로 작동한다. 본 논문에서는 ECDH에 ECDSA-secp256k1와 동일한 타원곡선인 secp256k1를 적용하였다.

ECDSA-secp256k1와 ECDH-secp256k1를 적용한 안전한 원격 업데이트를 위한 절차는 다음과 같다.

첫째, 선행 조건 단계이다. 신뢰할 수 있는 CA는 PrvKCA(CA의 개인키), CertCA(CA 인증서), PrvKIoT(IoT 헬스케어 기기의 개인키), CertIoT(IoT 헬스케어 기기의 시스템 인증서), PrvKSrv(업데이트 서버의 개인키), CertSrv(업데이트 서버의 시스템 인증서)를 생성한다. CA는 인가된 IoT 헬스케어 기기에 CertCA, PrvKIoT, PrvKIoT를 전달하고 업데이트 서버에 CertCA, PrvKSrv, CertSrv를 전달한다. PrvKCA는 외부에 전달하지 않고 CA만 소유한다.

둘째, 인증서 교환 단계이다. IoT 헬스케어 기기는 업데이트 서버에 CertCA를 전달하고, 업데이트 서버는 IoT 헬스케어 기기에 CertSrv를 전달한다.

셋째, 인증서 검증 단계이다. IoT 헬스케어 기기와 업데이트 서버는 각자 전달받은 CertSrvCertCA를 미리 가지고 있던 CertCA로 검증한다. 검증 결과 유효한 인증서라면 CertCACertSrv가 CA에 의해 발급된 인증서임을 확인할 수 있으며, 각 인증서에 포함된 인증서 소유자의 개인키를 신뢰할 수 있다.

넷째, 키 생성 단계이다. ECDH 키 교환 알고리즘에 따라 IoT 헬스케어 기기는 개인키 PrvKA와 공개키 PubKA를 생성하고 업데이트 서버는 개인키 PrvKB와 공개키 PubKB를 생성한다.

다섯째, 전자 서명 생성 단계이다. IoT 헬스케어 기기는 ECDSA 알고리즘에 따라 PubKA를 메시지로 사용하여 PrvKIoT로 전자 서명 SignA을 생성한다. 업데이트 서버는 동일한 방식으로 PubKB와 PrvKSrv를 사용해 전자 서명 SignB를 생성한다.

여섯째, 키 교환 단계이다. IoT 헬스케어 기기는 업데이트 서버에 PubKASignA를 전송하고, 업데이트 서버는 IoT 헬스케어 기기에 PubKBSignB를 전송한다.

일곱째, 키 검증 단계이다. IoT 헬스케어 기기와 업데이트 서버는 각각 전달받은 공개키와 전자서명을 검증한다. 검증에는 첫 번째 단계에서 전달받은 인증서에 포함된 공개키를 활용한다. 검증 결과가 유효하다면 전달받은 공개키가 인증된 시스템에서 생성되었음을 신뢰할 수 있다.

여덟째, 공통키 생성 단계이다. ECDH 키 교환 알고리즘에 따라 IoT 헬스케어 기기는 PubKB와 PrvKA로 공통키를 생성하고 업데이트 서버는 PubKA와 PrvKB로 공통키를 생성한다. 키 교환이 정상적으로 이루어졌다면 각 시스템이 생성한 공통키는 SharedKAB로 동일하다.

아홉째, 암호화 단계이다. 위 절차에 따라 두 시스템은 모두 공통키 SharedKAB를 소유하게 되었다. 따라서 IoT 기기에 적합한 ChaCha20 등의 대칭키 암호화 알고리즘의 키로 SharedKAB 사용해 이후 이루어지는 통신을 암호화 할 수 있다. 스니핑 기법을 사용해 공격자가 본 통신을 도청하더라도, 공개키 SharedKABSharedKAB를 생성하는데 필요한 PrvKA, PrvKB는 네트워크로 전송되지 않기 때문에 암호문 해독에 필요한 키를 확보할 수 없다. 그 결과, IoT 헬스케어 기기 원격 업데이트 상황에서 전송되는 소프트웨어나 기타 정보들이 유출되지 않는다.

본 절차를 따라 안전한 원격 업데이트를 수행한 경우 중간자 공격 기법을 활용한 공격자는 다음과 같은 이유로 업데이트 상황에 개입할 수 없다.

첫째, 인증서 교환 단계에서 IoT 헬스케어 기기나 업데이트 서버에 전송할 인증서를 확보할 수 없다. CA는 인가된 시스템에만 인증서를 발급하기 때문에 공격자는 CA로부터 인증서와 개인키를 발급받을 수 없다. 공격자가 임의의 인증서를 발급하거나 인증서 조작을 시도하는 경우, 공격자는 CA의 개인키를 알 수 없기 때문에 인증서에 포함될 유효한 전자 서명을 생성할 수 없다.

둘째, 인증서 교환 단계에서 공격자가 네트워크 보안의 허점을 이용해 네트워크로 전송되는 인증서를 탈취하였다고 하더라도, 각 시스템의 개인키는 네트워크로 전송되지 않기 때문에 유출되지 않는다. 따라서 전자 서명 생성 단계에서 개인키로 서명을 할 수 없고, 그 결과 IoT 헬스케어 기기와 업데이트 서버는 키 교환 단계 및 키 검증 단계에서 제3의 공격자가 개입하였음을 알 수 있다.

본 절차는 다음과 같은 환경에서 구현하여 평가시험하였다. ARM 계열의 Arudino MKR1010 보드와 적외선 체온계 센서를 사용해 모의 IoT 헬스케어 기기를 구성하고 WiFi 무선 네트워크를 통해 PC에서 구현한 업데이트 서버로부터 원격 업데이트를 받는 상황을 구현하였다.

표 5는 평가시험을 위해 CA가 발급한 각 시스템 별 개인키 예를 보인다. 표 6, 7, 8은 각각 CA, IoT 헬스케어 기기, 업데이트 서버를 위한 경량 인증서의 예이다. 각 개인키와 경량 인증서는 시스템별로 미리 가지고 있도록 구현하였다.

Example of private key for each system

Example of light-weight digital certificate for CA

Example of light-weight digital certificate for IoT healthcare device

Example of light-weight digital certificate for update server

표 9, 10은 ECDH 키 교환 알고리즘을 위해 IoT 헬스케어 기기와 업데이트 서버가 각각 생성한 개인키와 공개키, 생성한 개인키를 CA로부터 발급받은 개인키로 서명한 디지털 서명의 예를 보인다.

Example of key pair generated by IoT healthcare device

Example of key pair generated by update server

표 11은 IoT 헬스케어 기기와 업데이트 서버가 ECDH 알고리즘에 따라 서로 다른 공개키와 개인키로부터 각각 생성한 공통키의 예를 보인다. IoT 헬스케어 기기는 PubKB와 PrvKA로 공통키를 생성하고 업데이트 서버는 PubKA와 PrvKB로 공통키를 생성하였으나 결과는 모두 같다.

Example of shared key generated by each system

표 5의 PrvKCA, PrvKIoT, PrvKSrv표 9, 10의 PrvKA, PrvKB를 제외한 정보들은 모두 네트워크로 전송되었다. 그러나 네트워크로 전송된 정보들이 모두 유출된다고 가정하더라도, 공격자는 개인키를 알 수 없어서 유효한 디지털 서명을 생성하거나 공통키를 계산할 수 없기 때문에 통신에 개입하거나 이후 진행될 암호화된 통신으로부터 원본 데이터를 추출할 수 없다.

따라서 본 구현을 통해 본 논문에서 제안한 절차에 따라 IoT 헬스케어 기기와 업데이트 서버가 중간자 공격을 방어할 수 있으며, 그 결과로 암호화된 통신에 사용할 공통키를 안전하게 보유하였음을 알 수 있었다.


Ⅵ. 결론 및 향후 과제

본 논문에서는 중간자 공격으로부터 IoT 헬스케어 기기를 보호하기 위해 적합한 디지털 서명 알고리즘을 평가시험하고 구현하였다. 평가시험은 AVR, ARM, Tensilica 계열의 MCU를 탑재한 4종의 보드에서 ECDSA 및 EdDSA 전자 서명 알고리즘 3종을 구현하여 알고리즘 수행 가능 여부와 속도를 측정하는 방식으로 진행하였다. 그 결과 동일한 보안 수준에서 ECDSA-secp256k1 디지털 서명 알고리즘이 실행성과 속도 효율성이 가장 우수했다. 또한 본 논문에서는 IoT 헬스케어 기기 인증과 식별을 위해 ECDSA-secp256k1와 함께 사용할 경량의 디지털 인증서를 구성하고 유효성 검사 방법을 정의하였다. ECDSA-secp256k1와 경량 디지털 인증서를 IoT 헬스케어 기기 원격 업데이트 상황에 적용한 결과 중간자 공격을 위해 연결을 시도하는 공격자를 IoT 헬스케어 기기와 업데이트 서버가 식별할 수 있었다. 또한 ECDH 키 교환 알고리즘과 함께 사용하면 스니핑 공격을 방어하는데도 활용할 수 있음을 보였다.

본 논문은 비교적 성능이 부족한 IoT 기기에서 실제 구현을 통해 실행성과 효율성이 우수한 디지털 서명 알고리즘을 선택하고, 디지털 서명 알고리즘과 함께 사용할 수 있는 경량의 디지털 인증서를 제안함으로써 강력한 보안이 필요한 IoT 헬스케어 기기를 중간자 공격으로부터 방어할 수 있는 실례를 제시했다는 점에서 그 의의가 있다.

향후 연구 과제에서는 디지털 서명 알고리즘 최적화 기법을 연구하여 IoT 헬스케어 기기의 성능에 따라 효율적인 구현 방법을 제시하도록 한다.

Acknowledgments

이 논문은 2021년도 산업통산자원부의 재원으로 한국산업기술평가관리원(KEIT)의 지원을 받아 수행된 연구임

References

  • Global IoT Microcontroller(MCU) Market Forecast 2018-2026, https://inkwoodresearch.com/reports/internet-of-things-microcontroller-market, . [accessed: Aug. 10, 2021]
  • Hyeongseok Jeon and Sungkee Lee, "Analysis of Remote Update Vulnerabilities of IoT Healthcare Devices", The Journal of Korean Institute of Information Technology, Vol. 19, No. 1, pp.  87-97, Jan. 2021. [https://doi.org/10.14801/jkiit.2021.19.1.87]
  • Yong-Hee Jeon, "A Study on the Security Modeling of Internet of Things(IoT)", The Journal of Korean Institute of Information Technology, Vol. 15, No. 12, pp. 17-27, Dec. 2017. [https://doi.org/10.14801/jkiit.2017.15.12.17]
  • Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid, "Recommendation for key management part 1: General (revision 5)", Federal Information Processing Standards(FIPS) Special Publications(SP) 800-57, May 2020.
  • Elaine Barker, Lily Chen, Allen Roginsky, Apostol Vassilev, Richard Davis, and Scott Simon, "Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography", Technical Report NIST Special Publication(SP) 800-56B, Mar. 2019. [https://doi.org/10.6028/NIST.SP.800-56Br2]
  • Don Johnson, Alfred Menezes, and Scott Vanstone,  "The Elliptic Curve Digital Signature Algorithm (ECDSA)",  International Journal of Information Security, Vol. 1, No. 1, pp. 36–63, Aug. 2001. [https://doi.org/10.1007/s102070100002]
  • Daniel R. L. Brown, "SEC 2: Recommended Elliptic Curve Domain Parameters", Certicom Research, Jan. 2010.
  • S. Turner, D. Brown, K. Yiu, and R. Housley, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, Mar. 2009. [https://doi.org/10.17487/rfc5480]
  • S. Josefsson, and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, Jan. 2017. [https://doi.org/10.17487/RFC8032]
  • M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, Sep. 2005. [https://doi.org/10.17487/rfc4158]
  • Jae-Yoon Lim, Seunghwan Yun, Sun-Hee Lim, Okyeon Y, and Sangjin Lee, "Effective Certification and Access Control Model Study Applying SPKI/SDSI between Distribution Domains", Korean Institute of Information Technology, Vol. 8, No. 10, pp. 87-97, Oct. 2010.
저자소개
전 형 석 (Hyeongseok Jeon)

2014년 2월 : 경북대학교 심화컴퓨터공학(공학사)

2016년 3월 : 경북대학교 대학원 컴퓨터학부(공학석사)

2016년 3월 ~ 현재 : 경북대학교 대학원 컴퓨터학부 박사과정

관심분야 : 의료정보, IoT, 의료정보보안

이 성 기 (Sungkee Lee)

1979년 2월 : 서울대학교 전기공학(공학사)

1981년 2월 : 서울대학교 전기공학(공학석사)

1990년 8월 : University of Utah 컴퓨터과학(공학박사)

1990년 ~ 현재 : 경북대학교 컴퓨터학부 교수

관심분야 : 의료정보, 국제의료표준, 의료정보보안

Fig. 1.

Fig. 1.
Key exchange under a MITM attack

Fig. 2.

Fig. 2.
Elapsed time in digital signature generation by digital signature algorithm

Fig. 3.

Fig. 3.
Elapsed time in digital signature validation by digital signature algorithm

Fig. 4.

Fig. 4.
Elapsed time in key pair generation by digital signature algorithm

Fig. 5.

Fig. 5.
Light-weight digital certificate validation process

Fig. 6.

Fig. 6.
Interation diagram of secure remote update on IoT healthcare device

Table 1.

Test platforms for digital signature algorithms

Board MCU Clock speed
(MHz)
Flash memory
(KB)
SRAM
(KB)
Arduino UNO Rev3 AVR ATmega 328P 16 32 2
Arduino mega 2560 Rev3 AVR ATmega 2560 16 256 8
Arduino MKR 1010 SAMD21 cortex®- M0+ 32bit low power ARM MCU 48 256 32
Node MCU ESP8266 1.0 Tensilica 32-bit RISC CPU xtensa LX106 80 4096 64

Table 2.

Comparison of properties of digital signature algorithms

Algorithm ECDSA
secp256r1
ECDSA
secp256k1
EdDSA
curve25519
Property
* with 8 bits compression indicator
Security level(bits) 128 128 128
Public key size(bits) 520* 520* -
Compressed public key size (bits) 264* 264* 256
Private key size(bits) 256 256 256
Signature size(bits) 512 512 512
Hash algorithm SHA-256
(IETF Implementation)
SHA-256
(Bitcoin Implementation)
SHA-512
(Fixed)

Table 3.

Comparison of digital signature algorithm speed by board

Digital signature
algorithm
Board Elapsed time on (ms)
Key pair
generation
Signature
generation
Signature
validation
ECDSA
secp256r1
UNO 4426.64 5118.79 5445.76
Mega 2560 4446.24 5144.77 5462.98
MKR 1010 1249.71 1732.24 494.52
ESP8266 606.00 715.04 606.29
ECDSA
secp256k1
UNO 3820.19 4678.74 4601.57
Mega 2560 3799.77 4647.8 4610.09
MKR 1010 1330.28 1846.93 578.66
ESP8266 595.81 722.81 613.94
Ed25519 UNO Failed Failed Failed
Mega 2560 6192.07 6253.09 10118.99
MKR 1010 1029.88 1034.40 1679.92
ESP8266 302.13 303.61 487.26

Table 4.

Structure of light-weight digital certificate for ECDSA-secp256k1

Element Format Length (bits) Description
Issuer ID EUI-64 64 ID of the certificate issuer
Owner ID EUI-64 64 ID of the certificate owner
Owner public key Octet string 264 Compressed public key of the certificate owner
Digital signature Octet string 512 Digital signature generated from the rest of the certificate with issuer’s private key

Table 5.

Example of private key for each system

Owner Description
CA
(PrvKCA)
96 FE B2 BE A1 23 7F CF A0 2C EC 7B CF 9F 6B 50 14 76 2D 14 EF EC 97 F5 75 9F FD 88 39 BA 9E E2
IoT healthcare device
(PrvKIoT)
3D EB FD 5B 8F 92 DA BF EF BF 1F B4 7B 3F 1D 03 F5 A6 19 AD 97 86 C0 5F DC 95 CC B3 7D FE 76 01
Update server
(PrvKsrv)
57 75 AE F3 BE EE 7E FD 3D A5 5E 94 DF 68 35 C8 35 3F 36 A2 E5 2B EF 94 BB 92 E3 EE C7 50 F4 C9

Table 6.

Example of light-weight digital certificate for CA

Element Data (Octet string)
Issuer ID 84 83 37 00 00 00 00 01
Owner ID 84 83 37 00 00 00 00 01
Owner public key (compressed) 03 7E E2 BB 4F 97 38 31 2E 12 3D 74 07 2C D7 21 DA BE C3 E1 EC 08 97 F7 A7 66 B5 B6 DD F7 D6 BB E8
Digital signature C9 62 5B 64 4E 78 EB 82 26 72 6B 61 04 25 17 C1 3D 9D B7 CD 19 F7 37 5D 93 DA 67 60 97 51 1F FF FF 61 FE 81 D5 AB 0A 8B ED 0B A9 B2 5C 91 BF FC 3E EE 0E 7E 26 13 87 EC 34 E4 E4 D7 AD 0C D4 14

Table 7.

Example of light-weight digital certificate for IoT healthcare device

Element Data (Octet string)
Issuer ID 84 83 37 00 00 00 00 01
Owner ID 84 83 37 01 00 00 00 01
Owner public key (compressed) 03 32 87 F7 2F 35 65 0B 14 36
F9 2A 1A B1 E9 0E F3 07 DB 2A 02 1C 77 47 44 D1 91 44 1D AB 6A 4D 43
Digital signature DD 59 2B EE D6 0D B5 9E C1 81 94 D5 62 0C CD FE 51 9F 74 EA 24 42 E7 15 7D 54 6B 50 66 43 AD 27 26 8F C5 0D D8 68 37 CC C5 96 8C 7E F7 C3 83 FC 7C 06 11 98 AC E5 B3 10 CF 15 21 67 78 04 4D 45

Table 8.

Example of light-weight digital certificate for update server

Element Data (Octet string)
Issuer ID 84 83 37 00 00 00 00 01
Owner ID 84 83 37 06 00 00 00 01
Owner public key (compressed) 02 3B 2F DF F8 79 45 C6 07 EE BD 0E D5 E1 23 65 F1 F7 41 9B 50 6B DD 02 B5 4B 7F 13 7B A8 08 64 A3
Digital signature B5 C1 2A F3 F2 ED 4A 58 CE 6C 2D 53 C6 EB D1 00 DC E2 58 CF 29 A2 72 D5 78 EC B0 9D FA 66 8E 9C 43 C6 FF 60 D8 52 A0 CF 75 39 F1 BB E8 73 C7 8F E9 A3 00 DE C2 39 11 95 F8 29 D2 F8 A1 56 4B 69

Table 9.

Example of key pair generated by IoT healthcare device

Entry Data (Octet string)
Private key
(PrvKA)
E7 A5 BA 15 0C 7E ED A0 A9 A2 BE 3F 6B D1 42 BF 0D 83 72 DB 2A 56 A3 1E 48 E9 BD 36 8D 7B 67 07
Public key (compressed)
(PubKA)
02 CF D1 A6 9F 2D FB D8 E2 10 BC F3 CA AF 50 96 C6 73 E2 44 E6 B2 BB 70 E4 7B 7D D2 33 F4 24 DB 45
Digital signature
(SignA)
43 16 9A 0A E3 26 02 BB 41 2A 6D E3 B4 55 37 A8 95 DD AD 08 3D 56 B9 84 5F B2 76 1B 5A F7 CA DF 1F 35 79 36 36 A2 23 9F 69 0F 47 4A D7 06 E2 76 E5 94 6A 41 E2 52 E6 8E 21 62 E6 1B 0A 04 16 05

Table 10.

Example of key pair generated by update server

Entry Data (Octet string)
Private key
(PrvKB)
CE 83 FF 6B 7F 69 EE 4D 18 DD F4 D3 A4 E1 FB 80 CD 6B 73 FD B7 95 61 9A DA 8B B0 4B 0B 4F 9B CA
Public key (compressed)
(PubKB)
02 A8 51 48 B9 B9 A8 8C EF F1 B6 E0 25 A1 04 19 39 95 26 04 4A DA 13 8A 7B 52 03 5D 56 C9 70 D1 0D
Digital signature(SignB) AA AA 56 51 BC 12 E3 72 02 41 D9 5F B2 7F FC 94 ED 42 74 42 49 D6 70 28 18 74 75 6A 94 2B 11 64 19 0A 8A BC 37 F5 65 6D 8A 78 F1 08 3B 24 6B FC EC 25 0F 78 88 C4 5D 79 F7 9F 2A E9 E4 FB 7E 89

Table 11.

Example of shared key generated by each system

Generator Data (Octet string)
IoT healthcare device CF 62 E3 4D 19 07 A5 2E BD 63 13 F2 7D 8A 87 BE 4B A0 0C C0 CA 54 E7 5D A5 28 62 13 46 11 CF 46
Update server CF 62 E3 4D 19 07 A5 2E BD 63 13 F2 7D 8A 87 BE 4B A0 0C C0 CA 54 E7 5D A5 28 62 13 46 11 CF 46