본문 바로가기

논문 분석

IoT 환경에서의 네트워크 보안 프로토콜 성능 분석

 

논문 선정 이유

1학년의 뉴스 스터디에서도 IoT 관련 보안 내용을 보았고 IoT 기기를 사용하면서 IoT보안에 관심이 생겼다.

 

 

서론

-국내 IoT 시장은 2015년에서 2019년까지 연 평균 23.7%로 가장 빠르게 성장한 데 반해 미흡한 보안으로 많은 보안 사고가 발생

공격자의 관점에서 IoT 시장 규모의 증가는 공격할 수 있는 접점의 증가를 나타냄

-> 기기 설계부터 IoT 환경에 맞는 보안을 고려해야 함.

 

- 대다수의 IoT 통신 프로토콜은 IoT 환경에 적합 한 통신을 위해 경량화, 유연성, 확장성 등의 특징을 지니고 있지만 제한된 메모리와 성능으로 인해 보안 기능이 적용되어 있지 않거나 보안에 대한 고려가 부족

 

- 안전한 보안 통신 환경을 구축하기 위해서는 IoT 기기의 제한된 특성에 맞는 경량화된 암호화 프로토콜이 필요

 

- IoT 통신 프로토콜과 검증된 암호화 통신 및 인증을 제공하는 TLS의 접목이 필요하며 TLS 버전 1.2보다 암호화 및 성능 문제를 해결한 TLS 버전 1.3의 사용을 고려해야 함.

 

 

 

IoT 사이버 공격 위협

IoT 기기는 DDos 공격의 봇넷처럼 하나의 공격 수단으로 활용될 수도 있고 IoT 기기 자체가 직접적인 공격 대상이 될 수도 있음.

 

1.IoT 사이버 공격 동향

실생활과 밀접한 서비스로 사생활 침해가 크며 네트워크를 통해 공격이 이루어진다는 공통점이 있음.

 

2.네트워크 보안 위협

2020 Unit 42 IoT 위협 보고서에 따르면 IoT 기기 트래픽의 98%는 암호화되지 않아 공격자가 암호화되지 않은 네트워크 트래픽을 통해 개인 또는 기밀 정보를 수집하여 해당 데이터를 악용할 수 있으며 주요 IoT 위협은 IoT 기기의 취약점을 이용하여 네트워크의 다른 시스템을 공격함.

-> IoT 기기의 망 분리뿐만 아니라 데이터 암호화, 사용자 인증 등의 보안도 함께 적용되어야 함.

 

3.IoT 보안과 기존 보안과의 차이점

IoT는 PC나 모바일의 고전력, 고성능 환경에서 의 보안과 달리 저전력, 저성능의 자원으로 보안 기능을 구현해야 함.

 

 

 

TLS 보안 위협

-네트워크 보안을 위해서는 TLS 통신이필요하지만 MITM 공격 또는 잘못된 구현 및 운영으로 Table 2와 같은 위협이 발생할 수 있음.

-IoT환경에서 주로 사용되는 TLS 버전1.2에서도 POODLE, DROWN 등 다양한 위협이 존재

 

1. FREAK Attack (Factoring Attack onRSA-EXPORT keys)

MITM공격을 통해 클라이언트가 RSA-EXPORT key를 요청하는 것으로 변조시킴.

Summary of attacks on TLS

2. POODLE Attack (Padding Oracle On Downgraded Legacy Encryption)

-TLS 버전 1.2 이하 버전에 영향을 주는 공격으로 MITM 공격을 통해 TLS의 최신 버전이 아닌 SSLv3 프로토콜을 사용하도록 유도함.

-클라이언트와 서버가 SSLv3을 통한 통신을 시작하 면 공격자는 Padding Oracle 공격을 통해 암호화 된 통신 메시지를 복호화하여 열람할 수 있음.

 

 

TLS 버전 1.3은 버전1.2의 프로토콜 취약점을 상당 부분 해소하였기에 버전1.3의 사용이 권고됨

-> 하지만 IoT 환경은 약 17%를 제외하고 TLS 버전 1.3을 지원하지 않고 있음.

=> IoT 환경에서도 TLS 버전 1.3의 적용 필요

버전 1.3과 버전 1.2의 주요 차이점

 

 

 

TLS 버전별 특징

1.Cipher Suite

-Static RSA와 Diffie-Hellman을 제거해 모든 공개키 기반 key exchange 메커니즘은 forward secrecy를 제공

-RC4, CBC, 3DES 같은 legacy 알고리즘의 지원을 중단하여 버전 1.3의 모든 대칭키 암호화 알고리즘은 AEAD 알고리즘으로 보안을 향상

 

2.Handshake

-TLS 버전 1.2의 Handshake는 Change Cipher Spec을 포함해 2-RTT(Round Trip Time)

-1.3에서는 extension을 통해 Change Cipher Spec 같은 메시지 교환을 줄여 1-RTT로 단축

 

Message flow for a full TLS Handshakefor new session

 

-서버는 ClientHello 메시지의 extension정보를 바탕으로 암호화 알고리즘 및 파라미터를 선택할수 있기에 ServerHello 메시지 이후의 모든 Handshake 메시지를 암호화 할 수 있음

 

 

 

 

성능 시험 및 분석

1. TLS 1.2와 TLS 1.3의 성능 비교 분석

Handshake의 Round Trip Time을 기준으로 2-RTT인 TLS 버전 1.2와 1-RTT인 TLS 버전 1.3의 Handshake, 0-RTT 인 TLS 버전 1.3의 early data를 통한 resumption의 경우의 Handshake 처리 속도를 분석

-서버는 클라이언트의 Certificate 를 요구하지 않고 Alert나 HelloRetryRequest 메시지 없이 새로운 세션과 early data에 대한 full Handshake만을 가정

 

-> IoT 환경에서 TLS 버전 1.3은 버전 1.2에 비해 Handshake 연결 속도가 약 39.94% 향상되었으며 early data를 사용할 경우 약 116.20% 향상된 것을 확인, TLS 버전 1.3을 적용할 경우 연결 속도뿐만 아니라 속도의 안전성도 향상됨

=> Handshake 연결 속도의 향상은 보안 채널 연결을 위한 상호 인증 및 암호키 교환 시간의 단축을 의미

시간이 단축될수록 사용자에게 보안 기능의 제공으로 인한 서비스 지연을 줄여 보안에 대한 불편함을 줄일 수 있음

Time performance of TLS 1.2 and TLS 1.3

 

 

 

2. Cipher Suite 성능 분석

IoT의 제한된 자원으로 가장 적합한 알고리즘을 선택할 수 있도록 TLS 버전 1.3에서만 지원하는 5개의 암호화 알고리즘 조합을 대상으로 성능 분석

 

performance of cipher suites in Raspberry pi 4

-암호화 속도는 TLS_AES_128_CCM_8_SHA256알고리즘이 0.035ms로 가장 빠르고TLS_AES_256_GCM_SHA256 알고리즘이 가장 느렸음.

-복호화 속도는 TLS_CHACHA20_POLY1305_SHA256과 TLS_AES_128_GCM_SHA256이빨랐다.

-알고리즘 간의 전체 CPU와 메모리 사용량의 차이가 미미

 

결론

-TLS 버전 1.3은 TLS 버전 1.2에 비해 보안과 속도 향상이 이루어졌다는 장점을 갖고 있음.

-TLS 버전 1.3의 장점으로 대다수의 웹 사이트는 TLS 버전 1.3을 지원하는 데에 반해 대다수의 IoT 기기는 TLS 버전 1.3을 지원하지 않음.

-TLS 버전 1.3 은 TLS 버전 1.2의 프로토콜 취약점을 대다수 해결 하였기에 IoT 보안이 중요해진 만큼 IoT 기기 역시 TLS 버전 1.3의 사용이 필요.

-또한 IoT는 PC 나 모바일 환경과 달리 제한된 자원으로 보안 통신을 구축해야 하므로 임베디드 시스템에 맞게 경량화된 보안 프로토콜을 사용하는 것이 적합.

- IoT 환경에서 TLS 버전 1.3을 사용할 경우 IoT 기기 사용자의 서비스 지연 시간을 단축할 수 있으며 다수의 IoT 기기를 처리해야 하는 경우 TLS 버전 1.3의 사용으로 처리량을 증가시킬 수 있음

 

 

느낀 점 

논문을 읽으면서 IoT 기술 개발자들이 왜 보안을 등한시 하는지 알 것 같기도 했다. 개발자들의 입장에서는 그저 성능이 좋아야 잘 개발한 것이니 성능을 저하시킬 수 있는 보안 기술은 신경 쓰지 않는 것 같기도 한데 소 잃고 외양간 고치지 말고... 

보안도 함께 기술을 발전시키길 바란다.

 

 

https://www-dbpia-co-kr.libproxy.swu.ac.kr/journal/articleDetail?nodeId=NODE11149721