보안 요구사항은 어떻게 ECU 설계가 될까? — Clause 10

현업에서 보는 ISO/SAE 21434 04

이전 편 | TARA는 왜 자동차 보안의 출발점이 되었을까? — Clause 9

지난 편에서 TARA의 결과물들이 나왔습니다.

"비인가 OTA 패키지는 설치되면 안 된다"
"브레이크 ECU는 인증되지 않은 메시지를 수용하면 안 된다"
"Debug Interface는 양산 이후 잠겨야 한다"

그런데 여기서 설계자들이 가장 궁금해하는 질문이 나옵니다.

"그래서 실제 ECU에는 뭘 어떻게 넣어야 하는데?"

Clause 10은 바로 그 질문에 답하는 절입니다.
위협 분석 결과를 실제 ECU 아키텍처와 구현으로 연결하는 단계입니다.

Clause 10은 어디에 위치하는가

Clause 9에서 TARA를 수행하면 Security Goal이 나옵니다. Clause 10은 그 Goal을 실제 제품으로 만드는 단계입니다.

시리즈 전체 흐름에서의 Clause 10 위치

Clause 5·6
조직·프로젝트

→

Clause 7·8
공급망·지속

→

Clause 9
TARA

→

Clause 10
제품 개발

→

Clause 11
검증

→

Clause 12~14
양산·운영

Clause 9와 Clause 10의 차이를 한 줄로 정리하면 이렇습니다. Clause 9는 "무엇이 위험한가"를 분석하고, Clause 10은 "그 위험을 어떻게 막을 구조를 만들 것인가"를 정의합니다.

Clause 10의 핵심 흐름

Clause 10 내부는 크게 이런 단계로 진행됩니다. Security Goal에서 시작해서 실제 구현 코드까지 내려가는 과정입니다.

Clause 10 Product Development 제품 개발 단계 보안

Security Goal 수령

Clause 9 TARA에서 도출된 Security Goal을 제품 개발의 입력으로 받습니다. 이 단계가 Clause 9와 10의 연결점입니다.

Cybersecurity Requirement 정의

Security Goal을 구체적이고 검증 가능한 요구사항으로 변환합니다. 시스템 수준(System Level)과 소프트웨어 수준(SW Level)으로 계층화됩니다.

Cybersecurity Architecture 설계

요구사항을 만족하는 보안 구조를 설계합니다. 신뢰 영역 분리, 인증 구조, 암호화 위치, 키 관리 체계 등이 결정됩니다.

구현 (Implementation)

Architecture 설계에 따라 실제 코드와 설정을 구현합니다. Secure Coding Guideline이 함께 적용됩니다.

통합 및 검증 준비

구현된 보안 기능이 요구사항을 만족하는지 확인하기 위한 검증 계획을 수립합니다. Clause 11 검증의 입력이 됩니다.

Clause 10의 Work Product — 실무자가 꼭 알아야 할 것들

설계자 입장에서 가장 중요한 질문은 "실제로 무엇을 만들어야 하는가"입니다. Clause 10에서 요구하는 Work Product를 정리했습니다.

Work Products Clause 10 — 산출물 목록 실무자 필수 확인

Cybersecurity Requirements 필수

Security Goal에서 도출된 구체적 요구사항 목록. 각 요구사항은 검증 가능한 형태로 작성되어야 합니다. "서명 검증된 소프트웨어만 실행되어야 한다"처럼 Pass/Fail 판단이 가능해야 합니다.

Cybersecurity Architecture 필수

보안 요구사항을 만족하는 시스템 구조 설계서. 신뢰 영역 경계, 인증 흐름, 암호화 적용 위치, 키 관리 구조, 접근 제어 정책이 포함됩니다. 아키텍처 다이어그램과 함께 근거가 문서화되어야 합니다.

Cybersecurity Specification 필수

구현 수준의 상세 명세. 어떤 알고리즘을, 어떤 파라미터로, 어떤 인터페이스로 구현할지 정의합니다. Secure Boot의 경우 서명 알고리즘, 키 길이, 검증 시점, 실패 시 동작이 모두 명세됩니다.

Traceability Matrix 필수

TARA의 위협 → Security Goal → Requirement → Architecture → 구현 구현까지 전 단계 연결 추적 문서. VTA 심사에서 "이 보안 기능이 왜 존재하는가"를 증명하는 핵심 증거입니다.

Secure Coding Guideline

구현 단계에서 개발자가 따라야 하는 보안 코딩 규칙. 버퍼 오버플로우 방지, 난수 생성, 메모리 안전성, 입력 검증 등이 포함됩니다. MISRA-C, CERT-C가 함께 참조됩니다.

Integration & Verification Plan

보안 요구사항이 실제로 구현됐는지 어떻게 확인할지 계획하는 문서. Clause 11 검증 활동의 입력이 됩니다.

Cybersecurity Case (부분)

이 단계까지의 보안 활동 근거를 누적 정리합니다. "우리는 충분한 보안 활동을 수행했다"는 주장의 근거 모음으로, Clause 11 이후 최종 완성됩니다.

Work Product 중 가장 많이 지적받는 것이 Traceability Matrix입니다. 보안 기능 구현은 했지만 "왜 이 기능이 필요한가"를 추적하는 문서가 없으면 VTA 심사에서 인정받기 어렵습니다. 구현보다 추적성 관리가 더 중요한 경우가 많습니다.

Security Goal이 실제 기술로 내려가는 과정

TARA에서 나온 Security Goal이 구체적인 기술 요구사항으로 변환되는 과정을 예시로 살펴봅니다.

Security Goal 비인가 OTA 패키지는 차량에 설치되어서는 안 된다

↓ Cybersecurity Requirement로 세분화

ECU는 ECDSA 서명을 검증해야 한다

공개키는 HSM에 저장되어야 한다

Anti-Rollback을 지원해야 한다

OTA 실패 시 Recovery Mode 제공

Bootloader는 변조 방지되어야 한다

↓ Technical Implementation으로 구체화

ECDSA-P256

HSM Key Slot

Secure Flash

Version Counter

Secure Boot

Security Goal 브레이크 ECU는 인증되지 않은 CAN 메시지를 수용해서는 안 된다

↓ Cybersecurity Requirement로 세분화

CAN 메시지에 MAC이 포함되어야 한다

송신 ECU는 메시지를 서명해야 한다

Freshness Value로 재전송 공격 방지

검증 실패 메시지는 무시해야 한다

↓ Technical Implementation으로 구체화

SecOC (AUTOSAR)

CMAC (AES-128)

Freshness Manager

HSM for MAC계산

Security Goal Debug Interface는 양산 이후 비활성화되어야 한다

↓ Cybersecurity Requirement로 세분화

양산 ECU의 JTAG/SWD는 잠겨야 한다

Debug 활성화는 인증 절차가 필요하다

Debug 잠금 상태는 검증 가능해야 한다

↓ Technical Implementation으로 구체화

Lifecycle State 관리

HSM Debug Auth

OTP Fuse 설정

Secure Debug 절차

21434 Clause 10은 "반드시 Secure Boot를 써라", "반드시 AES를 써라"고 명령하지 않습니다. "무결성이 검증된 코드만 실행되어야 한다"는 요구사항을 제시하고, 구현 방법은 프로젝트 특성과 HW 제약에 따라 선택합니다. 요구사항이 먼저고, 기술은 그 다음입니다.

주요 보안 기술 — TARA 결과가 선택을 결정한다

Secure Boot, HSM, SecOC 같은 기술들은 처음부터 존재하는 것이 아닙니다. TARA 결과로 어떤 위협이 식별됐는지에 따라 선택됩니다.

자동차 보안 기술 — TARA 어떤 위협에서 나오는가

Secure Boot

악성 펌웨어 설치 위협 → 코드 무결성 검증 필요 → Bootloader 단계부터 서명 검증

HSM

키 탈취 위협 → 소프트웨어 키 저장 불가 → 하드웨어 보안 모듈에 격리 보관

SecOC

CAN 메시지 위변조·주입 위협 → 메시지 인증 필요 → MAC 기반 통신 보호

Secure Diagnostics

불법 진단 접근 위협 → 진단 명령 인증 필요 → Seed/Key 또는 PKI 기반 인증

IDS/IDPS

알려지지 않은 공격·비정상 통신 위협 → 런타임 모니터링 필요 → 이상 탐지 및 대응

Secure Flash

물리 공격을 통한 펌웨어 추출·변조 위협 → Flash 접근 제어 필요 → 읽기/쓰기 권한 분리

보안과 현실 사이 — 설계자가 반드시 마주치는 문제

Clause 10에서 가장 어려운 것은 "가능한 가장 강한 보안"과 "현실적으로 구현 가능한 보안" 사이의 균형입니다. 자동차 ECU는 IT 시스템과 달리 RAM, Flash, CPU 성능, 부팅 시간, CAN 대역폭 등 엄격한 제약이 있습니다.

요구하고 싶은 것

모든 CAN 메시지에 SecOC 적용

모든 ECU에 Secure Boot

모든 키를 HSM에 저장

IDS 전체 ECU 적용

강력한 대칭·비대칭 암호화

현실에서 마주치는 문제

CAN 부하 증가 → 주기 Miss → 제어 성능 저하

Boot Time 증가 → 시동 지연 → OEM 요구사항 위반

HSM 탑재 MCU 원가 상승 → BOM 변경

오탐 발생 → 정상 동작 방해 → 안전 문제

저사양 MCU 연산 한계 → 실시간 제어 영향

SecOC를 모든 CAN 메시지에 적용하면 CPU 부하가 증가해 제어 주기가 어긋날 수 있습니다. 이는 보안 문제보다 더 큰 기능 안전(ISO 26262) 문제로 이어집니다. 자동차 보안 설계는 항상 Safety와의 균형을 고려해야 합니다.

그래서 실제 Clause 10 설계에서는 위험도에 따라 적용 범위를 조정합니다. Safety Critical ECU(브레이크, 조향)에 우선 적용하고, 상대적으로 낮은 위험도의 ECU는 Tailoring을 통해 범위를 조정합니다. 이 결정 근거가 모두 Work Product로 문서화되어야 합니다.

Traceability — "왜 이 기능이 여기 있는가"를 증명하라

Clause 10에서 구현만큼 중요한 것이 Traceability입니다. 보안 기능이 구현돼 있어도 "왜 이 기능이 필요한가"를 추적할 수 없으면 VTA 심사에서 인정받지 못합니다.

Traceability — TARA에서 구현까지 연결되는 증거 체인

TARA

위협: OTA 패키지 위변조 가능 — LTE를 통한 원격 펌웨어 교체 시나리오, Damage: Safety (악성 코드 실행), Feasibility: 높음

Goal

비인가 OTA 패키지는 설치되어서는 안 된다 — Risk Level: High

Req

ECU는 ECDSA-P256 서명이 검증된 소프트웨어만 설치해야 한다 — 검증 가능한 Pass/Fail 기준 포함

Arch

Bootloader에 OTA Signature Verification 모듈 추가, 공개키는 HSM Key Slot에 저장 — 아키텍처 다이어그램 참조

Impl

ECDSA-P256 구현, HSM API 연동, Anti-Rollback Counter 적용 — 소스 코드 위치, 버전 정보 포함

Verif

서명 검증 통과·실패 테스트, Anti-Rollback 동작 확인, Pentest 포함 — Clause 11에서 수행

Traceability는 단순한 문서 작업이 아닙니다. "이 보안 기능이 왜 여기 있는지"를 끝까지 설명할 수 있어야 VTA 심사를 통과할 수 있습니다. 실제 프로젝트에서는 DOORS, Codebeamer, Polarion 같은 Requirement 관리 툴이 이 작업을 지원합니다.

OEM과 Tier-1은 어떻게 역할을 나누는가

Clause 10은 OEM과 Tier-1이 긴밀하게 협력하는 단계입니다. 역할 분담이 명확하지 않으면 요구사항이 구현과 어긋나는 일이 발생합니다.

Clause 10 — OEM·Tier-1 역할 분담

OEM

차량 수준 Security Goal 정의 및 System Level Requirement 도출. 전체 차량 아키텍처에서 보안 경계 설정. Tier-1에 Requirement 전달 및 DIA 체결. Cybersecurity Case 최종 취합 책임.

Tier-1

OEM 요구사항을 ECU 단위 Technical Requirement로 세분화. Cybersecurity Architecture 및 Specification 설계. 실제 구현 및 단위 검증. Traceability Matrix 작성 및 OEM에 증거 제출. Tier-2 요구사항 전달 및 SBOM 관리.

OEM이 "서명 검증된 OTA만 허용"을 요구사항으로 전달하면, Tier-1은 이것을 ECDSA-P256 적용, HSM Key Slot 구성, Anti-Rollback 구현으로 구체화합니다. 이 세분화 과정에서 Tier-1의 기술 역량이 가장 중요하게 작동합니다.

현업에서는 실제로 이렇게 경험한다

요구사항 한 줄이 HW BOM을 바꾼다 — "HSM 필요" 한 줄 때문에 MCU 변경, PCB 변경, Flash 증가, 원가 상승까지 이어집니다. 그래서 TARA 결과가 나오는 Concept 단계에서 HW 선정팀과 보안팀이 함께 움직여야 합니다. 이미 MCU가 확정된 뒤 HSM 요구사항이 생기면 프로젝트 전체가 흔들립니다.

Traceability 관리가 진짜 힘들다 — 실제 프로젝트에서는 Requirement 수천 개, Security Goal 수백 개, ECU 수십 개가 연결됩니다. 이 추적성을 수작업 엑셀로 관리하다가 버전 불일치, 누락이 발생하는 경우가 많습니다. 초기부터 DOORS, Codebeamer 같은 툴 도입을 고려해야 합니다.

SecOC 적용 범위 협상이 가장 어렵다 — SecOC를 모든 CAN 메시지에 적용하면 CPU 부하가 올라갑니다. OEM은 전체 적용을 원하지만 Tier-1은 제어 성능 영향을 우려합니다. 어떤 메시지가 Safety Critical인지, 어디에 우선 적용할지 협상이 프로젝트 초기에 반드시 이루어져야 합니다.

보안 Requirement가 개발 중 계속 늘어난다 — 처음엔 Secure Boot만 넣으려다가, 나중엔 HSM, SecOC, IDS, Secure Diagnostic까지 확장되는 경우가 많습니다. Requirement가 중간에 추가되면 아키텍처와 Traceability를 모두 재작업해야 합니다. 초기 Requirement 범위를 충분히 논의하고 확정하는 것이 중요합니다.

Cybersecurity Architecture가 기능 아키텍처와 충돌한다 — 보안팀이 신뢰 영역을 나누고 싶어도 기존 기능 아키텍처가 이미 확정돼 있으면 충돌이 생깁니다. 특히 Gateway 분리, ECU 간 인증 추가는 기존 통신 구조 전체를 바꾸는 경우가 있어 개발 초기 보안 아키텍처와 기능 아키텍처를 함께 검토하는 것이 필수입니다.

마무리

Secure Boot도, HSM도, SecOC도
처음부터 정해진 기술이 아닙니다.
위협을 분석하고, 위험을 평가하고,
보안 목표를 정의한 결과로 선택되는 기술들입니다.

Clause 10은 단순히 "보안 기능을 구현하는 단계"가 아닙니다. 자동차 아키텍처 자체를 Risk 기반으로 설계하기 시작하는 변화입니다. 기능 위에 보안을 얹는 수준이 아니라, 보안을 포함한 아키텍처를 처음부터 설계하는 방향으로 산업이 이동하고 있습니다.

다음 편에서는 Clause 11을 다룹니다. 구현된 보안 기능이 실제로 요구사항을 만족하는지, 공격에 견디는지를 어떻게 검증하는지, Pentest가 어떻게 연결되는지를 살펴봅니다.

핵심 요약

• Clause 10은 Product Development 단계 — TARA 결과를 실제 ECU 설계로 연결한다
• 핵심 흐름: Security Goal → Cybersecurity Requirement → Architecture → Implementation
• 주요 Work Product: Cybersecurity Requirements, Architecture, Specification, Traceability Matrix, Secure Coding Guideline
• Traceability Matrix는 VTA 심사의 핵심 증거 — 구현보다 추적성이 더 중요한 경우가 많다
• 21434는 특정 기술을 강제하지 않는다 — 요구사항이 먼저고 기술은 결과다
• Secure Boot·HSM·SecOC는 TARA에서 식별된 위협에 대응하기 위해 선택되는 기술들이다
• 자동차 보안은 성능·원가·실시간성·Safety와의 균형이 설계의 핵심 과제다
• SecOC는 CAN 부하, Secure Boot는 Boot Time, HSM은 원가에 영향을 준다
• OEM은 Vehicle Level Requirement를 정의하고, Tier-1은 ECU 단위 구현을 수행한다
• 보안 Requirement 한 줄이 MCU·PCB·BOM 전체를 바꿀 수 있다 — Concept 단계 협업이 필수

📚 현업에서 보는 ISO/SAE 21434 — 시리즈

0

ISO/SAE 21434는 도대체 무엇을 바꿨을까? — 오버뷰

1

ISO 21434는 왜 개발보다 조직 관리부터 시작할까? — Clause 5·6

2

차량 보안은 왜 공급망 전체를 관리해야 할까? — Clause 7·8

3

TARA는 왜 자동차 보안의 출발점이 되었을까? — Clause 9

4

보안 요구사항은 어떻게 ECU 설계가 될까? — Clause 10  ← 현재 글

5

차량 보안 검증은 무엇을 증명해야 할까? — Clause 11

6

양산 이후 차량 보안은 어떻게 유지될까? — Clause 12~14

ISO21434 Clause10 ProductDevelopment SecurityRequirement SecureBoot HSM SecOC Traceability CybersecurityArchitecture 차량사이버보안 WorkProduct 자동차규제