“현대 IoT 생태계에 심각한 보안 결함 있다··· 난수 생성 불량이 근간”

현대 통신 프로토콜의 안전성은 공격자가 추측할 수 없는 비밀 토큰을 생성하는 알고리즘에 크게 의존한다. 이러한 알고리즘이 인증, 암호화, 액세스 제어 및 현대 보안의 여러 측면에 사용된다. 모두 암호학적으로 안전한 난수 생성(공격자가 예측할 수 없는 방식으로 선택된 숫자나 기호의 시퀀스)를 필요로 한다.

난수 생성기(RNG, Random Number Generator)로 알려진 이러한 번호를 선택하는 프로세스가 많은 보안 시스템과 기능의 토대가 된다. 현대의 운영체제와 컴퓨터는 RNG가 안전하게 작동할 수 있게 보장하고 있다. 그러나 단순한 운영체제를 실행하는 IoT 장치는 높은 랜덤성 소스를 찾는 데 문제를 보이곤 했다.

최근 SoC 벤더들은 OS에서 안전하게 사용할 수 있는 난수를 생성하도록 설계된 주변기기 컨트롤러를 자사 제품에 통합하여 이 문제를 해결하려고 노력했다. 그러나 보안업체 비숍폭스의 연구팀은 IoT 개발자들이 하드웨어 RNG 사용하는 방식을 분석한 결과, 시스템의 보안을 해치는 중대한 구현상의 문제를 발견했다. 그들은 최근 데프 콘(DEF CON) 보안 컨퍼런스에서 자신들의 조사 결과를 보고했다.

연구진은 “현재 IoT의 기술 상태는 '잘못하고 있다'고밖에 표현할 수 없다”라고 표현했다. 

하드웨어 RNG vs 소프트웨어 RNG
소프트웨어 기반 RNG는 일반적으로 결정론적 소프트웨어 알고리즘을 사용한다. 대개 네트워크 정보, 무선 인터페이스, 다양한 타이밍 값 등 서로 다른 소스의 랜덤 값을 결합하는 엔트로피 풀에서 시드되기 때문에 의사 난수 생성기(PRNG ; pseudo-random number generators)로도 알려져 있다. 

범용 PRNG라는 것도 있으며, 이는 비보안 목적으로 사용된다. 또 암호학적으로 안전한 PRNG(CSPRNG)는 합리적이고 계산적으로 실현 가능한 시간 내에 시드값을 추측하거나 출력을 예측하는 공격에 대한 보안성 보장을 제공하도록 고안되었다.

CSPRNG는 암호의 암호화(Cryptographic Ciphers) 및 해싱 기능을 사용하여 키 생성과 같은 중요한 작업에 사용되는 출력을 생성한다. 또한 알려진 공격을 방지하기 위한 테스트도 수행한다. 이 모든 작업은 컴퓨팅 리소스와 메모리를 소모하는데, 이 두 가지 모두 IoT 기기에서는 매우 부족하기 때문에 SoC 벤더는 하드웨어 RNG 기능을 추가했다.

하드웨어 RNG는 소프트웨어 알고리즘의 경우처럼 예측할 수 없는 방식으로 물리적 프로세스에서 난수를 생성하기 때문에 진정한 RNG(TRNG)라고도 한다. TRNG의 출력은 직접 사용해도 안전해야 하지만, 비숍 폭스 연구진이 밝혀낸 바와 같이, TRNG와의 인터페이스는 까다로울 수 있으며, 실수는 그 위에 구축된 보안 시스템에 엄청난 결과를 초래할 수 있다.

하드웨어 RNG 오류에 대해 확인하지 않음 
SoC 벤더는 개발자가 자사의 C 코드에서 서로 다른 기능을 호출하여 하드웨어 추상화 계층(HAL) API를 통해 하드웨어 RNG와 상호 작용할 수 있도록 한다. 이러한 RNG 기능의 이름은 벤더마다 다를 수 있지만 출력은 난수(32비트 정수)에 대한 포인터이며, 중요한 것은 그것이 잠재적인 오류를 나타내는 반환 값이라는 점이다.

비숍폭스 연구진은 보고서에서 다음과 같이 설명했다.
 

“RNG 주변기기에 대한 HAL 기능은 여러 가지 이유로 실패할 수 있지만 단연코 가장 흔한(그리고 악용 가능한) 것은 장치에 엔트로피가 부족했다는 점이다. 하드웨어 RNG 주변기기는 (아날로그 센서나 EMF 판독과 같은) 다양한 수단을 통해 엔트로피를 우주에서 끌어내지만 무한 공급에서는 엔트로피가 없다. 초당 아주 많은 랜덤 비트만 생산할 수 있다. RNG HAL 기능에 난수가 없을 때 호출하려고 하면, 실패하여 오류 코드가 반환될 것이다. 따라서 기기가 너무 많은 난수를 너무 빨리 얻으려고 하면 호출이 실패하기 시작할 것이다.”

이 문제는 큰 키를 생성하는 동안 자주 발생할 수 있다. 예를 들어, 2048비트 비밀 키를 생성하는 동안 기기는 RNG 홀 기능을 루프에서 반복적으로 호출하고 하드웨어는 한계로 인해 따라잡지 못하고 출력 오류가 발생하는 경우가 많다. 

문제는 깃허브에 존재하는 코드와 FreeRTOS와 같은 인기 임베디드 OS의 RNG 처리 코드에서도 개발자들이 하드웨어 RNG 오류를 확인하지 않는 것으로 보인다는 점이다. 비숍 폭스 연구진은 “IoT 산업이 작동하는 방식이 대개 그렇다. 기본적으로 모든 SDK 및 IoT OS에서 이러한 행동을 찾아볼 수 있다”라고 말했다.

하드웨어에 따라 HAL RNG 기능이 실패할 때, 출력은 부분 엔트로피, 숫자 0 또는 초기화되지 않은 메모리일 수 있기 때문에 큰 문제다. 이러한 출력 중 암호용으로 안전한 것은 아무것도 없다. 

2019년 키팩터 연구진이 RSA 키에 기반하여 7,500만 개의 디지털 인증서를 분석한 결과 172개마다 하나 꼴로 비밀 키를 복구할 수 있는 공격에 취약한 것으로 나타났다. 난수 생성 불량이 원인이었으며, 취약한 인증서는 대부분 IoT와 라우터, 스위치, 방화벽 등 임베디드 네트워킹 장치에서 발견됐다. RSA 공용 키를 생성하는 데 사용되는 소수가 충분히 랜덤 하지 않으면 2개의 개별 키가 한 인자를 공유할 가능성이 높다. 그러면 보안이 위험해지기 매우 쉽다. 

IoT가 하드웨어 RNG를 처리하는 방법에 대한 연구 결과에 대해 비숍폭스 연구진은 “... IoT 장치에서 RSA 키가 취약한 사례가 광범위하게 발생하는 것은 예상된 결과 그대로였다. 이것은 이론상 문제일 뿐 아니라 실제로도 악용 가능한 대형 문제인 것 같다”라고 말했다.

잘못된 강제 구현 
그러나 연구진은 IoT 소프트웨어 개발자들의 잘못된 구현을 탓하는 것은 성급하다고 경고한다. 이러한 오류를 적절하게 처리하더라도 기기의 기능에 영향을 미칠 수 있는 또 다른 단점이 있기 때문이다. 다음과 같은 설명이다.

“보안 통신을 위한 암호화 키를 생성하는 도중에 있는 네트워킹 스택이라면 오류를 어떻게 ‘처리’해야 하는가? 실제로 2가지 옵션만이 있다. 즉, 호출이 완료될 때까지 전체 프로세스를 중단하는 것이 하나이고, 프로세스에서 CPU를 100% 사용하고 다른 모든 프로세스를 막아서 호출을 완료할 때까지 무기한 HAL 기능에 대한 스핀 루프가 다른 하나의 옵션이다. 둘 다 받아들일 수 있는 해결책이 아니다. 이것이 개발자들이 오류 조건을 무시하는 이유다. 대안은 형편없으며 RNG 하드웨어 주변의 생태계는 아무런 도움이 되지 않았다.”

그 외에도 RNG의 작동 방법과 오류 처리 방법이나 오류 방지 방법에 대해 적절히 문서화하는 장치가 거의 없으며, 예상 작동 속도, 안전한 작동 온도 범위 또는 무작위성의 통계 증거에 대한 정보가 누락된다. 문서화가 존재하더라도, 그것을 올바르게 만드는 것은 쉬운 일이 아니다.

하드웨어 RNG 출력만으로는 신뢰할 수 없다
비숍폭스 연구진은 하드웨어 RNG만을 IoT의 엔트로피 소스로 의존하려고 함에 따르는 다른 많은 문제점을 발견했다. 예를 들어, 진정한 CSPRNG가 없는 경우 하드웨어 RNG를 지원하는 많은 SDK 및 IoT 운영 체제가 이를 사용하여 libc rand()와 같은 안전하지 않은 PRNG를 시드한 다음 출력을 보안 목적으로 사용하지 않아야 할 경우에도 그 출력을 사용한다.

연구진은 “libc rand()와 같은 PRNG의 경우 생산되는 숫자들이 RNG의 내부 상태에 대한 정보를 드러내기 때문에 매우 불안정하다. 빠르고 구현하기 쉽기 때문에 보안과 관련이 없는 컨텍스트에는 괜찮다. 하지만 암호화 키와 같은 용도로 사용하면 모든 숫자가 예측 가능하기 때문에 기기의 보안에서 치명적인 붕괴를 초래할 수 있다”라고 말했다.

LPC54628 마이크로컨트롤러에 대한 한 테스트에서, 연구진은 하드웨어 RNG에 의해 생성된 난수들의 품질이 좋지 않다는 것을 알아냈고 그들의 코드에 뭔가 문제가 있다고 의심했다. 제조업체 문서를 자세히 살펴본 결과, 베스트 프랙티스에 권장 사항을 발견했다. 

예를 들어 128비트 난수를 얻으려면 개발자가 4개의 연속된 RNG 32비트 출력을 연결하지 않아야 한다고 제조업체는 말했다. 대신 32비트 숫자 하나를 사용하고 다음 32개 숫자를 삭제하고 나서 그 다음 32개 숫자를 사용한 뒤 또 다른 32개 숫자를 삭제하는 등의 작업을 수행해야 한다. 이 API 행동은 매우 이상하고 반 직관적이어서 취약한 구현이 거의 확실해진다. 

또한 연구자들이 테스트한 일부 하드웨어 RNG 구현은 통계 분석 테스트에서 실패하거나 생산된 바이트의 상대적 분포에서 명확한 패턴을 보였다. 따라서 개발자들이 적절한 오류 처리, API 요구 사항, 열악한 문서화의 각종 장애물을 극복하더라도 여전히 하드웨어 RNG의 출력에만 의존해서는 안 된다.

답은 하드웨어 RNG의 출력이 엔트로피 풀의 소스 중 하나에 불과한 IoT에 대해서 적절한 CSPRNG를 갖는 것이다. 리눅스, 윈도우, 맥OS, 안드로이드, iOS, BSD와 같은 모든 주요 운영 체제는 오류 방지 CSPRNG 하위 시스템을 갖추고 있으며 애플리케이션 개발자는 하드웨어와 직접 인터페이스 하거나 코드가 정확하지 않은 지 혹은 난수가 안전하지 않은 지 걱정할 필요 없이 쉽게 사용할 수 있다.

연구진은 “취약성이 단일 기기의 SDK나 특정 SoC 구현에 있지 않다. IoT에는 CSPRNG 하위 시스템이 필요하다. 문서를 변경하고 사용자를 탓하는 것만으로는 이 문제를 해결할 수 없다. 이러한 CSPRNG 하위 시스템을 위한 가장 우아한 장소는 점점 더 대중화되고 있는 IoT 운영 체제 중 하나에 있다. 새로운 기기를 처음부터 설계하는 경우 운영 체제에서 CSPRNG를 구현할 것을 권고한다”라고 말했다. ciokr@idg.co.kr