보안은 기능이 다 돌아간 뒤 프로젝트 막바지에 붙여도 될까요? 제품을 출하하면 제조사의 책임도 거기서 끝날까요? EU 사이버복원력법(Cyber Resilience Act, 이하 CRA)은 두 질문에 모두 “아니오”라고 답합니다. 제조사는 제품의 사이버보안 위험을 평가해 그 결과를 기획, 설계, 개발, 생산, 납품, 유지보수 단계에 반영해야 하고(제13조 제2항), 출시 뒤에도 지원 기간 동안 취약점을 처리해야 합니다(제13조 제8항).
그렇다면 개발 현장에서는 언제, 무엇을 정해야 할까요? 펌웨어 서명 키는 어디에 두고, 생산 라인에서는 기기마다 다른 키를 어떻게 넣으며, 폐기하는 기기의 자격 증명은 어떻게 무효로 만들까요?
이 글은 연결 기기 하나가 설계되어 폐기될 때까지의 순서를 따라, CRA가 요구하는 것과 그 요구를 구현하는 기술 수단을 짝지어 정리합니다. CRA의 적용 범위와 일정, 보고 의무는 EU 사이버복원력법(CRA) 이해하기에서 다뤘으므로 여기서는 반복하지 않습니다.
1. 보안을 마지막에 붙이기 어려운 이유
CRA의 제품 요구사항은 첫 문장부터 개발 과정을 겨냥합니다. 디지털 요소가 있는 제품은 위험에 맞는 적절한 수준의 사이버보안을 갖추도록 설계, 개발, 생산되어야 합니다(부속서 I 제1부 제1항). 집행위원회 FAQ는 위험 평가가 설계와 개발 단계의 위험 식별, 분석, 평가로 끝나지 않고, 생산, 납품, 유지보수 단계에서 실행하는 위험 처리 대책까지 아우른다고 설명합니다(FAQ 4.1.1).
기술 문서도 같은 방향을 가리킵니다. 제조사는 출시 전에 기술 문서를 작성해야 하는데(제13조 제12항), 여기에는 시스템 아키텍처를 포함한 설계와 개발 정보, 생산과 모니터링 공정 및 그 공정의 검증에 관한 정보, 업데이트를 안전하게 배포하려고 고른 기술 수단의 설명이 들어갑니다(부속서 VII 제2항). 생산 공정과 업데이트 배포 구조까지 설명해야 한다면, 그 결정은 개발 막바지가 아니라 아키텍처를 정할 때 내려야 합니다.
하드웨어는 사정이 더 분명합니다. 소프트웨어 결함은 보안 업데이트로 고칠 수 있지만, 고쳐 쓸 수 없게 만든 부트 코드나 보드 설계의 결함은 출시 뒤에 바로잡기 어렵습니다. 집행위원회 FAQ도 특히 하드웨어 제품에서 매우 큰 위험을 주는 취약점을 적절히 해결하지 못하는 경우를 들며, 예외적이겠지만 제조사가 제품을 회수해야 할 수도 있다고 설명합니다(FAQ 4.3.4).
그렇다고 CRA가 특정 기술을 정해 주지는 않습니다. 요구사항은 목표 중심이고 기술 중립적이며, 어떤 수단으로 구현할지는 제조사가 위험 평가에 따라 정해 기술 문서에 적습니다(FAQ 4.2.1). 아래에서 다루는 기술 수단도 법이 요구하는 목록이 아니라, 연결 기기에서 그 요구를 충족할 때 흔히 쓰는 방법입니다.
2. 위험 평가가 부품 선정보다 먼저입니다
“와이파이로 통신을 암호화하는데 무엇이 더 필요할까요?” 개발 초기에 자주 나오는 질문입니다. 와이파이 보안은 기기와 무선 접속 지점 사이의 통신을 보호합니다. 하지만 기기에서 도는 펌웨어가 진짜인지 확인하지 않고, 기기에 저장된 키를 지켜 주지 않으며, 클라우드 서비스에 기기의 신원을 증명해 주지도 않습니다. CRA는 위험 평가 결과 해당하는 경우 전송 중인 데이터뿐 아니라 저장된 데이터의 기밀성, 프로그램과 설정의 무결성, 무단 접근 차단까지 요구합니다(부속서 I 제1부 제2항 (d), (e), (f)). 이런 보호는 기기 안에 있어야 합니다.
그래서 부품을 고르기 전에 위험부터 평가합니다. 평가는 다음 질문으로 정리됩니다.
- 이 기기는 무엇에 쓰는가
- 어떤 데이터를 다루며, 그 데이터는 얼마나 민감한가
- 무엇과 연결되는가
- 공격자가 이 기기를 장악하면 무엇을 얻고, 어떤 피해가 생기는가
CRA가 요구하는 위험 평가도 같은 내용을 담습니다. 의도된 용도와 합리적으로 예견할 수 있는 사용, 운영 환경과 보호할 자산 같은 사용 조건, 제품이 쓰일 기간을 고려해 위험을 분석하고, 부속서 I 제1부 제2항의 요구가 저마다 제품에 적용되는지, 적용된다면 어떻게 구현하는지 밝혀야 합니다. 평가는 문서로 남기고 지원 기간 동안 필요에 따라 갱신합니다(제13조 제3항). 적용되지 않는 요구가 있다면 그 근거를 기술 문서에 분명히 적습니다(제13조 제4항).
평가 결과는 뒤따르는 모든 결정의 크기를 정합니다. 민감하지 않은 환경 측정값만 보내는 센서와 개인 정보나 안전 관련 데이터를 다루는 기기는 위협도, 필요한 보호 수준도 다릅니다. 평가가 부정확하면 보호가 모자라 요구사항을 충족하지 못하거나, 반대로 효과 없이 원가만 늘어납니다. 법은 평가 방법론을 정해 두지 않았으므로 제조사가 고를 수 있지만, 위협 모델은 제품의 의도된 용도와 예견할 수 있는 사용에 맞아야 합니다(FAQ 4.1.2). ISO/SAE 21434의 TARA로 위협과 위험을 분석해 온 자동차 업계의 경험이 여기서 쓸모가 큽니다. 다만 차량 형식승인 규정 (EU) 2019/2144가 적용되는 제품에는 CRA가 적용되지 않습니다(제2조 제2항 (c)). 자동차 부품 회사라도 범용 부품이나 산업용 기기는 대상이 될 수 있으며, 그 경계는 앞선 글 7장에서 다뤘습니다.
3. 기기 보안의 네 가지 기본 요소
기기 수준의 보안은 네 가지 기본 요소로 나눠 볼 수 있습니다(참고 문헌 4). 이 글에서 다루는 구현에서는 앞의 세 요소가 주로 비대칭 키 쌍에 기댑니다(대칭 키로 만든 메시지 인증 코드, 곧 MAC으로 검증하는 방식도 있습니다). 개인 키로 서명한 데이터는 공개 키를 가진 누구나 검증할 수 있으므로, 기기는 자기 신원을 증명하고 데이터가 바뀌지 않았음을 증명할 수 있습니다. 이 구조에서 가장 중요한 전제는 개인 키가 드러나지 않는 것이고, 검증에 쓰는 공개 키도 바뀌지 않게 지켜야 합니다.
| 요소 | 하는 일 | 없으면 생기는 일 | 주로 관련된 CRA 요구(부속서 I 제1부 제2항) |
|---|---|---|---|
| 신뢰 부팅 체인(보안 부팅) | 바꿀 수 없는 첫 부트 단계가 부트로더의 서명을, 부트로더가 응용 프로그램의 서명을 확인한 뒤 실행 | 공격자가 올린 펌웨어가 기동 때 실행되어 기기를 사실상 장악 | (f) 프로그램 무결성 |
| 펌웨어 무결성 | 업데이트 이미지가 정당한 제조사에서 왔고 전송 중 바뀌지 않았는지 설치 전에 서명으로 확인 | 변조된 업데이트가 경고 없이 설치되어 실행 | (c) 보안 업데이트, (f) 무결성 |
| 키 보호 | 암호 키를 읽거나 복사하거나 바꿀 수 없게 보관 | 그 키가 지키는 모든 기능이 함께 무너짐(기기 사칭, 통신 복호화, 위조 서명) | (d) 무단 접근 방지, (e) 기밀성, (f) 무결성 |
| 민감 데이터 암호화 | 위험 평가가 민감하다고 본 데이터를 저장 상태와 전송 중 모두 암호화 | 데이터를 가로채거나 빼낼 수 있음 | (e) 기밀성 |
오른쪽 칸은 각 요소가 주로 뒷받침하는 요구를 짚은 것입니다. 법은 이 요소들을 이름으로 요구하지 않으며, 적용 여부와 방법은 위험 평가로 정합니다. 특히 암호화는 조건부여서, 암호화할 만한 데이터를 다루지 않는 기기도 있습니다. 참고로 소비자 IoT 기기의 기본 보안 표준인 ETSI EN 303 645는 보안 부팅으로 소프트웨어를 검증하도록 권고하고, 그 설명에서 하드웨어 신뢰 기점을 한 가지 수단으로 듭니다(5.7-1).
네 요소는 서로 맞물립니다. 신뢰 부팅은 서명을 검증할 믿을 만한 키가 있어야 성립하므로 키 보호에 기댑니다. 펌웨어 무결성 검사도 검사하는 부트 코드가 이미 변조됐다면 아무것도 증명하지 못하므로 신뢰 부팅에 기댑니다. 암호화한 데이터도 키를 꺼낼 수 있다면 이름만 보호받는 셈입니다. 한 요소가 약하면 그 요소에 기대는 다른 요소도 함께 약해지므로, 네 요소는 따로따로 붙이지 말고 설계 단계에서 하나의 구조로 정해야 합니다.
여기에 생산 단계의 과제가 하나 더 붙습니다. 기기마다 고유한 신원을 넣는 프로비저닝입니다. 이것이 없으면 현장에서 기기를 인증하고, 등록하고, 관리할 수 없습니다. 6절과 7절에서 다룹니다.
4. 키를 어디에 둘까: 위험에 맞춘 하드웨어 보호
네 요소는 모두 비밀로 남는 키에 기댑니다. 그렇다면 키는 보드의 어디에 두어야 할까요?
플래시 메모리에 둔 키는 켜진 채 남은 디버그 인터페이스로 읽히거나, 펌웨어 취약점으로 새어 나가거나, 메모리를 물리적으로 분석해 복원될 수 있습니다. RAM에 둔 키는 메모리 내용을 흘리는 코드 결함 하나에 노출될 수 있습니다. 응용 소프트웨어가 주소로 접근할 수 있는 메모리에 키가 있다면, 그 소프트웨어를 장악한 공격자도 결국 그 키에 닿을 수 있습니다.
어디까지 막아야 할지는 2절의 위험 평가가 정합니다. CRA는 필수 요구사항을 제품의 위험에 비례해 구현하게 합니다(FAQ 3.3). 키가 지키는 기능이 중요하거나 공격자가 기기를 손에 넣을 수 있는 제품이라면, 키를 소프트웨어가 닿지 않는 하드웨어에 두는 편이 안전합니다. 위험이 낮은 제품이라면 더 단순한 보호로 충분할 수도 있으며, 그 판단과 근거는 위험 평가에 남깁니다.
하드웨어 보호의 대표적인 형태가 보안 요소(secure element)입니다. 키를 만들고 보관하고 내부에서 암호 연산을 하는 전용 칩으로, 호스트 MCU는 키로 연산을 해 달라고 요청할 수 있지만 키를 읽어 내는 명령은 없습니다. 자동차 ECU 개발자에게는 MCU에 내장된 하드웨어 보안 모듈(HSM, 이하 내장 보안 모듈)이 더 익숙할 것입니다. ETSI EN 303 645도 민감한 보안 파라미터를 안전하게 저장하는 수단으로 신뢰 실행 환경(TEE), 하드웨어에 묶인 암호화 저장소, 보안 요소, 전용 보안 부품 등을 듭니다(5.4-1). 어떤 형태를 고르든 다음 세 가지를 확인합니다.
- 보호된 키 저장: 개인 키를 보호 영역 안에서 만들고 밖으로 내보내지 않는가
- 암호 엔진: 서명, 검증, 키 합의를 호스트가 아니라 보호 영역 안에서 실행하는가
- 하드웨어 난수 생성기: 키를 만들 때 하드웨어에서 얻은 난수를 쓰는가. 시작 상태(시드)를 짐작할 수 있는 소프트웨어 의사 난수 생성기로 만든 키는 예측될 수 있습니다.
외장 보안 요소는 보통 I2C 같은 직렬 버스로 호스트 MCU와 연결됩니다. 그런데 비밀을 밖으로 내보내지 않게 만든 보안 요소와 어떻게 쓸모 있게 통신할까요? 답은 챌린지-응답입니다. 호스트가 챌린지, 곧 보안 요소가 내부 키로 처리해야 하는 데이터를 보내면, 맞는 키를 가진 보안 요소만 올바른 응답을 계산할 수 있습니다. 호스트는 그 응답을 검증하고, 키는 버스를 건너가지 않습니다. 필요하면 버스 통신 자체도 암호화할 수 있습니다.
호스트 쪽에도 조건이 하나 있습니다. 기동 때 가장 먼저 실행되는 코드는 공격자가 바꿀 수 없어야 합니다. 첫 단계를 고쳐 쓸 수 있다면 그 뒤의 모든 검증이 의미를 잃기 때문입니다. 그래서 호스트 MCU가 변경할 수 없는 부트 ROM을 갖췄는지가 부품 선정의 점검 항목이 됩니다. 부트 ROM이 신뢰 체인의 시작을 붙잡고, 보안 요소가 그 체인이 쓰는 키를 지킵니다.
구조를 고를 때는 장단점도 따집니다. 외장 보안 요소를 호스트 MCU와 분리해 두면, 다음 개정에서 MCU 공급사를 바꾸더라도 같은 보안 요소와 프로비저닝 체계를 이어 쓸 수 있습니다. 대신 부품이 하나 늘어나는 만큼 원가와 보드 면적을 따져야 합니다. 내장 보안 모듈은 부품을 늘리지 않지만, MCU를 바꾸면 키 관리 방식도 함께 다시 검토해야 할 수 있습니다. 제품 수명이 길고 하드웨어 개정이 여러 번 예정된 제품일수록 신뢰 기점을 프로세서 선택과 떼어 두는 이점이 커집니다.
이미 출시한 제품에 보안 요소를 덧붙일 수 있을까요? 외장 보안 요소는 버스로 붙이고 라이브러리를 기존 펌웨어에 넣으면 되므로, 가능한 경우도 있습니다. 다만 호스트 MCU에 변경할 수 없는 부트 단계가 없으면 신뢰 체인을 완성할 수 없고, 완성된 보드에는 보안 요소를 놓을 자리가, 꽉 찬 플래시 메모리에는 새 코드를 넣을 자리가 없을 수 있습니다. 그래서 새 프로젝트는 첫 아키텍처 논의부터 보안을 넣고, 기존 제품은 다음 설계 개정을 기회로 삼는 편이 현실적입니다.
참고로 보안 요소는 CRA의 핵심 제품(부속서 IV), 보안 기능이 있는 MCU는 중요 제품(부속서 III) 범주에 들어갑니다. 그렇다고 이런 부품을 넣은 완제품까지 그 등급의 적합성 평가 절차를 따르게 되지는 않습니다. 등급은 완제품의 핵심 기능으로 정합니다(제7조 제1항, FAQ 3.2).
5. 소프트웨어 개발: 서명된 코드 안의 결함 줄이기
보안 부팅은 서명된 코드만 실행되게 할 뿐, 서명된 코드 안의 결함까지 막아 주지는 않습니다. 정상적으로 서명한 펌웨어에 버퍼 오버플로가 있다면 그 결함도 함께 실행됩니다. 그래서 하드웨어 보호와 함께 소프트웨어를 만드는 과정에도 보안 활동을 넣어야 합니다. CRA는 위험 평가 결과 해당하는 경우 알려진 악용 가능한 취약점 없이 출시하고(부속서 I 제1부 제2항 (a)), 외부 인터페이스를 포함한 공격 표면을 제한하며((j)), 적절한 악용 완화 기법으로 사고의 영향을 줄이도록((k)) 요구합니다. 보안을 효과적이고 정기적으로 시험하고 검토하는 일은 지원 기간 내내 지켜야 하는 취약점 처리 요구에 들어 있습니다(제2부 제3항).
개발 단계별로 할 일을 CRA 요구와 짝지으면 다음과 같습니다. 제3자 부품 실사(제13조 제5항), SBOM 작성(부속서 I 제2부 제1항), 시험 보고서(부속서 VII 제6항)는 법이 직접 정한 항목입니다. 코드 리뷰, 정적 분석, 퍼징 같은 구체 기법은 법이 이름으로 요구하지 않으므로, 어떤 기법을 어디까지 쓸지는 위험 평가로 정합니다.
| 단계 | 할 일(예) | 주로 관련된 CRA 요구 |
|---|---|---|
| 요구와 설계 | 위협 분석으로 보안 요구사항을 정하고, 외부 인터페이스와 서비스, 권한을 꼭 필요한 만큼만 둠 | 제13조 제2항, 부속서 I 제1부 제2항 (j) |
| 구현 | 시큐어 코딩 규칙을 따르고, 쓰지 않는 코드를 지우고, 스택 보호 같은 컴파일러 보안 옵션과 메모리 보호 기능을 켬 | 부속서 I 제1부 제2항 (k) 악용 완화 기법 |
| 구성 요소 관리 | 오픈소스와 제3자 부품을 실사하고, 빌드할 때 SBOM을 만듦 | 제13조 제5항, 부속서 I 제2부 제1항 |
| 검증 | 코드 리뷰와 정적 분석, 퍼징과 침투 시험으로 취약점을 찾고, 결과를 시험 보고서로 남김 | 부속서 I 제2부 제3항, 부속서 VII 제6항 |
| 출시 전 확인 | SBOM을 알려진 취약점 정보와 대조하고, 찾은 취약점이 실제 운영 조건에서 악용될 수 있는지 판단 | 부속서 I 제1부 제2항 (a)(FAQ 4.2.2) |
소비자 IoT 표준 ETSI EN 303 645도 비슷한 항목을 권고합니다. 쓰지 않는 코드는 지우고(5.6-6), 소프트웨어는 필요한 최소 권한으로 실행하며(5.6-7), 메모리 접근을 하드웨어 수준에서 제어하는 장치를 갖추라고 합니다(5.6-8). 그리고 버전 관리를 쓰고 스택 보호 같은 컴파일러 보안 옵션을 켜는 일을 예로 들며 시큐어 개발 절차를 따르도록 권고합니다(5.6-9). 조직 전체의 틀이 필요하다면 미국 NIST의 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)를 참고할 만합니다. SSDF는 시큐어 개발 활동을 조직 준비, 소프트웨어 보호, 안전한 소프트웨어 생산, 취약점 대응의 네 묶음으로 정리합니다.
빌드 환경도 지켜야 할 대상입니다. SSDF는 개발, 빌드, 시험 환경을 안팎의 위협에서 보호하고(PO.5), 소스 코드와 실행 코드를 무단 접근과 변조에서 보호하며(PS.1), 받는 쪽이 배포된 소프트웨어의 무결성을 확인할 수 있게 하라고 권합니다(PS.2). 8절에서 다룰 서명 키 보관도 같은 맥락입니다. 자동차 소프트웨어 개발에서 이미 쓰는 코딩 규칙, 정적 분석, 보안 시험 체계는 여기서도 쓸모가 큽니다.
6. 시제품에서 신원 구조를 먼저 확인합니다
프로비저닝은 기기마다 고유한 암호 신원, 곧 키와 인증서를 넣는 과정입니다. 칩 제조사의 공장에서, 제품 생산 라인에서, 또는 현장에서 원격으로 할 수 있습니다. 인증서는 공개 키를 기기 일련번호 같은 신원에 묶고, 그 묶음을 신뢰받는 인증기관(CA)이 서명한 것입니다. 기기는 인증서로 자기 공개 키가 정말 자기 것임을 다른 시스템에 증명합니다.
아키텍처를 확정하기 전에는 평가 보드로 직접 해 보는 편이 빠릅니다. 일부 보안 요소는 칩 공장에서 개인 키를 칩 안에서 만들고 그에 맞는 기기 인증서를 미리 넣어 출하합니다. 이런 보안 요소를 쓰면 키 생성과 인증서 기반 시설을 먼저 갖추지 않고도 첫 연결부터 인증된 통신을 시험할 수 있어, 평가 시간을 기반 시설이 아니라 응용 프로그램에 쓸 수 있습니다.
양산을 약속하기 전에 다음 네 가지를 확인합니다.
- 호스트 MCU에서 보안 요소를 인증해 챌린지-응답 흐름이 실제로 동작하는지
- 미리 넣은 기기 인증서로 서버나 클라우드에 처음 연결해, 양산 기기가 쓸 초기 연결 경로가 동작하는지
- 응용 프로그램에 어떤 키와 인증서가 필요하고, 각각 어디에 둘지
- 서명한 펌웨어 이미지를 실제로 쓸 부트 경로에서 검증해, 호스트 플랫폼이 신뢰 체인의 시작을 붙잡을 수 있는지
이 시험의 더 큰 가치는 구조가 이어진다는 데 있습니다. 평가 보드에서 확인한 신원 모델, 곧 공장에서 넣은 자격 증명으로 기기를 서비스에 처음 연결하는 방식은 양산 제품이 쓸 모델과 같습니다. 이 단계에서 검증해 두면 양산으로 넘어갈 때 구조를 다시 짜지 않고 기기 수와 그 뒤의 기반 시설을 늘리는 데 집중할 수 있습니다.
7. 생산 라인도 보안 설계의 일부입니다
생산 환경은 신뢰 경계 밖에 있습니다
시제품 한 대에 키를 넣는 일은 책상 위 작업입니다. 생산 라인에서 수천 대에 넣는 일은 성격이 다릅니다. 둘의 차이는 다음과 같습니다.
| 구분 | 시제품 | 양산 |
|---|---|---|
| 규모 | 한 대 | 수천 대 이상 |
| 키 다루기 | 개발자가 직접 | 자동화된 프로비저닝 |
| 환경 | 개발자의 작업대 | 위탁 생산사, 시험 공정, 공장 네트워크 |
| 인증서 | 칩 공장에서 넣은 인증서, 시험용 인증서 | 제조사 인증기관(CA)으로 이어지는 양산 인증서 |
| 관리 | 로컬 디버깅 | 출하한 기기 전체의 수명주기 관리 |
인증서로 기기를 인증하는 구조라면 양산 기기는 한 대 한 대가 자기 키와 인증서를 가져야 하고, 기기 인증서가 클라우드나 서버가 믿는 인증기관까지 이어져야 상대가 그 기기를 믿을 수 있습니다. 흔한 구성은 양산 인증서를 제조사가 관리하는 인증기관으로 이어지게 하는 것이고, 그러면 어떤 기기에 신원을 내줄지 제조사가 직접 정할 수 있습니다. 기기 인증서는 발급 기관이 서명하고, 발급 기관의 인증서는 그 위 기관이 서명해, 최종적으로 상대 시스템이 이미 신뢰하는 루트 CA에 닿습니다. 이 인증기관과 인증서, 관리 절차를 묶어 공개 키 기반 구조(PKI)라 부릅니다.
어려운 점은 이 일을 제조사가 다 통제하지 못하는 곳에서 해야 한다는 것입니다. 위탁 생산사, 시험 공정, 공장 네트워크는 제조사의 신뢰 경계 밖에 있습니다. 프로비저닝은 이들을 믿지 않고도 돌아가야 하고, 개인 키는 생산 환경에 한 번도 드러나지 않아야 합니다. 한 번 새어 나간 키는 그 키를 가진 누구에게나 인증을 내주므로, 개인 키를 드러내는 생산 공정은 같은 결함을 대량으로 찍어 냅니다. CRA가 생산 공정과 그 검증에 관한 정보를 기술 문서에 넣게 한 것(부속서 VII 제2항 (c))도 이런 맥락에서 읽을 수 있습니다.
제품군 전체가 같은 비밀번호나 같은 비밀 키를 쓰는 구조도 피합니다. ETSI EN 303 645는 공장 기본 상태가 아닌 모든 상태에서 비밀번호가 기기마다 고유하거나 사용자가 정한 것이어야 한다고 하고(5.1-1), 소스 코드에 박아 넣은 핵심 보안 파라미터를 쓰지 못하게 하며(5.4-3), 업데이트 검증과 서비스 통신 보호에 쓰는 핵심 보안 파라미터는 기기마다 고유하게 만들도록 요구합니다(5.4-4). 업데이트를 검증하는 제조사 공개 키처럼 비밀이 아닌 값은 기기마다 다를 필요가 없습니다. 이 표준은 CRA보다 먼저 나온 소비자 IoT 표준이지만, CRA의 기본 보안 설정(부속서 I 제1부 제2항 (b))과 무단 접근 방지((d))를 구현할 때 참고할 만합니다.
출하 전에는 쓰지 않는 인터페이스도 닫습니다. 켜진 채 남은 디버그 포트는 키를 읽어 내는 통로가 될 수 있고, CRA는 외부 인터페이스를 포함한 공격 표면을 제한하도록 요구합니다(부속서 I 제1부 제2항 (j)). 다만 이것도 위험에 비례해 판단합니다. 집행위원회 FAQ는 출시 뒤 켜진 채 남은 디버그 인터페이스를 발견했더라도, 봉인을 뜯고 기판에 납땜까지 해야 악용할 수 있어 위험이 매우 낮다면 취약점을 문서화하고 사용자에게 권고하는 정도로 다룰 수 있다는 예를 듭니다(FAQ 4.3.1).
키 기반 시설은 직접 지을까, 서비스로 쓸까
생산용 키 기반 시설을 갖추는 방법은 크게 두 가지입니다. 하나는 직접 구축입니다. 루트 CA의 서명 키처럼 가치가 큰 키를 드러내지 않고 만들고, 보관하고, 쓰는 변조 방지 장비인 HSM을 사서 운영해야 합니다(4절의 내장 보안 모듈도 HSM이라 부르지만, 여기서 말하는 HSM은 서버 쪽 장비입니다). 키 보관과 인증서 관리, 누가 어떤 조건에서 자격 증명을 발급할 수 있는지 정하는 사용자 관리도 만들어 제품군이 시장에 있는 동안 유지해야 합니다. 부담은 장비 구매로 끝나지 않고, 이를 계속 운영할 전문 인력도 꾸준히 필요합니다. 다른 하나는 관리형 HSM 환경과 인증서 관리를 서비스로 쓰는 방법입니다. 두 방법을 견주면 다음과 같습니다.
| 고려 항목 | 직접 구축 | 관리형 서비스 |
|---|---|---|
| HSM | 구매, 설치, 운영, 유지 | 서비스 안에서 제공 |
| PKI와 루트 CA | 직접 설계하고 관리 | 서비스에서 만들고 관리 |
| 사용자와 접근 관리 | 직접 만들고 유지 | 서비스에 포함 |
| 필요한 전문성 | 사내에 계속 필요 | 연동과 정책 결정 중심 |
| 키 보관 | 모두 회사 통제 안 | 서비스 쪽 HSM 안 |
| 물량 확대 | 기반 시설 추가 투자 | 서비스가 처리 |
직접 구축이 맞는 조직도 있습니다. 보안 엔지니어링 조직을 이미 갖췄거나, 물량이 많아 기기당 서비스 비용이 크게 쌓이거나, 키가 회사가 통제하는 기반 시설 밖으로 나가면 안 되는 데이터 주권 요건이 있는 경우입니다. 어느 쪽이든 양산하기 전에 정해야 합니다. 프로비저닝 계획 없이 공장에 도착한 기기는 보안 구조가 아직 덜 끝난 기기입니다.
8. 출시 뒤: 업데이트 서명 키는 어디에 둘까
새 펌웨어를 내보낼 때는 이미지를 개인 키로 서명하고, 기기는 들어온 이미지마다 설치 전에 서명을 검증합니다. 이때 서명 키는 빌드 서버나 개발자 노트북에 두지 않습니다. 그런 곳에 둔 키는 일반 IT 기반 시설의 보안 수준을 그대로 물려받기 때문입니다. 서명 키는 HSM 안에 두고, 정해진 사람이 정해진 절차로만 서명하게 합니다. 기기에 넣는 검증용 공개 키는 비밀일 필요는 없지만, 바뀌지 않게 보호해야 합니다(ETSI EN 303 645 5.4-1).
업데이트를 어떤 방식으로 내려보낼지는 법이 열어 두었습니다. CRA는 무선 업데이트(OTA)라는 방식을 이름으로 요구하지 않습니다. 대신 다음을 요구합니다.
- 보안 업데이트로 취약점을 고칠 수 있게 하고, 해당하는 경우 기본으로 켜진 자동 보안 업데이트와 쉬운 해제 방법, 업데이트 알림, 일시 연기 기능을 제공(부속서 I 제1부 제2항 (c))
- 기술적으로 가능하면 보안 업데이트를 기능 업데이트와 분리해 제공(제2부 제2항)
- 업데이트를 안전하게 배포하는 체계를 갖추고, 보안 업데이트는 해당하는 경우 자동으로 배포(제2부 제7항)
- 보안 업데이트를 지체 없이, 원칙적으로 무료로, 사용자 조치 안내와 함께 배포(제2부 제8항)
자동 업데이트 요구는 모든 제품에 적용되지는 않습니다. 다른 제품에 부품으로 통합되는 것을 주된 용도로 하는 제품, 그리고 전문 ICT 네트워크나 산업 환경처럼 자동 업데이트가 운영을 방해할 수 있어 사용자가 자동 업데이트를 합리적으로 기대하지 않는 제품에는 적용되지 않습니다(전문 제56항, FAQ 4.3.3). 그래도 현장에 깔린 많은 기기에 지원 기간 내내 보안 업데이트를 내려면 OTA가 현실적인 방법인 경우가 많습니다. 어떤 배포 방식을 골랐는지는 기술 문서에 적어야 하고(부속서 VII 제2항 (b)), 보안 수정만 따로 낼 수 있게 업데이트 구조를 처음부터 나눠 두는 것도 설계 단계의 일입니다.
출시 뒤 자격 증명도 현장 방문 없이 관리할 수 있게 설계해 두는 편이 좋습니다. 정해진 주기에 따라, 또는 사고 같은 사건이 생기면 기기의 키를 새것으로 바꾸고(키 교체), 새 키를 더하고, 이후 업데이트에 필요한 자격 증명을 내려보낼 수 있게 합니다. 이것은 CRA가 이름으로 요구하는 기능이 아니라 구현 수단의 하나입니다. 다만 제조사는 지원 기간 내내 취약점을 처리하고 필요한 보안 업데이트를 내야 하므로, 업데이트 서명 체계도 그만큼 오래 돌아가야 합니다. 지원 기간은 제품이 쓰일 것으로 예상되는 기간을 반영해 정하며, 원칙적으로 최소 5년입니다(예상 사용 기간이 5년보다 짧으면 그 기간, 제13조 제8항).
9. 폐기까지 처음부터 설계합니다
제품 수명의 마지막 단계도 처음부터 설계에 넣어야 합니다. CRA는 사용자가 모든 데이터와 설정을 안전하고 쉽게 영구 삭제할 수 있게 하고, 그 데이터를 다른 제품이나 시스템으로 옮길 수 있다면 안전하게 옮겨지게 하라고 요구합니다(부속서 I 제1부 제2항 (m)). 기본 보안 설정 요구에는 제품을 원래 상태로 초기화할 수 있게 하는 것도 들어갑니다((b)). 사용자에게 주는 안내에는 제품을 안전하게 폐기하는 방법과 사용자 데이터를 안전하게 지우는 방법을 담아야 합니다(부속서 II 제8항 (d)).
인증서 기반 구조에서는 이 요구가 구체적인 작업이 됩니다. 기기 인증서를 폐지(revoke)해 연결된 시스템이 더는 그 인증서를 받아들이지 않게 하고, 기기 안의 키를 무효로 만들어 다음에 하드웨어를 손에 넣는 사람에게 그 비밀이 쓸모없게 합니다. 인증서 폐지는 법 조항의 문구가 아니라 위 요구를 구현하는 수단의 하나입니다. 무엇을 지울지(자격 증명, 사용자 설정, 기록), 서버 쪽에서 폐지를 어떻게 반영할지는 설계 단계에서 정해 두어야 합니다.
지금까지의 흐름을 기기 신원의 일생으로 정리하면 다섯 단계입니다.
- 탄생: 칩 공장이나 생산 라인에서 보호된 하드웨어 안에 개인 키를 만들고 인증서를 넣습니다.
- 귀속: 기기를 제조사의 계정이나 PKI에 묶어 신원의 주인을 정합니다.
- 활성화: 고객이 처음 켤 때 그 신원으로 안전한 연결을 맺고, 응용 프로그램에 필요한 자격 증명을 받습니다.
- 유지: 사용 기간 동안 키를 교체하고 새 인증서를 받습니다.
- 폐기: 자격 증명을 폐지하고 기기를 안전한 상태로 초기화합니다.
하드웨어 보호를 고른 구조라면 어느 단계에서든 개인 키는 보호된 하드웨어 안에 머뭅니다. 기기 쪽에서는 보안 요소나 내장 보안 모듈이고, 기반 시설 쪽에서는 HSM입니다.
10. 부품과 서비스로 대신할 수 없는 것
보안 요소 같은 하드웨어 신뢰 기점과 관리형 서비스는 키 보관과 기기 신원 관리의 많은 부분을 덜어 줍니다. 그래도 5절에서 본 알려진 악용 가능한 취약점 확인과 공격 표면 제한 같은 나머지 제품 요구와 기술 문서, 적합성 평가는 여전히 제조사 몫입니다. 그중에서도 다음 두 가지는 부품을 고른다고 해결되지 않습니다.
첫째, 위험 평가입니다. 어떤 부품이나 서비스도 제품의 의도된 용도와 데이터의 민감도를 대신 정해 주지 못합니다. 2절에서 본 것처럼 평가는 문서로 남기고 지원 기간 동안 필요에 따라 갱신해야 합니다.
둘째, 취약점 처리와 보고 체계입니다. 부속서 I 제2부의 취약점 처리 요구, 곧 SBOM을 포함한 구성 요소와 취약점의 식별, 효과적이고 정기적인 보안 시험과 검토, 조정된 취약점 공개(CVD) 정책, 취약점 신고 연락처 같은 요구는 위험 평가로 골라 적용하는 것이 아니라 지원 기간 내내 모두 지켜야 합니다(FAQ 4.1.3). 실제로 악용되는 취약점과 제품 보안에 영향을 주는 중대한 사고의 보고 의무는 이미 2026년 9월 11일부터 시행 중입니다(제14조, 제71조 제2항).
하드웨어 신뢰 기점을 넣었다고 CRA 대응이 끝나지는 않습니다. 하드웨어는 각 기술 수단을 믿을 수 있게 하고, 조직의 절차는 그 수단이 지원 기간 동안 제대로 돌아가게 합니다.
11. 마무리: 지금 시작할 순서
임베디드 엔지니어는 이미 전력 예산, 발열, 보드 면적, EMC 여유 같은 제약 안에서 설계합니다. CRA는 이 목록에 사이버보안을 더합니다. EMC처럼 EU 시장에 들어가는 조건이라는 점은 같지만, 출시 뒤에도 지원 기간 내내 취약점을 처리하고 보안 업데이트를 내야 한다는 점이 다릅니다.
지금 시작한다면 다음 순서를 권합니다.
- 적용 판단과 위험 평가: 제품에 어떤 디지털 요소가 있고, 어떤 데이터를 다루며, 의도된 용도에서 어떤 위협이 나오는지 정합니다. 이 결과가 뒤따르는 모든 결정의 크기를 정합니다.
- 위험에 맞춰 신뢰 기점 정하기: 위험 평가 결과에 따라 보안 요소나 내장 보안 모듈 같은 하드웨어 보호가 필요한지, 어느 수준까지 필요한지 정합니다. 필요하다면 새 프로젝트는 첫 아키텍처 논의부터 변경할 수 없는 부트 단계와 함께 넣고, 기존 제품은 다음 설계 개정을 그 시점으로 잡습니다.
- 개발 절차에 보안 활동 넣기: 위협 분석, 시큐어 코딩 규칙, 코드 리뷰와 정적 분석, 퍼징 같은 보안 시험, 빌드 단계의 SBOM 생성을 개발 절차에 넣고 결과를 기술 문서에 남깁니다.
- 시제품에서 신원 구조 검증: 키가 미리 들어간 평가 보드 같은 수단으로 신원 구조와 서명 부팅 경로를 양산 전에 확인합니다.
- 생산 전에 프로비저닝 방식 결정: 직접 구축과 관리형 서비스를 비용, 전문성, 키 보관 주체, 물량 확대 면에서 견주어 정하고, 출하 전에 닫을 인터페이스도 정합니다.
- 수명주기 전체 계획: 업데이트 서명과 배포, 키 교체, 인증서 폐지, 폐기 때의 초기화를 고른 구조가 모두 지원하는지 첫 출하 전에 확인합니다.
마지막으로 질문 하나를 드립니다. 여러분 제품의 펌웨어 서명 키는 지금 어디에 있습니까? 누가 그 키로 서명할 수 있는지, 그 키가 새면 이미 출하한 기기를 어떻게 지킬지 바로 답하기 어렵다면, 바로 그 지점이 시큐어 개발 관점에서 CRA를 준비할 출발점입니다.
CRA의 적용 범위, 일정, 보고 의무는 EU 사이버복원력법(CRA) 이해하기: 적용 대상부터 24시간 보고 의무까지에서, 진단 인터페이스를 인증서로 잠그는 방법은 진단 서비스가 해킹 통로가 될 때: UDS 0x27에서 0x29로에서 다뤘습니다. 세온이앤에스가 CRA 대응을 어떻게 돕는지는 EU CRA 대응 컨설팅 페이지에서 확인할 수 있습니다.
참고 문헌
- Regulation (EU) 2024/2847, 디지털 요소가 있는 제품의 수평적 사이버보안 요구사항(사이버복원력법), OJ L, 2024-11-20.
- European Commission, FAQs on the Cyber Resilience Act, v1.4, 2026-09-04.
- ETSI, EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things: Baseline Requirements, 2024-09.
- Mouser Electronics, Designing for the Cyber Resilience Act: Securing Connected Devices from First Schematic to Final Decommissioning, Microchip Technology 협업 e-book, 2026-08-19 게시.
- NIST, SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, 2022-02. 1.2판(SP 800-218 Rev. 1)은 2025-12-17 초안이 공개되었으며, 2026-10-19 확인 기준 최종판은 1.1판입니다.
이 글의 법 조항과 그 해석은 2026년 10월 19일 기준 EU 공식 문서를 바탕으로 정리했으며, 법률 자문을 대신하지 않습니다. 집행위원회 FAQ는 구속력 있는 해석이 아니며, 부속서 I 제1부 제2항의 요구가 개별 제품에 적용되는지와 어떻게 구현할지는 제품별 위험 평가로 정해야 합니다. 설계에서 폐기까지의 단계 구성, 기술 수단의 설명, 비교표와 점검 목록은 참고 문헌 4의 e-book을 바탕으로 특정 제품과 무관하게 다시 정리했으며, 5절의 소프트웨어 개발 활동과 11절 3단계는 참고 문헌 1, 2, 3, 5를 바탕으로 덧붙였습니다.
관련 서비스
이 글에서 다룬 보안 부팅, 펌웨어 서명 검증, 보안 업데이트를 제품에 구현할 개발 인력이 필요하시다면, 세온이앤에스가 어떻게 맡아 진행하는지 확인해 보세요.
관련 영상
이 글의 핵심을 영상으로도 정리했습니다.