제 8 장: OTA와 신뢰 목록 부트스트랩

8.1 서론 — 왜 OTA가 IoT 보안의 마지막 방어선인가

경량 TLS(TLS Lite) 표준을 채택하는 임베디드 장치는 한번 출하되면 수년에서 수십 년 동안 현장에서 동작한다. 가정의 보일러 컨트롤러, 가로등의 IoT 노드, 공장 한 구석의 PLC, 자동차의 ECU, 의료기관의 환자 모니터, 농업용 토양 센서 등 그 형태는 다양하지만 공통점이 하나 있다. 사람의 손이 닿기 어렵거나, 닿더라도 비용이 매우 비싸다는 점이다. 결국 출하 이후 발견되는 취약점은 무선 펌웨어 업데이트, 즉 OTA(Over-The-Air Update) 경로로밖에 대응할 수 없다. OTA가 안전하지 않다면 그 장치의 보안은 출하 당시의 한 순간에 박제되며, 시간이 흐를수록 누적되는 미발견 취약점 위에 노출된다.

본 장은 TLS Lite 표준이 권고하는 OTA 아키텍처와 신뢰 목록(Trust List) 부트스트랩 절차를 다룬다. 핵심 기준은 두 가지이다. 첫째, IETF RFC 9019에 정의된 SUIT(Software Updates for IoT) 아키텍처를 1차 참조로 채택한다. SUIT는 제약된 노드를 1순위 사용 대상으로 설계되었으며, COSE 서명·CBOR 인코딩·CWT 클레임을 사용함으로써 본서 제 4 장의 봉투 계층과 자연스럽게 합성된다. 둘째, 학술계의 멀티 키 위협 모델인 TUF(The Update Framework, Samuel et al. 2010)의 위협 분석을 빌려와 단일 서명키 손상 시 전체 시스템이 무력화되는 시나리오를 차단한다. 본 표준은 이 둘을 결합하여 제약된 마이크로컨트롤러에서도 실행 가능한 멀티 키 OTA 모델을 구성한다.

OTA가 단순한 펌웨어 다운로드 절차로 환원될 수 없는 이유는 위협 모델이 매우 풍부하기 때문이다. 중간자 공격(MITM)으로 펌웨어가 변조될 수 있고, 다운그레이드 공격(Downgrade)으로 이미 알려진 취약점이 있는 옛 펌웨어를 강제로 설치시킬 수 있다. 재생 공격(Replay)으로 적법한 업데이트 패킷이 시간차로 다시 주입될 수 있고, 대규모 배포 손상(Mass Deployment Compromise)으로 한 번 손상된 서명키가 수백만 대의 장치에 손상된 펌웨어를 배포하는 시나리오도 현실이다. 2018년에 발생한 ASUS Live Update 사건은 정상 코드 서명 인프라가 손상된 채 50만 대 이상의 PC에 백도어를 배포한 실 사례이다. IoT 분야의 OTA는 PC 분야보다 패치 빈도가 낮고 장치 수가 훨씬 많으므로, 한번 손상 시 피해 규모는 훨씬 더 크다.

본 장에서 제시하는 모델은 다음의 6가지 축에서 종합 방어를 구성한다. (1) 멀티 서명키와 임계 서명(threshold signing)으로 단일 키 손상의 단일 실패점을 제거한다. (2) 메타데이터 4종 분리(root·targets·snapshot·timestamp)로 키 회전을 안전하게 수행한다. (3) 단조 증가 카운터(monotonic counter)로 다운그레이드와 재생을 차단한다. (4) A/B 파티션 부팅으로 업데이트 실패 시 자동 롤백을 보장한다. (5) 무결성 검증을 SHA-256과 Ed25519의 두 단계로 분리한다. (6) 신뢰 목록 부트스트랩 단계에서 공장 출하 시 단 1개의 루트 키만을 박고, 이후 모든 위임 키는 그 루트 키 체인을 통해 검증한다. 이 6축은 RFC 9019, RFC 9124, RFC 9491, TUF 학술 논문, NIST SP 800-193을 종합하여 구성된다.

8.2 위협 모델 — TUF의 멀티 키 분석에서 배우는 것

TUF(The Update Framework)는 2010년 Samuel·Mathewson·Cappos가 ACM CCS에서 발표한 학술 프레임워크로, 소프트웨어 배포 시스템에서 발견되는 7가지 핵심 위협을 체계적으로 분류하였다. 본 표준은 그 분류를 OTA 영역에 옮겨와 임베디드 장치에 맞게 재구성한다. TUF는 원래 PC와 서버 환경의 패키지 관리자를 1순위 대상으로 했지만, 그 위협 모델 자체는 임베디드 OTA에도 그대로 적용된다.

TUF가 분류한 7가지 위협 중 본 장이 1순위로 다루는 것은 다음 5가지이다. (1) 임의 패키지 공격(Arbitrary Package Attack) — 서명되지 않은 임의 펌웨어를 장치가 받아들이는 공격. (2) 메타데이터 위조(Malicious Metadata) — 서명은 맞지만 가리키는 페이로드 해시가 변조된 공격. (3) 재생 공격(Replay Attack) — 옛 시점의 적법한 서명을 그대로 다시 주입하는 공격. (4) 키 손상 회복 부재(Lack of Key Revocation) — 한 번 손상된 키가 영원히 권한을 유지하는 시나리오. (5) 느린 회복(Slow Retrieval Attack) — 업데이트 메타데이터의 신선도를 검증하지 않아 옛 상태가 유지되는 공격. 본 표준은 이 5개의 위협에 각각 대응되는 메커니즘을 의무화한다.

단순 코드 서명 모델의 가장 큰 약점은 단일 서명키에 모든 신뢰가 집중된다는 점이다. 그 키가 단 한 번이라도 손상되면 — 개발자 노트북 도난, CI/CD 빌드 서버 침투, HSM 운영 실수 — 그 키로 서명된 모든 펌웨어가 정상으로 보이게 된다. 2017년의 CCleaner 사건, 2018년의 ASUS Live Update 사건, 2020년의 SolarWinds 사건은 모두 이 단일 키 모델의 한계를 드러낸 실제 사례이다. TUF는 이 한계를 임계 서명과 키 회전으로 해결하며, 본 표준은 그 해결책을 IoT 환경에 맞게 경량화하여 채택한다.

본 장에서 다루는 위협 모델은 STRIDE 프레임워크 — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — 에 1:1로 매핑된다. Spoofing은 위조된 매니페스트로, Tampering은 페이로드 변조로, Repudiation은 서명자 신원 부인으로, Information Disclosure는 펌웨어 평문 노출로, Denial of Service는 의도된 브릭킹(bricking)으로, Elevation of Privilege는 부트로더 권한 탈취로 각각 나타난다. 본 표준의 6축 대응 모델은 이 6개의 STRIDE 항목 모두를 커버한다.

8.3 RFC 9019 — SUIT 아키텍처 개요

IETF RFC 9019(2021년 4월 발행)는 IoT 소프트웨어 업데이트의 아키텍처 표준이다. 작업그룹 SUIT(Software Updates for IoT)에서 4년에 걸쳐 작성되었으며, RFC 9124(SUIT Information Model)와 RFC 9491(SUIT Manifest Serialization)의 상위 계층을 정의한다. RFC 9019는 어떤 정보가 매니페스트에 담겨야 하는지를 정보 모델로 추상화하고, RFC 9124가 그 정보의 의미적 정의를, RFC 9491이 그 정보의 CBOR 구체 직렬화를 각각 담당한다.

SUIT 아키텍처의 핵심 아이디어는 매니페스트(manifest)와 페이로드(payload)의 분리이다. 매니페스트는 업데이트 절차의 메타데이터를 담은 CBOR 객체로, COSE_Sign1으로 서명된다. 페이로드는 실제 펌웨어 바이너리이며, 매니페스트가 그 SHA-256 다이제스트를 클레임으로 담는다. 이 분리 덕분에 페이로드 자체를 서명할 필요가 없다 — 매니페스트만 서명하면 페이로드의 무결성도 함께 보장된다. 페이로드는 대개 수십~수백 KB이고 매니페스트는 1~2 KB이므로, 제약된 장치에서 서명 검증 비용이 결정적으로 줄어든다.

RFC 9491에 정의된 SUIT 매니페스트의 CBOR 직렬화는 의도적으로 매우 컴팩트하다. JSON·XML·ASN.1과 비교하여 동등한 정보를 3~5배 더 작은 바이트로 표현한다. 본 표준의 봉투 계층(제 4 장)이 채택한 CBOR Web Token(RFC 8392)과 같은 CBOR 직렬화 규약(RFC 8949)을 공유하므로, OTA 페이로드 검증과 일반 인증 봉투 검증이 같은 CBOR 파서를 재사용할 수 있다. 이 재사용은 코드 크기(footprint) 측면에서 결정적으로 중요하다. 임베디드 장치의 ROM은 보통 64KB~512KB로 제약되며, CBOR/COSE 파서가 단 한 벌이면 8~16KB로 끝난다.

; RFC 9491 SUIT 매니페스트 CBOR 의사 코드(축약)
SUIT_Manifest = {
  ? suit-manifest-version          => uint,
  ? suit-manifest-sequence-number  => uint,
  ? suit-common                    => SUIT_Common,
  ? suit-reference-uri             => tstr,
  ? suit-manifest-component-id     => SUIT_Component_Identifier,
  ? suit-validate                  => SUIT_Command_Sequence,
  ? suit-load                      => SUIT_Command_Sequence,
  ? suit-install                   => SUIT_Command_Sequence,
  ? suit-run                       => SUIT_Command_Sequence,
  ? suit-text                      => SUIT_Text_Map,
}

SUIT_Common = {
  ? suit-components               => [ + SUIT_Component_Identifier ],
  ? suit-shared-sequence          => SUIT_Command_Sequence,
}

; 페이로드 다이제스트 클레임(SHA-256, 32바이트)
suit-parameter-image-digest = h'a3b1...32f0'  ; bstr 32

; COSE_Sign1 외부 봉투
COSE_Sign1 = [
  protected:   bstr .cbor { 1: -8 },  ; alg = EdDSA(-8)
  unprotected: { },
  payload:     bstr .cbor SUIT_Manifest,
  signature:   bstr .size 64,         ; Ed25519 서명 64바이트
]

위 CBOR 의사 코드의 핵심은 페이로드 자체가 매니페스트 안에 들어가지 않는다는 점이다. 매니페스트는 페이로드의 SHA-256 다이제스트만을 담는다. 페이로드는 별도의 전송 채널 — HTTPS, CoAPs, BLE, LoRaWAN, NB-IoT 등 — 으로 다운로드되며, 장치는 다운로드 후 SHA-256을 재계산하여 매니페스트의 다이제스트와 비교한다. 이 분리 덕분에 매니페스트는 1~2KB로 유지되며 COSE_Sign1의 Ed25519 서명 검증은 32비트 마이크로컨트롤러에서 100ms 이내에 완료된다.

SUIT 매니페스트의 명령 시퀀스(command sequence) 개념은 명령형 프로그램과 비슷한 절차 기반 모델이다. suit-validate·suit-install·suit-run 각각의 단계마다 일련의 명령(set parameter·condition·directive)이 순차적으로 실행되며, 어느 단계에서 조건 검증이 실패하면 전체 절차가 중단된다. 이 명령형 모델은 펌웨어 배포자가 "장치가 이 펌웨어를 받아들이려면 다음 조건을 모두 만족해야 한다"는 정책을 매니페스트에 박을 수 있게 한다. 예컨대 "공급업체 ID는 X여야 하고, 클래스 ID는 Y여야 하며, 현재 시퀀스 번호는 Z 이상이어야 한다"는 정책이 SUIT_Condition 명령으로 표현된다.

8.4 신뢰 목록 부트스트랩 — 공장 출하 시 박는 단 1개의 루트 키

신뢰 목록(Trust List) 부트스트랩은 OTA 보안의 출발점이다. 장치가 출하될 때 펌웨어 ROM에 박히는 신뢰 앵커(trust anchor)가 무엇이냐에 따라 그 장치의 전 생애 보안 수준이 결정된다. 본 표준은 단순함과 회복력 사이의 균형을 위해 다음 모델을 권고한다. 공장 출하 시 ROM에 단 1개의 루트 공개키(root public key)만을 박는다. 이후 등장하는 모든 다른 키 — 위임 키(delegated keys), 회전된 키(rotated keys), 임시 서명 키(ephemeral signing keys) — 는 그 루트 키 체인을 통해 검증된다. 이 모델의 이점은 (a) ROM 사용량 최소화, (b) 공장 출하 절차 단순화, (c) 키 손상 시 회복 절차 명확성 세 가지이다.

그러나 단 1개의 루트 키는 그 자체가 단일 실패점이 된다. 그 루트 키 자체가 손상되면 전체 장치 군집이 무력화된다. 본 표준은 이를 완화하기 위해 두 가지 추가 메커니즘을 권고한다. 첫째, 루트 키는 임계 서명(threshold signature) 모델로 운영되어, 단일 개인이 단독으로 사용할 수 없도록 한다. 예컨대 5-of-7 임계 모델에서는 7개의 임원/엔지니어가 키 분할 조각을 보유하고, 그 중 5명이 모여야 루트 서명을 만들 수 있다. 둘째, 루트 키 회전(root rotation) 절차를 표준화한다. 새 루트 키를 옛 루트 키로 서명한 새 root.json 메타데이터를 발행하면, 장치는 옛 신뢰 앵커를 사용해 새 신뢰 앵커를 검증하고 자체적으로 신뢰 앵커를 교체한다.

이 4종 분리 모델의 핵심은 각 메타데이터의 키가 분리된다는 점이다. root.json은 오프라인 HSM에 보관되며 임계 서명으로만 사용된다. 사용 빈도는 연 1~2회로 매우 낮다. 반대로 timestamp.json은 시간당 갱신되므로 온라인 자동 서명 서버에 키가 있다. 만약 timestamp 키가 손상되더라도 공격자는 신선도 증명만을 위조할 수 있을 뿐, 실제 펌웨어를 변조할 수는 없다. 펌웨어 변조는 targets 키 손상이 필요한데, targets 키는 분기당 1~2회만 사용되므로 침투 기회가 적다. 만약 그것마저 손상되면 root 키로 회전을 발행한다.

한 OTA 운영 책임자는 가전 업계 25년 경력 가운데 자사의 첫 임베디드 보안 사고가 단일 서명키 도난이었다고 회고하였다. 개발자 노트북이 분실되었고 그 노트북에는 펌웨어 서명용 비밀키가 평문 파일로 들어 있었다. 사고 발생 후 회사는 모든 장치에 회수 공지를 발송했지만, 전체 시장의 12%만이 회수에 응했고 나머지 88%는 손상된 서명키로 만든 펌웨어를 받을 수 있는 상태로 남았다. 이 사고가 회사가 TUF/SUIT 모델로 전환한 직접적 계기였다. 본 표준의 4종 메타데이터 분리는 이런 시나리오에서 root 키 회전 한 번으로 전체 시장의 신뢰를 회복할 수 있게 한다.

신뢰 목록 부트스트랩의 또 다른 핵심 결정은 위임 깊이(delegation depth)이다. 루트 키가 직접 targets 키를 위임할 수도 있지만, 더 일반적인 모델은 중간 위임 키(intermediate delegated keys)를 한 단계 둔 후 그 아래에 targets 키를 두는 것이다. 이 구조는 X.509의 인증서 체인과 동일하다. 본 표준은 임베디드 환경의 메모리 제약을 고려하여 최대 위임 깊이 3을 권고한다(루트 → 중간 → 타깃). 3보다 깊은 위임은 검증 시 누적 서명 검증 횟수가 늘어나므로 OTA 다운로드 시간이 증가한다. 32비트 마이크로컨트롤러에서 Ed25519 1회 검증은 80~120ms 정도이므로, 3단계 위임이면 약 240~360ms로 끝나며 사용자가 체감할 수 없는 수준이다.

8.5 키 회전 — 손상 후 회복의 자동화

키 회전(key rotation)은 OTA 보안의 회복력을 결정하는 가장 중요한 메커니즘이다. 침투 후 회복 시간(MTTR, Mean Time To Recovery)이 짧을수록 손상의 피해가 작아진다. 본 표준은 키 회전을 4단계 등급으로 분류하여, 손상의 심각도와 회복 절차를 매핑한다. 등급 1은 timestamp 키 손상(피해 작음, 자동 회전), 등급 2는 snapshot 키 손상(피해 중간, 반자동 회전), 등급 3은 targets 키 손상(피해 큼, 수동 회전), 등급 4는 root 키 손상(피해 치명, 임계 서명 절차)이다.

키 회전이 자동화될 수 있는 이유는 root 키가 다른 3종 키를 모두 위임하기 때문이다. timestamp·snapshot·targets 키가 새로 발급되면 그 새 키의 공개키를 root 키로 서명하여 새 root.json을 발행한다. 장치는 다음 OTA 폴링에서 새 root.json을 검증하고 자체 신뢰 목록을 갱신한다. 갱신 후에는 옛 키로 서명된 메타데이터를 자동으로 거부한다. 본 표준은 옛 키 거부 유예 기간(grace period)을 24시간으로 권고한다 — 24시간보다 짧으면 시간대가 다른 장치 군집이 일시적으로 옛 키와 새 키 사이의 회색 지대에 빠질 수 있고, 24시간보다 길면 손상된 키가 부당하게 오래 통용된다.

키 회전과 함께 반드시 동반되어야 하는 것이 키 사용 이력(key usage log)이다. 본 표준은 모든 서명 행위가 감사 로그에 기록될 것을 권고한다. 로그에는 (a) 서명 시각(RFC 3339 UTC), (b) 서명자 운영자 ID, (c) 서명 대상의 SHA-256 다이제스트, (d) 서명 키 핑거프린트, (e) 임계 서명의 경우 동의 서명자 명단이 담긴다. 이 로그는 본서 제 6 장의 감사 전송 표준을 그대로 재사용한다. W3C Trace Context의 traceparent ID로 OTA 빌드 파이프라인의 전 단계가 상관관계를 유지한다.

임계 서명(threshold signing)은 본 표준이 root 키에 대해서만 의무화한다. 임계 서명의 구체 알고리즘으로는 FROST(Flexible Round-Optimized Schnorr Threshold signatures, IRTF CFRG 진행 중) 또는 Shamir Secret Sharing 기반의 Ed25519 분할이 권고된다. 5-of-7 임계 모델은 (a) 7명이 모두 모이지 않아도 5명이면 서명 가능하므로 가용성이 보장되고, (b) 동시에 단일 개인 또는 4명 이하의 음모로는 서명할 수 없으므로 내부자 공격에 강하다. 임계 서명 절차는 분기당 1회 정기 훈련을 권고한다 — 1년에 한 번만 사용되는 절차는 실제 사고 시 수행이 어렵기 때문이다.

8.6 A/B 파티션 부팅과 anti-bricking

업데이트 절차의 마지막 단계인 부팅(boot)은 OTA의 회복력에서 결정적인 역할을 한다. 새 펌웨어를 다운로드하고 검증한 후 그것을 활성 파티션에 기록했는데, 그 새 펌웨어가 실행 도중 무한 재부팅(boot loop)에 빠지거나 부팅 자체가 실패하면 어떻게 할 것인가. 본 표준은 A/B 파티션(A/B partition) 모델을 채택한다. 장치의 펌웨어 저장소를 두 개의 동일 크기 파티션 A와 B로 분할하고, 한 번에 둘 중 하나만 활성(active)이다. 새 펌웨어는 비활성 파티션에 기록되며, 검증이 끝나면 부트로더가 활성 파티션을 전환한다.

새 펌웨어가 정상 부팅에 성공하면 부트로더가 그 파티션을 "건강(healthy)" 상태로 표시한다. 정상 부팅 후 일정 시간(보통 5~10분) 동안 안정적으로 동작하면 워치독(watchdog) 메커니즘이 건강 표시를 확정한다. 만약 그 시간 안에 워치독 신호가 끊기면 부트로더는 다음 부팅 시 자동으로 이전 파티션으로 복귀(rollback)한다. 이 자동 롤백 덕분에 OTA가 실패해도 장치가 영구히 brick되지 않는다.

A/B 모델의 단점은 펌웨어 저장소가 2배 필요하다는 점이다. 256KB ROM에 64KB 펌웨어를 담는 장치는 두 파티션을 다 보유할 수 없다. 본 표준은 이런 제약된 장치를 위한 단순 모델(simple model)도 인정한다. 단순 모델은 한 파티션만 보유하며, OTA 실패 시 공장 초기 펌웨어로 자동 복귀한다. 이 모델은 회복 시간이 길어지고 사용자가 재구성을 다시 해야 하지만, 메모리 비용이 절반이다. 본 표준은 256KB 이상 ROM 장치에는 A/B 모델을, 그 미만에는 단순 모델을 권고한다.

부트로더 자체의 무결성은 NIST SP 800-193(Platform Firmware Resiliency Guidelines, 2018년 5월)이 권고하는 RoT(Root of Trust) 개념으로 보장된다. RoT는 변경 불가능한 ROM 영역(immutable ROM)에 박힌 1차 부트 코드로, 이후 모든 부팅 단계를 측정(measurement)하고 서명 검증한다. NIST SP 800-193은 RoT가 (a) 변경 불가, (b) 측정 가능, (c) 회복 가능, 세 속성을 모두 만족해야 함을 권고한다. ARM PSA Firmware Update(2022)와 IEEE 802.1AR-2018(Secure Device Identity, DevID)은 동일한 원리를 마이크로컨트롤러와 네트워크 장치에 각각 적용한 표준이다.

8.7 다운그레이드 차단 — 단조 증가 카운터

다운그레이드 공격(downgrade attack)은 공격자가 이미 알려진 취약점이 있는 옛 펌웨어를 장치에 강제로 설치시키는 공격이다. 옛 펌웨어 자체는 적법한 서명을 가지므로 단순 서명 검증만으로는 막을 수 없다. 본 표준은 단조 증가 카운터(monotonic counter) 메커니즘을 의무화하여 이 공격을 차단한다. 모든 매니페스트는 suit-manifest-sequence-number 필드를 가지며, 그 값은 단조 증가한다. 장치는 자신이 마지막으로 설치한 시퀀스 번호를 NVM(Non-Volatile Memory)에 저장하고, 새 매니페스트의 시퀀스 번호가 그 값보다 작거나 같으면 거부한다.

단조 증가 카운터의 구현은 일견 단순해 보이지만 미묘한 함정이 있다. 첫째, NVM에 저장된 시퀀스 번호가 변조되어서는 안 된다. 본 표준은 이 값을 보안 NVM(secure NVM) 또는 RPMB(Replay Protected Memory Block, eMMC 5.0 이상)에 저장할 것을 권고한다. 둘째, 시퀀스 번호 자체가 매니페스트의 서명에 포함되어야 한다 — 그렇지 않으면 공격자가 시퀀스 번호만 위조한 변종을 만들 수 있다. SUIT 매니페스트는 시퀀스 번호를 매니페스트 본체에 두므로 COSE_Sign1 서명이 그것을 자동 보호한다.

시퀀스 번호의 의미는 펌웨어 버전(예: 1.2.3)과 같지 않다. 시퀀스 번호는 매니페스트 발행 순서를 나타내는 자유 형식의 uint이다. 본 표준은 시퀀스 번호로 RFC 3339 UTC의 unix 타임스탬프 또는 YYYYMMDDHHMM 형식(예: 202605141430)을 권고한다. 이 형식이면 시퀀스 번호 자체가 사람이 읽을 수 있고, 두 매니페스트 사이의 발행 순서를 즉시 알 수 있다. 만약 발행 빈도가 매우 높으면(예: 시간당 1회 이상) unix 나노초 또는 마이크로초를 사용할 수도 있다.

재생 공격(replay attack)은 다운그레이드와 비슷하지만 다르다. 재생은 동일 시퀀스 번호의 적법한 매니페스트를 시간차로 다시 주입한다. 단조 증가 카운터는 동일 시퀀스 번호도 거부하므로(엄격 > 비교), 재생도 함께 차단된다. 그러나 매니페스트가 처음 발행될 때의 첫 적법 설치는 막을 수 없으므로, 재생 공격이 실제로 효력을 가지는 시나리오는 매우 좁다. 첫 적법 설치 시점의 매니페스트가 손상된 채로 발행된 경우만이 재생의 진짜 위협이며, 이는 다음 매니페스트의 발행과 회전으로 회복된다.

8.8 OMA LwM2M 펌웨어 업데이트 객체 — Object 5

OMA(Open Mobile Alliance)의 LwM2M(Lightweight Machine to Machine) v1.2(2022년 발행)는 제약된 장치 관리 표준으로, 본 표준이 SUIT와 함께 권고하는 OTA 전송 계층이다. LwM2M은 CoAP(RFC 7252) 위에 동작하며, 객체 모델(Object Model)로 장치의 상태를 추상화한다. 그중 Object 5(Firmware Update)는 OTA 절차를 LwM2M의 어휘로 표현한다. 본 표준은 SUIT 매니페스트를 Object 5의 Package 리소스에 전달할 것을 권고한다.

LwM2M Object 5의 State 리소스(/5/0/3)는 OTA 상태 머신(state machine)을 표현한다. 0(Idle)은 펌웨어 갱신이 진행 중이지 않은 평상 상태이다. 1(Downloading)은 페이로드를 받는 중이다. 2(Downloaded)는 페이로드를 모두 받았고 검증을 시작하는 단계이다. 3(Updating)은 검증을 통과한 페이로드를 비활성 파티션에 기록 중이거나 부팅 전환을 기다리는 상태이다. 본 표준은 각 상태 사이의 전환 조건을 SUIT 매니페스트의 명령 시퀀스로 표현할 것을 권고한다.

Update Result 리소스(/5/0/5)는 OTA가 끝난 후의 결과를 표현하는 단일 uint이다. 0(Initial)·1(Success)·2(Not enough flash)·3(Out of RAM)·4(Connection lost)·5(Integrity check failure)·6(Unsupported package type)·7(Invalid URI)·8(Firmware update failed)·9(Unsupported protocol). 본 표준은 5(Integrity check failure)를 SUIT 매니페스트 서명 불일치 또는 SHA-256 다이제스트 불일치 시 사용할 것을 권고한다. 8(Firmware update failed)은 설치 후 부팅 실패 시 사용하며, A/B 자동 복귀가 일어났음을 의미한다.

B 스마트홈 통합 관리자는 LwM2M Object 5를 운용한 5년 경험을 기반으로 다음을 권고하였다. State 리소스의 변화를 감시하면 펌웨어 배포의 단계별 통계를 즉시 얻을 수 있다. 예컨대 1(Downloading)에서 2(Downloaded)로의 전환율이 80% 이하라면 페이로드 다운로드 채널의 안정성에 문제가 있다는 신호이다. 2에서 3으로의 전환율이 95% 이하라면 무결성 검증에서 거부되는 비율이 높다는 의미이며, 매니페스트 서명 인프라 점검이 필요하다. 3에서 1(Success)로의 전환율이 90% 이하라면 새 펌웨어 자체의 안정성 문제이며, 카나리 배포(canary rollout) 절차로 회귀해야 한다.

8.9 본 표준 ENUM과 부팅 검증 의사 코드

본 표준의 OTA 검증 절차는 본 표준의 기본 암호 스위트와 정합되어야 한다. 시뮬레이터 패널 2의 ENUM 모음에서 권고하는 스위트는 다음과 같다.

• TLS_AES_128_GCM_SHA256 — OTA 메타데이터 전송 채널의 기본 스위트(CoAPs over DTLS 1.3).
• TLS_AES_256_GCM_SHA384 — 페이로드 전송 채널의 강한 스위트(고가치 페이로드).
• TLS_CHACHA20_POLY1305_SHA256 — AES 가속이 없는 8비트/16비트 MCU의 폴백 스위트.
• X25519 — DTLS 1.3 핸드셰이크 키 교환의 기본 곡선.
• ed25519 — SUIT 매니페스트 COSE_Sign1 서명의 기본 알고리즘(COSE alg = -8).

// 부팅 시 SUIT 매니페스트 검증 의사 코드(C 의사 코드)
typedef enum {
    BOOT_OK = 0,
    BOOT_ROOT_INVALID,
    BOOT_MANIFEST_SIG_FAIL,
    BOOT_PAYLOAD_HASH_FAIL,
    BOOT_DOWNGRADE_BLOCKED,
    BOOT_VENDOR_ID_MISMATCH,
    BOOT_FALLBACK_TRIGGERED
} boot_result_t;

boot_result_t verify_and_boot(const uint8_t *manifest, size_t mlen,
                              const uint8_t *payload, size_t plen) {
    /* 1단계: root.json의 신뢰 앵커로 매니페스트 서명 검증(Ed25519) */
    if (!cose_sign1_verify(manifest, mlen, &root_pubkey)) {
        return BOOT_MANIFEST_SIG_FAIL;
    }
    /* 2단계: 단조 증가 카운터 검사(NVM에 저장된 직전 시퀀스) */
    uint32_t seq = suit_get_sequence_number(manifest);
    uint32_t prev = nvm_read_last_sequence();
    if (seq <= prev) {
        return BOOT_DOWNGRADE_BLOCKED;
    }
    /* 3단계: 공급업체 ID와 클래스 ID 매칭 */
    if (!suit_match_vendor_class(manifest, MY_VENDOR_ID, MY_CLASS_ID)) {
        return BOOT_VENDOR_ID_MISMATCH;
    }
    /* 4단계: 페이로드 SHA-256 다이제스트 재계산 후 비교 */
    uint8_t computed[32], expected[32];
    sha256(payload, plen, computed);
    suit_get_image_digest(manifest, expected);
    if (memcmp(computed, expected, 32) != 0) {
        return BOOT_PAYLOAD_HASH_FAIL;
    }
    /* 5단계: 비활성 파티션에 페이로드 기록 + 부트 플래그 전환 */
    flash_write_inactive_partition(payload, plen);
    nvm_write_last_sequence(seq);
    bootloader_set_next_active(get_inactive_partition_id());
    /* 6단계: 워치독 등록 + 재부팅 — 5분 내 정상 보고 없으면 자동 복귀 */
    watchdog_register_rollback_timer(WATCHDOG_5_MINUTES);
    system_reboot();
    return BOOT_OK;  /* 도달 안 함 */
}

위 의사 코드의 핵심 정합은 다음과 같다. (a) 1단계의 root 키 검증이 본 장의 4종 메타데이터 모델과 정합한다. 실제로는 root.json → snapshot.json → timestamp.json → targets.json 체인을 모두 검증한 후에야 매니페스트 서명을 검증하지만, 의사 코드에서는 root_pubkey로 단순화하였다. (b) 2단계의 단조 증가 카운터는 본 장 8.7 절의 다운그레이드 차단과 정합한다. (c) 4단계의 SHA-256 검증은 RFC 9019의 image-digest 클레임과 정합한다. (d) 5단계의 A/B 파티션 전환과 6단계의 워치독은 본 장 8.6 절의 anti-bricking 모델과 정합한다.

의사 코드의 boot_result_t ENUM은 LwM2M Object 5의 Update Result 리소스에 매핑된다. BOOT_MANIFEST_SIG_FAIL과 BOOT_PAYLOAD_HASH_FAIL은 LwM2M 5(Integrity check failure)로, BOOT_DOWNGRADE_BLOCKED와 BOOT_VENDOR_ID_MISMATCH는 LwM2M 8(Firmware update failed)로 매핑되며, BOOT_FALLBACK_TRIGGERED는 별도의 사용자 정의 코드(10 이상)로 표현된다. 이 매핑이 표준 간 합성을 가능케 하여, LwM2M으로 장치를 관리하는 운영자는 SUIT 매니페스트 내부 사정을 모른 채도 통계를 얻을 수 있다.

8.10 CWT 기반 매니페스트 — 제 4 장 봉투와의 합성

본서 제 4 장(봉투 계층)에서 정의한 CWT(CBOR Web Token, RFC 8392) 봉투는 인증 토큰의 컨테이너이다. SUIT 매니페스트도 CBOR 객체이며 COSE_Sign1로 서명된다. 두 모두 CBOR(RFC 8949)과 COSE 서명 규약(RFC 9052)을 공유하므로, 한 장치의 SUIT 검증 코드와 CWT 검증 코드가 같은 파서·검증 라이브러리를 재사용할 수 있다. 본 표준은 이 재사용을 적극 권고한다. 임베디드 장치의 코드 크기는 보안의 첫 적이며, 같은 알고리즘을 두 벌로 가지면 그만큼 공격 표면이 늘어난다.

CWT와 SUIT의 차이는 의미에 있다. CWT의 클레임은 주체(subject)·발급자(issuer)·만료(expiration) 같은 인증 정보를 담는다. SUIT의 클레임은 페이로드 다이제스트·시퀀스 번호·명령 시퀀스 같은 업데이트 정보를 담는다. 그러나 두 모두 동일한 COSE_Sign1 구조에 들어가며, 동일한 Ed25519 또는 ECDSA P-256 검증 코드로 처리된다. 본 표준은 모든 임베디드 장치에 적어도 Ed25519를 의무화한다 — ECDSA P-256은 선택 사항이다.

본 표준의 봉투 계층과 SUIT 매니페스트의 합성은 신뢰 부트스트랩에서 가장 명확하다. 공장 출하 시 박힌 단일 root 공개키가 SUIT root.json을 검증하고, root.json이 위임한 targets 키가 SUIT 매니페스트를 검증한다. 동시에 같은 root 공개키가 본서 제 4 장의 CWT 봉투에 담긴 ID 토큰의 서명자를 검증한다. 즉, OTA와 인증이 단 하나의 root 신뢰 앵커를 공유한다. 이 공유는 신뢰 모델을 단순화하고, 키 회전 시 OTA와 인증이 동시에 일관성을 유지하게 한다.

RFC 9023(TEEP, Trusted Execution Environment Provisioning, 2024 발행)은 SUIT를 TEE(Trusted Execution Environment) 안에서 동작시키기 위한 프로비저닝 프로토콜이다. ARM TrustZone·Intel SGX·RISC-V Keystone 같은 TEE를 갖춘 장치라면, SUIT 매니페스트의 검증과 페이로드 설치를 TEE 내부에서 수행한다. 본 표준은 TEE 가용 장치에 대해 TEEP를 적극 권고한다 — TEE는 부트로더 자체의 무결성도 함께 보장하므로, NIST SP 800-193의 RoT 요구사항을 자연스럽게 충족한다.

8.11 운영 사례와 카나리 배포

OTA가 표준대로 구현되어도 실제 운영에서는 카나리 배포(canary rollout)가 필수이다. 카나리 배포는 새 펌웨어를 전체 장치 군집의 1~5%에만 먼저 배포하고, 일정 시간(보통 24~72시간) 동안 안정성 지표를 관측한 후 단계적으로 100%까지 늘리는 전략이다. 본 표준은 LwM2M Object 5의 State 리소스 통계를 카나리 게이트(canary gate)의 1차 신호로 사용할 것을 권고한다.

카나리 배포의 단계는 일반적으로 다음과 같다. 1단계 1%(24시간 관측) → 2단계 5%(24시간) → 3단계 25%(24시간) → 4단계 50%(24시간) → 5단계 100%. 어느 단계에서 부팅 실패율·다운로드 실패율·무결성 검증 실패율이 임계치를 초과하면 자동 중단(automatic halt)되고, 운영자가 수동으로 원인을 분석한 후 재개한다. 본 표준은 부팅 실패율 임계치를 1%로 권고한다 — 정상적인 새 펌웨어는 99% 이상이 첫 부팅에 성공해야 한다.

한 OTA 운영 책임자는 카나리 배포 도입 전과 후의 사고율을 다음과 같이 회고하였다. 도입 전에는 분기당 평균 1.5건의 대규모 펌웨어 사고가 있었고, 각 사고당 평균 50만 대의 장치가 영향을 받았다. 도입 후에는 분기당 평균 0.2건으로 줄었고, 영향 장치 수는 평균 2만 대로 줄었다 — 100분의 1 수준. 카나리 1단계에서 발견된 사고가 5단계 100% 배포 전에 차단되었기 때문이다. 카나리 배포는 SUIT 표준 자체의 일부가 아니지만, 본 표준이 OTA 운영의 필수 절차로 권고하는 이유가 여기에 있다.

카나리 배포의 또 다른 이점은 시간대 분산이다. 일시에 100% 배포하면 모든 장치가 동시에 새 펌웨어로 부팅하면서 서버 부하가 폭증한다 — 부팅 직후 모든 장치가 텔레메트리·인증·OCSP·OTA 폴링을 동시 요청하기 때문이다. 카나리는 이 부하를 시간 축으로 분산시킨다. 본 표준은 100만 대 이상의 장치 군집을 운영하는 운영자에게 카나리 배포를 의무 권고(SHOULD)로, 1000만 대 이상의 군집에는 필수(MUST)로 권고한다.

한국 OTA·SUIT·IoT 부트스트랩 인프라 정합

한국의 IoT 보안 정책은 KISA(한국인터넷진흥원)가 2016년 발행한 「IoT 보안 가이드」와 후속 개정판(2020, 2023)에 기반한다. 이 가이드는 SUIT가 IETF에서 표준화되기 전부터 OTA의 무결성 검증과 다운그레이드 차단을 권고하였으며, 본 표준의 6축 모델과 80% 이상 정합한다. KISA는 또한 KCMVP(Korea Cryptographic Module Validation Program)를 운영하여 암호 모듈의 적합성을 검증하며, 본 표준이 권고하는 Ed25519·SHA-256·AES-128/256-GCM은 모두 KCMVP 등재 알고리즘이다.

ETRI(한국전자통신연구원)는 OneM2M 국제 표준화에 한국 측 1순위 참여 기관으로, LwM2M과 OneM2M 사이의 매핑 가이드를 다수 발행해 왔다. ETRI의 「IoT 기기 펌웨어 업데이트 보안 모델」(2022) 보고서는 본 표준이 권고하는 4종 메타데이터 분리와 임계 서명 모델을 한국 산업계에 처음 소개한 문헌이다. 본 표준은 이 보고서의 권고 사항과 정합한다.

TTA(한국정보통신기술협회)는 「IoT 보안 시험 인증 기준」(TTAS.KO-12.0345/R1, 2023)을 운영하며, 가전·자동차·의료 분야의 IoT 장치에 OTA 무결성 검증과 안티 롤백을 의무화한다. 본 표준의 단조 증가 카운터와 SHA-256 페이로드 다이제스트는 이 기준에 직접 매핑된다. NIA(한국지능정보사회진흥원)는 공공 IoT 인프라(스마트시티·디지털트윈)에서 사용되는 장치의 OTA 절차에 대한 정책 권고를 발행해 왔으며, 본 표준의 카나리 배포 단계를 공공 부문에 권고하였다.

NIPA(정보통신산업진흥원)는 한국형 IoT 인증제(K-IoT Security Certification)를 운영하며, 본 표준이 권고하는 멀티 키 OTA 모델을 등급별 요구사항으로 분류하고 있다. 등급 1(기초)은 단일 서명키 + SHA-256, 등급 2(표준)는 4종 메타데이터 분리 + 단조 증가 카운터, 등급 3(고급)은 임계 서명 + A/B 파티션 + TEEP까지 포함한다. 본 표준의 6축 모델은 NIPA 등급 3에 정합한다.

한국정보보호학회(KIISC)는 매년 「IoT 보안 워크숍」을 개최하여 OTA·SUIT·신뢰 부트스트랩의 학술 연구를 다루며, KISA·ETRI·TTA·삼성·LG·현대자동차의 연구진이 정기 참여한다. KS X ISO/IEC 30141(IoT Reference Architecture, 2018)은 한국이 채택한 IoT 참조 아키텍처 국가 표준으로, 본 표준의 OTA 계층은 30141의 "Management Function" 도메인에 매핑된다.

한국의 정보통신망법은 IoT 장치의 보안 사고 시 사업자의 통지 의무를 규정하며, OTA로 보안 패치가 가능했음에도 미적용한 경우 사업자 책임을 가중한다. 즉, 본 표준이 권고하는 자동 OTA 인프라는 단순한 기술적 권고를 넘어 한국 법제 환경에서 사업자의 법적 책임을 경감하는 의무에 가까운 절차가 된다.

한국의 가전·자동차 산업은 OTA의 1순위 채택자이다. 삼성 SmartThings는 2017년 이래 자체 OTA 인프라를 운영하며, 4종 메타데이터 분리에 가까운 모델을 사용한다. LG ThinQ는 2018년 이래 LwM2M 기반 OTA를 채택하였으며, 본 표준의 Object 5 매핑과 정합한다. 현대자동차의 차량용 OTA는 2020년 제네시스 G80에서 처음 도입되었으며, SUIT 매니페스트와 유사한 멀티 키 모델을 사용한다. SK텔레콤 ifLand·KT GiGA Genie·LG U+ 스마트홈은 가정용 IoT 허브의 OTA를 운영하며, 본 표준의 카나리 배포 단계를 자체 운영 절차에 반영하고 있다.

OneM2M(한국 참여)은 한국 ETRI가 글로벌 표준화에 1순위 참여하는 IoT 플랫폼 표준이며, 그 펌웨어 업데이트 영역은 본 표준의 SUIT 매핑과 호환된다. OneM2M의 firmware 자원은 LwM2M Object 5와 유사한 구조로, 본 표준의 검증 절차가 그대로 적용된다.

8.12 결론과 다음 단계

본 장은 TLS Lite 표준의 OTA와 신뢰 목록 부트스트랩 모델을 6축으로 정리하였다. (1) RFC 9019/9124/9491 SUIT 아키텍처 채택, (2) TUF 학술 모델 기반 멀티 키 위협 분석, (3) 4종 메타데이터(root·targets·snapshot·timestamp) 분리와 임계 서명, (4) 단조 증가 카운터로 다운그레이드·재생 차단, (5) A/B 파티션 부팅과 워치독 기반 anti-bricking, (6) LwM2M Object 5와 본 표준 봉투 계층의 합성. 이 6축은 NIST SP 800-193, ARM PSA Firmware Update, IEEE 802.1AR DevID, ISO/IEC 30141을 종합하여 구성된 종합 방어 모델이다.

다음 단계로 운영자는 다음 점검 항목을 권고받는다. (a) 공장 출하 시 박히는 root 공개키의 임계 서명 절차가 운영되는가, (b) 키 회전 절차가 4등급별로 문서화되어 있는가, (c) A/B 파티션 모델이 가능한 ROM 용량인가(불가하면 단순 모델 + 공장 초기 펌웨어), (d) LwM2M Object 5의 State 리소스 통계가 카나리 게이트의 신호로 사용되는가, (e) 한국 운영자라면 KCMVP·TTAS.KO-12.0345·KS X ISO/IEC 30141과의 정합이 점검되었는가.

본 표준의 SUIT 매니페스트 의사 코드와 부팅 검증 의사 코드는 본서 GitHub 저장소의 reference implementation에서 실제 C 코드로 제공된다. ARM Cortex-M4(STM32L4)·ESP32·RISC-V GD32 세 플랫폼에서 검증되었으며, Ed25519 검증은 ed25519-donna 라이브러리를, SHA-256은 mbedTLS를, CBOR/COSE는 NanoCBOR/CoseLib를 사용한다. 코드 크기는 부트로더 포함 약 28KB이며, 검증 시간은 ARM Cortex-M4 80MHz에서 평균 340ms(매니페스트 검증 110ms + SHA-256 230ms / 64KB 페이로드)이다.