I. 서론
펌웨어는 임베디드 디바이스에 내장되어 서비스 제공을 담당하는 특수 목적의 소프트웨어이다. 이 중 암호 모듈은 펌웨어 내부에서 암호 알고리즘 및 각종 암호화 기능을 구현한 보안 모듈로, 데이터의 암호화/복호화, 해시 함수, 디지털 서명, 인증, 키 분배 등의 암호학적 기능을 제공한다. 이러한 암호 모듈의 암호 라이브러리는 데이터 기밀성과 무결성을 보장하기 위한 핵심 소프트웨어 코드이며, 민감한 데이터의 보호를 위해 취약점이 없어야 한다. 만약 암호 라이브러리에 취약점이 존재하여 공격에 악용될 경우 데이터 유출이나 위/변조와 같은 심각한 보안 사고로 이어질 수 있다.
부채널 공격은 암호 라이브러리의 암호학적 안전성에 핵심인 비밀키를 탈취할 수 있는 대표적인 보안위협요소이다. 구체적으로 부채널 공격이란 암호 라이브러리가 마이크로프로세서에서 동작할 때 발생하는 부가 정보(소요 시간, 소비 전력, 전자기파 등)를 분석하여 비밀키나 내부 데이터를 유추하는 공격 기법이다[1]. 부채널 공격에 대한 위협이 대두됨에 따라 개발 단계에서부터 이에 대응하기 위한 노력이 필요하다. 상수 시간 구현, 블라인딩, 마스킹, 더미 연산 등의 기법은 부채널 공격에 대한 대표적인 대응책이다[2]. 국제 표준인 FIPS 140-3 등에서도 높은 보안 요구사항을 만족하기 위해 부채널 대응책 적용과 안전성 검증 과정을 필수 요소로 규정하고 있다[3].
기존에 널리 활용되는 암호 라이브러리 부채널 안전성 평가 방법은 실제 부채널 테스트 보드(ChipWhisperer[4], SAKURA-X[5] 등)나 개발된 시제품에 암호라이브러리를 이식한 후 물리 환경에서 공격을 수행하는 것이다. 그러나 이러한 포팅 과정은 대부분 수작업으로 이루어져 번거롭고 오류가 발생하기 쉽다. 더군다나 실제 측정에서 부채널 정보누출이 관측되더라도, 그것이 대응책 구현상의 실수 때문인지 또는 특정 마이크로프로세서 하드웨어의 고유 특성 때문인지 분석하기 어렵다. 이러한 한계를 극복하고자, 최근에는 개발 초기 구현 단계에서 소스코드 또는 바이너리 상에 존재하는 부채널 취약점을 탐지하려는 연구들이 제안되고 있다[6][7].
임베디드 CPU 에뮬레이터를 활용하면 구현 단계에서 암호 라이브러리에 내재된 부채널 취약점을 효과적으로 탐지할 수 있다. 오픈소스 유니콘 엔진(Unicorn Engine)을 기반으로 한 Emusca, ELMO2 등은 에뮬레이터를 활용한 대표적인 부채널 취약점 분석 도구들이다[8][9]. 에뮬레이션 기반 분석은 실제 하드웨어가 없거나 제약된 환경에서 데이터-부채널 신호 모델링을 통해 예상 소비 전력이나 연산 시간 차이를 미리 파악할 수 있으며, 그 결과 소스코드에 존재하는 잠재적인 부채널 취약점을 조기에 제거할 수 있다. 즉, 에뮬레이션 기반 분석을 활용하면, 개발자는 암호 라이브러리에 적용한 부채널 대응책을 소스코드 단계에서 종합적으로 평가할 수 있다는 장점이 있다. 추가로 실제 하드웨어 환경보다 자동화된 대량 테스트 구성이 용이하다는 이점도 있다.
그러나 기존의 에뮬레이션 기반 부채널 취약점 분석 연구에는 다음과 같은 미흡한 점들이 존재한다.
Challenge I : 최신 에뮬레이터 활용 부족 - 본 논문에서 조사한 바에 따르면, 대표적인 오픈소스 에뮬레이터인 유니콘 엔진의 공식 사이트에 게재된 기존 부채널 분석 도구들은 구형 유니콘 엔진(ver.1)을 기반으로 개발되었음을 확인하였다. 몇몇 쇼케이스 도구들은 제공된 예시 이외에 다른 대상에의 수정·확장이 거의 불가능하거나, 최신 환경에서 정상적으로 빌드가 되지 않는 한계가 있음을 확인하였다.
Challenge II : 암호 함수에 대한 에뮬레이션 기반 검증 방법론 부족 - 부채널 취약점을 분석하기 위한 기본적인 가정은 암호 함수의 입출력 및 난수를 검증자가 의도대로 제어할 수 있어야 한다. 암호함수의 입력이 하나의 값으로 고정되거나 검증자가 난수를 알 수 없다면, 부채널 취약점을 분석하는데 어려움이 있을 수 있다. 하드웨어 형상이 있는 부채널 테스트보드 환경에서는 암호 함수가 내장된 바이너리 펌웨어를 테스트보드에 퓨징하고, 메인컴퓨터와 테스트보드 사이에 통신 모듈을 구성하여 암호 함수 입출력과 난수를 제어한다. 그러나 에뮬레이션 환경에서는 물리적인 통신모듈이라는 개념이 없으므로 에뮬레이터 상에서 암호 함수 입력에 해당하는 변수의 주소를 추적하고, 해당 메모리의 데이터를 특정 시점에 읽거나 검증자가 원하는 값으로 쓸 수 있어야 한다. 하지만 기존에 에뮬레이션 기반 부채널 취약점 분석 연구에는 바이너리 펌웨어의 암호 함수 입력변수를 식별하는 방법 및 에뮬레이터의 메모리 데이터를 읽고 쓰는 방안에 대한 가이드가 부족하다. 또한 암호 함수 내부에서 생성하는 난수는 외부에서 제어가 어려워 이에 대한 해결 방안이 필요하다.
Challenge III : 상용 솔루션 위주의 정보 제한 - Riscure 사의 Inspector SCA, Secure-IC 사의 Virtualyzr 등은 상업용 에뮬레이션 기반 부채널 취약점 검증 솔루션이다. 이러한 상용 도구들은 고객사 환경에 맞춤 개발되고 지속적인 업데이트와 유지보수를 지원하지만, 외부에 공개된 기술 정보는 매우 제한적이다. 따라서 에뮬레이션 기반 분석을 통해 부채널 안전성을 검증하는 절차와, 과정에서 얻은 데이터를 정제·해석하는 노하우의 공유가 미흡한 실정이다.
이러한 문제들을 해결하기 위해, 본 논문에서는 에뮬레이션 기반 부채널 취약점 검증 프레임워크를 제안한다. 구체적으로, 오픈소스 임베디드 CPU 에뮬레이터 중 부채널 분석에 널리 활용되는 최신의 유니콘 엔진(ver.2.0.1)을 기반으로 암호 라이브러리의 부채널 취약점을 검증하는 프레임워크를 설계하였다.
Challenge I에 대응하고자 최신 유니콘 엔진을 기반으로 한 도구를 개발하였으며, 암호 라이브러리가 유니콘 엔진 상에서 동작할 때 가상의 CPU와 메모리에 모사되는 모든 내부 상태 값을 로그로 기록하고 이 정보를 바탕으로 부채널 취약성을 평가하도록 구현하였다.
Challenge II를 극복하기 위해서는 바이너리 펌웨어 내부의 암호 함수를 에뮬레이션 기반 부채널 취약점 검증에 활용할 수 있는 리호스팅(rehosting) 기교를 제안한다. 리호스팅이란 용어는 임베디드 시스템의 소프트웨어를 원래의 물리적 하드웨어가 아닌 가상 환경에서 구동할 수 있도록 이식하는 방법을 총칭하는 용어이다. 본 논문에서는 에뮬레이션 기반 부채널 취약점 검증에 특화된 리호스팅 기교를 제시한다. 구체적으로 AES 암호 알고리즘의 세 가지 구현물을 예시로 펌웨어 소스코드를 최소로 수정하여 에뮬레이터에 이식하는 방안을 소개한다. 이 과정에서 메모리 값을 조작하는 트릭을 활용하여 가상 I/O 장치와 난수 생성기를 모사함으로써 실제 환경에 가까운 조건에서 암호 라이브러리를 동작시켰다. 추가로, 에뮬레이터 상에서 암호 알고리즘이 동작하는 구간을 식별하는 기법을 제시하여 원하는 함수 실행 시점을 정확히 파악할 수 있도록 하였다.
Challenge III에 대해서는 공개된 오픈소스 에뮬레이터를 기반으로 분석을 위한 코어 엔진을 구성하는 방안에 대해 설명하고, 프레임워크의 분석 방법론을 단계별로 설명하여 에뮬레이션 기반 부채널 취약점 검증 기술에 대한 노하우를 공유한다. AES 암호 알고리즘 구현물 3종을 대상으로 에뮬레이션 기반 부채널 취약점 검증 기술을 적용하고, 수집 데이터를 정제하는 과정을 시각화하여 부채널 취약 여부를 직관적으로 해석할 수 있도록 하였다. 더 나아가 추가적인 시각화 없이도 수치 해석만으로 부채널 취약성 존재 여부를 자동 판단하는 방안을 제안하였다. 이를 통해 에뮬레이션 기반 부채널 분석 과정에서의 노하우를 체계화하고, 연구 결과를 공개하여 소스코드에 대한 부채널 취약점 검증 분야의 지식 공유를 촉진한다.
본 논문의 구성은 다음과 같다. 2장 배경지식에서는 제안하는 프레임워크에서 고려하는 부채널 공격 및 관련 대응책에 대해 설명한다. AES 암호 알고리즘 및 구현물 3종을 소개하고, 에뮬레이션 엔진에 대해 설명한다. 추가로 에뮬레이션 도구를 부채널 분석 분야에 적용한 사례에 대해 소개한다. 3장에서는 논문의 주제인 에뮬레이션 기반 부채널 취약점 검증 프레임워크를 제안한다. 4장에서는 제안하는 프레임워크를 AES 구현물 3종 소스코드에 적용하고, 부채널 공격에 대한 안전성을 검증한다. 마지막으로 5장에서는 연구결과를 정리하고 향후 연구방향을 제시하며 끝맺는다.
II. 배경지식
2.1 부채널 공격 및 대응책
본 절에서는 에뮬레이션 기반 부채널 취약점 검증 프레임워크에서 고려하는 부채널 공격 유형과 대표적인 대응책을 설명한다. 제안 프레임워크에서 가정하는 부채널 공격은 비침투 공격에 한정한다. 대표적인 비침투 부채널 공격으로 타이밍 공격/단순 전력 분석과 차분 전력 분석이 있다. 단, 캐시메모리를 악용하는 타이밍 공격은 에뮬레이터 모사 성능의 한계로 본 연구 범위에서 제외하였다[10].
2.1.1 타이밍 공격/단순 전력 분석 공격 및 대응책
타이밍 공격(Timing attack, TA)은 암호 함수의 실행에 소요되는 미세한 시간 차이를 분석하여 비밀 정보를 탈취하는 기법이다[11]. 암호 함수의 입력값이나 비밀키에 따라 실행 시간이 달라지는 경우, 공격자는 하위 프리미티브 연산의 실행 구조나 특정 분기 조건을 유추함으로써 비밀 정보를 얻어낼 수 있다. 단순 전력 분석(Simple power analysis, SPA) 공격은 타이밍 공격과 유사하지만 전력 소모의 패턴 자체를 관찰하여 비밀키를 추출하는 기법이다[12]. 특정 명령어 시퀀스나 데이터 패턴(0 또는 -1 등) 또는 메모리 접근 주소 등이 소비 전력 패턴에 반영되는 특성을 이용하며, 타이밍 정보뿐 아니라 다양한 실행 정보를 조합해 공격이 이루어진다.
타이밍 공격을 방어하려면 암호 연산이 상수 시간에 완료되도록 구현해야 한다. 즉, 비밀키나 민감한 데이터에 따른 조건문이나 분기문을 제거하고, 데이터에 의존하여 클럭 사이클이 변동되는 명령어의 사용을 지양해야 한다. 또한 단순 전력 분석 공격을 막기 위해서는 부채널 신호(시간, 전력 등)와 내부 상태 값의 상관성이 최소화되도록 구현해야 한다. 예를들어, 비밀키 비트나 데이터 값에 종속적인 연산 구조를 제거하고, 특정 데이터나 주소 값에 대해 부채널 신호가 두드러지게 나타나지 않도록 연산을 설계해야 한다. 이러한 방법들을 통해 입력이나 비밀키에 무관하게 항상 동일한 실행 경로와 시간을 갖도록 구현하면 TA/SPA 공격에 대한 내성을 확보할 수 있다.
2.1.2 차분 전력분석 공격 및 대응책
차분 전력 분석(Differential power analysis, DPA) 공격은 암호 연산 과정에서 마이크로프로세서로부터 누출되는 다수의 전력 신호를 수집하고, 통계적 기법(상관계수 분석 등)을 통해 비밀키를 복원하는 강력한 공격 기법이다[13]. 차분 전력 분석 공격은 단일 신호로는 드러나지 않는 미약한 패턴을 다량의 신호들을 수집하여 통계 분석을 수행, 숨겨진 통계적 특징을 파악함으로써 비밀 정보를 추출한다.
마스킹 기법은 차분 전력 분석 공격에 대해 수학적 안전성을 보장하는 대표적인 대응책이다[14]. 암호 연산에 사용되는 민감한 데이터를 연산 과정에서 무작위 값과 결합(마스킹)하여 실제 비밀 정보와 부채널 신호의 상관관계를 없애는 방식이다.
마스킹 기법이 정확히 구현되었다면 부채널 신호에 비밀 정보가 누설되지 않게 되며, t-test 통계 검정으로 이에 대한 확인이 가능하다. 널리 사용되는 t-test 통계 검정 기반 평가 방법으로 TVLA(Test Vector Leakage Assessment)가 있으며, 본 논문에서는 차분 전력 분석 공격에 대한 대응책의 안전성 여부를 판단하기 위한 기준으로 TVLA 통계 검정 결과를 활용하였다[15].
2.2 AES 암호 알고리즘 및 예제 코드
본 절에서는 제안하는 프레임워크의 평가 예제로 사용하는 AES 암호 알고리즘 및 세 가지 AES 구현물에 대해 설명한다.
2.2.1 AES 암호 알고리즘 및 관련 부채널 공격
AES(Advanced Encryption Standard)는 미국 NIST에서 제정한 블록 대칭키 암호 알고리즘으로 128비트 블록을 처리하며 128/192/256비트 비밀키를 지원한다[16]. AES는 순차적인 라운드 구조로 이루어진 대치-치환 네트워크(Substitution-Permutation Network) 기반 알고리즘으로, 다음 4개의 프리미티브 함수로 구성된다.
• SubBytes: 비선형 치환 (SBox 대치 연산)
• ShiftRows: 행 단위의 순환이동을 통한 확산
• MixColumns: 열 단위 혼합을 통한 확산
• AddRoundKey: 라운드 키와 상태블록의 XOR
AES에 적용되는 주요 부채널 공격 유형과 공격 대상 함수, 대응책의 예시는 Table 1.에 정리되어 있다.
Table 1. Side-Channel Attacks against AES:Target Functions and Countermeasures

TA/SPA 공격의 주요 대상은 연산 시간이 입력이나 키에 따라 달라질 수 있는 함수이며, 대표적으로 MixColumns의 곱셈 연산이 TA/SPA 공격 표적이 된다. DPA 공격의 주요 대상은 SubBytes 연산 등 프리미티브 함수 전후의 비트값이 극적으로 바뀌는 부분으로, 이러한 공격에 대비하기 위해 마스킹 기법 등이 적용된다.
2.2.2 AES 구현물 3종
Table 2.는 본 논문에서 분석 예제로 사용하는 AES 구현물 세 가지(Tiny-AES, Naive-AES, Masked-AES)의 부채널 취약성을 요약한 것이다.
Table 2. Vulnerabilities of Three AES Implementations to Side-Channel Attacks

여기서는 각 구현물이 앞서 설명한 TA/SPA 및 DPA 공격에 대해 안전한지(secure) 또는 취약한지(insecure)를 구분한다.
Tiny-AES는 임베디드 시스템에 특화된 경량 C언어 AES 구현체로, 작은 바이너리 크기와 낮은 메모리 사용량, 높은 이식성을 갖는다[17]. 부채널 대응 측면에서 상수 시간으로 동작하도록 설계되어 TA/SPA 공격에 안전하다. 특히 TA/SPA 공격의 주요 대상인 MixColumns 단계에서, 갈루아 필드상의 2배, 3배 곱셈 연산을 룩업 테이블(xtime 테이블)로 구현하여 실행 시간과 연산 시퀀스가 입력값에 무관하게 일정하게 유지된다. 하지만 마스킹 등의 DPA 대응책은 적용되지 않아 DPA 공격에는 취약하다.
Naive-AES는 Tiny-AES 코드를 기반으로 MixColumns 함수를 테이블 참조 대신 조건문으로 구현하였다. Fig. 1.은 Naive-AES의 MixColumns에서 갈루아 필드 상의 2배(MUL2), 3배(MUL3) 곱셈을 수행하는 소스코드 일부를 보여준다.

Fig. 1. Multiplications of Naive-AES MixColumns
MixColumns 연산을 테이블 참조 대신 if-분기로 구현하면, 입력 바이트의 최상위 비트 값에 따라 실행 경로가 달라지게 된다. 이는 상수 시간 및 동일한 연산 시퀀스를 보장하지 못하므로 TA/SPA 공격에 취약해진다. 즉, 내부 상태 값에 따라 XOR 연산에 분기(0 또는 0x1b)가 생겨 소요 시간 및 소비전력의 형태가 달라질 수 있다. Naive-AES 역시 마스킹 기법이 없으므로 DPA 공격에도 취약하다.
Masked-AES는 암호화 연산에 마스킹 부채널 대응 기술(Pre-computation masked S-box)을 적용한 구현물이다[18]. 이 구현물은 상수시간 구현을 바탕으로 암호화 라운드에 마스킹이 적용되어 TA/SPA 및 DPA 공격에 저항성을 갖는다.
2.3 가상화 소프트웨어, QEMU 및 유니콘 엔진
가상화 소프트웨어는 가상화를 모니터링하는 호스트와 가상화 대상이 되는 게스트로 구성된다. 가상화 핵심 기술로는 CPU 가상화(명령어 실행 제어), 메모리 가상화(가상 메모리를 실제 메모리에 매핑), 주변 장치 에뮬레이션(I/O 가상장치를 통한 입출력)등이 있다. 이 기술들로 게스트는 마치 자체 하드웨어에서 동작하는 것처럼 구동되지만, 실제로는 호스트가 자원의 할당과 접근을 통제하며 실행 과정을 제어할 수 있다.
QEMU는 대표적인 오픈소스 가상화/에뮬레이션 소프트웨어로, 다양한 아키텍처를 지원하는 머신 에뮬레이터 및 가상화 플랫폼이다[19]. 특히 임베디드 기기의 대표 CPU인 ARM 아키텍처를 지원하여 임베디드 기기의 펌웨어 디버깅 및 취약점 분석 용도로 사용되고 있다.
QEMU에서 파생된 유니콘 엔진은 경량 멀티 아키텍처 CPU 에뮬레이터로 임베디드 시스템의 보안과 관련 분야에 특화되어 활용되고 있다. 임베디드 CPU의 명령어 실행과 메모리 접근 모사를 특화하여 불필요한 주변 장치 및 OS 코드를 제거함으로써 보안 취약점 분석에 편의성을 제공한다. 파이썬 언어로 바인딩을 제공하며 Unicorn API를 통해 명령어 실행, 메모리 접근, 예외 발생 등의이벤트 시 사용자 정의 함수를 삽입(hooking)할 수 있어, 에뮬레이션 중인 코드의 동작을 실시간 모니터링 및 제어할 수 있다.
유니콘 엔진은 2015년 BlackHat USA에서 최초로 소개되고 베타 테스트 과정을 거쳐 2017년 버전 1.0을 출시하였다. 이후 오픈 커뮤니티의 다양한 피드백을 반영하여 2022년 신규 유니콘 엔진 버전 2.0을 출시하였다.
임베디드 CPU 에뮬레이션 기반 검증기술 관점에서 신규 유니콘 엔진을 도입하므로 인해 향상된 사양은 다음과 같다.
• 중국어 기반 API 사용 설명서의 영문화
• 기반이 되는 QEMU 가상화 플랫폼을 버전 2.3에서 버전 5로 업그레이드 및 유니콘 엔진 코드 전면 재작성
• 파이썬 바인딩 함수 품질 개선으로 활용 편의성 증대
• 구형 API와 하위 호환을 유지하면서, 새로운 제어용 API 추가(메모리 매핑 기능 향상)
• 기존의 멀티스레드 지원에서 멀티코어를 추가로 지원하여 에뮬레이션 속도 향상
• 장시간 에뮬레이션 시 발생하는 메모리 누수 문제 해결 및 코드 최적화, 캐시 관리 개선, 성능·메모리 사용량 최적
2.3.1 재현 충실도
재현 충실도(fidelity)란 에뮬레이터가 실제 디바이스의 동작을 얼마나 정확히 모사하는지를 나타내는 척도이다. 가상화 분야에서 재현 충실도는 일반적으로 회로 레벨, 마이크로아키텍처 레벨, 명령어 레벨, API 레벨, 응용 프로그램 레벨의 다섯 단계로 구분된다. 예를 들어 에뮬레이터가 회로 레벨의 충실도를 가지면 개별 트랜지스터, 저항, 커패시터 등의 전기적 특성까지 정확히 모사함을 의미한다. 마이크로아키텍처 레벨에서는 프로세서 내부 파이프라인, 캐시, 분기 예측기 등의 동작을 모사할 수 있고, 명령어 레벨 충실도는 프로세서의 명령어 집합(opcode, operand 등)을 에뮬레이션하여 소프트웨어의 명령어 실행 흐름을 실제와 동일하게 재현함을 의미한다. API 레벨 충실도는 운영체제 API나 시스템 콜의 동작을, 응용 프로그램 레벨 충실도는 특정 애플리케이션의 동작을 얼마나 사실적으로 모사하는지를 뜻한다.
유니콘 엔진의 재현 충실도 수준은 명령어 레벨이다. 즉, 개별 명령어의 실행 전후로 CPU 레지스터와 메모리 등 내부 상태 변수들의 변화가 실제 하드웨어와 동일하게 재현됨을 보장한다. 최근에는 유니콘 엔진을 확장하여 마이크로아키텍처 레벨 충실도의 일부를 지원하려는 연구도 보고되고 있다[20].
본 논문에서 개발한 부채널 취약점 검증 도구는 명령어 레벨 충실도를 기반으로 동작하며, 따라서 캐시/파이프라인 등의 미세 효과는 모델링되지 않지만, 명령어 수행에 따른 CPU 상태, 레지스터 및 메모리 값의 변화를 정확히 추적할 수 있다.
2.3.2 유니콘 엔진 기반 부채널 분석 연구 동향
부채널 분석 분야에서 유니콘 엔진을 활용하려는 시도는 유니콘 엔진 홈페이지의 쇼케이스 항목에 정리되어 있다[8]. 그러나 관련 연구를 조사하는 과정에서 다음과 같은 미진한 사항을 확인하였다. 유니콘 엔진의 에뮬레이션 정보를 기반으로 시뮬레이션 전력 파형 생성 및 부채널 취약점을 분석하는 도구에 대한 제안들은 있으나, 이를 논문으로 정리하여 발표한 사례는 매우 드문 것으로 조사 되었다. 또한 시뮬레이션 전력 파형 생성 도구는 구형 유니콘 엔진 기반으로 구현되었음을 확인하였다.
기존에 발표된 논문으로는 멜트다운과 스펙터에 대한 취약점을 유니콘 엔진으로 찾으려는 시도가 있었으며[20], 코딩 과정에서 발생할 수 있는 분기 예측과 관련된 부채널 취약점을 식별하는 도구가 제안되었다[21]. 그러나 멜트다운 및 스펙터에 대한 취약점 분석 논문은 임베디드 CPU 환경에 적용하기에 적합하지 않다. 코딩 시 발생하는 부채널 취약점 분석 논문 역시 멜트다운 및 스펙터 취약점 탐지 논문에서 사용한 도구를 개량하여 분기 예측을 배제한 상수시간 구현에 초점이 맞춰져 있다.
사전조사 과정에서 저자들은 시뮬레이션 전력 파형 생성 도구의 최신화을 포함하여, 소스코드의 바이너리 컴파일부터 시뮬레이션 전력 파형 생성, 부채널 취약점 검증 전반을 아우르는 프레임워크가 필요함을 깨달았다. 이러한 목적을 달성하고자 에뮬레이션 기반 부채널 취약점 검증 프레임워크를 제안하며, 코어 에뮬레이터로 신규 유니콘 엔진을 채택하였다. 추가로 유니콘 엔진으로 코어 에뮬레이터를 구성한 이유는 다음과 같다.
• 임베디드 CPU 명령어 실행에 특화되어 분석 대상 모사 충실도가 높음
• 코드 조각(snippet) 단위로 실행이 가능하여 리호스팅 용이
• Python API 제공으로 분석 도구의 수정 및 기능 확장 용이
• 실시간 모니터링 및 트리거 후킹으로 레지스터/메모리 데이터 조작 용이
• 경량화된 에뮬레이터로 리소스 효율성이 높아 대량 테스트 가능
• 오픈소스로 제공되어 향후 엔진 성능 개선 시 검증 결과 신뢰도 향상 기대
제안하는 프레임워크의 코어 에뮬레이터에 대한 추가 설명과 구현 세부 정보는 공개된 프로젝트 저장소(GitHub) 및 관련 문헌에서 확인할 수 있다[22][23].
2.3.3 부채널 분석 관련 유니콘 엔진 핵심 함수
유니콘 엔진의 내장 함수는 C언어로 구현되어 있으며, 파이썬 등의 고수준 언어에 대해 바인딩 함수(래퍼 함수)를 제공한다. 본 소절에서는 에뮬레이션 기반 부채널 취약점 검증을 위해 핵심적으로 사용되는 레지스터 및 메모리와 관련된 파이썬 바인딩 함수 4종에 대해 정리한다.
먼저 레지스터 읽기 함수이다. 파이썬 함수로 reg_read이며, 함수의 입력 매개변수 중 reg_id에 레지스터의 ID를 입력하여 원하는 레지스터의 값을 읽어올 수 있다. 레지스터 ID의 정의는 유니콘 엔진의 arm_cont.py에서 찾을 수 있으며, 예를 들어 UC_ARM_REG_R0은 0번 레지스터, UC_ARM_REG_R1은 1번 레지스터, 그 외에 UC_ARM_REG_FP(프레임 포인터), UC_ARM_REG_PC(프로그램 카운터) 등의 레지스터 ID를 매개변수로 지정하고 값을 읽어 올 수 있다.
reg_write는 레지스터 쓰기 함수로 reg_read와 마찬가지로 매개변수에 레지스터 ID를 설정하여 임의의 값으로 쓰기가 가능하다.
mem_read와 mem_write는 메모리를 읽고 쓸 수 있는 함수이다. 해당 함수의 입력 매개변수로는 메모리의 시작주소가 있으며, 입력한 시작주소부터 한 바이트 단위로 메모리를 읽거나 쓸 수 있다. 만약 소스코드에서 전역 변수 등으로 메모리를 선언하였다면, 해당 전역 변수의 시작주소는 디스어셈블러의 도움 또는 ELF 파일 내부의 심볼 테이블의 정보를 참조하여 얻을 수 있다.
III. 제안하는 검증 프레임워크
본 장에서는 제안하는 에뮬레이션 기반 부채널 취약점 검증 프레임워크의 세부 동작 원리를 설명한다. Fig. 2.는 프레임워크의 전체 작업 흐름을 나타낸다.

Fig. 2. Flowchart of the proposed framework
프레임워크는 크게 네 단계로 구성된다: ①준비단계 – 에뮬레이션 기반 검증을 위해 대상 소스코드를 리호스팅 및 컴파일하고, 바이너리 상에서 검증 대상 암호 함수를 식별한다. ②에뮬레이션 및 로깅 단계 – 대상 바이너리를 에뮬레이터로 실행하여 명령어 단위로 동작을 모사하고, 이 과정에서 발생하는 내부 상태 값을 모두 로그로 기록한다. ③부채널 신호 모델링 단계 – 수집된 로그 데이터에 전처리와 모델링을 적용하여 부채널 공격 유형별로 의미있는 부채널 신호를 생성한다. ④부채널 누출 평가 단계– 최종적으로 정제된 부채널 신호를 바탕으로 암호 모듈에 부채널 정보 누출 취약점이 존재하는지 평가한다.
이하의 절들에서는 각 단계별로, 실제 하드웨어 부채널 테스트 보드를 이용한 전통적인 검증절차와 비교하면서 에뮬레이션 기반 검증 방식에서 추가되는 작업과 차이점을 서술한다.
3.1 준비 단계 (Preparation Phase)
대상 소스코드 리호스팅 –준비 단계의 첫째 작업은 암호 라이브러리에서 검증하려는 대상 암호 함수를 선정하고, 에뮬레이터 환경에 적용 가능하도록 소스코드를 리호스팅하는 것이다. 이 리호스팅 과정에서 가장 주의해야 할 점은 실제 하드웨어 환경과의 유사성을 최대한 유지하는 것이다. 따라서 필요한 최소한의 변경만 소스코드에 가하고, 본질적인 로직은 그대로 보존해야 한다.
암호 함수 리호스팅 과정을 부채널 테스트 보드 환경과 비교하면, 실제 보드에서 대상 암호 함수를 동작시키기 위해 샘플 코드를 수정하고, 통신 모듈 I/O로 송수신할 데이터를 환경에 맞게 재구성하는 일과 유사하다. 본 프레임워크에서는 암호 함수의 입력과 출력을 전달하기 위해 가상 I/O 전역 변수를 선언하여 통신 모듈을 모사한다. Fig. 3은 AES 구현물 3종의 분석에서 사용한 가상화 I/O 변수 vir_IN(입력)과 vir_OUT(출력) 선언 및 활용 예시를 보여준다.

Fig. 3. Example of Declaration and Usage of Virtualized I/O Variables
이렇게 전역으로 선언된 가상 I/O 변수들은 에뮬레이션 및 로깅 단계에서 메모리 후킹 기능을 통해 검증자가 원하는 값으로 읽고 쓸 수 있다. 즉, 실제 하드웨어에서는 별도의 통신 인터페이스로 전달될 데이터를, 에뮬레이터 메모리에 직접 주입하여 암호 함수 입출력을 제어할 수 있다.
I/O 외에 에뮬레이션 환경에서 통제하기 어려운 값으로 내부 난수가 있다. 임베디드 보안 디바이스에서 내부적으로 암호학적 난수를 생성하는 경우, RTC(Real Time Clock) 등의 하드웨어 주변 장치(peripherals)의 접근을 필요로 하는 경우가 대부분이다. 그러나 에뮬레이터에서 해당 코드를 그대로 실행하면 하드웨어 주변 장치를 모사할 수 없어 에뮬레이션에 실패하게 된다. 이러한 이유로 에뮬레이션 기반 환경에서 내부 난수를 제어하기 위해 약간의 트릭이 필요하다. Fig. 4.는 본 프레임워크에서 난수 생성 함수를 가상화하기 위한 예시 코드이다.

Fig. 4. Example of a Virtualized RandomNumber Generation Function
예시 코드와 같이 난수 생성 함수의 코드를 수정하여 내부에서 특정 버퍼(PRNG_buff)를 참조하도록 만들어 두면, 에뮬레이터 실행 중에 해당 버퍼 메모리에 접근하여 난수 값을 간접 제어할 수 있다. 예를 들어, 난수 함수가 호출되기 이전에 에뮬레이터의 메모리 쓰기 기능(uc.mem_write)을 사용하여 PRNG_buff에 검증자가 원하는 값을 미리 써 넣을 수 있다. 혹은 난수 함수 호출이 후에 메모리 읽기(uc.mem_read)를 통해 사용된 난수값을 추출할 수도 있다. 이러한 방법으로 Masked-AES와 같이 난수를 필요로 하는 구현물에서도 난수값을 제어하거나 확인할 수 있다. 더 나아가 역공학 지식과 리호스팅에 숙달된 검증자는 기존의 난수 생성 함수의 입출력 정보를 후킹하여 데이터를 읽거나 쓸 수 있을 것이다.
앞서 제안한 리호스팅 과정을 실제로 적용하기 위한 검증자의 노력은 다음과 같다. 대부분의 경우 에테스트 벡터로 암호 함수의 입출력을 확인하는 구현 정확성 검증 코드는 구현되어 있을 것이다. 따라서 구현 정확성 테스트 코드의 암호 함수 입출력 인자를 가상 I/O와 관련된 코드(Fig. 3.)인 vir_IN(입력)과 vir_OUT(출력)으로 대체하면 된다. 이를 제외하고 본 연구의 실험 예시에서는 리호스팅을 위해 AES의 내부 함수(난수 생성 함수) 여섯줄을 수정하였다(Fig. 4.). 다만 원활한 리호스팅 작업을 위해서는 암호 함수의 입출력 형태와 난수 생성 함수 구현물에 대한 기본적인 이해가 있어야 한다.
소스코드 컴파일링 – 대상 소스코드를 최소로 수정하여 에뮬레이터에서 동작하도록 리호스팅을 완료했다면, 다음으로 해당 코드를 컴파일하여 바이너리를 생성한다. 컴파일 결과물 바이너리 형식은 ELF, HEX, BIN 등이 있으나, 검증 목적에서 특히 중요한 것은 ELF 파일이다. 실행만 고려한다면 어떤 형식이든 무방하지만, ELF 파일은 헤더, 프로그램 헤더, 섹션 헤더로 구성되어 코드, 데이터, 심볼(symbol), 디버깅 정보 등의 메타 데이터를 포함하고 있다. 실제 하드웨어 장비에서 실행만 한다면 이러한 메타데이터는 불필요하여 파일 크기만 증가시키는 정보에 불과하다. 그러나 에뮬레이터 환경에서는 메타데이터, 특히 함수와 변수 이름 등의 심볼 정보가 중요한 역할을 한다. 심볼 정보를 이용하면 특정 함수의 시작과 끝 주소, 전역 변수의 주소 등을 파악할 수 있어 에뮬레이터 상에서 해당 지점을 후킹 트리거로 활용하기 용이하다.
본 연구에서는 arm-none-eabi-gcc 컴파일러를 사용하였으며, 유니콘 엔진에서 임베디드 CPU 에뮬레이션이 가능한 컴파일러 옵션을 조사하였다. 임베디드 디바이스는 OS 없이 베어메탈로 동작하는 환경이므로 --specs=nosys.specs 옵션을 사용하였다. 대표적인 임베디드 CPU인 ARM 코어와 관련된 컴파일러 옵션 중 유니콘 엔진은 두 가지 -mcpu=cortex-m4, -mthumb 컴파일러 플래그 옵션의 에뮬레이션을 지원함을 확인하였다. 최적화 옵션과 관련해서는 별도의 최적화 레벨(-O1, -O2 등)을 주어도 에뮬레이션 가능 여부에는 영향이 없음을 확인하였다.
대상 함수 & 변수 식별 – 심볼 메타데이터가 포함된 ELF 바이너리를 얻었다면, 다음은 해당 바이너리에서 검증 대상 암호 함수와 가상화 변수의 주소를 식별하여야 한다.
본 논문에서는 Capstone 디스어셈블러를 활용하여 ELF 바이너리로부터 함수 리스트를 추출하고, 그중 AES 암호 알고리즘과 관련된 핵심 함수를 식별하였다[24][25]. Fig. 5.는 Capstone 디스어셈블러로 Tiny-AES 바이너리를 해석하여 AES 암호화 함수들을 찾아낸 결과 일부를 보여준다.

Fig. 5. Disassembly results of tiny-AES
이 예시에서 AES_init_ctx 함수가 0x8640 주소에, AES_ECB_encrypt 함수가 0x8684 주소에 시작함을 확인할 수 있다. 이러한 함수 시작 주소는 이후 에뮬레이션 및 로깅 단계에서 특정 함수가 실행되기 시작하는 시점을 트리거로 삼기 위해 사용된다. 예컨대 로그 데이터의 명령어 주소 열에서 0x8684 주소가 등장하는 시점을 탐색함으로써 AES 암호화 함수의 실행 구간을 식별한다.
리호스팅 과정에서 삽입한 가상 I/O 메모리(vir_IN, vir_OUT)와 난수 버퍼(PRNG_buff)와 관련 변수의 정보는 파이썬 라이브러리 LIEF의 get_symbol 기능을 이용하여 추출하였다. 파이썬 라이브러리 LIEF는 변수의 심볼 테이블을 분석하여 이름, 주소, 크기, 유형 등의 정보를 추출할 수 있다. 이 중 주소와 크기 정보는 에뮬레이션 단계에서 메모리 후킹에 활용되는데, 유니콘 엔진이 제공하는 uc.mem_read()와 uc.mem_write() 함수를 통해 해당 메모리 주소의 값을 읽거나 써서 I/O와 난수값을 제어할 수 있다.
3.2 에뮬레이팅&로깅 단계 (Emulating&Logging Phase)
준비 단계에서 에뮬레이터로 실행 가능하도록 리호스팅 및 컴파일된 바이너리를 얻었다면, 에뮬레이팅&로깅 단계에서는 해당 바이너리를 유니콘 엔진으로 실행하고 명령어 단위 동작을 추적하여 로그 데이터를 수집한다. 유니콘 엔진은 에뮬레이션 중 다양한 후킹 기능을 제공한다. 본 프레임워크에서는 부채널 비침투 공격 모델만을 고려하므로 메모리 조작 후킹은 가상 I/O 메모리를 수정하는 경우에만 사용하고, 그 외에는 코드의 동작을 수집하기 위한 후킹만 활용한다. 즉, 실제 하드웨어에서 부채널 신호를 수집하는 것과 같이 에뮬레이션 단계에서도 암호 함수의 입출력만 조절하고, 암호 알고리즘의 동작에는 간섭하지 않으며 로그만 기록한다. 로깅 과정에서 본 프레임워크는 바이너리가 가상의 CPU에서 명령어 단위로 실행되는 모든 과정을 추적하고, 각 명령어 실행 전후의 CPU 레지스터 상태를 비롯한 관련 정보를 실시간으로 읽어들여 테이블 형태로 저장한다.
Fig. 6.은 Tiny-AES 바이너리를 에뮬레이션하여 얻은 로그 데이터의 일부분을 예시로 보여준다.

Fig. 6. Log data of tiny-AES
로그 데이터는 테이블 형태로 저장되며, 각 행은 한 명령어 실행을 나타낸다. 첫 열 ctr은 명령어 실행 순서를 의미하는 카운터로 0부터 1씩 증가한다.
두 번째 열 Address는 실행된 명령어의 메모리 주소로, 이는 앞서 준비 단계에서 디스어셈블을 통해 확인한 바이너리의 명령어 주소와 일치한다. 따라서 로그 테이블에서 Address 열을 살펴봄으로써 특정 함수의 시작과 끝 지점을 찾아낼 수 있다. 예를 들어 AES_ECB_encrypt 함수는 Address 열에서 0x8684 주소가 등장하는 부분부터 해당 함수의 수행 구간으로 판단할 수 있다.
세 번째 열 Opcode와 네 번째 열 Operands는 명령어의 연산 코드와 피연산자들로, CPU가 수행한 연산 종류와 그 대상들을 나타낸다. 부채널 분석 관점에서, 특정 암호 함수가 임의의 입력값에 대해서도 항상 동일한 Opcode 시퀀스를 나타낸다면 해당 구현은 TA/SPA 공격에 내성이 있다고 볼 수 있다. 반대로, 입력에 따라 실행되는 Opcode의 패턴이 달라진다면 이는 조건문 등의 이유로 연산 과정이 분기되었음을 암시하며, 실제 소비 전력에서도 연산 소요시간 또는 전력 파형의 패턴이 구분될 수 있음을 의미한다.
그 이후 열들은 명령어 실행 이전(b)과 이후(a)의 CPU 레지스터 값을 나타낸다. 즉 bR0, bR1, ...은 해당 명령어 수행 직전의 레지스터 상태, aR0, aR1, ...은 수행 직후의 상태를 의미한다. 본 프레임워크는 유니콘 엔진으로 모사 가능한 모든 레지스터(R0–R10, FP(R11), IP(R12), SP(R13), LR(R14), PC(R15), CPSR)의 값을 로그로 기록한다. 이 로그 데이터는 다음 단계에서 부채널 신호를 모델링하기 위한 원시 데이터로 활용된다.
3.3 부채널 신호 모델링 단계(Side-Channel Signal Modeling Phase)
부채널 신호 모델링 단계에서는 에뮬레이팅&로깅 단계에서 얻은 원시 로그 데이터를 가공하여, 각각의 부채널 공격 기법에 활용할 수 있는 의미 있는 부채널 신호로 변환한다. 제안 프레임워크는 공격 유형별로 서로 다른 신호 모델링 방법을 적용한다.
TA/SPA 신호 모델링 – TA/SPA 공격은 암호 연산의 실행 시간이나 소비 전력 패턴의 형태에 의존하여 취약점을 분석한다. 유니콘 엔진은 개별 명령어의 사이클 수 및 실행 시간 정보를 직접 제공하지 않으므로, 이를 보완하기 위해 명령어 별 사이클 수 데이터베이스를 구축하여 합산하는 방법도 생각해 볼 수 있다. 그러나 이러한 접근은 CPU 아키텍처별로 방대한 명령어 사이클 정보를 사전에 수집해야 하므로 비효율적이다. 대신, 명령어 주소열과 Opcode열 자체를 하나의 신호로 보고 시각화하면 입력에 따른 실행 경로 변화 유무를 보다직관적으로 파악할 수 있다.
예를 들어 Tiny-AES에 대해 로그 테이블의 Address 값을 관찰하면 연산 시퀀스에 변화를 확인할 수 있다. Fig. 7은 Tiny-AES 로그의 Address 열을 시각화한 그래프이고, Fig. 8.은Opcode 열을 범주화하여 숫자로 변환한 뒤 시각화한 그래프이다.

Fig. 7. Visualizing the ‘Address’ column in the tiny-AES log table

Fig. 8. Visualizing the ‘Opcode’ columninthetiny-AES log table
Fig. 7.에서 X축은 명령어 실행 순서(ctr), Y축은 명령어 주소 값이다. Fig. 8.의 경우 Opcode는 문자열 데이터이므로 시각화 전에 각 Opcode를 고유한 숫자로 변환하여야한다. 본 프레임워크에서는 MATLAB의 categorical 함수를 활용하여 Opcode들을 정수로 치환하였다. 이러한 Address/Opcode 시각화를 통해 입력 의존적인 분기 발생 여부를 눈으로 쉽게 확인할 수 있다. 즉, 모든 실행이 동일한 경로를 따르면 Y값 변화 패턴이 입력에 상관없이 일정할 것이고, 경로가 달라지면 패턴에도 차이가 나타날 것이다.
DPA 신호 모델링 – DPA 공격 적용을 위한 부채널 신호 모델링으로는 부채널 분석 분야에서 가장 널리 쓰이는 해밍 웨이트/디스턴스(Hamming Weight/Distance, HW/HD) 모델을 적용하였다. 수집된 로그 데이터는 CPU 내부 레지스터의 디지털 값들이므로, 실제 측정 결과인 소비전력과는 근본적인 차이가 있다. 하지만 HW/HD 모델은 디지털 값을 해당 비트들의 1 개수(HW)나 변경된 비트 개수(HD)로 변환함으로써 실제 물리 부채널 신호로 근사해주는 역할을 한다. 구체적으로, 본 프레임워크에서는 명령어 실행 후의 레지스터 값들(aR0, aR1, ...)에 HW 모델을 적용하고, 전후 레지스터 값 쌍((bR0, aR0), (bR1, aR1), ...)에 HD 모델을 적용하여 DPA 분석용 신호들을 생성하였다. 이렇게 얻어진 가상 부채널 신호는 실제 하드웨어에서 측정한 신호와 비교할 때 완벽하게 정렬되어 있는 이상적인 형태이므로, 별도의 전처리 없이 바로 통계적 분석에 활용할 수 있다.
3.4 부채널 누출 평가 단계 (Side-Channel Leakage Assessment Phase)
마지막으로, 앞 단계에서 확보한 부채널 신호를 토대로 검증 대상에 민감 정보 누출 여부를 평가한다. 본 절에서는 에뮬레이션 신호 기반으로 분석한 누출 평가 결과로 대상 암호 함수가 부채널 공격에 내성이 있는지 여부를 판단하는 과정을 자동화하는 방안에 대해 논의한다.
3.4.1 TA/SPA 저항성 평가 및 자동화 방안
TA/SPA 저항성을 달성하기 위해서는 암호연산이 무작위한 입력에 대해 항상 동일한 상수 시간 및 일관된 연산 시퀀스를 유지하여야 한다. 본 프레임워크에서는 TA/SPA 저항성을 평가하는 지표로 로그 데이터의 Address/Opcode 시퀀스를 활용하였다. Address 시퀀스는 바이너리의 명령어 주소값인 정수 형태이며, Opcode 시퀀스 역시 categorical 함수에 의해 정수로 맵핑된 상태이다.
첫 번째 방안은 수집된 차분을 이용한다. 차분 분석 방법은 첫 번째 신호를 레퍼런스 파형으로 설정하고, 나머지 모든 파형을 시점마다 일대일 대응으로 차이 비교하고 이를 합산한 차분 스코어(ScoreDiff)를 계산한다. 스코어가 0이라면 임의의 무작위 입력에 대해 항상 동일한 Address/Opcode 시퀀스를 유지한다는 의미이므로 해당 암호연산은 TA/SPA에 대한 저항성을 달성했다고 판단할 수 있다. 차분 스코어를 계산하는 식은 다음과 같다.
\(\begin{align}\text {Score}_{\text {Diff }}=\sum_{i=1}^{N-1}\left(\left|T_{0}-T_{i}\right|\right)\\\end{align}\) (1)
수식에서 N는 수집된 파형 개수이며, Ti는 i번 째 파형이다.
두 번째 방안은 분산을 이용한다. 분산 분석 방법은 서로 다른 다수의 입력으로 생성한 Address/Opcode 시퀀스들을 그룹으로 모아 시점 각각에 대한 분산 값이 모두 0인지를 계산함으로써 그룹 전체가 모두 동일한지 판단하는 방식이다.
두 방법 모두 이론상 실행 경로가 한번이라도 달라지면 차분 값이나 분산 값이 0이 아닌 것으로 나타난다. 다만, 차분 스코어를 계산하는 과정이 분산을 구하는 과정보다 속도 측면에서 장점이 있어, 본 프레임워크의 TA/SPA 저항성 평가 자동화 항목은 차분 스코어를 채택하였다.
3.4.2 DPA 저항성 평가 및 자동화 방안
DPA 저항성 평가의 지표는 FIPS 140-3 국제 표준에서 권고하는 통계 기법인 t-test 기반 TVLA 평가 방법론을 적용하였다. 다음 수식은 TVLA를 구하는 식이다.
\(\begin{align}\text {TVLA}=\frac{\mu_{\mathrm{A}}-\mu_{\mathrm{B}}}{\sqrt{\frac{\mathrm{s}_{\mathrm{A}}^{2}}{\mathrm{~N}_{\mathrm{A}}}+\frac{\mathrm{s}_{\mathrm{B}}^{2}}{\mathrm{~N}_{\mathrm{B}}}}}\end{align}\) (2)
두 그룹 A와 B에 대해 μ는 평균, s2은 분산, N은 샘플 수이다. 암호 알고리즘의 S-box 출력 등의 중간 상태 값에 비밀 정보와 랜덤 마스크가 섞여 있으면, 고정/랜덤 입력 그룹의 TVLA 결과값이 임계값 범위(±4.5) 내에 있을 것이다. FIPS 140-3에서는 이 임계값의 검정 신뢰도를 높이기 위해 수백만~수천만 개의 부채널 신호를 수집해야 함을 권고하고 있다. 그러나 제안 프레임워크와 같이 노이즈가 통제된 환경에서는 극단적으로 적은 수의 테스트만으로도 통계적으로 유의미한 신뢰 구간의 결과를 얻을 수 있다. 즉, TVLA 임계값 판정 기준을 적용하되 필요한 신호의 개수은 실제 측정보다 크게 감소한다는 이점이 있다. 이는 에뮬레이션 기반 부채널 검증의 가장 큰 장점 중 하나로, 이상적인 신호 환경 덕분에 검정력(statistical power)이 높아지기 때문이다.
본 프레임워크에서는 DPA 저항성 평가 자동화의 효율성 향상을 위해 두 가지 제안을 적용하였다. 첫째로 두 그룹의 파형 개수를 동일하게 수집한다. 둘째로 CPA논문에서 제안한 추정량 수식 변형 방법론을 참조하여 t-test식을 재구성하여 TVLA를 계산한다[26]. 하나의 시점에 대해 두 그룹의 파형 개수가 동일한 경우, TVLA 수식은 다음과 같이 변형이 가능하다.
\(\begin{align}\frac{\sum A-\sum B}{\sqrt{\left(\sum A^{2}+\sum B^{2}\right)-\left(\frac{\left(\sum A\right)^{2}+\left(\sum B\right)^{2}}{N}\right)}}\end{align}\) (3)
위 수식에서 N은 하나의 그룹의 파형 개수 이다. 하나의 시점에 대해 ΣA는 그룹 A의 모든 파형을 합산한 값이며, ΣA2는 각 포인트를 제곱한 후 합산한 값이다. ΣB, ΣB2 역시 그룹 B에서 동일하다. 위 수식을 사용하면 분산을 구하기 위해 모든 파형을 동시에 메모리에 로드할 필요 없으며, 파형을 순차적으로 처리가 가능하다.
3.4.3 에뮬레이션 기반 부채널 검증 시 최소 파형 수
본 소절에서는 에뮬레이션 기반 부채널 취약점 검증에서 가장 큰 장점인 노이즈가 통제되었다는 의미를 조금 더 구체적으로 살펴본다.
부채널 분석에서 고려하는 노이즈는 크게 전자적 노이즈(electronic noise)와 스위칭 노이즈(switching noise) 2가지로 분류 한다[27]. 전자적 노이즈는 실 디바이스의 소비전력을 측정할 때에 측정도구 또는 기타 하드웨어 소자들에 의해 필연적으로 포함되는 물리적인 잡음이다. 스위칭 노이즈는 데이터를 다루는 로직 셀(logic cells)에서 데이터에 의존해서 발생하나 DPA공격에 활용하는 비트들 즉, 비밀키와 관련된 비트들과는 관계없는 잡음이다.
에뮬레이션 기반 환경에서는 전자적 노이즈를 완전히 무시할 수 있다. 스위칭 노이즈의 경우, 부채널 신호 모델링 단계에서 로그 데이터를 어떻게 처리하는지에 따라 임의로 통제가 가능하다. 본 실험에서는 처리 속도를 중시하여 32비트 레지스터 데이터 전부에 대해 부채널 모델링을 적용하였으나 블록암호 DPA 공격의 기본 워드크기인 8비트 단위로도 모델링을 적용할 수 있다. 더 나아가 DCA(Differential Computation Analysis) 공격에서 데이터를 처리하는 방식인 1비트 단위로 로그 데이터를 나열하여 에뮬레이션 되는 모든 비트에 대해 정밀하게 취약점을 분석 할 수 있다[28].
그럼에도 불구하고 만약 부채널 신호 모델링 단계에서 스위칭 노이즈가 발생할 경우에 대해 논의해 보자. 구체적으로 32비트 레지스터 데이터에서 8비트 데이터는 유효하고 24비트 데이터는 스위칭 노이즈에 해당하는 경우에 취약점 분석에 필요한 파형수에 대해 분석해보자.
위 예시에서 SNR(Signal-to-Noise Ratio)을 구하면 다음과 같다.
\(\begin{align}\mathrm{SNR}=\frac{\operatorname{Var}\left(\mathrm{HW}_{8 \text { bit }}\right)}{\operatorname{Var}\left(\mathrm{HW}_{24 \text { bit }}\right)}=\frac{1}{3}\end{align}\) (4)
여기서 Var(.)는 분산이다. Var(HW8bit)의 의미는 8비트 데이터 집합(0x00~0xFF)의 원소각각의 해밍 웨이트 값으로 분산을 구한 결과이다. Var(HW24bit) 역시 24 비트 집합에 대해 동일하게 계산한다.
다음은 SNR과 부채널 취약점 평가방법론 중 TVLA와 NICV의 관계식을 두 논문을 참조하여 정리한 식이다[29][30].
\(\begin{align}\frac{1}{\frac{1}{\mathrm{SNR}}+1}=\mathrm{NICV}=\frac{1}{\frac{2 \mathrm{~N}}{\mathrm{TVLA}^{2}}+1}\end{align}\) (5)
여기서 N은 분석에 사용한 파형 수이다.
우리는 TVLA와 파형 수 N의 관계를 알고 싶으므로, 수식(5)의 좌변과 우변에 수식(4)에서얻은 SNR과 TVLA의 임계값 4.5를 대입한다. 계산 결과 분석에 필요한 최소 파형 수 N은 약 30개임을 알 수 있다. 극단적으로 32비트 레지스터 데이터에서 1비트 데이터는 유효하고 31비트 데이터는 스위칭 노이즈 일 때의 최소파형N은 약 314개이다.
이와 같이 스위칭 노이즈만을 고려하는 에뮬레이션 기반 부채널 취약점 검증 환경은 분석에 필요한 파형 수를 대폭 줄일 수 있는 장점이 있으며, 이론적으로 확인이 가능하다.
3.4.4 에뮬레이션 기반 부채널 누출 평가의 한계점
에뮬레이션 기반 검증기술은 알고리즘 형태의 부채널 대응책을 소스코드로 작성하는 구현단계에서 코딩 실수 등의 휴먼 에러(human error) 또는 컴파일러의 최적화 과정에서 의도하지 않은 코드 변형에 의한 사이드 이펙트를 점검하는데 효과적이다.
그러나 에뮬레이션 기반으로 얻어지는 정보에는 명확하게 한계점이 존재한다. 본 소절에서는 부채널 취약점 분석 관점에서 에뮬레이션 기반 정보의 한계를 파악하고, 이로 인해 생길 수 있는 잠재적인 부채널 취약점에 대해 알아본다. 즉, 실제 테스트보드 등의 하드웨어에서 얻은 부채널 정보를 바탕으로 취약점을 분석해야 되는 사항을 식별해 본다.
① 명령어 레벨 재현 충실도는 CPU 명령어 실행 사이클 중간 단계인 인출(fetch), 해석(decode), 실행(execute), 저장(write back) 각각의 중간상태 정보를 모사하지 못한다. 예를 들어 곱셈 명령어(MUL)는 대부분의 경우에 두 클럭을 소모한다. 따라서 곱셈 명령어가 수행될 때 첫 번째 클럭에 잠재된 부채널 취약점은 실제 하드웨어에서 검증하여야 한다.
② 파이프라인 및 분기 예측, 슈퍼 스칼라 등의 명령어 병렬 처리 기법을 모사하지 못한다. 병렬 처리로 인해 발생할 수 있는 잠재적 부채널 취약점은 마스킹 대응기법의 무력화를 들 수 있다. 구체적으로 병렬 처리에 의해 마스킹된 데이터와 마스킹 값이 동시에 연산되면 소비전력이 합산되어 마스킹 자체가 무력화 될 수 있다.
③ 캐시 메모리와 관련된 정보를 모사하지 못한다. 캐시 메모리란 CPU에서 자주 사용되는 데이터나 명령어를 임시로 저장하여 접근 속도를 향상시키는 전용 메모리이다. 캐시 타이밍공격은 암호화 과정에서 민감한 정보를 계산할 때에 캐시의 접근시간 차이를 이용하여 비밀키를 탈취하는 부채널 공격이다. 그러나 에뮬레이션의 재현 충실도의 한계로 캐시 메모리 정보를 모사 할 수 없다. 따라서 캐시와 관련된 부채널 취약점 역시 실제 하드웨어상에서 검증이 필요하다.
④ 기타 주변장치 및 물리적 회로구조로 인한 부채널 정보를 모사하지 못한다. 제안하는 프레임워크는 CPU만을 모사하여 부채널 취약점 검증에 활용한다. 그러나 현실의 보안 디바이스는 CPU 이외에 주변장치, 즉 메모리, 하드웨어 난수 생성기, 센서 등에서 다양한 부채널 신호정보를 방출한다. 또한 데이터 버스, CPU 레이아웃 등의 미세 회로구조로 인해 신호끼리 상호 간섭하여 예측하지 못한 부채널 정보를 누출할 수 있다. 따라서 하드웨어 구성이 갖춰진 시제품 및 양산품에 대한 부채널 취약점 검증 역시 매우 중요하다.
IV. AES 3종 구현물 분석 결과
본 장에서는 Tiny-AES, Naive-AES, Masked-AES 세 가지 AES 구현물에 대해 제안하는 프레임워크를 적용한다. TA/SPA 및 DPA 공격에 대한 제안하는 프레임워크의 부채널 안전성 검증 결과를 분석한다. 실험을 위해 수집한 데이터 세트는 Table 3.와 같다.
Table 3. Experimental Dataset of Three AES Implementations

입력이 무작위인 1,000개의 로그 데이터는 TA/SPA 검증에 사용한다. DPA 검증에는 입력이 무작위 및 상수인 두 그룹을 비교하여 TVLA 누출 평가를 수행한다.
4.1 제안하는 프레임워크의 TA/SPA 검증 결과
Fig. 9.는 AES 암호 알고리즘 구현물 3종의 Address 및 Opcode 정보를 활용한 TA/SPA 분석 결과를 시각화한 그림이다. 그림 내부 각각의 그래프는 3개의 파형을 겹친 그래프이며, 이로 인해 서로 다른 시퀀스의 파형들은 색깔이 차이를 통해 육안으로 확인이 가능하다.

Fig. 9. Visualization of TA/SPA Vulnerability Validation Results for Three AES Implementations
그림의 행은 AES 구현물 각각을 의미하며, 열은 시각화에 사용한 로그 데이터 테이블의 Address 열과 Opcode 열을 의미한다.
Tiny-AES 구현물은 상수 시간 실행과 마스킹 대응 기법이 미적용된 레퍼런스 AES이다. 프레임워크를 통해 Tiny-AES 바이너리를 에뮬레이션한 결과, 서로 다른 입력 값을 사용하더라도 명령어 실행 시퀀스가 완전히 동일하게 나타났다. 즉, 로그 데이터의 Opcode 열을 시각화하거나 Address 열 패턴을 비교하였을 때 알고리즘 내부 상태 값에 따른 연산의 차이가 없음을 확인하였다. 이는 Tiny-AES가 설계대로 입력에 무관한 일정한 실행 흐름을 유지함을 의미하며, 부채널 공격 관점에서 TA/SPA 공격에 대해 안전함을 의미한다.
Naive-AES는 Tiny-AES에 존재하던 테이블 기반 곱셈을 조건문 분기로 변경함으로써 TA/SPA 공격에 취약한 구현물이다. 제안하는 프레임워크를 사용하여 Naive-AES를 에뮬레이션한 결과, 서로 다른 입력에 대해 명령어 시퀀스에 차이가 발생함이 탐지되었다. 구체적으로, MixColumns 연산 중 상태 바이트의 최상위 비트에 따라 실행되는 명령어의 주소와 Opcode에 대해 차이가 생겼다. 로그 데이터를 더 자세히 분석하면, Naive-AES는 특정 지점에 Address/Opcode 패턴이 두 갈래로 갈리는 것이 확인되었다. Address 열에서 Difference그래프는 수식 (1)로 계산한 차분 스코어(ScoreDiff)이다. Opcode열의 작은 그래프는 명령어의 차이가 있는 구간을 확대한 그림으로, MOVLT와 MOVGE는 각각 피연산자의 크기가 작은 쪽의 데이터를 복사하는 명령어와 피연산자의 크기가 큰 쪽의 데이터를 복사하는 명령어이다. 이 결과는 Naive-AES 구현이 상수 시간 및 SPA 저항성 달성에 실패했음을 암시한다.
Masked-AES는 Tiny-AES 기반으로 제작되어 모든 연산이 상수 시간으로 실행되었고 입력에 따른 분기나 시퀀스 변화는 없었다. 따라서 TA/SPA 측면에서는 Tiny-AES와 동일하게 안전함이 확인되었다.
4.2 제안하는 프레임워크의 DPA 검증 결과
제안하는 프레임워크를 활용하여 DPA 공격을 적용하기 위해 CPU 에뮬레이터가 지원하는 모든 레지스터 각각에 대해 하나의 명령어가 실행될 때마다 해밍 웨이트 및 디스턴스 기반 가상의 전력 신호를 각각 생성하여 연접하였다. Fig. 10.은 AES 암호 알고리즘 구현물 3종의 DPA 분석 결과를 시각화한 그림이다. 그림 내부 TVLA를 제외한 각각의 그래프는 3개의 파형을 겹친 그래프이며, 이로인해 서로 다른 시퀀스의 파형들은 색깔이 차이를 통해 육안으로 확인이 가능하다.

Fig. 10. Visualization of DPA Vulnerability Verification Results for Three AES Implementations
그림의 행은 AES 구현물 각각을 의미하며, 열은 상수 입력으로 생성한 가상의 전력 신호 그래프, 난수 입력으로 생성한 가상의 전력 신호 그래프, 마지막으로 두 그룹의 t-test 검정 결과인 TVLA 그래프이다.
Tiny-AES의 경우 TVLA 값이 일부 지점에서 임계값 4.5를 크게 상회하여 소스코드가 동작하는 과정에서 부채널 신호에 비밀 정보와 관련된 누출이 존재함을 확인하였다. Tiny-AES는 마스킹 등의 DPA 대응책이 없으므로 예견된 결과로, 실제 물리 환경의 DPA 실험과 부합하는 검증 결과이다.
Naive-AES에 대해 부채널 신호 모델링 및 TVLA를 수행한 결과, Tiny-AES와 유사하게 부채널 누출이 존재함을 확인하였다. 따라서 Naive-AES는 TA/SPA뿐 아니라 DPA 공격에도 매우 취약한 구현임이 입증되었다.
Masked-AES는 암호화 연산에 마스킹 기법을 적용하여 DPA 공격에 대한 저항성을 갖춘 구현물이다. 단, 키 스케줄 부분은 마스킹되지 않았다. 본 실험에서는 암호화 라운드와 키 스케줄 두 부분을 비교하여 제안하는 프레임워크의 부채널 누출 탐지 능력 여부를 평가하였다. Masked-AES는 소스코드를 리호스팅할 때 입력 이외에 난수값을 제어할 수 있도록 조치하였다. 제안하는 프레임워크로 Masked-AES 소스코드의 부채널 취약점을 검증한 결과, 실행 앞단에서 부채널 누출이 발생하는 것을 확인할 수 있었다. 이 구간은 프레임워크 중 준비 과정의 대상 함수 식별 결과를 바탕으로 키 스케줄 함수인 것을 확인할 수 있었다. Masked-AES의 키 스케줄 코드는 Tiny-AES 코드와 유사하여, TVLA 결과 역시 비슷한 누출 패턴을 가짐을 확인하였다. 반면 암호화 부분은 t-test의 유의미한 통계 문턱값인 ±4.5 이상의 값이 관측되지 않았다. 즉, Masked-AES 암호화 함수의 소스코드는 마스킹 기법이 올바르게 적용되어 DPA 공격에 저항성이 있고, 이를 프레임워크를 통해 검증할 수 있음을 확인하였다.
실제 암호 구현물에 대해 제안하는 에뮬레이션 기반 프레임워크를 적용한 결과, 부채널 취약점 평가를 물리적 장비 없이 소프트웨어만으로 수행할 수 있는 이점이 있음을 확인하였다. 또한 제안하는 프레임워크는 노이즈가 전혀 없는 파형을 생성하므로 적은 수의 에뮬레이션 수행만으로 단시간에 소스코드의 부채널 취약점을 사전에 판별할 수 있었다. 구체적으로 실제 측정 환경과 비교하여 수백만에서 수천만 개의 수집 과정과 노이즈 제거 등의 신호처리가 필요없어 작업시간을 대폭 축소할 수 있는 장점이 있다. 추가로 Masked-AES의 DPA 안전성을 확인하는 과정에서는 난수를 고정하거나 바꾸어 가며 다양한 시나리오를 시험해 볼 수 있다. 이러한 신속하고 반복 가능한 테스트는 하드웨어 실험으로는 달성하기 어려운 프레임워크만의 강점이라 할 수 있다.
V. 결론
본 논문에서는 임베디드 CPU 에뮬레이터를 활용한 부채널 취약점 자동 검증 프레임워크를 제안하였다. 개발자가 암호 라이브러리 구현 단계부터 부채널 공격 대응책의 효과를 검증하기 위한 목적으로 설계된 본 프레임워크는, 최신 에뮬레이터를 기반으로 동작함으로써 기존 연구들이 지닌 호환성·확장성의 한계를 해소하였다. 또한 리호스팅 기법을 통해 암호함수의 입출력과 난수를 가상화하여 제어함으로써, 실제 하드웨어 없이도 다양한 공격 시나리오의 실험을 가능하게 하였다. 아울러 로그 데이터의 시각화 및 자동 분석 기법을 도입함으로써 부채널 누출 유무를 직관적이면서도 정량적으로 평가할 수 있게 하였다. AES 암호 알고리즘 구현물 3종을 대상으로 프레임워크를 실증하여, 제안하는 프레임워크가 TA/SPA 및 DPA 취약성을 효과적으로 판별할 수 있음을 확인하였다. Naive-AES의 경우 TA/SPA에 대한 취약점의 식별이 가능함을 확인하였으며, Masked-AES의 경우 부채널 대응책 소스코드상의 DPA에 대한 취약점이 없음을 검증하였다. 특히 Masked-AES에 대한 결과는 에뮬레이션 기반 검증을 활용하여 논문 등에서 제시한 마스킹 알고리즘을 정확하게 구현하였는지 확인할 수 있음과, DPA 공격에 대한 안전성을 소스코드 단계부터 평가할 수 있음을 보였다. 따라서 개발 단계에서 부채널 취약점을 선제적으로 발견하고 대응책의 구현 정확도를 높이는 데 본 연구가 기여할 것으로 기대한다.
5.1 향후 연구
마지막으로 제안하는 프레임워크에 대한 향후 연구 방향을 모색하고 논문을 마무리한다.
① 유니콘 엔진의 강력한 메모리 후킹 기능을 활용한 에뮬레이션 기반 침투 공격(오류 주입 공격)에 대한 검증 프레임워크 연구이다. 해당 연구 방향은 에뮬레이터 환경에서 명령어 스킵이나 비트플립 등의 오류 행위를 모사하여 암호 알고리즘의 연산을 오작동시키고, 오류 결과를 분석함으로써 차분 오류 주입 분석과 같은 공격에 대한 취약점도 조기에 발견할 수 있도록 하는 것이다.
② 2.3절에서 잠깐 언급된 코어 에뮬레이터의 모사 성능 향상 및 모사 대상 확장 연구이다. 본 연구에서 사용한 유니콘 엔진은 전용 명령어 세트(AES-NI, SIMD 등)를 지원하지 않는다. 따라서 전용 명령어의 연산 코드(opcode)가 실제 디바이스에서 어떻게 동작하는지 파악하고 에뮬레이터로 해당 연산 코드의 모사를 정의할 수 있다면, 향상된 성능의 에뮬레이터를 제안하는 연구로 발전할 수 있을 것이다. 추가로 바이너리 펌웨어 분야를 넘어 FPGA 시뮬레이터 등과 연동한 하드웨어 암호 IP에 대한 시뮬레이션 기반 부채널 취약점 검증으로 대상의 확장을 생각해 볼 수 있다. 즉, Verilog/VHDL로 설계된 암호 IP 코어를 FPGA 시뮬레이션 환경에서 구동하면서 내부 시그널을 추출하고, 이를 활용하여 부채널 취약점을 HDL(Hardware DescriptionLanguage) 구현 단계에서 검증할 수 있을 것이다.
③ 후양자 암호와 같은 복잡한 공개키 암호 알고리즘에 대한 에뮬레이션 기반 부채널 취약점 검증 방안을 마련하는 것이다. 복잡한 프리미티브 연산으로 구성된 후양자 암호에서 에뮬레이션 기반 검증기술 연구방향을 제시하면, 부채널 누출 평가 결과의 시점과 소스코드 라인 사이의 관계를 정확하고 신속하게 연결하는 방안을 찾는 연구가 있을 것이다.
④ 에뮬레이션 기반 검증기술은 분석 및 공격 기술로도 활용 될 수 있다. 실제 하드웨어에서 오류주입 공격으로 보호 부트 로더를 우회하거나 읽기 보호 비트를 무력화하여 비밀키가 하드코딩된 바이너리 펌웨어 추출이 성공했다고 가정해 보자. 난독화 기법이 적용되어 역공학 분석으로 비밀키를 찾는 것이 어려울 경우, 에뮬레이션 기반 검증기술로 시뮬레이션 파형을 생성하고 DCA 공격으로 비밀키를 분석하는 것이 하나의 돌파구가 될 수 있을 것이다. 다만 이러한 바이너리는 ELF파일과 달리 심볼 정보가 없어 역공학에 대한 지식과 함께 연구되어야 할 것이다.
References
- M. Randolph and W. Diehl, "Power side-channel attack analysis: a review of 20 years of study for the layman," Cryptography, vol. 4, no. 2, art. 15, May 2020. https://doi.org/10.3390/cryptography4020015
- X. Lou, T. Zhang, J. Jiang, and Y. Zhang, "A survey of microarchitectural side-channel vulnerabilities, attacks, and defenses in cryptography," ACM Computing Surveys, vol. 54, no. 6, pp. 1–37, 2021. https://doi.org/10.1145/3456629
- K. Schaffer, FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759, NIST Special Publication 800-140, Mar. 2020.
- C. O'Flynn and Z. Chen, "ChipWhisperer: an open-source platform for hardware embedded security research," Constructive Side-Channel Analysis and Secure Design (COSADE 2014), LNCS 8622, pp. 243–260, Aug. 2014.
- Y. Nomata, M. Matsubayashi, K. Sawada, and A. Satoh, "Comparison of side-channel attack on cryptographic circuits between old and new technology FPGAs," 2016 IEEE 5th Global Conference on Consumer Electronics (GCCE), pp. 1–4, Oct. 2016.
- J. Wichelmann, A. Moghimi, T. Eisenbarth, and B. Sunar, "Microwalk: a framework for finding side channels in binaries," Proceedings of the 34th Annual Computer Security Applications Conference (ACSAC 2018), pp. 161–173, Dec. 2018.
- N. Sehatbakhsh, B. B. Yilmaz, A. Zajic, M. Prvulovic, and A. Orso, "EMSim: a microarchitecture-level simulation tool for modeling electromagnetic side-channel signals," 2020 IEEE International Symposium on High Performance Computer Architecture (HPCA), pp. 71–85, Feb. 2020.
- Unicorn, "Unicorn engine," available at: https://www.unicorn-engine.org (accessed Sep. 2025).
- Q. A. Nguyen and D. H. Vu, "Unicorn: next-generation CPU emulator framework," Black Hat USA, Aug. 2015.
- D. J. Bernstein, "Cache-timing attacks on AES," Manuscript, Apr. 2005.
- P. C. Kocher, "Timing attacks on implementations of Diffie–Hellman, RSA, DSS, and other systems," Advances in Cryptology—CRYPTO'96, Proceedings, LNCS 1109, pp. 104–113, Aug. 1996.
- S. Mangard, "A simple power-analysis (SPA) attack on implementations of the AES key expansion," International Conference on Information Security and Cryptology (ICISC 2002), LNCS 2587, pp. 343–358, 2003.
- P. Kocher, J. Jaffe, and B. Jun, "Differential power analysis," Advances in Cryptology—CRYPTO'99, Proceedings, LNCS 1666, pp. 388–397, Aug. 1999.
- J. Blömer, J. Guajardo, and V. Krummel, "Provably secure masking of AES," Selected Areas in Cryptography (SAC 2004), LNCS 3357, pp. 69–83, Aug. 2005.
- T. Schneider and A. Moradi, "Leakage assessment methodology: a clear roadmap for side-channel evaluations," Cryptographic Hardware and Embedded Systems—CHES 2015, LNCS 9293, pp. 495–513, Sept. 2015.
- J. Daemen and V. Rijmen, "AES proposal: Rijndael," NIST AES Proposal, 1999.
- Tiny AES in C, "tiny-AES-c," available at: https://github.com/kokke/tiny-AES-c (accessed Sep. 2025).
- E. Oswald and K. Schramm, "An efficient masking scheme for AES software implementations," Information Security Applications (WISA 2005), LNCS 3786, pp. 292–305, 2006.
- F. Bellard, "QEMU, a fast and portable dynamic translator," USENIX Annual Technical Conference, FREENIX Track, pp. 41–46, Apr. 2005.
- O. Oleksenko, C. Fetzer, B. Köpf, and M. Silberstein, "Revizor: testing black-box CPUs against speculation contracts," Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2022), pp. 226–239, Mar. 2022.
- G. Barthe, M. Böhme, S. Cauligi, C. Chuengsatiansup, D. Genkin, M. Guarnieri, D. Mateos Romero, P. Schwabe, D. Wu, and Y. Yarom, "Testing side-channel security of cryptographic implementations against future microarchitectures," Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS 2024), pp. 1076–1090, Oct. 2024.
- u-eMuESL, "Unicorn-based emulation for u-eMuESL," available at: https://github.com/khu-mesl-348/u-eMuESL (accessed Sep. 2025).
- Y. Yoo, H. Kim, J. Park, and J. Cho, "u-INJECTOR: unicorn-based firmware dynamic analysis tool," Journal of KIISE, vol. 52, no. 4, pp. 269–275, Apr. 2025. https://doi.org/10.5626/JOK.2025.52.4.269
- Capstone, "Capstone disassembly framework," available at: https://www.capstone-engine.org (accessed Sep. 2025).
- N. A. Quynh, "Capstone: next-gen disassembly framework," Black Hat USA, Aug. 2014.
- E. Brier, C. Clavier, and F. Olivier, "Correlation power analysis with a leakage model," Cryptographic Hardware and Embedded Systems — CHES 2004, LNCS 3156, pp. 16–29, Aug. 2004.
- S. Mangard, E. Oswald, and T. Popp, Power analysis attacks: revealing the secrets of smart cards, Springer US, 2007.
- J. W. Bos, C. Hubain, W. Michiels, and P. Teuwen, "Differential computation analysis: hiding your white-box designs is not enough," Cryptographic Hardware and Embedded Systems—CHES 2016, LNCS 9813, pp. 215–236, Aug. 2016.
- S. Bhasin, J.-L. Danger, S. Guilley, and Z. Najm, "NICV: normalized inter-class variance for detection of side-channel leakage," 2014 International Symposium on Electromagnetic Compatibility, Tokyo, pp. 310–313, May 2014.
- P. Mishra, S. Bhunia, and M. Tehranipoor (eds.), Hardware IP security and trust, Springer International Publishing, 2017.