임베디드 시스템 엔지니어를 위한 펌웨어 보안
펌웨어는 OS가 로드되기 전에 실행되고, 재부팅 시에도 유지되며, 전체 하드웨어 권한으로 실행됩니다. 이러한 조합으로 인해 펌웨어는 애플리케이션 계층 보안 모델로는 다룰 수 없는 고가치 공격 대상이 됩니다. 프로젝트 후반부에 소프트웨어 체크리스트처럼 펌웨어 보안을 취급하는 엔지니어는 항상 최악의 시점에 취약점을 발견합니다. 라이프사이클 및 아키텍처 컨텍스트를 보려면 임베디드 펌웨어 개발 라이프사이클 및 아키텍처 페이지를 참조하십시오. 이 글은 보안 관련 결정에 전적으로 초점을 맞춥니다.
펌웨어 대상에 특화된 보안 위협 모델링
펌웨어 고유의 공격 벡터: 물리적, 공급망 및 업데이트 채널 위협
펌웨어는 표준 CVE 및 OWASP 모델에서 잘 다루지 못하는 세 가지 위협 창, 즉 물리적 접근, 공급망 조작, OTA 업데이트 채널 남용에 직면합니다.
물리적 접근 공격은 직접적이며 종종 과소평가됩니다. 보드에 접근할 수 있는 공격자는 디버그 인터페이스가 잠금 해제된 상태로 남아 있다면 JTAG 또는 SWD 프로브를 연결하여 몇 분 안에 플래시 내용을 읽을 수 있습니다. 생산 빌드에서 활성화된 상태로 남아 있는 UART 셸은 명령 인터페이스를 노출합니다. 일부 설계의 플래시 칩은 분리하여 기성품 프로그래머로 외부에서 읽을 수 있습니다. 이는 이론적인 위험이 아니라 제품 분해 분석 및 경쟁사 역공학에서 사용되는 표준 기법입니다.
공급망 조작은 제조 및 유통 창을 대상으로 합니다. 계약 제조업체에 제공된 펌웨어 이미지가 무결성 검증 없이 전달되면 장치 조립 전에 교체되거나 수정될 수 있습니다. 이 위협은 악의적인 행위자에게만 국한되지 않습니다. 잘못 구성된 프로그래밍 픽스처는 잘못된 이미지를 플래시할 수 있으며, 장치는 부팅 시 이러한 대체 사실을 감지할 방법이 없습니다.
OTA 업데이트 채널은 연결된 장치에서 가장 빈번하게 악용되는 벡터입니다. 파일 무결성만 확인하고 장치에 보유된 공개 키에 연결된 암호화 서명 검증 없이는 업데이트 파이프라인을 통해 업데이트 서버를 가로채거나 스푸핑할 수 있는 모든 당사자가 임의의 펌웨어를 푸시할 수 있습니다. 업데이트 엔드포인트의 약한 인증은 이를 더욱 악화시킵니다. 배포 전 및 배포 후 위협 창에는 다른 제어가 필요하며, 이를 혼동하면 둘 다에 허점이 발생합니다.
표준 취약점 분류 프레임워크는 일반 운영 체제에서 실행되는 소프트웨어를 위해 구축되었습니다. 펌웨어 위협 모델링에는 자체 방법론이 필요합니다.
펌웨어별 신뢰 경계 및 자산 분류
어떤 보안 제어를 선택하든 엔지니어는 펌웨어가 실제로 무엇을 보호해야 하는지 식별해야 합니다. 자산 목록에는 일반적으로 암호화 키, 장치 ID 자격 증명, 보정 또는 구성 데이터, 바이너리에 포함된 독점 알고리즘이 포함됩니다. 각 자산은 다른 위험 프로필을 가지며 다른 보호 접근 방식을 필요로 합니다.
임베디드 타겟의 신뢰 경계 매핑은 서버 측 아키텍처와 한 가지 중요한 점에서 다릅니다. 바로 경계가 논리적일 뿐만 아니라 물리적이기도 하다는 것입니다. 부트로더는 하드웨어 루트 신뢰가 검증한 것만 신뢰합니다. 애플리케이션 펌웨어는 부트로더가 전달한 것만 신뢰합니다. 클라우드 백엔드는 장치가 인증한 것만 신뢰합니다. 해당 체인의 어떤 링크가 끊어지든 전체 모델이 깨집니다.
자산의 위험 등급을 책정하면 제한된 하드웨어에 대한 투자를 우선순위화하는 데 도움이 됩니다. OTP 퓨즈에 저장된 장기 디바이스 ID 키는 전용 보안 요소를 정당화합니다. 단일 업데이트 주기 동안에만 사용되는 세션 토큰은 그렇지 않습니다. 모든 자산에 균일한 보호를 적용하는 엔지니어는 저위험 데이터에 리소스를 낭비하고 결과적으로 고위험 자산은 종종 과소 보호하게 됩니다.
보안 펌웨어 아키텍처: 부트 체인 및 메모리 보호 레이아웃
보안 부트 체인 설계 및 하드웨어 루트 오브 트러스트 통합
보안 부트 체인은 ROM 상주 코드에 대한 신뢰를 고정합니다. 이 코드는 제조업체가 한 번 작성하며 생산 후 수정할 수 없습니다. 이 불변의 부팅 단계는 실행을 전달하기 전에 부트로더의 서명을 확인합니다. 그런 다음 부트로더가 애플리케이션 이미지를 검증합니다. 각 단계는 이전 단계에서 검증된 것만 신뢰합니다.
키 저장소는 이 체인에서 가장 중요한 설계 선택입니다. 각 옵션에는 실제 절충이 따릅니다.
- OTP 퓨즈: 저비용, 쓰기-한번, 외부 종속성 없음 — 그러나 프로비저닝 후 키 순환 불가
- 보안 엔클레이브 (예: Cortex-A의 TrustZone, Cortex-M의 TF-M): 유연성이 더 높은 소프트웨어 기반 키 저장소이지만, 여전히 올바른 구성에 의존합니다.
- 전용 보안 요소 또는 TPM: 하드웨어 기반, 변조 방지, 최고의 공격 저항성 — 구성 요소 비용 및 보드 공간이 추가됩니다.
부팅 시 메모리 보호 장치(MPU) 구성은 데이터 섹션에 대한 실행 금지 영역과 검증된 이미지에 대한 읽기 전용 영역을 강제합니다. MPU 강제가 없으면, 애플리케이션의 버퍼 오버플로우는 깨끗한 부팅 검증 후에도 임의 코드를 덮어쓰고 실행할 수 있습니다.
롤백 방지는 종종 간과됩니다. OTP 또는 보안 NVM에 단조(monotonic) 버전 카운터를 저장하고 더 낮은 버전 번호의 이미지를 거부하면, 패치된 취약점을 다시 노출하는 다운그레이드 공격을 차단합니다.
전용 보안 MCU와 통합 보안 기능 중에서 선택하는 것은 위협 수준과 단위 비용 제약에 따라 달라집니다. 높은 가치 또는 안전 중요 애플리케이션의 경우, 제약된 하드웨어 타겟을 위한 임베디드 펌웨어 설계에서 통합 TrustZone 또는 보안 부팅 주변 장치는 종종 더 낮은 BOM 비용으로 적절한 보호를 제공합니다. 높은 가치 또는 안전 중요 애플리케이션은 일반적으로 별도의 보안 요소를 정당화합니다.
개발 파이프라인 전반에 걸친 펌웨어 보안 제어 구현
펌웨어 이미지 서명, 암호화 및 안전한 OTA 업데이트 구현
이미지 서명에는 비대칭 암호화가 사용됩니다. 개인 키는 빌드 환경의 하드웨어 보안 모듈에 상주하며 절대 외부로 유출되지 않습니다. 해당 공개 키는 제조 시 장치에 프로비저닝되어 애플리케이션이 덮어쓸 수 없는 영역에 저장됩니다. 부팅 시 부트로더는 실행 전에 해당 공개 키와 이미지 서명을 비교하여 검증합니다.
암호화와 서명은 서로 다른 목표를 수행합니다. 서명은 이미지가 신뢰할 수 있는 출처에서 왔음을 증명합니다. 암호화는 바이너리 내용을 추출로부터 숨깁니다. 많은 제품은 서명만 필요로 합니다. 바이너리 자체에 보호 가능한 IP(독점 알고리즘 또는 보정 모델)가 포함되어 있고 위협 모델에 물리적 플래시 판독이 포함된 경우 암호화가 필요합니다.
OTA 업데이트 보안은 서명된 이미지 이상의 것을 요구합니다. 완전한 파이프라인은 먼저 업데이트 매니페스트를 검증하고, 롤백 카운터에 대해 버전 번호를 확인하고, 이미지 서명을 검증한 후에야 플래시에 기록합니다. 매니페스트 검증을 건너뛰면 유효하지만 오래된 서명된 이미지를 사용한 재생 공격이 가능해집니다.
키 관리는 별도의 엔지니어링 계획이 필요합니다. 키 생성은 HSM에서 이루어져야 합니다. 회전 정책은 장치의 예상 서비스 수명을 고려해야 합니다. 임베디드 장치에서의 해지는 서버에서의 해지보다 어렵습니다. 대부분의 설계는 실시간 해지 확인보다는 인증서 만료 및 필수 업데이트를 통해 이를 처리합니다. IoT 장치 펌웨어 업데이트 및 연결 패턴에서는 클라우드 백엔드 신뢰 경계가 이 파이프라인에 또 다른 계층을 추가하여 별도의 처리가 필요합니다.
빌드 중에 사전 스트립 바이너리에 서명한 후 스트립 후 이미지를 배포하는 사례가 프로덕션에서 정기적으로 나타납니다. 서명이 일치하지 않습니다. 수정 방법은 플래싱되는 정확한 아티팩트에 대한 서명을 강제하고 빌드 완료 전에 해시 비교를 통해 확인하는 CI 게이트입니다.
런타임 보안 제어: 워치독, 스택 보호 및 보안 통신
스택 카나리는 실행을 리디렉션하기 전에 버퍼 오버플로우를 감지합니다. MPU 강제 스택 경계와 결합하면 성공적인 오버플로우의 영향 범위를 전체 시스템을 손상시키는 대신 오류가 발생한 작업으로 제한합니다. 대부분의 Cortex-M 대상에서 MPU 스택 가드 영역은 런타임 비용이 거의 추가되지 않습니다.
워치독 타이머는 가용성 제어 장치입니다. 워치독을 서비스하지 못하게 하는 펌웨어 잠김 공격(의도적이든 우발적이든)은 재설정을 트리거합니다. 엔지니어링 절충점은 워치독 타임아웃 선택입니다. 너무 짧으면 합법적인 처리 지연으로 인해 잘못된 재설정이 발생합니다. 너무 길면 장치가 작동 손상을 일으킬 만큼 오랫동안 잠긴 상태를 유지합니다. 산업용 HMI 애플리케이션의 일반적인 범위는 500ms에서 몇 초이며, 최악의 합법적인 처리 창에 맞게 조정됩니다.
펌웨어 계층의 보안 통신은 서버 인증서 유효성 검사뿐만 아니라 MQTT 및 HTTPS 연결을 위한 TLS 상호 인증을 의미합니다. 인증서 고정은 손상된 CA에 대한 보호를 추가하지만 인증서 회전을 복잡하게 만듭니다. 제약이 있는 장치에서는 리프 인증서보다 CA 인증서를 고정하는 것이 보안과 운영 유연성 간의 균형을 맞춥니다.
디버그 인터페이스 잠금은 구성 문제만큼이나 CI 적용 문제이기도 합니다. JTAG 잠금 비트 및 UART 셸 비활성화는 프로덕션 빌드 구성에서 확인해야 하며 디버그 지원 상태로 배포되지 않도록 차단해야 합니다. 서명하기 전에 바이너리의 디버그 퓨즈 구성을 확인하는 CI 게이트는 이 문제가 프로덕션에 도달하는 것을 방지합니다.
결함 주입 방지책은 물리적 접근이 현실적인 위협이 되는 경우에 적용됩니다. 전압 글리치 감지 회로 및 이중화된 중요 검사(동일한 보안 결정 두 번 실행 및 결과 비교)는 보안 부팅 또는 키 파생 작업에 대한 성공적인 글리치 공격 비용을 높입니다.
보안 검증: 펌웨어 정적 분석, 퍼징 및 침투 테스트
펌웨어 대상 정적 분석은 애플리케이션 계층 스캔과는 다른 약점을 식별합니다. 우선순위 문제는 경계 검사 없는 안전하지 않은 메모리 작업, 플래시에 하드코딩된 자격 증명, 키 생성을 위한 약한 엔트로피 소스, 통신 핸들러의 검증되지 않은 외부 입력입니다. PC-lint, Polyspace 또는 Coverity와 같은 도구는 코드가 하드웨어에 도달하기 전에 이러한 문제 중 다수를 포착합니다.
펌웨어 퍼징은 두 가지 접근 방식으로 나뉩니다. 에뮬레이션 기반 퍼징은 소프트웨어 에뮬레이터에서 펌웨어 이미지를 실행하여 하드웨어 없이 고속 입력 생성 및 커버리지 측정을 허용합니다. 하드웨어 루프 퍼징(Hardware-in-the-loop fuzzing)은 실제 대상에서 실행되어 에뮬레이터가 놓치는 하드웨어별 동작을 포착합니다. 속도와 충실도 간의 트레이드오프입니다. 대부분의 팀은 개발 초기에 광범위한 커버리지를 위해 에뮬레이션을 사용하고 릴리스 전에 통신 인터페이스의 대상 테스트를 위해 하드웨어 루프 퍼징을 사용합니다.
펌웨어에 대한 침투 테스트 범위에는 프로덕션 하드웨어에 대한 물리적 추출 시도, 재생되거나 수정된 패키지를 사용한 업데이트 채널 남용, 잠긴 장치에 대한 디버그 인터페이스 프로빙이 포함되어야 합니다. 소프트웨어 로직만 테스트하면 물리적 공격 표면이 완전히 누락됩니다.
CI의 보안 검사에는 알려진 취약한 라이브러리 버전에 대한 바이너리 스캔, 모든 펌웨어 종속성을 추적하기 위한 SBOM 생성, 모든 빌드 아티팩트에 대한 자동 서명 검증이 포함되어야 합니다. 컴플라이언스 프레임워크 — 산업 시스템의 경우 IEC 62443, 플랫폼 펌웨어 복원력의 경우 NIST SP 800-193, Arm 기반 장치의 경우 PSA Certified — 은 이러한 파이프라인 제어에 잘 맞는 구조화된 검증 기준을 제공합니다.
이러한 제어를 사내에서 구축할지 또는 전문 파트너와 협력할지 여부를 평가하는 엔지니어는 보안 키 프로비저닝 및 HSM 통합에 대한 팀의 깊이를 특별히 평가해야 합니다. 이러한 단계에서 격차가 가장 자주 나타납니다. 보안 요구 사항으로 구축된 맞춤형 펌웨어 처음부터 설계하면 아키텍처가 지원하도록 설계되지 않은 제어를 나중에 추가하는 비용을 피할 수 있습니다.
펌웨어 보안은 초기에 이루어진 설계 약속의 집합이며 빌드 파이프라인을 통해 지속적으로 적용됩니다. 프로젝트 시작 시 위협 모델링 및 서명 인프라를 포함하는 팀은 릴리스 시 보안 제어를 추가하는 팀보다 상당한 수준의 수정 비용이 적게 듭니다. STONE HMI는 산업용 HMI 시스템을 위한 프로덕션 등급 펌웨어를 개발합니다. 이러한 종류의 프로세스 규율 — 빌드 파이프라인에 추가되는 것이 아니라 통합된 보안 제어 — 은 배포된 장치에 걸쳐 패치하기 비싼 후기 수정 및 필드 취약성의 위험을 직접적으로 줄입니다.
