"We just did not have that on the embedded system": 임베디드 CTF 경쟁에서 얻은 마이크로컨트롤러 시스템 보안 관련 통찰 및 과제

기본 정보

• 논문 ID: 2503.08053
• 제목: "We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions
• 저자: Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Kai Kaufman, Md Armanuzzaman, Xi Tan, Katherine Jesse, Robert J. Walls, Ziming Zhao
• 분류: cs.CR (암호화 및 보안)
• 발표 시간/학회: ACM SIGSAC Conference on Computer and Communications Security (CCS '25)
• 논문 링크: https://arxiv.org/abs/2503.08053

초록

마이크로컨트롤러 시스템은 자동차, 의료 기기 및 산업 제어 시스템 등 중요 응용 분야에 필수적이다. 본 연구는 2023년과 2024년 MITRE 임베디드 CTF(eCTF) 경쟁의 팀 제출물과 경쟁 후 인터뷰를 분석하여 기술적 및 인지적 이중 관점에서 안전한 마이크로컨트롤러 시스템 개발의 전체 생명주기를 분석했다. 연구는 개념적 및 실천적 두 가지 주요 과제를 식별했다: 개념적으로는 마이크로프로세서 시스템에서 마이크로컨트롤러 시스템으로의 전환이 어렵고 참여자들이 마이크로컨트롤러 특정 공격에 대해 인식이 부족하며, 실천적으로는 Rust 등 메모리 안전 언어가 마이크로컨트롤러에서 지원이 부족하고 낮은 품질의 엔트로피 소스가 암호학 및 키 생성의 보안을 약화시킨다. 본 연구는 연구자, 개발자, 공급업체 및 교육자를 위한 맞춤형 권고사항을 제시한다.

연구 배경 및 동기

1. 연구 문제

마이크로컨트롤러(MCU) 시스템은 중요 기반시설에 광범위하게 적용되지만, 안전한 개발은 고유한 과제에 직면해 있다. 기존 연구는 주로 펌웨어 취약점 분석에 중점을 두고 있으며, 특히 개발자의 인지 및 실천 수준에서 취약점 발생의 근본 원인에 대한 심층적 이해가 부족하다.

2. 문제의 중요성

• 광범위한 응용: 마이크로컨트롤러는 자동차, 의료 기기, 산업 제어 등 중요 시스템을 구동
• 보안 취약성: MMU 등 표준 보안 기능 부재, C/어셈블리 프로그래밍으로 인한 메모리 오류 발생 용이
• 물리적 접근성: 범용 컴퓨터에 비해 측면 채널, 결함 주입 등 하드웨어 공격에 더 취약

3. 기존 방법의 한계

• 폐쇄 소스 장벽: 실제 펌웨어 획득 및 분석 어려움
• 단일 관점: 기술 분석만 수행하며 개발자 인지 및 의사결정 과정 간과
• 생명주기 관점 부재: 설계에서 구현까지 취약점 진화 과정 추적 불가

4. 연구 동기

eCTF 경쟁이라는 독특한 관점을 통해 연구팀은 다음을 수행할 수 있었다:

• 완전한 소스 코드, 문서 및 빌드 도구에 접근
• 기술 분석과 개발자 인터뷰 결합
• 초기 연구자의 보안 실천 관찰로 교육 개선 근거 제공
• 체계적 및 경험적 보안 과제 식별

핵심 기여

1. 방법론 혁신: CTF 경쟁을 통한 마이크로컨트롤러 시스템 보안 과제 연구 방법 제시, 기술 분석과 인지 관점을 결합하여 개발 전체 생명주기 검토
2. 이중 과제 분류 프레임워크: 개념적 과제(지식 격차)와 실천적 과제(도구/자원 제한)를 체계적으로 식별 및 분류
3. 실증적 발견:
   • 개념적 과제: 권한 분리, 메모리 소거, 스택 카나리 등 기본 보안 메커니즘 적용 부족; 플랫폼 적응 어려움; 하드웨어 공격 방어 인식 약함
   • 실천적 과제: Rust 등 메모리 안전 언어 지원 부족; 고품질 엔트로피 소스 부재
4. 실행 가능한 권고사항: 5가지 이해관계자(연구자, 공급업체, 교육자, 개발자, 컴파일러 유지보수자)를 위한 9가지 구체적 권고사항 제시
5. 데이터 자원: 47개 팀 제출물 분석(2023년 20개, 2024년 27개), 22회 심층 인터뷰 완료

방법 상세 설명

작업 정의

연구 목표는 마이크로컨트롤러 시스템 보안 개발의 과제를 식별하고 이해하는 것으로, 구체적으로는:

• 입력: eCTF 팀 제출물(소스 코드, 문서, 빌드 도구) + 참여자 인터뷰 데이터
• 출력: 보안 과제 분류, 근본 원인 분석, 개선 권고사항
• 제약: 보안 우선 경쟁 환경에 중점, 참여자는 초기 경력 개발자

연구 구조

1. 제출물 분석(Submission Analysis)

데이터 출처:

• 2023년: 20개 팀, TI TM4C123GXL 개발 보드 사용(ARM Cortex-M4F)
• 2024년: 27개 팀, Analog Devices MAX78000FTHR 개발 보드 사용(ARM Cortex-M4 + RISC-V)

분석 차원:

• 빌드 도구: 프로그래밍 언어, 컴파일러, 최적화 수준, 보안 컴파일 플래그, 링크 스크립트 속성
• 소스 코드: git diff를 사용한 수정 추적, 인라인 어셈블리, 메모리 작업, 난수 생성, 타이밍 관련 코드 검사
• 역어셈블리: 컴파일러 최적화가 보안 기능에 미치는 영향 검증
• 런타임 분석: 디버깅 도구를 사용한 정적 분석의 불확실성 검증

주요 검사 항목:

• 권한 분리(MPU 구성)
• 메모리 소거 구현(memset 최적화 문제)
• 스택 카나리 활성화
• 비실행 스택 구성
• 하드웨어 공격 방어(측면 채널, 결함 주입, 물리적 변조)
• 엔트로피 소스 품질

2. 참여자 인터뷰(Participant Interviews)

표본 특성(n=22):

• 교육 배경: 학부생 12명, 석사생 6명, 박사생 4명
• 보안 과정 경험: 8명이 보안 과정 배경 없음
• 임베디드 경험: 14명이 임베디드 개발 경험 보유

인터뷰 설계:

• 반구조화 인터뷰, 소요 시간 42-107분(평균 69분)
• 제출물 분석에서 반복되는 문제에서 비롯된 질문
• 인지(지식, 오해) 및 의사결정(우선순위, 트레이드오프) 탐색

데이터 분석:

• Otter AI를 사용한 전사 및 수동 검수
• 3명의 연구자가 독립적으로 개방형 코딩 수행
• 반복적 코드북 개발: 8개 주제, 40개 부주제, 278개 코드
• 협력적 코딩 충돌 해결, 공식 신뢰도 검증 불필요

기술 혁신점

1. 이중 접근 방법론: 대규모 코드 분석과 심층 인터뷰 결합으로 "무엇인가"와 "왜인가" 규명
2. 전체 생명주기 관점: 설계 문서→소스 코드→바이너리→개발자 인지에서 취약점 진화 추적
3. 생태계 분석 프레임워크: 문제가 개발자뿐만 아니라 컴파일러, 공급업체, 교육 등 다양한 측면에 기인함을 식별
4. 재현성: 인터뷰 자료 및 코드북 공개(https://github.com/CactiLab/eCTF-User-Study-Material)

실험 설정

데이터 세트

경쟁 데이터:

• 2023 eCTF: 원격 무열쇠 진입 시스템(차량 + 키 포브 펌웨어)
• 2024 eCTF: 인슐린 펌프 시스템(컨트롤러 + 혈당 모니터링 + 펌프 액추에이터)
• 참조 설계: C 언어로 작성, 기능 요구사항 충족하지만 보안 기능 없음

위협 모델:

• 기기 및 통신 채널에 대한 물리적 접근
• 소스 코드 접근(키/플래그 제외)
• 소프트웨어, 네트워크 및 하드웨어 공격

평가 지표

정량적 지표:

• 보안 메커니즘 구현률(권한 분리, 스택 카나리, 메모리 소거, 비실행 스택)
• 하드웨어 공격 방어율(측면 채널, 결함 주입, 비동기 변조)
• 엔트로피 소스 사용 분포

정성적 지표:

• 인터뷰 주제 포화도
• 인지 오해 유형
• 의사결정 우선순위 패턴

비교 방법

기존 연구와의 비교:

• 펌웨어 분석 연구(FirmXRay, Nino et al., Tan et al.): 기술 분석만 수행, 본 논문은 인지 차원 추가
• BIBIFI 연구: 마이크로프로세서 시스템에 중점, 본 논문은 마이크로컨트롤러 고유 과제에 집중
• Rust 채택 연구(Fulton et al., Sharma et al.): 본 논문은 임베디드 특정 제약 결합

구현 세부사항

• 3명의 박사급 임베디드 보안 연구원의 협력 분석
• 저자 팀이 경쟁에 참가했지만 사례 연구에서 제외
• IRB 면제 승인
• 참여자당 50달러 보상

실험 결과

주요 결과

개념적 과제 통계

1. 보안 메커니즘 구현률(그림 1):

2. 하드웨어 공격 방어율(그림 2):

• 모든 방어: 17/47(36.17%)
• 측면 채널 방어: 13/17(76.47%)
• 결함 주입 방어: 9/17(52.94%)
• 비동기 변조 방어: 7/17(41.18%)

3. 엔트로피 소스 사용(그림 3):

• 2023년: 엔트로피 없음 25%, 하드코딩/결함 있음 25%, 단일 엔트로피 소스 45%, 혼합 엔트로피 소스 5%
• 2024년: 엔트로피 없음 22.2%, 하드코딩/결함 있음 14.8%, 단일 엔트로피 소스 55.6%, 혼합 엔트로피 소스 7.4%

실천적 과제 통계

Rust 채택률 감소:

• 2023년: 5/20(25%) 팀이 Rust 사용
• 2024년: 2/27(7.4%) 팀이 Rust 사용
• 주요 원인: 2024년 SDK 크기 증가, Rust+C 혼합 컴파일이 플래시 메모리 제한 초과

제거 실험

메모리 소거 컴파일러 최적화 사례

사례 T12(Listing 1):

• memset 10회를 사용한 민감 데이터 소거
• 컴파일러 최적화로 5회 호출 제거(AES 키 소거 포함)
• 개발자 인터뷰 결과: 컴파일러가 최적화할 것이라는 완전한 인식 부재

효과적 구현 사례:

• T20/T15: Monocypher 라이브러리의 crypto_wipe(volatile 키워드) 사용
• T14/T02: Rust zeroize 라이브러리 사용
• T18: 최적화 방지를 위한 사용자 정의 인라인 함수

스택 카나리 구성 문제

• 2/47 팀만 컴파일러 플래그 활성화
• 무작위 카나리 값 초기화 팀 없음(기본값 고정 상수)
• 실제 펌웨어와 일치: <0.2% 활성화율(Xi et al. 연구)

사례 분석

사례 1: 비실행 스택 오해(T18, T13)

잘못된 구현:

// T18의 링크 스크립트
MEMORY {
    FLASH (rx) : ORIGIN = 0x00008000, LENGTH = 0x00038000
    SRAM (rw) : ORIGIN = 0x20000000, LENGTH = 0x00008000  // rw만 표시
}

문제:

• ELF 헤더 속성만 수정, 펌웨어 초기화 시 MPU 구성 미실행
• 인터뷰 결과: 21/22 참여자가 컴파일러 플래그만으로 충분하다고 생각

올바른 구현(4개 팀):

1. MPU 활성화
2. 스택 메모리 영역을 XN(eXecute Never)으로 구성
3. 해당 영역 활성화

사례 2: Rust unsafe 블록 남용(T11)

문제: unsafe 블록을 광범위하게 사용하여 C SDK 함수 호출 원인: 증분 개발 모델로 코드를 점진적으로 Rust로 이식 허용 비교: C18-T08은 unsafe를 저수준 하드웨어 상호작용 계층으로 제한

사례 3: 엔트로피 소스 조합(T14)

전략: 4개 엔트로피 소스 혼합

• RTC와 CPU 클록 드리프트
• 기기 특정 시드
• 내부 온도 ADC
• 초기화되지 않은 SRAM(실제로는 무효)

효과: 한 소스가 실패해도 조합 시드는 여전히 예측 불가능

실험 발견

관찰 1: 컴파일러 최적화는 언어 사양을 초과하는 보안 상태를 파괴할 수 있음(메모리 소거 등)

관찰 2: 임베디드 특정 공격에 대한 지식 격차가 방어 구현을 방해하는 주요 요인

관찰 3: Rust 의사결정 요인: 친숙도, 공급업체 지원, 라이브러리 지원, 학습 곡선

관찰 4: Rust 사용자가 직면한 과제: no_std 컴파일, HAL 구현, unsafe 관리

관찰 5: 자동화된 하드웨어 설명자를 Rust 구조로 변환하면 HAL 개발을 가속화할 수 있지만, 충실도와 보안성 추가 연구 필요

관찰 6: 마이크로컨트롤러 엔트로피 소스가 제한적이지만, 여러 사용 가능한 소스를 조합하면 난수 견고성을 효과적으로 향상시킬 수 있음

관련 연구

CTF 연구

• 교육 지향: Vigna et al.(iCTF 프레임워크), Vykopal et al.(교수 도구로서의 CTF)
• 과제 분석: Crispin et al.(Defcon CTF 경험), Chung et al.(조직 함정)
• 본 논문의 차별성: 제출물 분석과 인터뷰 결합 최초, 교육 효과가 아닌 보안 개발 과제에 중점

보안 소프트웨어 개발 및 사용자 연구

• BIBIFI 연구(Parker et al., Ruef et al., Votipka et al.): 마이크로프로세서 시스템 개발 분석, 대부분의 취약점이 실수가 아닌 오해에서 비롯됨을 발견
• Rust 채택 연구:
  • Fulton et al.: 고급 개발자 관점, 학습 곡선 및 라이브러리 지원 문제 식별
  • Sharma et al.: 6000개 이상의 임베디드 Rust 프로젝트 분석, 생태계 지원 부족 규명
• 본 논문의 기여: 마이크로컨트롤러 특정 제약에 중점, 기술 및 인지 이중 관점 결합

마이크로컨트롤러 시스템 보안

• 방어 기술: 권한 분리(Kage, ACES, EPOXY), CFI(μRAI, Silhouette, SHERLOC), 난수화(fASLR, HARM)
• 펌웨어 분석: FirmXRay, Nino et al., Tan et al.(실제 펌웨어 정적 분석)
• 본 논문의 독특성: 기술 해결책이 아닌 개발자 인지 과제 연구 최초

결론 및 논의

주요 결론

1. 생태계 책임: 보안 구현은 개발자, 교육자, 연구자, 공급업체의 공동 책임
2. MCU 개발 고유 요구사항:
   • 플랫폼 특성(하드웨어, 컴파일러, 도구 체인)에 대한 깊은 이해
   • 컴파일러의 불투명성 및 반직관적 동작 대응
   • 물리적 접근으로 인한 고유한 위협 방어
3. 교육 격차: 기존 과정이 임베디드 특정 과제에 대해 학생을 충분히 준비하지 못함
4. 3가지 개념적 과제:
   • 기본 보안 메커니즘 적용 부족
   • 플랫폼 적응 어려움
   • 하드웨어 공격 방어 인식 약함
5. 2가지 실천적 과제:
   • 메모리 안전 언어 지원 부족
   • 고품질 엔트로피 소스 부재

한계

1. 외부 타당성:
   • eCTF는 경쟁 환경으로 게임화 요소가 행동에 영향을 미칠 수 있음
   • 참여자는 주로 학생/초기 경력 개발자로 자격 있는 산업 환경으로의 일반화 제한
   • 저자는 발견이 실제 취약점의 보수적 하한을 나타낸다고 생각
2. 연구 범위:
   • 팀 협력 역학 및 경쟁 구조 미포함
   • 개념/실천 분류가 중복될 수 있음
3. 데이터 한계:
   • 자기 보고 데이터는 사회적 바람직성 편향 가능성
   • 표본 크기(n=22) 상대적으로 작음
   • 교육 배경 상세 데이터 부재로 교육 권고사항은 초기 단계
4. 위협 모델:
   • 경쟁 위협 모델이 모든 실제 시나리오를 완전히 반영하지 못할 수 있음

향후 방향

1. 교육 연구: 기존 임베디드 보안 과정의 체계적 검토, 과정 격차 식별
2. 경험 비교: 자격 있는 전문가가 유사한 과제에 직면하는지 조사
3. 도구 개발:
   • 권한 분리 자동화 도구
   • 컴파일러 보안 최적화 검증 도구
   • Rust HAL 개발 간소화 도구
4. 공급업체 지원:
   • 완전한 Rust SDK 또는 Rust-C 바인딩
   • 엔트로피 소스 투명성 및 API 표준화

심층 평가

장점

1. 방법론 혁신:
   • 코드 분석과 심층 인터뷰 결합 최초로 "무엇인가"와 "왜인가" 규명
   • 전체 생명주기 관점에서 취약점 진화 추적
   • 높은 재현성(공개 데이터 및 코드북)
2. 실증적 엄밀성:
   • 47개 팀 제출물의 완전한 분석
   • 22회 심층 인터뷰(평균 69분)
   • 삼각 검증(코드, 문서, 인터뷰, 역어셈블리)
   • 성숙한 방법 준수(Saldaña, Clarke & Braun)
3. 실용적 가치:
   • 5가지 이해관계자를 위한 9가지 구체적 권고사항
   • 체계적 장애물 식별(개인 실수만이 아님)
   • 실제 펌웨어 취약점 비율과의 일치로 발견의 대표성 검증
4. 통찰의 깊이:
   • 컴파일러 최적화가 보안을 파괴할 수 있음 규명(관찰 1)
   • 지식 격차가 방어 구현의 주요 장애물임 식별(관찰 2)
   • Rust 채택의 다차원적 과제 발견(관찰 3-5)
5. 명확한 작성:
   • 구조화된 분류(개념 vs 실천)
   • 풍부한 사례 및 코드 예제
   • 명확한 그래프(그림 1-3)

부족한 점

1. 일반화 제한:
   • 경쟁 환경과 산업 실무의 차이
   • 참여자 경험 수준이 초급
   • 2년 데이터만 포함(2023-2024)
2. 인과 추론:
   • 경쟁 압박 vs 지식 격차의 영향을 완전히 분리 불가
   • 보안 과정 유무에 따른 체계적 차이 미검증
3. 정량 분석 깊이:
   • 통계적 유의성 검증 부재
   • 다양한 요인의 상대적 중요성 정량화 미실시
   • 인터뷰 표본 크기 작음(n=22)
4. 도구 평가:
   • 제시된 권고사항의 실제 효과 미검증
   • 개선 조치 검증을 위한 중재 실험 부재
5. 범위 제한:
   • ARM Cortex-M 플랫폼만 중점
   • RTOS 환경 미포함(베어메탈만)
   • 팀 협력 요인 심층 탐색 미실시

영향력

1. 학술적 기여:
   • 임베디드 보안 사용자 연구의 새로운 패러다임 개척
   • 교육 개혁을 위한 실증 기반 제공
   • 컴파일러 및 도구 체인 개선 방향 식별
2. 실용적 가치:
   • 공급업체는 SDK 및 문서 개선 가능
   • 교육자는 과정 설정 조정 가능
   • 개발자는 일반적 함정 회피 가능
3. 정책적 의의:
   • 임베디드 개발 표준에 보안 포함 지원
   • 규제 기관에 취약점 근본 원인 분석 제공
4. 재현성:
   • 공개 자료로 검증 및 확장 용이
   • 방법을 다른 CTF 또는 개발 경쟁에 적용 가능

적용 시나리오

1. 교육:
   • 임베디드 시스템 보안 과정 설계
   • CTF 경쟁 조직 및 평가
   • 개발자 교육 자료
2. 산업:
   • IoT 기기 보안 감사
   • 보안 개발 생명주기(SDL) 개선
   • 도구 체인 선택 및 구성
3. 연구:
   • 컴파일러 보안 최적화
   • 메모리 안전 언어 임베디드 적응
   • 하드웨어 공격 방어 자동화
4. 표준 제정:
   • 임베디드 보안 모범 사례 지침
   • 공급업체 SDK 보안 요구사항

9가지 핵심 권고사항 요약

참고문헌(선별)

1. 권한 분리:
   • 16 Kage (Du et al., 2022)
   • 10 ACES (Clements et al., 2018)
   • 11 EPOXY (Clements et al., 2017)
2. 메모리 안전:
   • 18 Rust 채택 연구 (Fulton et al., 2021)
   • 52 임베디드 Rust 과제 (Sharma et al., 2024)
3. 펌웨어 분석:
   • 65 FirmXRay (Wen et al., 2020)
   • 42 IoT 펌웨어 보안 (Nino et al., 2024)
   • 56 Cortex-M 시스템 개요 (Tan et al., 2024)
4. 사용자 연구:
   • 46 BIBIFI (Ruef et al., 2016)
   • 62 개발자 보안 오해 (Votipka et al., 2020)

종합 평가: 이것은 임베디드 보안 사용자 연구의 고품질 논문으로, 혁신적인 이중 접근 방법을 통해 마이크로컨트롤러 시스템 보안 개발의 심층적 과제를 규명했다. 최대 가치는 기술 분석과 개발자 인지를 결합하여 교육, 도구 및 실무 개선을 위한 실행 가능한 경로를 제시한 점에 있다. 일반화 제한이 있지만, 실제 펌웨어 취약점 비율과의 일치성이 결론의 신뢰성을 강화한다. 본 연구는 임베디드 보안 커뮤니티를 위한 새로운 연구 패러다임을 수립했으며, 후속 연구가 이를 추가로 검증하고 확장할 가치가 있다.